If you read
'How To Read an RC Receiver With A Microcontroller - Part 1' you will probably have guessed that my approach is based around interrupts, you may even be thinking 'So what, there is nothing new in any of this'.
Your right on the first part, but writing the code to take control of the throttle signal on my 40Km/h RC Race car was a very long way from reading a signal and writing it to the serial port.
What Could Possibly Go Wrong ?
The real world quickly gets in the way - underground cables, vibration, noise from the RC Components in the car, mobile phone transmitters, the built up environment, low transmitter batteries, even passing traffic effects the signal.
During the design and test of the code, I had two hardware problems with a dry solder joint on the power capacitor attached to the electronic speed controller and a track on my low quality strip board which crumbled away. At the time I was not aware that these hardware issues were the cause and so I investigated every conceivable cause of interference.
|
Power Capacitor Soldered to ESC Power Terminals
|
Strip board track repaired after crumbling away!
|
One simple test repeated since the hardware issues were resolved involved propping the RC Car wheels off the ground and then walking away from the car with the transmitter. I repeated this many times, increasing the distance or changing the line of sight to include/exclude features in the built up environment. I was very surprised to see just how badly the signal degrades as you move the transmitter away from the car.
Transmitter and Receiver Adjacent To Each Other
Transmitter and Receiver 20 Meters Apart.
The charts show the pulse width variation over time with the transmitter set at a constant neutral signal. A straight line would indicate there is no variation in the pulse width, this is the result we might initially expect.
The two charts are generated using the code presented in the preceding post 'How To Read an RC Receiver With A Microcontroller - Part 1'
To create the charts, the serial output was cut and paste into Microsoft Excel.
The charts clearly show that as the distance between the transmitter and receiver increases, so the variation in the
signal increases. My tests have shown that the built up environment has an additional effect, further compounding the effects of distance.
With no controller input and the transmitter positioned just 20 meters away, the signal output by the receiver would randomly wander by as much as 30 milliseconds either side of the transmitter signal. Some of this would be due to the built up environment, moving the transmitter to a position occluded by a steel reinforced concrete pillar would cause chaos in the servo at only 20 meters.
So this isn't going to work is it ?
Not only does it work, but it works brilliantly. The best thing I can say about using the Arduino to control the throttle signal is that you can't tell its there.
The first few times I drove the current version of the software I kept having to bring the car back in to check that I hadn't shorted something and bypassed the Arduino completely.
So how does it work ?
First of all the mechanical nature of the servos and motors in our equipment provides a certain amount of signal smoothing, put simply, they just cannot move fast enough to react to the variation in the signal and so their position at any point in time reflects an average value of the signal in the preceding milli seconds.
Sample signal variation over 1 second - a random walk around the value 1540 - the value output by the transmitter.
In addition to the smoothing provided by the mechanical nature of the car, I have included a 'confidence' algorithm in the code. This algorithm compares the current input to the previous output, if the variation is small it ranks the new signal with a low value, if the variation is larger, the signal scores a higher degree of confidence. If the signal returns to its original value the confidence is reset to zero. The basic concept is that if we receive a vastly different signal, the chances are that its a new command from the driver, but if we receive a series of wandering signals they can generally be ignored provided that they do not creep in one direction which would indicate a subtle but valid input from the driver.
// Confidence Version 2, smaller, better, faster ?
int nDifference = nThrottleIn - nThrottleOut;
if(nDifference == 0)
{
nConfidence = 0;
}
else
{
nConfidence += (nDifference/4);
}
if((nConfidence >= SENSITIVITY) || (nConfidence <= -SENSITIVITY)) // SENSITIVITY = 8
{
nConfidence = 0;
// do something with this pulse ....
}
I am currently open minded as to the value of the confidence algorithm. Standard RC Equipment works well enough without the addition of this algorithm, however it is at a cost of battery drain, heat and mechanical wear. The real value of the algorithm in a mircocontroller environment is potentially in providing a lightweight, easily tuned mechanism to condition the signal for input into subsequent algorithms without introducing the lag that results from smoothing across multiple samples.
The following charts show a badly degraded signal before and after the simple confidence algorithm -
Signal Before Algorithm
Signal After Algorithm
In the charts above, the confidence algorithm clearly smooths a large amount of the signal noise, however it is too sensitive to cope with the extremes.
One feature of the algorithm is that the sensitivity can be easily changed through a single variable.
Test Conditions
The tests were performed with the transmitter and receiver at opposite ends of a steel reinforced concrete villa -
The line of sight was occluded by at least two walls
The receiver was adjacent to and transmitting serial data to a laptop.
The line of sight included an LCD TV and a kitchen appliance.
The reinforced walls, LCD TV and Kitchen Appliance have all been observed to cause a large degree of interference to RC equipment and signals.
Ideally the tests should be repeated with a higher value sensitivity however the test conditions are extreme and do not provide any qualification of the algorithms real world usefulness.
At present the algorithm has very little performance impact and clearly removes some noise, however before the algorithm can be qualified into or out of the RC Arduino projects it will need to be tested in the two most common RC Applications -
1) Racing - This is a tough environment with multiple transmitters sharing a fairly narrow physical and electro magnetic space.
2) Street Driving - This has its own challenges in the form of distorted signals reflecting from the build up environment.
In use to date, the confidence algorithm has no detrimental effect so it stays 'in' with one small change - 'Sensitivity' actually has the opposite effect and should really be renamed 'Damping' to reflect it effect on the signal variation.
Next up - Bad Pulses And What To Do With Them
Tamiya M03 Mini fitted with a Tamiya Sport Tuned motor and good for around 40Km/h.
Keeping the cost down.
