Smoother Tank-Drive Driving

Hi,

While driving at our last event, we’ve noticed that our drive is very “jittery” and that the driver is having a hard time making small adjustments, in comparison to other teams. See this game - we’re 4338. We’re using 8x 6" wheel drive (with four wheels slightly elevated) and the program is a cubic polynomial from XBoxControllers. Is there anything in the program that we can do to improve the driving? It was suggested that we try a logistic curve instead of cubic, what do you think? Do you have other ideas?

Thanks,
Orian Leitersdorf

Edit: Forgot to mention that we’re using 6 Spark Max Drive with Brake Mode enabled. Do you think we should try coast?

Switching to coast mode will make the robot less twitchy*, but not necessarily easier to control. You can try adjusting your cubic joystick transformation to give you a bigger low-power zone around zero. Perhaps even use two different curves depending on whether you’re driving normally (both wheels in the same direction) or turning “in place” (wheels in opposite directions).

In my opinion though, the thing that will help most though is just more driver practice. I don’t know if you build a practice robot or have a field carpet to drive around on, but the more time your driver gets with the robot the more comfortable he’ll be. Even if you have a similar drive base without all of the manipulators you can practice lining up with, it’ll help immensely. You’re welcome to reach out to 5987 in Haifa if you need a place to practice, though I expect there are some teams closer to you that will also be willing to share their practice space without the hour drive.

* In that it will decelerate slower when you’re commanding the motors to zero. If your driver/code is actively providing opposite voltage to stop the robot faster, switching to coast won’t help at all and I’d recommend fixing that instead.

3 Likes

Well, we’ve had the driver on the stick all of yesterday with our practice robot on our practice field with the carpet and I didn’t see much improvement—we see the exact same behavior with the practice robot. I’ll try your suggestions with changing the curve today and will update the results here.

Thanks for the offer.

Use joysticks instead of Xbox controllers.

4 Likes

Probably too late for that…

Also, I don’t think that’s the problem. We have a previous year robot that was 8x 6" wheels with 4 omni and 4 traction, there we have literal 6yr old drivers (during PR events) drive the robot smoother than what our driver can do with this year’s robot… I suspect it has something to do with us having 4 raised wheels this year, too late to change that too though…

Do you think that the raised wheels could be the problem? If it is, any suggestions?

Is tank drive the issue? Or are the wheels just gripping too much carpet?
You can experiment with two joystick arcade drive: one joystick only uses the y-axis for forward/backward drive, the other uses only the x-axis for rotation/turning. See if that helps.

Most likely you just have too much grip on the four wheels which are very close together. If you have omni wheels available, try swapping them in for the center wheels to see if the problem persists.

That’s already the setup we have…

Wouldn’t Omni-only drive results in us getting pushed very easily though? Edit: What if we only replaced 2/4 of the center wheels with Omni? Would that be a balance between getting pushed and turning?

I strongly recommend trying a slew limiter on your joystick inputs.

1 Like

How do you think we should implement that? In the Spark-Max ramps or on the roborio?

The idea that a higher-order polynomial makes fine control easier is only true up to a point.

What a higher-order polynomial scaling does is devote a larger portion of the joystick throw to a smaller portion of the output. The higher the order of the polynomial, the more drastic the effect. This can have the effect of making fine control more easily - but it is a complicated effect. If we look at the limiting behavior of x^n polynomial scaling as n -> infinity, we see that the logical end-case is a joystick sensitivity where the robot does not respond at all to any input except for max, at which it suddenly jumps to max speed. This clearly does not improve controllability.

So, there’s something of a “sweet spot” with polynomial scaling - too little, and you’re wasting joystick throw on speeds that you don’t really care about controlling. Too much, and you can’t control the thing at all. I’m hesitant to say pure cubic control is definitively outside of that zone, but it’s definitely butting up against the boundaries (for reference, our team uses .5x + .5x^3, a scheme suggested years ago by the inimitable @Ether ).

This problem is potentially exacerbated by the presence of deadband - since higher-order polynomial scaling crunches small inputs down to significantly smaller inputs, if deadband handling is not done carefully it can result in one losing small inputs entirely. This can be due to either poor deadband handling in code (e.g. naively deadbanding the joystick value after applying scaling; for higher-order polynomials this effect can be shockingly large - a 5% deadband applied in this way to cubic scaling discards all input up to ~37% of the joystick’s total throw), or to the natural “mechanical” deadband present in all robot drives due to friction. The “proper” deadbanding solution is to deadband joystick inputs before applying any scaling function, and also add a constant friction compensation term (being careful to match the sign to the direction) to one’s outputs. This is not common behavior in most FRC drive code I’ve seen, unfortunately.

So, to sum up: You will likely see improvements by reducing the order of your polynomial scaling (there’s a reason so many teams default to quadratic). You will also likely see improvements if you improve your deadbanding. You cannot simply assume that a higher-order polynomial gives you greater controllability at low speeds.

2 Likes

Our team has been using tank drive for a very long time, and we have experimented with various controllers but we have stuck to joysticks because of the ability to make more precise movements (this is very valuable for tank drive robots). I don’t suggests you don’t use game controllers but I do suggest you try a joystick because it could be the change you are looking for. Here is a link to the one we use: Thrustmaser T16000M FCS https://g.co/kgs/XQqhNG

Nobody has yet mentioned gearing.

You’re probably geared too fast.

More speed reduction in your gearbox would solve your fine-control problem.

Or use a shifting gearbox and use low gear for fine control.

2 Likes

We already have a shifting gearbox: 3 CIM Ball Shifter by Vex Robotics. Not sure about the exact ratios but I could check.

wait, just to get this straight, is this about the scaling of the joystick inputs for driving? What are the issues with linear conversion of joystick to motor output (input = output)?

Also check if the gearboxes are indeed in low gear when you’re having trouble making the fine-control adjustments.

.

1 Like

There’s no “problem” with it. As described in my post, scaling the joysticks differently can map a larger portion of the joystick throw to a smaller portion of the robot’s max speed. This often makes sense, because we often care more about the difference between, say, 10% and 20% speed, than we do about the difference between 80% and 90%.

Squaring the joystick inputs is a common “quick and dirty” way to accomplish this; it maps the first 50% of the joystick throw to only the bottom 25% of robot speed, which can make precise maneuvers easier to accomplish.

It is worth noting that the WPILib drive objects do this by default, so you may be doing it even if you are not aware of it.

2 Likes

Did you mean to say “map a smaller portion of the joystick throw to a larger portion of the robot’s max speed” ?

.

No. It clearly does do that, too (a canonical joystick scaling function maps [0,1] -> [0,1], so it’s impossible to do either one without also doing the other) - but the bit we generally care about is widening the range of joystick inputs that corresponds to low speeds, not compressing the range that corresponds to high speeds.

What do you mean “jittery”? Does this mean it jumps when turning? Or is it more like when you try to turn slightly it barely moves, and then moves too much? I’m asking based on experience here lol.

Understood.

But you said

…scaling the joysticks differently can map a larger portion of the joystick throw to a smaller portion of the robot’s max speed. This often makes sense, because we often care more about the difference between, say, 10% and 20% speed, than we do about the difference between 80% and 90%.

Mapping a larger portion of the joystick throw to a smaller portion of the robot’s max speed (as quoted above) leaves less throw for low speeds.

So it seems like what you meant was

…scaling the joysticks differently can map a larger portion of the joystick throw to a smaller portion of the robot’s low speeds. This often makes sense, because we often care more about the difference between, say, 10% and 20% speed, than we do about the difference between 80% and 90%.

Or perhaps I’m missing something.