Notes on a possible Input Shaping Implementation

poofjunior

Hey folks,

I would love to see input shaping implemented on the Duet. So I read-up on the math and took notes on how to do it fast on standard resource-constrained hardware. In a nutshell, I wanted to really "see" what was happening to the position signal when we apply input shaping to it.

My "crash-course" notes on the math are here:
https://github.com/Poofjunior/input_shaping_notes/blob/main/input_shaping_and_modifying_kinematics.ipynb

In short:

Input Shaping requires running all position curves through a convolution with a special impulse sequence signal.
The impulse sequence signal requires measuring the natural frequency for each axis. Printer owners will need to run some sort of "self-test" routine with an accelerometer to collect the machine's impulse response.
Convolution is a pretty resource-intense operation, but since our second signal is an impulse sequence, the math simplifies dramatically and is actually pretty fast.
Technically, we're convolving our impulse sequence with our acceleration signal, but it turns out that it's equivalent to convolve the impulse sequence with either velocity or with position, so convolve with whatever's convenient.
because our position signal is convolved with an impulse sequence, it's impractical to solve for the inverse function (i.e: time as a function of position) analytically. But an iterative solver really shines here.

I'll bet you'll get a lot of requests for this feature in the future, so I hope this helps the folks doing firmware digest what's actually involved in coding it up!
(And if someone wants to point me to where in RRF that step times are being calculcated, I might just give this a go in a few months.)

Finally if you have any questions on the math, feel free to reach out!
Cheers!

bot

Have you seen this thread by @DigitalVision?