Closed peci1 closed 1 year ago
What may be a bit hidden in this PR but I consider it a nice bonus is the better and more explicit separation of concerns of the two asynchronous parts that process the fix/reference position.
This PR makes it explicit that the result of transformTileToMapFrame()
(and its UTM counterpart) is to determine the location of the origin of the center tile in a TF frame that can be later transformed to the fixed frame. And transformMapTileToFixedFrame()
just takes this origin location and does the transformation to fixed frame.
Depends on #104 and #105.
This PR makes use of the UTM mode added in #105 and adds the possibility to use custom position reference for tile positioning. By default, the received NavSatFix messages are used as reference, as without this PR. The added options allow to specify a TF frame connected to the UTM frame and use that frame as the center tile position reference.
I've split the XY reference and Z reference as sometimes you want to track the robot in XY, but keep Z at a fixed altitude.
An example video showing how it works with
base_link
as the XY reference andutm
as Z reference. The violet path is the NavSatFix messages converted to UTM. You can see they are quite jumpy (I've manually blocked the receiver antenna to make the signal worse in this case). If you look closely, the map tiles always follow the fused robot pose estimate from TF and do not follow the jumpy fix messages.https://user-images.githubusercontent.com/182533/195618526-c044455f-bfc7-44d1-92c0-ee22467d5fb1.mp4
This PR gets closer to not needing fix messages at all, but there are still a few places where they are needed. We could iterate in this PR to make the need for fix messages disappear completely, but that would still require some work (at least a way to determine the initial UTM zone and hemisphere). I think it's doable, but maybe let's first finish the dependencies of this PR and work on this later.