Calculating /tf_static and /tf

[WesG911]

Hi Johannes,

I'm sorry to open a new issue. I wasn't able to reopen the closed one...

Thank you very much for your aswer Johannes.

Actually, I still don't get how were the non static attributes of /tf calculated. The provided bag shows that its frame_id is /local_cs and its child_frame_id is /sensor/camera. Can you please clarify more for me how was it calculated from the raw kitti data ?

Thank you very much in advance,

Best regards, Wes

[MohammedCHGHAF]

Hello Johannes,

I am interested in this topic too. Can you please explain in more details how were the non static attributes of tf calculated in order to generate the provided bags ?

Thanks for your help,

Best, Mohammed

[johannes-graeter]

Hi,

sorry, my response seems to have been eaten by my mobile github client... There is no magic behind this. The /tf to local_cs is just the groudntruth from kitti, that I added to the bag, so I could show it side by side to the estimate (which is published as /estimate/local_cs). Local_cs is is actually the vehicle, so any COS on the vehicle you would like to model (f.e. to implement a motion model). Probably should have named it /grountruth/local_cs or sth like that... Does that answer the question?

Best, Johannes

[hexdforward]

Seems you didnt answer above questions, i think the reason why @WesG911 and @MohammedCHGHAF has this question is that they want to use more kitti rosbags or self‘s rosbags to generate the bag which limo need. So could you explain how to calculate /tf or /tf_static ? It would be better if you could provide an example. Thanks!

[MohammedCHGHAF]

Indeed @hexdforward , the idea is to be able to generate more kitti rosbags that are compatible with limo. It would be extremely helpful if @johannes-graeter were able to provide an example of the calculations ...

Thank you ! Best, Mohammed

[johannes-graeter]

It would indeed be great if you would be able to supply more data in rosbags! unfortunaltely the code i used for this is proprietary to my university and I am not a part of it anymore... also the bags itself where on a hard drive that is now corrupted...

I understand that the tf tree built up in my application is a little confusing I sturggled with it quite a long time since I wanted to show my trajectory estimates and the groundtruth all in rviz with the sensors. Also the estimate prior is in a seperate node and is also published via tf in order to be able to replace it easily... First, static is everything that is calibrated before. Everything that is called local_cs can be seen as a fixed frame on the earth, I just named in local to say that is not localized by gps or some global reference. The Sensor rig is hung up at sensor/camera topic, so once you connect your estimated trajectory to this topic, you can plot your data as seen in the videos. On launch (see https://github.com/johannes-graeter/limo/blob/master/demo_keyframe_bundle_adjustment_meta/launch/kitti_standalone.launch) there is some additional static transforms introduced to connect the tree (also in https://github.com/johannes-graeter/limo/blob/master/demo_keyframe_bundle_adjustment_meta/launch/tf2_static_aliases_kitti.launch) and the estimate from limo will then be published as a transform between estimate/local_cs_vehicle and estimate/vehicle.

So you have local_cs(fixed) -s-> estimate/local_cs_vehicle -d-> estimate/vehicle -s-> sensor/camera and so on. What is confusing is that while my system uses a vehicle coordinate system (roughly calibrated to the mid of the rear axis of the car), the tf for the groundtruth from kitti (as provided in the bag) is given not in vehicle coordinates but relative to the first camera in the rig. so the tf transform for groundtruth is: local_cs(fixed) -d-> sensor/camera and so on

To show the trajectories side by side I introduce new coordinate systems gt/local_vs_vehicle and gt/vehicle, just to show a path between them.

I know it is all a bit wild and unclear even for me, also it is now nearly 3 years that I wrote this code :) I guess a tf tree viewer (rosrun tf view_frames) will help (make sure to call it while limo is running to get everything that is published on launch). Hope that helps! If you have code for producing the bags that is public, I would be happy to contribute! Not being able to supply the bags bugs me...

Do you actually need the rosbags or would a cpp bin reading images and lidar also be enough (I think that would actually be clearer, putting this in a ros system really is a piece of work if you wnat to be able to switch the individual parts...)