Open RichardJFoster opened 10 months ago
I was apparently not being smart - there was a simple solution of updating lastPose
to trajectory.end()
after pushing the path, however I'm not sure if this will cause any ripple effects elsewhere. It doesn't look as if it should - Android Studio reports that addTrajectory
had no in-library usages. It still feels as if I may be working around a "problem" that is a result of my lack of familiarity with the tool though....
I'm hoping this is just me doing something silly and not understanding, however....
The team I work with recently started using MeepMeep to visualize things when the physical bot is unavailable. At first, they were really excited about it, but have since run into a roadblock. Specifically they want/need to include a trajectory where the bot reverses. While the
TrajectorySequenceBuilder
exposes anaddTrajectory
call, there appears to be no way to access aTrajectoryBuilder
to build the trajectory to add.Working with a MeepMeep fork, I tweaked the DriveShim.kt so it could provide a
TrajectoryBuilder
(delegating to the RoadRunnerTrajectoryBuilder
providing the applicable velocity and acceleration constraints in the same way thetrajectorySequenceBuilder
call was doing). I was then able to use that successfully to generate a reverse trajectory to pass to theTrajectorySequenceBuilder
and the visualized path was sane. Unfortunately, when used in that way, theaddTrajectory
processing does not appear to be correctly setting the post-trajectory position to the end of that trajectory, and the first call on trajectorySequenceBuilder after adding the reversed trajectory snaps back to the position where the robot was before theaddTrajectory
call was made.Since a picture is worth a thousand words, you can find a short video demonstrating the specific challenge here.
Any suggestions for how to resolve this gratefully received. Once it's all working, I'll be happy to generate a PR if applicable.