PX4 Dev Call: July 27, 2022

rroche · July 20, 2022, 5:00pm

July 27, 2022

Join us

Agenda

Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release

Community Announcement

PX4 Youtube Channel is booming

Check out the Control Allocation video!

Community Q&A (No deep technical discussions)

Guideline for asking a Question

Specify what you are trying to achieve
Specify what environment / platform you are using
Prepare a Link or Document to help understand if possible
First, ask the question on the Slack or create a Github Issue!
If you take over 5 minutes for the question, please continue in Slack or a Github Issue.

Q.1 : Circuit Breaker - Chris

Cons: Currently it’s tedious to enable the circuit breaker (need to set magic-number)
Pros: If we have a bit-flip or any bit errors, we don’t want to accidentally enable the circuit breaker.

Documentation on Circuit Breakers are not specific.
“Flight termination” behavior isn’t easy to predict with current documentation.

Flight Termination Circuit Breaker param is here.

Even if the geo fence violated ‘action’ is to Terminate, we don’t want to fight for this using this ‘circuit breaker’. User should rather be explicitly notified that vehicle WILL terminate, if the action setting is to ‘Terminate’.

Related PR : RFC Commander

github.com/PX4/PX4-Autopilot

[RFC] Commander failsafe state machine rewrite

PX4:main ← PX4:pr-failsafe-statemachine-rewrite

opened 08:08AM - 24 May 22 UTC

bkueng

+2030 -30

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)

Let’s kill a lot of the circuit breakers!

Q.2 : GPS 1 and GPS 2 - Farhang

Putting second GPS to GPS 1, is it correct to do that? GPS signal is not coming in.

Check baud rate
Try out the gps commands (driver) in the console manually
Start with first port, do the gps info & try out the other port as well

Q.3 : How does external compass priority setting work (automatic?) - Junwoo

With a boat (which has an external mag & GPS), it was unclear what kind of setting I needed to apply for a magnetometer priorities.

It should be ok without touching the priorities (PX4 automatically sets external / internal mag’s priorities appropriately)

Can check each sensor_mag message to check if it’s configured to be internal / mag

It would be nice to have an UI that shows which hardware is connected to where, in which rotation, which priorities and what attributes are related in a single view.

CAN / MAVLink can add complexity
Sharing the Device Tree to the UI (e.g. QGC) would be an option as well.

Docker containers - Florian

Using the docker to flash (via USB connection) was tricky. Building the firmware image itself is not a problem.

Giving the privilege when running the container could give permission to detect all the bootloader connections, etc - should be enough to flash the device.

Maybe check the dmesg or lsusb output within the container to check if board is detected

Project Updates

P.1 : Racing boat project

Junwoo is currently integrating PX4 into a Racing boat and posting updates via blog series in the forum. Please feel free to check it out if you are interested!

PR (For reference, is used for testing purposes): [WIP] Rover controller refactor by junwoo091400 · Pull Request #19957 · PX4/PX4-Autopilot · GitHub

P.2 : Helicopter support - Alex & Daniel

Currently bought a helicopter to try out the PX4 support

General Discussions

D.1 : Cube Orange problems

There has been multiple reports of Cube orange having problems with PX4:

Configuration for optical flow (Hereflow)

Let’s collect the problems here:

Cube Orange SD card logging dropouts are high - Alex

Using STM32H7 SDMMC1 causes problem in DMA, so need to use STM32H7 SDMMC2.

Check sd bench command outputs to verify if there’s issue there first
Maybe this might help?

Other

This is pretty cool

Weekly Overview

Github

Recently updated Issues / PRs in PX4-Autopilot Link

Pull Requests

Issues

Pixhawk 6c - Issue Tracking · Issue #19943 · PX4/PX4-Autopilot · GitHub
Bug in master for MicroRTPS SITL bridge : px4_sitl_rtps doesn't work with px4_ros_com micrortps_bridge · Issue #19917 · PX4/PX4-Autopilot · GitHub

Slack

Last Dev-Call

PX4 Dev Call: July 20, 2022

Slack bot to encourage people to use / visit Discuss Forum
- Currently the Slack API doesn’t tell if a message is in a thread or not - Ramon

High priority queue

Discussion based on: https://github.com/orgs/PX4/projects/24