CamJam EduKit 3 – part 2

First of all I’d like to thank you all for the positive responses to my first blog about the CamJam EduKit 3 – loads of you commented, retweeted and even offered some really helpful advice. Yesterday, Louise came around and we embarked on phase two of the robot build.

On Wednesday I hosted a Coding Evening in Twickenham and quite a few attendees brought along their robots. Richard Hayler brought his CamJam robot which was controlled by a bluetooth keyboard – what impressed me most is that Richard had written his code and then set up the pi so that it automatically started running on boot up. I was also very impressed with the Crumble Bot kit that Nic Hughes brought along, controlled by an interface based on Scratch so very easy to use – I’d be interested in trying one out for myself as it looked like a great introduction to robot building for children.

The first thing I wanted to do was to make my code run on start up, so I quickly checked the code I’d written last weekend to make the bot move forward, turn left and right and backwards. I’d been sent a blog post from Raspberry Pi Spy, as I’d been warned by Alex Eames from RasPi.Tv that auto booting on Jessie could be a little complicated. I was rather proud of myself for figuring out that because my python file was in a folder called EduKitRobotics, I needed to include that in the code I was typing in, meaning that instead of the website of example of /home/pi/myscript.py, I needed to use /home/pi/EduKitRobotics/4-driving.py, however, what I failed to do was to use capital letters for any of the commands in square brackets in the config file. I also made one massive mistake in the terminal code that I was typing in meaning that nothing worked.

You can imagine the fear when I saw the words ‘dead’ in the instructions, but luckily it was Alex to the rescue as he spotted that I’d made a typo in the ‘ExecStart’ command – my python filename was missed off – I’d obviously been in such a hurry to get it typed that instead of typing:

/EduKitRobotics/4-driving.py

I’d just written

EduKitRobotics.py

A simple, but silly error, which caused my code to fail. The next attempt to run everything, with the capital letters all in place and the correct file information typed up, we were ready to test whether our code launched on start up.

We were quite excited when, after quite a wait, our robot set off wobbling across the carpet, as seen here, however, we couldn’t help but notice that the wheels were starting to come off the side of the box. Fortunately, it was Stuart to the rescue as he found a piece of wood, cut it to size and stuck it to the bottom to support the motors!

My next task was to attempt the code for following a line – at this point, I decided it was safest to just use the 4-driving.py saved code for all of my future work to save having to redo my boot up code, so I carefully copied and pasted the original code into a new file and began work on the next bit of Python.

I should probably point out that I got a fair bit of stick last week from both Stuart and Louise for the awkward position I was sat in to type my code and so this week I borrowed a monitor so that I could be a bit more comfortable. I also decided that to input my code I’d use my Pi 3 because it had enough USB slots to have a mouse and keyboard attached, and then I could simply pull out the memory card and put it in the A+ when we wanted to use it in the robot. This also meant that our cables could be permanently attached to the pi, without worrying about maneuvering them to attach the pi to a monitor (yes I still need to figure out how to VNC into the pi). So, with the line following code ready to go, we put our robot back onto the floor, plugged in the trusty Anker power supply and set it off. We were hugely disappointed when nothing happened, until I realised that the diagram for wiring the line sensor showed the sensor facing up, whereas we had installed it facing down and therefore the cables were the wrong way around!

With a slight fear that we’d damaged the sensors by having it back to front, we switched the cables and ran the code again – this time it worked, but we had a slight issue with the robot going backwards and so I had to go and tweak a tiny bit of code to get it sorted and then we were able to watch excitedly as our robot wiggled it’s way along a line. We did have one further problem, the bit of wood we’d added to help support the wheels had made our robot a little heavier and that meant it couldn’t manage to move on the big, fluffy carpet in the living room so we had to relocate to the tiled kitchen, with its black, granite tiles. Not an ideal location for testing for black lines, but as long as we kept the robot on bits of paper, it worked ok!

Our final bit of Python was the code to get the front sensors working so that our robot could detect distance. Using a bit of careful cutting and pasting from the previous code I had typed up, I was able to get the robot moving fairly quickly – you can see it bouncing around the kitchen here. I should note at this point that it took quite a long time from plugging in the battery to the code actually starting to run and we were often close to giving up when it started to run. I’d estimate it was between 30-60 seconds from battery in to code running, which can be a long time when you’re worried that it doesn’t work!

The next step of our build involved Louise spending a lot of time with spray paint and an entire tube of super glue to decorate the robot!

One slight issue with all the decoration is that it made the robot quite heavy, as you can see here, but it was so funny that we didn’t really mind!

Perhaps jealous of our achievement, Stuart got out his remote controlled car, and then started looking suspiciously at the sensors and muttering that he could attach them to the car and automate it… we decided it was safest to hide our robot from his tinkering hands, but watch this space to see if he does end up using a CamJam Kit with his car.

So, as you can see, we had a fantastic couple of days building our robots – considering neither of us is particularly techy, we were pleased with our achievements both in terms of the building and the coding. I still don’t think this is a class activity, but definitely one to do with a small group of enthusiastc children as it was so much fun.