ARDMS – Autonomous Racing Drone Motion Controller

I pursued creating ARDMS because of the lack of AM32 firmware availability in the US because of Ukraine and Russia using autonomous drones in their warfare, but i still wanted to keep creating and flying my drones. ARDMS is not a replacement for software like ArduPilot or iNav, it is simple, reliable, and easy to use firmware that communicates with Betaflight and its forks. ARDMS is an autonomous racing drone motion controller firmware built in Python to simplify drone control. It allows users to program autonomous flight routes with ease and consistency. MOSFET regulation is utilized for the controlling of the ESC, unlike most F405 firmware versions. The system also includes automatic PID loop calibration for each motor my program acheives this by strapping the quadcopter to a surface, ARDMS measures the power curves on each lateral axis to calculate optimal P, I, and D values for a pre-programmed PID controller based on a iFlight Nazgul DC5 with stock motors and a 389g payload.

Features

• Program custom flight routes with installed GPS module for predictable autonomous missions
• Automatic PID calibration using strapped testing for initial setup and tuning
• Communicates with Betaflight software and its forks for testing and configuration
• Supports ESC communication using MOSFET regulation for motor control
• Utilizes GPS module to plan routes using simple line-based path following algorithms
• Full-duplex serial communication for high-bandwidth data transfer with MOSFET support

Development Process

1. Compared ArduPilot with iNav to determine feature list
2. Used shoelace theory to determine the area selected by the user for autonomous flight planning
3. Implemented automatic PID calibration by calculating optimal P, I, and D values from measured power curves
4. Built integration with Betaflight software for testing, debugging and visualizing motor outputs safely without arming ESCs
5. Tested MOSFET activation and motor responses and refining utilizing the predicted power curves for accuracy and stability
6. Added functionality to allow users to program autonomous routes using a simple, repeatable workflow

Technical Details

• Chose MOSFET regulation because AM32 ESCs require MOSFET regulation to efficiently control motor output. I added MOSFET regulation because standard F405 stack firmware distributed in the United States did not support it.
• Communication protocol uses DShot because it provided the highest speed between the stack and ESC while supporting MOSFET regulation
• Used full-duplex instead of half-duplex serial connection because full-duplex provided the bandwidth needed for MOSFET regulation over DShot protocol
• Installation is performed via the Betaflight firmware flasher using the firmware provided in the GitHub repository
• PID calibration process involves strapping the drone and running automated test sequences on each axis to measure response curves
• GPS waypoint system uses linear interpolation between points with configurable turning radius for smooth path following

SWIFT – Swarm With Intelligent Formation Tracking

SWIFT is an open-source project for WSSEF (Washington State Science and Engineering Fair). It allows users to program autonomous flight routes for drone swarms with ease and repeatability. SWIFT builds on my previous explorations with ARDMS and offloading computational tasks to an external unit. Our aim is to create a more professional system with swarm support and higher consistency rates for post-disaster recovery operations. The system includes individual node identification to assign tasks to separate node groups or even individual nodes, with multiple search modes to target specific situations.

view on github

Projected Features

• Series drone positioning for ultra long range search distances across difficult terrain
• Automatic takeoff and landing based on flight status and individual node health monitoring
• Affordable and easy-to-deploy system designed for first responders with minimal complex background knowledge needed
• Under 249g FAA drone launch weight regulations for unrestricted deployment
• ML-enhanced thermal imaging for detecting heat signatures in search and rescue operations
• Formation tracking algorithms to maintain swarm coordination during search patterns

Current Status

• Desktop application for mission planning and swarm coordination is functional in testing environment
• Search algorithm using shoelace theory for area coverage calculation has been implemented.
• Working on formation tracking algorithms to maintain swarm cohesion(how tight they stay together) during search patterns
• Preparing for WSSEF presentation with the demostration of a live swarm autonomous programming route.

Current Technical Details

• Uses shoelace formula to calculate search area boundaries and optimize flight paths for complete coverage
• 3.5x4in heat seeking sensors for air to ground heat signature detection
• Each node approximate cost of 80$, including sensors and communication modules.
• Base station approximate cost of 200$, this includes redundant communication modules and direct connection with the ground operators computer.
• Designed to operate under 249g to avoid Part 107 commercial drone regulations and enable fastest deployment without authorization from the FAA.
• Programmed in Python

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

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.

view on github

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

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.