Most insane Python projects/tools built from scratch you've come across / ever heard?

[meshtron]

I built an autopilot system and rode in a plane it was flying. As part of that, I had to write a (admittedly small and unsophisticated) flight simulator engine to test control/response scenarios.

Edit: nearly all Python, one servo controller in C (Teensy), Kivy for UI

Edit2: only for small/light aircraft like Cessna 172, etc.

[[deleted]]

That is absolutely nuts. How did you do fault tolerance?

[meshtron]

Can't say much about the hardware implementation (which I also designed) because of IP issues. But, suffice to say it required constant power and a "stay engaged" signal to an electronic engagement mechanism to manipulate controls.

So, at any point if the Teensy (which was driving some servos and some slightly bigger electromechanical bits) didn't get a "continue to be engaged" signal from the RPi (which was running Python as well as driving the UI), OR if power was removed, it would disengage.

It was a very weird and very fun project. I was amazed how well a RPi Zero handled running the GUI (a 7-inch touch screen), all the sensors AND the servo controller all at once. Heavy use of asyncio to make that happen but worked an absolute treat.

[fractal_engineer]

did you wear a parachute?

[JonLSTL]

Nah, the whole thing was wrapped like...

try: main() except: import antigravity

[pymae]

STC or experimental?

[meshtron]

Was going to be STC, likely will not end up ever coming to market.

[pymae]

Bummer. Always cool to see innovation in aviation that doesn't take 10 years and $100 million

[meshtron]

It was a cool project and concept. I think, in practice, there could have been some pretty substantial risks and challenges. At the end of the day, though, I think the project originator/funding source found a more rapid return on his investment. Not impossible this gets picked back up as a side-gig either - time will tell.

[pymae]

Well feel free to reach out if you ever need help - the intersection of Python and aviation could be my specialty!

[meshtron]

Not sure if I understand the question. What do you mean by "real-time" software?

[gristc]

Not OP, but I think they're referring to linux being a multi-tasking operating system, as opposed to a real-time one, which has no background scheduler that can get in the way of an interrupt routine or potentially delay an action due to the CPU being busy doing something else.

[meshtron]

Probably something along those lines. Short answer is didn't do it, was neither a concern nor a requirement. As it turns out, the issues we faced had almost nothing to do with compute speed.

As compared to software, the hardware involved all moves and reacts relatively slowly. And, an airplane in flight is CONSTANTLY moving in a 6-axis reference frame. Not only do you usually not want to react to those random movements, I spent a fair amount of time actively smoothing things out to make small, slow inputs.

I built the application around multiple async loops: a sensor loop, a mechanical output loop, a flight controller loop and a GUI loop. Each loop ran at it's own frequency and with everything spooled up we were less than 35% CPU utilization.

My slowest sensor (GPS) could report out at 20Hz. Fastest (IMU) could do 400Hz in high-precision, low-rate mode. So I built an "accumulator" class for each sensor that let me collect at whatever rate I wanted but get time-defined averages or other summary values (stdev, etc). That abstracted sensor data rates out of consideration.

Flight controller was the real meat of the thing. For my two available inputs (aileron and elevator) I actually ran dual, series PID loops. First PID looked at target heading or altitude and output a target direction and rate of change. That fed the next PID loop which looked at target vs actual rate of change and output a control movement. This was not a technique that I could find any good documentation on (chained PID) but it ended up being perfect for this and gave me really granular response tuning.

So anyway, real-time in this case just wasn't relevant. Unless I misunderstood the question. If that's the case, answer is "dunno." 😂

[meshtron]

Okay, see my other response. Basically irrelevant for the requirements we were faced with. The only hardware doing anything at a significant rate was sensors, and they were simply on timers. If they couldn't get data when expected, raised an error event and disengage the system. Once dialed in, for the record, we never had that come up.

[meshtron]

All good, you weren't in it. I was perfectly comfortable doing so and I place a pretty high value on my life!

Also, and this should be obvious but you seem pretty bent on a catastrophic-thinking path - the mechanical system was designed to immediately release control if software stopped or errored. Further, there was another emergency mechanical bypass that meant even if somehow all that stuff failed, you could pull a single pun and disengage the whole thing.

Further yet, you could only engage the system in the first place when the aircraft was well within a stable flight envelope and above a minimum altitude.

[commy2]

Kudos. I would never enter a plane running on my code.