My team is attempting to actively change the trajectory that we are giving the ramsete command to accommodate different scenarios on the field. What is the best way to do this on the fly? Is it possible or would it be better to use a ramsete controller and do the rest of the integration ourselves?
Thanks!
If by reuse, you really just mean pass in a selection from the shuffleboard to chose WHICH trajectory you are going to follow, that absolutely can be done. You create multiple trajectories ahead of time and pass the appropriate one based on selection.
You absolutely can create trajectories on the fly and start a new RamseteCommand to run one. You just need to feed in your new waypoints, generate the trajectory, and start a new command.
It is probably not ideal for smooth control, because the separate Ramsete commands will not have any continuity between them, But if your driver has changed their mind about where the robot should be going before it finishes running one trajectory, you can certainly interrupt the command and start another at any time.
I coded up a complete Teleop driving solution for Romi using nothing but short Ramsete trajectories. This worked by feeding two waypoints into the trajectory generator - one representing where you are, and the second representing where you want to go. The command could be recalculated during every timeslice.
This is what my team is working on but like you said there is discontinuity between trajectories. Is there anyway to easily mitigate this without re-coding part of the trajectory backend?
WPILib doesn’t ship an implementation for on-the-fly replanning of paths.
I strongly suggest, at the very least, writing your own command implementation - the existing RamseteCommand is a very brittle abstraction intended to help teams who have trouble “plumbing” their code by themselves. It is not appropriate for more advanced features like this, and will be more of a hindrance than a help.
You probably don’t have to touch the “backend” much - the trajectory generator can handle trajectories with nonstationary initial states.
Yes; the Ramsete controller has no idea that a Trajectory object even exists; it is stateless and depends only on the current error. So, it is not so hard to swap out what trajectory it is following.
Could you maybe share some videos of how you implemented this when you get a chance? This will be a good resource for other teams trying to do something similar.