# How do I get cartesian pose from Fanuc robot rather than joint states?

I'm currently using the fanuc_driver package with a real fanuc robot. The robot controller streams the current joint positions, which I can use to compute the current end-effector pose (forward kinematics). However, since this is a real robot with less than 100% calibration accuracy, the values don't perfectly match what I see on the teach pendant. I was wondering if there's a way to get the current cartesian pose of the robot from the controller. Is this already provided by the fanuc_driver package or can I make slight modifications to the package to achieve this? Thanks.

edit retag close merge delete

Sort by » oldest newest most voted

However, since this is a real robot [..], the values don't perfectly match what I see on the teach pendant.

How are you calculating FK? Do you use TF?

And could you quantify how much of a difference you see between rosrun tf2_tools echo.py base tool0 and what the TP tells you?

I was wondering if there's a way to get the current cartesian pose of the robot from the controller. Is this already provided by the fanuc_driver

No, there is currently no support for retrieving the Cartesian pose from the controller in fanuc_driver.

This has been done before though, albeit not in the publicly available version.

can I make slight modifications to the package to achieve this?

"Slight modifications" would depend on your perspective :)

At a high-level, you'd have to:

1. add a new message type and data structure to simple_message (something like a Cartesian pose)
2. update industrial_robot_client to make use of that new message and convert it to a TF broadcast of the base->tool0_controller transform (TF would most likely make the most sense)
3. update the Karel code to:
1. support that message type
2. create and send that message periodically

Definitely possible, but a bit of work.

If you want to do this, I would recommend doing it for fanuc_driver_exp instead of regular fanuc_driver. The code is structured better which would probably make it easier to add additional messages.

PS: I'm working on a ROS wrapper which will publish the state output broadcast by the R891 option. This would allow for very high update rates (up to several hundred Hz compared to the 125 Hz max of Karel) and would decouple this from fanuc_driver and fanuc_driver_exp. No ETA for that though.

more

Thanks @gvdhoorn. It turns out echoing the transforms like you suggested was what I needed to realize there was an error with my URDF, which was what caused the errors. rosrun tf tf_echo base_link link_4 (tf2_tools failed to build on my machine) revealed the error. I corrected the URDF and now the errors are in the order of 0.001mm to 0.003mm. Thanks a lot.

( 2020-06-16 11:40:08 -0600 )edit

there was an error with my URDF

Which URDF are you using?

tf2_tools failed to build on my machine

could you not install the binaries?

I corrected the URDF and now the errors are in the order of 0.001mm to 0.003mm

so your question was actually an xy-problem? :p

( 2020-06-16 11:41:06 -0600 )edit

It's a custom URDF for R2000-210F robot (edited one of the URDFs in the fanuc package and replaced the CAD files).

I tried installing with sudo apt install ros-kinetic-tf2-tools but the 'scripts' folder (which has echo.py) is missing after installation.

It was an XY-problem. I'm really sorry about that. I'll be on the lookout for the ROS wrapper though since I'm looking into the possibility of querying the robot I/O states for another application.

( 2020-06-16 11:55:07 -0600 )edit

It's a custom URDF for R2000-210F robot (edited one of the URDFs in the fanuc package and replaced the CAD files).

would you be interested/willing to contribute that to ros-industrial/fanuc_experimental?

I tried installing with sudo apt install ros-kinetic-tf2-tools but the 'scripts' folder (which has echo.py) is missing after installation.

Ah, I missed you are on Kinetic still. In that case you could indeed use tf_echo from the tf package.

It was an XY-problem. I'm really sorry about that.

No problem.

I'll be on the lookout for the ROS wrapper though since I'm looking into the possibility of querying the robot I/O states for another application.

In the meantime perhaps gavanderhoorn/dominh could be interesting. Or if you have any fieldbus options on your controller, you could use those.

Note that you will need R891 on your controller for the wrapper to work ...(more)

( 2020-06-16 12:01:22 -0600 )edit

Yes, I'm definitely willing to contribute the URDF. It makes use of CAD files from fanuc CRC though. I recall reading a post where you mentioned you were unable to get approval from fanuc to use those. Will that be an issue?

I will definitely check out the RPC interface. Thanks. You've been super helpful.

( 2020-06-16 12:26:30 -0600 )edit

Yes, I'm definitely willing to contribute the URDF. It makes use of CAD files from fanuc CRC though. I recall reading a post where you mentioned you were unable to get approval from fanuc to use those. Will that be an issue?

You would submit the PR with the visual meshes replaced by the collision ones. So both directories would contain the collision meshes.

( 2020-06-16 13:14:33 -0600 )edit

Alright. I'm currently using the visual meshes as collision meshes, so I'll simplify them to collision standard and submit the support package.

( 2020-06-16 15:09:03 -0600 )edit

I'm currently using the visual meshes as collision meshes,

that would be something to fix, regardless of whether you contribute the package.

so I'll simplify them to collision standard and submit the support package.

that would be great.

( 2020-06-17 05:28:31 -0600 )edit