Hardware Interfaces with many parameters

[destogl]

Integrating an existing robot into the ros2_control framework, an issue about parameterizing hardware interface came up. Concretely, the robot is rather complex with many sensors (FTS, cameras), tool changing system, many tools. Therefore many parameters need to be set at on start of the hardware. In ros_control we would typically use YAML files for this and access the parameters on the parameters server. Since the hardware interface does not have access to the ROS2 Node interface in ros2_control, this is no longer possible. Therefore we decided to define parameters under the ros2_control tag in URDF. So if one often needs to change those parameters, this is very inconvenient, especially if it is expected that end-users set the concrete values for their robots (e.g., IP-addresses).

I see two possibilities to make this easier:

1. Extend interfaces through the ros2_control library and enable RessourceManager and HardwareInterfaces to access the parameters.
2. Use YAML files inside xacro files as done by @livanov93 for the UR robots:
   • Load YAML file in xacro structure
   • yaml file parameter
   • macro for reading model data - This macro could be avoided
   • mapping in yaml_file
   • use in YAML file

As users, which approach do you prefer? I would especially like to get opinions from people focusing on using the library and not developing it (@guru-florida, @olivier-stasse, @dignakov, @v-lopez, @ahcorde, @jordan-palacios, @AndyZe, @livanov93)

Sorry @bmagyar and @Karsten1987, I think we are too biased. 😀

[gavanderhoorn]

I'm "glad" to see this raised, as it was basically what I tried to get across in #340.

Use YAML files inside xacro files as done by @livanov93 for the UR robots:

pedantic, but all of that is work coming from the 'upstream' universal_robot repository. It's not new.

I went a bit overboard in universal_robot though, and am not sure I'd do it again like that.

[bmagyar]

OK I'll stay quiet on this. How about raising the same question on ros discourse? Would help involving more ppl

[AndyZe]

I suspect it would be easier to do the yaml inside xacro option (Option 2).

Mainly because C++ isn't great at parsing, but that macro Lovro wrote looks very simple/readable. So I would vote for that (until somebody changes my mind...)

[dignakov]

I think I would prefer to have parameter support, or a way to load/pass a parameter structure.

I don't have a solid technical reason. It's just that it's one more file to write and maintain when creating a package, and having to add extra matching parameters to a urdf or xacro (I hope I'm understanding how the macro works correctly...).

It also makes the process of creating a new robot package somewhat different from how it's documented/described in other documentation, so someone coming to ros2_control would need to be aware of the extra steps.

[olivier-stasse]

If I understood well solution 2 is already implemented and amount to an organization of the robot_description package ?

This will not solve the problem for people who cannot modify the URDF description package of an industrial robot.

[AndyZe]

I guess I'm not clear on where the data gets stored for Option 1. Would it go in x_robot.ros2_control.xacro?

[guru-florida]

Also keep in mind parameters have to be changeable at runtime. For example joint parameters for origin-offsets, direction inversion, PIDs, etc. So #1 handles this for sure, how about Option #2? I don't see a way of updating parameters in Option2 without also having option 1 since every method of option 2 amounts to loading from a file.

[jordan-palacios]

From option 2, the xacro macro looks like a maintenance nightmare. We have multiple robots with very different configurations. I'd rather avoid having the create one file like this for each one. Also, using xacro as a bridge for yaml parsing does not seem right.

1. Extend interfaces through the ros2_control library and enable RessourceManager and HardwareInterfaces to access the parameters.

I much rather convert the Sensor, Actuator and System into nodes and just load the parameters into them directly, like we do in the controllers.

Mind you, this can be done from the command line now using the load verb. See ros2/ros2cli#590.

Also keep in mind parameters have to be changeable at runtime. For example joint parameters for origin-offsets, direction inversion, PIDs, etc. So #1 handles this for sure, how about Option #2? I don't see a way of updating parameters in Option2 without also having option 1 since every method of option 2 amounts to loading from a file.

I agree with you, but I'd say to leave parameter dynamic reconfiguring for a following PR.

[guru-florida]

I don't think we have to make Sensor, Actuator and/or System regular nodes, but nothing stops someone from adding Node interfaces to these classes or vice-versa deriving from Node and implementing the ros2 controls interface. I do something similar to this in my case.

[destogl]

OK I'll stay quiet on this. How about raising the same question on ros discourse? Would help involving more ppl

I don't know about that. I would like to have still interested but not so experienced people here. But someone who is thinking about control.

Thank you all for your contributions. It seems there is a slight tendency toward adding a node to the hardware interface (Proposal 1). That is also feedback I got from some other parties. This is somehow in line with the plans to support the lifecycle of hardware components, i.e., we could use a very similar interface used for controllers and leverage lifecycle nodes in the long term.

@bmagyar and @Karsten1987, now it's your turn :D What do you think about going with proposal 1 (and yes - I know - it breaks the API and ABI)

[AndyZe]

Another thing to consider is switching from simulation to hardware easily. Something like a launch parameter (sim:=true) in ROS1 would be great.

I saw there's now a separate hardware plug-in for fake components. I'm not sure how to switch between that and the real hardware plug-in.

[destogl]

I saw there's now a separate hardware plug-in for fake components. I'm not sure how to switch between that and the real hardware plug-in.

I will add this into examples in the next few days.

[mahaarbo]

Maybe a bit late, but I'd really like the 1st solution, support for parameters that can be changed at runtime in the hardware interface would be make life a bit easier.