Hey folks! Long time fan of Klipper’s architecture! I’ve always wanted thought the same architectural concept would apply perfectly to control servo motors.
That is; do the motion planning in Python on a non-RT host computer and stream the motion profile, ready to run, to the RT MCU on the servo drive.
Custom, well integrated servos have also been a long-time coming project for me, but a couple of friends and I have managed to prototype these little NEMA17 servos with an integrated driver super cheap (~$7 for the PCBA) recently. We’re going to see if we can get them manufactured in small-scale (100~1000) cheap enough for them to be a viable replacement for stepper motors in hobby applications (eg. ~$50 each)
(sorry, I had to split this in two because the forum said new users aren’t allowed to include so many links in one post )
For the control protocol, I’m imagining expressing all the paths as splines or a semantically equivalent piecewise-polynomial. This makes it extremely efficient and simple to compute the target position, velocity, torque, etc… in realtime on the servo’s MCU.
These splines can be computed in numerous ways, but perhaps the easiest (and dumbest) is using something like scipy.interpolate, specifically probably scipy.interpolate.make_interp_spline, because it means we can set the dimensionality to the number of servos we’re trying to control and the degree to meet our smoothness needs (eg. jerk control). I’m sure this has issues with cornering accuracy etc… and isn’t optimal, but might provide a simple starting point
Once they’re computed, we can express these paths to the servo’s MCUs as the coefficients of the polynomials + the start/end time of each piece.
On the MCU we can, trivially, take all the derivatives of our polynomial required to implement feedforward controls like shown here:
We can also easily do a cascading PID control loop as they describe earlier!
I’m here posting looking for 3 things:
Collaborators experienced with Klipper
Feedback on the design thus far
A gauge on excitement at the future of servos!
Looks like it’s very similar in concept to the suggestion here.
Do you know if the project got much traction at all? I notice there hasn’t been any commits on the branch recently?
We’ve been working on some BLDC servos that are coming out pretty inexpensive (~$30, motor and all!). If you’ve got the right experience and you’re keen to join in perhaps we could send you some once we get them?
Interesting. I’d be curious what chips you plan to use on the board you are designing.
I have spent a bunch of time on “stepper servo” support in the past. Both in prototyping of “mechaduino support” and in implementation of magnetic hall sensors for precise stepper axis position monitoring ( Configuration reference - Klipper documentation ).
Unfortunately, due to time constraints on my side, I don’t think I’ll be able to contribute to any new efforts in this area in the short term.
I can share a few high-level thoughts that may (or may not) help:
Consider reading through all the threads that have linked to Mechaduino experiment (as found immediately after the original post at that link). This topic has come up a few times before, and there have been several different ideas on the approach.
For what it is worth, I’m no longer convinced that a PID position/command feedback loop is a good idea. The concern is that if the motor over shoots a desired target then it will result in a print blemish, and commanding a return to the actual desired target will not undo that blemish, but is instead likely to make the blemish more noticeable. This, I believe, is what leads to the “salmon skin effect” that is a common complaint with past servo steppers implementations.
In contrast, it may very well be worthwhile to build some type of “overall feedback loop” so that, over extended time periods, the printer learns not to “overshoot the target in the first place”. That is a lot of work though.
If interested in utilizing velocity and/or acceleration in determining motor control, then the best way to do that may be to reuse the existing host kinematic system and calculate the desired velocity/acceleration from the existing queue_step commands that are queued in the micro-controller. That is, the Klipper host code already queues upcoming motion in the micro-controller 100+ms prior to it being used. It should not be difficult for micro-controller code to inspect that queued movement to obtain velocity and acceleration.
)
