There’s some current work right now on adding a state lattice planner to the SmacPlanner framework to enable omnidirectional / differential drive control sets. You bring up legitimate points of discussion but we haven’t made a decision why on them as we’re still getting the pieces assembled to do some initial testing. So there’s no clean answer I can give you that would likely be right in a few months – I’d be guessing.
In general though:
- That link is our current best guess and the route we plan to support at the moment. Adding rotate in places and move lateral left/right is our current plan for omni
- Probably not the best heuristic, but we need to try and see if its a good enough approximation. This could be replaced with a precomputed lookup table, similar to what exists there now, but as generated from BFS in the search field and then stored in the primitives file for use at runtime.
- This is the biggest unknown. Generally, I would like to keep this since it adds a serious speed up, but it doesn’t quite fit the motion model well. Basically I think for “easier” paths it will help, for “harder” paths it will take up some compute but won’t probably find the terminal solution for omni robots. The compute it takes up is non-trivial but also not massive. My intuition is to keep it, but we could disable it if we find that it is actively bad.
The problem of generating omnidirectional control sets is actually also an area of a bit of unknown. I’ve found almost no literature about how to general minimum control sets for omnidirectional robots that both utilize the full range of motion capabilities of an omni platform and has a practical branching factor for even moderately real-time path planning. The discussion you point to is my best estimate of how to support omnidirectional robots in a state lattice / search motion primitive based solution, but just tacking on “move left/right” isn’t a very satisfying solution when we’re able to auto-generate actual viable minimum control sets for ackermann and differential robot types.
If you know something we don’t, an area of collaboration would be to create a generator for omni control sets that meets your needs and then have that as an option along side our ackermann and differential drive control set generators to use in the state lattice planner implementation. Frankly, its not a huge priority to us support really great omni robots mostly because the few manufacturers we’ve found using omni robots requirements basically could work fine with the other control sets or were able to use just naive grid search. I’m not really satisfied with either of those answers, but my experience and opinions on how to best handle omni robots is limited. I’d be happy to have your collaboration to make sure omni robots have great support here, but it would involve a bit of leg work on your side – but you could build off our work.
2 areas of collaboration here:
- Help on control sets generators for omni robots to make best or better use of the drivetrain features
- Help replace the distance heuristic with a precomputed BFS using an arbitrary control set (such that it can be used for omni or any other model or a custom omni model from another maker)