Add support for controller variable read/write

[ted-miller]

The topic of accessing robot variables (BIDRSP) came up today.

This is already on our roadmap and should be fairly easy to add.

I think it should go into the next (not upcoming) release.

[gavanderhoorn]

I would suggest to do this for the next-next-next release (so 0.2.1 or something): we planned 0.2.0 to be about updates to the underlying infrastructure (Iron, etc).

[gavanderhoorn]

We may have a potential contributor lined up for this.

I'd suggest we discuss potential implementation approaches here in this issue and continue from there.

---

Edit: starting point for interface definitions: Yaskawa-Global/motoros2_interfaces@main...gavanderhoorn:motoros2_interfaces:variable_rw.

[yeu-geissdoerfer]

@gavanderhoorn I reviewed your "starting point for interface definition".

It makes sense to me. I would like to clearify two points.

1. string message is the written form of the uint32 result_code, so that the user has an human readable error. Did I understood that correctly?
2. Read and write positions only in ROS base frame. This would mean that it is not possible to set a position in a user/tool frame for an INFORM job and simply execute the INFORM job without using the trajectory interfaces. I just want to mention this, since we also talked about triggering INFORM jobs and user frames are used quite a lot in INFORM jobs.

[gavanderhoorn]

1. string message is the written form of the uint32 result_code, so that the user has an human readable error. Did I understood that correctly?

The message field (of type string) is for humans indeed.

The result_code field (of type uint32) is to facilitate (semi) automated error handling.

2. Read and write positions only in ROS base frame. This would mean that it is not possible to set a position in a user/tool frame for an INFORM job and simply execute the INFORM job without using the trajectory interfaces. I just want to mention this, since we also talked about triggering INFORM jobs and user frames are used quite a lot in INFORM jobs.

I'm not against using other frames/origins.

What we'd have to make sure of though is producers/consumers (ie: on the ROS application side) would be able to transform those poses to other frames in their TF tree(s). That would require the ROS application to have access to / knowledge of the frames which could be set in poses returned by the Yaskawa controller (and vice-versa of course).

As I wrote earlier, it's just a starting point. I'd be completely open to changing message definitions.

[gavanderhoorn]

Btw: could I assign this issue to you?

[yeu-geissdoerfer]

You could. I need to see when I have time to implement it.

[gavanderhoorn]

@yeu-geissdoerfer: friendly ping. Have you had any chance to take a look?

[yeu-geissdoerfer]

@gavanderhoorn I wouldn't havet time until early September at the earliest. I will comment as soon as I know for sure.

Regarding the transformation of poses to other frames. This would also require that ROS access the tool data from the RC to generate the transformation from base/robot fram to tool frame for example. In general that would make sense, but I would see that as a second step. How do you see it?

[gavanderhoorn]

This would also require that ROS access the tool data from the RC to generate the transformation from base/robot fram to tool frame for example.

TF could do this. MotoROS2 currently broadcasts it as tcp_N (docs).

For this to work generally we'd have to broadcast all defined tools, not just the active one.

In general that would make sense, but I would see that as a second step. How do you see it?

Perhaps we should then first focus on non-pose variables.

[yeu-geissdoerfer]

@gavanderhoorn we would also need to think about how we handle "figure informations", since this is usually not used in ROS.
Either the user can define these figure informations or we define generally valid default values.

[gavanderhoorn]

We could consider using the approach described here.

[yeu-geissdoerfer]

Instead of the uint32 address in the service definitions I would prefer using uint32 var_number as the MotoPlus API also uses the term variable number instead of address for manipulating variables.

[gavanderhoorn]

Instead of the uint32 address in the service definitions I would prefer using uint32 var_number as the MotoPlus API also uses the term variable number instead of address for manipulating variables.

I would recommend to take my initial proposal from Yaskawa-Global/motoros2_interfaces@main...gavanderhoorn:motoros2_interfaces:variable_rw, push it to your fork of motoros2_interfaces and then open a draft PR against yaskawa-global/motoros2_interfaces. We can then discuss any changes you believe need to be made.