Question regarding using nodes within component plugins

[Roozter]

I was wondering if its worth while to have some of the component loaders take a ros2 node as an argument. The reason I ask is because our application holds calibration parameters of our actuators in the transmission, and it would be nice if we could update these parameters via ros2 param during runtime.

Not sure if this goes against the ros2_control paradigm, wanted to ask before I spend any time on submitting a pr for this.

Thanks!

[saikishor]

Hello @Roozter!

Could you please give us some more information on how you are currently applying these calibration parameters to the transmission system and how you are planning to tackle it?. Regarding, updating these parameters on runtime, do you mean to change them with the parameter callback, more or less how the generate_parameter_library does?

Thank you

[Roozter]

Hi @saikishor!

Thanks for the response. Currently, we have have a multi-DOF manipulator which has a transmission associated with each joint. We have a method of performing online calibration of our robot using a computer vision system. The calibration procedure provides us joint offsets which we use to update the offsets that reside in the transmission. The desire is to use a ROS2 parameter callback function to make the update at runtime, which prevents us having to manually update a offset param in the URDF and restart our robot software.

We would also like the ability to pass a node down to the transmission, because it allows us to load the offsets to the node parameters at launch time.

Please let me know if you need any more details.

-Rooz

[saikishor]

Thank you for the explanation

The calibration procedure provides us with joint offsets which we use to update the offsets that reside in the transmission. The desire is to use a ROS2 parameter callback function to make the update at runtime

I'm not sure if updating the offsets in the transmissions at runtime is the proper way to handle this issue because this might create jerky movements on the robot. Moreover, parameters are the right way to tackle this as they don't ensure a real-time state update for you.

You could write a controller or a node that simply adds these offsets to the joint values and reports them in a topic similar to /Joint_states, this way you can have access to the positions with offset.

Regarding loading offsets at launch time, you could have these offsets inside the URDF that the transmission loader reads and parses to the Transmission. Does this work for you?

Let me know what you think

[Roozter]

You do have a point about the jerk that is generated when performing the calibration update. Typically, we don't see a large jerk because the online calibration is a finer calibration that occurs after a coarse calibration, but it could cause a large jerk if someone's offsets are large.

There are definitely ways around this, but my team prefers the update via rosparam method.

Appreciate you taking the time in considering my request!

[saikishor]

Hello @Roozter!

I'm still not sure why this has to be dealt with at the transmission level and not at the controller level. @bmagyar Do you think such an interface would be interesting to have in ros2_control?

[gavanderhoorn]

I'm still not sure why this has to be dealt with at the transmission level and not at the controller level

I could think of one advantage (although I'm not necessarily convinced the transmissions are the best place to store this): if controllers are responsible for maintaining this bit of state, each controller would have to be extended to keep it around and take it into account.

If something external to the controllers would be responsible, no changes to controllers would be needed, and all of them would 'work' with such systems that can be calibrated at runtime.

[saikishor]

if controllers are responsible for maintaining this bit of state, each controller would have to be extended to keep it around and take it into account.

Of course, I agree that having these offsets at the transmission level or at lower levels, so that we avoid setting them to each and every controller. My concern is about changing them at runtime at such a lower level. Once, we have the calibrated values, you can always load them to the lower layers and then propagate them to the controller.

I see the point of the ability to change these calibration offsets at runtime to interpret the changes. I'm just worried that any issue with the computations or with some human error in the configuration, the sudden changes in the offsets at such a lower level could be catastrophic. That's the reason, I was referring to having a kind of calibration_controller that allows to update offsets at runtime on top of the state interfaces data( for instance, a joint_state_broadcaster with the ability to update the offsets) so we can perceive the changes in the state with such offsets. Once we have it verified, we set these offsets to the lower level, and then all controllers have access to the calibrated joints data.

If the proposed approach by @Roozter is interesting to you guys, we can discuss it.