1
$\begingroup$

At my company, we are facing the following problem.

We have a platform on which we often try different sensor configurations. Often the amount of sensors and type stay the same, but the extrinsic calibration changes. Over time we now have recorded a lot of data with different configurations.

We chose not to record the robot_descrition or tf_static, as it often happens that e.g. we notice 1 month later, that sensor x should have been pitched by 5 degrees, or during field tests we did adjustments to the physical setup but had no time to adjust the URDF.

EDIT: When replaying the bag we launch robot_description with the fitting URDF. However, matching the bag with the correct URDF version is often a challenge.

I would assume this is a common problem, and would like to know how you guys are handling this?

We are using ros2 humble and record in mcap.

I am not sure if stackexchange is the right platform to post this, please point me to another site if needed.

Thanks and looking forward to your ideas.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

I would suggest saving the sensor placement (x y z roll pitch yaw) in a yaml file that you add to your git. Something like:

sensor_1:
  x: 0.123
  y: 1.526
  z: 4.616
  roll: -5.002
  pitch: 12.470
  yaw: -17.917

This file will be used by your URDF or xacro file.

And in the end, this parameter will be loaded by the robot_description to generate the sensors in those new frames.

So whenever you update this sensor.yaml file, the tf will be updated as well.

Improve this answer
$\endgroup$
8
  • $\begingroup$ That configuration needs to be included in the bag file, too, so that it can be properly replayed. $\endgroup$
    – proan
    Commented Nov 30, 2023 at 17:33
  • $\begingroup$ if you record the tf_static and tf, this is unnecessary. Otherwise, you can play the rosbag and run the robot_state_publisher node along with it $\endgroup$
    – ignacio
    Commented Dec 1, 2023 at 8:14
  • $\begingroup$ Currently, we are using exactly this approach of a version .yaml. However, you somehow need to know which version goes with the bag you look at. Especially, when you want to have automatic testing. $\endgroup$
    – Metz
    Commented Dec 1, 2023 at 9:04
  • $\begingroup$ @ignacio is correct that if you record the TF tree in your bag file, you can play back the data without also needing to know which configuration the recorded bag came from. However, you may want to have a note so that you don't have to dig into the TFs to see which configuration you're using. You can always publish a string message with a configuration text or a custom message that is your YAML file and record that into the bag files. $\endgroup$
    – proan
    Commented Dec 1, 2023 at 17:16
  • $\begingroup$ If you want to use a specific version for your automatic testing, you might want to consider my second option. Because then you can always run in whichever position you want to. I guess you will also want to do some automatic testing for calibration $\endgroup$
    – ignacio
    Commented Dec 3, 2023 at 18:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.