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?
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.
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
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.
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?
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?
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.
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
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.