Derek Schulte: Path Planning for 3D Printers

[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

spaghettiPath 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.

simpleYou 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.

trapezoid[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.

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

kiss[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!


Filed under: 3d Printer hacks, cons, Hackaday Columns

Derek Schulte: Path Planning for 3D Printers

[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

spaghettiPath 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.

simpleYou 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.

trapezoid[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.

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

kiss[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!


Filed under: 3d Printer hacks, cons, Hackaday Columns

Helicopter Pendulum is PID-licious

If you’ve ever tried to tune a PID system, you have probably encountered equal parts overwhelming math and black magic folk wisdom. Or maybe you just let the autotune take over. If you really want to get some good intuition for motion control algorithms, PID included, nothing beats a little hands-on experimentation.

To get you started, [Clovis] wrote in with his budget propeller-based PID demo platform (Portuguese, translated shockingly well here).

The basic setup is a potentiometer glued to a barbecue skewer with a mini-quadcopter motor and rotor on the end of it. A microcontroller reads the voltage and PWMs the propeller through a MOSFET. The goal is to have the pendulum hover stably in midair, controlled by whatever algorithms you can dream up on the controller. [Clovis]’ video demonstrates on-off and PID control of the fan. Adding a few more potentiometers (one for P, I, and D?) would make hands-on tweaking even more interactive.

In all, it’s a system that will only set you back a few bucks, but can teach you more than you’d learn in a month in college. Chances are good that you’re not going to have exactly the same brand of sardine can on hand that he did, but some improvisation is called for here.

If you don’t know why you’d like to master open-loop control algorithms, here’s one of the best advertisements that we’ve seen in a long time. But you don’t have to start out with hand-wound hundred-dollar motors, or precisely machined bits. As [Clovis] demonstrates, you can make do with a busted quadcopter and whatever you find in your kitchen.


Filed under: Arduino Hacks

Fan controller project

pics-lucky-resistor-11-600

Lucky Resistor has written up documentation on his fan controller project:

The fan controller described on this project page, controls one or more PWM controlled 12V PC fans. It uses the input from two precise DHT22 based temperature sensors. The MCU is an Arduino Uno, which is powered using a 12V power source. On top of the Arduino Uno, there is the Adafruit data logger shield — and on top of that is an Adafruit LCD shield. The software is a simple, custom written PID controller.

More details at Lucky Resistor’s project page.

Line Follower with No Arduino

There’s hardly a day that passes without an Arduino project that spurs the usual salvo of comments. Half the commenters will complain that the project didn’t need an Arduino. The other half will insist that the project would be better served with a much larger computer ranging from an ARM CPU to a Cray.

[Will Moore] has been interested in BEAM robotics — robots with analog hardware instead of microcontollers. His latest project is a sophisticated line follower. You’ve probably seen “bang-bang” line followers that just use a photocell to turn the robot one way or the other. [Will’s] uses a hardware PID (proportional integral derivative) controller. You can see a video of the result below.

Looking at how [Will] used simulation to devise a PID with opamps and a PWM generator is illustrative. As you can see from the video, the results are good.

We’ve looked at BEAM before. We’ve even seen mutants that combine traditional BEAM circuitry with microcontrollers. But it’s still nice to see the pure analog version running through its paces every once in a while.


Filed under: robots hacks

See a Cheap Smoker get an Automation Power Up

[Jason] learned a lot by successfully automating this meat smoker. This is just the first step in [Jason’s] smoker project. He decided to begin by hacking a cheaper charcoal-fed unit first, before setting his sights on building his own automatic pellet-fed smoker. With a charcoal smoker it’s all about managing the airflow to that hot bed of coals.

automated-meat-smoker-air-valve
Custom mount for servo was actually one of the more challenging things to get just right.

[Jason] started by making sure the bottom was sealed off from stray airflow, then he cut a hole into the charcoal pan and attached a length of steel pipe. The opposite end of the pipe has a fan. Inside the pipe there is a baffle separating the fan from the charcoal pan. The servo motor shown here controls that valve.

The pipe is how air is introduced into the smoker, with the fan and valve to control the flow rate. The more air, the higher the temperature. The hunk of pipe was left uncut and works fine but is much longer than needed; [Jason says] the pipe is perfectly cool to the touch only a foot and a half away from the smoker.

With the actuators in place he needed a feedback loop. A thermocouple installed into the lid of the smoker is monitored by an Arduino running a PID control loop. This predicts the temperature change and adjusts the baffle and fan to avoid overshooting the target temp. The last piece of hardware is a temperature probe inside the meat itself. With the regulation of the smoker’s temperature taken care of and the meat’s internal temperature being monitored, the learning (and cooking) process is well underway.

There are many, many smoker automation projects out there. Some smokers are home-made electric ones using flower pots, and some focus more on modifying off the shelf units. In a way, every PID controlled smoker is the same, yet they end up with different problems to solve during their creation. There is no better way to learn PID than putting it into practice, and this way to you get a tasty treat for your efforts.


Filed under: cooking hacks