This is our team’s first year using path planning for autonomous, and we’re experiencing a puzzling consistency issue. Our most recent code creates a simple S-curve trajectory, and the robot follows the path pretty well the first time we run the code; however, when we re-enable the robot, it drives straight forward for a couple of meters and then performs the S-curve. We verified the gyro, encoder, and pose readings are reset in autoInit(). We can’t think of any other reason why it would be adding this additional movement. Any ideas would be much appreciated!
Edit: To clarify, the path runs properly every time we re-deploy the code and enable the robot, but not in subsequent enable/disable cycles.
Is it possible you can post your code so we can take a look at it?
Off the top of my head, I would guess there is something not “Resetting” after your auto ends. We had to reset a few variables in our code in AutoDisable(). Kind of a shot in the dark, but might help.
Don’t have it with me right now but we’ll send it first thing tomorrow morning, sorry. And yeah, that’s what we suspect but we just have no idea what. We’ll try and have it do some weird stuff before the trajectory but after enabling to see if it’s something we missed that we have to reset or if it’s something that the ramseteCommand is failing to resetting. Thank you!
The pose you dump into trajectory generator is relative to the field. Therefore, when you run the trajectory, you should have your robot’s pose the same as the starting pose of the trajectory.
If the trajectory you want to run is relative to the robot, you can either reset your odometry or use the transform convenience methods of the Trajectory class to fit the starting pose of the trajectory onto your robot’s current pose.
The key for us (we had this EXACT same issue) was to set the Pose of your odometry module back to your origin in DisabledInit.
We were originally just resetting encoders, but without setting the Pose, our error would be significantly off and the feedback portion of your trajectory command would add unwanted speed to your wheels in the second or third autonomous run
We’ll try exactly that and let you know how it works. We figured this wasn’t the issue since we printed the pose coordinates and angles onto the dashboard and saw them resetting, but from the sound of what you described, it might just do - we’re seeing that same unwanted speed. Thank you!
That’s what we’ll try tomorrow based on @mray190’s code. As I replied to him, we saw the pose coordinates reset on the dashboard, but that’s probably what it is since it seems to be the consensus of the replies thus far. Thank you!
We found this out the hard way when our robot would just floor it down the other end of our field, obviously not following our path. Once we updated the starting pose of the path to match the current pose of the robot (or vice versa), it worked flawlessly.
@mray190@bsimmons@chenyx It worked! Now any paths we make in the trajectoryGenerator work consistently. Since it was going too fast and kept losing control, we wanted to use PathWeaver paths to include velocity vectors. However, when we test paths we create in Path Weaver, we see the robot not follow the path (for example, instead of doing a U shape it just rushes forward). Any ideas? The path imported correctly and everything.
I am not very familiar with path weaver, but can you check the starting pose of your trajectory and the robot pose when you start following it? They should be pretty much the same
Also, it’s my understanding that the control points in pathweaver don’t control velocity, the control the curvature of the path around that point.
If you want to slow the robot down, go into the pathweaver project settings and change your max velocity, that’s what we did.