PX4 Sync / Q&A: Dec 18, 2024

farhang · December 15, 2024, 4:52pm

PX4 Sync / Q&A: Dec 18, 2024
Dronecode Calendar

Agenda

Announcements
Release Discussion
Q&A

Announcements

There will be no calls on Dec 25th 2024 and Jan 1st 2025

Discord announcement to be expected how to update your information on PX4 database for years 2024 Analytics report.

Release Discussion

Bug report / Q&A

1- Flash is size is huge and build fails for some boards

2- Future plan to separate airframes on the builds to save flash maybe?

QGC would also need to have all the separate airframes builds for flashing
Longer CI build times would also be expected

github.com/PX4/PX4-Autopilot

[RFC] Split build targets per vehicle type

opened 05:10PM - 06 Nov 24 UTC

mrpollo

stale

In summary, we will be moving away from a default build target that fits all har…dware, to a per vehicle type, eg: **Current:** * px4_fmu-v6x_default **New:** * px4_fmu-v6x_multicopter * px4_fmu-v6x_fixedwing * px4_fmu-v6x_vtol * px4_fmu-v6x_boat * ...etc... We will also introduce a manifest.json file, with a list of all targets, this json file will live in S3. Our hopes are that QGC fetches the manifest from S3, and builds a list of available options for the user. Once the user selects what they want, they proceed with the firmware update. QGC downloads the right files from S3, following the manifest.json, and then proceeds with the current firmware update We need someone experienced in QGC ## TODO **PX4** * [ ] Generate builds per vehicle target * [ ] Generate manifest.json metadata * [ ] Upload manifest and vehicel targets to S3 **QGC** * [ ] Update PX4 update UI and introduce all the new options * [ ] Build UI based on the manifest.json metadata file (downloaded from S3)

PRs needing review

github.com/PX4/PX4-Autopilot

[Sponsored by ARK] Bidirectional DShot

PX4:main ← dakejahl:dev/bidirectional_dshot_single_timer

opened 10:37PM - 29 Oct 24 UTC

dakejahl

+1344 -251

First of all a big thank you to @julianoes for the initial implementation. This …implementation differs in that it uses up to 4 DMA channels for Capture Compare input on all 4 channels of the first timer. The limitation to a single timer is due to the limited available DMA channels on most boards (4 without PX4IO on ARKV6X) This will work down to 1 DMA channel by only capturing the input from a single timer channel. **Implementation** If Bidirectional DShot is not enabled the implementation is the same as it was before. Timers will be configured for DShot mode if the timer supports Burst Mode and if there is enough DMA channels available (1 DMA per timer). If Bidirectional Dshot is enabled, only the first timer will be configured for DShot due to DMA channel limitations. Burst mode uses 1 DMA, and CaptureCompare mode uses 4 (re-using the DMA used during Burst). An hrt callback is used to process the eRPM frames since DShot frames have predictable timing but unpredictable pulse count. This [webpage](https://brushlesswhoop.com/dshot-and-bidirectional-dshot/#erpm-transmission) was a useful resource. **TODO** - Param for `timer_index` which selects the timer for bidirectional mode. Right now it is hardcoded to the first timer. - Test STM32F7 and fix build for F4/F1 **Further discussion** Initially I wanted to support bidirectional dshot on all timers with DMA simultaneously. This requires triggering each timer (burst/captcomp) sequentially so that we can reuse the available DMA channels between the timers. Timer1 Burst (1DMA) --> Timer1 CaptComp (x4 DMA) --> Timer2 Burst (1 DMA) --> Timer2 CaptComp (x4 DMA) I made it pretty far with this implementation but decide to scrap it because I kept running into race conditions and this development has already taken quite some time. I think it is still possible to do, but is out of scope of this PR. The code is structured in a way that should allow fairly easy extensibility to support this in the future. **Issues** An issue I found but am not fixing here is that DShot.cpp configures all of the channels on timers that have DShot enabled. This results in a pulse train on every channel output on that timer, regardless of if the output function is enabled. The fix is not super easy as it requires extra logic in order to properly initialize the timer channels for burst mode, since the enabled outputs need to be sequential. This is the current implementations behavior so I am leaving it as I found it. **Targets Tested** ARKV6X with 4 DMA channels ARKV6X with 2 DMA channels CubeOrange with 4 DMA channels **Screenshots** ![image](https://github.com/user-attachments/assets/4cba3e58-196c-4dff-b459-81d091ec0f45) ![image](https://github.com/user-attachments/assets/c6a5e2cb-1f54-4838-8f45-d99f08dafbc6)

github.com/PX4/PX4-Autopilot

Add cleanup function for SITL Gazebo on macOS

PX4:main ← farhangnaderi:pr-fix-macos-gazebo-cleanup

opened 12:15AM - 14 Dec 24 UTC

farhangnaderi

+10 -0

### Solved Problem When running PX4 SITL on macOS, pressing Ctrl+C would not always cleanly stop the simulation processes (e.g., gz sim). This often forced users to press Ctrl+C multiple times or manually kill processes. ### Solution - Added a `cleanup()` function guarded by `if [ "$(uname)" = "Darwin" ]`. - Within `cleanup()`, use `pkill -f "gz sim" || true` to stop Gazebo simulation processes. - Clear the `trap` for `INT TERM` signals right before `exit 0`. ### Changelog Entry For release notes: ``` New Gazebo Harmonic SITL on MacOS ``` ### Alternatives We could also add a `kill 0` call or a broader signal handling mechanism, but `pkill -f "gz sim"` suffices for macOS SITL with minimal side effects. ### Test coverage - Local testing on macOS Sequoia. ### Context N/A I cannot add reviewers here. @mrpollo @MaEtUgR @ThomasDebrunner you might want to try.