Automeat - Part 3: Massflow Subsystem and Live Fire Testing

Continuing my series on developing Automeat, my charcoal smoker automation project, I will explain the way I built the massflow subsystem which turns a requested airflow into a windy reality.

Fan Setup

a picture of 3 different sizes of blower fan

I ordered up three sizes of Delta blower fan and after playing with them on my desk to get a feel for their noise levels and flow decided to go with BFB0712HH, the middle option of the three.

I modeled the blower from drawings in its datasheet and grabbed a STEP file from Sensirion for the MAF and used those to design a test piece to mate the fan to the MAF. I iterated on this piece a couple times while working on the massflow subsystem in order to make it more friendly to FDM printing. It’s currently in a state that works and prints with good quality quickly. I intend to change this part later in development but the current version is appropriate for testing and experimenting. on the left a 3d CAD model of a manifold piece, on the right a picture of a partial print of that same manifold with a blower fan mounted on it

Implementing The Massflow Subsystem

As mentioned in prior posts, the massflow subsystem is one of two PID loops running in automeat. This was the first major chunk of the overall system I worked on as it is easy to do as a standalone piece and uses components that will be needed elsewhere. Most of my time spent here was reading documentation because it turns out that implementing a PID is incredibly simple. It involves no tricky math – just basic addition, subtraction, division, and multiplication. I had always imagined there was more under the hood when tuning PIDs for things like drones and printers but that simply is not the case. I packaged a basic library up and named it PIDBULL because I am not a serious person and it gave me an excuse to write myself little jokes in the code

1
2
//MR WORLDWIDE
pidbull masspid(0.03, 0, 85, 0.85, 0.02, .005); 

Moving along, I opted to use the built in LED PWM functionality (driver/ledc.h) to slap together a simple library and give myself an easy interface for spinning up fan objects and adjusting their duty cycles. This also allowed me to shove the boilerplate initialization and configuration for ledc timer configs out of sight, keeping the main code cleaner. Yes, I named it pwmfan.cpp.

Tuning Massflow

Prior experience with trying to keep my quadcopters horizontal was useful in getting the first rough tuning going for massflow but I wanted to do a better job. I peppered print statements through the code and then piped them over to Touchdesigner via USB serial. Touchdesigner is great for rapid and visual crunching of data like I needed here, ingesting a long string and parsing it out into manipulable data and live graphs in real time. At this point I was able to quickly visualize system behavior and dial in my PID gains more effectively.

network of touchdesigner operators being used to visualize massflow system data

The limiting factor now is mostly turbulence. Massflow is pretty good at staying within a single data point (in this case 1 L/min) of the setpoint while still reacting very quickly to perturbances. It seems that smoothing out the final bit of oscillations may be difficult without either slowing the system’s response time to disturbances or reducing flow in order to make it less turbulent. With typical flows in the range of 10-100 L/min for this application a wobble of 1 L/min from setpoint is a very small deviation and averages out fully over the time scale of smoker operation. I will revisit it in the future but am happy with the state of this part of the system for now.

Plumbing

My goal with attaching to my smoker was to completely avoid permanent modifications of any kind. I like the idea of being able to fully revert to manual operation and original form. Some research around how others have solved this problem led me to universal adapters available for other commercial systems. I decided to use them as inspiration and procured a metal dog bowl. Because the body of the smoker is roughly spherical at either end, a bowl mates up quite well over the top of one of the air inlets. I ordered up some bolts and wing nuts to clamp the bowl in place and designed a printable part to attach a hose to the dog bowl after drilling a large hole in it. This is not the most elegant of solutions but it was cheap, quick, and effective. The printed part is not exposed to noteworthy heat so no issues there. Iterating on this particular part is one of the lowest priority items on the project as its primary flaw is ugliness.

model of an adapter piece on the left, the printed part mounted to a dog bowl on the right

Empty Fire

With massflow working I set out to collect some test data. I hardcoded a setpoint and lit a load of charcoal in the empty smoker. Using my laptop as a serial monitor and tee to dump to a logfile I was able to collect data for later analysis. Changing the setpoint required editing the hardcoded value, recompiling the code, and reflashing the controller. Inelegant but field-expedient, and the dead time while reflashing is fast enough to not affect the burning fuel. I tried running very little airflow, a lot of airflow, and shifting flow drastically between low and high to collect something akin to impulse and step responses. I cleaned up this data to create a CSV file and then wrote a little python script using matplotlib to handle graphing and scipy to smooth the data with a butterworth filter. The resulting graph is quite easy to understand and gives insight into how things are working.

graph showing temperature and airflow during a test run

The Dark Magic of Tuning

From here I spent time reading about how to characterize systems (a “plant”) from their step responses and researched how people handle this sort of thing in the real world. While it seems academically proven that a transfer function can be derived from analyzing the open-loop step response, either I have not accumulated enough skill points to use this ability or the reality of my system is not so simple as the equations would suggest. I tried following the Ziegler-Nichols method and found that it was wildly inappropriate for this application and provided results worse than even the guessed gains I first tried.

Further reading suggested that in many cases there is a certain art to working with real world systems and that I would not necessarily be wrong for feeling that it is most efficient to focus on logging and visualizing data for tuning by hand.

I’ll stop here and save the combustion system tuning for a later post as it is an interesting topic on its own.


stan
WRITTEN BY
stan
serial project starter