In term 2 we were tasked to build a “minime” for 3.007, which was a small vehicle powered by a rechargeable battery pack and controlled by an Arduino.
Largely to teach us fabrication methods, we spent the week using Solidworks to CAD the minime and then sawing and bending acrylic to make the chassis. We then connected a bunch of wires to a breadboard and attached the servo motors and we had our very own robotics car controlled by a photoresistor (turn left if light, turn right if no light etc.)
And then in term 3, we had the AmigoBot for use in Digital World, where we experimented with Signals and Systems and used algorithms to turn sensor input into movement output.
But the AmigoBot was not ideal for a number of reasons:
- They spoilt easily, despite having a polycarbonate shell etc. This also included the port for the wire, which somehow had really bad connectivity.
- It was heavy, which meant that it spoilt easier. This also meant that algorithms were inherently significantly off due to a lack of ability to account for inertia.
- They were not repairable in house, so we always had to get someone to repair them.
- They cost roughly $3000.
And so the miniamigobot was born – why pay $3000 for something you can pay a little more and get each student to make? While it is an added long term cost for the school to keep buying parts and giving them to students, I believe that the learning opportunity from a project like this can be well worth it.
All we needed was two sonars, two servo motors to swivel those sonars around, and voila we’ll be done… or so we thought. After some research and collection of scrap electronics lying around we realized a few things:
- Sonars come in many shapes and sizes. And costs.
- Getting accurate feedback from each wheel is not going to be easy – there are two ways to do this, with a stepper motor or with a dc motor that comes with an encoder.
- But using a dc motor would require a different arduino, more specifically, a dfrduino romeo.
- Getting python (the DigiWorld course is run in python) to talk to the Arduino over serial might not be as easy as we thought.
And so this led to the new to do list:
- Test different sonars on different surfaces and angles to find the most cost effective solution (we’re all about $$ here)
- Test various feedback mechanisms
- Research on (dc controller + arduino) vs (dfrduino romeo) vs (servo motor + hacked on feedback mechanism)
- Get python and arduino to talk to each other, prove that AngleProp and DelayProp both work.