Malaka J. Prasad
Hardware Interfacing, Sensor Fusion & System Modeling Lead
IMU and sensor fusion, low-level drivers, and the 3D CAD models of the drone and transmitter.
Our story
From zero drone knowledge to AMD Labs
Our story began with our first-year microcontroller project. When we started, none of us knew anything about drones. We had a dream and a proposal, and we had to bring them into the real world.
How it unfolded
A first-year project
It began with our first-year microcontroller project (IN1901) at the Faculty of Information Technology, University of Moratuwa. None of us had built anything aerospace before. We were Group 39, Team MicroSolutions.
Learning from people who had done it
We asked seniors, mentors and robotics teams, at our university and others, what actually fails in real drones. Their advice shaped our parts list: an F450 frame, 980 KV motors, 30 A ESCs and a 3S 5200 mAh battery.
Working around local supply limits
Proper silicone wire and connectors were not sold locally, and importing them was too slow and too costly. So we tested generic connectors by trial and error, and harvested good wire from cheap assemblies.
Starting over with a new brain
Our first flight controller used an ESP32, but its wireless stack and task scheduler caused timing jitter. We redesigned around an STM32H743 and gave the ESP32 a better job: running telemetry.
Taming noise and latency
Motor spin-ups locked the I2C bus until capacitors stabilised the power rails. Moving the IMU from I2C to SPI then removed the biggest bottleneck in the control loop.
Tuning without crashing
We could not afford a professional test bench, so we built wooden rigs that let the drone rotate on one axis while it stayed locked in place.
Finding the hardware flaw
The drone kept drifting on liftoff. Magnets and Hall sensors on the motors showed that cheap motors and ESCs spun at different speeds on the same signal. Replacing them with branded parts fixed it.
First stable liftoff
After about twelve months, the drone lifted off vertically and stably. Holding a controlled hover by hand is still unsolved: our thumb joysticks could not give fine enough inputs, so that is next on the list.
From project to AMD Labs
After the project, we started an R&D startup called AMD Labs, to keep building adaptable aerial systems.
Showing at FITExpo 2026
Now we are showing AMD24 and everything we learned at FITExpo 2026, so that others can learn from it and build on it.
The team
We are Team MicroSolutions
Abiram L
Communication Protocols, Network Integration & App Dev
The radio link, STM32-to-ESP32 communication, and the Aeronexus dashboard.
Achintha Jayawickrama
Spatial Data Processing, Telemetry & Hardware PCB Architect
GPS and magnetometer integration, survey visualisation, schematics and PCB design.
Nimsara K. Karunarathna
Propulsion, Power Systems & Flight Control Loops Lead
Power distribution, motors and ESCs, PID tuning, motor mixing and status LEDs.
Luxshana N
Remote Controller & Wireless Communication Systems Lead
The custom transmitter: joysticks, display, radio firmware and its power system.
With thanks
Our supervisor Mr. B.H. Sudhantha, our co-supervisor Mr. Hemantha Wanniarachchi, the staff of our department, and the seniors, mentors and robotics teams who shared what they knew.
What we learned
Lessons we would pass on
- Ask early. One conversation with an experienced builder can save weeks.
- Test each part alone. We proved the motors with a spare ESP32 before the flight controller touched them.
- Measure before blaming software. Our worst drift problem turned out to be the motors.
- Software cannot fix bad hardware. Noise, uneven thrust and imprecise joysticks all needed physical fixes.
- Build what you cannot buy. Wooden rigs did the job of an expensive test bench.
Where next?
Follow the same path: learn the ideas, build it stage by stage, and read the problems we hit along the way.