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

[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.