Traction Control Part 1.2 - Taking Control

So far I have used two pairs of IR Emitter, Detector diodes to monitor the speed of the front wheels, I use this information to detect wheel spin based on the assumption that if one of the wheels is spinning more than 20% faster than the other then I have lost traction in that wheel. This is all covered in the post Traction Control Part 1.1.

The next step is to interface the Arduino between the remote control receiver that receives the signal from the users radio and the electronic speed controller that delivers power to the electric motor based on the users signal.

As the first step towards this I will implement a 'Child Mode' for my cars. The idea here is that if I hold the brake for 10 Seconds, the Arduino will enter 'child mode' and map the throttle input range to a more limited 'child' range. This way whenever my son or daughter want to have a go I can discretely hold the brake to activate child mode before passing them the transmitter, a similar signal will be used to revert to standard operation.

Prototype using Arduino to read input pulse width, then use the Servo library to generate output pulse of same width. The picture shows a servo connected rather than the electronic speed control but the pulse, logic and connectivity is the same for both. I prefer testing with a cheap servo rather than a racing motor spinning at 21,000 RPM !

I have had an early version of this working where the Arduino was capturing the throttle pulse width through an interrupt and then using the writeMicroseconds function of the Servo library to control the servo. This proved the concept of decoupling the servo from the receiver and giving the Arduino responsibility for mapping from the input signal to the servo.

During the testing of this code I found that I had a massive electrical noise problem when the Arduino was powered from the same LIPO battery as the rest of the car, this put the project on hold while I investigated strategies for dealing with the noise. I now have the noise under control and in the next few days hope to be able to post the 'Child Mode' code and confirm that the noise really is under control and the strategy used to control it.

Anti-yaw control Part 1

I gave a new kit its first run today, its a Tamiya Sand Scorcher which is a reissue of a 30 year old design. It looks fantastic in motion but could really use some on board electronic help to stay on track.

A little bit of history

Back when the kit was issued it would have been powered by a 7.2 volt Nicad battery which took about 18 hours to trickle charge and lasted about 7 minutes. Today I am running the reissue on an 8.4 Volt Lipo which takes an hour to charge and lasts about 30 minutes, its also about half the weight of the original batteries.

The kit itself is very different from todays plastic and carbon kits which contain very few metal parts, the sand scorcher is almost entirely metal with parts made from stainless steel, aluminium and brass. 

Its a real novelty to put together if your used to todays kits, it also makes for a more 'scale' drive as the weightier metal parts cause the car flop, lurch and bounce around far more realistically than a modern lightweight plastic kit.

I am not sure whether its the lighter, more powerful modern day battery, the rear wheel drive chassis, the desert sand or just my driving but the car is impossible to drive in a straight line. Every rear wheel drive radio controlled car I have ever driven has had this problem, but this one is the worst of the lot. One solution which many people have tried with RWD RC Cars is to put a gyroscope into the car.

A gyroscope fitted in my Tamiya M04 Rear Wheel Drive On Road Chassis.

The gyroscope senses the car beginning to fishtail and instantly steers into the skid (counter steers) to keep the car moving forward. This can also be useful over rough ground and jumps where the gyroscope will keep the front wheels pointing into the landing even if the car starts to rotate to the side in the air, this reduces the stress on landing minimising parts wear and breakage, it also keeps the speed up as the car 'digs in' less on the landing.

My F103GT RWD On Road Chassis demonstrating how to 'steer into' a skid or fishtail.

If the rear of the car is skidding left the steering is turned to the left, this is known as 'steering into the skid', this stops the car from spinning out and should allow the driver to straighten out of the skid as the rear regains grip	If the car skids to the right we steer to the right, in both examples you can see how the front wheels point straight ahead as a result of 'steering into the skid' its the fact that the front wheels point in the direction of travel that should stop the car from spinning out and allow the driver to regain control.

I have had limited success using gyros, the problem is that the gyroscope is passive, it applies the same level of counter steer regardless of the cars speed and the drivers intentions, for example if I am trying to turn left, the gryoscope will sense the car rotating and tell the wheels to turn right to keep the chassis straight. This counter steering effect is adjustable through 'Gain' this is a static setting which controls how hard the gryo will try to keep the car straight. What we need for effective 'Anti Yaw or Yaw Control' is active gain that keeps out of the way when you want to turn and gets straight on the job when you don't. This is where Arduino comes in.

Project Goals - 

1) Easy to access user interface to set the base level of gain

2) Allow adjustment of the base level without needing to restart the Arduino or the Gyroscope

3) Actively adjust gain around the base level based on the signal coming from the controller

3.1) If the controller is telling the car to turn, reduce the gain so that the gyro does not fight the turn

3.2) If the controller is telling the car to accelerate or brake, increase the gain to prevent fishtail and spinout

4) Provide a simple means of turning the active components off for easy comparison between 'active anti yaw', 'passive gryo based anti yaw' and no anti yaw.
5) Provide an easy interface to set a maximum and minimum range for the servo, these limits will prevent the software/user command combination from sending signals to the servo which would cause it to exceed the mechanical limits of the model.
5.1) Record the range limits to the EEPROM for persistent storage
6) Record any operating errors to the EEPROM for persistent storage and retrieval
7) Use the project as a test bed for decoupling noise before progressing the traction control project

More soon. In the meantime, here is another picture of my fresh 'weathered' Sand Scorcher, the bodyshell is white plastic which I have painted and otherwise abused to look like 30 year old metal.

Spice Vs M-Grips

M-Grips (blue) for the win in this case. I would have expected the Spice tyres to show the highest G's but it was early morning so the spice would be struggling to get up to temperature.

Data Logging Part 3 - Data Logged !!!

I have finally logged some data to the SD Card. To make life super easy I am logging the data is CSV format, this is a very simple text based format that can be imported by any spreadsheet application, in my case I am using Excel. The charts are simply generated by selecting the data and clicking the Excel chart icon.

The first test - Figure of 8 and Max Acceleration, Max Braking.

This first chart plots the X,Y,Z Axis as red, orange, pink. I would not have expected to see much movement in the Z axis as the car is running on reasonably flat tarmac however I am running smaller tyres than normal and so the car is dragging on the road where I haven't yet raised the suspension to compensate. Bumping along small stones is one possible cause for the movement in the Z Axis. For the remaining charts I have removed the Z - Axis so that we can see whats happening in the X and Y Axis (lateral G-Force and acceleration/braking).

I am quite pleased with the data here. For the first half of the test I was driving in a steady figure of 8, you can see this in the graph where on the left side the pink (acceleration/braking) line is steady and the lateral G-Forces swing from positive to negative as the car corners to the left and then to the right.

For the second half of the test I changed to accelerating and braking, again this shows up clearly as the pink line now moves from the positive to the negative, accelerating to braking. Interestingly you can see that the M03 is able to brake much harder that it can accelerate - pretty much what you would expect but its nice to see it captured consistently. I can also see from the red line that at the end of my acceleration and braking runs I always turned to the right to start the next run. The final point of interest is that the test strip was on a slope, and you can see this in the acceleration and braking runs where the peak G-Force under braking is higher on the first and third runs (uphill) than on the second and fourth runs (downhill).

Scatter Graph

This last graph plots each data point on an X and Y Axis, with more data it should provide a reasonable representation of the traction circle.

Again you can see that I spent more time turning left and that the brake force was about 50% higher than the acceleration.

Thats the easy bit finished. Now I need to develop a test protocol to confirm the quality of the test data. I also need to run some tests comparing spinout data with controlled high speed cornering, its pretty useless data if spinouts can't be determined from successfully negotiated high speed corners.

Data Logging Part 2 - A User Interface

My first attempt at a micro controller user interface -

I am pretty happy with it, its a thousand times better than the horrible interfaces you get on your average Electronic Speed Controller. Take the example of a Tamiya TEU104BK, the user interface consists of a single 1*2 mm grey button hidden in a 4mm recess in the case. The button and indicator light are in highlighted area in the pic below, a 10mm push button is included for size comparison.

While I have used a great big bright red 10mm push button, I haven't completely broken away from tradition, the interface still relies on the users ability to count and interpret a sequence of flashing lights. The reason for this is that mirco controllers provide a limited number of inputs and outputs. Each of these inputs/outputs can be extremely powerful so using them up with indicators, displays and multiple push buttons is an unacceptable waste of resources.

The data logger user interface


1 Big Red 10mm Push Button
1 Bright Red LED to signal 'Recording'
1 Bright Green LED to signal 'Sending recorded data over the serial interface'

The system has 5 states -

State	Meaning	Record Indicator	Serial Indicator
Idle	Not currently doing anything	Brief flash every 2 seconds	As Record
Record	Recording Data to SD Card	On	Off
Serial	Reading SD Data and writing to serial	Off	On
Memory Full	No more data can be recorded	On 1 Second/Off 1 Second	As Record
Error	Something is wrong	Rapid Alternate with Serial	Rapid Alternate with Record

To move between states the push button must be held for 1 second or more. To enter record from idle 1 Second, to enter Serial from idle 4 Seconds, to exit either record or idle 1 second.

All I need now is a Micro SD Card and the data logger is up and running.

Data Logging Part 1 - Acceleration

Its so easy to build circuits and programs with the Arduino that I have a few projects progressing side by side on the same hardware. In this project I intent to record performance data on board my RC Racer then upload the data for analysis on the PC. Something which I see as very simple but very useful is the ability to record and visualise the traction circle for different setups. For my purposes the traction circle will be plotted from the X and Y G-forces acting on my car, to sense and record these forces I am using an ADXL335 3-Axis Accelerometer and a Micro SD Card. Both of these are available on easy to use 'breakout' boards that can be plugged directly into the Arduino UNO. The two plots above are produced from live data coming from the Arduino into my PC, I am using 'Processing' to display the results. The screen area represents +-1G in the X and Y Axis, Z is not plotted. The first plot is generated with the board flat on the table. The second plot is the result of me tapping the side of the table to generate some movement in the X-Axis, then tapping the front of the table to get some action on the Y-Axis, but the really interesting plot is the next one -

Here I have used the constant 1G acceleration provided by good old fashioned gravity. By tilting the board from one side to the other I can use gravity to apply 1G of acceleration to the left and then the right. You can see the result of this in the lines running right, up and down from the center. The diagonal line running from the center to the top right is the result of me trying to 'draw' the line by progressivley tilting the board and letting gravity do the work. This was surprisingly difficult, it had that addictive quality that the simplest of games have - something thats quick and easy to understand, takes a while to master and can always be improved upon. I can think up a dozen gaming applications for this - for example physical tetris where you actually have to rotate the controller to rotate the tiles and then swing the control to the left or right to position tiles. Another application would be target based sports simulations, the sensor is sensitive enough to pick up hand tremors.

Getting back to the main purpose of this project, the left side of the screen shows a sample of a traction circle I have generated by rotating the board which is sensing the constant 1G force of gravity over a range of angles. In practice most of the plot points would be toward the center of the screen but this provides a quick bench test and proof of concept. The sensor I am using can sense up to 3G, and also records the z-axis which I am recording but not currently plotting. I have no idea what to expect in the car, probably less than 1G but will get some plots up with different tyres in the next day or so - I know that racing tyres are worth every penny compared to stock tyres and soon I will be able to prove it !

Traction Control Part 1.1 - Monitoring Wheel Speed

The Atmega328 microprocessor at the heart of the Arduino is able to process 16 million operations per second.

The wheels or my test car running at full speed turn 68 times per second.

The Arduino is able to perform around a quarter of a million operations in the time it takes for my radio controller car wheel to rotate once.

Given these numbers I was confident of being able to monitor the speed of all four wheels, however I wasn't so sure of how to electronically sense the mechanical movement of the wheels. There are several challenges here -

1) I can't add anything to the wheel which upsets the balance, so no metal or magnets.
2) I have very little room to work with between the wheel and the wheel hub so have no option to add beam breakers to the wheel.
3) The front wheels need to turn freely in order to steer so I cannot impede their movement and cannot rely on a constant angle between the wheel and the sensor.

The solution I chose was to use pairs of infrared emitter and detector diodes.

• Cheap
• Easily Available
• Non-invasive
• Side facing design

The 'side facing design' means that the light is emitted and detected through the side of the diode, in our case this is an advantage as the diodes are very slim in profile and as the leads exit at the bottom this allows us to mount the diodes lying flat. The diodes are 2mm tall when mounted this way leaving around 10mm between the wheel hub and the wheel.

Most IR Sensor circuits rely on 'beam breaking' where an object passes between the emitter and the detector - breaking the beam. This is not an option in my case due to the small amount of space available and the amount of vibration present in the wheel and the hub.

One idea I had was to try sensing reflectance instead, to do this I initially set up a circuit with both the IR Emitter and Detector facing out from a prototype board. I then fixed a small strip of white tape to one of my tyres. At low speeds I was able to detect the white tape passing the in front of the sensors and count the revolutions per second. At this stage I was not concerned about higher speeds as the design was far from optimal.

The next step was to develop a package for the IR pair that could be mounted in the car between the wheel and the steering hub.

To do this I first trimmed the leads of the diodes and soldered on some flexible wire which I could later route around the car. I also used a layer of heat shrink to protect the wire joint from electrical shorts and mechanical wear.

Next I used double sided tape to mount the diodes to a square of styrene which I then glued to the wheel hub.

You should be able to spot the sensor mounted to the steering hub in the center of the picture below.

To ensure the best quality data I needed a sharp transition from reflecting to non-reflecting. To achieve this I sprayed the inside of the wheel satin black and then mounted a strip of 'bare metal foil'. This is an aluminum foil that has an adhesive on one side, its usually used for adding metal details to small 1/32 and 1/43 model cars and for this reason is exceptionally thin and therefore light enough not to upset the balance of the wheel.

On the other end of the sensor wires I soldered individual header pins allowing me to easily plug the sensors into my prototyping board.


Note that as I used a common ground wire for the two LEDs reducing my connetions from four to three.

I have made and mounted a set of sensors for both front wheels and now that I have proved the concept will eventually make sets for the rear wheels in order to monitor traction at all four corners.

Next up - connecting to the Arduino and writing the software, here is a preview -

What can I do with an RC Car and Arduino ?

One of the strengths of the Arduino is the ease with which it can be interfaced with inputs (sensors) and outputs (motors, servos, LEDs, speakers etc, etc, etc)

In the coming weeks I hope to be able to build the following radio controlled car based projects

1) G-Force Logging - use an accelerometer connected to the Arduino to measure acceleration and deceleration and log this data to an SD Card.

2) Traction Alarm - use infra red sensors to measure the speed of the wheels and sound an alarm or flash a visual signal whenever the speed of one wheel exceeds the other by a given percentage

3) Training Mode - It would be nice to have a button to push to put a car in training mode, this would limit the power to 25 or 50% allowing me to pass the controls to my kids and then easily return the car to full power when I get the controls back

4) Traction Control - This is really a combination of 2 and 3 with a lot of extra work required. The circuit from 2 would be used to detect wheelspin and the circuit from 3 would be used to manage the power being requested from the motor. With some experimentation it should be possible to create a program to vary the motor power based on the degree of wheelspin detected and the amount of power being requested by the driver. It would also be nice to combine this with 1) to be able to log acceleration with and without traction control.

5) Traction Contol with Brake Force Control - Assuming that 4) can be made to work, the next logical step is to add active brake by using the same principle to detect a wheel locking and automatically reduce the brake force.

6) Yaw control - Yaw is movement in the left to right axis, like the fishtailing that rear wheel drive cars produce under hard acceleration. It is possible to sense this using a gyroscope and have the car automatically correct by steering into the skid.

7) Active Torque Distribution - In a twin motor car it should be possible to send power to which ever axle is generating the most grip

And now a quick look at some cars

Rear Wheel Drive Tamiya F103 GT with HPI Zonda Bodyshell

Front Wheel Drive Tamiya M03 with Kamtec Beetle Bodyshell

This final car is a front wheel drive car joined to a rear wheel drive car, it was an interesting project and very fast, much faster than the two donor cars.

Custom 4WD Twin Motored Car

Unfortunatley as fast as this car was, the handling was too unpredictable. The rear of the car was built from a Tamiya M04 a car with notoriously bad handling. Getting this car to handle will require Active Torque Distribution at the very least.

What is an Arduino ?

What is an Arduino ?

If you have ever wanted a small gadget to control something with, Arduino is the answer.

The Arduino team have taken a microcontroller which is basically a single chip computer and built an easy to use physical computing platform around it.

You already have countless microcontrollers in your life, there is one in your washing machine for instance. On thier own microcontrollers can be very difficult to use, difficult enough to be beyond the access of all but the most dedicated hobbyists. What the Arduino team have done is produce a design which reduces the learning curve to the absolute minimum while still providing a powerful platform for project development.

What is most impressive about the arduino is the range of sensors available, my own interest is in measuring the effect of setup changes on my radio controlled cars and also in providing active in car control. There are off the shelf boards and software that literally allow the sensors I need to be plugged in to the Arduino with no need to seperatley source individual electronic components or even get deep into understanding thier purpose.

Its a bit like building a PC, if I need a graphics card, I buy a graphics card, I don't need to buy 300 components or even understand what they do, I just buy and plugin a ready made solution which does what I want.

Arduino does what I want.