Modifying Scratch On Raspberry Pi for GPIO

I’ve been have a discussion via DM on twitter with David Whaley (@whaleygeek) about producing a modification of Scratch that has native blocks for GPIO (particularly for robot motor controls)

Enchanting is an example of such a mod to control LEGO motors that runs on x86 based computers.

He says – wouldn’t it be great to have such a mod for the Pi to do similar things – and he’s right of course 🙂

It would just be a matter of a bit of effort to make such a mod for the Raspberry Pi but there are some considerable issues both political and technical that make this simple task quite challenging.

To make reading easier – lets call a proposed mod RoboPi

Developing from NuScratch

The current version of Scratch on the Pi (commonly called NuScratch) is a major re-write/speed-up of the standard Scratch 1.4 that is used on all other platforms.

(The original Scratch 1.4 is still available and still works on the Pi – albeit much more slowly)

Therefore it would be good to use NuScratch as a source to make a Scratch Pi mod with dedicated motor/leds etc blocks – lets call this proposed mod RoboPi just to give it a label.

But NuScratch is under constant development so if someone was to take the current snapshot and develop RoboPi from it – it would miss out on further speed ups that are promised.

NuScratch source code has not been released which makes the job even harder.

Developing from Whiskers

Another young developer is working on a Scratch 1.4 mod,  called Whiskers, to make it look and behave like Scratch 2.

So this would make it a good candidate as well as basis of RoboPi but it too is under constant development and isn’t quite stable yet (simplified statement of its current development position)

But since the code is open source, it would be possible to go ahead and just keep importing and Whiskers development into RoboPi – painful but possible.

Developing from original Scratch 1.4

This has great advantage of stability (code is rock solid stable and open-source)

But it would lose out to NuScratch in terms of speed on the Pi and the target audience of young Scratchers are not known for patience when it comes to GUI response times.

Problems with Raspberry Pi Foundation

The very poor relationships between myself and the Foundation have to be taken into account with my next statements 🙂

Raspberry Pi have done some sort of deal with MIT to make major changes and behaviour to NuScratch and keep using the Scratch name and Scratch logo.

This deal is not available to ANYONE else, which means any other mods are not allowed to call themselves Scratch.

Although NuScratch was developed from the open-source Scratch 1.4 code base – NuScratch source code is not available (for undisclosed reasons)

Raspberry Pi will not talk to me and, given past experiences, would actively try to negate/sabotage any initiative with my name on it.  So someone else would have to lead and drive this project.

Is there someone else with the time/experience/drive to do this?

And if so – which route to go down?

Alternatives to Scratch

Develop RoboPi from another Block Language

Using any other existing block languages (such as Google Blockly) suffer from not being Scratch!  So this invloves extra learning curves for both pupils and teachers – fine for Gifted & Talented ones – but raises the entry bar for all others.  The pedalogical effort that has gone into Scratch is not something to be thrown out without a very good reason.

Develop RoboPi independantly

Obviously the solution to all this is to invent our own new block language for physical computing see – XKCD927 and I leave reader to decided whether this is a good path

Make RobiPi look and feel like Scratch

Not as daft as it sounds 🙂

Joseph from Redfern Electronics did this with the Crumble (Best physical computing device for primary education IMHO).  Crumble software looks and feels VERY similar to Scratch but without the graphics/sound elements of Scratch.

Because it implements a sub-set of Scratch syntax and abilities – just blocks needed for physical computing – the editing GUI response times could be made to go away and a nice lean piece of software could be made.

I would suggest that RoboPi should to copy exactly the standard Scratch block colours and syntax so that the learning curve is minimised.

It might even be possible that by simply cutting out the unneeded elements from Scratch 1.4, that it could be gain the necessary extra editing response speed of NuScratch.

Simon

 

 

You may also like...

19 Responses

  1. Darren Townsend says:

    Any of the above options are valid, but my feeling is that for the target audience (mainly primary schools) you really need One App To Control Them All ! If you have something specific enough, like Lego Mindstorms, then a stand-alone piece of software is acceptable, but if you’re just talking about controlling motors and sensors, then you need to use the same software that you use for LEDs and buttons.

    For example, as we’ve spoken about before, I’m currently doing some stuff on Physical Computing with my son’s primary school, using Scratch on Pi’s. I’ve personally used your ScratchGPIO since you started it but, in school, I’m using NuScratch because it comes already installed, which is easier and makes the process feel more ‘polished’. My next session will be on sensors, ideally the Ultrasonic Sensor module. However, Tim Rowledge is currently struggling to get this implemented, so I may have to revert to ScratchGPIO which, although excellent, has a different syntax and setup methods.

    Switching from one package to another just to do something this simple is the sort of thing that will put schools off using it altogether, especially in schools like ours where there is no-one on staff (I’m just a fanatical parent, remember) that understands how this stuff works.

    So the point is (in case you were wondering), if you head off in a different direction (and I perfectly understand and support your reasons for wanting to do so) then you’re basically going into ‘competition’ with the RPF product, and I would worry about the image that this would project to schools that are already confused by all these new-fangled devices and methods.

  2. cymplecy says:

    The reason for the post was to get discussion away from private DM – not to propose any one solution to the problem but to highlight the issues surrounding it 🙂

    SZero is my current development path – e.g a fix for the missing functionality of NuScratch until NuScratch implements control of other devices natively.

    People that only need basic GPIO control can just use NuScratch but if they need extra devices then they can use SZero which will only control them and let NuScratch deal with basics.

    As and when NuScratch gets devices added, they will be removed from SZero.

    So getting back to topic 🙂 This post is about native blocks for GPIO/Robotics – no more

    broadcast GPIO24PWM512

    blocks – its about having a block that says:

    assign Motor 1 to pins 24

    and then use it

    set Motor 1 to 512

    etc

  3. Darren Townsend says:

    That’s fine, and I fully support SZero, and am as frustrated as you are with the apparent lack of progress on NuScratch’s support for basic hardware. But I really think that unless you’re going to launch a stand-alone package, with the possible issues that may result, then our best course of action is to trust that the RPF and Tim are going to get this sorted. If we apply (by which I mean people other than yourself, for obvious reasons) the right amount of pressure/influence/annoyance/assistance then we may be able to help it get done quicker.

  4. tim says:

    Y’know, you could – any and all of you – actually talk to me. There’s absolutely no need for any sort of competition here. I don’t have time to do all the things I (let alone everybody else) want but if people actually communicate clearly then at least stuff can go on my list!

    Adding custom blocks is certainly possible; not trivial but doable. It means becoming not compatible with vanilla Scratch, which was a big thing that many people argued for not so long ago and was a factor in my not getting asked to do an of them. Maybe people don’t worry so much now that MIT have gone nuts and made that strange decision to go Flash.
    I am tim@rowledge.org if you feel the need to email me directly, or just post on the raspberryPi scratch forum.

    • cymplecy says:

      Unfortunately I’m not allowed to post on the forum and taking things to email just hides conversations from everyone except the addressees.

      Your work to speed up Scratch on the Pi is great 🙂

      But obviously there is a big rift in the software universe re GPIO control from Scratch.

      I (and others) already enabled anyoen to control pretty much any hardware addons from Scratch.

      In my view you are seemingly working to replace all the hard work done by myself (or others such as Gerhard) instead of integrating this and doing it differently (using values of 0-1024 instead of 0-100).

      If you’ve done this under instruction from bad people at the Foundation – its understandable – they are paying – they get what they want – and they want to stick it to me and obliterate my efforts.

      If you did it for other reasons – then that is not understandable because ability of Scratch to control add-ons has been set back.

      Now – its no good saying that people can still use ScratchGPIO as in reality – they are using inbuilt GPIOServer (and spending time and effort re-writing instructions and videos and tutorials!!!!!)

      I think you have to take some responsibility for this situation and I suggest that you should re-assess what the objective is here

      if you fully read my blog article – believe I articulated how it is VERY BAD to fork an existing actively being developed project.

      You don’t have time/effort to get GPIOserver to level of functionality of ScratchGPIO within any sort of reasonable time.

      Your code is not open – we can’t fork it wven if we wanted to (and we don’t because that is VERY BAD idea)

      So everyone is stuck

      We can’t develop RoboPi (well we can but it would be studid to do it while your are actively developing NuScratch)

      Now – if your part of the rosy specs RaspberyyPi are great and can do no wrong and anyone who says otherwise neeedss shooting camp – carry on.

      If not – why not put some effort into reaching out and embracing the community and not just be coding up in your ivory tower.

      I don’t care one iota if my code is re-written – its poor code – it works – but is poor code.

      But what I get VERY irrate about is that kids are losing out due to a political battle between so called adults 🙂

      I’l stop now and I’d just like to say – PLEASE PLEASE PLEASE do not get upset and take marbles home like RaspberryPi have done.

      Can you come up with someone positive that will let us all work together (even if we have to keep it secret from RaspberryPi and they can’t spell co-operation) 🙂

      Simon

    • Darren Townsend says:

      Hi Tim. Good to see you’ve found your way here and are willing to join the conversation. We have ‘spoken’ on a few occasions on the RPF Forum, re. NuScratch’s lack of support for, what I would consider to be, basic hardware (ie. the bits in the CamJam Edukits). I realise that you are under different pressures that an individual like Simon would be, but you seem to have spent a lot of time and effort in trying to support every bit of hardware out there without, it would seem, a coherent strategy and with no consideration for the end user, which in my opinion will be mainly schools. I don’t see that schools will be buying proprietary add-ons when they can achieve the same thing (and probably learn more) using single components. The Pi is supposed to be about getting the kids back to basics, so what’s the point in giving them plug-n-play modules? So, instead of adding support for the 10th different motor controller board, why not just use a generic board that can be bought from Ebay for pennies?

      I’ve been using Simon’s ScratchGPIO since the start, but having GPIO functionality built-in to Scratch from the start makes life much easier when you’re trying to ‘sell’ the concept to (non-geek) primary school teachers and kids, but the current situation is not good. As an example, last term I led my first two Physical Computing sessions at my son’s school. We were covering the use of LEDs and buttons and we coded them using GPIOServer, so I talked through how to set the pins up (Broadcast Config, etc). Next time, I want to introduce sensors, and specifically the HC-SR04module as I think it has a lot of scope for some fun projects. As GPIOServer doesn’t support these yet (even though they are part of the CamJam Edukit3 which occupies so much of my Twitter feed as it’s used at PiCademys), I’m going to have to revert to ScratchGPIO, which means going through a different procedure to configure the pins, not to mention using a different version of the same software!

      From the conversations that I’ve had with you, Tim, you seem like a really good guy trying to please lots of parties who all have different priorities and, understandably, your main focus has to be what the RPF want you to do. You always say that if there’s something that we feel should be done, we need to email the Foundation which will get them to task you with it, which sounds plausible, until you find that there is no specific contact for Education, and the general contact email states ‘We can’t promise to reply because we get thousands of emails’, which is at least accurate, they don’t reply, I’ve tried!

      Lastly, as Simon said, your project is not open, so no-one is able to offer help (I couldn’t anyway, you’re way above my skill-level!), even if they could. I think we’d all be interested to know what (if there is one) the roadmap is for your project. Is there a time-scale? How long is your To-Do list? What are your priorities, and who sets them? And what can we do to help, besides crossing our fingers or sacrificing our first-born’s to the RPF gods?

  5. Scratch is good but I was horrified with how the connection to hardware works. That needs abstracting away. If you have a look at what’s been done with the block editor for the Microbit they have blocks such as digital-write or servo-write and device-camera-take-picture.
    At the end of the day, kids or don’t care if it’s pure scratch or not they just want something easy to use. If scratch can’t provide that then they will use something else.
    For my latest project I’ve ended up using Node-Red as that allows me to abstract away the details of a servo or stepper motor and provide simple connectors for “forward, backwards” if people want to look inside then they can, but they don’t have to.

  6. Darren Townsend says:

    Good morning, Simon. I realise I’m going backwards a bit here (it’s what all the cool kids are doing, apparently), but I’m having a conversation on the Pi forum with Tim Rowledge regarding ultrasonics. I have asked why he has chosen to go 2-pin instead of 1-pin, and his answer was that he didn’t understand the 1-pin diagram. Now, I thought I did, until I looked at it again…and it seems that I don’t!

    So, can you explain the purpose of the 3 resistors, please? I originally thought that the resistors that connected ECHO to GPIO23 via GND formed a 5v/3v3 divider, but now that I look again I see that they are identical, so that can’t be the case…can it?

    Also, what is the purpose of the resistor between the GPIO and TRIGGER? Is it merely to limit current, and why is it needed for the 1-pin method and not for the 2-pin method?

    You’re probably bored to death of the whole NuScratch saga, but I’m still hopeful that it can be brought up to scratch (pun intended, although poor!) with a little nudge every now and again. Unfortunately, I don’t have the programming knowledge and experience to state my case with the certainty that I would like, so I just need to make sure I understand it properly myself.

    Thanks.

    • cymplecy says:

      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 🙂

      Simon

      • Darren Townsend says:

        Yep, that makes perfect sense. After a bit of thought while walking the dog (it’s where I do most of my thinking, it’s not a euphemism), I figured the bit about the resistor divider being identical resistors. I think I was trying too hard to get to 3.3V when, as you said, that’s not necessary.

        As for the 3rd resistor, I think it’s superfluous. I’ve currently got it running without it and it’s fine. I’m also pretty sure that you could ignore either the Trigger or Echo pin entirely, as the transducers are identical. So you could use the same transducer to do both jobs – I think?

        • Darren Townsend says:

          I just had another thought while typing a reply to Tim, on the forum. From what I understand, the two transducers are identical and are both capable of Tx and Rx. If this is the case, then you could ignore one of the pins completely and just use the either the Trig or Echo pin for both jobs. This should also mean that you could use both transducers independently, just as if you were using two separate modules?

          That’s it, I’ve done too much thinking today! I need a beer…

  7. Jack says:

    I may be interested in trying out scratchgpio. However the installer gives no indication of what it does and quite frankly it’s bad practice to trust a random internet site.

    Is the source available in an open form?

    • cymplecy says:

      its all on github v7 is stable branch https://github.com/cymplecy/scratch_gpio

      Its intended for kids and teachers 🙂

      And since I’m the world’s leading physical computing Scratch person I object to the “random internet site” 🙂

      Its been superseded by Pis own version BTW – your about 3 years late to the party 🙂

      • Jack says:

        Thanks. I’m interested in looking at the methods used.

        I don’t mind being late to the party as long as there’s something to drink.

        • Darren Townsend says:

          Oh, the party’s still in full swing. In fact the older kids have gatecrashed and are trying to take over the stereo (does using the word ‘stereo’ make me seem old?).

          There’s still plenty to drink though, but beware, the stuff that the older kids are peddling is like a new wine – very well packaged and from a reputable source, but it lacks depth and could leave a bit of a sour taste. The stuff that Simon’s offering is much more mature and well-rounded, and any change to the recipe has been done gradually, in response to customer feedback and has only enhanced the final product.

          *Simon, I wish you hadn’t started this party analogy. I’m trying to stop myself coming up with more puns, and it’s Friday and I’ve got 3 days off, so I’m a bit demob-happy as well! Also, I’d like to apologise for giving up on ScratchGPIO, in favour of gpioserver, but I’m back with you now and will be installing it on the school Pi’s (which we can now buy with the £250 that my company have just donated to our cause…YAY!!!). Keep up the good work, and if I’m able to make my way up to one of your events up North sometime, I’ll buy you a pint.

      • Darren Townsend says:

        …and he’s much better at making Scratch do cool stuff than he is at punctuation:P

  8. Hi!

    I just found this thread, and I thought I’d throw my $0.02 in 🙂

    The current “broadcast” model is terrible, and much harder to explain to kits.

    I’ve had many requests from teachers to support Scratch for my RoboPi and PiDroidAlpha robot controller boards, and I’ve looked into it every six months or so. I’ve emailed with Tim several times, and he sent me suggestions to look at NuScratch and several other comparable block oriented languages.

    NONE of them appear to be easily extensible with C or Python. The latest scratches are fully dependant (as mentioned above) on Flash, another ridiculous decision.

    This is NOT great for the kids, teachers, and RPF.

    Scratch needs some simple common blocks, with some means of tying Python or C code to actually implement the functionality.

    At a minimum:

    digital read, digital write
    analog read, analog write
    pwm frequency
    motor speed/direction
    ultrasonic distance sensor

    Ideally of course it should be extensible for other custom blocks, but leave the implementation detail to python.

    • cymplecy says:

      Welcome to the discussion William 🙂
      The broadcast model was/is used so that it doesn’t materially alter squeak based Scratch and therefore it can still be called Scratch.

      However, given the fact that Tim has altered Scratch 1.4 so much now I think he/Foundation should just do a deal with MIT and call it officially PiScratch and do for the dedicated blocks

      Alternatively, now that we have the super fast (relatively speaking) Pi3, BYOB 3.11 runs sufficiently well that running a ScratchGPIO type application (e.g using broadcasts to send signals to an unlying Python prog) is full viable and fast enough for general use to achieve your aim of having dedicated blocks calling Python code (via the broadcast mechanism but hidden from end users)

      BYOB is a bit tool slow to run on PiZero (but since its not really a viable product for people like yourself to target – maybe that doesn’t matter)

      In fact as I write this, I think I should start working on PiBlock http://simplesi.net/piblock/ again 🙂

      I do very much like your idea of having generic common block names and then just each hardware retailer making their own Python interpreter for each one

      Obviously, I can’t let mention of RPF going by without adding my 2 cents 🙂 They don’t care about the kids – they really don’t – its all about them having control – if they cared about kids, they would have worked with myself or Gerhardt or Tony and taken one of our Scratch gpio implementations as a starting point instead of paying someone to start all over again (with the obvious delay it caused/is still causing) and to make it effectively closed source is the worst aspect of it all 🙁 🙁 🙁 Bad people – very bad people 🙁

  9. Darren Townsend says:

    Simon,

    I’m sure I’m going to hate myself in the morning, but I agree fully with your last paragraph!

    As you know, I went over to NuScratch for a while, mainly because it is packaged with the standard Raspian, which makes it easier to ‘sell’ to teachers. But progress has just been so damn ssllloooowwwww…..

    One way in which your assertion that they’re not thinking of the kids (or at least certainly not with Scratch) really hits home with me, is the recent implementation of servo support. The full range of travel is around 50 degrees ! When I asked Tim about this, when it was still in planning stage, his decision was based on his 20+ years experience with servos in model aircraft. I tried explaining that the end-user requirements were completely different, and that $2 micro servos didn’t need the same level of protection as $150 professional ones, but he’s ploughed on with it regardless. This was the final straw for me, as whoever is overseeing Tim’s work either has no clue about what NuScratch is used for in a Primary setting or, as you say, doesn’t care.

    I actually think that the RPI has lost interest with Scratch, as the focus seems to be very much on Python these days. This is all very nice, but not we want at KS2 level. Scratch is the best tool IMHO for grabbing the kids’ interest; they are already familiar with the interface, so you’re really just expanding on their current knowledge.

    I don’t always agree with what you say and the way that you say it, but ScratchGPIO is the thing that’s had the biggest impact on me and enabled me to introduce the Pi into my son’s school and help the school to expand their Computing curriculum. Tomorrow I am running my first after-school Pi Club, and I don’t think I’d have had the confidence and ability to do that without the stuff I’ve done and learned using your software.

    NuScratch may be a dead duck, but I’m doing my bit to make sure that ScratchGPIO has a strong future.

Leave a Reply

Your email address will not be published. Required fields are marked *