Driving and "Traction controls"

[willferral]

I need some suggestions. Here is our problem: We designed our robot with a simple four-wheel drive system, skid-steering. We tested the original robot with a relatively slow gear system, and could go about 6ft/sec. We tested our robot early on without any "traction controls." It was easy to drive, and very maneuverable.
http://www.youtube.com/watch?v=asyMu...eature=related Then we changed two things. One, we geared up to 9 ft/sec. Two, we added traction control. Now the robot is very hard to drive. To me the driver, it feels like there is a "delay" in the system. Our programmer had good intentions by putting a traction control system in, but it make the robot intolerable to drive. How did your teams solve the control conundrum? Any suggestions for us? Thanks!

[Bongle]

Originally Posted by willferral

I need some suggestions. Here is our problem: We designed our robot with a simple four-wheel drive system, skid-steering. We tested the original robot with a relatively slow gear system, and could go about 6ft/sec. We tested our robot early on without any "traction controls." It was easy to drive, and very maneuverable.
http://www.youtube.com/watch?v=asyMu...eature=related Then we changed two things. One, we geared up to 9 ft/sec. Two, we added traction control. Now the robot is very hard to drive. To me the driver, it feels like there is a "delay" in the system. Our programmer had good intentions by putting a traction control system in, but it make the robot intolerable to drive. How did your teams solve the control conundrum? Any suggestions for us? Thanks!

You've got a bunch of options:
1) Make a better traction control system. There are many options that allow for quick control. One of the ones posted (by 121 I believe) had encoders mounted on free-spinning wheels, one on each side. The driven wheels would then be set to have velocities either slightly higher or slightly lower (depending on what you wanted to do) than the free-spinning wheels.
2) Have it only enable when a button is pressed, or don't use it at all. This allows the driver to drive in 'raw' mode most of the time, then use traction control when quick acceleration is needed. As a programmer I never like this solution because it means my hard work will go unused most of the time, but from a practical standpoint: if the robot performs better without it, then don't use it. I have seen many matches go wasted because a robot just wants to use its ineffective mechanism or programming when it could have been better spent doing less glamorous tasks. If it comes down to it, face reality and say "hey, this doesn't work. We can work on it in the off-season to make it work, but for now we'd be better off pushing balls"
3) Take your current system and tweak, tweak tweak.

[nathanww]

To me the driver, it feels like there is a "delay" in the system.

Not to go too much into technical discussion, but the delay you're noticing is likely due to the physics of the playing field. Essentially, high responsiveness=large,sudden changes in motor speed=slipping=decreased responsiveness. The job of the traction control system is to keep manuevering within the envelope where it is not slipping. If tuned correctly, this will mean that overall maneuverability and acceleration is increased, but if it is overzealous the reverse might be true.

There are many options that allow for quick control. One of the ones posted (by 121 I believe) had encoders mounted on free-spinning wheels, one on each side.

Actually, a purely closed-loop traction control can be quite slow because you have to wait for enough data to come in. Otherwise, you might be dealing with a situation where, say, a motor encoder has registered 1 tick and a follower has registered 0. If you don't wait for enough data, this will indicate that you're operating at 0% efficiency. The technique that we're using to correct this problem is a "hybrid" approach--a basic ramping system limits acceleration to somewhat reasonable values while we wait for an average from an accelerometer.

Have it only enable when a button is pressed, or don't use it at all. This allows the driver to drive in 'raw' mode most of the time, then use traction control when quick acceleration is needed.

I would be extremely cautious about doing this, because

1. Functionality of the robot != responsiveness to commands. The cRio is capable of making tactical descisions in the time it takes a human driver to blink. With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa
2. 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"

[AmoryG]

Originally Posted by willferral

I need some suggestions. Here is our problem: We designed our robot with a simple four-wheel drive system, skid-steering. We tested the original robot with a relatively slow gear system, and could go about 6ft/sec. We tested our robot early on without any "traction controls." It was easy to drive, and very maneuverable.
http://www.youtube.com/watch?v=asyMu...eature=related Then we changed two things. One, we geared up to 9 ft/sec. Two, we added traction control. Now the robot is very hard to drive. To me the driver, it feels like there is a "delay" in the system. Our programmer had good intentions by putting a traction control system in, but it make the robot intolerable to drive. How did your teams solve the control conundrum? Any suggestions for us? Thanks!

Well, first could you tell us how you're doing traction control?

[Lil' Lavery]

Originally Posted by nathanww

I would be extremely cautious about doing this, because

1. Functionality of the robot != responsiveness to commands. The cRio is capable of making tactical descisions in the time it takes a human driver to blink. With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa
2. 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"

That's only true if the robot is A) programmed correctly, and B) the programming is actually advantageous to your strategy.
Beyond that, it may just be a difference in design philosophy, but I always want my driver to have the ability to override my robot. There's no way to predict every potential situation on the field, and as such, there's now way to program every potential reaction into your robot. Sometimes a human (preferably very well trained) is needed to react in the proper way.

[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.

[ZakuAce]

This is interesting. We never did have enough time for anyone but the programmers to test our traction control on the real robot, and we ran out of money to build a second one. I know our programmers made it so we can't accelerate/decelerate faster than 1.9ft/sec, so it will be sluggish but won't slip. I'm pretty sure they do NOT want a manual override, but I don't think any of them are going to be the competition driver. Ah, dilemmas!

[AmoryG]

When your robot turns, does it slow one side of the wheels down or speed one side of the wheel up? So in a tank drive you have say 4 wheels two on each side:

|                |

|                |

To turn right you either need the left side of the wheels turning faster than the right:

f 
a
s
t

|                |

|                |

Or turning the wheels on the right side slower than the wheels on the left:

                  s
                  l
                  o
                  w

|                |

|                |

I think usually in traction control, if the robot's wheels are spinning faster than the robot is moving, the speed on wheels will be limited. If when turning you increasing the speed of one side of the wheels your traction control might be reducing their speed making the turn of your robot appear delayed.

[ay2b]

Originally Posted by nathanww

we discovered that our drivers thought process was something like "robot acting odd->mash buttons"

It's amazing how many drivers think that way! Fortunately, with enough practice most drivers can be trained out of that. The trick, of course, is to be able to find a way for them to get that practice before the actual competition.

[willferral]

The discussion has been very enlightening on the subject of programing. I don't want to discourage further program suggestions because our programmer is considering what you all have to say, but what do you all think about the idea of speed as it relates to what I am still calling "delay." If our traction control program sets a locked rate at which our robot can accelerate, then gearing it down (theoretically) won't matter. So in all of your minds, is it worth it to have the high speed capabilities? I already know that without traction control and lower gear ratios, the robot drives great. What speeds are your robots running at, and how well would you say it drives?