farhang
November 3, 2024, 10:55pm
1
PX4 Sync / Q&A: Nov 6, 2024
Agenda
Announcements
Release Discussion
Q&A
Announcements
The next ELISA workshop will be hosted in collaboration with NASA with topics and discussions focused on advancing Space Grade Linux. Location: NASA Goddard Space Flight Center in Greenbelt, Maryland,...
Release Discussion
No major discussions regarding v1.15 so far, plans are for next major release soon.
Bug report / Q&A
PRs needing review:
PX4:main
← PX4:pr-ekf2_range_kin_low_speed
opened 09:48AM - 01 Nov 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
When the height above ground (HAGL) estimate is low, the drone will usually decelerate and then the check would run anymore (default of `MPC_LAND_CRWL` is 0.3m/s and the kinematic consistency checks runs when > 0.5m/s). If the low HAGL estimate is due to bad sensor readings (e.g.: reflections), it will be stuck in that state.
### Solution
Allow invalidating the kinematic consistency at any vertical speed but only validate if there is a significant vertical speed (the latter condition is the same as before).
PX4:main
← PX4:pr-flaps-on-abort-main
opened 09:35AM - 01 Nov 24 UTC
Alternative to https://github.com/PX4/PX4-Autopilot/pull/23795
### Solved Pro… blem
Vehicle could stall during landing abort because flaps are currently instantly retracted.
### Solution
Keep flaps in landing configuration until the abort altitude is cleared.
### Changelog Entry
For release notes:
```
Improvement: FW Position Control: keep flaps in landing config during abort
```
### Test coverage
SITL tested
![image](https://github.com/user-attachments/assets/c0b1896e-ab79-4295-bb53-73e8b8350521)
PX4:main
← microstrain-robotics:microstrain_px4_driver
opened 02:17PM - 29 Oct 24 UTC
This driver enables integration of MicroStrain by HBK sensors with the PX4 autop… ilot system.
Supports the following sensors (At this moment):
*[`MicroStrain CV7-AHRS`](https://www.microstrain.com/inertial-sensors/3dm-cv7-ahrs)
*[`MicroStrain CV7-AR`](https://www.microstrain.com/inertial-sensors/3dmcv7-ar)
Submodule [`mip_sdk`](https://github.com/LORD-MicroStrain/mip_sdk) is required to facilitate communication with MicroStrain sensors.
Currently, only sensor data is published for use by EKF2. Full integration for Inertial Navigation System (INS) capabilities is in development.
Flight log includes a flight where the CV7 accel, gyro, and mag instance is prioritized
https://review.px4.io/plot_app?log=c3bd7d9e-7519-4569-8e51-82e88d31b05d
Flash Savings
The current system is already stretched to far, we can no longer carry a unified build for all systems, we need to split, the team thinks we should split per vehicle type, this will allow for more features to be bundled within each build target, and potentially help us with flash savings for the foreseable future.
Note: we need help from a QGC contributor to help us update the PX4 firmware update process, please reach out to @dagar or @mrpollo
PX4:main
← dakejahl:pr-v6x_flash_savings_mags
opened 01:50AM - 31 Oct 24 UTC
The px4_fmu-v6x target is always out of flash. This blocks merging for everyone … because CI doesn't pass. This kinda feels the same as someone using the last of the toilet paper and not replacing the roll...
23.5kB flash savings
**Before**
```
Memory region Used Size Region Size %age Used
ITCM_RAM: 0 GB 64 KB 0.00%
FLASH: 1946736 B 1920 KB 99.02%
DTCM1_RAM: 0 GB 64 KB 0.00%
DTCM2_RAM: 0 GB 64 KB 0.00%
AXI_SRAM: 100284 B 512 KB 19.13%
SRAM1: 0 GB 128 KB 0.00%
SRAM2: 0 GB 128 KB 0.00%
SRAM3: 0 GB 32 KB 0.00%
SRAM4: 2 KB 64 KB 3.12%
BKPRAM: 0 GB 4 KB 0.00%
```
**After**
```
Memory region Used Size Region Size %age Used
ITCM_RAM: 0 GB 64 KB 0.00%
FLASH: 1923272 B 1920 KB 97.82%
DTCM1_RAM: 0 GB 64 KB 0.00%
DTCM2_RAM: 0 GB 64 KB 0.00%
AXI_SRAM: 100284 B 512 KB 19.13%
SRAM1: 0 GB 128 KB 0.00%
SRAM2: 0 GB 128 KB 0.00%
SRAM3: 0 GB 32 KB 0.00%
SRAM4: 2 KB 64 KB 3.12%
BKPRAM: 0 GB 4 KB 0.00%
```
PX4:main
← PX4:pr-ci-flash-diff
opened 04:00PM - 30 Oct 24 UTC
### Solved Problem
Increase awareness of the impact of a code change on FLASH s… ize. Allow developers to see exactly how much and where their change will increase FLASH usage.
### Solution
- In case of a PR:
- Compile the base revision
- Compile the current revision of the branch
- Diff the flash usage using bloaty
- In case of a commit on main:
- Compile the previous main revision
- Compile the current main revision
- Diff the flash usage using bloaty
### Alternatives / Future
This is an initial working version that includes the following two boards:
- px4_fmu-v5x
- px4_fmu-v6x
If we want, we can easily add more boards in the future.
This version compiles 2 times for each board (1 compile before / 1 compile after) to create the diff. With two boards this results in 4 compiles, which is fast and only creates a small overhead. If we add many more boards, we should reuse the artifacts created by other jobs. However, this will increase the complexity of the code as an external script will need collect the artifacts from the base and current revisions and unpack them.
In addition bloaty has the tendency to detect non-existing remappings (like in the comment below) when there are no changes. In case of real changes the output is however really useful as can be for example seen here:
![image](https://github.com/user-attachments/assets/db92624e-dc4c-481d-b35f-797d48c1f416)
https://github.com/alexcekay/PX4-Autopilot/pull/2
@AlexKlimaj made this helpful resource flash-per-func-inline.txt · GitHub
opened 05:10PM - 06 Nov 24 UTC
In summary, we will be moving away from a default build target that fits all har… dware, to a per vehicle type, eg:
**Current:**
* px4_fmu-v6x_default
**New:**
* px4_fmu-v6x_multicopter
* px4_fmu-v6x_fixedwing
* px4_fmu-v6x_vtol
* px4_fmu-v6x_boat
* ...etc...
We will also introduce a manifest.json file, with a list of all targets, this json file will live in S3.
Our hopes are that QGC fetches the manifest from S3, and builds a list of available options for the user.
Once the user selects what they want, they proceed with the firmware update.
QGC downloads the right files from S3, following the manifest.json, and then proceeds with the current firmware update
We need someone experienced in QGC
## TODO
**PX4**
* [ ] Generate builds per vehicle target
* [ ] Generate manifest.json metadata
* [ ] Upload manifest and vehicel targets to S3
**QGC**
* [ ] Update PX4 update UI and introduce all the new options
* [ ] Build UI based on the manifest.json metadata file (downloaded from S3)
MAVLink GPS_RAW_INT
Clarification
by RyanF:
Which datum is it being used for altitude in GPS_RAW_INT ? (cc @hamishwillee )
https://mavlink.io/en/messages/common.html#GPS_RAW_INT
Merged PRs
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: EKF2_GPS_YAW_OFF
Documentation: Updates merged in PX4 user guide https://github.com/PX4/PX4-user_guide/pull/3406
```
### 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~~
1 Like
Hi, I am currently working on developing new flight controller based on STM32H743, I can’t connect to nsh serial console defined through UART. The serial console is currently defined in UART 3, when I try to connect it using ‘screen’ there is no output from the console.
https://discuss.px4.io/t/need-help-to-setup-serial-console-in-custom-flight-controller/42106
1 Like