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.

IMG_8477IMG_8478

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.Screen Shot 2016-03-27 at 17.59.37.png

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). IMG_9929So, 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.

Advertisements

CamJam EduKit 3 – Part 1

This weekend I decided it was time to try out the rather exciting CamJam EduKit 3 – Robotics

Screen Shot 2016-03-20 at 18.09.54

I admit that I’ve been avoiding having a go because I was terrified of everything going wrong, so this weekend I called my friend and we embarked on our first robot building exercise.

So…in the kit are all the parts you need to build a robot – once again, it looks very complex and scary, but it’s not that difficult once you get going. My friend and I decided to use the box as our chassis, as suggested in the instructions available here.

IMG_6807-1.jpeg

The first thing we needed to do (after setting up Python and running Hello World) was to attach the motors. We realised straight away that we need to put some holes into our box so that we could feed the cables through and so, being girlie girls, we got the drill out of the cupboard and started making holes in the case. It was at this point that I realised that this may not be a project for the primary school classroom, unless you want to pre-punch the holes or have children waving drills around…although, a strong leather punch may be a better option.

So, using the diagram below from the worksheet, we stuck our bits on with the provided double sided tape…and quickly realised that this led to a stunted angular robot because the front wheel was so much lower than the back one so we had to start again and rethink our motor position.

Screen Shot 2016-03-22 at 10.07.49Screen Shot 2016-03-22 at 10.23.12

After a bit more time with the drill, we’d repositioned the wheel motors on the side of the bot and carefully carved out some extra holes to fit the line sensor and ultrasonic sensor (Louise wanted to make sure it looked pretty).Take a look at the two pictures above and see if you can spot the difference between the photo and the diagram…at this point we were a little bit confused as the motors appear to be the other way around on the photo compared to the diagram and so we decided to follow the photo’s direction and worry about it later.

IMG_8407     IMG_8410

I put Louise in charge of following the wiring instructions, and as a complete novice, she found it fairly easy to put together following the sheet, we even learned how to tell the difference between the resistors by reading the bands (after a moment of panic about how we could tell which was which). The worksheets so far are really clear and easy to follow.

Screen Shot 2016-03-22 at 10.20.07

We hadn’t really done any coding yet, because we were so eager to get the build done, which meant that we didn’t really know if any of it worked!

IMG_3806IMG_4239-1IMG_3070IMG_4144-1

We had a bit of an issue when we started coding, because the instructions ask that you make sure you’re using the newest version of Raspbian and even tells you how to check, but in order for us to check we ended up running an update to the pi, and then installing a package from instructions I found online and THEN we could check whether we had Jessie or Wheezy (it turned out we had Wheezy installed so I had to find a memory card that already had Jessie).

So, I could finally start typing my code to check the motors were properly set up. The instructions talk you through the Python code, which requires no extra library installs, but did require a lot of typing lines and lines of code to set up which pins do what.

# CamJam EduKit 3 - Robotics
# Worksheet 3 - Motor Test Code
import RPi.GPIO as GPIO # Import the GPIO Library
import time # Import the Time library
# Set the GPIO modes
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
# Set the GPIO Pin mode
GPIO.setup(7, GPIO.OUT)
GPIO.setup(8, GPIO.OUT)
GPIO.setup(9, GPIO.OUT)
GPIO.setup(10, GPIO.OUT)
# Turn all motors off
GPIO.output(7, 0)
GPIO.output(8, 0)
GPIO.output(9, 0)
GPIO.output(10, 0)
# Turn the right motor forwards
GPIO.output(9, 0)
GPIO.output(10, 1)
# Turn the left motor forwards
GPIO.output(7, 0)
GPIO.output(8, 1)
# Wait for 1 second
time.sleep(1)
# Reset the GPIO pins (turns off motors too)
GPIO.cleanup()

I’m actually really pleased because I could follow this code quite easily so, while it was a bit boring to type, but I knew what I was doing. Now, do you remember when I mentioned earlier that we were a bit confused by which way around to put the motors. It turns out we should’ve put them the other way around because when we tested the code the wheels went backwards, but the instructions were very clear and so we were quickly able to make some alterations to make it go forwards – pins 9 and 10 controlled the right motor and so if turning on just pin 10 made it go backwards then turning on just pin 9 must make it go forwards. We changed pin 7 and 8 too and everything worked perfectly.

Check it out here.

Now, if you watch the video, you may notice the slightly awkward position of the Pi and the bot – I confess that I don’t know how to use a pi ‘headlessly’ i.e. without a monitor attached and so I currently have no way of getting it running without having it attached via HDMI to a monitor or screen – this is not an ideal set up so before we finish the build we need to find out how to VNC into the pi from my MacBook. I’m also really keen to try and figure out how to do this code in Scratch so hopefully when I write up part two I can let you know successes or failures for that.

So, conclusions from our experience so far. Firstly, this is not one to attempt with a class unless you are willing to either pre-make the bases, let them use a drill or try out a punch, but you could get children to bring their own base materials from home, making it clear that they would need to punch holes in it to run wiring through. I like that there is room to fail or be independent in your design – you can put your motors where you want and just hope that it works, but if it doesn’t, so what, you can just move them and try somewhere else. The build itself is dead easy, BUT the code is very long and tedious so it takes a while to type and even longer to debug. If you don’t know how to dial in, it’s also a problem so there are lots of specific skills needed. Saying that, my friend and I had an absolutely fantastic time on Saturday building our robot and I can’t wait to spend more time on it this weekend, so it is a great activity! I can honestly say that I haven’t had that much fun in ages; my friend Louise went home telling her flatmates about how amazing the Raspberry Pi is and how cool robot building is. I’m really excited about spending more time on the project and I think that this is a brilliant way to get people exciting about the things we can do once we know how to code. I can’t help but that once the code is re-written using Ben Nuttall’s GPIOZero (a simplified Python library, designed to make Python code even easier when using the GPIO pins) or with Scratch this will become more accessible to everyone, but for now it would take a brave person to get this out for a classroom activity.

Watch out for part two of this blog within the next week.

PS I LOVE ROBOTS AND I LOVE THIS KIT