ROS Driver on Fanuc R-J3iB? [closed]

[marabount]

Hello,

I would like to test the ROS driver on the Fanuc M6iB robot with an older R-j3iB controller. Some relevant information about the controller:

Core software version: Handling Tool 6.4
Socket Messaging (SKMG), includes MSG_CONNECT, MSG_DISCO and MSG_PING: Installed
PC Interface (PCIF): Installed
KAREL (KARL): Installed (not sure about the version, but I can check)
ASCII Upload (ASBN): Installed.
Is it possible to tweak the ROS driver and recompile it for R-j3iB? Maybe somebody has tried this already and can help.

Regards,
Alex

[gavanderhoorn]

NOTE: be careful when trying out the branch I link to below.

Even though I've not had any reports about problems with it, and I've tested it in Roboguide, this was all back in 2015. The code looks sane enough, but as always with industrial robots, be sure to test it while observing all safety requirements.

---

Original comment: As I replied on your ROS Answers question, we've had some people try to use fanuc_driver on R-J3iB and older.

The changes I made are still available here: melodic-devel...gavanderhoorn:v611_karel_moveto.

That's for V6.11 specifically, so it could be that V6.40 doesn't need all of those, but this might form a good starting point.

Biggest differences with HEAD:

• uses Karel MOVE TO statements for motion, instead of TP motions
• doesn't use TP RUN(..), but a small Karel program that calls RUN_TASK(..) (as the controller I created that branch for didn't have the multi-tasking option installed)
• disables colours in log lines (no iPendant)
• doesn't monitor all requirements for motion like current HEAD does

My recommendation would be to start with the state relay side: compile all the Karel programs and see whether the socket infrastructure works correctly in that. If you get no complaints (ie: Karel errors) try to use the robot_state_visualize_m6ib.launch file to check whether what RViz shows corresponds to your real robot.

Also check the output of rostopic echo -c /robot_status. It should update properly according to the state of the R-J3iB (ie: e-stop, errors, drives powered, etc).

If that all works, there is a reasonable expectation the trajectory relay could work as well.

NOTE: make sure your controller only has a single motion group configured/active. Fanuc has been advising against using MOVE TO for years, and warning against using it on controllers with multiple motion groups. The branch I link to does use MOVE TO, so to avoid any surprises, only use it with controllers with a single motion group.

[MOAMIndustries]

Do you expect to be able to do closed-loop control?

No, i expect the controller to handle that part but it would be very useful to see what the load is on the motor at any time, especially if we can dump that into a bag file

you must have R648 (User Socket Messaging).

Are the R numbers configurable software options when the controller is purchased? Or is this a dedicated hardware module?
Essentially, should I expect this to be included or not.

I'll aim to get something with Karel to play it safe. Thanks for getting back so quickly.

[gavanderhoorn]

it would be very useful to see what the load is on the motor at any time

motor currents is not something fanuc_driver reports by default, so that would have to be added.

Note also: I'm not exactly sure there is a system variable for that you can use on V6.x controllers.

Are the R numbers configurable software options when the controller is purchased?

Yes. All of these are software options which must be present on the controller.

Essentially, should I expect this to be included or not.

Afaik, User Socket Messaging is not an option included by default. But I have limited experience with controllers older than R-30iA, so I can't say for sure.

With Fanuc, the question "is this included by default or not?" is probably always best answered: "no, not by default". Or at least, that's what I always assume. If it turns out something is included, it's just a pleasant surprise.

But always ask. Your vendor should know.

[MOAMIndustries]

With Fanuc, the question "is this included by default or not?" is probably always best answered: "no, not by default". Or at least, that's what I always assume. If it turns out something is included, it's just a pleasant surprise.

🤣

Gotcha, and this isn't a surprise really. Apparently many of the machines in the factory these were removed from have DeviceNet or Profibus add-ons as well. I suspect they may not be helpful with ROS though.

[gavanderhoorn]

Apparently many of the machines in the factory these were removed from have DeviceNet or Profibus add-ons as well

well not with the fanuc_driver we provide in this repository, no.

You could theoretically use them, but it would require substantial changes to various parts, both on the ROS side as well as the Karel side.

A network connection (which is sort-of implied by the presence of User Socket Messaging) makes it trivial to exchange arbitrary strings of bytes. We use that to transfer data in both directions (ie: ROS<->controller).

A fieldbus (like Profibus) can be used for this, but they are typically more geared towards synchronisation of a "memory image" (ie: a set of words or bytes). That makes it slightly more complex to exchange 'streams', as you'd have to come up with a way to implement streaming semantics, or map things to static locations in that memory image and then use some sort of state machine to indicate presence of new data (ie: toggling bits to implement a hand-shake).

All possible, but not supported by what fanuc_driver does right now.

[gavanderhoorn]

And just to be completely clear: fanuc_driver is not the most performant way to control a Fanuc externally.

It's mentioned in the readme of the package, but I want to make it clear that it's mostly suitable for pick-and-place type work.

It's been a long time since I've used MOVE TO, so performance could be somewhat better than the TP based version used on R-30iA and newer, but I don't expect you to reach 'native' performance.

[gavanderhoorn]

Reason to check state reporting first is also to make sure #105 isn't actually an issue on your controller.

RViz would not be able to correctly visualise your robot if there is a problem with the deg -> rad conversion.

[gavanderhoorn]

@marabount: have you been able to test the branch I mentioned?

[gavanderhoorn]

Have either of you @marabount / @MOAMIndustries been able to test the V6.4 compatibility branch?

[MOAMIndustries]

I have not yet, but may be able to in the coming weeks. I'll let you know if I do

[gavanderhoorn]

Seeing as there is no activity here I'm going to close this discussion.