You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is something that was in the ros1 version and is still an issue today. Can see the ros1 issue here. Our use case is we convert from map coordinates(lat/long) to local(UTM) and the x/y position coordinates of the system are large, a few hundred thousand to a few million iirc. Things with coordinates of this size are not rendered properly.
The text was updated successfully, but these errors were encountered:
I think that the underlying implementation issues are still the same. Floating point numbers get less uniform the further away from 0 that you are.
The full solution would probably require switching to doubles in many places in the code base, which is (guessing) a substantial amount of work, potentially with performance trade offs.
One option would be to add a local offset to the UTM so that your coordinates are closer to zero.
Alternatively, if you are just looking for a local cartesian coordinate system, then using the transforms that you find in the MATLAB/NavPy lla2ned function should suffice. This should be sufficient for relatively small working areas.
Yeah I understand the work arounds. I don't have any familiarity with rviz code or even worse ogre3d code, just wanted to report the bug with the hope that one of the devs would attempt to fix at some point
This is something that was in the ros1 version and is still an issue today. Can see the ros1 issue here. Our use case is we convert from map coordinates(lat/long) to local(UTM) and the x/y position coordinates of the system are large, a few hundred thousand to a few million iirc. Things with coordinates of this size are not rendered properly.
The text was updated successfully, but these errors were encountered: