.configOpenloopRamp does work. Be careful using it on the drive subsystem. Anything more than 0.2 seconds makes the robot harder to drive as the controls start to lag the driver inputs significantly. In particular, the open loop ramp rate cuts both ways, so when you tell the robot to stop, it will ramp down to zero making it keep driving for the duration of the ramp rate. If you’re using this to control robot acceleration, consider other options like more driver practice or nerfing drive controls.
Also, I’m not sure what interactions there are between .configOpenloopRamp and trajectory following autonomous. It may interfere with trajectory following setting its precise motor voltages.
Last year our 4 Falcon drive train and top heavy robot had a tendency to want to stand on its nose under hard stops and wheelie on hard acceleration. Our solution was to have our driver throw the robot into a sideways slide to stop, and be just a little bit easier on acceleration. Your mileage may vary.
I might be somewhat biased, but I suspect you’ll have better success using WPILib’s slew rate limiter. I’ve found that a rate of 3-4 units/second (assuming your drive control signal runs from -1 to 1) is a good place to start.
Arcade drive itself has problems with turns at high speed. Basically no matter what you do with multipliers, if you try a full speed forward and full turn, it’s going to turn less than at half speed forward. It’s really not good for the driving challenges. Are you using WPILib Differential Drive?
That’s a fundamental issue with any robot without omni-directional motion, not arcade drive itself.
To Op: Multiplying your axis by a constant to cap max speed is always going to be a disadvantage, because you are purposefully not using the full range of voltage available to you. Typically, one might fix this by changing the gear ratio of the drive train. For example, let your current top speed was 25 fps (feet per second) and your gear ration was 75:1. If you wanted your top speed to be 15 fps, then you need a gear ratio of 125:1. However, this will take time, so you have to weight the cons of taking the robot apart vs using a constant to chance the voltage.
I was talking about the sum of turn and forward being capped at 1, losing the ability to drive one side as fast as it should go. One solution to this is to scale down (divide) both wheel outputs by the larger of the two, which differentialdrive does in some schemes.
What you might try is using curvature drive instead. Arcade will get you moving, but it’s not easy to control in driving challenges like this year, because the turning is independent of the forward and backward.
DifferentialDrive.curvatureDrive acts more like a car. It does a few important things for controllability.
One, it scales up the turn to match the forward and backward speed, meaning that pushing the turn stick halfway one direction will make your robot drive the same circle regardless of how fast you are going. (That is, until your robot starts drifting).
The other thing it does is after the turn value and the forward backward value have been turned into wheel speeds for the sides of the drivebase, it scales both down like I was saying so that the speed ratio between the two sides stays correct.
Three, it has an option for a button to return to arcade drive when you really do need to turn in place.
We just started using it today and it’s already significantly easier to control.
Thanks， I will try to use it on our robot this week . But do l need to rewrite my drive program totally or do l just need to change the method to drive?
l can’t use .configPeakOutputForward to set the peak speed , and when l push the axis to max , the robot will still run at its fastest speed(1.0), so where’s the problem?