PX4 Sync / Q&A: Jan 22, 2025Dronecode Calendar
Announcements
Future Events
Flight Testing Update
Release Discussion
Bug Report / Q&A
ROS Aerial Meeting ROS Aerial Robotics Meeting of 2025 - Right after the PX4 Dev Call
We are running a beta program with Ascend Engineering (Chicago). They will be running flight testing for the community as part of an arrangement with Dronecode
How to reach out to the team
GitHub: Tag user @PX4 /testflights
Discord: #flight-testing
Weekly on the PX4 Dev Call
How to Request Testing (GitHub)
Write down the steps to test 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
It’s time to start coordinating the v1.16 release.
Here’s what I (@rroche ) think we need:
Identify any open issues in the main branch
Mark relevant queued pull requests for review
We should pull everything relevant and make a conscious decision to leave out what might introduce unnecessary risk for this release period.
It’s important to note that we need more help reviewing; we can only do so much with our limited bandwidth.
Branch out and freeze with no new features added.
as a reminder, release branches are meant for fixes only
Document the v1.16 release
We need help identifying the main features and changes for the release.
Tag the first release candidate for v1.16
Flight test the RC with as many vehicles as possible
Monitor for feedback from the flight ops team and the community
Iterate on RCs as needed
Promote a stable release
Project Board
For release coordination, we will be using the project board.
I’m promising the following stages
Todo : Needs ReviewIn Progress : Changes requested, Flight Ops requestedBlockers : Priority Items with more than a week in queueDone : Everything that made it to the release.
Discussion
Track ownership of features or no ownership
Requirement tracking should be part of the source code so we can verify and keep it up to date
Proposal: have more paid engineers only working in open source
1 Like
Falcon
January 21, 2025, 7:44am
2
Hi,
The updates in recent px4 firmwares seems very huge which caused problems to flyers. It’s not anymore building on top of what’s been done instead it’s changing what’s use to be to a new firmware every update which makes it risky to update every new release comes out.
Hope the developers check the following discussion and discuss it internally because it shows how changes are big which makes it not encouraging to update.
Regards
I just got an X4 from UAV Systems International. It came with arudcopter loaded on a Cube Orange+, but i switched over to PX4 and did a few test flights. The Cube Orange+ is hard mounted, but I though that was okay for the cube since 2 of the imus are mechanically isolated. My drone was a bit twitchy during the flights so I checked the accel logs and sure enough I’m seeing big vibration. Plots are attatched. What is weird is that the first 2 imus are high, but I thought they’d be lower. Any i…
dronecan node status logging
PX4:main ← dakejahl:pr-uavcan_node_status_logging
opened 11:50PM - 04 Nov 24 UTC
Initial implementation taken from https://github.com/PX4/PX4-Autopilot/pull/2388… 2 but reimplemented using the existing interface. This adds ~700B to flash for the extra data in `NodeStatus` but I think it's worth it
dronecan esc extended logging
PX4:main ← iq-motion-control:feature/add_extended_esc_status_logging
opened 03:53PM - 05 Nov 24 UTC
This is the Status Extended portion of a prior PR discussed with @dakejahl here … https://github.com/PX4/PX4-Autopilot/pull/23882. He has handled the Node Status portion in his own PR here: https://github.com/PX4/PX4-Autopilot/pull/23890.
Attached is a log where you can see the ESC Status Extended logging.
[log_1_2024-11-5-10-08-06.zip](https://github.com/user-attachments/files/17635176/log_1_2024-11-5-10-08-06.zip)
Here's a quick snapshot of the input/output throttle percentages from 3 attached ESCs. One motor is configured purposefully so that the input and output throttles should not match.
bidirectional dshot – H7 only and single timer only. This is a phase 1 PR, more timers/targets can be added with additional development effort
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.
**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**
“minimal” mavlink mode
PX4:main ← dakejahl:pr-mavlink-minimal
opened 02:23AM - 26 Mar 24 UTC
Added the KConfig option `MAVLINK_MINIMAL` and `MAVLINK_MSG_SELECT`. Using `MAVL… INK_MSG_SELECT` requires specifying KConfig options `MAVLINK_<message_name>` to enable the mavlink message in the `streams_list`. This follows the same pattern as the `uavcannode` for including message streams. The `MAVLINK_MINIMAL` option disables the message handlers for incoming mavlink data and thus disables functionalities that rely on bidirectional communication. This "minimal" version of the mavlink module simply sends out mavlink messages.
**Problem being solved**
The mavlink module is pretty heavy, and a lot of the flash usage comes from the message handlers for sending and receiving. The ARK Flow has a UART on the debug connection that we can use to send mavlink OPTICAL_FLOW_RAD messages to systems that don't have CAN (e.g voxl2).
See new build target
```
make ark_can-flow_serial
```
**TODO**
- [ ] Figure out a better way to specify the streaming message set rather than the "mode". The pre-defined modes (normal, config, etc) are restrictive and don't give the flexibility to specify the messages or their rates.
Tested successfully
https://github.com/dakejahl/mavlink-cpp/blob/master/examples/listener/listener.cpp#L36-L38
**Before**
```
Memory region Used Size Region Size %age Used
flash: 534457 B 448 KB 116.50%
sram: 16604 B 192 KB 8.45%
```
**After**
```
[4/7] Linking CXX executable ark_can-flow_default.elf
Memory region Used Size Region Size %age Used
flash: 441109 B 448 KB 96.15%
sram: 15804 B 192 KB 8.04%
```
- CONFIG_MAVLINK_MINIMAL -- **58.4KB savings**
- CONFIG_MAVLINK_MSG_SELECT &&
CONFIG_MAVLINK_OPTICAL_FLOW_RAD -- **35.8KB savings**
By simply adding this to the default.px4board
```
CONFIG_MODULES_MAVLINK=y
CONFIG_MAVLINK_MINIMAL=y
CONFIG_MAVLINK_MSG_SELECT=y
CONFIG_MAVLINK_OPTICAL_FLOW_RAD=y
```
1 Like
Falcon
January 21, 2025, 9:51pm
4
Hi again,
I hope you can add “throw to arm” capability to be used in mini drones.
Thanks
Hello,
while downloading uavcan parameters for example uavcan param list 6 get:
This happens when i connect few DroneCAN devices like 2 servos.
Thanks
