FRC Characterization + RamseteCommand causing oscillation around setpoint

I ran the characterization tool and got these values:

kS = 0.789
kV = 0.439
kA = 0.0705
kP = 0.439

Following the WPILib docs to follow a PathWeaver trajectory, I’m creating and returning a RamseteCommand. The desired path is a simple 5-feet-forward.

When I run the autonomous, the robt gets to the five feet mark and then starts oscillating endlessly, going forward, then backward, then forward, etc.

I ran two trials, one with a 5-foot-forward PathWeaver trajectory, and another 5-foot-forward trajectory generated in code. The behavior is the same. I also set kP to 0; it gets to the setpoint slower, but it still exhibits the same behavior, oscillating around setpoint.

My guess is that it’s just the constants, kS kV kA, that are off. My question is, how would it be off? Everything went fine in the characterization process. If they don’t seem to be off, what could be wrong?

According to WPILib docs,

A good test for this is to calculate the “theoretical” value of kV , which is 12 volts divided by the theoretical free speed of your drivetrain

The max speed of our robot is 3.896 m/s. 12 divided by 3.896 is 3.08, which is FAR from my current kV of 0.439. Something up with that?

It may or may not be important to mention that while doing the Dynamic Forward/Backward test, I changed Dynamic Step Voltage from 6V to 3V simply because the robot was going way too fast.

Is your code available online? I don’t think this problem is caused by your characterization values.

This sounds like your Pose that you’re feeding back into the RamseteCommand is incorrect. Check your units on your encoders.

Please make sure you’re on wpilibTraj branch!

I will take a look, I didn’t even think of that. Thanks.

Update: It seems like everything is fine, I convert sensor ticks (using Falcon 500s) to meters, and it feeds into odometry.update(). If the units were off, wouldn’t the robot not get anywhere near 5 feet? It gets perfectly to five feet but then just starts oscillating around it.

Well, if your units were off, your ramsete controller would be trying to correct your over/undershoots and oscillation could very well occur.

But your code for your pose looks pretty okay. I’d still suggest logging your pose to the console just so you can understand what the controller is receiving and basing its outputs on. As well as logging the voltage commands the controller is sending. Basically getting a picture for how your ramsete is turning your inputs into outputs.

I’m not seeing any issues in your code though. So more information may be required

Can you run trajectory.getTotalTimeSeconds() that is how long the motion should last. Is that in line with what you are seeing?

Pose is reaching 1.48 meters, so that’s pretty on par with 5 feet. Voltage commands are oscillating between 1.25V and -1.25V. I have no idea what else to do, I’m kinda lost.

2.9 seconds, which is very accurate with what it’s supposed to be doing, but after 2.9 seconds it just oscillates around 5 ft.

I’m so incredibly confused.

This is what I see when graphing the pose vs the setpoint. It first goes, doesn’t reach the setpoint and starts the oscillation, then oscillates at a point that’s under the setpoint. This is accurately reflected in the distances the robot moves in real life.

I got nothing.

There should be no way that RamseteCommand is still scheduled past its time. Can you verify if it is still scheduled? Do the joysticks still not work? I assume you are testing this by running auto?

The oscillation is probably in the velocity/position controller, not the ramsete controller.

Likely cause is a unit error in the gains.

I guess what I am saying is that what I think that graph is showing is a ramsete command running for 30 seconds that should only be running for 3.

I completely agree the oscillation is an issue too but it seems like this is a bigger structural issue. Whereas the oscillation is likely a tuning / characterization issue.

There’s not necessarily evidence from the graph that the ramsete command hasn’t ended; if they’re using a PD loop on position then it could oscillate like that even with a stationary setpoint.

Edit: I was reading the wrong part of your repo; there’s definitely also something funky with the fact that this was running for that long in the first place.

In the class on line 91 it looks like the command is being scheduled constantly during autonomous.

In my experience it is best to leave the autonomousPeriodic method blank and let the CommandScheduler take care of everything during autonomous or when following paths, especially since the command is already being scheduled in autonomousInit.


Yep that is the the trajectory running too long problem at least good catch! I almost never modify autoPeriodic in command based so didn’t think to check there.

I would agree with this statement. Take your pid values down. Oscillation in other systems usually means your P-value is too large.

This oscillation happens even when P = 0. I quote from original post:

I also set kP to 0; it gets to the setpoint slower, but it still exhibits the same behavior, oscillating around setpoint.

I swear to god I didn’t put that there, it’s been there since the start. I just looked at another auto-generated project and there’s nothing in autonomousPeriodic. I’ll take it out and let you know.