NomadicMILK

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. As the robot has no visual input, no beacons for triangulating, no micro-GPS for its own localization, it has to rely on dead reckoning only.

On cloudy days in ancient times, sailors had to rely on a compass, a knotted robe (or chip log) and extrapolation for maintaining their course. Normally they 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 are 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 to be fairly constant when driving on a flat surface. On a flat surface it is possible to draw a reasonably 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 approach taken (i.e., no additional navigation beacons) was ever going to work. Simulation showed however that 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 the left and right side are controlled on a low level by two separate PID control loops. Using the encoder data as a 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 could only be 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. A number of other (open source) libraries for atmel interfacing (the well known AVR-LIB by Procyon) have also been used.

A number of small custom PCBs have been developed, such as a microcontroller board, 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 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) this 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. The status of the robot (such as battery status) can be checked and programs can be written or uploaded with a terminal emulator running on PC or Mac.

I remember a strange phone call 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 phone call.

The robot basically consists of 4 motorized wheels mounted around 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 the robot is 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:

• Draw prerecorded GPS tracks in a recognizable way
• Draw them accurately
• Accept drawing from PC in clear, easy to understand format
• Store programs on Flash disk or other nonvolatile memory
• Make drawings ranging from 1 square meter up to 100 square meters
• Work for a couple of hours on batteries, rechargable
• Can be transported as hand-luggage (airplane), lightweight
• has to be durable (shaking, dust, sun)

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 back side 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.

In the blog ‘Robot development - electronics’ you can read more about the microcontrollers that are being used, the sensors, and all the other clever stuff (very technical, probably).

News site NU.nl (in Dutch) reports that after a two-year test with GPS technology by eight Frisian farmers, potato production in euros per acre may increase by 4 to 5 %. The farmers have united themselves into a cooperation called “Precision farming De Wadden” (Precisielandbouw De Wadden). One of the famers, and head of the cooperation, Ate-Jo Oosterhof from the village of Westhoek, owns ‘mixed soil’ fields. These are fields with both heavy and light soil. More potatoes can be grown in heavy soil than in light soil. Until now the amount of potatoes put in the ground has been calculated using a mean average of what both soil types can have. By using a digital map of his plot however, the Frisian farmer can see exactly what soil he is driving on. Now he links his machine that puts the potatoes in the ground to the GPS navigation system. This results in the exact amount of potatoes being put in both soil types.

This is a nice example of a very practical application of GPS technology in combination with a kind ‘self-navigating’ or ‘self-thinking’ device, similar to the drawing robot we are developing for NomadicMILK.

source (picture & news article)