Revision history [back]

From what I understood, motion performance using fanuc_driver or fanuc_driver_exp is lower because they use position streaming, so the robot velocity is fixed by the robot controller and there is no "look-ahead" functionality.

The 'fixed velocity' is not really a result of position streaming, it's just how fanuc_driver was implemented. fanuc_driver_exp does pass on velocities (or segment durations) to the Fanuc controller.

The biggest problem with the available implementations is the lack of look-ahead (or: both implementations deprive the controller of the possibility to use its look-ahead functionality, as it only ever has a single PR which is also constantly updating).

Is this the only reason? Generating the TP program offline will still result in keeping the CNT vs accuracy limitation as far as I understand

Whatever interface you use, as long as you use TP programs, there will always be the smoothness vs accuracy problem.

You can mitigate it somewhat by using CR termination types instead of CNT, as the former allows you to specify a radius instead of a percentage, but that is not supported by default in either fanuc_driver or fanuc_driver_exp (there is a branch in fanuc_driver_exp which was the result of some testing, see gavanderhoorn/fanuc_driver_exp@linear_support, which uses CR, but there is still no look-ahead (note: you cannot use the regular industrial_robot_client nor fanuc_driver nodes with that branch, as it uses a custom message type)).

could this limitation be removed some other way?

If "this limitation" refers to the smoothness vs accuracy then fundamentally all (industrial) robots suffer from this problem: smooth motions require continuity (up to the Nth derivative) so with sparse trajectories, you must introduce some form of cornering/blending/rounding (the robot cannot change direction instantaneously). Planners which are capable of taking jerk constraints (for instance) or higher into account and produce dense trajectories might get away with very little blending, but it'll probably still be there/necessary.

Off-line generation of TP programs is not inherently any better. It will however allow the controller to fully use look-ahead, which will improve motion smoothness. Dense trajectories will still slow-down the controller.

With newer controllers and the newest software versions, you have some alternatives to full off-line-and-upload approaches:

• J519 (or Stream Motion): this is a real-time external motion interface which gets you 125 Hz joint and Cartesian position control over a UDP connection. Requires a real-time system and is difficult to buy from Fanuc (except in the US)
• R912 (or Remote Motion Interface): this is essentially a drip-feed for TP programs. Look-ahead works, but same smoothness-vs-accuracy with CNT termination. Main advantage: unlimited program length and programs can be generated on-the-fly

The first allows closed-loop control applications over Fanuc hardware (in the traditional sense of the word, ie: real-time closed-loop in the millisecond range).

The second not really: minimum motion length is 40 ms and there is a minimum queue depth (due to look-ahead requirements).

ROS support for these two options is limited. Or at least: support in publicly available packages is limited.

From what I understood, motion performance using fanuc_driver or fanuc_driver_exp is lower because they use position streaming, so the robot velocity is fixed by the robot controller and there is no "look-ahead" functionality.

The 'fixed velocity' is not really a result of position streaming, it's just how fanuc_driver was implemented. fanuc_driver_exp does pass on velocities (or segment durations) to the Fanuc controller.

The biggest problem with the available implementations is the lack of look-ahead (or: both implementations deprive the controller of the possibility to use its look-ahead functionality, as it only ever has a single PR which is also constantly updating).

Is this the only reason? Generating the TP program offline will still result in keeping the CNT vs accuracy limitation as far as I understand

Whatever interface you use, as long as you use TP programs, there will always be the smoothness vs accuracy problem.

You can mitigate it somewhat by using CR termination types instead of CNT, as the former allows you to specify a radius instead of a percentage, but that is not supported by default in either fanuc_driver or fanuc_driver_exp (there is a branch in fanuc_driver_exp which was the result of some testing, see gavanderhoorn/fanuc_driver_exp@linear_support, which uses CR, but there is still no look-ahead (note: you cannot use the regular industrial_robot_client nor fanuc_driver nodes with that branch, as it uses a custom message type)).

could this limitation be removed some other way?

If "this limitation" refers to the smoothness vs accuracy then fundamentally all (industrial) robots suffer from this problem: smooth motions require continuity (up to the Nth derivative) so with sparse trajectories, you must introduce some form of cornering/blending/rounding (the robot cannot change direction instantaneously). Planners which are capable of taking jerk constraints (for instance) or higher into account and produce dense trajectories might get away with very little blending, but it'll probably still be there/necessary.

Off-line generation of TP programs is not inherently any better. It will however allow the controller to fully use look-ahead, which will improve motion smoothness. Dense trajectories will still slow-down the controller.

With newer controllers and the newest software versions, you have some alternatives to full off-line-and-upload approaches:

• J519 (or Stream Motion): this is a real-time external motion interface which gets you 125 Hz joint and Cartesian position control over a UDP connection. Requires a real-time system and is difficult to buy from Fanuc (except in the US)
• R912 (or Remote Motion Interface): this is essentially a drip-feed for TP programs. Look-ahead works, but same smoothness-vs-accuracy with CNT termination. Main advantage: unlimited program length and programs can be generated on-the-fly
• use the spline motions on V9.30 and up: Fanuc added support for spline motions in V9.30 system software, which is a different interpolation method (from J and L). Instead of considering only the current and next (and next) point, spline motions allow for the definition of trajectories. You essentially control the control points of a spline which runs through all the trajectory points added to it

The first allows closed-loop control applications over Fanuc hardware (in the traditional sense of the word, ie: real-time closed-loop in the millisecond range).

The second not really: minimum motion length is 40 ms and there is a minimum queue depth (due to look-ahead requirements).

The third is different from the first two in that it's not an external interface, but it does affect motion performance: the controller should do much better with dense trajectories as it considers the spline and not the individual trajectory segments when interpolating.

ROS support for these the first two options is limited. Or at least: support in publicly available packages is limited.

From what I understood, motion performance using fanuc_driver or fanuc_driver_exp is lower because they use position streaming, so the robot velocity is fixed by the robot controller and there is no "look-ahead" functionality.

The 'fixed velocity' is not really a result of position streaming, it's just how fanuc_driver was implemented. fanuc_driver_exp does pass on velocities (or segment durations) to the Fanuc controller.

The biggest problem with the available implementations is the lack of look-ahead (or: both implementations deprive the controller of the possibility to use its look-ahead functionality, as it only ever has a single PR which is also constantly updating).

Is this the only reason? Generating the TP program offline will still result in keeping the CNT vs accuracy limitation as far as I understand

Whatever interface you use, as long as you use TP programs, there will always be the smoothness vs accuracy problem.

You can mitigate it somewhat by using CR termination types instead of CNT, as the former allows you to specify a radius instead of a percentage, but that is not supported by default in either fanuc_driver or fanuc_driver_exp (there is a branch in fanuc_driver_exp which was the result of some testing, see gavanderhoorn/fanuc_driver_exp@linear_support, which uses CR, but there is still no look-ahead (note: you cannot use the regular industrial_robot_client nor fanuc_driver nodes with that branch, as it uses a custom message type)).

could this limitation be removed some other way?

If "this limitation" refers to the smoothness vs accuracy then fundamentally all (industrial) robots suffer from this problem: smooth motions require continuity (up to the Nth derivative) so with sparse trajectories, you must introduce some form of cornering/blending/rounding (the robot cannot change direction instantaneously). Planners which are capable of taking jerk constraints (for instance) or higher into account and produce dense trajectories might get away with very little blending, but it'll probably still be there/necessary.

Off-line generation of TP programs is not inherently any better. It will however allow the controller to fully use look-ahead, which will improve motion smoothness. Dense trajectories will still slow-down the controller.

With newer controllers and the newest software versions, you have some alternatives to full off-line-and-upload approaches:

• J519 (or Stream Motion): this is a real-time external motion interface which gets you 125 Hz joint and Cartesian position control over a UDP connection. Requires a real-time system and is difficult to buy from Fanuc (except in the US)
• R912 (or Remote Motion Interface): this is essentially a drip-feed for TP programs. Look-ahead works, but same smoothness-vs-accuracy with CNT termination. Main advantage: unlimited program length and programs can be generated on-the-fly
• use the spline motions on V9.30 and up: Fanuc added support for spline motions in V9.30 system software, which is a different interpolation method (from J and L). Instead of considering only the current and next (and next) point, spline motions allow for the definition of trajectories. You essentially control the control points of a spline which runs through all the trajectory points added to it

The first allows closed-loop control applications over Fanuc hardware (in the traditional sense of the word, ie: real-time closed-loop in the millisecond range).

The second not really: minimum motion length is 40 ms and there is a minimum queue depth (due to look-ahead requirements).

The third is different from the first two in that it's not an external interface, but it does affect motion performance: the controller should do much better with dense trajectories as it considers the spline and not the individual trajectory segments when interpolating.

ROS support for the first two options is limited. Or at least: support in publicly available packages is limited.

I've not tested spline motions in a ROS context yet.