Ask Your Question

How does LGSVL tf2 transformation works?

asked 2021-09-18 13:17:29 -0600

anguyen9630 gravatar image

updated 2021-09-18 13:19:34 -0600

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.

edit retag flag offensive close merge delete


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:

“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]”

osilva gravatar image osilva  ( 2021-09-19 06:25:43 -0600 )edit

This is also a good read:

osilva gravatar image osilva  ( 2021-09-19 06:30:27 -0600 )edit

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 gravatar image osilva  ( 2021-09-19 06:41:00 -0600 )edit

@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.

anguyen9630 gravatar image anguyen9630  ( 2021-09-19 08:11:20 -0600 )edit

Your question is super interesting. Let me dig a little more. Thank you for the clarification.

osilva gravatar image osilva  ( 2021-09-19 08:19:23 -0600 )edit

It may be lack of computational resources:


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,

    • the localization jumps erratically while the vehicle does not move
osilva gravatar image osilva  ( 2021-09-19 09:00:05 -0600 )edit

What's your hardware?

osilva gravatar image osilva  ( 2021-09-19 09:01:33 -0600 )edit

@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.

anguyen9630 gravatar image anguyen9630  ( 2021-09-19 09:02:54 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2021-09-21 04:53:10 -0600

niosus gravatar image

I don't really know how LGSVL implements odometry, but in my mind odom is not a fixed frame. My understanding aligns with yours about the chain earth->map->odom->base_link. Here:

  • base_link is between the rear wheels of the car
  • odom is initially at the spot where the car starts
  • map is in the origin of the map
  • earth is in the center of the earth

Now, the way I understand it, when the car drives, its odometry is not ideal, so there is some wheel slippage. Imagine, for the sake of example, that a car starts from the center of the map (making odom and map be at the same spot at the start) and drives straight in x direction for 10 meters. However, let's say its tires, say the left ones, are deflated. In the odom frame the position of the base_link frame will be [10, 0, 0]. However, in the map frame the car will drift to the left, so its position in the map frame will actually be smth like [9.5, -0.5, 0]. One way to deal with this is to _correct_ the position of the vehicle by some alignment with map. We perform the update and move the car to its correct position. Now, the coordinate of base_link in odom frame is still [10, 0, 0]. So there is no way for map and odom to be aligned anymore. The way to deal with this is to move odom frame around making it a dynamic frame.

Does this clear up anything or is it only more confusing?

edit flag offensive delete link more


This is perfectly understandable, however, I don't think it is just slippage. Of course I might be wrong but from my understanding, slippage would be just a minor variance. I don't think this is just caused by slippage as you can see in my screenshot. If is just the slippage then I don't think the odom would move by that much.


The initial position is 130. When the baselink move forward 5 units the odom moved back 15....

anguyen9630 gravatar image anguyen9630  ( 2021-09-21 07:29:37 -0600 )edit

Yeah, that _is_ confusing. Are you sure the localization actually works as expected?

niosus gravatar image niosus  ( 2021-09-22 04:17:08 -0600 )edit

Yea, I don't know the answer to that, sorry. I would assume it is because this is the demo. I didn't do anything to it.

anguyen9630 gravatar image anguyen9630  ( 2021-09-22 04:28:40 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2021-09-18 13:17:29 -0600

Seen: 99 times

Last updated: Sep 21 '21