I copied the example in the manual for following trajectory with Ramsete command. I made a few mods to fit our code but should be very close the example. When I run it and it calls generateTrajectory it fails with: TrajectoryGenerationException: Something went wrong at iteration 1 of time parameterization.
It appears I set some of the parameters incorrectly. It is now executing. However, the behavior is bizarre. I asked for a straight trajectory to start, 3 meter drive straight ahead. Interior waypoints at 1 and 2 meters, Y value of zero. When it executes under simulation it drives all over the place in loops and arcs and ends up in the wrong place facing the wrong way. Still working on it to see what might be wrong.
There’s a place you set up simulated encoder noise. I believe it’s a 7-value list wherever you set up the drivetrain plant. What do you have there?
Null, that is, passing no information about noise. So “perfect” operation. I essentially just want to start with driving a straight line from starting pose to finish pose 3 meters away passing through two waypoints, also showing a straight line. By straight line, the starting (lower left) X=1.2 Y=.5 angle=0. WP1 X=2 Y=.5 angle=0. WP2 X=3 Y=.5 angle=0. Finish X=4 Y=.5 angle=0.
So when it runs it first rotates 180 degrees then runs a curved course backwards (this is in fact the forward X direction) and goes up (+Y) and over and stops at X=4.34 Y=2.74 angle=177.40 (still facing backwards from start).
On line 260 in your drivetrain class where you update your odometry, try feeding it a negative angle and restricting the output to +/- 180 degrees?:
With WPIlib trajectories, it expects +Yaw to be turning left and -Yaw to be turning right. Most gyros, including the navX, treat clockwise (right-turn) as positive and counter-clockwise (left-turn) as negative.
In the current docs, it shows the gyro access method here:
The 2020 example code of the same page is a bit clearer for showing you how to do it with a non-gyro class (Line 180):
Good reminder about opposite sign issue…but our function getTotalYaw2d does reverse the sign of the total yaw. In any case, the total yaw at the start of this test is zero, so sign should not enter into it.
I expected since in this test I set the initial rotation to zero and and final rotation to zero, the trajectory should go in the direction the robot is currently pointing without any turns. I can’t figure out why it turns 180 before moving forward.