TRAP_TRAJ trajectory_done flag is set earlier than expected

I’m using ODrive v3.6 with 0.5.6 firmware.
Four motors (over 2 ODrives) are used to command a 3-axis cartesian (1 motor for X, one for Y, 2 for our Z axes, they are stacked one upon the other). The ODrives are commanded in position control mode, with the input mode being TRAP_TRAJ, and with realistic acceleration/deceleration limits, however I reach the problem with gravity affecting those in one direction or the other. The problem specifically is that I’m polling the Trajectory_Done_Flag over the CAN, and wait for it to become 1 before continuing with my program, however it gets raised to 1 before the axis has stopped moving, and in some cases it’s only halfway through the trajectory.

I want my cartesian to execute commands as quickly as possible, thus the accel_lim / decel_lim are aggressive, but realistic. However consider one of the horizontal axes, e.g. X. Its motor is bearing the most load, as it moves all the other axes + the cartesian instrument. The cartesian is not stationary, as it is mounted on a rover-type of robot. If the robot is not standing on even ground, it could be that the X axis is not horizontal, but can be tilted up to 10°. Thus gravity assists motion in one direction, and resists it in the other. The position commands are still executed, however the motor is no longer powerful enough to reach the prescribed acceleration or deceleration speeds (depending on tilt direction).

I pored through the controller code and I see that the trajectory_done_ flags is raised based only on planned timing: the trajectory planner computes the expected time for the move based on the acceleration/plateau/deceleration speeds, computes a total time, and raises the flag when this time elapses. However, if the acceleration phase is slower than expected, down due to reaching the current limit on the motor, then I will get trajectory_done_ raised early: potentially quite early, with the X axis coordinate only halfway through the move (of course the discrepancy depends on the amount of tilt). At least that’s my take on what actually happens.

My inertia config term is 0, I plan to play with that, too, but in general I would have expected the trajectory_done flag to be raised only in the vicinity of the requested position, and possibly computed while the deceleration has started to execute and the controller has seen how it progresses.

What can be done about that? Do I need to move away from trusting trajectory_done?

@Wetmelon Is this a known issue in v3.6 fw / fixed in 0.6.x?

However, if the acceleration phase is slower than expected, down due to reaching the current limit on the motor, then I will get trajectory_done_ raised early

Trap Traj moves must be achievable. Varying too far from the trajectory is considered an error (and we plan to eventually make this a fault state)

@Wetmelon , what are your recommendations to alleviate my issue? Reduce the accel/decel speeds?

Bump.

Any guidance will be kindly appreciated.

Hi, yes, you need to reduce your accel/decel or use a bigger motor :slight_smile: