Replies: 3 comments
-
This was suggested before and I sort of decided against it since I couldn't think of a way to implement it that I'd be happy with. The best way I thought of was just adding another stationary state to the end of the trajectory for X seconds but that seems a bit hacky. Also this would make it impossible to run the same path without the wait time if you wanted. After thinking about it a bit another possibility I could think of that would probably be ok is having each trajectory have its own new SequentialCommandGroup(
new PPSwerveControllerCommand(pathGroup[0], ...),
new WaitCommand(pathGroup[0].getEndWaitTime()),
new PPSwerveControllerCommand(pathGroup[1], ...),
new WaitCommand(pathGroup[1].getEndWaitTime())
) and then you could choose whether you use that wait command or not. If you think that's good enough I'm happy with that solution. I can work on it whenever so I could take this up if you'd like. |
Beta Was this translation helpful? Give feedback.
-
That seems like a great solution! Our team does not use command groups, but we could easily adapt our code to using something like getEndWaitTime(). I especially like the new "path groups" feature, as it would also allows different behavior on each segment of the path, something which we had to work around in the past. |
Beta Was this translation helpful? Give feedback.
-
Ok, transferred this to #130 |
Beta Was this translation helpful? Give feedback.
-
This way, you could change how long the robot waits at a marker/stop point without having to change it in code and redeploy. I would be happy to work on this when I have a little bit more time.
Beta Was this translation helpful? Give feedback.
All reactions