-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
switch between move_base planning and 8 DOF planning #130
Comments
Does this still address that we should better use localization and /map frame with the 8DoF controller instead of /odom (with drift) or is this not a goal anymore? Using move_base just to get close to the goal and then switching to /odom is just descreasing the problems but not solving them. I understood from yesterday's phone call that everyone favored using /map in all circumstances. Or did I get it wrong? |
Yes, that would be bes. |
This related to the low level controller though, the planner already plans in map frame |
ok, then the base_controller.cpp has to listen to /map instead of /odom. If that is all, this is easy to fix. |
Depends how the controller has been implemented. Theoretically yes, practically maybe. |
The base controler as part of the full 8 DOF contoller accumulates drift. Also the 8 DOF planner does not replan when the path is no longer collision free.
Therefore for long base trajectories move_base should be used (replans when obstacle appears, and uses precise localisation)
I.e. manipulate locally using 8 DOF plan and control, with rather small base movements
-> navigate near target position using move_base
-> manipulate locally again
This way we get the best of both worlds.
Actually, there is nothing we have to do here. The top level planner takes care of moving between nav goals.
The text was updated successfully, but these errors were encountered: