# PX4 Dev Call: May 25, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [May 18, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-may-25-2022/27512 "2022-05-18T17:01:29Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![rroche](https://discuss.px4.io/user_avatar/discuss.px4.io/rroche/32/17635_2.png) [@rroche](https://discuss.px4.io/u/rroche)\ **Post date:** [May 18, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-may-25-2022/27512/1 "2022-05-18T17:01:29Z")
# May 25, 2022 ## Join us > **[Jitsi Meet](https://meet.jit.si/PX4DeveloperCallWeekly)** > > Join a WebRTC video conference powered by the Jitsi Videobridge ## Agenda - Community Announcement - Community Q&A - Project Updates - General Discussions - Weekly Overview - High priority queue - Release ## πŸ“’ Community Announcement > **[Schedule | LF Events](https://events.linuxfoundation.org/px4-developer-summit/program/schedule/)** > > Register Now All session times are listed below in Eastern Standard Time (EST). To view the schedule at your preferred time, please choose your location on the right-hand navigation panel under… * * * ## πŸ§‘β€πŸ€β€πŸ§‘ Community Q&A (No deep technical discussions) * * * ### ❗ Guideline for asking a Question 1. Specify what you are trying to **achieve** 2. Specify what environment / **platform** you are using 3. Prepare a **Link** or **Document** to help understand if possible 4. First, ask the question on the **Slack** or [create a **Github Issue**](https://github.com/PX4/PX4-Autopilot/issues/new/choose)! 5. If you take over 5 minutes for the question, please continue in Slack or a Github Issue. ### Q.1 : Can you trigger the kill switch from QGC? (moving away from RC) We think you should use the [`MAV_CMD_DO_FLIGHTTERMINATION`](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_FLIGHTTERMINATION) mavlink message, and there are other params that help you roll back if needed before termination > ## πŸ‘·β€β™€οΈ Project Updates * * * ### P.1 : Switching to control allocation by default, but we need to move the airframes and mixer files. This is the right time to start doing this Plan: - Starting with simulated vehicles go through all vehicles you care about - [ROMFS: start converting airframes to default control allocation by dagar Β· Pull Request #19631 Β· PX4/PX4-Autopilot Β· GitHub](https://github.com/PX4/PX4-Autopilot/pull/19631) ### P.2 : Request for comments for a new failsafe state machine architecture: > > > I was working on preflight check reporting with the events interface and wanted …to check how it could fit into the whole structure. So I came up with this: > !\[commander drawio\](https://user-images.githubusercontent.com/281593/169977325-5cf1068e-08ad-42a9-9dc9-45599e615754.png) > > > The basic idea is that the arming/health checks do the GCS reporting, prevent all or individual modes from arming, and can set flags that are then used in the failsafe state machine (the checks run and report during arming as well). > This PR is about implementing the failsafe state machine part. > > \### Failsafe state machine > \- As one of the basic requirements, there needs to be a way to generate user documentation from the code. > I ended up using Emscripten, which allows to compile the C++ code directly to webassembly and run it in the browser. So any possible failsafe combination can be checked directly, and the logic corresponds 1:1 to what runs on the vehicle. > This allows to implement arbitrary logic in the C++ code. > At the same time it is very convenient for development (testing and debugging) as well. > The condition flags are extracted from the msg file directly, and there's a minimal parameter storage. The accessed parameters are added to the UI (using the parameter json metadata). > The implementation of this PR can be tested under https://logs.px4.io/plot\_app/static/failsafe\_test/index.html. > Use \`make run\_failsafe\_web\_server\` to build & run it locally. > \- The implementation is split into a generic framework (base class) and class that implements the actual checks (this could be vehicle-specific). > - The framework maintains a set of active actions and an action becomes active when a condition is triggered. Action can have additional settings (e.g. if user takeover is allowed). The selected failsafe is then the most severe active action. > So it's well-defined what happens when multiple failsafes trigger. > Then there's fallbacks to the next option, should the desired failsafe not be available. > - clear condition: by default, when the failure condition clears, the vehicle goes back into the user intended mode. An action can change this to e.g. clear only on disarming or on mode switch. > - user takeover: the default behavior is when an action is triggered, the vehicle first goes into Hold for N seconds (configurable, and disabled for N=0), with a user notification. During that time the user cannot take over. After that the action is triggered and the user can take over by switching into any mode or moving the sticks. > - \`can\_run\`: this is a bitset for each mode if it can be executed (basically what \`main\_state\_transition\` currently does). This is used by the failsafe state machine for mode fallback. We probably need more granularity here later on (e.g. which modes require position). > - The behavior generally matches closely what we have now, apart from generically handling multiple failsafes. It can generally be changed as we need it. > \- state machine inputs: minimal state (armed, vehicle type, user intended mode, user takeover request, etc), \`vehicle\_status\_flags\` (conditions) and param configuration > \- output: failsafe action (if any), updated user intended mode > \- Not everything is done yet, for testing I implemented the core of the existing failsafe state machine, \`set\_nav\_state\`, user takeover and a few other things. > \- I'm also suggesting to change the lockdown action to disarm. > > Feedback is welcome, also unexpected or unintended behavior (there's generally various details that can be done one way or another). > Thanks to @KonradRudin & @MaEtUgR for testing & support. > > Screenshot of the web sim: > !\[image\](https://user-images.githubusercontent.com/281593/169977907-cd060eff-674f-44d3-94b9-ab3883218c6e.png) Proof of concept for all the mechanisms we should need to replace the current failsafe handling. Can be simulated by building a local web application directly from the C++ code to test out scenarios easily. ### P.3 : Priority inheritance bug in NuttX. The last remaining release blocker for PX4 1.13 was a priority inheritance bug in the real time OS that was found by brute force constantly disarming. ## πŸ€” General Discussions * * * ### D.1 : ## πŸ“… Weekly Overview * * * ### 🐁 Github > [Recently updated Issues / PRs in PX4-Autopilot Link](https://github.com/PX4/PX4-Autopilot/issues?q=sort%3Aupdated-desc) **Pull Requests** - [Support on Generic button/switch triggers by RC Controller by junwoo091400 Β· Pull Request #19638 Β· PX4/PX4-Autopilot Β· GitHub](https://github.com/PX4/PX4-Autopilot/pull/19638) - **Issues** \* ### πŸ’» Slack ### ☎ Last Dev-Call > [PX4 Dev Call: April 27, 2022](https://discuss.px4.io/t/px4-dev-call-april-27-2022/27066) - ## ❗ High priority queue * * * Discussion based on : [https://github.com/orgs/PX4/projects/24](https://github.com/orgs/PX4/projects/24) ## 🌾 Release * * *