Driving and "Traction controls"

[Bongle]

Originally Posted by nathanww

I would be extremely cautious about doing this, because

1. Similar to this, making an effective descision to disable a TC system requires understanding at a low level of what is going wrong with the system. If you think that you can do that with the robot 50ft away from you, on a competition floor, while driving, in about 10 seconds, that's great, but otherwise it's likely that mucking about with the robot's programmatic internals on the field will do more harm than good(our original plan was to have a system to essentially fix common problems that might come up with the robot from our OI, but we scrapped this after we discovered that our drivers thought process was something like "robot acting odd->mash buttons"

Making an effective decision is easy: "the robot isn't doing what I tell it to in a timely fashion, switching to manual override". They don't need to understand WHAT is going wrong, simply that something is.

I'd be extremely cautious about NOT having a manual override, because by not having a manual override, you're essentially saying: "my control software is perfect and can deal with all situations". I've had many situations where the robot or the program got into a state either through malfunction, damage, or human error (driver, mechanical, or programmatic) that the control software was not able to deal with. At that point, you want the ability to directly drive individual motors and solenoids. You may be less effective than the cRio in an ideal situation, but if the code on the cRio has a bug or a sensor is malfunctioning, being worse than ideal is better than not moving at all.

With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa

Sure, which is why you'd have the traction control button pressed when you want it, and not pressed when you don't. Or you'd have it on all the time and allow the driver to press a button if they need to execute a maneuver that it wouldn't permit. Full-time traction control and stability systems do actually remove the ability to do certain maneuvers, and there are times when it is legitimate to want them off.

The main point I was trying to make was this: if you're not capable of making a useful full-time traction control system, then be honest with yourself, and make a simpler one that works in a subset of situations. We spent two weeks trying to get a full-time closed-loop system working, and failed. So we moved to a much simpler system that works in nearly all of the situations the more complicated one worked in. It is less buggy, less susceptible to sensor failure, and easier to debug and maintain. Of course a fully-tested, well-implemented full-time system would be preferable to what we have, but a buggy full-time system that we forced the driver to use at all times would be far worse than no traction control at all.
------------------------------------
Back on topic:
Another potential source of delay is simply too much strain on the cRio. Several times during our development we wrote code that simply did too much in a single cycle, resulting in 0.5-1.0 second delays. Doing large printfs or running camera code every loop are examples of things that can put a large delay in the robot. If you're using windriver, use the GetFPGATime function to get an idea of how long each loop is taking. It should take very small (< 0.01 sec) amounts of time per loop. Note that GetFPGATime returns microseconds.