I’ve had my Pi now for just under 6 months, however for half of that it was in Carlisle while I was in Oxford, and for the two months after that I was too busy to do anything with it; as this was a typical student summer for me: sorting the stuff I’d brought back to Carlisle; packing to back to Derby; and upgrading, fixing and building PCs for family and friends. All that normally keeps me busy enough, but a new addition for this summer was my part-time work at the Pinegrove Hotel, so what little time I had remaining was used to recuperate from all the aforementioned.
Now I’m back in Derby and have my Pi with me, I’ve finally got around to using it properly. My Dissertation piece is going to be based around a robot controllable from the web, but for assembly by an end user with no knowledge of programming or electronics, while still being customisable (i.e. not locking them to a specific form or set of tasks).
This idea was kindled when I stumbled across the Kickstarter for Dexter Industries’ Brick Pi. At that time, I didn’t have a Pi, had barely stepped into the world of Linux, and had only used an official LEGO Mindstorms kit during a University module where I made it play football with an IR Ball using the HiTechnic IR Seeker Sensor programmed in Robot C. Naturally, I thought it a good idea as it would get me more Linux experience and get me back into a project seeped in the style of programming and building I enjoyed back in my Systems and Control A-Level. However at the time of the kickstarter I didn’t have much money, and I needed to talk it over with university staff before I committed to this, as the last thing I wanted to do was spend over £300 on parts and then find out what i wanted to do wasn’t suitable for a final year project.
After talking it over with staff, and getting David Evans to be my supervising tutor, I was set and purchased the BrickPi starter bundle in April. The bundle included: a Raspberry Pi Model B Rev 2.0, the BrickPi Expansion Board, WiFi dongle, an SD card with the Dexter Industries modified Raspbian Wheezy image ready to use, and a battery pack for 8x AA batteries with wire for attaching it to the BrickPi Board.
Fast forward to mid-September and I’m back in derby getting ready for the final year of my degree and now have the time to experiment.
This is what i have at present.
The Robot is based on the Dexter Industires WiFi car poject as a chassis, but with an extra touch sensor as well as a mount of the Raspberry Pi camera and another sensor, and a frame to hold the battery pack.
The current version is not without problems. The most noticeable is due to the weight added by the battery pack.
The battery pack is heavy enough that it’s pushing down on the caster and forcing it onto the ground. I’ll have to redesign this part of the robot, it’s not like I’m lacking the parts, but my concern is still going to be weight. If all else fails I might have to stump up for one of the new Ball Caster parts found in some recent sets as that should take the weight nicely.
The Brick Pi itself seems to still have some teething troubles, especially with the colour sensor that comes with the Mindstorms NXT 2.0 set. I bought a 2.0 set from ebay thinking that the colour sensor would be better than the light sensor (having done quite a few tests with it two years ago during the IR football project) but I couldn’t get my sensor to work with the test programs on the Pi or the NXT brick. Thus I decided to buy a new one, and it arrived today.
Yes, that’s how it came. In a comparatively huge box with a few of those air pillows. It borders on the ridiculous.
Anyway, with replacement sensor in hand I tried to get it to work, with the same (lack of) results. I decided to load up the NXT software on my PC and actually make a program that used it, in case the test programs were faulty. My error soon became apparent. What i had been doing on the NXT brick was trying to test it with the Light Sensor’s test, the colour sensor didn’t have one; but it did have an entry in the Data Log section of the NXT brick which I didn’t notice as I was going to the light sensor and tried that, not realising that it wasn’t an update to the light sensor, but a different sensor altogether.
Having now found out I’d used £25 unnecessarily, and now had two fully operational colour sensors, I was now faced with a BrickPi that didn’t play ball, so I hit the forums. The result was surprising as I wasn’t the only one with this problem. The issue on the Pi was that the sensor wasn’t lighting it’s lamp (which it uses to reflect light of the item it’s sensing the colour of), and thus wasn’t getting any reading back but Black. However Dexter Industries can’t replicate this themselves, which is annoying as they can’t debug it until then. There’s a jury-rigging solution at the moment where you define a spare port which physically has no sensor attached to it as having a colour sensor. This lights the lamp and returns intelligible results on the sensor port that actually has the sensor attached. It’s not ideal as I essentially lose a port, but it’ll do for the mean time while D.I. is trying to reproduce it. I do however have a theory: there may have been a batch of BrickPi boards that weren’t flashed properly, and thus have an error on the Arduinos at the heart of the board. I may even try and get my hands on an AVR programmer and try flashing it myself.
That’s all for now, as I’ve now got to go away and redesign the rear caster and generally improve the design. The next version should include a bumper of some sort as that’s what the touch sensor is doing at the front.