Milkor – Aerospace & Defence Company

This was my first time writing software attached to something that could leave the ground. I worked on a 12-foot UAV prototype for the Milkor 380 program, with embedded flight-control software underneath it and cameras, LiDAR, radar, RF, and other hardware feeding the system.

Before this, most of the software I had written lived in environments where the machine underneath it was easy to ignore. Embedded systems remove that. Tasks have deadlines. Sensors produce data on their own schedule. Hardware has physical limits. Timing matters. Memory matters. A component that behaves perfectly in isolation can still cause problems once it shares resources with everything else.

I worked in C/C++ around the flight-control stack and an RTOS that handled deterministic scheduling and real-time sensor work.

I also spent time bringing up and calibrating cameras, LiDAR, radar, and RF. That meant moving between software and hardware: reading data, checking interfaces, figuring out whether something was behaving correctly, then seeing what happened when the aircraft was flown. The integrations produced more than fifteen hours of flight data.

If a task ran late, a sensor was wrong, or an interface behaved differently from what the code assumed, the physical system exposed it. The loop either responded correctly, on time, under real conditions, or it did not. That is where the interest in embedded systems and control became serious.