Is there any advance in publishing the transform from world to robotX/map?

[vikcp]

Hi,

I have been checking your package and I thought that it will be producing the transform between the maps that are published by the robots and the map published by the map_merger. I found that issue where you said that it was in your roadmap. Is there any advance on this feature? If not, any hint on where you think that the enhancement should be?

Thanks.

1. What I mean by world -> robotX is transform from world frame to robots map frame. SLAM usually publishes map -> odom transform, your odometry odom -> base_link. map_merge would publish world -> map for each robot (I call here map frame robotX, to distinguish between robots). Maybe I should call that mapX frame to avoid confusion.

2. Interesting. My experience with GPS was that it is too imprecise for map merging. Sure, it is usable for initially navigating robots towards themselves to create a overlapping space (if you want), but the error is usually too high (esp. in rotation) for creating a usable map. In my experience it was better to use feature-based merging in that scenario.

Originally posted by @hrnr in https://github.com/hrnr/m-explore/issues/12#issuecomment-383367498

[hrnr]

Hi,

unfortunately no progress as I'm quite busy.

Implementing this is not hard though. One just needs to spin up a thread for tf publishing at a reasonable stable rate and publish the transforms that you can get here:

https://github.com/hrnr/m-explore/blob/745ae1e79a8289ca825cce7f7382e3e611073171/map_merge/src/combine_grids/merging_pipeline.cpp#L212

Check this from my other project how it should be done:

https://github.com/hrnr/map-merge/blob/800932d1d8c07caef8aba2966c58e784fc3099a8/map_merge_3d/src/map_merge_node.cpp#L231-L249

Devil is gonna be in the detail. One needs to ensure thread safety.

Cheers, Jiri

[vikcp]

Thank you, I'll have a look!

Best

[vikcp]

Hi Jiri,

I have been working on this issue, and following your hints I have implemented a thread that publishes the transforms.

However, I have found that when the number of simulatenous robots is high, 7 for instance, I get an error "bad alloc" from the grid_compositor.cpp at line 66 when it tries to resize the "result_grid". Do you have any idea about what it is happening?

I could do a pull request to add the feature, but it would be requried to solve this issue.

Best.

[hrnr]

Let's reopen this. I can't see you commenting on the closed ticket in my notifications.

The problem you described looks like a memory corruption, probably because of some race condition you introduced with the new thread.

Feel free to open a PR, so I can see your code and we can work that out together.

Cheers, Jiri