Fanuc post-processor

[Victor L]

Hello,

I'm computing and simulating "complex" trajectories with ROS but I need to execute them with a native Fanuc TP program because:

- I need to modify robot I/Os during trajectory

- I need to control the robot velocity

The ROS Fanuc driver does not allow that.

The difference between the ROS simulation and the real robot trajectory is not an issue, it is just supposed to give an overview of where the robot will be and how it will move.

Using the ASCII Upload option we can upload (FTP) text files (.LS) and they are compiled by the robot controller.

Has anyone developed a post-processor to convert ROS trajectories into Fanuc TP programs ?

Bye

[G.A. vd. Hoorn - 3ME]

On 1-3-2016 15:46, Victor L wrote:
> Hello,
>
> I'm computing and simulating "complex" trajectories with ROS but I need to
> execute them with a native Fanuc TP program because:
> - I need to modify robot I/Os during trajectory
> - I need to control the robot velocity
>
> The ROS Fanuc driver does not allow that.

[..]

Just some related info:

- re: io: another user of the driver is currently working to implement
the candidate rep we have, that would allow IO interfacing. If you have
serious needs (so not 'enable/disable single io every now and then'),
I'd seriously consider using a fieldbus, not a software only solution.
- re: velocity: the Fanuc driver can do that, just not the default
version.


Gijs

[Victor L]

I started a project here:

https://github.com/InstitutMaupertuis/fanuc_post_processor

Feel free to contribute!

[Huang Yijiang]

Hi Victor,

Thanks for your great work! 

Currently I'm working on kuka robot and have little experience on fanuc, but based on my understanding,

the idea of this fanuc post-processor is very similar to the "kuka krl file parser" that I proposed in kuka_experimenal issue[1] - to "translate"

ros-generated trajectory into vendor-specific robot language that can be uploaded (or simply copy into controller manually) and compiled by the

robot's controller (fanuc's or kuka's KRC). Thus I think your great work might be a good reference and template for a "kuka_post_processor".

I have a few questions:

- how do you control the robot's velocity in this way? in kuka's language KRL, without using ros, we can sepcify the speed of the end effector and let the

robot to execute a cartesian path (e.g. straight line) by simply writing:

$VEL.CP=0.002

LIN {E6POS: X 538.92, Y 39.451, Z 26.35, A 89.997, B 34.644, C 10.439, E1 0, E2 0, E3 0, E4 0} C_DI

   But as the generated trajectories are joints' values, velocities and efforts, how do you do this?

- In application without the need of feedback (especially suitable for post-processor method, an offline planning and execution), we need to correctly weave some 

digital/analog IO commands with trajectory, e.g. the end effector is a pneumatic gripper that can be turned on and off by setting IO port 0 in robot's controller. Have 

you encountered some problems like this in your projects? 

Thank you for your contribution and discussion!

Best,

Yijiang 

[1] https://github.com/ros-industrial/kuka_experimental/issues/81

[Victor L]

Hi

We are working with Fanuc robots and we have one Kuka robots (though I have never used it).

I think we should not continue in the way I did the fanuc post processor; it works and it is perfectly usable but the ideal thing would be to have a common interface to generate programs for all robots.

To answer your questions:

To control the velocity, our applications using the post processors have a Qt interface asking for the desired linear speed. Then the post processor uses this parameter and generates a program containing linear motion (not joint motion, otherwise you can't specify a metric velocity).

The ROS trajectory message itself is not enough, you need a "richer" message that contains velocity etc..

Yes we use a lot of DI/DO on the robots to trigger the laser, start sensors recording etc.. in our laser applications. (we did not use this at all with the grinding project). The post processor allows to insert special commands like "append digitial output" etc. This way we can trigger things related to the robot or wait for digital inputs to continue etc.

In the long term the best thing we can think of is having the RoboDK post processors us-able as a ROS service. If you are interested in that take a look at the repository and try to find a nice solution to get things running:

https://github.com/ros-industrial/robodk_postprocessors

Bye