map_server: reload_map_from_file service?

[MartinPeris]

Hi there,

I was wondering if it would be useful to implement a service on map_server to reload the map from a file. I think it would be beneficial in multi-floor environments where one needs to change the map due to the robot changing floors, instead of having to kill the map_server node and starting it again with the map of the new floor.

Please let me know if this can be already achieved by some other means

[mikeferguson]

One way I have seen folks do multi-floor is to lay all the floor maps next to each other on a single map and then "teleport" the robot between floors when it goes into an elevator.

That said, loading a new map seems a bit better. The only concern than would be that everything that consumes the map updates correctly.

[MartinPeris]

The "teleporting" option might be a quick hack, but I don't think that should be considered "best practice".

In my humble opinion, that the map consumers updates correctly should be a concern... for the map consumers, don't you think?

Anyway, I am going to implement this feature for my own project so, I will send a pull request :)

[DLu]

This is another use case where layered costmaps are useful. Rather than teleporting the robot, I've created several static maps that share the same coordinate system. Then, when a new map is published on the /map topic, the static data will be swapped out for the new data.

What I'd recommend doing is creating a map_mux that takes several published topics (/floor1_map /floor2_map etc) and switches which one of them is published to /map can be changed by the method of your choosing.

[MartinPeris]

Thanks for your suggestion David. I think it is a good idea, but what would be the advantage of having all the maps loaded in memory at the same time (which can be a non negligible amount of memory) in contrast with loading them from disk when needed?

[DLu]

I'd say its the ROS-iest way to do it, with the added benefit of having no changes to map_server. You could also have multiple robots on different floors, perhaps. I have no response about the amount of memory.

[MartinPeris]

From a ROS-iness point of view, sounds reasonable. I think I'll do it this way although we might want to give it some more thought.

How about this?

1 - Create package map_server_mux
2 - map_server_mux node will receive a list of map, map_metadata topics and static_map services + a default map topic (using rosparam perhaps?)
3 - map_server_mux will publish the map and map_metadata topics + static_map service according to the selected source
4 - map_server_mux will provide the service switch_source that will effectively switch the map topics to be published and static_map service to be referenced.

The switch_map.srv declaration would be something like:

string source_name

And a parameter configuration example could be:

map_sources : map1 map2
default_map : map1
map1 : { map : '/map1', map_metadata : '/map1_metadata', static_map : '/static_map1'}
map2 : { map : '/map2', map_metadata : '/map2_metadata', static_map : '/static_map2'}

Any comments?

[mikeferguson]

@MartinPeris My one suggestion would be: if making a mux, maybe don't make it specifically for maps. There already exists a topic_tools/mux node which is frequently used with cmd_vel (the Pr2 for instance uses this mux to switch between joystick and application commands, allowing the joystick to override the application so you can steer away from danger). Of course, mux doesn't work for multiple topics (like your map/map_metadata stated above), but this is a common thing (cameras for instance typically have a camera_info topic in addition to the actual camera data). I can imagine that a multi_topic_mux (n*m->n topics, where current is m->1) would be quite useful in general.

[mikeferguson]

Bah, right after hitting enter I noticed the static_map aspects. I guess that would be slightly different from a generic node. However, I would note that your mux already has the map (since it has to pass the map through itself), and so it should be able to just advertise the static_map service itself and return the last map passed through the mux (no need to even tell the mux about the other static map services, they won't be used by anybody).

[MartinPeris]

@mikeferguson you are right, there is no need to tell the mux about the other static_map services. Regarding a generic node... might be out of my time availability :p