EASY traction control?

[RoboMaster]

One of our programmers is a wicked smart calculus and programming guy and he rigged up this monster program (at least to me) that would decreace the speed of a wheel if it was slipping, therefore giving it more traction (we have four wheel drive). I don't know the details, but he took the PMW signal that we were sending to the motor and figured out how fast the wheel should be going. Then, using the encoders that we installed on our gearboxes (which are basicaly rotation sensors), we figured out the actual speed of the wheel. We compared those two values and if the wheel was going faster than it should, it must be slipping, so we reduced the power to that wheel. (the code is a lot more complicating than that, though (it's LabVIEW, by the way))

We also have a system that has been previously mentioned, where instead of powering the wheels at the exact speed that the joystick is telling them to run, the code just increaces the speed of the wheel incrementally if the joystick-user wants to go faster/slower. We call this our acceleration control system.

But actually, I personally find the acceleration control stated above bad. Because the robot speeds up and slows down slowly, the turning and stopping is delayed and effectivly the robot's reaction time is slow. This was very cumbersome and most of the time people on our team were just constanly holding down a button that we had programmed which would turn off this feature and we would just drive carefully.

I have thought about keeping our traction control system, but re-doing our acceleration control system. Since mostly we were just driving carefully and slowly, we could simply divide the joystick value by 2 (or something) and then our robot would drive slower and we would have more control. In many games, and especially in 2009, drivers are manuvering precisely and this control is a giant benifit. If you did need to go fast (like you were trying to sprint down to the end of the field), then one could hold down/push a joystick button and the motors would use the actual joystick values and would not divide them by 2.

So that's my input, see what you think. To restate, I think the incremental acceleration control has merit, but after trying it out on a robot, I found it to be cumbersome because of the slow response time of the robot and would have rather liked to have had a slower robot that therefore had more control.

Whew, what an essay!

[biojae]

What 399 did was a simple open loop system. We took the joystick value and cubed it. this makes the values non-linear and has some deadband in the motors. The drivers have more control over the speed in the low traction environment.

[ComradeNikolai]

Originally Posted by RoboMaster

But actually, I personally find the acceleration control stated above bad. Because the robot speeds up and slows down slowly, the turning and stopping is delayed and effectivly the robot's reaction time is slow. This was very cumbersome and most of the time people on our team were just constanly holding down a button that we had programmed which would turn off this feature and we would just drive carefully.

During our driver tryout period, most of them experienced the same problem, so I switched the traction control from automatically enabled to automatically disabled. It works well for accelerating and smooth curves when you're not colliding into other robots but, once you hit something, the system gets thrown off. Personally, I found it splendid to use until it was thrown off (and when I drove, I used it often, for what it was designed for), but our other drivers had other preferences.

Having a disable/enable feature is a good idea.