Implementing Traction Control for an advantage in the 2009 game

[DonRotolo]

I think I can safely say that the robot with the best ability to move around will have an advantage this year. One way to do that is to maximize traction. A slipping wheel provides no traction (at least at certain high slip values)

In looking at this graph (scroll down to see the graph) we see that on a certain surface* a certain amount of slip provides optimal traction while maintaining stability. This is the principle behind Anti-Lock Brakes and other traction control systems.

If we then conclude that traction control can be superior to excessive acceleration**, we now have a few issues to manage before we can implement that in software.

The purpose of this thread is to share knowledge and ideas on how to implement this, especially since automotive engineers probably know a lot more about this - and can help their teams more - than others, who can and should benefit from this expertise.

Anti-Lock Braking Systems (ABS) work on the principle that a wheel can only slow down at a maximum rate, and once it exceeds that rate it is "locking up". ABS is implemented without knowing the coefficient of friction or vehicle speed by finding the slope (differential) of the wheel speed. Once that slope (rate of change) exceeds a certain experimentally-derived value, the wheel is Locking Up and actions are taken to reduce the braking force upon that wheel.

Acceleration Slip Regulation (ASR) is different, and is probably more of what we need to implement in this year's game. ASR works by measuring the slip due to acceleration, comparing the actual speed of the driven wheels to the undriven wheels, reducing throttle input*** if driven wheel speed exceeds that of undriven wheel speed by some value (perhaps 20%).

The graph mentioned shows 20% to be the magic number for dry pavement and rubber tires****.

The first problem is to measure the speed of each wheel. This is moot if all wheels on a side are driven by a single motor, since they all are at the same speed, so the first requirement seems to be that each wheel needs its own motor (although an 8 wheel drive may be possible, 2 wheels off one motor). The encoders provided are OK, but may also be overkill at 300 pulses per revolution (most ABS systems have 48 or 96).

The second problem is to measure the actual vehicle speed. In a car, just use the undriven wheels, but in a robot, usually there is no undriven wheel. In this case, one can mount an undriven 'fifth' wheel for this purpose, perhaps using a caster type mounting system (if you want to detect sideways travel). One post mentioned using an optical mouse - my MS optical mouse seems pretty reliable at 1/16" off the desk surface, but it would probably get quickly dirty on a FIRST field. Trains use acceleration control for optimal traction, and they sense vehicle speed using radar (essentially a traffic radar gun - Ramsey Electronics sells a kit for $60)). I wonder which might be best here.

The next problem is motor speed control. Cars usually work at 15 to 30 Hz, due to limits of their mechanical systems. The new Jaguars can adjust their outputs a lot faster than that. The control system can keep up with it, too, but can the motors? Can a PID loop be implemented that gets a new setpoint every 1/60th of a second?

This being a somewhat deep issue, any and all comments are welcome, since we never know which tidbit will be the important one.

Don

*The curve changes a little for different surfaces, mostly flattening as mu decreases, but the principle remains. One notable difference, not relevant here, is on loose surfaces such as gravel.

**This also applies to excessive negative acceleration, also known as braking.

***Some systems also apply braking to a single slipping wheel, but in FIRST we can limit ourselves to a single response.

**** This is not stated anywhere, but I know it to be true from my experience with these systems.

.

[MrForbes]

The first thing that came to mind was that the coefficients of static and dynamic friction for rubber tires on pavement seem to be more different than they are for the robot wheels on regolith. That means we don't have as much to gain as car designers do. I'm not rtying to dissuade anyone from working on this, though.

Also with a typical skid steer 4 wheel drive, the front and rear wheels on each side will be slipping the same amount in the driving direction, because they are turning at the same speed, and they are on the same surface, and the stay the same distance apart. So, there seems to be no need to worry about sensing the speed of each wheel, only the speed of each set of commonly driven wheels. This concept is used in older automotive ABS also, note you'll find only one speed sensor on the rear axle of 80s pickup trucks with primitive ABS.

[sbrumund]

It is relatively simple to limit the rates of acceleation and turning in the programming as opposed to monitoring wheel speed to look for slippage.

With this approach you would need to test the robot on the surface and adjust the limits in the program.

Any traction control system will require some getting used to.

[TheOtherGuy]

You mentioned using a caster for figuring out the actual velocity of the robot; another possible way to do this is with the accelerometer. Before kick-off we designed a quick inertial positioning system using an accelerometer and gyro based off of 111's system back in '04 (I think it was '04...). Using some trivial physics you can use a loop to keep track of your actual velocity and position. Now, we haven't actually messed around with an accelerometer at any point in our history, so I don't exactly know how accurate these are, but that was our first take on traction control.

[Adam Y.]

The next problem is motor speed control. Cars usually work at 15 to 30 Hz, due to limits of their mechanical systems. The new Jaguars can adjust their outputs a lot faster than that. The control system can keep up with it, too, but can the motors? Can a PID loop be implemented that gets a new setpoint every 1/60th of a second?

You might not want to implement a PID loop depending on what you are trying to accomplish with the drive train. Using a ramp instead of a step input is ideally what we want. The problem is that it changes the system type that you need (Read: How many integrators you need) to achieve a specific amount of steady state error.. I actually have to go over the dynamics of a basic gear train (Read: How many integrators you start out with) but the worst case scenario is that you have to integrate at least once to get a system that doesn't give an steady state error that blows off to infinity and twice to get zero steady state error.

[DonRotolo]

Originally Posted by sbrumund

It is relatively simple to limit the rates of acceleation and turning in the programming as opposed to monitoring wheel speed to look for slippage.

With this approach you would need to test the robot on the surface and adjust the limits in the program.

Agreed, an empirical approach would probably be effective, even if the testing surface differed from the actual surface (simply adjust one parameter).

However my goal is to show these kids an engineering approach. Someone once said that the difference between an engineer and a tinkerer is that the engineer can calculate the results beforehand.

This assumes that 6 weeks is enough, of course.

[Otaku]

What you could do is use optical encoders with optical encoder wheels on two kinds of wheels -- driven and not -- then take the data from both and make a table that you can use to program the TCS with. Drive the robot on a surface as close to regolith that you can.

Or, you could program it so each wheel has an optical encoder, each side independent, but tell the code that when the non-driven right-side wheel's speed value and the driven right-side wheel's speed value don't match, to slow down the motor until they do and keep it there, in the traction zone.

this assumes, of course, the use of extra optical encoders on non-drive wheels, which would require a drive system with possibly extraneous wheels. But if the bot's 2wd with four wheels, it'd work.

[King Duke]

CAN interface on jaguar motor controller, allows for reading the current and voltage. Wouldn't these spike when the wheel loses traction?

[d235j]

Originally Posted by King Duke

CAN interface on jaguar motor controller, allows for reading the current and voltage. Wouldn't these spike when the wheel loses traction?

The CAN interface is not FRC-legal for 2009.

[Blair Frank]

What about using analog current sensors? Would that work, and provide the same functionality as the CAN interface?

[DonRotolo]

Originally Posted by Otaku

What you could do is use optical encoders with optical encoder wheels on two kinds of wheels -- driven and not -- then take the data from both

Absolutely, but at this time we are planning on six driven wheels and none undriven. I mentiojned that in the intiial post: "but in a robot, usually there is no undriven wheel."

Originally Posted by Blair Frank

What about using analog current sensors? Would that work, and provide the same functionality as the CAN interface?

Good idea Blair - you'd need to compare the measured current AND voltage and then compare it to what was being commanded to the Jaguar (i.e., the PWM value), but this may be simpler in some cases than using wheel encoders - and probably a lot less expensive as well.

Why not just current? Because motor output is not directly proportional to only current if the robot can be acted upon by external forces - like a robot slamming into you. The current should remain the same for a given wheel speed so long as you are slipping above a certain factor, but get below that slip threshold and it gets nonlinear. Measure power (Power = current * voltage) and you can be sure all the time.

[cgredalertcc]

I don't know that there is any team out there quite up to the level of programming, prototyping, testing, and time management skills this might require, but I had a thought and I figured I would put it out there. In watching my favorite car show, Top Gear, I saw the track test for the Nissan GTR. The GTR uses a myriad of sensors to analyze the car's current situation in comparison to predetermined targets. If the car gets outside those boundaries the electronic system appropriately routes power and there by keeps the car constantly in control, while allowing a significant amount of freedom in terms of aggressive driving and cornering. I have no doubt a similar system would be possible for this game, but I am sure it would require a great deal of time and testing. Any thoughts.

[DonRotolo]

You seem to be describing what I call ESP. Certainly there are teams up to this, and we have the sensors necessary. It is a bit more ambitious that i think our team wants to bem but good suggestion, I'll bring it up. The advnatage is that you also get the robot working to give you directional controls, not just acceleration.

[cgredalertcc]

I didn't really make my suggestion clear in re-reading my post. I guess the most difficult part of the system I'm describing is obtaining the data to know what those predetermined targets should be. I was contemplating the idea of obtaining them with a robot using a relatively standard kit wheel of similar diameter from previous years, because the rover wheels aren't going to provide accurate driving targets, even off of the Regolith.

[DadDean]

I’m thinking two things,
1st by the time you have drive control your robot is going to be hit by another and be out of control.
2nd Optics - Optical encoders on the wheels and optical mouse to senses floor movement. The mouse may need modifying so it will work a few inches off the floor. I will be a cool thing for the programs to work on.

I think this game is going to fun to build, play, and watch