PX4 Sync / Q&A: Jan 22, 2025

dakejahl · January 21, 2025, 8:52pm

dronecan node status logging

github.com/PX4/PX4-Autopilot

uavcan: add node status logging to uORB

PX4:main ← dakejahl:pr-uavcan_node_status_logging

opened 11:50PM - 04 Nov 24 UTC

dakejahl

+158 -36

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 ![Screenshot from 2024-11-04 14-45-31](https://github.com/user-attachments/assets/00b1d5a4-20bc-4670-bb6d-e9a40095fe57)

dronecan esc extended logging

github.com/PX4/PX4-Autopilot

Add Support for DroneCAN Status Extended Message

PX4:main ← iq-motion-control:feature/add_extended_esc_status_logging

opened 03:53PM - 05 Nov 24 UTC

vertiq-jordan

+73 -1

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. ![image](https://github.com/user-attachments/assets/8aab78bc-c135-473c-bc3a-648e465f3c92)

bidirectional dshot – H7 only and single timer only. This is a phase 1 PR, more timers/targets can be added with additional development effort

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)

“minimal” mavlink mode

github.com/PX4/PX4-Autopilot

[mavlink] KConfig for minimal functionality (flash savings)

PX4:main ← dakejahl:pr-mavlink-minimal

opened 02:23AM - 26 Mar 24 UTC

dakejahl

+695 -5

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 ```

Topic		Replies	Views
PX4 Dev Call: June 4, 2025 (Team sync, and Community Q&A) PX4 Autopilot	1	64	June 4, 2025
PX4 Dev Call: May 21, 2025 (Team sync, and Community Q&A) PX4 Autopilot	3	73	May 21, 2025
PX4 Sync / Q&A: Aug 7, 2024 PX4 Autopilot	0	61	August 6, 2024
PX4 Dev Call: November 02, 2022 PX4 Autopilot	0	678	October 26, 2022
PX4 Dev Call: May 28, 2025 (Team sync, and Community Q&A) PX4 Autopilot	3	99	May 28, 2025

PX4 Sync / Q&A: Jan 22, 2025

Related topics