farhang
September 30, 2025, 9:49pm
1
PX4 Sync / Q&A
Agenda
Announcements
Future Events
Flight Testing Update
Release Discussion
Bug Report / Q&A
Announcements
The PX4 DevSummit you all were waiting for
Sponsorship opportunities are still open till end of this week:
The Dronecode Foundation is thrilled to announce that the PX4 Developer Summit will return in 2025, this November 10-11 in Atlanta, Georgia, at the Omni Atlanta Hotel at Centennial Park....
Future Events
ROSCon 2025 Singapore
Contribute to Dronecode/roscon-25-workshop development by creating an account on GitHub.
Flight Testing Update
About the Test TeamThe team at Ascend Engineering (Chicago). are running flight testing for the community.
How to reach out to the team
GitHub: Tag user @PX4PX4 **/testflights**
Discord: Flight Testing & Log Analysis
Weekly on the PX4 Dev Call
How to Request Testing (GitHub)
Write down the steps to te@PX4PX4t your issue/pull request
Make sure to note the risk involved in flying
Write down things to look out for / anticipate - eg: “we are looking for no yaw jumps”
Add issue/pull request to the Flight Testing project board
Make sure to specify any hardware/software requirements as much as possible
main ← mrpollo/search_improvements
opened 06:47PM - 19 Sep 25 UTC
This PR tries to improve search by git hash or git tag, local results are great!
Notes:
EKF2 tests with VOXL2
EKF2 with OpticalFlow sensor (ARKFlow sensor)
Release v1.16 Issues?
Backports
release/1.16 ← backport_1.16/pr-available-modes-throttle
opened 01:16AM - 28 Sep 25 UTC
backport https://github.com/PX4/PX4-Autopilot/pull/25428
release/1.16 ← backport_1.16/mavlink_camera_dronecan_routing_bug
opened 10:03PM - 27 Sep 25 UTC
backport https://github.com/PX4/PX4-Autopilot/pull/25651
release/1.16 ← backport_1.16/serial_drain_revert
opened 09:57PM - 27 Sep 25 UTC
backport https://github.com/PX4/PX4-Autopilot/pull/25538
release/1.16 ← backport_1.16/uavcan_esc_init
opened 09:55PM - 27 Sep 25 UTC
backport https://github.com/PX4/PX4-Autopilot/pull/25485
release/1.16 ← mrpollo/116_macos_ci
opened 03:30PM - 29 Sep 25 UTC
locks down gcc v9 and brings a fix for macos sitl
release/1.16 ← backport_1.16/ark_fpv_vtol
opened 09:51PM - 27 Sep 25 UTC
backport https://github.com/PX4/PX4-Autopilot/pull/24768
release/1.16 ← pr-accel_cal_1.16_backport
opened 06:14PM - 25 Sep 25 UTC
v1.16 backport of https://github.com/PX4/PX4-Autopilot/pull/25626
As soon as backports are merged and settled we can aim for the point release.
Community Q&A / PRs for Review
PX4 documentation is now served by S3 and CloudFront instead of GitHub Pages.
We finally outgrew the GitHub Pages solution, as it was dragging us down with huge deployment times of up to a few hours. The new solution is fast and easy, allowing us to scale.
Issues:
PRs:
luka
October 1, 2025, 10:16am
2
Hello, can these two PRs be reviewed?
main ← Luka-Filipovic:diagonal-flights-fix
opened 03:09PM - 03 Sep 25 UTC
### Solved Problem
Fixes https://github.com/PX4/PX4-Autopilot/issues/24223
#… ## Solution
- Couple XY and Z speeds at the target waypoint considering the slope from the target to the next waypoint. In other words, determine what the velocity setpoint should be once the target waypoint is reached, and use that as the limiting speed in both XY and Z directions.
- Brake to the full stop if Z direction is changing in the target waypoint. This will effectively not make the trajectory fully stop but rather slow down until it enters the acceptance radius of a waypoint, i.e. until the triplet is updated. I am open to suggestions on how to improve this part and let the trajectory pass through the waypoint with higher but still safe speed.
### Test coverage
1. The old logic overshoots the path because of the slope change, the new logic follows the path properly but slows down in horizontal axis.
Mission profile:
<img width="2408" height="430" alt="image" src="https://github.com/user-attachments/assets/df62e8d6-61c9-4e11-8627-0fd35b7b7728" />
Old:
<img width="2656" height="2132" alt="old2" src="https://github.com/user-attachments/assets/fa41edea-fe82-48d1-a339-e9c895cc931a" />
New:
<img width="2656" height="2132" alt="new2" src="https://github.com/user-attachments/assets/2935814a-581a-4a58-a595-ed9ba00ddcac" />
_The RVIZ visualization from screenshots shows mission path (connected waypoints) in pink and trajectory setpoints in cyan._
main ← Luka-Filipovic:set-loiter-from-last-position-type-setpoint
opened 11:44AM - 24 Sep 25 UTC
### Solved Problem
When the final mission waypoint is reached, the navigator se… ts the loiter position setpoint to the current position instead of the mission’s intended waypoint.
As a result, the vehicle ends up loitering at the position where it entered the waypoint’s acceptance radius, instead at the waypoint itself.
### Solution
On mission end, call `setLoiterItemFromCurrentPositionSetpoint()` if current position setpoint is of type `SETPOINT_TYPE_POSITION`
Thanks!
Could this PR get reviewed as well?
main ← pr-speed-weight
opened 11:17AM - 30 Sep 25 UTC
### Solved Problem
When trying to enable pure airspeed control with the ROS 2 f… ixedwing control API, it was apparent that the speed weight of TECS was not exposed by the control API. However, rather than exposing this interface we can guess which speed weight we would need to use depending on which setpoint (height + airspeed or airspeed) we are using.
### Solution
This PR adds automatically setting TECS speed weight to 2 in case the height or height rate setpoints are invalid.
I don't think it makes sense to have the speed weight 0 or 1 if there is no height or height rate to track.
This enables pure airspeed control using the PX4 ROS2 control API. This is mainly useful for performance estimation or gliding.
@nbobbili @lucamorando95 @msberk FYI
### Changelog Entry
For release notes:
```
Feature/Bugfix Airspeed only setpoint for fixed-wing aerial vehicles
New parameter: N/A
Documentation: Need to update the px4 control API.
```
### Other Alternatives
We can expose the speed weight on the ROS2 control API