AMD Labs

Challenges

What went wrong and what we did

Eight problems we solved along the way, and five limits we are still working on. The problems taught us more than the wins.

01

Starting with no drone experience

It was our first aerospace project, and all five of us were new to it.

Symptom

Wrong motor, ESC or propeller choices could have doomed the build before any code was written.

Cause

The gap was knowledge of thrust, current draw and which parts work together.

How we found it

We asked seniors, mentors and robotics teams at our university and others about real failures.

Fix

Their advice shaped a parts list where the frame, motors, ESCs and battery suit each other.

Lesson

Ask people who have failed already. It is the cheapest test there is.

02

Parts we could not buy locally

Suitable wire and connectors were not sold in the local market.

Symptom

High-current silicone wire and vibration-proof connectors were unavailable, and importing cost too much and took too long.

Cause

Regional supply limits against a fixed academic deadline.

How we found it

We tested locally available connectors for current capacity, grip under vibration and ease of soldering.

Fix

We kept the safest connectors and harvested quality wire from cheap assemblies for the power and sensor harnesses.

Lesson

Check real capability rather than the label, and look at what is already inside cheap products.

03

An ESP32 cannot be a flight controller

Our first brain could not keep steady timing.

Symptom

Control timing was unstable during early firmware prototypes.

Cause

Wi-Fi and Bluetooth stacks and the FreeRTOS scheduler added unpredictable jitter and latency.

How we found it

We reviewed how established systems such as Pixhawk and Betaflight are built, and found they rely on STM32 chips.

Fix

We redesigned around the STM32H743, with its hardware floating point, and repurposed the ESP32 for telemetry.

Lesson

Pick a chip for its timing guarantees as well as its clock speed.

04

I2C bus freezing as motors spin up

Sensor data stopped whenever the ESCs drew hard.

Symptom

The I2C bus to the sensors randomly froze during motor spin-ups, which would crash a drone in flight.

Cause

An oscilloscope showed voltage dips and high-frequency noise on shared power rails during high-current draw.

How we found it

We probed the rails and bus lines with an oscilloscope while spinning the motors.

Fix

We soldered ceramic and electrolytic capacitors across VCC and GND at the sensors and STM32 rail, and later added a software bus recovery.

Lesson

Fix noise at its source first. Software recovery is a backup.

05

Clone chips under the same name

The same part name could hide different silicon.

Symptom

Sensor boards sold under one name contained different chips, with different addresses and registers.

Cause

Regional vendors and batch variation, for example HMC5883L, QMC5883L and Si24R1 clones.

How we found it

Fixed drivers crashed or read garbage on a chip that did not match the datasheet.

Fix

At boot, the firmware scans the bus, identifies the chip and loads the correct driver and scaling.

Lesson

Assume parts will vary, and detect them at boot.

06

No budget for a test bench

Free-flight tuning risked destroying the drone.

Symptom

Starting PID values are only estimates, so a free-flight mistake could end the project.

Cause

Professional multi-axis test benches were far beyond our budget.

How we found it

We looked at what such benches actually do: restrict movement while allowing rotation.

Fix

We built wooden rigs that lock the drone in place and let it rotate on one axis, so gains could be pushed safely to their limits.

Lesson

You often need the principle behind expensive equipment, rather than the equipment itself.

07

Uneven thrust from budget motors

The drone drifted, and it was not the software.

Symptom

After static tuning, the drone drifted in pitch and roll on every liftoff attempt.

Cause

Cheap unbranded motors and ESCs spun at different speeds from the same signal.

How we found it

Debugging confirmed correct PWM output. Magnets and Hall sensors on the motors then measured each motor's RPM.

Fix

We replaced them with branded motors and ESCs, which gave matching speeds and a level liftoff.

Lesson

Measure the physical output before spending more time on code.

08

I2C slowing the control loop

The fast chip spent its time waiting.

Symptom

Timing analysis showed the loop was limited even with a fast processor.

Cause

Reading the IMU over I2C, typically limited to 400 kHz, left the CPU waiting on the bus.

How we found it

We measured control loop timing and traced where the time was going.

Fix

We moved the MPU6500 to SPI and refactored the driver, which removed the bottleneck.

Lesson

The slowest link sets your speed, however fast the processor is.

09

Holding a hover by hand

Stable on liftoff, but not controllable in the air.

Symptom

After stable vertical liftoff, the pilot could not hold a sustained hover.

Cause

Thumb joysticks lack fine travel and spring precision, while the drone responds very quickly.

How we found it

Post-flight review pointed to over-correction by the pilot, known as pilot-induced oscillation.

Fix

Still open. Our next step is Hall-effect RC gimbals, followed by a repeat hover test.

Lesson

Your control input is part of the control system too.

10

Radio range of about 100 m

The radio set the working area.

Symptom

Beyond about 100 m in line of sight, signal strength dropped quickly and packets were lost.

Cause

The physical limits of 2.4 GHz nRF24L01+ modules, plus local interference.

How we found it

Field tests of the link at increasing distance.

Fix

Still open. We lowered the data rate to 250 kbps to get the best range. Sub-GHz LoRa or ExpressLRS is the planned upgrade.

Lesson

Design missions around the range you have measured, not the range on the box.

11

Rough metal location

It can find a zone, not a point.

Symptom

Survey maps show where a disturbance is roughly, but not its exact position, depth or shape.

Cause

A consumer magnetometer plus GPS with about 2 to 5 m of error.

How we found it

We analysed the collected survey data against what we were trying to locate.

Fix

Accepted for now. We class it as a preliminary sweeping platform that guides follow-up work on the ground.

Lesson

Say clearly what your sensor can tell you, and what it cannot.

12

Only 5 to 7 minutes of flight

High current draw limits survey time.

Symptom

Safe flight time is about 5 to 7 minutes, too short for wide-area surveys.

Cause

The current drawn by the motors and electronics from one 3S 5200 mAh battery.

How we found it

Flight endurance analysis of the prototype.

Fix

Still open. Battery swaps for now. A propulsion redesign is on the roadmap.

Lesson

Do the flight time sums early, and include everything on board.

13

Little spare lift

Adding parts used up the margin.

Symptom

The custom PCB, modules and printed enclosures pushed the platform close to its lifting limit.

Cause

The finite thrust of an F450 with 10-inch propellers.

How we found it

Reviewing the weight added during integration.

Fix

Still open. Heavier sensors will need lower KV motors, larger propellers and a higher-voltage battery.

Lesson

Keep a weight budget from day one. Every gram adds up.