How to make Fanuc CRX-10iA/L move faster?

asked 2022-09-16 15:50:50 -0500

Theodoro Cardoso
20 ●3 ●6 ●10

updated 2022-09-16 17:56:17 -0500

Hi everyone,

I’d like some help with making the Fanuc CRX-10iA/L move faster for a pick and place application.

The robot’s MoveIt package works well, the planner is tuned and outputs nice paths in a constrained space – I don’t think any changes on planning would bring relevant benefits.

On joint_limits.yaml, setting has_acceleration_limits parameter to true and playing around with max_acceleration seems to make the real robot way faster, at the expense of smoothness. However, by doing so the following error from industrial_robot_client: joint_trajectory_interface.cpp appears:

[ERROR] [1663335256.191674382]: Validation failed: Max velocity exceeded for trajectory pt 4, joint 'joint_3'

Velocities are all default (specified in the datasheet) and the problem doesn't happen when has_acceleration_limits is false. How can I fix this?

Given that the speed and acceleration limits on the C++ node and in the TP are set to 100%, what else can be improved to decrease the robot’s motion time from point A to point B?

I’m glad to provide more details as needed.

Thanks!

Comments

It's likely you can't make it any faster. At least not with any of the drivers I've written/maintain. See #q371112, #q390670 and #q318241 for three previous Q&As about this.

It's possible to approach the max performance of the robot, even without some of the more recent/fancy options, but that'd require work (ie: a new driver), and so far no one has made anything available in that direction.

gvdhoorn ( 2022-09-17 00:22:12 -0500 )edit

gvdhoorn,

Suppose we just want to decrease the motion time as much as possible, regardless of smoothness, using the drivers you've written and without off-line-and-upload approaches.

Increasing the acceleration on joint_limits.yaml improved the robot's pick frequency a lot. Is it possible to eliminate the validation error on the original question? Would you have any hints on that?

Theodoro Cardoso ( 2022-09-19 05:36:19 -0500 )edit

add a comment

answered 2022-09-19 11:29:14 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

One thing I could suggest would be to use trajectories which are as sparse as possible (ie: the least amount of points traversing the largest distances possible).

Look-ahead (or the lack of) is much more of a problem with short segments, as the (Fanuc) motion controller cannot properly look into the future to know which acceleration and velocity profile it can use (so it will use a conservative one). Long segments help, as there would be sufficient distance to start going faster.

re: validation error: you could cheat and increase the velocity limits in the URDF. That's the information the validation method uses you show the error of. I'm surprised the validation even works, because in most cases it fails to parse the limits and just gives up.

That functionality is part of industrial_robot_client. The source should show you how it is implemented. Just search for the error message and it should not be difficult to find.

edit flag offensive delete link

Comments

Velocities are all default (specified in the datasheet) and the problem doesn't happen when has_acceleration_limits is false.

a quick comment on this: probably because in that case, MoveIt uses its default of 1.0 rad/s^2, which will make it difficult to reach the specified velocity limits in the first place.

Or if you're willing to spend some time on development: create a ROS driver for Fanuc robots with option R912. That would suffer from all the same issues wrt smoothness-vs-accuracy, but would not suffer from reduced performance due to lack of look-ahead. R912 is essentially a drip-feed for TP programs, and the controller sees "just another TP program". It just happens to be generated "in real-time", by an external entity, over a TCP socket.

gvdhoorn ( 2022-09-19 11:30:45 -0500 )edit

I can confirm that increasing the URDF velocity limits beyond reasonable values got rid of the validation error. Also increasing both the velocities and accelerations in joint_limits.yaml to a large number, like 10000, made the robot way faster and the trajectory much smoother as there are now as few points as possible, just as suggested above.

gvdhoorn, thanks for the help!

Theodoro Cardoso ( 2022-09-22 05:06:29 -0500 )edit

It would be great if you could post a more concrete example of how you changed things, and what the results are. "way faster" is rather subjective, so some numbers (or descriptions including numbers, such as "reduced average trajectory execution by 40%") would be good to see.

In the end it's likely the main result of your changes is for almost all motion segments to have close to the minimum length in terms of time, or the maximum joint velocities all the time (ie: 100%). That's fine for pick-and-place type applications, but obviously not so much for other tasks, which require more continuous, controlled motion.

A wireshark capture of the traffic between your ROS pc (ie: running the driver) and your Fanuc controller would be insightful, as we could corroborate my assumptions.

gvdhoorn ( 2022-09-22 06:23:01 -0500 )edit

add a comment

How to make Fanuc CRX-10iA/L move faster?

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

How to make Fanuc CRX-10iA/L move faster? edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

How to make Fanuc CRX-10iA/L move faster?