Why is there a separate "global_frame" parameter?

[reinzor]

For me it is unclear what the function is of the "global_frame" parameter and I am questioning if this parameter is necessary.

How would you configure the frames if I would like to let my controller run in the odom frame and my planners in the map frame? What does the "global frame" do?

Thanks,

AFAIK this was not the case in the default move base

[corot]

Yes, you are right; indeed there are a bunch of new parameters that where not there on old move_base:

• global_frame
• map_frame
• robot_frame

This is due to the fact that mbf_abstract_nav doesn't relay on costmaps, and all these parameters normally come from there. A possible solution cold be that the concrete implementation provides these parameters depending on the maps used, e.g. mbf_costmap_nav would provide them from the costmaps, as on current move_base. @spuetz, what do you think?

[reinzor]

Thanks for the reply. But why constrain MBF to run controllers and planners in the same frame? Not necessarily a costmap2d implementation.

[corot]

You mean... controllers and planners must use the same frame? Shouldn't be the case in the costmap-based implementation: they will use whatever is specified on costmap's global_frame parameter. In other implementations, looks like you are right: both use whatever is in 'map_frame' parameter.
I reassign to @spuetz, who will probably explain better why is this the case.

[corot]

Hi @reinzor, I made a branch removing the three redundant parameters (see my last post on #156). Please provide feedback if you give it a try! Thanks a lot

[spuetz]

So the global_frame is a static frame which does not move and can be seen as root of the tf tree. The map_frame is the frame of the map which is used to provide and accept resources in the map specific frame, since the planner and normally the controller, as well as the recovery plugins do their computations with respect to the map frame. To compute the pose in the map we need the robot_frame, since we are looking for the transformation from the map_frame to the robot_frame. If you have a world frame where the map is re aligned at a time, then the map_frame is not static but the global_frame is. In simple scenarios where the map does not move over time the map_frame and the global_frame are the same, both set to "map". Maybe this has been mixed over time in the implementations due to merging. But we should have this clearly separated. We should have these parameters in the mbf_abstract_nav since all implementations need tf to get the poses right. Then it is conventional and we don't need to re-implement it all the time.

[corot]

I'm revisiting this issue; I really dislike the proliferation (and much more the duplication) of parameters on MBF, so I updated the https://github.com/magazino/move_base_flex/tree/less_params branch. There, I get frame names from costmaps if available, removing the extra parameters. As the frames are in RobotInfo, I remove many attributes.