greghgradwell

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 t

greghgradwell

1. Hardware vs. Software

Software is great, but at some point it has to interact with hardware or it's useless. One of the pressing questions early on was how many of the hardware interfaces could be written in Elixir. For example, the first peripheral I wanted to test out was an IMU (inertial measurement unit). If I were working with Arduino, I would have a library already available, ready to plug and play.

Should I connect the IMU to an Arduino board, and then interface with the Arduino board using a serial protocol of my choice? Or does the extra hardware outweigh the benefits of ready-to-use software?

Since I was still very new to Elixir, I thought it would be interesting to replicate one of my previous projects that had utilized Arduino, in this case a 2-axis camera gimbal. Do I have pictures of the original? No. Did I take pictures of the Elixir version before I took it apart? Also no. So we'll have to use our imaginations. (Don't worry, I hear your boos and I agree)All I can offer i

greghgradwell

2. Code for any Mode

From the start, this autopilot was designed to use multiple nodes operating on a local network. And with that premise in mind, I introduce you to Segal's law (not to be confused with Steven Seagal's Above the Law).

₁

"A person with a watch knows what time is it. A person with two watches is never sure."

And here lies perhaps the biggest issue when it comes to multiple devices working together:

If two devices disagree, how do you know which one is right?

I'm sure there's a lot of really clever answers to this, but the nature of Elixir allows for an answer that is simple. And I like simple.

If a device is alive, assume it's right.

greghgradwell

3. Commands on Demand

Welcome back! Unless you never left, in which case, maybe it's time for a snack?? Previously we were discussing the notion of taking two sources of hardware output and somehow rectifying them into a single software input. I used the example of two IMUs, but I'm going to retract that one for now, because I haven't actually duplicated sensors on the vehicle yet. Rather, let's talk about using multiple sources of vehicle commands, since I've at least got that much working. But 2021 is the year of redundant sensors! (or should I call them oxiliary?)

Pesky front seat drivers...¹

Two is one

I've never tested an autonomous system that lacked the option for a human operator to assume manual control. I know there are aircraft out there where the pilot is l

greghgradwell

Media Credits

I'm not really sure how best to do this, but here are the links to any media that appear in my posts. I'll try to provide credit as thoroughly as possible. If your material appears here and you'd like it removed, please let me know.

0. In the Middle

1. No pictures? Good luck getting anyone to come back.

1. Hardware vs. Software

1. Sparkfun BNO080 breakout: https://cdn.sparkfun.com//assets/parts/1/2/8/9/1/14686-Qwiic_VR_IMU_BN0080-01.jpg
2. Pololu Micro Maestro: https://a.pololu-files.com/picture/0J1951.600x480.jpg?7e54ef728c9e5b6707a45ae5868bfb66
3. Macho Man and Hulk Hogan: https://media.giphy.com/media/Te0zPUD9m7KDe/giphy.gif

2. Code for any Mode

greghgradwell

4. Attested Development

Do you ever look back on your life and think:

₁

Great! Me too. And even though I'm constantly convinced I've made it to the other side of senseless, I continue to provide examples of the contrary. Today I figured we could talk about one such instance involving our good friend, the multiplexor.

As I'm sure you remember from Part 2, a multiplexor takes input signals from two different sources, and based on some criterion passes only one of them on. This is a very useful tool, as it allows for a direct link between the RC receiver and the servos in the vehicle. If things go south with the autopilot, I can simply switch to manual control, which gives me that extra bit of comfort as I manually pilot the airplane directly into the ground due to poor decision making.
Things got a little

greghgradwell

5a. "X" Marks the Spot

Today we're going to talk about something near and dear to my heart: staying inside.

At several points in my career I have been involved with flight test programs of varying levels of sophistication and technical complexity. The biggest drawback for me was that the aircraft usually had to fly outdoors. I thought engineering was a civilized activity, but apparently there are some parts that require what basically amounts to camping in the jungle. Fortunately for those of us that shudder at the thought of being too far from the fridge, there is a great tool we can leverage to delay those perilous journeys for as long as possible: computer simulation.

Simulation is a tool in your arsenal that can be very useful in the right situation. In case you tend towards physical prototypes for the purpose of testing (as was often my strategy), allow me to offer a few thoughts on the subject:

• The more often you'll be testing your system, the more you'll want a simulator. The it

greghgradwell

5b. Good HIL Hunting

If you remember from last time, we were parsing X-Plane data output messages and converting them to native Elixir messages that contained the same information. By doing this, the Estimation module could not tell that its data was coming from a simulator instead of a real aircraft. Here is the data path, as previously shown:

The Estimation module might not know the difference, but the sensor path is being totally bypassed. At some point, once we're content with the performance of our aircraft control in the simulator, we would like to stress more of the system. The next step in the progression was to take the X-plane data and create messages that conformed to the protocols of our sensors, in this case a VectorNav VN-300 INS and a [TeraRanger Evo 60m ToF (time of flight)](https://www.terabee.com/shop/lidar-t

greghgradwell

6. SimPATHy

For someone who keeps using the word "autopilot", I sure have avoided the autonomous part of the project for a long time. Well, hold onto your socks because today we'll be describing how the vehicle actually pilots itself. And the good news is, the explanation is quite simple:

1

But how did the aliens do it? One theory is that they used Dubins paths. If you've never heard of a Dubins path, that's probably because you spent your college years with friends. Big mistake. In case you don't feel like clicking on that nicely added link, a Dubins path is essentially the shortest path between two points given a constraint on the curvature (turning radius) of the path. To create a Dubins path you just need to specify two or more waypoints, each of which includ

greghgradwell

7. The Mimic Gimmick

What's that saying? "Fake it until you make it." Well today's topic goes a little something like this:

Make it and fake it until you can afford to partake it.

For as long as there have been prototypes, there has been the question of make vs. buy. If you're anything like me, you're a real sucker for the make argument, especially when you actually understand how something works. But it sure is nice to just unwrap your newly acquired piece of hardware, plug it in, and get on with your life. However, sometimes that hardware is really expensive, and you're just working on some crazy idea that will likely never generate a dollar, let alone enough revenue to justify a $5,000 inertial navigation system (INS). So if the plan is to someday use a VN-300 Dual Antenna GNSS-Aided INS, but our capital is currently tied up saving for a [LEGO NES Console](https://www.lego.com/en-us/product/nintendo-entertainment-system-71374?CMP=AFC-AffiliateUS