Everyone loves a radio controlled car and a quick look in the toy cupboard of any household will normally reveal at least one and most probably more in various states of disrepair – you can also guarantee that the batteries will be flat, if they are there at all.
We thought it would be interesting to resurrect some of our old cars and give them another lease of life by hacking the controller so it could be connected up to the raspberry pi and controlled from it. We called our creations pi-cars.
We’ve had fun using our pi’s to play around with the cars in this way and also found that my two young boys enjoyed it as an introduction to programming with Scratch. We would now love to know if you have any ideas about what you would do with a pi-car
and have five to give away for free for those who submit the best ideas on what you would do with one – just click here and fill out a simple form. and you can now buy them from our Embark ideas website by clicking here.
So what have we done?
We took apart the controllers from a number of old and new radio controlled cars and added a bit of buffering electronics to access the functions of the controller. We exposed these functions by adding a connector on the radio controller unit so it could be connected via a suitable cable to the GPIO pins on the pi. This meant that setting different pins on the pi exercised different functions on the car.
The Monster Truck hacked controller with connecting cable
Another of our hacked controllers this time with a PS2 connector
A radio controller connected to the Pi
We were able to test this was working with a little python script that exercised the pins
How to test firing the pins through Python to check it works. Sorry about the change of orientation half way through!
However, we really wanted to be able to control the car from Scratch so my 5 and 6 year old boys could use it as they liked Scratch when they had played around with it after we received our pi. We wanted to see if they would find it more interesting using Scratch to actually move something – something which they thought was pretty cool anyway – rather than just moving something virtual on the screen or light up an LED.
So to do this we needed a script that would run on the pi listening for Scratch sensing commands and sending them to the GPIO pins. Luckily ‘SimpleSi’ http://cymplecy.wordpress.com/2012/08/26/scratch-controlling-the-gpio-on-a-raspberrypi/ had already created one which we used initially. This did seem to work pretty well but had a problem with one of the cars so we ended up writing our own similar handler. This also suffered the same problem so SimpleSi’s script was obviously not the problem but the mod we made to one of the particular controllers – one to put onto the bug list for later!
Regardless, we now had a script that was able to receive commands from Scratch and pass them onto the GPIO pins. (If anyone is not aware of netcat it is really useful for testing things like this – I used it to simulate Scratch which meant I could complete and test it all from the command line.)
In Scratch it was then simply a question of enabling remote sensing and creating variables with the exact names that the handler script was expecting. In turn the script would receive these commands and then turn on and off the GPIO pins. Setting these different variables to 1 and then 0 could be put within all the other Scratch control and other commands available in the drag and drop interface.
How to use Scratch to connect to the Python handler script and onto the Pi. Sorry (again) I missed off the bottom of Scratch at the start. To enable remote sensing just right click on the block second from the bottom in the sensing section and click ok.
So there you have it we were now able to control our radio controlled car through Scratch. Next was to introduce this to my clients – my 5 and 6 year old sons. At this point I feel it my duty to provide a word of warning for anyone else attempting this sort of thing for the first time with children so young who obviously have little experience. We have jointly over 25 years experience in dealing with what we thought tough clients in the technology sector and sometimes have had to explain if things are not working correctly. However, none of these clients are as tough as small children. If it doesn’t work they don’t hold back and are brutal in their expressing their thoughts and losing interest, so make sure you do not skimp on preparation and testing beforehand. Perhaps with people who are a bit older or have a bit more experience there is value in working through problems – as all engineers have to do this eventually – but there is a real risk of putting people off if things do not work well enough to the extent where there is lots of waiting around – it is difficult enough without that. I’m sure lots of people have already experienced this and worked through it but thought it worth pointing out anyway.
What did we do with it?
Interestingly (but unsurprisingly) when using the pi-cars with the boys a common theme emerged; the things I thought would be fun were not deemed ‘fun’ and the things I did not think would be fun, or had not thought of, were declared ‘fun’.
This was probably concentrated by a number of false starts where lack of preparation meant things did not work for a variety of different reasons – batteries dead, hacked controller not working properly, pi full up of other garbage I was messing around with causing it to not work etc etc… Anyhow after yet another false start I gave myself a talking to and actually followed the engineering principles used to good effect in my professional life to ensure that I was finally properly prepared for a good session.
Cracking the code
As noted to move the pi-cars around in scratch we needed to create variables and then set them to ’1′ to activate the GPIO pin and make the car move forwards or back or the wheels turn left or right. These variables were named ‘gpio-output0′, ‘gpio-output1′ etc…
I had considered naming them ‘forwards’, ‘backwards’ etc but was glad I did not in the end as working out the code for which one was which was definitely declared a ‘fun’ activity. They enjoyed working out the code and writing down in their notepads (lab-books ) which name was which direction.
Here are the results of the code breaking that we did earlier and a bit of an explanation as to what we did with them
So on a roll and with an unexpected bit of success I suggested that in Scratch we set up a program to listen for arrow key presses and use the codes they had worked out to move the car forwards on the up arrow, back on the down arrow… you get the idea. There was ‘almost fun’ had in setting it up and although they put on a brave face after seeing what they had created they did point out they could actually control it better with the actual controller rather than pressing the keys so struggled a bit to see the point.
However, luckily during some of the many pauses for problems earlier on they had been enjoying playing around with the cars and discovered they could make them skid around on our fairly shiny flooring. They were able to make it skid a couple of times but not consistently as the action to do it was quite difficult involving moving the controller quickly forwards, backwards, left and then forwards again to get the best skid motion – a use for controlling the car through the pi had been unearthed! The skid motion could be modelled and the actions put into Scratch to make the car do the perfect skid time and again.
This activity was declared ‘definite fun’ and kept attention for a long period of time as we perfected the skid program. The program we created needed them to complete the following:
- Consider the action they used to create the skid with the controller and break it down into smaller sections – go forwards, wait, quickly go back, turn left, then forwards again etc
- Implement the actions in Scratch
- Run the program and see if it worked
- Work out what was wrong and modify wait times or add actions
- Rerun the program until happy
The steps above are common to most engineering projects of requirements analysis, implementation, testing and reworking and I was surprised how long this activity held their interest. It seemed that having a radio controlled car that moved around physically definitely held their interest for longer than just moving round something virtual on the screen and I suspect they learnt more because of it and will have a better chance of remembering it.
Here is the video of us actually making the car do a skid after many attempts and adjustments. It’s not much but did teach them how to break it down something into smaller steps and kept them interested for a long period of time. They worked out what steps they should do to make it skid round the corner and then programmed that into Scratch with little help. This video was actually a re-run for the cameras unfortunately we didn’t capture the best one.
We would now like to know how you get on with it. We have five to give away for free for the best five ideas on what you would do with a pi-car. There are no rules on what you can and cannot suggest, it does not have to be for a particular age group or even for education purposes – although this is where we think it will be most useful. Just work out what you would do and fill out this simple form.
So why have we done it? (potential boredom warning)
There are a number of reasons why we started this project from simply identifying something to do with our pi to more lofty educational ambitions involving how people gain inspiration from learning about technology.
We grew up with a BBC computer in school and can fully understand how this inspired a generation of children to learn about coding and become excellent computer science engineers. However, we do have a slightly different take on it. Whilst the BBC computer did catch the imagination of some children, I think the ones it enticed were those who were ‘born to program’ – lets call them ‘the 1%’ (even though it is probably more like 0.1%). We all know who these guys and girls are. They are essential, the ones who have a natural affinity with technology and who often stand out a country mile due to the pace and accuracy of their work. They have reached a guru like state, although would never claim to be a ‘guru’ as they truly understand the complication and beauty of some of the technology we use. We think these people will love the pi and do some truly great stuff with it – probably without much help beyond an initial nudge. The raspberry pi device itself with its cheapness and subsequent ubiquity should hopefully ensure that many of the 1% are enticed. Without the pi many of these people may not have had the chance of coming into contact with technology until it was too late.
So yes the 1% are essential and the raspberry pi should be a massive benefit to them but they cannot do everything on their own. Others are needed aside from them (at least I hope they are as I am definitely not in the 1% gang). In fact we think ‘The Others’ are also essential on technology projects and the general prosperity of the world for the different skills and views that they bring to the table. Logically for The Others to be involved they too have to be enticed into committing to technology and the earlier the better. Perhaps some of The Others would actually become the 1% if they are enticed early enough.
Moving back to the BBC computer, whilst it was great, the time spent trying to get lines of code to work and constantly failing with syntax errors meant that many of ‘The Others’ were turned away. This is also evident in some of the very early videos of putting raspberry pi’s into classrooms – ‘it was good but very annoying when I could not get it to work’. Aha, the purists may retort, people have to learn, computer science is hard, some people are just not up to it, if they can’t even do that they shouldn’t be allowed to program. We agree that yes computer science and programming is hard, there will be times when incredible persistence will be needed to solve problems and you feel like Sisyphus http://en.wikipedia.org/wiki/Sisyphus but to get to a level where you are willing to put the effort in, you have to see be able to see the potential of what you can do. For some, syntax errors are not going to provide the potential view of beauty and will not cut it.
Quick disclaimer here we are not trying to say that raspberry pi foundation or anyone else in particular is trying to only cater for The 1%, we just think there is a risk that they could be the only ones catered for and The Others may be missed.
So enough of the drivel, in short we like the pi-car as we think it may be able to play a part in enticing people – who may not have otherwise done so – to get interested in technology and start programming, learning by accident and then commit to learning more. Even if not at least they will still have had fun playing around with a pi-car because everyone loves a radio controlled car.