Building Sensors For The Scratch Programming Language

[Kevin Osborn] is making it a bit easier for young programmers to write programs that interact with the physical world. The device he’s holding in the picture is an Arduino based accelerometer and distance sensor meant for the Scratch language.

Scratch is a programming language developed at MIT. It has kids in mind, and focuses on graphical building blocks. This can make it quite a bit easier to introduce youngsters to programming concepts without the roadblocks and gotchas that come with learning syntax.

As you can see in the clip after the break, [Kevin’s] Arduino sketch includes hooks that automatically pull the accelerometer and distance data into the Scratch environment. We figure his example provides everything you need to get just about any type of sensor up and running, be it a magnetometer or LDR (both of which would make a nice burglar-alarm type project). Give it a try with your own hardware and see what you can accomplish.

8 thoughts on “Building Sensors For The Scratch Programming Language

    1. The main problem with programming languages is that the really useful ones are a little too abstract for kids. BASIC or some scripting language is probably more appropriate, but there’s usually not much in the way of object-oriented functionality, so you’re stuck with a bunch of “gotchas” and having to come up with twisted ways to get what you want.

      Object oriented languages are great in that you can determine all the possible data types, write some generic code, and never worry about how someone wants to use your methods. The problem is that the child has to learn the syntax of your methods in addition to whatever OO language you’re using.

      How to get rid of the syntax confusion? Flowchart modules! What I’d really like to see one of these systems do is show the kids the generic code generated by their flowcharts. Then, they can learn how to code piecemeal as they peel back the layers of abstraction.

      Unfortunately, I don’t know if this particular software would help kids out too much since the main “gotcha” here is the terrible labels for the values coming from the sensors.

      A really nice thing would be a system where strings are stored in memory on the device and sent to the software upon plugging in. You could even rename the labels, or change them back to default if you get confused. This is a real-world problem too with MIDI devices and PC video game controllers… but I digress.

      1. Scratch does have a paramater to show the programatic structure of the script, although it’s a hidden option. If you hold down SHIFT while opening any of the pulldown menus, there’s some more advanced features available. One is Write Project Summary.

        This basic sprite collision game:

        generates psuedo-code like this:

        when I receive “GameStart”
        go to x: -200 y: (pick random -200 to 200)
        change “color” effect by (pick random 0 to 75)
        wait ((Fish Eaten) + (pick random 0 to 2)) secs
        point in direction 90
        move 2 steps
        turn (pick random -20 to 20) degrees
        if on edge, bounce
        if (touching color c[000063]?)
        broadcast “got-me”
        go to x: -200 y: (pick random -200 to 50)
        wait ((Fish Eaten) + 1) secs
        change “color” effect by (pick random 10 to 25)

    2. Yes, I find Flowcharts are harder to work with than actual code.

      You know what is far worse than flowcharts, though? Class diagrams, procedure diagrams, and anything involving UML. That stuff is pure evil.

      1. Glad I’m not the only one who feels that way (about flowcharts and UML).

        Anyway, any teaching tool that may generate interest in programming in kids is a good thing in my book.

  1. it depends on what you mean by code. when you start dealing with large scale applications, code is kind of irrelevant. most functionality ends up getting black boxed with a clear interface. what it does behind that interface could be anything, in any language. but the block elements must fit together a certain way.

    now if you’re talking about setting up registers on a microprocessor, or doing physics, kinematics, image processing, or just blinky lights, then yes i’d much prefer code of a diagram. that amount of code fits into one block on a diagram, generally. obviously you can zoom in and have diagrams at any level.

  2. As I understand it Scratch was intended as transitional to text programming. While it has visual blocks, it reads/scans like c/java.
    It is object oriented with scripts attached to actors (sprites) and backgrounds with message passing.

    I agree about the sensor board interface, it was intended only for a specific board. There is a more modern interface called remote sensors, but it requires a network proxy. I wanted something that was plug and play.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.