It’s not incredibly hard, but it does have its difficulties. When the target car is far away, getting to it is relatively simple. The algorithm runs something like this: Drive forward and turn towards the target. Turn sharper if the target is very far to the left or right, and drive faster if the target is farther away. This sort of control is known as proportional control.

Proportional control is a very simple way to solve this problem. So we’re done, right? Not quite. What if you’re too close to the target and you can’t turn sharply enough even at your lowest speed to drive towards it? Herein lies the difficulty of controlling steered vehicles. In fact, this is an entire class of problems known as the control of non-holonomic vehicles.

The E-Maxx RC truck’s stock power supply is a pair of 7.2V batteries in series for a total of 14.4V. The only components on the truck that run at 14.4V were the main drive motors. Seeing as we had to run a PIC for logic and control, as well as some hobby servos, we added some additional batteries.

For the PIC, we put in a 9V battery and installed a voltage regulator to bring the voltage down to 5V. To power the hobby servos, we attached 4 AA cells in series for a 6V battery pack.

As a safety feature, we used a 30A circuit breaker on the main drive motor circuit, and added a servo to trip it on release of a radio "deadman’s switch".

The stock TRAXXAS motor controller on the E-Maxx RC truck proved to be inadequate for our uses. During intended use, the stock controller is more than sufficent, because all you’re trying to do is drive the truck around with a radio controller. We wanted the truck to move as slowly as possible, but the stock speed controller cut off the bottom 10% of the input command range and kept the minimum speed of the truck to about jogging speed. However, because the top speed of the E-Maxx truck is 25mph, we needed to be able to go as slow as possible. The stock controller has a deadzone of about 10%, so we installed a Victor 885 from IFI Robotics, which has a deadzone of 3% and a a current capacity of 120A, which exceeded our needs.

We used the TSOP22xx series IR sensors from Vishay Semiconductors, which are typically designed for use in something like a TV set or other IR remote-controllable devices.

TV’s and other remote controlled devices are often around sunlight or other sources of ambient IR radiation. In order to help reduce interference from these outside sources, remote control signals are modulated on a carrier frequency of 38kHz (typically). The TSOP22xx series IR sensors do exactly that, by band-passing a frequency range near 38kHz and demodulating the sent signal.

The TSOP22x series are digital, meaning we cannot determine distance to the IR source by measuring the signal’s intensity. Also, the sensors have a limited cone of "vision." To address both of these issues, we mounted two angularly offset sensors on a custom PCB in order to obtain directional data. That is, if the left sensor on the PCB is on but not the right one, we know that the target is somewhere to the left of the centerline of the PCB.

For the logic and control components of the truck, we used the PIC18F2455 microcontroller from Microchip and the SSC-32 servo controller from Lynxmotion. The SSC-32’s logic and the PIC18F2455 were both run off of the 9V battery, although the PIC was run off of a 5V voltage regulator. The SSC-32 servo power buses were run off of the 4 AA cell 6V battery pack.

The IR sensors were connected directly to the PIC and powered off the same 5V source from the voltage regulator, and all of the servos as well as the Victor 885 controller were all connected to the Lynxmotion SSC-32 board. All of the decision making is done on the PIC after the sensors are polled, and the output is sent over RS-232 serial to the SSC-32 which controls the servos and speed controller appropriately.

We started with 4 AA cells to power the beacon, but since each of the 12 LEDs pull 0.1A by themselves, this proved to drain the AA cells extremely quickly. We decided it might be a good idea to invest in some recharagable NiMH AA cells. Unfortunately, due to the large current draw and the slight differences in voltage across the NiMH AA cells, one of the four was drained disproportionately quickly and became reverse-biased, resulting in irreparable damage. In the end, we switched to using an external power supply that was more than capable of providing the required power.

The drive train of the RC car was powered by 4 AA cells. In this case, the AA cells were sufficient, even though they were not the factory-approved power solution for the car.

The most important part of the target RC car is the IR beacon. Since the IR sensors bandpass a frequency range around 38kHz, we needed a way to generate a 38kHz square wave.

In the end, we used a 555 timer tuned to 38kHz with a precision capacitor and a potentiometer. After several prototypes, we managed to get the 555 timer working. However, because of the relatively high 0.1A current draw from the IR LEDs, we needed to use a MOSFET to drive them.

One thing we neglected to do was add an pull-up transistor to our circuit, so the resultant wave was not a perfectly formed square wave. As a result of this, the IR sensors, which typically have a range on the order of the length of a large room, only were able to detect the beacon within about five feet.

The parameter controller was the first and simplest of all four state estimators developed. Both eyes are always focused on a single point, which the controller returns as the guess of the target position. This intersection of servo angles moves based on what each eye reports that it sees.

The parameter control works by only changing either the radius of the guess or the angle of the guess. If each eye sees the target with both sensors, the guess does not move. If only the left eye or only the right eye sees the target, the angle of the guess changes to follow the targets' new move. If the target enters one of the crossed zones where three sensors see the target, the guess changes radius to follow the target.

The parameter controller relies a damping effect on its changes of radius and angle. Every time it changes state, it analyzes how long it has been in the previous state and the current radius and continues the change in angle or radius for a proportional amount of time. This minimizes the hysteresis inherent in a multi-state system, and assumes the target and the car have some inertia which will not allow for instantaneous changes in position.

The static averager was created in order to find as exact a position as possible when the E-Maxx is stationary and the target is moving relatively slowly. The static averager sweeps both eyes from left to right and records changes in eye state and the angle at which those changes occurred. When each eye has changed state twice, the static averager decides on a servo angle that is the average of the two state change events, and focuses both servos on the intersection of the two angles.

The wiggle controller was created as an addition to the parameter controller when it was found that the parameter controller lost ranging information too easily for targets moving radially towards or away from the the cat. The wiggle controller kicked in after a certain amount of time had elapsed, and purposefully moved the focused eyes through a change in angle in order to observe a state change event. Once the event had been observed, the parameter controller kicked in and generated a position guess.

The brute force controller was created to attempt to generate faster, more accurate guesses on target location by keeping the eyes in continuous motion. Each eye panned right and left, attempting to keep both sensors focused on the target by reversing the travel direction every time it observed a sensor state change. The controller stored the angle of state change in a buffer and compared it to the next angle update from the other eye to compute the next guess intersection. The oscillation of the two eyes was linked by a damping constant in order to ensure that the eyes were either moving towards each other or away from each other. This decreased the time between one eye registering a state change and the other registering a state change, which was critical for an accurate guess of current position.

What’s proportinal control? Typically you have some desired value, in this case, you want to be pointed directly at the target, so you take the direction heading from you to your target. You then take your current value: your current heading in this case, and take the difference of the two values.

The thing you control, the steering wheel, is then moved proportionally to the difference, which is typically referred to as the "error." As a result, you will turn the steering wheel more sharply if your target is far from your current direction of travel.

Another example is the gas pedal. If your target is far from where you are (the error is great) you will step harder on the gas pedal. If your target is close, you don’t step on the pedal quite as hard.

The main driving algorithm essentially checks to see if the target is closer than 50 inches. If it is, then it will run the parallel_park() function. If it farther than 50 inches, we should run the proportional control driving algorithm.

The parallel_park() algorithm essentially turns the truck’s wheels in the opposite direction of the target’s location, and backs the car up until the truck’s heading angle is within a certain error angle of the target. That is, the truck will execute a backup turn until it faces the target once again.

The parameter_drive() algorithm uses proportional control to drive the truck. If the truck is far away from the target, the truck will drive faster. If the target is very far to the right or left, the truck will turn more sharply.