infos on io_relay

[GGU23]

Hello,

I am trying to add in the io_relay_node.cpp some code to reproduce the ros services /read_mregister & co.
After looking at the code i wrote those lines to get the value of M010.

  motoman_msgs::ReadMRegisterRequest request;
  request.address = 10;

  motoman_msgs::ReadMRegisterResponse answer;

  io_relay.readMRegisterCB(request,answer);

but I have compilation errors in the catkin_make:

error: ‘bool motoman::io_relay::MotomanIORelay::readMRegisterCB(motoman_msgs::ReadMRegister::Request&, motoman_msgs::ReadMRegister::Response&)’ is protected within this context
   55 |   io_relay.readMRegisterCB(request,answer);

Do you happen to have some examples or documentation on the functions in io_relay ?

[gavanderhoorn]

I'm not exactly sure what you're trying to do. Or more precisely, why you are trying to do this.

What is it you'd like to achieve?

reading/writing M-registers is already fully supported by the provided services:

• motoman_msgs/ReadMRegister
• motoman_msgs/WriteMRegister

after starting the IO relay, a rosservice list should show you the exact service server URIs.

[GGU23]

What I need to do at the end is my own effort control law on the robot. Thus I want to proceed step by step by starting to learn how to read/write in some registers (here the M-registers for safety).

The problem is /io_relay provides a "rosservice", and I can't read/write continuously with it, nor work some code on the data (for example to decode the register data).

[gavanderhoorn]

What I need to do at the end is my own effort control law on the robot.

in the form of admittance control?

The problem is /io_relay provides a "rosservice", and I can't read/write continuously with it

Whether you use the ROS API or the underlying code from io_relay doesn't really change too much I believe. It's still services, only at the Simple Message level at that point.

From your description it sounds like using registers would be a work-around. And not one I would probably recommend.

Currently, MotoROS publishes joint position and velocity (on supported controllers). The code supports torque as well (here), but the Simple Message types used do not at the moment. You could opt to change MotoROS such that it includes joint torque in the joint state messages it broadcasts.

That would probably be a more efficient way -- and one with less overhead -- than using m-registers.

But that's based on what I understand/extrapolate from your terse description.

[gavanderhoorn]

Regardless of how you get the data out of the controller: if you're still going to use MotoROS to actually control motion, make sure to read #458 and #252.

[gavanderhoorn]

Did you manage to make any progress @Waillyam23?

[GGU23]

No, but after deeper discussions with Yaskawa it was confirmed that a real-time control application such as what we wanted was not possible, at least not with satisfying results since the controller only accepts precomputed trajectories as an input.

[gavanderhoorn]

I don't believe that's exactly true, but as I mentioned earlier, there are other things that may complicate what you want(ed) to do (#458 and #252).