Showing posts with label development. Show all posts
Showing posts with label development. Show all posts
Wednesday, February 4, 2015
Robot Club - fourth session completed
Link to Preparing post details in the parts in the kits.: http://winkleink.blogspot.co.uk/2014/11/preparing-for-2015-after-school.html
Link to First session; http://winkleink.blogspot.co.uk/2015/01/robot-club-first-session-completed.html
Note; I did not post for the second session. There is a short summary in the Third Session post.
Link to Third session: http://winkleink.blogspot.co.uk/2015/01/robot-club-third-session-completed.html
This week we nearly had a full house.
Only 1 child missing due to illness.
The 4 who attended the previous week remember a lot of their work and code so were getting stuck into getting their robots to go around a corner.
I had a bit more fun getting drivers on enough school PCs to permit the Arduino Nano to be seen. It needs custom USB/Serial drivers that are not included by default.
The teacher who is ICT coordinator came in to see the session in full swing with robots spinning, or moving along the floor. With coding going on and due to plus and minus lines on the batteries being shorted a nice little display of black smoke and the lovely smell of burnt plastic.
No real harm done just a jumper wires plastic sleeving was melted.
I congratulated the child on making smoke as it's something we all do when we work with electronics. They were kind of shocked.
It was great that the teacher had the same attitude so no harm done and no concern about burning down the school.
I tested their robot kit and Arduino. Nothing damaged, amazingly so did a little bit of rewiring and handed them back their robot to get working on again.
On of the kids who was in the previous session had a problem where their robot was pulling to the left. These are small cheap kits so the motors aren't tuned and the wheels are small and have grip meaning they catch on the carpet. Meaning they cannot reliably go straight.
We tried to fix it by turning the wheels in or our to change the resistance but no go so introduced that child to analogWrite.
A value of 235 seemed to make it all work perfectly. They had a nice straight running robot.
Once again the kids were not that eager to leave as they were perfecting their code and making it better.
At the end one of the girls who was being collected wanted to show her mother what she had done so she gave a great demonstration of her robot. Holding down reset to stop it moving.
Set it up and let it go. She then explained the code she had made as well as giving details on some of the other parts we will be using.
Next week we will be using an input device. A small line following sensor. I will mark the edge of the room area with white paper providing a contrast with the blue flooring. The idea will be to detect the paper and make the robot turn.
This will be the first time the kids do inputs and will also require the introduction of the 'if' statement.
Looking forward to another productive session next Monday.
Tuesday, February 19, 2013
Raspberry Pi + GPIO + Scratch + Remote Control Car
At the beginning of 2013 I started a Code Club at my local primary school and the kids love making and playing the games. Due to the way the club is set up in the school there is expected to be a few classes after the official Code Club sessions are completed so I've been trying to come up with some ideas of things I could bring in to the class to show the kids that Scratch can do more than make a cat move around the screen.
Then on my regular trawl of the web I found this fantastic code http://cymplecy.wordpress.com/2012/08/26/scratch-controlling-the-gpio-on-a-raspberrypi/ for controlling the GPIO pins on the Raspberry Pi using Scratch.
With an old cheap remote control car in a drawer I had the makings of a fun project for me that (hopefully) will be of interest to the kids.
Having read that the Raspberry Pi GPIO pins are not protected, so one silly mistake on my part could cause the death of my Raspberry Pi I dusted off my old electronics knowledge and put together a small transistor based driver circuit for the 4 pins used.
I originally wired this up on a protoboard and it worked, except for when it failed. Did I mention the remote control car was cheap. Well, the aerial was just a bit of wire and with all the other wires I added to the circuit there was regular interference that caused the remote to activate the wrong signal making it unreliable. Knowing the circuit was good the logical thing to do was to put the circuit on a proper board. Rather than going all the way to etching my own circuit board I made it up on a stripboard
After a false start (details of things I almost did wrong) I got the 4 circuits soldered up and tested. Worked first time.
Not the prettiest soldering but after doing near no soldering for over 20 years I was happy with the result.
Now I the circuit soldered up and it worked. With a bit of coding in Scratch I could program the remote control car for a sequence of actions like
Forward 2 second
Left 0.5 seconds.
Reverse Right 2 seconds
As you'd expect from a simple remote control car the was no way to give very accurate instruction. The motor was either on or off, no variable speed or feedback. Even with these limitations it felt great when I clicked on the code in Scratch and car actually did what I expected it to do.
Then on my regular trawl of the web I found this fantastic code http://cymplecy.wordpress.com/2012/08/26/scratch-controlling-the-gpio-on-a-raspberrypi/ for controlling the GPIO pins on the Raspberry Pi using Scratch.
With an old cheap remote control car in a drawer I had the makings of a fun project for me that (hopefully) will be of interest to the kids.
Having read that the Raspberry Pi GPIO pins are not protected, so one silly mistake on my part could cause the death of my Raspberry Pi I dusted off my old electronics knowledge and put together a small transistor based driver circuit for the 4 pins used.
![]() |
| one circuit per pin |
I originally wired this up on a protoboard and it worked, except for when it failed. Did I mention the remote control car was cheap. Well, the aerial was just a bit of wire and with all the other wires I added to the circuit there was regular interference that caused the remote to activate the wrong signal making it unreliable. Knowing the circuit was good the logical thing to do was to put the circuit on a proper board. Rather than going all the way to etching my own circuit board I made it up on a stripboard
![]() |
| again, 1 circuit per pin. white blobs under resistors are cuts in the tracks |
After a false start (details of things I almost did wrong) I got the 4 circuits soldered up and tested. Worked first time.
Not the prettiest soldering but after doing near no soldering for over 20 years I was happy with the result.
Now I the circuit soldered up and it worked. With a bit of coding in Scratch I could program the remote control car for a sequence of actions like
Forward 2 second
Left 0.5 seconds.
Reverse Right 2 seconds
As you'd expect from a simple remote control car the was no way to give very accurate instruction. The motor was either on or off, no variable speed or feedback. Even with these limitations it felt great when I clicked on the code in Scratch and car actually did what I expected it to do.
![]() |
| the vehicle of my success!!! |
And finally he is a short video of the car in action.
This is why I love the Raspberry Pi and the fun of hacking. With a little bit of effort you can have a lot of fun. Now I have a remote control car that I can control with drag and drop commands in Scratch on a £30 computer.
Subscribe to:
Posts (Atom)






