Tank Driving

Hello, my driveteam after some experimenting, decided the previous season that they are most comfortable with driving using 2 joyticks, one to control the output of the right side and one to control the left side output.

We simply used the wpilib tankDrive method in the DifferentialDrive to get it working.

Although this method of driving was my drivers favorite, they still had some issues with it.
First of all it was hard for them to get the robot to drive straight since it’s hard to maintain both joysticks at the same y position not mentioning the slight difference in every drive train side input/output ratio.
Plus I have noticed that when the joystick value changes abruptly, the robot slightly wobbles before changing its output to the desired value.

What are the common ways to fix these problems?
And moreover, what other things should I implement in our code to give my drivers better and easier control over the drivetrain?

Fixing the straight driving is pretty simple: put a button on one of the joysticks that sets both drivetrain sides to the average of the two joystick values. When the driver wants to drive straight he can push the button and the robot will always drive straight. This of course assumes that the robot drives straight when the two drivetrain sides are given equal commands, but that’s a different a different topic altogether.

I’m not sure what the wobbling problem you’re describing is. Maybe you can give some more details of when it happens and what it looks like.

One more feature that I like to add is a button that slows down the drivetrain by a certain percentage (I like 60%). So when the driver presses the button and pushes the joysticks halfway forward, the drivetrain only moves with 30% power. This helps with fine positioning and lining up with field objects or game pieces.

Thanks, the slowing down button will probably help us.
About the wobbling issue, it happens when there is a big sudden change in the joystick value, for example, when the robot isn’t moving and then the driver slams the joystick forward, or when driving at a high speed and immediately stops, or even when trying to make a hard turn at a high speed.
I heard thar the ramp rate function in the talon srx should fix this problem but also seen teams limit the accelaration of the drivetrain, which method work better?

If this wobbling is accompanied by the Robot Safety Light dimming or quickly flashing, I think what you are seeing is a brownout caused by low battery voltage. If you can post a picture of the Driver Station log when this happens, we can tell you for sure.

If this is the case, there are a few ways to solve it. Current limits, voltage ramps, or averaging the last few joystick values (essentially a voltage ramp), will all help. The best solution is probably changing the gear ratio so that the robot has better acceleration and a lower top speed, but that’s probably not an option.

We also experienced the same problem. For a 4-CIM drive train, it seemed that if we allowed 1/2 second to go from full power reverse (-1) to full power forward (+1), that corrected it. So, we saved the previous time/power each pass, and if the next time/power exceeded that maximum increment, it was clipped to the max. Did not effect top speed, or cause weird tracking, but did eliminate the surge especially when changing motor direction.

We went with using the left stick for steering and right stick for throttle. This gave us better high speed swerving ability (much easier to keep the throttle pinned and use the other joystick to swerve). But that choice is always left to the drivers.

This is an example of the wobbling issue, maybe the I am using the wrong term to describe it, this is our 2017, I chose to show him rather then our 2018 robot since the 2018 robot is tall and can be turned over more easily and showing the short 2017 robot shows that the problem is related to the code.

This should probably fix my problem, but is this solution different from the talon srx config ramp rate function? Or maybe it should be used in addition to the ramp rate function?

The problem there appears to be that the robot accelerates too quickly. That combined with a drop center drivetrain gives the rocking motion.

Some solutions in the future would be using the Talon SRX’s ramp rate function, manually limiting the acceleration in code, averaging the last few joystick values to slow sharp transitions, keeping the center of gravity low, and/or getting rid of the drop center. You can also look into anti-tipping code if you end up with another tall robot that still rocks like this. I theory, adding the anti-tipping component to the manual driving component should act to dampen the rocking as the robot quickly accelerates.

First of all thanks for the help :),
That robot in the video doesn’t have a drop center drivetrain, so i’m guessing it’s just an acceleration problem.
To solve this problem would you say that the right usage of the Talon SRX’s ramp rate function should do the trick? Or should I add to it something of my own like manually limiting the acceleration in code or averaging the last few joystick values…

Not sure if this is related to your oscillation or not, but I’ll throw it out there to fuel conjecture:

The only robot I’ve ever seen rocking/swaying on hard acceleration was 3946’s 2013 Ultimate Ascent robot. Most unfortunately, this 4 wheel contraption was only driven by its front wheels; the rear wheels were idle omnis. Curiously, the oscillation was only noted when the robot was accelerating forward (front wheel drive, where the fraction of the robot weight supported by driven wheels was reduced during acceleration); the driver determined that it was much more stable if driven across the field in reverse (rear wheel drive, in which the fraction of robot weight supported by driven wheels was increased during acceleration).