Added Tf publisher

[vikcp]

Related to issue #29

I get an error "bad alloc" from the grid_compositor.cpp at line 66 when it tries to resize the "result_grid".

Thanks.

[cero10]

Is there a way I can get a version of the map merger where I can freely control the merged map's origin, by changing the initial poses of the robots? because I tried this branch but the merged map still has an offset.

[vikcp]

Is there a way I can get a version of the map merger where I can freely control the merged map's origin, by changing the initial poses of the robots? because I tried this branch but the merged map still has an offset.

This PR does not involve the initial poses of the robot nor the creation of the merged map. It is just to publish the transforms between maps.

[andresjguevara]

Is this feature ready to be merged?

[hrnr]

@andresjguevara It would need couple of adjustments. Would you be interested to contribute those?

[vikcp]

Hi, I have been working on this feature for a while. I finally find out how to get these transforms, because what I found was that OpenCV provides the proper rotation, but not the translation, so you need to manually reverse the process to obtain the translation. I need to clean up the code, and then I can PR again to see if it fits here. I'd need a couple of days

[vikcp]

I have updated the PR with my last modifications.

@hrnr I have commented the "adjuster" because it was misleading the results. I don't know if you have other experience with this but it helped a lot no to add it in the loop.

@andresjguevara If the PR takes time or does not fit, you can use my fork of this work and try my branch called publish transforms, it should be working. However, take into account that no transform is given if the maps do not stitch and if the stitching is wrong it will provide wrong transforms.

[hrnr]

Thanks, I can take a look on Wednesday. I'm planing to release for Melodic, so it would be great to get your changes in.

[Xvdgeest]

This looks awesome, exactly what I need. When will this feature be merged? Will it also be for kinetic? Is there still help needed?

[Xvdgeest]

Thank you guys very much for putting the work in to get the transforms published. I cloned this branch and ran it on two mobile robots using rplidar and gmapping to create the (same) map. The robots are moving in the same area, thus seeing each other, which causes some disturbance.

I noticed that the transforms are very "jumpy". When the maps are merged (almost) correctly, The rotations align but the translation is off by a few meters. Also, the maps are drawn at (x,y)=(100,100), which is not a problem but it is a bit strange.

I'll see if I can find a solution, if you have any ideas, help would be greatly appreciated.

[vikcp]

@Xvdgeest Hi, Regarding the "jumpy" transforms it might be cause for several reasons. One of them it could be due to the rate in which maps are updated and its new information processed. Are these transforms more stable once the map is closer to a completion and it does not expands anymore? Regarding the initial position, the merged map is set initially at (0,0) but the maps that you are creating with gmapping can be initiated at a different position depending on the parameters that you use or your odometry values. Please report any issues that you find so that we can all try to improve this feature. Thank you!

@hrnr Hi! Did you have time to check this PR? It will be very helpful if you could have a look at the code. Thank you!

[jkRaccoon]

@hrnr hi~! I`m still wait for this pr :)

[tristan-schwoerer]

@hrnr Is this viable to use? Would be amazing if we can get this PR approved then