# Ramsete/Trajectpry Making Robot Motors Change Direction Violently

I tried to use the ramsete command to make my robot follow a path from pathweaver but when I try to run the path, the robot shakes violently and the motors quickly and violently move forward and backward. The robot doesn’t move very much (less than 3 inches) and I tend to shut it off pretty quickly. Any ideas as to why it might be doign that?

Our code is here (github repository), the ramsete command related files are here RamseteCommandGenerator.java, TestAutoPath.java, our constants (ramsete values, pid values, characterization values) are here (Constants.java), and our path is here (TestPath.wpilib.json). @jdaming have you seen this before?

The most common error people encounter with path following is, by far, unit conversion. Be sure you check your setpoints and measurements to ensure the values make sense.

I just posted the code, characterization values, and paths

In your periodic, you’re just inputting your encoder values. This means your robot is gonna go forward a revolution and then ramsete is going to say “AHHHH! i’ve gone foward 2000+ meters, I need to go backward and then AHHH, I’ve gone backwards 2000 meters”. You need to convert your encoder values to the distance moved by the wheels

1 Like

Another thing I would suggest here is setting up simulation so that you can run tests without the robot. In the past I have thought that simulation really wouldn’t be accurate enough to help, but I can honestly say that thinking is just dead wrong. If you have it working in simulation (not that hard to do) you know the logic is right. It was so much easier to debug in simulation because I didn’t have to worry about the robot hitting people or it breaking itself or numerous other real world problems. I found that I was able to catch a whole bunch of simple problems I had by just running it there.

2 Likes

So I just need to convert encoder to meters? Do my values from characterization need to be taken with meter conversions? Basically do I need to enter my conversion factor and switch the units to meters in the analysis window?

Everything should be in meters.

I set my encoder conversion factors to the measured distance per rotation in meters and set the characterization units to meters with conversion factor. I entered the new constants and am only having slightly more luck. The motors still change direction but this time the robot seems to be able to move a bit further, sometimes forward, sometimes backward. Any additional suggestions?

Log every relevant piece of data (setpoints, sensor measurements, odemetry) and check that it is all sensible.

Trying to debug a nontrivial controls problem without looking at robot telemetry is a bad idea.

I second the advice to get the simulation working. This will help will getting all the signs of motors vs encoders vs velocity right. If any of those are contradictory, the Ramsete will go completely nuts.

I’m using spark max’s which will probably make that painful. Is there a different route that I could take? Does anything look crazy in my code?

I am looking at a piece of code from 4776 that shows the velocity being converted to meters per second RamseteCommandPractice/DriveSubsystem.java at master · 4776-SCOTS-BOTS/RamseteCommandPractice · GitHub do I need to do that?

We use SparkMaxes, and the simulation is still doable. We created a “SparkMaxWrapper” class to handle that. See the code here:

1 Like

You might need a minus sign on one of the motors in tankDriveVolts(). Not sure which works correctly. That’s why the simulation is so great.

3 Likes

The reason I’m hesitant to set up the simulation as a diagnostic measure is as follows: As programming captain I have been granted the ability, and also the car space, to take the robot home each week for programmer robot relationship building ;). All jokes aside, I’m not opposed to implementing simulation or taking all metrics but I am trying to see if anyone can find any trivial solutions to my issues before I spend the somewhat limited time I have before the next meeting focusing on implementing the simulator and getting data.

There’s no trivial solution to misbehaving feedback loops. You have to understand the different layers of the system and actually look down into it to find out where it’s deviating from your expectations.

You need to log telemetry data, with shuffleboard or print statements or similar.

The solution was trivial from my point of view. @prensing’s suggestion to negate one of the sides of tank drive volts fixed the not going forward part and @Sumifairy and @Daltz3’s suggestions to make everything meters, along with example code from 4776 helped me get the constants straight

What do you intend to do if, due to a change of system configuration, you end up with another sensor inversion or unit conversion problem?

Well, in that case I would escalate through the more complicated diagnostics steps, such as: Simulation and telemetry. However, if at all possible, I tend to lean towards diagnostic steps and solutions that are simpler and more within my current mental capacity, especially when I have limited time.

so it appears that the time has come for more advanced diagnostics… I will keep this thread up to date with my findings and data