*This is a discussion directed at creating a global map for RTAB-Map equipped devices to map to*
I envision a ros machine listening to all available map topics on the network. version 1: In RVIZ you can see each map being created as map data becomes available. Each map would be separated, ideally by a tab / frame border. No loop closure detection between independent maps in version 1. version 1: You can manually combine maps. No loop closure will have taken place, but you can drag / position overlying scans over the top of one another. Topic data for the global map would include the topics for the individual maps as well as their position in the global frame. version 2: Each map will remain separate until a loop closure is detected, at which point those maps become connected. version 2: leverage any gps / heading data a robot may have in order to orient maps on incoming data. Do not look for loop closures unless multiple scanned locations are within GPS proximity (this could potentially be a feature for local mapping as well). --- Concerning version 1: In my mind this can be a ros machine listening on the same network as the robots. This doesn't seem like too much work either. The most intrusive part would be the draggin / rotating of maps. The global map is essentially built by the user. What are your thoughts? Please let me know where I may be simplifying this process too much. |
Administrator
|
Hi,
In version 1, it is mostly a plugin in RVIZ that would be like rtabmap_ros/MapCloud plugin but for X mapData inputs. To drag a map, this could be a interactive marker that could be moved with the mouse (and somewhat linked to its corresponding map), adding a transform from /world -> /map1 for example to rotate/translate a map. Version 2 is a lot more tricky. If we simplify the problem by disabling the memory management (i.e., we assume each robot can process their map always online), who is responsible to find loop closures between maps? A "server" would subscribe to each published map (containing each the latest data seeing for each robot), then compare data to its own global map to find loop closures across the robots. Note that we assume also that the server has unlimited power to process incoming data online. In some way, that server could be another instance of rtabmap node or similar, but subscribing to maps instead of sensor data. GPS can be indeed used to limit the search for loop closure, but indoor or if there are high buildings around, it won't work. cheers |
Version 1 sounds pretty solid to me.
Version 2: Good point about non-gps areas. I also thought about the ability of being able to click/drag around a group of points to manually state "watch this area for loop closure". This way we're not checking against EVERY point on a map for a loop closure, but only specified points. Otherwise yes, the server would need "unlimited" power for processing. What do you think? Is this enough to start a uml for version 1? Once we have a uml (or other high level approach to version 1) then I can start in on development. I'm in NYC and am also working on putting together a small team for a project that would work with software like this. If I can get some guys together I can throw them on the development for this as well. |
Administrator
|
Hi,
Yes, version 1 can be done independently of rtabmap source code, as it could be a new RVIZ plugin. You may link your repository or create a pull request to be tested after that to rtabmap_ros. Version 2 requires quite a lot of development (and design) and I don't have much time right now do to much about this. If you have a clear idea, you may fork the projects and test stuff on your side. cheers |
Yes, I don't think it makes sense for you to put any of your time in on this in the initial stages. I'm already working on an rviz plugin for version 1. This is my first rviz plugin so we'll see how it goes..
As for version 2, it makes sense for me to start on it and to carve out a clear path. I'll be asking questions along the way if you don't mind. Thank your for your direction thus far, it is very much appreciated. |
This post was updated on .
Regarding version 1:
I was hoping that I could do everything in version 1 as an rviz plugin to avoid forking rtabmap but as far as I can tell I will need to add an interactive marker topic to rtabmap. I hate to do this because that adds mandatory functionality which most people won't end up using. Do you know of a better way? |
Administrator
|
What this interactive marker topic would have to do? I don't think rtabmap needs to know that the plugin exists. All manually added transforms would be contained in RVIZ.
|
This post was updated on .
Each /map would need an interactive marker so that the rviz user can take the multiple incoming maps and align/overlap them manually. I’m trying to figure out a way to do the markers locally but with my limited experience, the only way I know how to use an interactive marker is through a topic.
|
Administrator
|
Hi,
A simple idea: make the interactive marker changing a TF only on its callback. For example Marker1 would change TF /world -> /map1, Marker2 would change TF /world->/map2, and so on... this would be independent of the mapping approach used. Then if you set the RVIZ fixed frame to world, you will then see all maps together. Of course, if you kill everything and restart all robots, you would have to manually set the marker's position again. cheers, Mathieu |
Free forum by Nabble | Edit this page |