PX4 Dev Call: June 29, 2022

rroche · June 22, 2022, 5:01pm

June 29, 2022

Join us

Agenda

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

Community Announcement

PX4 master branch naming → ‘main’

In case you want to learn more: visit Github’s Post on it

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 : Where are parameters saved in Flight controller (physically)? - Vatsal

Problem now : Not sure if saving parameter in Flash is possible.
Answer : In STM32, there’s flash backend.
Also can utilize MTD / NuttX to store the parameters
Usually in FRAM, after v1.12, it would also save into a SD card

Q.2 : Is Px4 using ROS? - Kevin

MAVROS exists as a bridge between Px4 and ROS
MAVLink is used for telemetry & controlling PX4 vehicle
MAVROS is bridging that MAVLink connection as a ‘ROS Node’
There exists uORB messaging system that acts like ROS system!
Check out the tutorial blog post on uORB → PX4 uORB Explained: Part 1 - PX4 Autopilot

Project Updates

P.1 : PWM Disarmed value PR

github.com/PX4/PX4-Autopilot

PWM: Use disarmed value as default failsafe value (#19836)

main ← failsafe-defaults-disarmed

opened 07:24AM - 25 Jun 22 UTC

MaEtUgR

+84 -82

## Describe problem solved by this pull request Before https://github.com/PX4/P…X4-Autopilot/pull/19805 failsafe values stayed 0 which resulted in PWM signal being lost completely upon vehicle termination if not configured explicitly different per channel. The pr introduced default failsafe values of 900 for channels configured as ESCs and 1500 for servos. While this solved most cases there remain some unsafe ones where the output is not correctly masked as ESC, mistaken for a servo and even though the disarmed value is 0 or even set to 900 and the motor not turning when disarmed it can spool up upon vehicle termination. Also, it could be that an ESCs and servos are calibrated/set up for a different idle values than 900 and 1500 in which case the failsafe value is out of sync with the disarmed one and has to be set separately. E.g. @RomanBapst reported a VTOL pusher which was presumably not masked as ESC spinning up after vehicle termination. ## Describe your solution **My suggestion to prevent these cases is to use the channel's disarmed value as the default failsafe value.** The user has to then only change it in case he wants to have a specific PWM value other than the disarmed one for a channel upon termination e.g. to set up a PWM parachute or bring a PWM gimbal into its safest position. ## Describe possible alternatives I know this only applies to the legacy mixing system and probably mostly benefits the 1.13 release. I'll follow up with @bkueng about the new dynamic one. **EDIT:** I'll still check in but according to this the new mixing already follows this logic: https://github.com/PX4/PX4-Autopilot/blob/55563eba49f87624d7b73356ea3d421fee7ec081/Tools/module_config/generate_params.py#L281 ## Test data / coverage I did not test these code changes yet. I first want to get feedback on the proposed changes. ## Additional context IO mixing to FMU: https://github.com/PX4/PX4-Autopilot/pull/16444 Default PWM configuration loading: https://github.com/PX4/PX4-Autopilot/pull/17833 Fix for failsafe defaults being 0: https://github.com/PX4/PX4-Autopilot/pull/19805

Had a case where Motor was wrongly configured as a Servo, and having it go to 1500 PWM value fired up the motor!
Related PR on Failsafe: PWM set all failsafe values by Igor-Misic · Pull Request #19805 · PX4/PX4-Autopilot · GitHub

First, Mixer done on IO side kinda worked
Next, mixer being done in FMU now

Need to review exceptions like Parachute, in terms of configurable failsafe value

P.2 : Generic Button/Switch support support for old QGC

Need to keep Parameters as depreciated, and then fade it out
MAVLink also has implementation to make sure QGC doesn’t get confused due to missing parameters: PX4-Autopilot/src/modules/mavlink/mavlink_parameters.cpp at main · PX4/PX4-Autopilot · GitHub

P.3 : Board information metadata JSON file PR

github.com/PX4/PX4-Autopilot

Generate Board Information metadata in CI (#19848)

main ← junwoo091400:pr_bootloader_id_qgc_sync

opened 01:27PM - 29 Jun 22 UTC

junwoo091400

+227 -5

## Describe problem solved by this pull request There were multiple instances w…here the QGC didn't have the fully updated list of bootloader IDs for the boards supported by PX4, which led to **users not being able to flash their boards as QGC didn't recognize them** (and didn't know which firmware was needed to be flashed) For example, a user reported problem here: https://github.com/PX4/PX4-Autopilot/issues/19432 and it was manually fixed in QGC side here: https://github.com/mavlink/qgroundcontrol/pull/10252. **This is not scalable**, and is a lot of manual labor of copying the data from the PX4's side to QGC side (although it's not too intensive). ### Key Improvements 1. QGC being able to automatically detect new boards by it's board ID, when the board is added in PX4 side 2. QGC being able to auto-connect new boards by it's vendor & product ID (and name), when a new board is added in PX4 side ## Describe your solution ![PX4_Board_Information_Json](https://user-images.githubusercontent.com/23277211/176460048-1e7a2e4e-8f80-4004-b12b-441a266d98cb.png) The aim of this PR is to automatically generate the **board information JSON file** that includes all the information needed to flash / build / download target builds, which QGC can then download and update the supported boards list to the latest data. ### Update to QGC Repository First, the JSON file will get updated to the QGC Repository as a Pull Request or a direct commit like [how the Parameter / Airframe Metadata is getting synced](https://github.com/mavlink/qgroundcontrol/commit/1fa8485f7fa12eb19b3fc07f2cffe4bc2d3bb8c4) via Jenkins CI. This will make sure that QGC will have the latest Board information and will always fully support all the boards for flashing :+1: ### Update to Local QGC Second, the JSON file will be uploaded to a S3 server, for example to a place like: https://px4-travis.s3.amazonaws.com/Firmware/master/_general/board_info.json. This will then get pulled to local QGC installations so that the QGCs with the internet connection will have the latest board information Json file as well. ### Existing Use-Case Ardupilot already does that (and QGC supports this Server-fetch based board information update) by this manifest link: https://firmware.ardupilot.org/manifest.json ### Information inside board_information.json This file should include generic information about the board targets, and not be limited to bootloader ID itself (which is crucial for QGC), so that we can utilize the file in many different applications. ``` { "board_name" = "HUMAN_READABLE_BOARD_NAME", (summary) "target_name" = "TARGET_NAME_FOR_BUILD", (manufacturer_board_label) "description" = "DESCRIPTION", (description) "board_id" = "BOOTLOADER_ID", "image_maxsize" = "FLASH_SIZE", "build_variants" = {"VARIANT_1", "VARIANT_2", ... }, (labels) } ``` :exclamation: If any critical information is missing, please let me know! ## Describe possible alternatives The Board information JSON file can be loaded into board's Flash as a [component information](https://github.com/PX4/PX4-Autopilot/pull/16039) as well, but that would mean that a PX4_FMU-V5 board would need to hold all the information about ATL_MANTIS-EDU, PX4_FMU-V3, and so on, which doesn't make sense especially since we are constrained in Flash memory. ## QGC PR https://github.com/mavlink/qgroundcontrol/pull/10343 ## Additional context Related discussion / PRs in the past - https://github.com/PX4/PX4-Autopilot/issues/16351 - https://github.com/mavlink/qgroundcontrol/pull/9221 - Related discussion in QGC for this feature: https://github.com/mavlink/qgroundcontrol/issues/2797

Switch from Jenkins to Github Actions
https://github.com/PX4/PX4-Autopilot/blob/main/.ci/Jenkinsfile-compile
There are some issues on QGC Windows with Orange? board / etc.
TODO : Try out any NON-PX4 boards: Cube, etc. Weird Driver issue
Matthias using KAKUH7 with no issues on Windows
Let’s give a test with the QGC build on Mac/Linux/Windows platform and make sure the JSON fetching part works!

General Discussions

D.1 : manual_control_setpoint message roll/pitch/yaw … x/y/z naming

Discussion is here

Proposing renaming the fields as roll/pitch/yaw/throttle
What about Rovers?
- We don’t have unified control mode for Rovers (some people use Yaw, some Roll, etc)
What about Throttle range?

D.2 : Getting Follow Me into V1.13

PR is up, just needs a quick review

D.3 : Coding Format

CLang format
CLang tidy : Takes a long time to build (Currently done in Github Actions!)
Static Analysis · Workflow runs · PX4/PX4-Autopilot · GitHub
File Names: Google C++ Style Guide

Topic		Replies	Views
PX4 Dev Call: June 15, 2022 PX4 Autopilot	0	667	June 8, 2022
PX4 Dev Call: May 25, 2022 PX4 Autopilot	0	654	May 18, 2022
PX4 Dev Call: July 20, 2022 PX4 Autopilot	0	944	July 13, 2022
PX4 Dev Call: August 10, 2022 PX4 Autopilot	1	709	August 10, 2022
PX4 Dev Call: May 18, 2022 PX4 Autopilot	0	696	May 11, 2022