Avoid double management of sensor configurations in urdf and config

[Owen-Liuyuxuan]

Background

In this section, we first summarize and review how we are working on aip_launcher and organizing URDF Xacro files and calibration configs.

Internal Document

File Organization

1. Calibration configs: they are Yaml files, storing the names of the sensor links and the related transformation values between joints and the bases.
2. URDF file: they are Xacro files, loading the calibration configs and setting the links of the sensors. This will be used to publish a tf tree and simulation.

Interface and Usage

In XX1 Autoware launch, the launching progress: 1. tier4_vehicle_launch/vehicle.launch -> 2. tier4_vehicle_launch/vehicle.xacro -> 3. aip_xx1_description/sensors.xacro

I would point out that I would expect that the launch process is rather fixed and it is not expected to be modified for now.

Management and Problem

As the title indicates, there is a double management problem of sensor configurations in urdf and config.

Whenever we would like to add or remove a sensor from the sensor configuration file, we also need to change codes in the xacro files.

For now, the only important extra information that the "sensor.xacro" contains are the types of sensors.

Discussion

Basic Ideas and Tricky Problem of Sensor Type

The core idea is to get rid of the description urdf. We can programmatically create xacro files from the calibration files.

For now, we temporarily infer the sensor types from the names of the sensor links (we could add the sensor type names in the calibration files in the future)

Difficulty in Changing Launch Runtime

The launch process is fixed in tier4_vehicle_launch/vehicle.launch and tier4_vehicle_launch/vehicle.xacro. If I run a xacro compilation script during the launch, I may need to refactor tier4_vehicle_launch significantly, which is not favorable for now from my perspective.

Compiling URDF files in Build

To limit the range of modification, I consider compiling URDF file during the build time. By modifying the CMakeList.txt in aip_launcher, we can obtain flexibility within the aip_launcher while not affecting other codes.

Possible Proposal

#274

I implemented the modification for aip_xx1_description. Using compile-time conversion and naive link_name inference in that PR.

Tested the text creation on XX1 / X2 / XX1 Gen2, and over-all PSim launch on XX1

Further Possibility

1. We could write the names of sensors in the sensor calibration files (individual parameters). And we can read them and load them correctly.
2. It is further possible to clean up different description packages, and unify the xacro creation.

[Owen-Liuyuxuan]

Updates (12/13):
As stated in #274.

We have implemented two decisive improvements to the system so that it becomes much more reliable.

1. Type annotation in configuration.
2. Force recompiling on each colcon build.

In my opinion, the methods now have been usable for different projects if configured correctly.

[Owen-Liuyuxuan]

Updates (12/20):
As stated #361.

We have further implemented two important improvements to the system so that it becomes much more usable for different projects.

1. Create an independent aip_urdf_compiler package, which stores the scripts, templates, and test scripts and exports a CMake macro for usage.
2. Add an optional keywords for frame_id. So that users can directly indicate the frame_id.