How are you implementing traction control?

I know there’s already a thread with traction control ideas–but I wanted to get a sense of how many people are using each method. 1678 is planning on using an accelerometer-based system, where we look for large shifts in juoystick position and check if this correlates with a shift in acceleration.

Our team plans to use code. We’re going to add an acceleration rate cap. This way when you slam the joysticks forward, you only accelerate at say 25% power a second.

It is a good idea to also program an override button so that you can accelerate to full when you need to.

From what I understand what my team is doing(I’m not a programmer) we plan on using a mix of encoders and an accelerometer to get our ideal acceleration based on if wheels are slipping and we’re accelerating. This is just from what I’ve been told, I’m not a programmer and I’m not 100% sure on how they’re implementing it.

There was no mention of just using the encoders to limit accelleration. Since the robot (plus trailer) should be friction limited to an accelleration of 0.5 m/s2 then you just need to make sure the wheels never pick up speed any faster than that.

Interestingly, after we worked this through with the programming team tonight, I took the opportunity to throw some basic kinematics at them.

The time to cross the playing surface at maximum specified (.06 static) coefficient of friction should be (assuming a 54 foot playing field minus robot, trailer and bumper… total length for acelleration should be about 15m) should be about 7.75 seconds, with a peak velocity of just under 4 m/s. Which is about 12 fps, which is considered fairly speedy for an FRC robot.

But then you hit the driver station bumper and stop.


I’m just wondering how were u able to get the value of 0.5m/s^2? are u simply taking (normal force* CoF)/mass? and than the normal force i’m guessing ur assuming maximum weight?

And yet Dave has stated that he has gone down the length of the field and back in 12 seconds. This would appear to be pretty solid evidence that the published coefficients are not correct and you should try to perform a test to determine the actual CoF to get the correct maximum acceleration.

I’ve laid out the steps we used here. When we did those calculations we assumed that the entire 36 pound weight of the trailer would be borne by the trailer wheels, which is not an entirely correct assumption, some of the trailer mass will contribute to normal force on the robot and thus improve traction a bit, but even if you run the numbers for just the robot (no trailer), it seems that FIRST has published a (I’ve been waiting to use this… sorry)… coefficient of fiction.


re-running the numbers without the trailer, or with 100% of the trailer weight on the tongue and contributing to the normal force of the robot, is should still take at least seven seconds each way… unless there is some great bouncy rebound off the end driver station wall. These calculations are also based on 100% regolith travel… Dave may have been using the carpet at the edge of the field to get up to speed. Perhaps we have been underestimating the influence that the carpeted boundary will have on the game. </Edit>

Limiting the commanded acceleration of your drive wheels can prevent wheel slippage - but ONLY in the absence of unaccounted external forces. If you are running into the arena walls and other robots, this assumption is no longer valid.

In other words, this type of traction control would not help in a pushing match.

This is how we’re doing it…

Your wheel speed is given by a magnetic rotation sensor (what controls your volume in your car). This is compared to to integrated accelerator value, over 20ms. Find the difference, correct the motor speed, use some ifs to determine if your driver is accelerating your decelerating. Then out put the correct speed of the robot to the wheel, plus a tiny fraction of acceleration energy, or none if you want to hold constant speed…

It will be interesting to see how teams do this. Plus it is so expensive to have a large enough field, I think so many teams will be in for a real hard time at their first regional.

I talked with our lead programmer about traction control last night…I think the plan is to use just the encoders to detect wheel spin, as a sudden increase in wheel speed, then back off power to get the wheel speed back to what it was before it spun, then ramp power up again till it spins, back off, etc. My guess is that spinning could be limited to a small part of a revolution, since the kit encoders have such high resolution.

Also…turning it off…the plan for now is to turn the steering wheel to turn traction control off. :slight_smile:

We’re basically using a two step process:

  1. Smoke
  2. Mirrors

We are planning to use an encoder wheel (omniwheel) with encoders attached to the gearboxes. Then the rotation of the shafts on the gearbox will be compared to the encoder wheel rotation. If they aren’t moving at the same speed then we know that we are slipping.

Another thing to think about though is that once you loose traction, the bot will need to slow the motors down past where it started to slip to regain traction. Its sort of a hysteresis effect because of the differences in the statics and kinetic coefficients of friction.

On our drive train, all four wheels are going to be powered their own motor. And then we are going to monitor the speed of the wheels with encoders. At the moment we are thinking that we going to monitor the speed of the robot with a another wheel that isn’t powered and monitored with another encoder. Our chassis should be done by tonight, we will see how all these things go.