Feature request: Jerk limiting

[saosebastiao]

Hi, thanks for the project. I recently bought the dev kit and I’m exploring the code base. One of the things that can be incredibly useful on servo motors is limiting jerk (first derivative of acceleration). On CNC machines, jerk limitation helps remove potential sources of hardware failure, miscalibration, drift, and overshoot. I’d imagine it is also quite helpful with robotics, as those are shared concerns.

There are quite a few CNC controllers which implement jerk limiting, one excellent example being g2core. While useful at the CNC controller level, I think it actually a much better fit when limited at the motor controller level, as it has access to data on current, torque, backemf, and temperature, which could potentially enable more sophisticated control regimes than PID control, such as Model Predictive Control.

I’m still familiarizing myself with the codebase, but would you be willing to accept outside code contributions? I wouldn’t mind giving it a try myself, along with a few other features that I think would be great and potentially worthwhile to other users (for example, integration with OpenCyphal).

[jpieper]

I agree jerk limited trajectories can be valuable!

Well, moteus is open source so even if it isn't accepted upstream and you implement it, you can use it!

Jerk limiting of the trajectory is nominally separate from other more advanced control like MPC, but if you're patient and willing to fit things within the timing constraints and architecture, feature contributions of any sort are certainly welcome!

[thestumbler]

I did a constant jerk in my application. I can see the benefits of having that in the controller, but not sure big of a headache that would be. Interesting, the comment that limiting jerk limit will reduce wear and tear on mechanical parts.

[saosebastiao]

Yeah, Jerk limited trajectories are a different concern than MPC, I guess I'm thinking a few steps ahead. My thought process was if we have jerk limited trajectories, then it would also be useful to add feed-forward control to PID, but it might be better implemented as MPC. Either way, that's just my brain running amok.

Could you elaborate on the timing constraints? Are you talking about meeting the specified control rate?

Also, could you enable the Discussions feature on the repo? I have a few things I'd like to discuss with you or the community, but they're not really a great fit for issues, and I don't want to be a nuisance.

[jpieper]

There are a fixed number of execution cycles available within the control loop. You probably add around 50-100 ARM cycles to the base cycle count without finding ways to speed up other parts. There is a HIL test fixture which verifies that this holds across all the features tested using the following script: https://github.com/mjbots/moteus/blob/main/utils/firmware_validate.py

I'm not going to enable Discussions for now, but there is a Discord which is intended to serve a similarish purpose: https://discord.gg/W4hUpBb

[jpieper]

Given that it has been about a year with no updates, I'm going to close this out for now.