Question: interrupt with GPIO?

[hanschanhs]

Hi - is there support for interrupting/stopping a trajectory sent from a ros2 program with via a gpio directly connected to the arm? Or will I need to pass the signal from the ros2 program (worried that the latency will be too slow)? Thanks!

[ted-miller]

The best method is to utilize the Functional Safety Unit (FSU). This allows an input signal to immediately stop the robot motion, regardless of the commanded trajectory. While the robot is physically stopped, you can pass a signal through the ros2 program to abort the programmed trajectory.

Please contact your local Yaskawa support office for more information on how to utilize the FSU and Safety Logic Circuit. There are some introductory videos available here:
https://knowledge.motoman.com/hc/en-us/sections/4406523431319-Safety

[gavanderhoorn]

@hanschanhs: do you have a requirement for this 'stop' to be safety-rated, or are you trying to implement some sort of part detection / touch sensing?

If the former: @ted-miller's suggestion would be a solution.

If the latter: FSU might not be what you need/want.

[hanschanhs]

Thanks alot for this - yea I'm afraid it will be more akin to touch sensing. We had a ros setup with another robotic arm where a proximity sensor is wired to the arm's gpio pins: there was a ros server which allowed me to query the state of the IO pins, telling me if the proximity sensor is triggered. The latency is definitely not high enough and ideally there would be some way of interrupting the arm directly. Would proximity sensor > custom ros node publishing state > subscriber control node sending trajectories to a yaskawa arm and interrupting it the moment proximity sensor is triggered be fast enough?

[gavanderhoorn]

Would proximity sensor > custom ros node publishing state > subscriber control node sending trajectories to a yaskawa arm and interrupting it the moment proximity sensor is triggered be fast enough?

latency between ROS 2 publisher and MotoROS2 can be very low, but what would probably be even lower latency is to integrate the stop motion logic in the INIT_ROS job.

@ted-miller: would that be possible? Provided the IO is a regular IO on the controller, would changing the state(s) of the IOs waited on in INIT_ROS based on state of the sensor IO be possible?

MotoROS2 would abort the motion/trajectory with an error, but that could be handled by the client script(s).

---

Edit: perhaps even fancier if we could extend MotoROS2 with native support for triggering behaviour (such as motion abort) based on controller-local events. We could perhaps expose a couple of hooks for various behaviour in MotoROS2. We'd have to make sure to notify the ROS 2 side of what's happening though.

Touch sense being one of the use-cases -- which would probably work much better if the round-trip through the Agent and a ROS 2 node could be avoided.

[ted-miller]

We have not tested this specific use-case. But I expect that the latency will be too high for this type of application.

Traditionally, this type of application would utilize a "rapid input" on the servo control board. Then there is a special instruction in INFORM to stop the robot when that rapid input is activated. But this type of functionality is not available in MotoROS2.

[ted-miller]

@gavanderhoorn
I didn't see your response while I was typing mine.

I suppose you could change the WAIT logic in INIT_ROS to monitor a different input. Then when the WAIT logic is aborted, it should stop motion on the arm (with an error).

I don't know what kind of latency that would contain. But it'd certainly be better than aborting the trajectory though ROS.

[gavanderhoorn]

@hanschanhs: just curious: have you been able to make something work?