Feature request: Jerk limiting about moteus

[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]

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.