search

Yaskawa-Global / motoros2

ROS 2 (rcl, rclc & micro-ROS) node for MotoPlus-compatible Yaskawa Motoman robot controllers
96 stars 20 forks source link

Add support for controller variable read/write #180

Open ted-miller opened 11 months ago

ted-miller commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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: https://github.com/Yaskawa-Global/motoros2_interfaces/compare/main...gavanderhoorn:motoros2_interfaces:variable_rw.

yeu-geissdoerfer commented 3 months ago

@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 commented 3 months ago
  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.

  1. 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 commented 3 months ago

Btw: could I assign this issue to you?

yeu-geissdoerfer commented 3 months ago

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

gavanderhoorn commented 2 months ago

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

yeu-geissdoerfer commented 2 months ago

@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 commented 2 months ago

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 commented 1 month ago

@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.

image

gavanderhoorn commented 1 month ago

We could consider using the approach described here.

yeu-geissdoerfer commented 1 month ago

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 commented 1 month ago

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 https://github.com/Yaskawa-Global/motoros2_interfaces/compare/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.