Open and Closed Loop Traction Control

[Pulsar]

I have Two Days to develop an effective traction control system for an upcoming competition. Now - there are a number of ways to do this, but at this time let's limit our discussion (please) to the two systems I've already worked on.

The first, less desirable system, is that of a model-based control system. Simply put, we've measured the power applied to the wheels of our vehicle at different speeds in non-slip conditions, plotted and fit that to a curve. We then took that curve and limited the permissable torque to a certain % above or below the torque curve at any given point.

This system is somewhat predictive, which is desirable. However, it will only function for surfaces with a known model.

The second system, which I am struggling with, is the more desirable. This is a feedback system that does not care what surface it is on. We have two unpowered wheels to provide feedback. Those wheels are compared to the powered wheels. A slip percentage can be computed to determine the amount of extra wheel spin you have. Being a mechanical guy pressed into systems and controls work, this is where I falter (and why the classical model I mentioned above makes sense to me...).

Is has been suggested to use a PID loop to control the power to the motors. I am passingly familiar with PID loops (I can write them and tune them). Having slip %, and drive input, I am unsure how to structure the PID to minimize slip to a certain level while still providing decent response to the drive. Another team suggested that they feed actual slip % and desired slip % into the PID - but I don't know how one would integrate that with the drive input.

Little help?

 

[CycloWizard]

The first thing you need to do is determine what you want to control. Is it traction? Is it wheel rotational frequency? Is it actual velocity?

From what you said, I have to guess that it's the slip percentage. Therefore, since you already have this variable in hand, simply compute the error between the set slip % and the actual slip %, feed it into your PID loop, and the PID loop will spit out the command voltage or current. The beauty of closed-loop control is that the controller replaces the need for any real detailed knowledge of the physical system. However, depending on the type of motor and transmission you have, it may be difficult to pick the type of controller you want and/or tune its parameters.

 

[Pulsar]

Cyclo - your statement is EXACTLY where I'm struggling.

If I have a PID utilizing desired slip % and actual slip %, how does my driver input factor into that?

Should I be using my driver input and calculating a desired slip % from it to feed the PID?

So driver input - for instance the gas pedal, would actually be calculated into a desired slip %?

Or would the driver input drive the vehicle, except when slip % moves above a threshold, then the PID takes over? It seems like that would creating bucking in the system, and I'd rather stay away from having to implement another layer of complexity in a low pass filter or something similar.

Thank you for responding - no one else on the team "gets" this stuff, so I need someone to bounce ideas off of and work through it.

Oh - and the system is a simple 12V DC voltage controller running an electric motor in a single speed transmission. NO complexity from the mechanical side. (And no, due to complexity I don't want to look into voltage or current monitoring - maybe next year).

 

[CycloWizard]

Ah, now I think I see what you're getting at. I would treat the slip as a disturbance in the system, whereas the setpoint is actually the driver input. The driver hits the "gas," he wants to get to a certain velocity setpoint (really, hitting the gas to a certain level is fixing the motor's output work as a constant). Your system changes this input somehow into a current to supply the motor. The motor outputs torque, and the torque results in movement. This is where your slip comes in: if there is no slip, then everything is good to go and there is a clear relationship between the driver input velocity setpoint (as indicated by "throttle" position) and the actual vehicle velocity. Thus, the controller simply takes the input and makes an output based on the difference between the setpoint (probably a velocity) and the true measured velocity (which is what you need to determine using your slip measurements).

When slip occurs, that relationship breaks down. How exactly it breaks down depends on how you're calculating slip, which is something I'm not familiar with in this scenario. If you can explain how you're measuring/using "slip," I can probably help a little more.

 

[Pulsar]

We calculate slip by comparing a driven wheel to an undriven wheel. Slip % = (drive - undriven) / undriven * 100. (We have high resolution quadrature encoders on both the driven and undriven wheels that run at an update of .1 khz.)

Here's what I'm thinking would potentially work:

Let's say the drive signal ranges from -1 (reverse) to 1 (forward) just for simplicity's sake.

If I calculated like this:

drive signal * max slip => send to PID as setpoint (range would be, in this case, from -20 to 20)
actual slip => send to PID as the actual value (range from -100 to 100)

Then the PID, if tuned correctly, would try to match the actual slip to the max slip.

Do you think that would work as intended? Our belt drive system has basically zero drivetrain lag and zero electrical lag, so any other complexity factors can be ignored like geartrain lash, etc. At this point in time, I'm just looking for straightline control - obviously turning will add more factors into the system.

The only issue I see in this is that removing your foot from the pedal will result into a coast to a stop rather than a traction controlled stop - I'm not sure how to work around that. Perhaps another case that checks for foot removed and goes max opposite to current direction until the encoders see themselves as stopped.

Thanks again!

 

[Pulsar]

Bah.

I sat down and thought about it and that set up won't work either.

If we're going full speed (value of 20) and the driver reduces to half speed (.5 * 20 = 10% slip), then we won't actually slow down any. So while it will work to accelerate the robot in the forward direction, this would not result in the robot slowing when the joysticks are not pushed all the way forward. 10% forward slip still represents trying to accelerate forward.

!@#$!@

 

[Pulsar]

Try 2 -

PID Setpoint: (% slip allowed * pedal value * follower wheel count) + follower wheel count
PID Variable (actual): actual wheel value

I think that's it.

Then when I want to turn I simply up the % slip allowed to some other value (20% has shown to be about the best slip value traction wise).

 

[CycloWizard]

So you have a gas pedal but no break pedal? You could add a toggle switch that inverts the motor command current for braking, which I think would be pretty cool. Alternatively, you could use a dial that goes from a negative current to a positive current. Of course, depending on the motor/transmission setup, that won't work if the motor's direction doesn't depend on the sign of the current. If someone is actually going to be driving this thing in a competition, they would surely require you to have some sort of braking system for safety purposes, if nothing else.

 

[Pulsar]

Up till now, without traction control, when our voltage controller sees zero duty cycle from the pwm cable, it automatically brakes by shorting the engine poles. This is a poor way to stop because you go into a four wheel skid.

I'll have to set up a case statement to accelerate the vehicle in the opposite direction until it comes to a stop when I implement the traction control. However, I think my "Try 2" might actually get me somewhere. I'll code it all tonight and run it in simulation.

 

[blahblah99]

The only thing the PID motor loop will control is the commanded RPMs for the motor. This is easy to do - you can find examples of PID motor control everywhere. If you have problems modelling the plant, you can always tune the Kp, Ki, Kd values emperically using the Ziegler-Nichols method.

If you want traction control, you will need to add an accelerometer and come up with a seperate control algorithm. The inputs to the system are acceleration, and motor RPM. The output is the commanded RPM, which goes into the PID motor loop controller. The PID motor loop controller has nothing to do with traction control other than the fact that it provides the fastest transient response to a given RPM input.

If you know state-space analysis, now is the time to put it to use. 🙂

 

[Pulsar]

Actually the way it finally worked is this:

We used our follower wheel and our driven wheel to calculate slip percent.
We fed that into a PID loop as the variable to be controled, limited the output to a range of -1 to 1, and then gave it a setpoint (desired point) of zero (zero slip). We then subtracted the output of the pid from the value commanded by the pedal.

By tuning the pid for the slip, we controlled to what degree it counteracted the pedal command. The final result was a 15% improvement in acceleration.

Woot!

P.S. - you CAN use accelerometers, but they have to be higher end ones. Any amount of noise will create issues on integration. A number of other teams tried this most gave up on it ($/performance value wasn't there).