Quadrature Encoder

One of the essential things an autonomous rover must have (which mine didn't had) is one or more quadrature encoders. In fact even some non-autonomous vehicles have these devices. Most regular cars these days feature this type of sensor as part of the ABS system (see http://en.wikipedia.org/wiki/Anti-lock_braking_system). Very reliable and high-resolution sensors can be found in these (featuring 90 steps or more).

For this autonomous rover I found that 16 steps would be the bare minimum, and easy to implement with common components.

As I didn't want to modify the RC car itself (drill holes, cut parts, etc), I looked for a solution that would minimize the impact on the car. As such I found that a good option would be to use the inner ring of the wheel as a surface for sticking an encoder band. This band has 16 steps, and looks like this:

Now remotely controlled via IP

After some hobby time spenditure, the result meets the expectations. While it is a functional and simple (and a good fallback solution), controlling the car via a regular RC radio is not the most interesting scenario. Having a device that is mostly digital, being controlled by an analog receiver isn't quite the nicest thing one would want to showcase. With that in mind, and taking into account that all the necessary hardware was already there and working, I have decided to take a little bit of time implementing the necessary components to be able to control the car from a remote peer in a wifi network. As such all I had was to:

Booster circuitry up and running

Running digital equipment has the drawback of requiring tight voltage ranges in order to operate. In the case of my robot, I had the need for powering the Fonera 2100 from a pack of 4 AA batteries. While the batteries can deliver 4.8 Volts once fully charged (which is barely sufficient to power this wireless appliance directly), once the voltage drops further, the Fonera ceasses to operate. In this situation the batteries still have remaining energy that is not possible to use.

Drastic Improvement: new Mobile Platform

After a lot of stress tests with the original platform, it was time for something better. The original platform was no more than a toy RC car (entirely made of plastic) with some hobby RC parts on top of if, such as refurbished steering system (with a real servo) and a home made ESC (Electronic Speed Controller) for the original toy car motor. During a demonstration with my 4 year old nephew, showing him how fast the roving robot would go in an open area, suddenly something happened: it started running full speed, totally out of control, both forward and backward (in my mind I immediately tought one of the ESC FET's had fried). I rushed to grab it, and suddenly smoke started coming out of the motor. Worried about the LiPo battery, with the motor still running and smoking, I centered all effort in disconnecting the battery. My nephew started to cry with the stange situation. After making sure no fire would occur, I had a confused infant to comfort.

Power pack!

While the rear wheel traction motor provides plenty of power for normal operation, the curiosity of obtaining some extra power through a different propulsion method is appealing. Since I had some parts from a unfinished airplane project, the materialization of another exclusive idea became real: to build a special trailer for the car, with a single purpose - to push the car even faster, with the help of a propeller instead of traction wheels. Featuring a 9x6E propeller, a 150 Watt brushless motor, an 18 A ESC, and a 1300 mAh LiPo battery, this trailer provides the closest one can ever get from raw rocket power, with controller propulsion.

Sensors are never too many

While it is important to design a autonomous rover capable of performing even under the worst conditions and with the least available information from the surrounding environment, if we can provide good information, it will certainly lead to better results as long as we have a good software implementation behind it.

System override

Unlike some other domains, with robot software bugs can have expensive outcomes. In order to avoid unpleasant mishaps, I have decided to implement a hardware solution for preventing software originated problems that could cause a calm, boring robot to become a runaway beast hitting hard against walls, people, animals and anything that is in its way. To achieve this I have built a PWM control source multiplexer: