What is error code 25: Planning Error?

[joshuafishman]

Hello,

We occasionally see a controller error 25, typically when there's nothing obviously wrong. The docs just say this is a "Planning Error" -- what does this mean?

[penglongxiang]

Hi @joshuafishman , for further diagnosis, please download the log package through xArm studio and send it to support@ufactory.cc, please also describe your issue briefly and specify the rough time spot of the situation occurrence. Thanks.

[joshuafishman]

I'll do that, but what does this error code mean in general?
We've only seen it when using DI/O port 4 or when using get_vacuum_gripper in the SDK (although we've never been able to narrow down the exact circumstances, the error doesn't appear when these calls are removed), neither of which obviously has to do with planning.

[penglongxiang]

Hi @joshuafishman , usually this Error would apprear when a path planning calculation is in process. If there is only I/O operation without any motion process in parallel, it is abnormal to me. So it is crutial to send us the log [with rough time spot] for analysis. Would you please briefly describe the program context when this happens? What the program is doing before, after or executing in parallel with the problematic IO operations.

[joshuafishman]

I've sent the log file to the support email, so hopefully that's helpful. The error happens only when we call: code = XArmAPI.set_cgpio_digital(gpio_port + 8, True) #gpio_port = 4 when that port is already set to True, but just doing that in a script is not sufficient to reproduce it. We're also streaming motion commands of the form: XArmAPI.set_servo_angle(angle=target_joints, wait=False, speed=spd, mvacc=acc, radius=50), querying joints and velocities with get_servo_angle(is_radian=True) and realtime_joint_speeds and checking for errors with get_xarm_controller_error_state.

[penglongxiang]

Hi, thanks for the log.

We think the cause would be the combination of radius-blending joint motion with GPIO operation inbetween. Our current design actually does not support this combination, the IO between blending motions will cause a C25 planning error. We will re-evaluate the logic to see if there is any chance for imporvement. It will be hard to decide which point to trigger the IO since it is between a continuous motion and the target before it will not actually be reached.

For now, you may either use radius = -1 (no blending, will decelerate to 0 velocity) if a following IO operation is needed. Or consider the position triggered IO operations (within tolerance radius) if contiouous motion with IO is a must.

Thanks.

[joshuafishman]

That's really interesting, and makes a lot of sense -- thanks for the explanation! On our side, when we send an IO (or similar) command with blended motions, we don't expect any guarantees about when that command will execute within the motion series -- before any motions, after all motions or anywhere in the middle would work. We're basically just trying to maximize rate e.g. turning the vacuum gripper on en route to a pick location through a series of waypoints, so it's possible we can make something work for position-triggered IO as well.

[joshuafishman]

Would you expect a position-triggered IO command with an xyz target of the end of a blended motion segment and a fault_tolerance_radius of the radius for the blended motion to work?

[alonks1234]

Hi, I just triggered this in ServoJ mode. I spoke with @joshuafishman and this seems to contradict the advice given here. Please advise