How does LGSVL tf2 transformation works?
Hello, I am new to ROS2 and Autoware and trying to use the record/replay demo outside of LGSVL.
I managed to get the p2d_ndt initial localization to work but as my car move around the robot on RVIZ would just stand still at that initial pose. I would guess that this is due to some missing tf.
I tried to reverse engineer LGSVL and it just leads to even more confusion. I understand that the map->odom and odom->base_link are both dynamic. The tree for the transform for LGSVL is earth->map->odom->base_link.
What unfathomable to me is that as the LGSVL robot move around, the base_link frame actually travel away from the odom frame and the map -> odom and map -> base_link transformation is actually different.
ros2 run tf2_ros tf2_echo map odom
At time 1631987443.149688576
- Translation: [-284.880, -8.165, 0.394]
- Rotation: in Quaternion [0.003, -0.003, 0.998, 0.070]ros2 run tf2_ros tf2_echo map base_link
At time 1631987449.749682176
- Translation: [-241.212, -6.367, -0.008]
- Rotation: in Quaternion [0.005, 0.012, 0.009, 1.000]
So can I make the transformation different even though the tree are the same? I hope some one can clear it up.
Not sure how much research you have done so forgive me if this is already too basic to you.
Have you looked at the documentation: https://autowarefoundation.gitlab.io/...
“odom-/base_link transform must be bounded
Local algorithms involve transforming constructs with respect to different times and space. An implicit assumption is that these transforms will be smooth across time. As such, local algorithms must operate with respect to the /odom coordinate frame, which has the built-in assumption of having smooth evolution. This typically assumes that the /odom frame origin is fixed in space without moving.
If a vehicle is travelling for long distances, then the magnitude of the /odom-base_link transform will grow in magnitude, possibly to the point where floating point precision becomes an issue[3]”
This is also a good read: https://www.ros.org/reps/rep-0105.html
If the vehicle travels a long enough distance that the distance from the odom frame's origin to the vehicle approaches the maximum floating point precision, degraded performance may be observed for float-based data persisted in the odom frame. This is especially true of 32-bit floating point data used in things like pointclouds. If distances on this order are encountered a systematic reset of the odom frame origin may be required. If centimeter level accuracy is required the maximum distance to the odom frame is approximately 83km. [6] There is not a standard solution to this, systems with this issue will need to work around it. Potential solutions include additional coordinate frames in which to persist obstacle data or to store obstacle data, or using higher precision.
@osilva I too assume that /odom should be fixed but for some reason, /odom actually moves for the lgsvl which is why I am so confused.
In my implementation, I am trying to use the p2d to first estimate the initial /odom position and then transform the /base_link but instead of the /base_link moving, the /odom moves instead.
So I tried checking out how does LGSVL implement the transform but somehow they manage to make both the /odom and the /base_link to move...............
As you can see here. The /odom is not fixed.
Your question is super interesting. Let me dig a little more. Thank you for the clarification.
It may be lack of computational resources:
https://autowarefoundation.gitlab.io/...
Troubleshooting
Lack of computational resources The computational demands of running the LGSVL simulator and the Autoware.Auto stack for the AVP demo in parallel are high and may not be met by commonly available laptops with a consumer-grade NVidia accelerator.
There are various manifestations pointing to this of lack resources:
the localization is not able to follow the vehicle as it moves around in simulation and gets stuck at a past location,
What's your hardware?
@osliva RTX3070 and Ryzen 5 2600 w/ 16gb RAM. But like I said, the localization does work with LGSVL, albeit weirdly. The one that is not working is my implementation.