# PX4 Dev Call: June 29, 2022 **URL:** \ **Category:** PX4 Autopilot\ **Created:** [June 22, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-june-29-2022/28003 "2022-06-22T17:01:06Z")\ **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:** [June 22, 2022, 5:01pm UTC](https://discuss.px4.io/t/px4-dev-call-june-29-2022/28003/1 "2022-06-22T17:01:06Z")
# June 29, 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 * * * ### PX4 master branch naming → ‘main’ 🫶 - In case you want to learn more: visit Github’s [Post](https://github.com/github/renaming) on it 😉 ## 🧑‍🤝‍🧑 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 : Where are parameters saved in Flight controller (physically)? - Vatsal ![image](https://discuss.px4.io/uploads/default/original/2X/2/21deb1636a85677f85e4dd94ae142ea1148396ef.png) - 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](https://px4.io/px4-uorb-explained-part-1/) ## 👷‍♀️ Project Updates * * * ### P.1 : PWM Disarmed value PR > > > \## 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](https://github.com/PX4/PX4-Autopilot/pull/19805) 1. First, Mixer done on IO side kinda worked 2. 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](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_parameters.cpp) ### P.3 : Board information metadata JSON file PR > > > \## 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](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](https://github.com/PX4/PX4-Autopilot/pull/15949#issuecomment-1168325766) - 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](https://github.com/PX4/PX4-Autopilot/pull/19844), 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](https://github.com/PX4/PX4-Autopilot/actions/workflows/clang-tidy.yml) - File Names: [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html#File_Names) ## 📅 Weekly Overview * * * ### 🐁 Github > [Recently updated Issues / PRs in PX4-Autopilot Link](https://github.com/PX4/PX4-Autopilot/issues?q=sort%3Aupdated-desc) **Pull Requests** \* **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 * * *