After-school Robot Primary Club

It would be nice if these additions appeared as native blocks in scratch

Because the RPi is unique, then GPIO i/o blocks are not going to appear in mainline Scratch.

It is possible to make a special RPi vesion (the pi-face people have done that I believe) but then you are into supporting your own version of Scratch and you can't load/save projects to the Scratch website and it would be confusing for the younger customer

However, once 2.0 comes out AND assuming their is goign to be a standalone version AND it works on the RPi then we can make our own blocks up and we are off to the races that way

Simon

Schoolboy error today - went to show them Scratch on the netbooks - it wasn't installed!!
(I blame the IT Tech - i.e ME!)

So that slowed us down a bit as we had to install it quickly by hand but we did a quick run through of Scratch (moving the cat across the screen) and them moved on to showing it on the RPi

Did a quick Pin11on pin11off loop test and then we connected the RPi up to one of the Robot breadboards with a ULN2003 buffer on it and swittched the motors on and off.

Showed them the £4 IR Line sensors but didn't have time to wire show them working.

Then we were out of time

So next week, its show them that VNCing is the same as connected a screen/kbd to the RPi and then we will DEFINTELY get the Robots rolling under their instructions.

One thing I need to sort out though is some sort of master ALLOFF command as we ended up with the motors running and they didn't stop until the RPi closed down.

Simon

Sorry to be copying your plans but I was thinking of trying the IR line following sensors. Am I correct in thinking each unit just senses black or white and hence gives either a hi or lo signal?

Also just trying to work out how to hook up an ultrasound distance sensor to the pi. I have a really cheap sensor (about £1.50 from ebay) which should be possible to connect and then add to the scratch handler!

The idea IS to copy (and improve them )

The IR sensors are just on or off as I have no mechanism for reading analog sigs yet. PRobably going to need an array of 3 or 4 to provide enough info to make reasonable desicisions.

The ultrasound modules give very short pulses (1 metre distance = 3.3ms duration) - you can can them to work fine on arduino but not had success yet on an RPi.
(check out http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=18291&start=25 )

Did think about using a Shrimp (http://shrimping.it/blog/ as a front end processor and stretching the pulse (by say a factor of 50) but haven't had time to try it

Simon

Just wired up my HC-SR04 (the cheapest ebay distance sensor i could find) and with a few lines of python I have a reasonable distance measurement!

It keeps giving random values every now and again but it does this with the ardiuno as well.

Now i need to work out how to incorporate it into the scratch handler so I can have distance variable to play with.

[url]Just wired up my HC-SR04 (the cheapest ebay distance sensor i could find) and with a few lines of python I have a reasonable distance measurement![/url]

Can you post your code please?

And how you wired up your SR04 (pwr/level-shifter?)

Simon

So the HC-SR04 is digital. I have the VCC connected to the 5V power from the pi. GND to GND. The trigger pin to a GPIO output and then echo pin connected to an input via a 300ohm resister and a 3.3V zenner diode (thanks Gordon!).

The Python code is crude but simple. I turn the trigger pin on very briefly (supposed to be 10uS). Then wait until the echo pin comes on I then time how long the pin remains on. The distance is the time of that echo signal in microseconds divided by 58. I appreciate the timing in python isn't going to be perfect but the results are pretty good. As I say I just need to add it to the scratch handler in a neat way!

Code: Select all

import time
import RPi.GPIO as GPIO
import datetime as dt
GPIO.setmode(GPIO.BOARD)
GPIO.setup(12, GPIO.OUT)
GPIO.setup(11, GPIO.IN)
GPIO.output(12, False)
while True:
   time.sleep(2)
   GPIO.output(12, True)
   time.sleep(0.00001)
   GPIO.output(12, False)
   while GPIO.input(11)==False:
      a=1
   t1=dt.datetime.now()
   while GPIO.input(11):
      a=1
   t2=dt.datetime.now()
   t3=(t2-t1).microseconds
   distance=t3/58
   print'Distance:',distance,'cm'

The a=1 bits are just to do something in the while loop waiting for the pin to change (there must be a neater way!)

As I say I just need to add it to the scratch handler in a neat way!

If I can get it work for me - you can be sure that I'll be adding it in (like the special motor function)

But if you don't want to wait - please have a go - I suggest not using Pins 11 or 12 as they have the motor PWM functions on them

Simon

Yippee - got it working as well
I used 2x 330ohm resistors to form a simple voltage divider to feed pin 11 as don't have any zeners on hand but I'll be down tesco's tomorrow

Off to see about incorporating it into the handler
Going to stick in on Pin 13 for this
Simon

Excellent, I'll leave it up to you to add it to the handler then! It is actually surprisingly easy to set up.

I assume we could have more than one feeding into the GPIO but then only use one pin for the trigger signal.

If things get any more complex you will probably need a GUI for the handler to make it customisable (?is that a word?)

Quick bit of code for you to paste in so you can see the fruits of your labour

I think I'll modify it and steal pin 23 as the trigger output and allow any of the current input pins 22,7,8,10,24,26,19 be used as echo receivers (I've seen one 'bot design with 1 sensor on front and 1 each side (for maze navigating) and I can easily see need for 1 at back as well)

But we could end up needing a configuration setting - might be best to do that via a simple .txt file to start with

This is going to be so "cool" for the kids to play with

Code: Select all

import datetime as dt
....
    def run(self):
        last_bit_pattern=0L
        for i in range(PINS):
            #print 'i %d' % i
            #print 'GPIO PIN %d' % GPIO_PIN_INPUT[i]
            if (PIN_USE[i] == 0):
                last_bit_pattern += GPIO.input(PIN_NUM[i]) << i
            #else:
                #last_bit_pattern += 1 << i
            #print 'lbp %s' % bin(last_bit_pattern)

        last_bit_pattern = last_bit_pattern ^ -1
        sensor_name = "sonar1"
        bcast_str = 'sensor-update "%s" %d' % (sensor_name, 999)
        print 'sending: %s' % bcast_str
        self.send_scratch_command(bcast_str)
       
        while not self.stopped():
            time.sleep(1.1) # be kind to cpu - not certain why :)
            pin_bit_pattern = 0L
            for i in range(PINS):
                if (PIN_USE[i] == 0):
                    #print 'pin' , PIN_NUM[i]
                    pin_bit_pattern += GPIO.input(PIN_NUM[i]) << i
                #else:
                    #pin_bit_pattern += 1 << i
            #print bin(pin_bit_pattern)
            # if there is a change in the input pins
            changed_pins = pin_bit_pattern ^ last_bit_pattern
            #print "changed pins" , bin(changed_pins)
            if changed_pins:
                #print 'pin bit pattern %d' % pin_bit_pattern

                try:
                    self.broadcast_changed_pins(changed_pins, pin_bit_pattern)
                except Exception as e:
                    print e
                    break

            last_bit_pattern = pin_bit_pattern
            GPIO.output(12, True)
            time.sleep(0.00001)
            GPIO.output(12, False)
            while GPIO.input(7)==False:
              a=1
            t1=dt.datetime.now()
            while GPIO.input(7):
              a=1
            t2=dt.datetime.now()
            t3=(t2-t1).microseconds
            distance=t3/58
            #print'Distance:',distance,'cm'
            sensor_name = "sonar1"
            bcast_str = 'sensor-update "%s" %d' % (sensor_name, distance)
            print 'sending: %s' % bcast_str
            self.send_scratch_command(bcast_str)


Ok time for bed said Zebedee

But current code listens for a broadcast called "sonar" - if it receives it - it pulses Pin23 and its up to the Scratch programmer which pin they read the distance value from - so if echo output is connected to Pin19 - then the Scratch user just needs to monitor pin19 sensor value

Simon

Ok - I can see we are going to need some sort of timeout code so that the handler doesn't stick inside either of these while loops - going to see if this works out

Code: Select all

                    t0=dt.datetime.now()
                    t1=t0
                    while ((GPIO.input(19)==False) and ((t1-t0).microseconds < 10000)):
                        t1=dt.datetime.now()
                    t1=dt.datetime.now()
                    t2=t1
                    while ((GPIO.input(19)==True) and ((t2-t1).microseconds < 10000)):
                        t2=dt.datetime.now()
                    t2=dt.datetime.now()
                    t3=(t2-t1).microseconds
                    distance=t3/58
                    if distance < 500:
                        #print'Distance:',distance,'cm'
                        sensor_name = "pin19"
                        bcast_str = 'sensor-update "%s" %d' % (sensor_name, distance)
                        #print 'sending: %s' % bcast_str
                        self.send_scratch_command(bcast_str)           



I saw your post this morning and the code you haveincluded makes sense.

Did you actually have problems with it getting stuck in the while loops or was it just keep the code fool proof?

If I have followed your code correctly the timeout you have set of 10000 microseconds will mean that you can measure only up to 10000/58=172cm then the loop will give up. In theory the sensor can give a measurment upto 500cm. With he echo signal being even longer (~38ms) if there is nothing in its path.

If your code works fine then ignore me; otherwise I think you need to wait abit longer. I havent done the timings myself but I clearing it must take longer for the echo signal to arrive when the distance is longer so potentially you would need to wait 38+abit milliseconds at each loop before totally giving up!

Something I just though, which probably isn't an issue, is the frequency of the trigger signal - is there a trigger signal only when there is a Scratch broadcast? If it forms part of a loop in your script you need to be sure that there is at least a 50ms gap between the triggers. I'm not really sure of the timings in scratch but I think it is probably unlikely that you could make a loop that would send a out a broadcast faster than 50ms but if that is possible then the handler would need something to prevent that happening.

I just did a quick guess based on my maximum distance (my sensor is pointing at a wall 1.32m away ) but I'll make sure the code doesn't affect the 5M range

I was getting locking up (I had it with your original code as well) - it can lock up if the pin your receiving on is not actually being used to receive the echo (Or you've wired up the wrong pin!)

I don't think the 50ms issue is going to be a real problem (I don't think Scratch together with the handler) is going to be able to loop faster than 20 times/sec) but I'll make sure

I have an Arduino after-school club tomorrow so I need to pre-pare for that tonight but I'll be back to this tomorrow evening

Smon

Had a great day out with a ScratchPiBot at Manchester RaspberryJam but not quite as sucessful back at the school this Monday
From my blog

Week4
Having successfully had a run out at Manchester Raspberry Jam, I thought it would be plain sailing but no I couldn't get a 2nd RaspberryPi to connect to the school WiFi so we had to make do with just the one (Which worked fine via VNC). The roboteers coded up 2 different methods of controlling the bot - Method 1 was to control both motor speeds using up/down arrow keys and then increasing one/decreasing the other using left/right keys to steer. Then they tried W/S for left motor Up/Down for right motor. Next time I aim for them to re-code up a control system and race against each other. We are both learning a lot

Although I cloned the SD card - I couldn't seem to get the second RPi to be visible over the school WiFi (I don't have much time to setup as I'm actually working fixing printers etc during the afternoon )

But we still made some progress and finally the kids got to write code and control the bot. One of them remarked on how slow Scratch seemed to be but was happy when I pointed out that we were VNCing into it and that the RPi is slower than the 2.8GHz dual-core Win7 machine being used as a dumb terminal

So I need to see make sure the VNC Settings are as fast as they can be- might reduce colour depth to see if that helps.

Also, the bot seemed to stop responding to Scratch commands but cured by exiting Scratch and relaunching my ScratchGPIO shortcut whick kills any running handler and launches a new one. I'll need to try and replicate this at home as and fix it as its a pain tin the neck

Simon

Setting color depth to 64 colours (I'm using UltraVNC as the viewer on my PC) seems to be a good compromise between display quality vs speed (Well - OK as a robot controller )

Simon

http://cymplecy.wordpress.com/2012/10/01/after-school-mini-bytes-club/
Couple of point to learn
1. Always have at least one spare extra SD with a working image on it as one of the cards got corrupted during testing at lunchtime and valuable time was used up taking a backup of the remaining working one and copying it back to the corrupted one.

2. If possible, have a complete RPi spare as well as I've at least blown the poly-fuses on one of the RPi

Other than that - it went OK and everyone was well into the Ultra-sonic range finder process and we all cheered when the bot stopped before hitting the wall all by itself.

I need to play with integrating the the IR sensors so we can try some line following

Simon

Praise the polyfuse design engineers

Its saved my bacon yet again - my "broken" RPi is back to life after leaving it alone for 24 hours

Simon

Glad the pi recovered!

Have you managed to fully incorporate the distance finder into the scratch handler? If so would be great to have a copy.

My next project is to get a cheap accelerometer working, have you had any success with the line followers i have three of them but havent quite managed to get them nicely calibrated yet!

Have you managed to fully incorporate the distance finder into the scratch handler? If so would be great to have a copy.

Just updated the code to add in the the published installer - I've hardcoded pin23 to do the pulsing but you can use any input pin (7,8,10,19,22,24,26) as the pulse receiver. Documentation in updated article
http://cymplecy.wordpress.com/2012/08/26/scratch-controlling-the-gpio-on-a-raspberrypi/comment-page-1/#comment-208

have you had any success with the line followers i have three of them but havent quite managed to get them nicely calibrated yet!

I've not tried them yet - plan was to do it today but as always - real life overtakes intentions

Simon

Well, at least I've got 3 working RPi and 4 ready-to-go imaged SD cards ready for tomorrow

How come there only seems to be about 2 days in each calendar week at the moment????

Simon

Week 6
http://cymplecy.wordpress.com/2012/11/12/week-6-in-scratchpibot-club/

I had one failure of VNC requiring re-boot on one 'bot.

Since we now had 2 'bots, I switched from using main class PC to 2 netbooks - the netbook screens (1024x600) were too small (certainly for my eyesight as least) for remote VNCing so I'm going to use a couple of the older laptops next time.

The IR Sensor was showing good promise (sitting on a bench not moving of course )

The next club isn't for 2 weeks so DEFINTELY going to get a pair of sensors wired up for next outting - promise

Simon

Week 7
http://cymplecy.wordpress.com/2012/11/26/week-7-in-scratchpibot-club/

The IR Sensors that worked fine on the boys robot are these ones http://www.ebay.co.uk/itm/120990563177

The girls' ones are these http://www.dfrobot.com/wiki/index.php/Line_Tracking_Sensor_for_Arduino_(SKU:SEN0017)
They may be alright and just need their height adjusting - at the moment they are mounted on wooden dowels but if I can get some long 3mm bolts then I could make them adjustable as they just need to be closer or further away from the track.

I've had some M3 machine screws in 30mm and 40mm lengths from: http://www.modelfixings.co.uk/ who are fine for small orders (I needed them that long to build a bridge for a headless electric guitar - yet another unfinished project.)

Blutak might just do the job too. Maybe they just need lifting up a bit, as they're a different type of sensor. They look like they have lenses on them?

Looking good. I like the idea of the roll-up racetrack