ROS control using Fanuc's external "Stream Motion" protocol

[jonbinney]

From talking to Fanuc, it sounds like they've recently rolled out an external control protocol that they very descriptively call "Stream Motion". Has anyone tried writing a ROS driver based on this, or have any experience with it? If it sounds promising but doesn't yet exist, we could potentially help write such a driver.

[gavanderhoorn]

Has anyone tried writing a ROS driver based on this, or have any experience with it?

Yes, and yes.

That's about it for now.

[ghost]

@gavanderhoorn Hello, I wonder if there has been an update on the "stream motion" development for the FANUC robot?

Thank you.

[gavanderhoorn]

What sort of update are you looking for specifically?

Right now I have nothing I can publicly release, if that is what you were wondering about.

[ghost]

@gavanderhoorn

Thank you so much for your quick response. We are wondering if there has been an update the FANUC stream motion or DPM based driver such that we can do real-time force control with it.

But I guess you have answered my question. Thank you again for your help.

[gavanderhoorn]

We are wondering if there has been an update the FANUC stream motion or DPM based driver such that we can do real-time force control with it.

A bit of expectation management: J519 only allows position control.

[gavanderhoorn]

First step: gavanderhoorn/packet-fanuc-stream-motion-j519.

[gavanderhoorn]

Update: I'm working on making a ros_control-based driver available for controllers with J519. Right now that includes a hardware_interface and a simple configuration with a joint_trajectory_controller. Cartesian control will be added later.

A primitive version currently works quite ok, and work now focuses on embedding a state machine so that multiple IBGN sessions can be handled natively on the ROS side (ie: start, stop, start again, stop, etc), instead of relying on full restarts.

[oliverz21]

@gavanderhoorn Thank you for your work. I am wondering if you have any update on the controller with J519 that you can share right now. Thanks again.

[gavanderhoorn]

Unfortunately not right now. We're in the process of refactoring some parts, and until that is done I cannot release it.

Code is being evaluated by multiple companies and organisations, and they appear to be quite happy with the performance. The biggest issue right now is the jerk-limited requirement on trajectories, which none of the time-parameterisation plugins (for MoveIt fi) is. Other planners and/or parameterisation approaches are needed, and are being worked on in parallel to driver development.

As a small note on performance: we've been able to get the robot to 100% easily.

[jdzied]

@gavanderhoorn Very nice to hear. Did you manage to use the "Calculation of Acceleration and Jerk limits" with packet_type 3? According to Fanuc the current limits can be received in realtime, but I could not get any response from the robot with packet_type 3 and protocol version 2.

[gavanderhoorn]

@jdzied: right now the driver doesn't support protocol version 2, so I'm afraid I cannot help you.

We will be adding support for newer versions though, but right now I don't have access to hw that runs that version, so I can't test it.

[asierfernandez]

This new driver looks very promising.

In Tecnalia we've been playing with the fanuc_driver and some custom code, but we didn't succeed on having a smooth trajectory motion.

@gavanderhoorn we are interested on testing/developing such driver. Is there a way we could try it?

[gavanderhoorn]

@asierfernandez: contact me via email and we can discuss your request.

[EdsterG]

As a small note on performance: we've been able to get the robot to 100% easily.

Was this compared to the stream motion limits or compared to robot motion generated via a pendant program?

[sharma409]

@gavanderhoorn i've got the same question as above ^

I can't seem to hit the same speeds as pendant limits

[SepehrGharaaty]

@gavanderhoorn I was wondering if you have finished the controller for MotionStream ? I would like to know more details about driving the robot using MotionStream. Thanks

[gavanderhoorn]

All currently available software has been moved to the fanuc-stream-motion organisation.

Further developments will also appear there.

As such, I'm closing the issue here.

Note: even though it's a Github organisation, and not a personal account, there is nothing official about the software hosted there.

As always, everything there is community contributed and will depend on the community for support.

This is no different from how Fanuc has treated these kinds of efforts so far.

[liyipeng2023]

Unfortunately not right now. We're in the process of refactoring some parts, and until that is done I cannot release it.

Code is being evaluated by multiple companies and organisations, and they appear to be quite happy with the performance. The biggest issue right now is the jerk-limited requirement on trajectories, which none of the time-parameterisation plugins (for MoveIt fi) is. Other planners and/or parameterisation approaches are needed, and are being worked on in parallel to driver development.

As a small note on performance: we've been able to get the robot to 100% easily.

The joint positions can be obtained in real time and the motion command also works by using the J519 option (thanks to the protocol presented in gavanderhoorn/packet-fanuc-stream-motion-j519). However, I can only control the robot with a very slow trajectory (e.g., q_offset+5sin(0.01t)). When using a faster trajectory (e.g., q_offset+5sin(0.1t)), I will get a warning code named 'MOTN-611' and the robot will stop. Could you help me to resolve this issue. Thanks a lot.

[gavanderhoorn]

J519 is extremely sensitive to jerk, and you have to make sure your trajectories are absolutely smooth, and jerk-limited.

Older system software versions would give you a static set of velocity, acceleration and jerk limits, and you had to make sure your trajectory did not violate those.

Newer versions (ie: anything released this year) use dynamic acceleration and jerk limits. You have to interrogate J519 to give you those limits, and scale your trajectory accordingly.

If you don't, you'll get errors and controlled stops.

[liyipeng2023]

Thank you for your response.

[sshazly]

I want to write my experience here in the hopes that someone has had a similar experience or has had success in fully commanding a real or simulated robot through roboguide.

I first started testing StreamMotion through roboguide, it took a while and I had to do a lot in order to get just a single joint moving. The first thing I noticed is that in the documentation it says that the communication interval (8ms or 4ms) is used to calculate the vel/acc/jerk. What's interesting about this is that roboguide, in my case, was running on a windows 11 computer which is decidedly not real-time. In my initial tests I had a separate Linux computer with the rt kernel enabled commanding roboguide on windows.

In my linux code I printed to the screen only when 10ms was violated. Even with a super slow trajectory I could trigger that jerk limit error by spam clicking roboguide, which slowed down the actual comm-interval to sometimes as high as 0.25 seconds... but stream-motion still assumes 8ms updates during calculations so I'm guessing that's why I was getting jerk-limit violations.

I went into Windows and changed roboguide priority to realtime and saw a drastic improvement as long as I did not click on the application. But eventually I would still see jerk limit violations, which was always preceded by violations in the 8ms communication interval.

So I said fine, I'll just try it against the real robot since that should be real-time... I can tell you I am WELL below the jerk limits that I query on initialization (I hard-coded it to be 1/10th the smallest axis value, after getting frustrated) and I'm a bit lost about why I am still experiencing jerk limit violations. Is there any guidance on how they are calculating jerk limits? Could it be lost packets? The previous contractors did not use shielded ethernet cables so that's the next thing I'll try to fix...

This whole experience has been a bit frustrating and I'm hoping somebody has had some success out there and maybe I need to reevaluate my math, but I really don't think I'm incorrectly limiting my jerk since I was only getting violations in roboguide when the com interval was larger than 10ms. Hoping @gavanderhoorn has had success and can give me some hope here.

[gavanderhoorn]

I'm afraid I can't really give you any easy solutions.

J519 is/can be very finicky about the trajectories and the velocity/acceleration/jerk profiles you send it.

In the limited time I worked with it, I've also had the controller unexplainably 'refuse' to execute certain motions -- but I was on a rather early version of Stream Motion, even before the type 3 packets allowed to retrieve the 'dynamic' limits, so we assumed there were still problems with the option itself.

Have you tried reaching out to your local Fanuc branch office? Depending on where that is, they should be able to help you. I've talked to some pretty knowledgable people.

Overall J519 can be very powerful, but it's definitely not the easiest remote motion interface for industrial robots I've worked with.