High-Speed 3D Printer with Distributed Computing

I created this high-speed 3D printer out of curiosity to see how far I could push an Ender 3 clone (Voxelab Aquila). The goal was to create a system that would work with the existing printer hardware while adding extra computational power. The printer's internal MCU handles motor control and reads limit switches, while computationally heavy tasks like path planning, acceleration calculations, and G-code preprocessing are offloaded to a Minnowboard or Raspberry Pi cluster. This architecture allows for significantly faster printing without overloading the printer's built-in controller.

Features

• 508% increase in printing speed over stock Voxelab Aquila configuration (tested with standard PLA with 58% relative humidity)
• Physical cooling system improvements designed for high-speed extrusion and rapid layer cooling
• Web interface to control cluster, monitor print status, and send G-code files remotely
• Automatic MMU (Multi-Material Unit) control for multi-material printing with filament switching
• Support for multiple filament types during single print job with automatic material transitions. (Utilizing custom MMU)
• Real-time temperature monitoring and adjustment based on print speed and material

Hardware Setup

Voxelab Aquila setup with external computational offload using minnowboard MAX board.

Custom dual-fan cooling configuration for high-speed printing with intake and exhaust over build plate. Front fan serves as outtake and fan placed on the left of the toolhead serves as a intake.

Development Process

• Stripped the printer MCU and wired it to communicate with external computation device (Minnowboard or 5-node Raspberry Pi cluster)
• Modified printer firmware to offload path planning, acceleration curves, and G-code preprocessing to external cluster
• Performed homing and calibration routines, identifying communication latency issues between MCU and cluster
• Resolved latency by optimizing serial communication protocol and increasing baud rate from 115200 to 250000
• Tested extrusion at higher speeds and encountered cooling bottleneck where layers weren't solidifying fast enough
• Implemented high-efficiency dual-fan cooling system with intake and exhaust fans positioned over build plate
• Iteratively tuned PID temperature control values to maintain consistent extrusion at increased feed rates

Technical Details/Decisions

• Chose computational offloading over replacing printer board because it was more cost-effective and allowed incremental upgrades to computing power
• Used Mac Mini to emulate variable numbers of Raspberry Pis during development to determine optimal cluster configuration for efficiency and cost
• High-efficiency cooling system uses intake fan to pull ambient air and exhaust fan to remove heat from build plate area
• Cooling configuration critical for maintaining print quality at 508% speed increase without it layers delaminated
• Serial communication runs at 250000 baud over USB connection between MCU and cluster master node
• G-code preprocessing on cluster includes path optimization and acceleration planning calculations
• 5-node RPI setup was most optimal for the voxelab aquila. It gave the most efficent configuration for the printer. Not too many, not too few.
• The emulated RPI was the PI 4B 4GB using a 500mb capped wired connection.

Mosquito Guard – Environmental Monitoring System

Mosquito Guard is a battery-powered environmental sensor box that tracks temperature and humidity to calculate real-time mosquito breeding risk. We built this for under $30 using an ESP32, DHT11 sensor, and an OLED display all in a 3D-printed enclosure. The idea was to make something actually deployable outdoors that could help identify mosquito hotspots before they become a problem. The system uses a weighted risk algorithm based on mosquito breeding thresholds and research, displaying everything through a standalone WiFi access point with a web dashboard. This project won first place at the 2025 Chameleon Hackathon.

Features

• Real-time mosquito breeding risk calculation based on temperature and humidity thresholds from research using set location
• Standalone WiFi access point mean no internet required, you can connect directly to the device to monitor raw sensor readings
• Web dashboard with Chart.js graphs showing historical trends over selected time periods
• OLED display shows connection information and sensor readings directly on the device
• Compact 3D-printed housing designed for outdoor deployment with room for battery/solar integration
• Weighted risk algorithm (60% temperature, 40% humidity) for accurate breeding condition detection
• Color-coded risk meter with gradient display (green to yellow to red) for instant visual feedback

Features we didnt get time for

• Solar panel integration for even longer battery life for the node.
• Additional sensors for more comprehensive data collection, such as light, air pressure, quality and moisture of the soil.
• Mobile app with notifcations for node status.

Development Timeline

30 minutes in - experimenting with ESP32 and DHT11 sensor, establishing baseline readings

1 hour in - finalized web dashboard design, implementing data storage and visualization

CAD design for hardware enclosure - sent to 3D printer to print during hackathon

Snip of our presentation we gave during the hackathon

Development Process

• Prototyped on breadboard with ESP32 and DHT11, stored sensor readings and implemented weighted risk function
• Researched mosquito breeding conditions to establish temperature and humidity thresholds for risk calculation algorithm
• Built web server on ESP32 serving single-page dashboard with inline CSS/JS to avoid file system bloatware.
• Designed risk meter UI with gradient progress bar (green to yellow to red) updating in real-time based on weighted score
• Integrated Chart.js for dual y-axis graphing of temperature and humidity trends over chosen time interval
• Modeled and 3D-printed enclosure for the hardware with wire management and sensor positioning
• Wired final assembly inside case with strain relief clip for DHT sensor cable and configured OLED display to show WiFi credentials
• Tested system outdoors to verify readings matched expected environmental conditions and risk calculations

Technical Details

• Chose DHT11 sensor because it's affordable and accurate enough for mosquito risk detection DHT22 would be more precise but overkill for this application. Also it wasnt provided to us as part of the parts bin.
• ESP32 runs in AP mode broadcasting "MosquitoGuard67" SSID at 192.168.4.1 no router needed just directly connect to device
• Risk calculation uses thresholds where temperature factor evaluates to 0% at 50°F, 50% at 75°F, 90% at 95°F, then drops above 100°F
• Humidity factor calculates to 0% below 30%, 50% at 42%, and 90% at 80%+ humidity
• Final risk score is weighted 60% temperature, 40% humidity since temperature is the bigger factor in mosquito lifecycle speed
• OLED display (128x64 I2C SSD1306) shows IP address and connection info so you don't need serial monitor in the field
• Enclosure designed with battery compartment for future LiPo + solar panel integration for permanent outdoor deployment
• Web server stores last 100 data points in memory for historical trend visualization without requiring external database

VEX Stall Detection System

During the vex season - Pushback, our robot’s intake and storage system would regularly overheat once it filled up with blocks. The system used three motors (two 5.5W and one 11W), and when jams happened, they would sit stalled for too long pulling high current and overheating. This led to slower performance and risked failures at important times during matches.

To fix this I created a multi-parameter stall detection system. It monitors motor RPM, current draw, and temperature to detect stalls and automatically protect the motors without taking control away from the driver during scoring. After testing 12 different stall limits, I landed on a limit configuration that completely eliminated overheating and significantly improved reliability throughout the season. My programming solution was submitted as our teams Innovate Award entry.

The Problem

• Intake system needed to handle large numbers of blocks without causing heat or performance issues
• Motors would overheat when blocks filled the system, causing excessive current draw
• Three motors were affected, two 5.5W motors and one 11W motor
• Overheating reduced intake speed and overall drivetrain speed during matches
• We didnt have time for a intake rebuild so we needed a programming solution to fufill this.
• Needed to protect motors without limiting driver control during scoring

Research & Solution Development

• Explored multiple stall detection methods, including current-only, temperature cutoffs, RPM detection, and combined monitoring
• Tested each parameter individually to understand how they behaved under load
• Found that relying on a single parameter often gave unconsistent results
• Determined that combining multiple inputs would provide the most accurate stall detection
• Chose to monitor RPM, current draw (mA), and temperature together
• Multi-parameter detection proved far more consistent than single-threshold approaches

Pics & Demo

The initial problem we were dealing with was the clogging of the rollers led to the high temperatures of the motors which caused a performance degradation. The neon blue graph at the bottom displays the average temperature of the motors over time.

First testing of threshold values - we can see that the stall detection is very stiff to respond.

6th variation of threshold values - now we can see that the stall detection is more responsive to our monitored values.

Demo of the final programming solution which we used in tournaments

Implementation Details

• Monitoring of RPM, current draw, and temperature delta
• RPM stall detection with a recovery window once RPM rises 20% above the stall threshold
• Current monitoring with a <1500mA threshold to catch electrical stalls early in the intaking process
• Temperature delta tracking over 3-second intervals to detect heat buildup from jams
• Automatic power reduction to 20% when a stall is detected to prevent damage
• Driver override option during scoring to allow full power when needed

Testing Process

• Designed a testing process that would stress the system the most
• Tested 12 different configurations to dial in optimal thresholds
• Used generated graphs to analyze current, RPM, and temperature behavior
• Evaluated how often overheating occurred and how it affected overall bot speed
• The 12th configuration proved the most stable and efficient
• Driver could intake blocks without thinking about stopping intake to allow for maximnum performance

Results & Benefits

• Eliminated motor overheating during competition
• Reduced unnecessary power draw freeing power for the drivetrain
• Maintained consistent intake performance throughout entire matches
• Improved overall robot reliability and increased endurance throughout the entire match

Technical Details

• Over 25 different thresholds were tested - only 12 made it to data analysis process
• VEX motors suffer much more from heat damage than regular motors because of their lack of a proper metal heatsink and the downsides of having a high heat retention time.
• Used matplotlib for data visualization and analysis.
• Software development was much better than hardware changes for us because we then we wouldve had to tune the new intake as well.
• Driver asked for a override and i implemented it in a trigger hold sequence that completely bypassed the heating system which then increased the holding time for the temp deltas and rpm based processes.