Traction Control Algorithm

[Mr. Lim]

Looking for some advice.

This may not be so applicable to FIRST since most robots are a little "underpowered," and have their weight bias and drivetrain layouts set-up to prevent wheel-spin.

but,

Would the current sensors be a good indicator for loss of traction? I have heard that the outputs are a little bit noisy, and noticed in the default IR navigation code, an average of the last 10 readings as actually being used to resolve the current current. Is this still fast enough? Would a simple RC circuit smooth things out?

If they are a good indicator of wheel-spin, how do most traction control algorithms react when wheel spin is detected? Would you drop your motor output by a fixed value? to a fixed value? by a fixed percentage? kill the output all together for one cycle?

Then, there's detecting wheelspin in the first place. You could create a look-up table of expected current values for a motor speed, and if it's significantly lower, then, you've got wheelspin.

I'm sure someone has, or is thinking this through too. Post your ideas!

[Chris Hibner]

Originally Posted by SlimBoJones

Looking for some advice.

This may not be so applicable to FIRST since most robots are a little "underpowered," and have their weight bias and drivetrain layouts set-up to prevent wheel-spin.

but,

Would the current sensors be a good indicator for loss of traction? I have heard that the outputs are a little bit noisy, and noticed in the default IR navigation code, an average of the last 10 readings as actually being used to resolve the current current. Is this still fast enough? Would a simple RC circuit smooth things out?

If they are a good indicator of wheel-spin, how do most traction control algorithms react when wheel spin is detected? Would you drop your motor output by a fixed value? to a fixed value? by a fixed percentage? kill the output all together for one cycle?

Then, there's detecting wheelspin in the first place. You could create a look-up table of expected current values for a motor speed, and if it's significantly lower, then, you've got wheelspin.

I'm sure someone has, or is thinking this through too. Post your ideas!

This is kind of a lengthy answer, but here it goes...

First, I think it would be beneficial to describe how an automobile typically performs traction control (of course, this is going to be different depending on the system supplier, but here is one generic method that is used):

The first thing you need is the inputs to the algorithm. For automotive traction control this is typically wheel speed (to infer vehicle speed based on wheel angular speed) and an inertially calculated vehicle speed (i.e. integral of acceleration measured with an accelerometer).

The algorithm can then compare the two vehicle speed calculations. If the wheel speed is higher than the inertial speed, you know the wheels are spinning. You can then adjust the motor torque output until the two calculated speeds match.

At first glance, a simple linear (PID or compensator) algorithm appears to fit the job. However, this type of algorithm is typically too slow to do the job well. Instead, a rule-based algorithm is usually used. In other words, the algorithm compares the two calculated speeds to some look-up table, performs some if-then-else logic, and then adjusts the desired motor output based upon the lookup table and the logic. The basis of the tables and logic are usually created by a lot of testing and trial-and-error. Therefore, to answer your questions on what to do, I guess the answer is "everything you mentioned". In other words, you'll probably need to do a lot of trial and error to determine your own set of rules.

Now, back to the robot.

The current that a motor draws is directly proportional to the torque it is producing. Therefore, the current sensors are basically torque sensors. For traction control, you would ideally want to sense the velocity of your wheels. You may be able to estimate velocity given the torque (i.e. current) and the commanded PWM. I don't know if this is feasible or not since I've never deeply studied the problem. The look-up table that you mentioned would do this.

The one thing to keep in mind is that the current draw will also vary somewhat due to the temperature of the motors, and maybe some other outside factors. Therefore, even if you can estimate the velocity given the torque and your commanded PWM, the accuracy may not be good enough for traction control. In order to make this work, you're probably going to have to put a lot of work and research into your solution.

Even if you can accurately determine the wheel speed, you will most likely need another source to determine the robot speed so you can make the comparison. The reason is because your algorithm will not know if the wheels have their current speed because the wheels are slipping or because the robot is moving.

Whatever you end up doing, good luck with it. If you do get it to work, let us all know how it turns out.

-Chris

[KenWittlief]

Its an interesting idea - if the motor was near stall condition, and it started to spin, the wheel rpms would increase suddenly and the current draw would drop

but I dont think it will drop a lot - its still going to take a lot of power to spin a wheel with that much weight on it

so I think what you are looking for is a change in current, a sudden change. That would prevent normal operation, like ramping up to speed quickly from tiggering your traction contol circuit

only thing Im wondering is how usefull this will really be - the kinetic friction of the wheel and the static friction - if they are not that much different, then stopping the motor for an 'instant' to hook-up with the surface again, will it really give you that more pushing power?

in fact, I think you might have the idea backwards - I would think you'd want to use the current sensors to detect when your motors are stalled, drawing 40 amps, and back them off! Seems to me that being able to spin your wheels in a shoving match is what you want - you can keep applying a strong force, but your motors are not spinning at 3 rpm and turning your robot into a moble easy-bake oven :c)

The idea for the RC filter makes sense, except a filter with that low of a cuttoff frequency would have a significant phase delay, so you would be doing the same thing the SW you referred to is doing, it would take a while for the sudden jump (rising edge) to get through the filter - the digital muli-sampling probabally works better - it can tell if a sudden high reading is a noise spike, or if its real (if it persists for several cycles).

[Steven Carmain]

Past:
In 2002, the Technokats had a "Traction Control System" that we took a light sensor and pointed it at our treads. We still had metal treads and they reflected great. We also had a black and white wheel made of plastic and was painted. Another light sensor was used for the wheel, and we counted the differences in the tracks. A custom circut counted each and when the treads counted 16 (I think?) we sent a digital pin back to the OI. The system had three level of traction based on counts. It worked OK until the free wheel got pinched and we wore off half the wheel.

Today:
Now, you could make an encoder wheel to count your wheel speed for both wheels. You could use a rubber wheel to make a better roller wheel. You also have interrupts to make it super accurate! And you don't need a custom circut board!