PX4 Sync / Q&A: Oct 30, 2024
Agenda
Announcements
Release Discussion
Q&A
Announcements
Release Discussion
Bug report / Q&A
1- Are there any plans to support Ubuntu 24.04?
PX4:main
← PX4:ubuntu-24.04
opened 03:45PM - 13 May 24 UTC
### Solved Problem
[Ubuntu 24.04 stable](https://releases.ubuntu.com/noble/) ca… me out and we already have the first developer @haumarco using it on a new laptop. Some things need to be adapted.
### Issues
- [x] When I followed https://docs.px4.io/main/en/dev_setup/dev_env_linux_ubuntu.html and ran `git clone https://github.com/PX4/PX4-Autopilot.git --recursive` I got prompted to enter https credentials for `Tools/simulation/jsbsim/jsbsim_bridge/models/Rascal` and `ATI-Resolution`. I don't know why that is since the repos are still public.
Ticking this one since it's unrelated and tracked here: https://github.com/PX4/PX4-Autopilot/issues/23124
- [ ] The newer python versions have this annoying [pip package environment enforcement](https://stackoverflow.com/questions/75602063/pip-install-r-requirements-txt-is-failing-this-environment-is-externally-mana). For Arch Linux which had this problem already quite some time ago [I added the `--break-system-packages` parameter](https://github.com/PX4/PX4-Autopilot/pull/21340/files#diff-4ce953c96a002a55eb9773fd29372540c47d736556a63852df9f6950991e6149R70) which is in my understanding not the proper solution so we might as well do it correctly now and use a virtual environment. But I need to first figure out how to do it correctly before rolling that out.
**Related:**
- https://github.com/PX4/PX4-Autopilot/issues/23073
- https://github.com/PX4/PX4-Autopilot/commit/d25938698715dbb6a10e0891471c33a08687bf85
- [ ] `libncurses5` seems not available. Only `libncurses5-dev`? Why? New version?
- [ ] The Java version condition by default uses 14 which doesn't exist. 11 works but we should probably use a newer one if possible.
- [ ] Gazebo neither classic nor gz exist as packages for 24.04 yet.
- [ ] There's a Warning about Compatibility with CMake < 3.5
### Changelog Entry
```
Ubuntu 24.04 support of toolchain
Documentation: Make sure it's reflected on the development environment page.
```
### Test coverage
With this hacky draft I could successfully build `make px4_sitl` and `make px4_fmu-v5x`. I haven't tested more. Let's cooperate to work through the items and do more testing.
PX4:main
← PX4:mrpollo/multiarch-container
opened 07:14PM - 07 Oct 24 UTC
Updates **ubuntu.sh** to work with ubuntu 24.04, and also adds a px4-dev contain… er, which can be used to build px4 and test via GitHub workflows in CI.
- ubuntu 24.04 is now the only supported distribution
- this is important because we previously claimed support for older distributions, but we were not actively monitoring nor testing for support, essentially setting wrong expectations
- Introduces a new in-three container **px4-dev** which takes advantage of the updated ubuntu script
- this container will be used to test the **ubuntu.sh** script is always up to date and working.
TODO
- [ ] github actions workflows
- [ ] check if gcc can be updated to a version available via package manager (apt)
How to use
```
# From project root
./Tools/container/docker_build.sh
./Tools/container/docker_run.sh make px4_fmu-v6x
```
also see #23745 #19982 #21808
PX4:main
← PX4:mrpollo/ci_ubuntu
opened 04:32PM - 30 Oct 24 UTC
test builds in ubuntu 22.04 and ubuntu 24.04
2 - Serial com not working with px4 1.14 and cube orange plus
Either use 1.15 or get an idea from current serial implementation:
/****************************************************************************
*
* Copyright (C) 2023 PX4 Development Team. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. Neither the name PX4 nor the names of its contributors may be
* used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
This file has been truncated. show original
3 - Is there swag store going to be back any time soon?
4- #define RC_SERIAL_PORT "/dev/ttyS0"
is this the only thing to get radio receiver working i have a radiolink sbus and rc_input driver is not able to detect it how to proceed
PRs needing review:
PX4:main
← dakejahl:dev/bidirectional_dshot_single_timer
opened 10:37PM - 29 Oct 24 UTC
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
**Screenshots**


PX4:main
← dirksavage88:pr-dronecan_rtk_yaw
opened 04:33PM - 16 Oct 24 UTC
<!--
Thank you for your contribution!
Get early feedback through
- Dronec… ode Discord: https://discord.gg/dronecode
- PX4 Discuss: http://discuss.px4.io/
- opening a draft pr and sharing the link
-->
### Solved Problem
Adds support for dual RTK heading via AP Periph, which publishes heading as a distinct message (RelPosHeading) instead of via the ecef position fields.
Fixes [#22520](https://github.com/PX4/PX4-Autopilot/issues/22520)
### Solution
- Add sub callback for relposheading within GNSS sensor uavcan driver
- Process heading information and validity in process fixx method
### Changelog Entry
For release notes:
```
Feature: Add support for AP Periph (dronecan) dual GPS heading setups
New parameter: None
Documentation: Pending doc update PR in PX4 user guide
```
### Alternatives
Create a sub to the sensor gnss relative uORB topic directly in [EKF2](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/ekf2/EKF2.cpp#L2430)
### Test coverage
- Tested using dual Holybro ZED-F9P dronecan nodes and pixhawk 6xrt
### Context
TODO: post log
Pending doc update PR: https://github.com/PX4/PX4-user_guide/pull/3406
Merged PRs
PX4:main
← PX4:maetugr/gimbal-timeout
opened 04:33PM - 17 Oct 24 UTC
### Solved Problem
When an angular velocity setpoint (`gimbal_manager_set_manua… l_control`) stops streaming while still commanding non-zero velocity, the gimbal continues turning indefinitely.
Context:
I found this when working with a gimbal that can be steered by a lever but also a "level out" button it's crucial to not constantly send the lever-based angular velocity setpoint (`gimbal_manager_set_manual_control`) because that overrides any button-based attitude setpoint (`gimbal_manager_set_attitude`) immediately again. Solution: only send angular velocity setpoints when the lever is actually deflected and stop sending them when they are zero. But what happens if you lose connection?
### Solution
1. Little refactor (optional)
2. Save the timestamp of the last received setpoint for every single input case.
3. Implement a timeout to stop the gimbal if the last non-zero angular velocity setpoint was too long ago
### Changelog Entry
```
Fix: Stop gimbal from spinning when an angular velocity setpoint stream times out
```
### Alternatives
@julianoes I'm eager to find out if you have any better idea or implementation architecture in mind to solve this problem.
### Test coverage
I tested using MAVLink gimbal V2 as in- and output. I mapped a lever to gimbal pitch-rate and shut the input MAVLink connection while the lever was deflected and gimbal moving. Before the change it would continue spinning indefinitely, with my pr there is no update anymore for 2 seconds and then there is one single update that commands the gimbal to 0 pitch-rate and it stops. Note: When I tried NAN that caused the gimbal to reset its orientation which I consider undesired e.g. during connection dropouts.