inconsistent sensor parameters

[christianrauch]

Describe the bug
The documentation provides the example:

  <sensor name="imu_sensor">
    <param name="mujoco_type">imu</param>
    <!-- There is no requirement for the mujoco_sensor_name to match the ros2_control sensor name -->
    <param name="mujoco_sensor_name">imu_sensor</param>
    <!-- Default value of orientation_mjcf_suffix is '_quat' -->
    <param name="orientation_mjcf_suffix">_quat</param>
    <!-- Default value of angular_velocity_mjcf_suffix is '_gyro' -->
    <param name="angular_velocity_mjcf_suffix">_gyro</param>
    <!-- Default value of linear_acceleration_mjcf_suffix is '_accel' -->
    <param name="linear_acceleration_mjcf_suffix">_accel</param>
  </sensor>

However, linear_acceleration_mjcf_suffix (and the other _mjcf_suffix) is not a parameter of the sensor, but the <hardware> and it is retrieved via get_hardware_parameter_or.

IMHO, these plugin-specific parameters should be part of the plugin configuration (i.e. inside <hardware> / </hardware>) and not in the interface definition. The interface definition can be reused by multiple hardware implementations, and this way, it clutters the interface and makes reusability more difficult.

Expected behavior
Clear separation of interface and implementation.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Ubuntu]
• Version [e.g. Humble]
• Anything that may be unusual about your environment

Additional context
Add any other context about the problem here, especially include any modifications to ros2_control that relate to this issue.

[eholum-nasa]

I think there's a good refactoring opportunity here, and cleaning up the param definitions could be apart of that.

For historical reasons (they were first...) FTS/IMU sensors are very tightly coupled into the interface. Now that we have plugins support I think they should be re-implemented as standalone plugins. This would enable us to do exactly what you're suggesting and keep the interface definition separate from the details of the hardware - though it would likely be a significant interface change...

Does that make sense? We'd probably have to expand the plugin definition so that we could hook in state and command interfaces, but maybe we should do that anyway.