The Drone Industry Got Better When It Outgrew Arduino

Third installment...

There is a sentence guaranteed to irritate at least a few people in the open-source drone community: Modern drones became better aircraft when they outgrew Arduino.

Before somebody reaches for the keyboard, that is not an argument that Arduino failed. It is almost exactly the opposite.

Arduino succeeded so spectacularly at opening electronics, programming, and autonomous systems to ordinary builders that the people it empowered eventually demanded more than the original hardware could provide. More processing power. More sensors. Faster communication. Better filtering. Redundancy. Sophisticated navigation. Real-time operating systems. Companion computers. Computer vision. And eventually aircraft capable of performing missions whose complexity would have sounded almost ridiculous when hobbyists were first wiring accelerometers, GPS receivers, and electronic speed controllers to inexpensive microcontrollers on workbenches.

Arduino helped create the appetite.

Then the drone industry ate the kitchen.

Arduino Was Never Supposed to Be the Finish Line

Arduino's importance to unmanned aviation has never really been about the specifications printed on a microcontroller datasheet.

It was about access.

When Arduino emerged in the early 2000s, its revolutionary quality was not that microcontrollers suddenly existed. Engineers had been working with them for decades. The revolution was that considerably more people could now participate. Students, hobbyists, artists, programmers, experimenters, and backyard engineers could buy inexpensive hardware, connect sensors to it, write understandable code, make mistakes, change something, and try again.

That philosophy transferred almost perfectly into the emerging do-it-yourself drone community.

Early ArduPilot development grew directly out of that world. ArduPilot's own project history traces its beginnings through the DIYDrones community, the first ArduPilot hardware in 2009, the APM1 platform in 2010, and increasingly sophisticated autonomous capabilities that followed.

We discussed that progression in our earlier FIELD NOTE, How Arduino Took to the Skies, because the connection matters. Early ArduPilot hardware grew from the Arduino ecosystem, giving experimenters a relatively accessible way to control motors, integrate sensors, navigate using GPS, and begin building aircraft that could make decisions without the pilot directly commanding every movement.

That was extraordinary.

But something interesting happens when a technology succeeds.

People start asking it to do things it was never designed to do.

And eventually, the technology has to evolve—or get out of the way.

Pixhawk Didn't Betray Arduino. It Proved Arduino Worked.

This is where the history becomes more interesting than the mythology.

There is a tendency to blend Arduino, ArduPilot, Pixhawk, and open-source drone development into one continuous technological object.

They aren't.

Arduino is a hardware and software ecosystem built around accessible microcontroller development. ArduPilot evolved into a sophisticated open-source autopilot software project. Pixhawk developed as an open flight-controller hardware standard with its own lineage and ecosystem.

The connections are real.

The distinctions matter.

As ArduPilot matured, it moved beyond the original Arduino/AVR-class hardware and onto considerably more powerful flight controllers. By 2013 and 2014, the project was expanding onto other architectures, including Pixhawk-class hardware, and later onto Linux-based systems and other platforms.

That transition is sometimes described as Arduino being left behind.

We think that's the wrong interpretation.

Pixhawk didn't betray Arduino. It proved Arduino worked.

Arduino's job was never to remain permanently bolted into the center of every autonomous aircraft. Its greater contribution was demonstrating that sophisticated electronic experimentation did not have to remain locked inside corporate engineering departments or university laboratories.

Once thousands of people had permission to experiment, they inevitably started demanding better tools.

An 8-bit microcontroller that was perfectly adequate for teaching, prototyping, and early autonomous-flight experimentation becomes a very different proposition when the aircraft is expected to fuse multiple inertial sensors, evaluate GPS and barometric data, maintain attitude, calculate navigation solutions, communicate with a ground station, manage failsafes, log enormous amounts of flight data, control payloads, and execute increasingly sophisticated autonomous behavior simultaneously.

At some point, asking the original architecture to keep carrying the load stops being loyalty.

It becomes nostalgia.

The Garage Started Becoming an Aerospace Laboratory

This may be the part that annoys the purists.

The maker movement didn't disappear as drone technology became more sophisticated.

It professionalized.

Today's ArduPilot is hardly some charming little weekend Arduino experiment. The project supports airplanes, multirotors, helicopters, rovers, boats, submarines, advanced autonomous missions, multiple failsafe systems, sophisticated sensor filtering, scripting, telemetry, detailed logging, and a huge range of configurable vehicle behavior. ArduPilot itself describes a platform capable of controlling an extraordinary variety of vehicle systems.

That is aerospace software.

Open-source aerospace software, certainly.

But aerospace software nonetheless.

And that evolution reveals something important about Arduino's contribution.

Arduino helped blur the boundary between amateur and professional development.

A hobbyist could begin experimenting with sensors at a kitchen table. A university team could prototype an autonomous aircraft without developing every electronic component from scratch. A startup could test an idea using inexpensive hardware before committing significant capital to specialized systems.

Some of those hobbyists became engineers.

Some of those university projects became companies.

Some of those experiments became technologies that eventually appeared inside commercial aircraft.

The garage didn't lose.

The garage grew up.

Then DJI Did Something the Maker Community Wasn't Trying to Do

While the open-source community was optimizing flexibility, experimentation, configurability, and transparency, companies such as DJI were solving a different problem:

How do we make all of this complexity disappear?

That distinction matters.

The enthusiast building an ArduPilot aircraft may want access to parameters, firmware, sensors, logging, tuning, hardware choices, mission logic, and the underlying behavior of the aircraft.

The commercial operator often wants something entirely different.

Turn it on.

Wait for the systems checks.

Plan the mission.

Fly.

Bring back useful data.

Those philosophies eventually produced very different kinds of aircraft.

Open-source systems frequently optimize freedom.

Highly integrated commercial systems optimize usability.

Neither goal is inherently superior.

But one of them turned drones into tools that could be deployed by photographers, inspectors, construction teams, emergency responders, survey crews, utilities, public agencies, and thousands of other users who had absolutely no interest in compiling firmware or understanding how an extended Kalman filter was estimating aircraft state.

And that raises an uncomfortable question for open-source loyalists:

Did open source help win the technological revolution while closed systems won the user-experience war?

Before somebody fires off the angry email, notice the wording.

We said helped.

Modern commercial drone technology did not descend directly from Arduino like one long electronic family tree. Autonomous-flight research long predates Arduino, and commercial manufacturers conducted enormous amounts of proprietary research and development of their own.

But the open-source community unquestionably became one of the great proving grounds of modern small unmanned aviation.

Ideas were built.

Code was shared.

Aircraft crashed.

Failures were dissected.

Sensors improved.

Navigation improved.

Control algorithms improved.

People tried things because nobody had told them they couldn't.

Our earlier FIELD NOTE, The Hidden Architecture Behind the Drone Revolution, explored precisely that idea: much of what appears effortless in today's polished commercial aircraft rests on layers of engineering knowledge accumulated across laboratories, universities, companies, repositories, forums, workshops, and garages.

The finished aircraft may hide that architecture.

That doesn't mean the architecture isn't there.

The Better the Drone Became, the Less the Pilot Had to Know

Modern drone operators can accomplish vastly more while understanding vastly less about how their aircraft actually works.

That is not necessarily criticism.

It may be one of the industry's greatest accomplishments.

A modern enterprise aircraft continuously evaluates inertial measurements, satellite navigation, magnetic heading, altitude, motor performance, battery state, positioning quality, obstacle information, command inputs, and countless other variables while the pilot watches a remarkably clean display showing an aircraft icon moving across a map.

That interface represents an astonishing amount of hidden engineering.

The operator doesn't have to understand all of it.

That is what good engineering eventually does.

It makes complexity disappear.

But there is a tradeoff.

When everything works, abstraction is wonderful.

When something doesn't work, knowledge suddenly matters again.

The builder who has spent years inside open systems often develops an intuitive understanding of failure modes that someone raised entirely on integrated commercial aircraft may never have needed.

That doesn't make one pilot better than another.

But it does produce different kinds of technological literacy.

One operator understands how to use the machine extraordinarily well.

Another may understand why the machine behaves the way it does.

The strongest operators eventually learn some of both.

Arduino's Greatest Contribution May Have Nothing to Do With Arduino

This is where the argument comes full circle.

If Arduino disappeared from every flight controller tomorrow, its influence on modern drone development would not disappear with it. Because Arduino's greatest legacy may never have been the board.

It was the idea.

• The idea that sophisticated electronics should be approachable.

• The idea that documentation should be understandable.

• The idea that somebody should be able to purchase inexpensive hardware, connect something to it, write code, break it, fix it, change it, and learn.

• The idea that experimentation should not require permission.

That mindset fed directly into the culture that produced early ArduPilot development and countless other robotics and autonomous-system projects.

Today, Pixhawk defines open hardware standards for drone systems. ArduPilot runs sophisticated autonomous vehicles across air, land, and water. Companion computers perform tasks once completely impractical aboard small unmanned aircraft. Machine vision and onboard artificial intelligence are steadily moving more decision-making into the aircraft itself.

The technology moved on.

The philosophy didn't.

And perhaps that is how technological revolutions are supposed to work.

The successful platform doesn't demand that the future remain compatible with its limitations. It creates enough people willing to challenge those limitations that eventually somebody builds what comes next.

So Yes, Drones Got Better When They Outgrew Arduino

There. We said it again.

But “outgrew” should never be confused with “became irrelevant.”

The Wright Flyer was outgrown.

Vacuum tubes were outgrown.

Mechanical flight computers were outgrown.

Nobody serious would argue that their importance disappeared simply because better technology followed.

Arduino belongs in a similar conversation—not because it invented autonomous aviation or because every modern drone secretly descends from an Arduino board, but because it helped remove one of the most important barriers to technological progress:

the belief that complicated things belong only to experts.

Arduino handed people the tools and essentially said:

Go figure it out.

Thousands did.

Some of them built aircraft.

Some wrote autopilots.

Some created companies.

Some contributed code.

Some crashed spectacularly and tried again.

And eventually the systems became so sophisticated that the little microcontroller platform associated with the beginning of that journey could no longer carry the entire workload.

That isn't obsolescence.

That's success.

Arduino helped build a generation of people capable of building beyond Arduino.

And perhaps the most fitting tribute to that legacy isn't insisting that Arduino remain at the center of modern drones.

It's recognizing that the whole point was to see what people would build once it wasn't.

THE FLYING LIZARD®

Aviation-Driven Drone Intelligence™

Where People and Data Take Flight™