So this is a very naïve and open question from which I hope to receive educational responses: how do some teams make their robot drive really smooth? The essential issue I deal with is that when you apply no max acceleration to your robot and you stop suddenly (especially if your robot is tall) the robot will tip over (or be very close to doing so). On the other hand, if you do provide a max acceleration, then the robot won’t stop when you want it to and it will ram into something. Yet there are a lot of teams, especially the historically well-performing teams, that seem to have really fast robots yet they move in a very smooth and controlled manner. Is this a characteristic of swerve (though I did see some pretty smooth-driving robots that didn’t have a swerve drive), or is it driver skill, or is it a goldilocks value for their max acceleration, or is it some variable max acceleration that depends on the current speed of the robot, or something completely different? (If this question has already been answered, feel free to point me to the discussion). Thank you!
Generally really good teams have low centers of gravity, skilled drivers, and current limits on acceleration. I’m not sure how they handle deceleration other than CG though.
You can swap around driver skill and code all day long, pretty much every team handles it differently. We just applied a cube function apparently just nothing to the joystick inputs and that fed straight to the drive controllers.
Much like a car, setting limits can be a good or bad thing depending on the driver.
This is built into the wpilib DifferentialDrive.arcadeDrive(double x, double y, boolean squaredInputs) method.
Who needs that when you run dual stick tank drive 
- Slew Rate Limiting has been the “secret sauce” for us this year. When it is on, robot drives like butter, when it isn’t, robot is tippy.
- Driver practice. It’s the answer I’m sure you don’t want to hear but I have to put it here because it works so well.
How do you decide what limit to set for the slewratelimiter?
Guess and check. I think we started with a value of 3.5, removed it for a few comps, then added it back with a value of 6 for worlds. From what my students and I understand, the quickest way to define it is ‘maximum change in velocity allowed’, so generally a higher number is less restrictive.
A few settings you could adjust to arrive at a good solution:
-
Coast/Brake mode on your motor controllers. For our tank drives, we typically have 1 motor per side on brake mode and the rest on coast, as this seems to produce desirable balance of abrupt vs. latent stopping. Haven’t worked on swerve since 2010/2011, but I’d give diagonally opposite drive motors in brake and the other 2 in coast a try if I wanted to explore this with swerve.
-
Ramp rate on motor controller output changes. Careful here, as too gradual of a ramp rate can introduce lag for the driver.
-
Current limiting, which might have differential effect on starting versus stopping.
Whatever you choose to do after testing the effects of the above settings, the most important thing will be plenty of drive practice. Make sure both your tuning of your motor controller/code parameters and your drive practice is on carpet like would be used in competition to have the most representative environment for testing and practice for what the robot will experience in competition.
I’ll try it! thx!
The limit is in input units per second, so if it’s on your joystick and you say 2, it will allow you to go from 0 to 2 in one second, but will not allow you to go any more than that. Because the joystick caps at 1, this is basically “0 to full in 1/N second” and then N is the number you put in.
The number one thing to do there is to set your current limits so your driver can’t break the tires free… Saves lots of brownout woes.
I’ve fought (and lost) for two years to get the kids to use acceleration/deceleration limits. They finally implemented them and were really happy with it!
I’ve asked if they kids could use the accelerometer/gyro to do self-stabilization… Not critical this year, but in a tall bot year making the bot pay attention to tilt would be a major advantage!
I think that unless you are willing to “drive under” a tipping robot (Segway-esque inverted pendulum stability), by the time you detect the tipping, it is probably too late.
I think the better solution would be to limit the amount of turning available to the driver as a function of speed. If they are going slow, they can turn fast. But if they are going fast, their turning is limited to prevent tipping to the side. Tipping over forward or backward is best prevented with acceleration and deceleration limits which could also be adjusted based on the rate of turning that is being commanded at the same time (such that the sum of the forward acceleration vector and the lateral acceleration vector does not exceed a stability limit).
Segway-esque is -exactly- what I’m getting at! Bonus points for actually driving on two wheels to show off 
Limiting turning and accell/deccel is a MUCH simpler way to get at this. Plus, there’s also the big challenge of telling the difference between sloping parts of the field and the bot falling over.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.