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

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

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

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

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

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

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