spl23
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 378
Joined: Fri Dec 26, 2014 11:02 am

Changes from NuScratch15012016 to NuScratch02052016

Fri May 13, 2016 8:00 pm

Changes from NuScratch15012016 to NuScratch02052016

The major change is in swapping from use of wiringPi to pigpio. This made it easier to extend the GPIOServer to support model servos and the SR04 series ultrasonic sensors so popular with robotics tinkerers. We are using the pigpiod daemon rather than a direct bind to the pigpio library, which has the advantage that other applications can use the same facility and at some point we ought to be able to co-ordinate the pin usage so that applicationA doesn’t think it has gpio21 as an input whilst applicationB is determinedly using it as a pwm output. It also has the ability to accept input from other Pi’s that the one it runs on, which isn’t currently used from Scratch but might be an interesting future feature.

All the low-level device code had to be touched to make this change and despite testing there may be some bugs. One bug already known is that the value range for the pwm outputs is set to 0-255 instead of the 0-1023 that ought to pertain; we’ll fix that for the next release of NuScratch.

Other GPIOServer changes

The new servo support uses two new broadcasts:
‘servoXX%YYY’ to set the servo output on gpio XX to YYY % of movement; 0% is the centre so remember to use ’servoXX%-100’ to go to extreme low-value. You can also use ‘servoXXpercentYYY’ if you prefer to spell it out.
‘servoXXstop’ will close down the the thread that runs the servo attached to gpio XX. It’s a good idea to do this to release resources.
You can see the basic use of these in the new example project ‘gpio-servoDemo’ which will be found in Examples-> Sensors and Motors.
I have limited the pulse width range to 1000-2000 milliseconds with 1500 as a centre position in order to protect the hardware. I know that some servos will accept a wider range but they’re uncommon in my 45 years of model flying.

The ultrasonic support is currently quite basic and only handles a single sensor. There are two broadcasts of interest:
‘ultrasonictriggerXXechoYY’ sets the two pins used by the SR04. You won’t be startled to hear that the gpio XX is the one attached to the trigger pin of the sensor and YY is the one for the echo pin. Remember to do the correct wiring for these sensors since they use 5v and the echo pin voltage must be scaled down to ~ 3v to protect your Pi.
‘ultrasonicclose’ shuts down the thread that monitors the SR04.
The result from the ultrasonic sensor are provided as a sensor variable ‘ultrasonicdistance’ giving you the distance measured in centimetres. The example project ‘gpio-ultrasonicDemo’ (also on Examples -> Sensors and Motors) illustrates how this can be used to set the position of a sprite.

Camera use: some reports of the broadcast ‘photo’ not working intermittently lead to a revised way of getting the camera to take a snapshot. This seems to be much more reliable but there are still cases where the camera OS level drivers simply can’t provide a picture in a timely manner, so just occasionally it may still fail.
To make using the camera a bit more flexible there is a new broadcast to allow requesting a specific sized image. ‘[email protected]’ will request an image XXX pixels wide and YYY pixels high. There are some cases the camera simply won’t accept - for example ‘[email protected]' sometimes looks strange, and ‘[email protected]’ simply won’t work, and asking for a [email protected] image will strictly speaking work but you might get very bored waiting for it to transfer and appear in Scratch.
I also added ‘photobig’ (or ‘photolarge’ whichever you prefer) to grab an image the size of the stage.

System changes
There is a new and slightly faster Squeak virtual machine.
The entire code for displaying the stage and sprites has been reworked to clean up a lot of ancient ugliness. The major visual effect is that dragging a sprite in the small stage now works correctly (and in fact more correctly than the original Scratch release) for precise positioning of the dropped sprite and the size of the sprite whilst being dragged. It also works for odd scales rather than just half or double, so maybe we can extend the stage sizes some day.
Font sizes for Scratch can now be set by editing your ‘.scratch.ini’ file (remember the first dot!) and adding a line
fontscale=1.5
or a similar number; much outside the range 0.7 - 2 will tend to make things look ugly because it stretches the layout beyond it’s decent limits.
The Japanese translation files have been extended and improved a little. If you are multi-lingual and spot problems in any of the translations, do please let us know and maybe volunteer to help edit the relevant files!

Known issues
As Simon mentioned the changes to support Bluetooth audio have caused problems with ALSA that are not yet solved for Scratch.
Anyone using xrdp (and possibly other remote desktop facilities) will still need to use ‘sudo’ even though we no longer need it for gpio access. This is due to some issue with xrdp and so far no one has any information about how it might be solved. For now, the solution is to edit /usr/bin/scratch and make sure that the line starting with
WRAPPER=
reads
WRAPPER=“sudo -E "

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 5:22 am

Great stuff, Tim! Thanks for the updates, I'll have a play with them this weekend.

Next request - support for cheap stepper motors (ie. 28BYJ-48's), please!

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 3:11 pm

I found some time to have a quick play with a servo and HC-SR04, so I'll give you my initial thoughts.

First, an apology - I see now that you're not Tim, as I said above! Unless you're incognito, of course!

So, first impressions;

Well done on implementing support for these components, as I feel they are essential for primary school use. The commands are easy to understand and use. However...

Servo - movement is ok, but the range is severely limited! I estimate it to be about 75-80 degrees. Is this intentional, or something that just needs finessing?

HC-SR04 - although quick to respond, the average reading seems to be under-reporting by about 20% (ignoring the odd 'way-out' reading, which you expect from these devices). IE, 10cm actual shows as 8cm, etc. Not sure whether this is down to the choice of resistors in the divider, which might give slightly different voltages. You don't give any recommended values in your description. I used 470R & 330R as I normally do.

Edit - just found your diagrams on Github, and tried with those resistors, but the results are the same.

I hope my feedback is of help.

Thanks.

timrowledge
Posts: 1286
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 4:07 pm

Actually that is me writing above ; it's just that Simon posted it on the forum rather than adding it to the Raspbian release post.

So - servo movement. This is a bit of a problem in that for 45 years I've been flying radio controlled models and servos have always been specified as accepting pulses between 1-2mS with an expected centre at 1.5mS. Going outside those values would be considered A Bad Thing likely to damage the servo and so that's the limit I have currently set. I'll see if I can find anything that convinces me it is smart to exceed those values; feel free to point me to specs etc that might make the point.

Ultrasonic - I'm pretty sure the voltages shouldn't noticeably affect the result, other than a way-too-low main vcc probably meaning it won't work at all, and a too-high echo output will prevent proper measurements by releasing the magic smoke from your Pi. It's all done by timing the signals and some arithmetic to convert time into distance. The code to do the calculation can be found in joan's SRTED.c (part of the pigpio sources that you can see on her website at http://abyz.co.uk/rpi/pigpio/code/SRTED.zip) and I'l admit I didn't double check the constant used to convert microseconds to centimetres in the _cb() callback function. I hope it's correct! I suppose there is some possibility the timing is off a bit, maybe if you've done any over-clocking? I'll see if anyone can hook up a scope to look at the signals.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 6:05 pm

Hi, Tim! So you're just trying to confuse me then ;)

I sort of understand what you are saying about the servo's range of movement but, 45 years experience notwithstanding, the use of servos in model aircraft is quite specific and narrow, usually involving quite small, accurate movements. In robotics, and indeed in primary school Physical Computing, the range of tasks that the servo is called upon to do is far wider - waving flags, level-crossing barriers, moving a sensor from side-to-side, robotic arms, and so they need a greater range of movement. Indeed, most of the examples that I've seen & used, and the stuff I've done myself, utilise near-on 180 degrees of movement, and all of the 3rd party Scratch gpio software allows that sort of range. The other difference is that, in RC flying, the operation of the servo is pretty critical to the wellbeing of the aircraft, so it's important to be nice to it. In primary school robotics, this is not really the case. We're using servos that cost a couple of pounds, as opposed to the 'proper' RC stuff that can cost over £100 :o . So trashing a 9g Microservo is no big deal, they are effectively disposable.

As for the HC-SR04; well I know they're not the most accurate bits of kit to start with, and there's a fair bit of maths & timing involved to get anything resembling a sensible answer form them. I'll have a look at the document that you referenced and have a further play with different set-ups. I think I need to start thinking about some of this stuff for myself, instead of badgering you about it all the time ;) . Some Pi stuff using the HC-SR04 uses it in 1-pin mode, so the Echo & Trigger are connected to the same gpio with the addition of a 3rd resistor. Have you considered this method, and if so, is their a reason that you didn't use it, although I'm pretty sure it makes no difference to the accuracy. None of my Pi's are overclocked ( I love them because they're fun, not because they're fast), and my quick test was done on a stock Zero with a fresh Raspian install. I'll try my old B though, just out of curiosity.

As always, Tim, great work. I appreciate all of the work you're putting into Scratch for us Pi users, even though I don't see the point of the quest for more speed; I just want more fun!

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 6:19 pm

Ok, just a quickie. I've just had a quick read through that C code (it's bloody hard in Notepad, as well :? ) and compared it with another example (at http://www.modmypi.com/blog/hc-sr04-ult ... spberry-pi). There is a small difference in the constant; the C example uses 17015 (once adjusted for cm) and the ModMyPi code uses 17150. It is, as I said, a small (ok, tiny) difference, but it's one thing I've spotted so far).

User avatar
joan
Posts: 14356
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 7:30 pm

ESCs (used to control brushless motors such as those used in quadcopters and probably planes) are controlled like servos but are typically constrained between off (1000 µs) and full throttle (2000 µs). I wouldn't be surprised if other aircraft control are also limited to 90 degrees and a similar pulse range.

pigpio limits pulses to be between 500 and 2500 µs, perhaps arbitrarily.

On the sonar ranger incorrect distance could you put a scope on the line and get some figures for echo high duration versus reported distance? That's the simplest way to definitively check for errors.

timrowledge
Posts: 1286
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 11:05 pm

Forris wrote:Hi, Tim! So you're just trying to confuse me then ;)
Well, duh. How else am I supposed to get any pleasure out of life?
Forris wrote:I sort of understand what you are saying about the servo's range of movement but {snip}
I'm happy to admit my bias here. We don't like to torture our model controls too terribly because Bad Things Can Happen to my $2000 models. It's worth reading, for example, https://www.pololu.com/blog/17/servo-co ... -in-detail

I suppose I could adjust things to allow a wider range, perhaps under some option setting with a warning in letters of smelly fire.
Forris wrote:As for the HC-SR04; well I know they're not the most accurate bits of kit to start with, and there's a fair bit of maths & timing involved to get anything resembling a sensible answer form them. I'll have a look at the document that you referenced and have a further play with different set-ups. I think I need to start thinking about some of this stuff for myself, instead of badgering you about it all the time ;) . Some Pi stuff using the HC-SR04 uses it in 1-pin mode, so the Echo & Trigger are connected to the same gpio with the addition of a 3rd resistor. Have you considered this method, and if so, is their a reason that you didn't use it, although I'm pretty sure it makes no difference to the accuracy.
Yes; I didn't understand it and concluded that if I couldn't work out how it worked it might be a bit of an issue for kids. I like to hope I'm as smart as, and more knowledgeable than, most kids...
Forris wrote:As always, Tim, great work. I appreciate all of the work you're putting into Scratch for us Pi users, even though I don't see the point of the quest for more speed; I just want more fun!
Faster is better because it means you can do more in the same time, which means you can do cleverer algorithms for your robot motion, or game character behaviour, or financial transactions etc. And it's a symptom of making the code better (At least in this case, where the original code wishing Scratch was truly ugly in a lot of places) which is simply The Right Thing To Do. As an engineer of various sorts, I have CDO, which is OCD with the letters in the order they damn well should be in!

For software I'll tolerate C, enjoy ARM assembler and adore Smalltalk. In fact I often write any C or assembler in Smalltalk and use Slang to output the C/Asm as required. C++ is the most evil nonsense known to software-mankind, unless you insist on considering all the other dreadful things out there like java/python/apl/etc, which is neither good for my sanity nor your safety, so lets not.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

timrowledge
Posts: 1286
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Changes from NuScratch15012016 to NuScratch02052016

Sat May 14, 2016 11:09 pm

Forris wrote:There is a small difference in the constant; the C example uses 17015 (once adjusted for cm) and the ModMyPi code uses 17150. It is, as I said, a small (ok, tiny) difference, but it's one thing I've spotted so far).
Ah, well I guess that's a typo since the speed of sound in air at STP is 343.1m/s and thus the constant needs to be 17155 to allow for the double path length. The difference is only 1% though, so clearly it isn't the major cause.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Changes from NuScratch15012016 to NuScratch02052016

Sun May 15, 2016 5:13 am

timrowledge wrote:I'm happy to admit my bias here. We don't like to torture our model controls too terribly because Bad Things Can Happen to my $2000 models. It's worth reading, for example, https://www.pololu.com/blog/17/servo-co ... -in-detail

I suppose I could adjust things to allow a wider range, perhaps under some option setting with a warning in letters of smelly fire.
Thanks. Yes, indeed, RC models falling from the sky isn't a good thing for anybody, but the same level of risk does not apply to primary school robotics, where it's all about how much usability & fun can be had from each component.
timrowledge wrote:Yes; I didn't understand it and concluded that if I couldn't work out how it worked it might be a bit of an issue for kids. I like to hope I'm as smart as, and more knowledgeable than, most kids...
I'll agree with you on knowledgeable, but I've found that thinking that you're smarter than most kids can be dangerously embarrassing :oops:

I'll put my limited knowledge to work and see if I can find a reason for you to consider it.
Forris wrote:As always, Tim, great work. I appreciate all of the work you're putting into Scratch for us Pi users, even though I don't see the point of the quest for more speed; I just want more fun!
timrowledge wrote:Faster is better because it means you can do more in the same time, which means you can do cleverer algorithms for your robot motion, or game character behaviour, or financial transactions etc. And it's a symptom of making the code better (At least in this case, where the original code wishing Scratch was truly ugly in a lot of places) which is simply The Right Thing To Do. As an engineer of various sorts, I have CDO, which is OCD with the letters in the order they damn well should be in! :lol: :lol:

For software I'll tolerate C, enjoy ARM assembler and adore Smalltalk. In fact I often write any C or assembler in Smalltalk and use Slang to output the C/Asm as required. C++ is the most evil nonsense known to software-mankind, unless you insist on considering all the other dreadful things out there like java/python/apl/etc, which is neither good for my sanity nor your safety, so lets not.
Ok, I'll admit that that last sentence went mostly over my head! I really need to learn more...

Forris
Raspberry Pi Certified Educator
Raspberry Pi Certified Educator
Posts: 279
Joined: Fri Jan 06, 2012 7:46 pm

Re: Changes from NuScratch15012016 to NuScratch02052016

Sun May 22, 2016 3:20 pm

Tim,

Ok - I've thought a bit, done some experimenting, and had a chat with Simon (ScratchGPIO).

Re. the 3-pin mode, this is Simon's answer:

"I just found a post on the internet that said do it that way – I did – and it worked :). 0.5 of 5V is 2.5 which would be recognised as a good high signal. I presume the other resistor is just defensive protection."

After a bit of thought, it made sense. To set an input pin High needs just over 2V, so 2.5V is fine. You don't need to bother with an exact conversion from 5V to 3V3.

As for the 3rd resistor, I'm currently running it without one (as per the instructions for 4-pin mode) and it works exactly the same.

One more thought, and I haven't tried this yet, but I think that you could ignore either Trigger or Echo entirely! The two transducers are identical and are both capable of Tx and Rx. So if you use 3-pin mode, you would only need to use one or the other. Actually, a thought just occurred to me as I was typing. If this was indeed the case, you could (I think) use both, but as separate units, and average the results. Also, if you take a look at Simon's code, you'll see he sends 3 pulses for every measurement and takes the median, which gives better accuracy as it filters out any daft results.

Hope that helps.

Return to “Scratch”