Hello, my team is trying to tune the trajectory following that we have in our auto and we are experiencing shuddering on our robot as it attempts to follow the trajectory even when all gains on our PID controllers are set to 0. It only does this when the Ramsete controller is enabled, however, and is super smooth as soon as we disable the controller. We have a tank drive drivetrain with a total of 4 Falcon 500s with 2 on each side. We triple checked our unit conversions that we have set up in our code and confirmed that they are very accurate for converting both position and velocity from Falcon encoder ticks to meters. We also recharacterized our robot countless times and it has not solved our problem. We have also gone through the WPILib troubleshooting doc for trajectory following extensively and no changes seemed to help besides disabling the Ramsete controller, which causes our paths to be inaccurate. We even went as far as to try and tune the Ramsete controller b and zeta gains and the kS, kV, and kA values from the characterization manually, but to no avail. Our code is linked below and some of the specific classes that we use to create the trajectories are in the RobotContainer.java, Drive.java, Constants.java, and Units.java classes. We feel as though we have exhausted most of the solutions we could find to this specific problem, so any help would be greatly appreciated!
Would you be able to send a video of the shuddering you’re seeing?
Check your max acceleration that you set for the paths, there is a chance that you are accelerating too quickly and triggering the Secondary Current Limit (stops motor for a couple milliseconds)
If that isn’t the issue, there is a chance that you are controlling the drivetrain with two commands at once, causing interrupting information to be sent at the same time, so double check the requirements of your ramsette command. But looking through your code, you seemed to do the requirements correctly.
Probably the best way to describe it is a bucking bronco, the front jumps up a little.
Unfortunately the entire programming group had to go finish their homework just now, but will be back tomorrow. (They’d get a lot more done if school didn’t get in the way.)
We had thought that originally too, but when we did have commands conflict like that, we saw vicious shuddering and the robot would barely move, but this seems like more of a tuning problem somewhere rather than that. We could definitely try lowering the acceleration once our team opens shop for tomorrow, though.
I’m not sure what your problem is, but here are a few suggestions of things to look at.
I know you said you still see this problem with feedback control disabled, but I’m a little concerned to see here that you might be using a negative P value.
public static final double kPDriveVel = 0; //-1.0001
This may not be your problem, but I think you would be better off setting up your motors as leader and follower (WPI_TalonFX.follow) rather than using MotorControllerGroup.
In the Drive subsystem, I see that you’re inverting the right motor controller groups, you’re negating both of the voltages in tankDriveVolts, and in various places you’re negating the left encoder. It’s better practice (and less error prone) to set up your inversions correctly on the controllers and encoders from the start, and not sprinkle your code with negations. Is your odometry tracking the robot position correctly?
We had a very similar problem, for us it turns out that when we were characterizing our robot we were setting one of the gear ratios incorrectly. The guided tips that are in that software make a suggestion which is something like “Standard Ratio is 1 52” which our team was reading as put 1 in the first box and 52 in the 2nd, so the ratio was 1:52. Turns out there was suppose to be a period between those so the real ratio they were suggesting was suppose to be 1:1.52. I assume their software IDE just didn’t like a non alpha numeric in the field so they did their best.
NOTE: I am guessing at the numbers above as I don’t have the software running in front of me. If this sounds remotely like it might be your issue some quick googling will steer you better.
That negative gain value was just a change we made briefly just to see if it would have an effect, but it didn’t change anything. Also yes, our odometry does track correctly, but we can change our subsystem to use motor controller following instead. I’ll send that video to show you exactly what our problem is tomorrow, too.
Hmmm that’s definitely interesting, we put our gearing in as a fraction that we calculated out from our gearbox gearing of (62.0 / 9.0) * (30.0 / 18.0). Our gearing is a bit strange, so it comes out to a bit of a weird gear ratio of 1860:162 from motor turns to external wheel turns, but we tested it for distance on our odometry and it is accurate. Maybe that could be our problem? Is it possible that the SysId program takes in the gear ratio in reverse, from external wheel turns to motor turns?
Here are some videos of our robot shuddering at two different accelerations. Adjusting the acceleration didn’t seem to help, but we also shifted our drivetrain to use motor controller following rather than MotorControllerGroups.
if you want your totally free to try and use our ramsette command for yourself. It’s MIT licensed so your free to just cut and paste, but i’m sure you can shape it around your robot.
This works perfectly for us, so if you try it you can eliminate the issue for yourself.
I also don’t know about falcons, but NEOs like to report velocity as RPM, and use minutes as their time unit, making the velocity report as 60x, causing those oscillations.
make sure to double check that your scaling your encoder units for position and velocity correctly.
That is a good point. Falcons report speed in encoder ticks per 100 ms, so we are already multiplying that reported value by 10 so that we can get the encoder ticks per second. Our conversion factors to meters per second are accurate too so we should be good on that end. We’ll try and implement your solution and see if it helps.
Thanks for posting the videos. By my estimation, the shuddering is on the order of about 3-4Hz. This suggests to me that it’s not two commands fighting (the typical error), but rather the control system introducing oscillations.
Again, this is probably not your problem, but looking at Drive,resetOdometry, you reset the IMU just before calling odometry.resetPosition with imu.getAngle. The documentation says “The gyroscope angle does not need to be reset here on the user’s robot code. The library automatically takes care of offsetting the gyro angle.” There’s a potential problem here if the IMU reset takes time and the getAngle returns a pre-reset value.
I’m still baffled here about what might be wrong with your code, but these threads have some useful ideas:
Sorry for the late reply, it’s been a bit of a crazy past two weeks with district champs and worlds. We tried everything that you guys suggested and we still had no luck. One thing that we did note is that the motors are in fact turning off completely when the shuddering happens, which also occurs at any speed. Since we’re at worlds at the moment, we’re just living with the oscillations until the season’s over before tackling the problem head on post-season. We’re just going to try making a bare-bones project with only a drivetrain subsystem and trajectory following to see if we can isolate the problem and incorporate all your suggestions. Thank you for all your help, this is a very weird issue so your help is much appreciated!
We also did try to take out the resetImu() call but the robot would still try to orient itself in the last recorded imu position and the shuddering did not get better so we just added it back in. That is definitely something for us to test more later on.
@Kyle10603 I am having the exact same problem you described in this thread. Have you by any chance had the time to look at it and find some clues since April?