Forris wrote:Thanks for this post, Tim. It's a shame that you haven't found a way to add the ultrasonic sensor yet.
Yup. It's a bit tricky to do cleanly. We need to claim two gpio pins and to avoid clashes with other devices it needs to be possible to specify which two. Then the dratted sensor works by requiring a busy-wait loop, which is death to an interactive UI, so at the least it needs to spawn a low-level thread. And the repeatability is terrible (in my experiments my office apparently jumps from 1.4m to 7m wide, which isn't technically impossible but is quite unlikely) so one has to do several measurements, throw out apparently obvious outliers and average the remainder. I suppose one could do a sort of running average in this background thread... hmm. Maybe.
Forris wrote:That and servo control are, for me, the 2 must have items for use in primary school robotics with Scratch.
I understand and would very much like to get it working soon. Servos are a problem when using wiringPi right now because the pwm code therein simply can't manage the frequency response needed. A new servo-pwm api is needed somewhere. I'm assuming you also understand the current limitations involved; some of the cheap servos out there pull a bit more than is helpful even on the control line.
There are some pretty neat servo-control HATs too that would be good to support.
Forris wrote: I was quite excited when I saw that the EduKit is now supported, but sadly it seems (and I really don't mean this to come across a harsh as it looks when I typed it, I appreciate the hard work that you're putting into this project), that it adds nothing extra, as it functions the same as the RyanTeck board.
Yup, but different gpio pins, which is quite important! I wish people would co-ordinate a little on this. There are now several dual motor boards to support, some using pinA->direction, pinB->speed and others using pinA->forward speed, pinB->backward speed (and don't you mix them up!) Why this madness! Make it stop!
Forris wrote:Anyway, please keep up the great work that you are doing on Scratch. One more thing that would be nice, though, is a 'Broadcast AllOff' block, which is really helpful when working with lots of leds.
That might be even trickier; we'd need to be able to reliably track exactly which pins we have control over (which is a big problem currently since you could be running several programs that access gpio via a variety of libraries, all thinking they have control) and which are outputs in order to be able to turn them off. You can tell I'm a real engineer by the way this sort of thing worries me...
I guess an approximation to sanity might be plausible by trusting our list of pins set as outputs by Scratch but I can't help thinking of the chaos ensuing as a simple 'gpioalloff' turns off the atmospheric cycling units on the ISS.
And as always - if you need more capabilities, and especially if you're a teacher wanting them for lesson plans, contact the foundation and request, nay *demand*, them. That gets turned into my time, which gets turned into new features.