Skip to content

Instantly share code, notes, and snippets.

@greghgradwell
Last active November 17, 2020 13:28
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save greghgradwell/c000c27352172c1285120836e69427c9 to your computer and use it in GitHub Desktop.
Save greghgradwell/c000c27352172c1285120836e69427c9 to your computer and use it in GitHub Desktop.
0. In the beginning, there was the middle

0. In the beginning, there was the middle...

You're jumping into a novel at about Chapter 6. And no, that's not because you missed the earlier chapters. I am only writing it now because it has finally become something worth recording (and hopefully reading). First, let me assure you that this is neither a theoretical exercise, nor a vague description of a "stealth" project. In short order you will be introduced to the current prototype that has already demonstrated many of the original project goals. And there will be plenty of pictures (please ignore the fact that this post has approximately 0 pictures 😬).

This project started out as somewhat of an experiment, or rather, it was a means to scratch an itch that had been bothering me for a few years:

What does it take to make an autopilot sufficiently reliable, affordable, and integratable enough to be extremely useful?

Or written as more of a challenge:

Can I create an autopilot that I could trust, afford, and would actually want to use?

It's basically a rework of the fast-cheap-good triangle. I know plenty of autopilots that can satisfy one or two of those requirements, but I haven't found one that really fits all three. But even this challenge isn't really compelling, because who cares if somebody "wants to use" a device? The real question is, what are they going to do with it? So let's make the final target something like this:

Can we create an autopilot that many people could trust, afford, and easily use to do something really interesting?

You may notice that the pronoun has changed from "I" to "we". Well, yeah, to do this right I will need some help. Therefore I will continue to use "we", even though at the moment it is still just I. Oui? Aye.

The Brett Factor

Here's the thing: everyone needs a Brett
My Brett is probably the nicest person this side of the Rockies. He also happens to be brilliant. He also might not like being referred to as "my Brett", so I'm leaving his last name out of this. (Sorry Brett)

Now Brett happens to be a fan of the Elixir programming language. I had never even heard of it before, but he thought its robustness and support for concurrency might make it a suitable candidate for an autopilot. When I looked into the language and the BEAM virtual machine upon which it ran, I was convinced as well. After learning about Elixir, I came across the Nerves project. Nerves is essentially embedded Elixir capable of running on cheap single-board computers (Raspberry Pis, BeagleBones, etc). The Nerves core team is fantastic, and the community is extremely friendly. If network-capable embedded devices interest you, I highly recommend you check it out.

I will spare trying to convince you why Elixir is a great language for creating an autopilot. After all, you couldn't argue back, so it would make for a pretty lousy debate. But let me at least tell you why I found it appealing:

If you give a mouse Elixir...

  • Elixir is built on top of Erlang, which was designed by the Ericsson Computer Science Laboratory to be EXTREMELY reliable
  • Nerves allows Elixir to be run on very affordable hardware
  • Elixir coupled with affordable hardware means we can have an autopilot consisting of several, smaller/cheaper devices (nodes) connected on a local network, thereby adding redundancy without sacrificing capability (assuming we do it right)
  • An autopilot that is designed to operate as a decentralized cluster can more easily adapt to the requirements of the vehicle or mission (add/subtract nodes, sensors, etc.)
  • If nodes can be easily added to our network, then third-party hardware can be directly integrated with the autopilot via an API.
  • If this hardware is smart, it can pilot the vehicle by means of high-level commands (speed, course, altitude), or it can provide environmental data to the autopilot's map/navigation system (obstacles, other vehicles, geofences, etc.). This is because all nodes are (almost) equal in the eyes of the cluster. A command can have several sources, with the highest priority one taking precedence.
  • If commands are designed to be sent from anywhere inside the vehicle, then they can also be sent from outside the vehicle. Hello SWARM!
  • Those last two bullet points...are you excited? I'm excited. I bet Brett is excited. He's an energetic dude.

With these statements as my guide and motivation, I set out to build a robust, decentralized, expandable, maintable autopilot set atop the Erlang/Elixir/Nerves platform. If anything about this interests you, please stick around for more of the journey. If it's not educational it should at least be entertaining. Did I mention pictures? There will be pictures.

-Greg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment