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 kitfor $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.
*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.