Closed skasperski closed 4 years ago
As far as I remember there was an unwritten rule to never use the local frame. I think some parts of the planner might break if you set the local frame to something other than zero. But I am not sure. Use with care and check if the planner explodes if you do set it ;-)
I am having this issue because of the traversability map that is created by the planner. There is always an offset between the MLS that is given to the planner and the Trav-Map that is created. So I wonder how to set the position of the MLS correctly so that the Trav-Map is located in the same place.
uhhmm well i dont have access to ugv_nav4d anymore. Thus I cant check :) But a good starting point would be to look at how the planner loads the map and check if it does anything to the frame. Also check if the input mls has a local frame or is somehow translated. There is a chance that such a local frame on input might be ignored or partly ignored inside the planner.
The local frame describes the origin of the map frame inside of the grid map (which is organized as an image, xy starting at the left upper corner). The local frame is applied in all interface methods, so if the interface is used properly in ugv_nav4d it shouldn't be an issue. The local frame is not the transformation of the map in the world frame.
When the Trav-Map is created, the following is applied in ugv_nav4d:
trMap.getLocalFrame() = mlsGrid->getLocalFrame();
That's why I originally changed the MLS to include the local frame.
I looked deeper into this and it now seems that the map is actually handled correctly by the planner. It produces correct trajectories at the correct position. The problem seems to be that the visualization draws the cells in the wrong position. Interestingly the map-extends are shown in the correct position. But the actually map data is shifted exactly twice the correct offset. So it seems the localFrame is applied twice somewhere in the visualization.
@arneboe @saarnold
Ok good to know. I'll look into it.
Here is a small example in combination with the ugv_nav4d planner, which illustrates the problem.
This is a picture of the traversability map using the normal visualization. The planner works fine.
However, if we delete this line, everything gets shifted, but the map-extend still does not match the map itself. Yet again the planner works fine.
Let me know if https://github.com/envire/slam-maps/pull/33 solves your issue.
Yes, works for me.
Ok great.
It also works for me, thanks!
What is the correct way to set the origin of the map, or the pose of the map in the world?
I played around with the local-frame property, but I don't understand what it does. What is the difference between
map.data.translate(offset);
andmap.data.getLocalFrame().translate(-offset);
?