At this moment I am working on the preparation of the installation “NomadicMILK, Cameroon version”.
I plan to combine the sand track, the video material we shot during our fieldwork in Cameroon, and all the audio that came with it, in a sound scape like installation. The track will tell its story by itself, at least that’s how I envision the installation now. Still three weeks to go to make an outstanding work, and bring the worlds of digital biennials and rural Cameroon together!
The robot has to accurately re-draw a pre-recorded GPS track, using its internal sensors. To tackle the navigation problem (briefly summarized as ‘WHERE AM I NOW’ and ‘WHERE DO I NEED TO GO’) the robot needs to be able to find its location and heading direction. The robot has no visual input, no beacons for triangulating, no micro-GPS for its own localization, so the robot has to rely on dead reckoning only.
On cloudy days in ancient times, sailors had to rely on compass, knotted robe (or chip log) and extrapolation for maintaining course. Normally the would have an additional absolute position measure too, namely the Sun, which could be measured using a sextant. Just as the sailors did on those days, our robot has to rely on a compass and on odometric sensors on the wheels (optical sensors counting wheel revolutions).
The reason for not having a system with beacons was the trade-off we had to make between a simple and reliable system, and the accuracy of resulting drawing. More components such as optical or RF-responder beacons, as being used in harbors or factory floors, would increase the accuracy of the robot’s positioning, but also increase the chance of failure. (more stuff means that more things can go wrong)
The worst ‘enemy’ of the robot’s accuracy is the amount of slip in the wheels. We use 4 motorized wheels, instead of the more common ‘2 motorized wheels + caster’ – configuration. This 4-wheel configuration has been chosen in order to be able to work on a rough surface. When doing a spot-turn, the 4-wheel configuration will always require some amount of slippage. This amount can be assumed fairly constant when driving on a flat surface. On a flat surface it is possible to draw a reasonable accurate drawing, provided that the amount of slippage is constant.
The drawings at the Graz exhibition were made this way. Especially because the drawn figure does a runaround, the accumulation of tiny rotation errors will show when the robot has to return at its starting point. The following plot shows the recorded GPS track
With accumulation of errors, caused by slippage, the figure quickly becomes unrecognizable. Especially after the Graz exhibition we were in doubt whether the taken approach (no aditional navigation beacons) was ever going to work. Simulation showed however that by adding a compass for correcting and compensating for angular slippage, could make the robot’s patterns more recognizable and accurate. The following figure shows a number of track runs, where a compass (still with some deviation) has been used.
As you can see, the figures are not completely the same, but every realization is at least recognizable.
The pairs of motors on left and right side are on low level controlled by two separate PID control loops. Using the encoder data as feedback signal, the motors are position controlled. In order to travel at a certain velocity, a set point trajectory is generated from the given robot instruction (such as ‘forward 100′) given a velocity of for example 20cm/sec. This 100 cm is divided into a part for speeding up, a part traveling at the constant given velocity, and a part for slowing down. Example graphs are shown in the next figure:
Using this strategy has led to a fairly accurate results, as shown in the last research trip to Cameroon. Unfortunately the compass had only been used during the first couple of workshops, due to a failing connector….. oh, well.. we live and learn, don’t we?
Because the robot has to be small, lightweight and low power, there is no room for using a big on-board computer. Instead, the robot is controlled by a small 8-bit microcontroller. The amount of functionality that can be stuffed into such a small controller is quite amazing.
The robot is controlled by a single ATmega32 controller by Atmel. This controller is an 8-bit RISC type running on 16 MHz. It is able to run two PID control loops for the two motor-groups, it interfaces using RS232 with a host PC, it reads out compass and incremental encoder data, and interfaces with a SD flashcard for program storage.
The controller is programmed using the GNU-GCC port for Atmel, also a number of other (open source) libraries for atmel interfacing (the well known AVR-LIB by Procyon) have been used.
A number of small custom PCB’s have been developed, such as a microcontrollerboard, a SD-interface board and a serial-port interface. This modular approach has been used to facilitate testing and debugging, and replacement of parts.
A tilt-compensated hall-effect based compass by OceanServer has been used for determining the driving angle. Normally these modules are being used for (model) submarines and autonomous underwater vehicles.
Optical encoders mounted on the motor shaft are being used that generate 12o pulses per revolution. With 1:30 gear and a wheel diameter of 12,7 cm (*pi = 40 cm/revolution) yields an accuracy of (30*120 / 40 ) = 90 pulses per cm.
In the latest incarnation of the robot two 7.2V NiMH battery packs are mounted. Each pack stores 2500mAh, enough for several hours of continuous operation
The robot ‘talks’ to a host PC using the ancient but very reliable serial RS232 protocol. With a terminal emulator running on PC or mac, status of the robot can be checked (such as battery status) and can programs be written or uploaded.
I remember a strange phonecall I had on a bus trip, I think it was end of summer in 2006. Esther had got my phone number from somebody, had visited my website and tried to explain the purpose of this project in a nutshell. Which is not an easy task. Links between Milk, Fulani and Robotics were not directly apparent to me, so, yes, it was quite a long call.
I’ll try to describe the Robot’s hardware as we have it now, with a little context relating all the way back to this first phonecall.
The robot basically consist of 4 motorized wheels mounted round a bottle. Using a laptop and a serial cable, you can upload a processed GPS track to the robot, which the robot stores in its memory. The GPS track can be played back by the robot by pressing a button.
In fact is the robot nothing more than a drawing tool, much similar to a plotter. Even closer is the idea of a ‘logo turtle’. Logo is a programming language developed in 1967. It can be used for making drawings, either on a computer screen by a cursor, or in the real world by a (two-wheeled) robot. See wikipedia for an elaborate discussion.
Even the syntax of the LOGO language resembles the NomadicMilk robot into detail. Both use simple ‘forward 100′ or ‘right 90′ like commands for making drawings.
The engineering criteria for this project make up quite a long list:
I started out with a rugged 4-wheeled robot kit by lynxmotion
As you can see in earlier blog posts, we first mounted the bottle with sand on the backside of the robot, yielding weird ‘notches’ in the drawings. In the current version, I drilled a large hole in top and bottom plate of the frame, allowing a bottle to be put right in the center.
Read in the blog ‘Robot development – electronics’ more about the microcontrollers that are being used, the sensors, and all the clever stuff (very technical probably)