FSU may limit robot velocity and interfere with MotoROS

[gavanderhoorn]

From #245 (comment):

We have recently realized that when the FSU limits the speed of the robot, it reduces the motion command received by ROSi but there is no feedback about it and then the robot doesn't reaches its expected position.

[gavanderhoorn]

@EricMarcil @ted-miller fyi.

[gavanderhoorn]

@EricMarcil: I've never used / interacted with the FSU, but can it set/read IOs on the main controller? Or other variables / flags?

If it can (ie: when it is active or limiting or generally interfering), we could use that to detect it and take appropriate action.

[gavanderhoorn]

@EricMarcil @ted-miller: have you had any more indication that the FSU may be interefering or ran into any issues (or customers)?

[EricMarcil]

Area monitoring and motion range that generate alarm are fine, since it will create an alarm that will completely stop the motion and the alarm status bit will be reported. The system will need to be reset and new motion planned from the current position.

The issue is mainly with the FSU speed limit function. When it becomes enables, the motion commands capped to the speed limit and excess motion is discarted and we don't have any feedback of it. So from ROS perspective, the motion completed properly but the robot is not where you would expect it.

So currently, the recommendation is not to use the FSU speed limit with ROS. You are better off to set the system to alarm. Otherwise, you would need to program the FSU to also generate an output when the speed limit kicks in and seperately monitor that signal (outside of the MotoRos driver or by customizing the MotoRos driver). Since up to 63 speed limits conditions can be programmed using various signals, it is difficult for us to define a generic monitoring system, especially since the FSU is independent from the controller so we don't have the same level of access.

We've put in a request to get new APIs that would allow us to better monitor the FSU current speed limitation but at this time we don't have a timeline as to when it will be available.

[gavanderhoorn]

Thanks for your comments.

The issue is mainly with the FSU speed limit function. When it becomes enables, the motion commands capped to the speed limit and excess motion is discarted and we don't have any feedback of it. So from ROS perspective, the motion completed properly but the robot is not where you would expect it.

If MoveIt is used, the Trajectory Execution Monitor may already have stepped in and cancelled execution of the trajectory as it checks tracking error and if that becomes too large will cancel the goal.

If users send FollowJointTrajectory goals to the action server(s) without MoveIt then what you write can happen, yes.

[gavanderhoorn]

Stupid question: there is no "speed limit (any of the 63) is active" IO signal available then?

[EricMarcil]

There are signals that indicates that an FSU condition is turning on, but we can't know what that condition is. It could speed-limit, range limit, tool orientation limit... and if it is the speed, what is the limit 0? 100? 250 mm/s? We would need to download and parse the FSU configuration files. So it might be possible but difficult. At this time, we haven't had anyone officially requesting this, so it is difficult to justify putting the time and effort into it.

[EricMarcil]

If people are in need of this functionality, let us know. We can then re-assess the situation.

[gavanderhoorn]

No, I was thinking that maybe we could check whether that signal is high/on/true and trigger an error if the FSU is active. As for now we can't know what the scaling is, so if there is any scaling, we could refuse to execute trajectories.

That way we'd at least inform users instead of having them run into the issue and then asking/reading docs.

[gavanderhoorn]

I'll close this for now as we're blocked on the availability of access to the state of the FSU and we don't have an actual report of this being an issue.

If any of that changes, we can revisit (and re-open).

[madsherlock]

We have just tried using the MotoROS robot-side software together with the moto library, and we can confirm the FSU issue.

Our (borrowed) robot had an FSU with an (unknown to us) tool speed limit of 250mm/s, and the trajectory we sent to the robot moved faster than this.

The effect is that the robot doesn't reach some of the trajectory points, without informing the user, and then keeps going while the rest of the program is far from the trajectory - it is similar, but executed in a different position entirely.

We concluded that the FSU was actually potentially dangerous in this scenario.

We disabled it, and then everything was fine*, and MotoROS knew where the robot was again.

*well, it also disabled the safety curtain...

[EricMarcil]

@madsherlock Disabling the FSU is a bit of an overkill. There are many functions (like motion range limits) available in the FSU that are very useful.

You should be able to disable only the speed limit by going to Security security level and then the Safety Function menu. Select the Speed Limit and review the list of the speed limits and set them to Invalid as needed.

On an HC-robots, some of the PFL default limits are all the way to the bottom (file 31 and 32). You can change the speed limit (but I do not recommend increasing it) but cannot invalidate directly. To disable that one, you have to go to the Safety Function - Safety Logic Circuit menu and disable the PFL function by putting a NOT at the beginning of the first line. For more detail refer to manual 181437-1CD (HW1484764) Collaborative Operation Instructions, section 3.3.1. Disabling Collaborative Operation by Changing the Safety Logic Circuit.

Disabling the PFL function of an HC-robot basically makes it a normal non-collaborative robot and people should not be allowed close to the robot while it is running.

Finally, as you change safety settings, a safety risk analysis should be conducted to make sure that the system is still safe to operate.

[cjue]

@EricMarcil:

If people are in need of this functionality, let us know. We can then re-assess the situation.

One of our customers uses the FSU for speed limiting based on a laser scanner, with a slowdown-zone and a stop-zone.

Telling them to replace the speed limiting with "stop the robot" works, but reduces the value and attractiveness of their investment into the robot, the FSU and safety equipment, so they (and we) do need this functionality.

Have there been any changes to the API two allow finding out if FSU speed limiting is active?

[EricMarcil]

@cjue Unfortunately, there hasn't been any changes to the API. I'll try to investigate if I can find some work around... but it's a long shot.

[EricMarcil]

Just an update. I've manage to handle the FSU Speed Limitation inside the MotoRos driver.
It is working well on one axis in the joint space but still has some bugs when multiple joins are being moved (it moves to slowly).
I need to do more testing and debugging but I should be able to post a beta version next week.

[cjue]

Thanks for the update, we are still very interested in that functionality.

We just spent a lot of time to find out why one robot cell sometimes misbehaved, only to find out that a PLC sometimes activated the speed limiter for some seconds without anyone noticing.

[EricMarcil]

So far, I tested moving multiple axes in the joint space for a single robot.
My speed limit was either on or off for the whole trajectory.
I've added code to handle multiple control group but haven't tested it.

Need to test:

• Turning on/off speed limit in the middle of a trajectory.
• Move along a line. Does it still follow the line when speed limit is enabled or does it cause distortion of the motion
• Test with multiple control group.

To Do:

• DX100 support?
• Should we add some flag to notify that speed limit is on?

If anyone has time to do some testing on it and review the code. It would be appreciated.

[gavanderhoorn]

I believe we should also decide what the ROS side should do.

Motion planners/executors like MoveIt will notice a gradually increasing tracking error, and at some point will decide to cancel the motion.

Without some way of MotoROS notifying motoman_driver what is going on, the FSU slowing down things is going to cause a lot of aborted trajectories.

Should we add some flag to notify that speed limit is on?

yes, that would be necessary.

[ted-miller]

@EricMarcil,
Can you open a new PR for discussion/review?

[EricMarcil]

Opened PR #542

[iydv]

@EricMarcil
Any updates on PR #542 ? We are also using FSU speed limiting combined with laser scanners, so this feature is quite important for us.

[EricMarcil]

@iydv Technically, the hard part is done. But as mention by @gavanderhoorn, the motoman_driver would need to be revised. I'm not familiar with that part and was hoping for some assistance. I know that Gavanderhoorn and Ted Miller are focusing on the ROS2 effort. So, if you or someone else are able to help, it would be appreciated.
There was also the question of adding a FSU (Speed Limit) status, I guess that could be added to the SmBodyRobotStatus as:
int in_speed_limit;