reading tmap from rosparam/topic

[marc-hanheide]

In many cases (in particular robot fleets), having the tmap on mongodb is both inconvenient and complicated. Have we considered simply storing the map as YAML in a rosparam, like it is done for /robot_description? Or sharing it as a latched topic? To be specific, in RASberry project, ideally the central coordinator managed the tmap and deploys it to all robots. Either via a topic (probably more workable) or by rosparam. In my view, a latched topic, in the same way as map_server works is the best option, with topological_navigation listening on that topic, and resetting everything if a new map is published. What do you think @Jailander ? Also this might be interesting for @gpdas

[Jailander]

I have a question before I can give you a fully informed opinion, are the robots not going to have a local MongoDB?
I am not particularly worried about the map because that can be done from a yaml file and published to a topic as it is now. However, all the nav stats are being stored in the MongoDB and those are used for prediction already. That means that an alternitive for that is also needed and it might be a bit more complicated.
Also less importantly all tags and meta information are not covered in the topological map topic and are managed via MongoDB, I can still sort via yaml but it is something to consider.

[marc-hanheide]

Thanks!
The robots do have a local mongo, but it just occurred to me that they must share the same map with the central coordinator. The problem is, however, that a distributed ROS system is not an option, as connections to the robots must be assumed unstable. Hence my current proposal to use ROSduct, which works fine to share selected topics and services via websockets. So, one way to see this, would be that indeed the tmap is published on a latched topic from the coordinator, which also has a mongodb store running. It could also simply expose its ROS services so clients (robots) can get data through that. Maybe thats also a good option, but we cannot assume a working mongodb DB connection from clients to the server, and we should not have to have N sources of the map, as then problems are predictable.
That said, does topo nav read the map directly from mongo via mongopy or via message_store services?
Also, the nav stats should first be stored locally by each robot, but can later be consolidated on a server after a batch sync, but that's not too important for now. The key thing is to agree on how we deploy one SHARED topological map to all robots. And the same should be done for the gridmap, centrally deployed from the coordinator server, as it is via /map topic. Informing also @MFernandezCarmona as these considerations are relevant also for ILIAD.

[Jailander]

AH, Ok I understand now!
There is one node called map_manager that reads the map from the DB using message_store and publishes it, however that same node also has all the services necessary to modify the map and query the metadata (i.e. Tags and content). I can think of two solutions now (probably there is a better middle way).
Easy solution: you can simply not use that node and get the topological map topic via rosduct, that should generally work however some things might not work like things that need access to content or tags.

Better solution: Modify (or create a simplified) map_manger to use pymongo and get the map and tags and content from central DB (probably map modification services are not needed).

[marc-hanheide]

AH, Ok I understand now!
I don't ;-)

There is one node called map_manager that reads the map from the DB using message_store and publishes it, however that same node also has all the services necessary to modify the map and query the metadata (i.e. Tags and content). I can think of two solutions now (probably there is a better middle way).

Does the map_manager already publish the current map on a topic? Is that topic used by topological_navigation to get the map, or does topological_navigation call a service on the map_manager? Or, does topological_navigation use pymongo to get the map? In other words, how does toponav get the map at the moment?

Easy solution: you can simply not use that node and get the topological map topic via rosduct, that should generally work however some things might not work like things that need access to content or tags.

Wouldn't it be useful to run this node, but run it on the coordinator server, and publish its map topic (which one is it?) globally? Also, some of its services can be exposed globally as required via rosduct?

Better solution: Modify (or create a simplified) map_manger to use pymongo and get the map and tags and content from central DB (probably map modification services are not needed).

I can't see why this is better? Where would you run it? I don't want clients to connect directly to the mongodb, as it requires another port to be somehow made accessible over a potentially unreliable and firewalled connection (e.g. a 4G network). Hence my proposal to use the rosduct websocket, which works almost everywhere, if in environments where IPs change frequently, etc.

[Jailander]

Does the map_manager already publish the current map on a topic? Is that topic used by topological_navigation to get the map, or does topological_navigation call a service on the map_manager? Or, does topological_navigation use pymongo to get the map? In other words, how does toponav get the map at the moment?

Yes it is published in a topic and it is the the topic that is used by navigation.

Wouldn't it be useful to run this node, but run it on the coordinator server, and publish its map topic (which one is it?) globally? Also, some of its services can be exposed globally as required via rosduct?

Yes part of my plan was to run the map manager on the central system. I should have clarified (replying from a geography training so trying to avoid type too much).

I can't see why this is better? Where would you run it? I don't want clients to connect directly to the mongodb, as it requires another port to be somehow made accessible over a potentially unreliable and firewalled connection (e.g. a 4G network). Hence my proposal to use the rosduct websocket, which works almost everywhere, if in environments where IPs change frequently, etc.

I was going to write "more complicated" rather than better but opted for better meaning "better", I wasn't aware you could expose services, in that case is more complicated AND worse.

[Jailander]

I don't ;-)

To simplify, the topological map is published in a topic, and it is used by navigation, however there a few specific things in navigation (e.g. no go nodes) that also need access to the tags in the meta information of each node on the MongoDB, this is done via a rosservice that is also provided by the map manager.

[marc-hanheide]

OK, cool, so agreement is as follows:

• Central Server runs:

  • <node pkg="topological_navigation" type="map_manager.py" name="topological_map_manager" args="$(arg map)" respawn="true"/>, reading the map from a local mongodb

• Robots run all the rest of https://github.com/strands-project/strands_navigation/blob/indigo-devel/topological_navigation/launch/topological_navigation.launch but not the map_manager.py

  • robots run a local mongodb, but only to store nav_stats etc in and not the actual map?
  • Can we have a simplified toponav launch file, which doesn't use any of the fremen, nav stats, or other clever stuff? No travel-time-prediction, just very basic topological navigation, base don shortest route? Does that exist already? Can you liaise with Yiannis to get that into RASberry?

[Jailander]

Yes, perfect will do so.

[hawesie]

/cc @bfalacerda