Software Development for Flight Control Systems

Flight dynamics in Python with Archimedes! In a new series we walk through implementing 6dof flight dynamics using the subsonic F-16 benchmark. The implementation uses hierarchical, multi-fidelity modeling and the spatial mechanics primitives for rigid body dynamics. The trajectory in the gif has tabulated aerodynamics, NASA turbofan model, rate-limited control surfaces, USSA1976 atmosphere, and... constant gravity. No sensor models (yet).  It runs on a laptop at ~8000x realtime using the SUNDIALS interface for adaptive ODE solving. The whole thing is implemented in Archimedes + NumPy, so the entire model (plus controllers and filters, coming soon) is also compatible with C code generation for real-time simulation, HIL testing, and embedded deployment using CasADi's computational graphs. An RK4 step takes ~380 µs on a Cortex M7, enabling 1+ kHz hard real-time running on bare metal. Check out the tutorials and the source code on GitHub! https://lnkd.in/e_74JVU4 (tutorial series) https://lnkd.in/ecV6nHdk (source code) #Archimedes #CasADi #ControlSystems #EmbeddedSystems #Python #OpenSource #Aerospace

𝗔𝘂𝘁𝗼𝗺𝗼𝘁𝗶𝘃𝗲 𝗶𝘀 𝘁𝗿𝘆𝗶𝗻𝗴 𝘁𝗼 𝗱𝗼 𝘄𝗵𝗮𝘁 𝗔𝘃𝗶𝗼𝗻𝗶𝗰𝘀 𝗺𝗼𝘀𝘁𝗹𝘆 𝗿𝗲𝗳𝘂𝘀𝗲𝗱 𝘁𝗼 𝗱𝗼. We often talk about the Software-Defined Vehicle as if a new frontier. But if you look up at the sky, you’ll see an industry that solved these problems decades ago. 𝗔𝘃𝗶𝗼𝗻𝗶𝗰𝘀 𝗰𝗮𝗹𝗹𝘀 𝗶𝘁 𝗜𝗠𝗔 (Integrated Modular Avionics). They use a strict standard called 𝗔𝗥𝗜𝗡𝗖 𝟲𝟱𝟯 to partition software across mixed-criticality apps, all running on small, deterministic RTOS kernels like INTEGRITY-178 or VxWorks 653, certified up to 𝗗𝗢-𝟭𝟳𝟴𝗖 𝗗𝗔𝗟 𝗔 for flight-critical functions. 𝗕𝘂𝘁 𝘁𝗵𝗲𝗿𝗲 𝗶𝘀 𝗼𝗻𝗲 𝗺𝗮𝘀𝘀𝗶𝘃𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗯𝗲𝘁𝘄𝗲𝗲𝗻 𝗮 𝗽𝗹𝗮𝗻𝗲 𝗮𝗻𝗱 𝗮 𝗺𝗼𝗱𝗲𝗿𝗻 𝗰𝗮𝗿. On airliners, Linux is mostly in the passenger systems – in-flight entertainment and maintenance tools. It’s not the DAL-A flight-control OS that actually keeps the aircraft in the air. 𝗙𝗹𝗶𝗴𝗵𝘁 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝘀 run on hard-real-time, chemically pure RTOS kernels, because “DAL A” means a failure is catastrophic. In practice, regulators and OEMs have long treated a general-purpose OS like Linux as too complex to underwrite the determinism and assurance case needed at that level. 𝗔𝘂𝘁𝗼𝗺𝗼𝘁𝗶𝘃𝗲 𝗶𝘀 𝗰𝘂𝗿𝗿𝗲𝗻𝘁𝗹𝘆 𝘁𝗿𝘆𝗶𝗻𝗴 𝘁𝗼 𝗱𝗼 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘁𝗵𝗶𝗻𝗴 𝗮𝗲𝗿𝗼𝘀𝗽𝗮𝗰𝗲 𝗵𝗮𝘀𝗻’𝘁 𝗲𝗺𝗯𝗿𝗮𝗰𝗲𝗱 𝗮𝘁 𝘀𝗰𝗮𝗹𝗲: push Linux into the safety-critical envelope (mainly ASIL-B/C safety-related functions, with some eye on ASIL-D), by wrapping it in hypervisors, supervisors, and safety monitors. It’s a bold engineering gamble. But looking at the “federated” trend returning to automotive, we may be relearning the lesson avionics taught us: 𝗞𝗲𝗲𝗽 𝘁𝗵𝗲 𝗽𝗲𝗻𝗴𝘂𝗶𝗻 𝗶𝗻 𝘁𝗵𝗲 𝗽𝗮𝘀𝘀𝗲𝗻𝗴𝗲𝗿 𝘀𝗲𝗮𝘁, 𝗻𝗼𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗽𝗿𝗶𝗺𝗮𝗿𝘆 𝗳𝗹𝗶𝗴𝗵𝘁 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝘀. #SDV #SoftwareDefinedVehicle #FunctionalSafety #ISO26262 #ARINC653 #Avionics #AutomotiveSoftware #SafetyCriticalSystems #AUTOSAR AUTOSAR #RealTimeSystems #AutomotiveIndustry #FutureOfMobility

Most engineers call specs and design docs “paperwork.” After 8+ years in safety-critical software I learned the opposite: without defined expected behaviour, real V&V isn’t possible. Requirements, specs, architecture, and documented decisions are what make unit tests, FTA/FMEA and reviews meaningful. At EULER-NAV we try to think and document first, then code, while accepting trade-offs because time and budget are real. The image shows a small excerpt from our architecture: the runtime view of one of the three redundant Kalman-filter chains in the Baro-Inertial AHRS. Tools are simple: Doxygen + MathJax + PlantUML. Doxygen is underrated: it supports deep cross-links, and you can fail the doc build on warnings (missing param docs, wrong file names, broken links). Used with care, it gives lightweight traceability without heavy tools. EULER-NAV Baro-Inertial AHRS product page: https://lnkd.in/eszAtqzF #softwareengineering #safety #uav #px4 #gnc #ardupilot

A SHORT COURSE on INTELLIGENT FLIGHT CONTROL, Part 18 Certifiable Intelligent Flight Control, Part 1 ---------------------------------------------- We began this short course with an "inside-out" look at system design, examining the DECLARATIVE, PROCEDURAL, AND REFLEXIVE functions that underlie navigation, guidance, and control. We conclude with an "outside-in" perspective of the GOALS FOR INTELLIGENT CONTROL of PILOTED AIRCRAFT, as specified by the FAA, DoD, and NASA. The FAA issues Type Certificates, Supplemental Certificates, Technical Standard Orders, and Regulations that govern the operation of civil aircraft and their software, e.g., FAR Parts 23 et al and DO-178C. DoD specifications are guided by the General Specification for Design, Installation, and Test (MIL-F-9490D), Flying Qualities Standards (MIL-HDBK-1797), and Software Specifications (DO-178C). NASA conducts research that seeks to improve these processes. The technology of modern flight control is continually changing, challenging assumptions and conclusions. As noted in the attached Google AI Overview, the initial answer to the question, "Can intelligent flight control be certified?" is "NO" because machine learning makes the real-time input-output relationship non-deterministic. The standards are continuing works in progress. There are caveats in the certification process and changes of perspective about what makes control systems SAFE. Current rules are based on software determinism and input-output traceability. "Learnable" neural networks may provide SAFE BUT NOT NECESSARILY IDENTICAL outputs from identical inputs. The trend in regulatory development is away from this "frozen approach" to designing control software with PERFORMANCE-BASED METRICS that reflect Intent, Completeness, Correctness, and "Innocuity." Evolving approaches rely on robust response to failures and protection against "BLACK SWAN" events (unpredictable events with unsafe consequences). Part 1 outlines basic principles of development for intelligent flight control. Part 2 gives examples of related control systems and the INTERFACE between HUMAN PILOTS and ARTIFICIAL INTELLIGENCE. Both parts present CRITICAL INFORMATION about goals and constraints for CERTIFIABLE FLIGHT CONTROL SYSTEMS. --------- Reference . Toward Intelligent Flight Control, 1993, https://lnkd.in/eYCFbyz5. . FAR Part 23, Airworthiness Standards: Normal Category Airplanes, https://lnkd.in/erUs6XEQ. . MIL-HBDK-1797, Flying Qualities of Piloted Aircraft, https://lnkd.in/evQZF684. . DO-178C, A New Standard for Software Safety Certification, https://lnkd.in/e3MhkTy7 . Flight Dynamics, 2nd Edition, 2022, https://lnkd.in/ePctugN8 . Google AI Overview, Certifiable Intelligent Flight Control, Part 1 (addendum below the graphic).

Satellite Electronics Control Units (ECU): Radiation-Hardened Design & Open Source Space Designing a Satellite Electronics Control Unit (ECU)—the spacecraft's onboard computer and command & data handling system (CDHS)—is an expert-level task dominated. While high-assurance systems use proprietary tools and Rad-Hard components, the field is rapidly adopting open-source software and Commercial Off-The-Shelf (COTS) hardware, especially for Small Sats and CubeSats. 1. Hardware Architecture: Resilience and Redundancy 💻 Processor Core: For high-reliability missions (e.g., GEO satellites), the core uses Radiation-Hardened (Rad-Hard) microprocessors (e.g., LEON3/4/5 SPARC V8, or specialized Rad-Hard ARM cores). For lower-cost CubeSats, COTS MCUs (e.g., STM32, ARM Cortex-M/R) are used but must be integrated with software mitigation techniques to handle Single Event Upsets (SEUs). Memory Design: All critical memory must feature Error Correcting Code (ECC), typically using dedicated {SRAM} or {SDRAM}. Data buses are often triplicated, and memory access logic includes scrubbing routines that continuously scan and correct transient bit-flips caused by cosmic rays (SEUs). PCB Design for Thermal & Radiation: Components: Components are often screened (up-screened COTS or QML-V) to withstand temperature extremes and Total Ionizing Dose ($\mathbf{TID}$). PCB: Multi-layer PCBs (10+ layers) are used for high-density routing. Thermal management is passive, relying on copper pours, thermal vias, and direct coupling to the spacecraft's chassis/radiators. Interface Protection: All external I/O pins must include Transient Voltage Suppressors (TVS) or optical isolation to protect against surges, particularly for connections to solar panels and RF systems. 2. Software Architecture and Flight Code (CDHS) 💾 The ECU software stack must be modular, fault-tolerant, and predictable, often leveraging specific open-source flight frameworks. Real-Time Operating System (RTOS): A highly deterministic RTOS, like a commercial RTOS (e.g., VxWorks, INTEGRITY) or an open-source alternative like FreeRTOS or a highly customized Linux/RT-Preempt, is mandatory. It ensures time-critical tasks, especially for the Attitude and Orbital Control System (AOCS), meet their deadlines. Open-Source Flight Software: Open-source frameworks have gained traction for small satellites: NASA Core Flight System (cFS): A flight-proven, platform-independent application framework that provides a modular environment with services like Telemetry/Command, File Management, and Scheduling. F Prime (F´): Developed by NASA JPL, this open-source framework is component-driven and tailored for smaller systems like CubeSats, offering a reliable C++ foundation. Fault Detection, Isolation, and Recovery (FDIR): This is the most critical software function. The code must constantly monitor the State of Health (SOH) of all subsystems (power, temperature, voltage).

The story of a #bug 🐞 that never took #flight ✈️ … Imagine we are developing the software that controls an aircraft’s flaps. A small part of the system, but a crucial one: if the flaps don’t work properly during takeoff or landing, the risk is enormous. In the past, the workflow was simple but risky: write the code, integrate it into the hardware, test it… and hope to catch any errors before final certification. A small mistake, like an error interpreting a temperature sensor, could go unnoticed until very late in the process, making it expensive and slow to fix, and in the worst case, jeopardizing the entire program schedule. Today, thanks to #virtual #engineering, that story has changed. Before a single line of code is deployed to real hardware, we digitally model the entire behavior of the system. We model the sensor, the controller, the flap actuators, even the physical behavior of the aircraft itself. During one of these virtual simulations, while automatically testing thousands of flight scenarios, something unusual appears: under certain conditions of low temperature and high humidity, the sensor sends erroneous data that the software misinterprets, triggering a premature deployment of the flaps. A silent fault. Difficult to foresee with traditional testing. But in the virtual world, there are no limitations: we can simulate winter in Canada or a storm over the Atlantic, as many times as we want. Thanks to this early detection, the fault is corrected directly at the #model-in-the-loop level. The logic is adjusted, additional protections are implemented in the software, and all scenarios are revalidated… all before the issue ever reaches a physical prototype, and long before it could ever put a real flight at risk. This small error, which never took flight, is one of the millions of reasons why virtual engineering has become the foundation of any safety-critical avionics software development. Because every fault detected in the digital world is one more step toward excellence in the real world. #Avionics #SafetyCritical #VirtualEngineering #SoftwareDevelopment #ModelBasedDesign

𝑹𝒆𝒂𝒍-𝑻𝒊𝒎𝒆 𝑺𝒆𝒏𝒔𝒐𝒓 𝑫𝒂𝒕𝒂 𝒇𝒓𝒐𝒎 𝑷𝑿4 𝑪𝒖𝒃𝒆 𝑶𝒓𝒂𝒏𝒈𝒆 𝒊𝒏𝒕𝒐 𝑴𝑨𝑻𝑳𝑨𝑩 This video shows the integration of 𝑷𝑿4 𝑪𝒖𝒃𝒆 𝑶𝒓𝒂𝒏𝒈𝒆 𝒇𝒍𝒊𝒈𝒉𝒕 𝒄𝒐𝒏𝒕𝒓𝒐𝒍𝒍𝒆𝒓 with 𝐌𝐀𝐓𝐋𝐀𝐁/𝐒𝐢𝐦𝐮𝐥𝐢𝐧𝐤 to read and visualize realtime 𝐈𝐌𝐔 𝐬𝐞𝐧𝐬𝐨𝐫 𝐝𝐚𝐭𝐚 using 𝐮𝐎𝐑𝐁 𝐭𝐨𝐩𝐢𝐜𝐬. Using the 𝐏𝐗4 𝐔𝐀𝐕 𝐓𝐨𝐨𝐥𝐛𝐨𝐱 𝐬𝐮𝐩𝐩𝐨𝐫𝐭 𝐩𝐚𝐜𝐤𝐚𝐠𝐞, I accessed: - Sensor.Acc (𝘈𝘤𝘤𝘦𝘭𝘦𝘳𝘰𝘮𝘦𝘵𝘦𝘳) - Sensor.Gyro (𝘎𝘺𝘳𝘰𝘴𝘤𝘰𝘱𝘦) - Sensor.Mag (𝘔𝘢𝘨𝘯𝘦𝘵𝘰𝘮𝘦𝘵𝘦𝘳) The accelerometer data was streamed and visualized directly in MATLAB Scope for realtime monitoring and analysis. 𝐓𝐡𝐢𝐬 𝐬𝐞𝐭𝐮𝐩 𝐢𝐬 𝐡𝐢𝐠𝐡𝐥𝐲 𝐮𝐬𝐞𝐟𝐮𝐥 𝐟𝐨𝐫: - UAV research & development - Hardware-in-the-Loop (HIL) testing - Flight control algorithm development - Sensor fusion & filtering experiments - Advanced drone system diagnostics One of the key technical aspects was handling uORB bus signals in Simulink and properly extracting structured data for logging and visualization. This integration demonstrates how powerful the combination of PX4 firmware + Cube Orange hardware + MATLAB/Simulink can be for rapid prototyping and research. If you’re working on PX4, UAV systems, or embedded flight control development, I’d be happy to connect and discuss ideas. #PX4 #CubeOrange #MATLAB #Simulink #UAV #DroneDevelopment #EmbeddedSystems #FlightController #HardwareInTheLoop #AerospaceEngineering

Rusty Flying Robots: Learning a Full Robotics Stack with Real-Time Operation on an STM32 Microcontroller in a 9 ECTS MS Course Arxiv: https://lnkd.in/ewqMrHfi Project: [Link not provided] 🔁 At a Glance 💡 Goal: Teach full robotics pipeline on constrained hardware using Rust for real-time UAV control. ⚙️ Approach: - Simulation: Students implement their own multirotor in Rust, validating with real data. - Controls: Implement geometric nonlinear controllers and integrate with STM32 firmware. - State Estimation: Develop SO(3) filters like MEKF for real-time sensor fusion. - Planning: Create motion planners with quadratic programs for agile maneuvers. 📈 Impact (Key Results) 🧪 Student Feedback: - Overall rating very good (1.1/5). - Students learned to deploy algorithms directly on embedded hardware. 🔄 Practical Skills: - Implemented modern control, filtering, and planning in Rust. - Validation on real UAVs showcased real-time feasibility. 🤖 Effective Teaching: - Combines simulation, low-level coding, and real hardware. - Encourages independent problem-solving and understanding. 🔬 Experiments 🧪 Benchmarks: Custom multirotor simulator, real flight data. 🎯 Tasks: Simulator development, control & filter implementation, motion planning. 🦾 Setup: STM32 microcontroller, Crazyflie 2.1 quadrotor. 📐 Inputs: Sensor data, reference trajectories. 🛠 How to Implement 1️⃣ Build a physics-based simulator in Rust. 2️⃣ Develop nonlinear controllers and validate in simulation. 3️⃣ Port algorithms to STM32 firmware, ensuring C-Rust interoperability. 4️⃣ Implement and tune state estimation filters. 5️⃣ Design and test motion planners with QPs. 📦 Deployment Benefits ✅ Real-time operation on microcontroller. ✅ Code portability across high-level and embedded systems. ✅ No reliance on proprietary software infrastructure. ✅ Enhanced student engagement with real hardware. 📣 Takeaway This course demonstrates the power of Rust for end-to-end robotics education. It enables real-time deployment on constrained hardware without sacrificing safety or performance. Combining simulation, control, filtering, and planning offers a comprehensive learning experience. Such approaches can reshape how robotics is taught at the graduate and undergraduate levels.

Now we are onto the controller of the autonomous drone stack. Over the last couple of days, i've been building the quadrotor simulation from scratch in Matlab, including full physics, IMU modeling and controller integration. As controller, Geometric Tracking Controller on SE(3), enabling the drone to follow both hovering and dynamics 3D trajectories with high stability and agility. Why Geometric Control over PID? Unlike classical PID, this method avoids local linearization and works directy on manifold of rigid body motions (SE(3)), creating a better performance for aggressive and large angle maneuvers. It is based on the paper: Geometric Tracking Control of a Quadrotor UAV on SE(3) (Lee, Leok, McClamroch - 2010). GitHub repo: https://lnkd.in/ddzVW4aG

First demo of converting our in-house flight dynamics and control code to support multiple, heterogeneous, interacting #aircraft / #rotorcraft. 🚁✈️ This simulation features US Army Future Vertical Lift (FVL) concepts modeled at varying fidelity levels: – Generic tiltrotor (rigid flapping + state-space tip-vortex wake) – Lift-offset compound (elastic flap) – Winged single main rotor (rigid-flapping) Flight control laws are now fully in MATLAB (no more Simulink), enabling multi-vehicle, leader–follower, and general multi-agent control architectures. Grateful for partial support from the Vertical Lift Research Center of Excellence (#VLRCOE) — helping us push rotorcraft research forward, year after year! More on my lab's research at: https://umbertosaetti.com/ Alfred Gessow Rotorcraft Center University of Maryland University of Maryland - A. James Clark School of Engineering University of Maryland Department of Aerospace Engineering University of Maryland Research Vertical Flight Society