First: let me start by saying this answer is based on my personal understanding, which is based on a few years of experience with Fanuc robots and writing external trajectory generation programs (or drivers) for them. I could be completely wrong, or have misunderstood some critical aspect of how they work. Keep that in mind when reading this.
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 ...
(more)
