[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.
The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)
The Problem
Path planning goes on inside the 3D printer itself. It’s what the 3D printer’s firmware does with the received G-code that turns it into the physical motion of motors along the X, Y, and Z axes as well as the extruder. While G-code is universal, it’s also unrealistic: it specifies a series of points in 4D space (the extruder, remember?) and the speeds that are needed to get there. Path planning blends knowledge of the physical printer’s motion control abilities and tries to make the end result match the G-code as much as reasonably possible, without taking forever. Being the interface between idealized G-code and a real printer, the planning firmware needs to take the design of the printer itself, with all its physical limitations, into account.
You can make your own, one-off, 3D printer out of unobtainium, dragon scales, and the unbilled labor of a year’s worth of weekends. But if you want to make a product to sell to the general public at a reasonable price, it’s got to be built using commodity parts and work robustly. This is what drove [Derek] to use a DC motor with an encoder instead of the ubiquitous, heavy, and relatively expensive stepper motors that most other 3D printers use. Driving DC motors in open-loop feedback meant that none of the “standard” printer firmwares were going to work — he needed to roll his own. And that’s how we have this talk, about getting from A to C, around the corner in B, as quickly and accurately as possible.
Trapezoids, and the KISS Principle
There are a few ways to turn a piece of G-code that says “go north at 50 mm/sec and then go west at 50 mm/sec” into machine movement. One is to go north at full speed, slam to a stop, and then jerk off west at full speed. This is what the earliest versions of DIY 3D printer firmware did — and the result was noise, and vibration of the print head, and degradation in print quality. These were ugly times.
[Derek], and the path planner in grbl, chose the next most complicated solution — moving at constant acceleration for each segment of the path, resulting in trapezoidal velocity profiles. This turns out to work decently well in practice and be easy to compute. [Derek] added corner rounding to the routine: where the G-code said to make a sharp corner, the firmware would take a curved corner that’s close enough that it wouldn’t look bad, but also doesn’t require the nozzle to slow to a stop. Combining the two is basically the simplest solution that can work well.
Connecting a few segments together is the next step, but it lets the printer eventually come to a stop, whether at the end of the path or because a user pressed the pause button.
Closed-loop Control
Most stepper-driven 3D printers operate in open-loop control mode. The firmware tells the stepper motor driver to take ten steps forward and hopes for the best. When a printer loses steps, layers get de-aligned from each other, and if you’ve had this happen catastrophically in the middle of a print, you know why this can suck.
[Derek]’s printer runs in closed-loop mode, meaning that if the printhead is too far south of where it should be, the firmware can tell that this is the case and apply more power to a motor to get it back right. Again, [Derek] chose one of the simplest methods that could work: PID control with feedforward. Of course, this means calibrating the algorithm to the machine, but a well tuned PID algorithm is a joy to watch.
And the closed control loop provides additional benefits. Where stepper motors have to be way overspecified to avoid the dreaded missed steps, closed-loop DC motors can get by on lower torques. The coolest trick that [Derek] plays with the feedback, however, is in using the ability to detect motor stall to home the printer. There are no limit switches on the three physical axes. Instead, when the motor hits the end of its ability to move, the firmware detects the stall and uses this to zero the coordinate axes. This reduces parts and simplifies the device. We’re all for that.
Conclusion
[Derek] designed his motion planning routines on the same tools that we all use, and used basically the simplest possible algorithms that would work well, avoiding “academic” complications for their own sake. In the end, this allowed him to optimize for speed, look fifteen steps ahead, include some necessary special tweaks like logic for dealing with very short segments and get the product out the door for a reasonable price. Motion planning and control in a closed-loop system is never simple, but “apply the KISS principle as far as possible and then tweak for performance later” is something that all of us hackers could stand to get tattooed on some suitably long part of our bodies. Better still, let’s just thank [Derek] for the reminder and exemplification!
