Comments (9)
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.
from strands_navigation.
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.
from strands_navigation.
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).
from strands_navigation.
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.
from strands_navigation.
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.
from strands_navigation.
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.
from strands_navigation.
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?
from strands_navigation.
Yes, perfect will do so.
from strands_navigation.
/cc @bfalacerda
from strands_navigation.
Related Issues (20)
- Online Fremen models update HOT 1
- [topological predictions] Online update of non existent model HOT 1
- [topological localisation] Localise by topic needs to be updated when switching map HOT 1
- [topological visualisation] See diferent actions with different colours
- problem with nav help service HOT 2
- Robot stuck by reconfigure error HOT 2
- Prevent addition of edges to empty node
- visualise_map functionality is duplicated
- [topological_prediction] prediction is skewed by many 'fatal' statistics HOT 4
- More involved reset for non-normal motor-status
- TopologicalRouteSearch with start and goal as the same node HOT 3
- message_store_map_switcher Does not compile HOT 1
- [topological_rviz_tools] adding tools freezes rviz if topmap stuff is not running
- Yaw_tolerance of intermediate nodes for edges with move_base type actions HOT 6
- node_by_node parameter is not being used in topological_navigation
- Standalone mode for create_topological_map launch
- remove topo map from db node
- insert empty map creates docking edge and charge point HOT 2
- Move topological_rviz_tools somewhere else? HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from strands_navigation.