Added change_map service to map_server #461
Conversation
Added MapServer::loadMapFromYaml() MapServer::loadMapFromParams() MapServer::loadMapFromValues()
of causing the map_server_node to exit Changed methods MapServer::loadMapFromValues() MapServer::loadMapFromParams() MapServer::loadMapFromYaml()
Added second test map and test constants Added rostest for change_map service
|
CI failed with an unusual error. Is the build system misconfigured? |
| @@ -0,0 +1,3 @@ | |||
| string map_path | |||
| --- | |||
| bool success | |||
There was a problem hiding this comment.
I'd really rather we not put messages in the packages in navigation -- we have a separate repo (https://github.com/ros-planning/navigation_msgs) that is for messages, this has the advantage of making the interface itself (the messages) lightweight to build, especially if someone is on an alternate platform where they can't actually build/install the full navigation stack, but they just want to communicate with it
There was a problem hiding this comment.
Also, the right place for this message is probably nav_msgs, given that is where GetMap is, etc (although I do realize that is in common_msgs, meaning getting a review/release is likely going to take longer)
There was a problem hiding this comment.
I can submit a PR to common_msgs/nav_msgs for LoadMap.srv. Do you think the service would pass scrutiny in that repo?
Would that mean a path for this change to be released is to wait for the service to be released in common_msgs, then modify this PR to not contain the LoadMap service?
When called map_server will load a new map (or reload the old) when requested This would allow completion of pull request ros-planning/navigation#461 Which would close ros-planning/navigation#279
|
I'm digging up old PRs. This is the oldest. Can you rebase this on melodic? |
|
Actually, this is blocked by ros/common_msgs#95 |
|
Now blocked by ros/common_msgs#152 |
|
No longer blocked. |
|
Closing in favor of #1029 :) |
This PR adds a "change_map" service to map_server including a change_map rostest. It also resolves #279.
The change_map service expects a path to a yaml file, and responds with a Boolean indicating if the map was successfully loaded. The new map and metadata are published to the appropriate topics.
If change_map is called with the currently loaded map, the current map is reloaded as if it were a brand new map, resolving #279.