PX4 Sync / Q&A: Jan 15, 2025

farhang · January 13, 2025, 5:58pm

PX4 Sync / Q&A: Jan 15, 2025
Dronecode Calendar

Agenda

Announcements

A new collaboration with Ascend Engineering for doing flight testings. Their fleet of vehicles suffices for the vehicles PX4 supports.

Future Events

FOSDEM is happening in Feb 1st and 2nd FOSDEM 2025 - Home
@rroche is going to present PX4-Autopilot at FOSEDM

Release Discussion

Changes to look for to achieve 1.16 release:

github.com/PX4/PX4-Autopilot

Removed Functionality: Remove collision avoidance interface on PX4 side

PX4:main ← PX4:pr-remove-avoidance-main

opened 08:01AM - 06 Jan 25 UTC

sfuhrer

+6 -2762

### Solved Problem We have archived the [ROS side of the avoidance](https://git…hub.com/PX4/PX4-Avoidance) some time ago, and the interface on the PX4 side is not actively maintained (most of the initial contributors have left or have a changed focus). With the introduction of external flight modes we have arguably a better way of implementing it, and thus I propose to remove the interface on the PX4 side completely. This saves us quite some flash (5.5k), removes code complexity and prevents new developers to be sent on the wrong (old) track. ### Solution Remove CollisionAvoidance library (which was used in FlightTask), remove health check for avoidance, remove `COM_OBS_AVOID`, remove from message `PositionControllerStatus.msg` the fields `yaw_acceptance` and `altitude_acceptance` that were exclusively used for avoidance and with that also remove some acceptance logic from Navigator. ### Changelog Entry For release notes: ``` Removed Functionality: Remove collision avoidance interface on PX4 side ``` ### Alternatives We could for a start only not build it but leave in code base (as it's [already done for constrained builds](https://github.com/PX4/PX4-Autopilot/blob/821558f9e38d17254f5974e1d1099a879485f84a/src/modules/flight_mode_manager/tasks/Auto/FlightTaskAuto.hpp#L58)). If somebody would complain we could revert more easily. Wouldn't resolve the lingering of a not-maintained PX4 code then though.

So far the flash is within the limit and might need to address that in new release
The preference to have PX4 compatible with the most of setups (regarding moving to new GCC 13.2 which is on Ubuntu 24.04)

Bug report / Q&A

1- [Bug] Unstable height estimates · Issue #24058 · PX4/PX4-Autopilot · GitHub

Relevant PR:

2- [Bug] Multi EKF vehicle local positions starting with large offset on quad indoors · Issue #24206 · PX4/PX4-Autopilot · GitHub

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. **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 al…ways 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.

github.com/PX4/PX4-Autopilot

Control Allocator: Metric

PX4:main ← PX4:pr-metric-allocator-library

opened 07:51PM - 10 Jan 25 UTC

Pedro-Roque

+228 -0

### Solved Problem Adds metric control allocation (ie non-normalized) to make p…ossible model-based control schemes. ### Solution - Replicates pseudo-inverse allocator but without normalization of the outputs - Allows usage on control allocation for compatible vehicle types (such as spacecraft `sc` in https://github.com/DISCOWER/PX4-Space-Systems/tree/dev-sc_ctl_alloc/src/modules/sc_control_allocator ) ### Changelog Entry For release notes: ``` Feature: Metric Control Allocation New parameter: XYZ_Z Documentation: Need to clarify control allocation page ``` ### Test coverage - Unit/integration test: available - Tested in SITL, will provide logs ### Context Depends on https://github.com/PX4/PX4-Autopilot/pull/24196

AlexKlimaj · January 13, 2025, 6:11pm

General unstable height estimates.

github.com/PX4/PX4-Autopilot

[Bug] Unstable height estimates

opened 07:26AM - 30 Nov 24 UTC

mkesselaers

bug-report

### Describe the bug We are using an ARK Pi6xFlow without GPS and are trying …to reliable takeoff to 2 meters. We use both EKF2_BARO_CTRL as EKF2_RNG_CTRL and the HGT_REF is set to barometric. When taking off, sometimes it goes to 2m, but most of the time to somewhere between 3 and 5. Using 1.16.0 alpha, the height was around 1m ### To Reproduce 1. Drone switched on 2. Armed 3. Takeoff to 2m command issued 4. Measure physical distance as soon as the height seem stable) ### Expected behavior Go to the correct height (more or less since exact would be impossible off course) ### Screenshot / Media _No response_ ### Flight Log barometric hgt ref (result 3.2m): https://review.px4.io/plot_app?log=514ae575-9d2e-4687-ab55-6e8836979b02 Range hgt ref (result 2m) https://review.px4.io/plot_app?log=b3753550-44ac-439a-905b-933f7a3932c3 Using 1.16.0 alpha : https://review.px4.io/plot_app?log=8122ff4b-e309-41f5-9257-55d74abbdb5d ### Software Version release 1.15.0 stable One test with 1.16.0 alpha ### Flight controller ARK Pi6xFlow board (Dexi Airframe from DroneBlocks) ### Vehicle type Multicopter ### How are the different components wired up (including port information) ARK board to ESC to Motors. Pi CM4 on ark-board, using MicroUXCREAgent to transform UORB to ROS2 topics. RC and a LED ring are connected to the ARK board as well ### Additional context After takeoff, the height should remain stable, regardless of what the terrain is doing. That's why we want to use barometric height reference, since a distance sensor will cause problems. We're also adding VIO using markers, but don't believe that this would be more reliable then a barometer

Multi EKF instability. Large deltas between estimates causing flyaways when switching. Lack of CI testing for multi EKF.

Patrik_Pordi1 · January 13, 2025, 9:08pm

github.com/PX4/PX4-Autopilot

[Bug] Multi EKF vehicle local positions starting with large offset on quad indoors

opened 08:58PM - 13 Jan 25 UTC

patrikpordi

bug-report

### Describe the bug I’ve been facing significant issues with quads using optic…al flow for localization indoors(no GPS and EKF2_HGT_REF=RANGE). The estimators are starting from a large offset from each other(20-500 m), if the estimator switches the drones tries to compensate. It happens occasionally. ### To Reproduce Fly indoors with no GPS and EKF2_HGT_REF=RANGE in the latest main in position/offboard. ### Expected behavior If the estimator switches the drone should should stay where it is since the estimates should align. ### Screenshot / Media ![image](https://github.com/user-attachments/assets/108a8736-d2ea-4a50-b458-ea4694f5b745) ![image](https://github.com/user-attachments/assets/c3d5fc08-51a5-4910-af74-54e3372ba70f) ### Flight Log https://review.px4.io/plot_app?log=6c072e4a-e0aa-4a46-9833-78db51355d37 https://review.px4.io/plot_app?log=6e490f75-ed41-477a-9d91-771896215a7d ### Software Version Main ### Flight controller ARKV6X Flight Controller ### Vehicle type Multicopter ### How are the different components wired up (including port information) _No response_ ### Additional context I am also having issues with dist_bottom_valid behaving weirdly and invoking fail safe even though the drone seemed fine otherwise.