PX4 Sync / Q&A: Aug 21, 2024

farhang · August 19, 2024, 5:13pm

PX4 Sync / Q&A: Aug 21, 2024:

Agenda

Announcements
Release Discussion
Q&A

Announcements

Updated CI / Github Actions

github.com/PX4/PX4-Autopilot

ci: replace build workflows

PX4:main ← PX4:mrpollo/ci_groups

opened 09:13PM - 14 Aug 24 UTC

mrpollo

+268 -255

# Summary Adds a new workflow for GitHub Actions that builds all of the targets… with visibility into build times. * Replaces the build tests running on github actions for building board targets * Scans the boards directory for all targets with some exclusions that aren't running on actions * Groups targets by platform architecture NuttX, aarch64, armed, base * Generates a build matrix by architecture with sub groups * if a manufacturer directory has less targets than a set LIMIT (currently 10) then makes a single group * if the group has more than LIMIT elements it splits it into groups, most notable example are the PX4/Pixhawk targets * else it creates misc groups under the platform, example: `nuttx-0`, `nuttx-1`... etc. * Reports time elapsed for each build in a summary * Uploads artifacts grouped in a zip * With current setup its generating 23 jobs helping free runners for other CI workflows * Previously Nuttx 60 Jobs * Previously Linux 4 Jobs * Previously ARM64 1 Job * Total measured time for build (with no wait time) ~28m **Link to Succesful Run** https://github.com/PX4/PX4-Autopilot/actions/runs/10408254596 ## Screenshots ### Total Duration ![Screenshot 2024-08-15 at 12 28 07 PM](https://github.com/user-attachments/assets/9bc725b7-b791-46d8-ae4d-7068084bc0cd) ### Matrix Job Summary ![Screenshot 2024-08-15 at 12 23 14 PM](https://github.com/user-attachments/assets/3c277047-b29f-43f8-9237-4f2badc2aaf3) ### Matrix Job Build Step ![Screenshot 2024-08-15 at 12 21 34 PM](https://github.com/user-attachments/assets/c3fb12d3-bfe2-4d9b-be45-04528331f603) ### Build Time on step ![Screenshot 2024-08-15 at 12 21 51 PM](https://github.com/user-attachments/assets/cf682873-6f65-4e6a-ab11-54065c937e39) ### Artifact Downloads ![Screenshot 2024-08-15 at 12 24 46 PM](https://github.com/user-attachments/assets/8021219e-30e9-4f80-a175-5331914ff599) # Next Steps * Include metadata generation and replace current workflow * Include SITL tests and replace the current workflow

Note from @dagar : Maybe shifting over to new gazebo as well for this!

Release Discussion

Project Board

Latest Release Tag

Draft Release Notes

Bug report / Q&A

Flight task might be better to be checked for locked in status and flight tests after:

github.com/PX4/PX4-Autopilot

Random thrust when no thrust input given and optical flow enabled (but not sending data) [Bug]

opened 07:17PM - 19 Apr 24 UTC

dirksavage88

Multirotor 🛸 priority-critical bug-report

### Describe the bug On recent main (early April), when optical flow is enabl…ed with EKF2_OF_CTRL but no optical flow or distance sensor is given, while in Position mode the vehicle will experience a surge in thrust that will ignore set-point despite exceeding the thrust set-point given. ### To Reproduce 1. Enable GPS or VIO as a position source & have valid position fed through sensors 2. Enable barometer with sys_use_baro, but set primary height to vision or GPS (not baro) 3. Enable optical flow as position source, disable range aid fusion 4. Attempt flying in position mode and increase thrust gradually until random thrust occurs 5. Attempt to switch out of position or kill switch as soon as infinite height drift occurs and thrust set-points are ignored ### Expected behavior Despite optical flow sensor/range sensor data not being fed into EKF2, the random thrust occurrence should not happen and thrust setpoints should not be ignored. I have also observed this behavior when range sensor and optical flow _is_ being fused but the rangefinder data fails a condition in the estimator checks (bypassed by setting range fusion to enabled instead of conditional) ### Screenshot / Media ![ignore_setpoint](https://github.com/PX4/PX4-Autopilot/assets/35986980/0bc92fdb-e6ec-43a6-82fc-aa85e95b4d5e) ![random_thrust](https://github.com/PX4/PX4-Autopilot/assets/35986980/76262495-d79e-438c-8fb6-1c6240d3f2fe) ### Flight Log https://logs.px4.io/plot_app?log=ca0d60d8-6dc6-4215-86f4-32fa2ad18f71 ### Software Version Main 1.15.0 apha ### Flight controller VOXL2 ### Vehicle type Multicopter ### How are the different components wired up (including port information) _No response_ ### Additional context _No response_

Maybe reproduced by main branch again and then going forward:

github.com/PX4/PX4-Autopilot

[Bug] (v1.14.3) Holybro Pixhawk 5X: Failed to init INA226

opened 02:43PM - 14 Aug 24 UTC

mrpollo

bug-report

### Describe the bug It seems like the INA226 in the Holybro Pixhawk 5X is no…t being detected using PX4 v1.14.3, I suspect there's an issue in the board config files. Here's en excerpt from the `dmesg` output. Screenshots and full `dmesg` output on the forum post linked below. ``` Board sensors: /etc/init.d/rc.board_sensors INFO [ina226] Failed to init INA226 on bus 1, but will try again periodically. ina226 #0 on I2C bus 1 (external) address 0x41 INFO [ina226] Failed to init INA226 on bus 2, but will try again periodically. ina226 #1 on I2C bus 2 (external) address 0x41 WARN [SPI_I2C] ist8310: no instance started (no device on bus?) bmp388 #0 on I2C bus 4 (external) address 0x77 bmp388 #1 on I2C bus 2 (external) address 0x76 ``` https://discuss.px4.io/t/holybro-5x-sensors-not-found-with-px4-v1-14/39815/5?u=rroche **Sensor Status** ``` nsh> sensors status selected gyro: 0 (0) validator: best: -1, prev best: -1, failsafe: NO (0 events) selected accel: 0 (0) validator: best: -1, prev best: -1, failsafe: NO (0 events) validator: best: -1, prev best: -1, failsafe: NO (0 events) [vehicle_air_data] selected BARO: 6780433 (1) validator: best: 1, prev best: 1, failsafe: NO (0 events) sensor #0, prio: 50, state: OK val: 100474.7813, lp: 100477.6953 mean dev: -0.0350 RMS: 1.6701 conf: 1.0000 val: 30.8700, lp: 30.8779 mean dev: 0.0263 RMS: 0.0341 conf: 1.0000 val: 71.0282, lp: 70.7894 mean dev: -0.0049 RMS: 0.1399 conf: 1.0000 sensor #1, prio: 75, state: OK val: 100508.6563, lp: 100508.9922 mean dev: -0.0533 RMS: 1.5992 conf: 1.0000 val: 31.1700, lp: 31.1797 mean dev: 0.0278 RMS: 0.0717 conf: 1.0000 val: 68.1877, lp: 68.1662 mean dev: -0.0034 RMS: 0.1340 conf: 1.0000 BARO 6780705 EN: 1, offset: 0.000, Internal BARO 6780433 EN: 1, offset: 0.000, Ext Airspeed status: no data [vehicle_acceleration] selected sensor: 0, rate: nan Hz, estimated bias: [0.0000 0.0000 0.0000] ACC 0 EN: 1, offset: [0.000 0.000 0.000], scale: [1.000 1.000 1.000], Internal [vehicle_angular_velocity] selected sensor: 0, rate: nan Hz , estimated bias: [0.00000 0.00000 0.00000] GYRO 0 EN: 1, offset: [0.000 0.000 0.000], Internal vehicle_angular_velocity: gyro filter: 85532 events, 1407745us elapsed, 16.46us avg, min 14us max 32us 0.934us rms vehicle_angular_velocity: gyro filter reset: 0 events vehicle_angular_velocity: gyro selection changed: 0 events [vehicle_gps_position] selected GPS: 0 nsh> ```

github.com/PX4/PX4-Autopilot

mav_sys_id change causes unresponsive system

opened 08:27PM - 14 Dec 23 UTC

ryanjAA

priority-critical bug-report

### Describe the bug If you change mav_sys_id to ≠ 1 you can not reboot or ch…ange anything from QGC. manually rebooting works but then I needed to get out a debug probe to access the fmu to reset the param... ### To Reproduce Used a few different versions of 1.14 release. Setup a plane and then set mav_sys_id to 2 or 3. Try and reboot via QGC and you should get a failed to reboot. I would not recommend doing a manual reboot since you need to set it from a debug board to fix it... ### Expected behavior Should work as previously and have be able to have multiple vehicles on the same network.. ### Screenshot / Media _No response_ ### Flight Log none made ### Software Version 1.14 release ### Flight controller v6c ### Vehicle type Fixed Wing ### How are the different components wired up (including port information) _No response_ ### Additional context Tried 3 different hardwares and software combos (and different versions of qgc between 4.2.9 and 4.3.0)

@marco : what is PX4 roadmap for new Gazebo implementation? How about fast forward possibility which new Gazebo offers?

@dagar : the go to solution cleaned up from the Gazebo classic is x500 for now, which might need to have Gimbal or couple other features added.

PRs needing review

github.com/PX4/PX4-Autopilot

Follow model in gz GUI

PX4:main ← PX4:pr-gz-camera-follow

opened 09:49AM - 27 Feb 24 UTC

Jaeyoung-Lim

+151 -8

### Solved Problem When running the simulation in gz, the model is not being followed by default. - Fixes https://github.com/PX4/PX4-Autopilot/issues/22659 @frede791 FYI ### Solution Start gz with a follow mode engaged to the model ### Changelog Entry For release notes: ``` Feature/Bugfix Gazebo gui follows model by default ``` ### Alternatives We could also create a custom plugin to follow the model ### Test coverage ``` make px4_sitl gz_x500 ``` ![Screencastfrom02-27-2024104558AM-ezgif com-video-to-gif-converter](https://github.com/PX4/PX4-Autopilot/assets/5248102/5d216ccb-549b-44e5-8a78-889a1af61c2c) ### Context - Thanks for the pointers! @srmainwaring - We probably need https://github.com/gazebosim/gz-gui/pull/515 to make the follow camera smoother

github.com/PX4/PX4-Autopilot

gps(septentrio): add resilience information reporting

PX4:main ← flyingthingsintothings:pr-resilience

opened 01:05PM - 06 May 24 UTC

flyingthingsintothings

+405 -9

### Solved Problem When errors occur in attached GNSS receivers, there is no wa…y to report them to the user so they know what is going wrong. ### Solution - Add automatic configuration for Septentrio receivers to report resilience information every second - Add to Septentrio parser so it can parse the new message types - Change the uORB message for GNSS information to support this new information - Report the changes through MAVLink (submodule still needs to be updated) ### Changelog Entry For release notes: ``` Feature: Report resilience information from GNSS receivers Documentation: Need to clarify page ... ``` ### Alternatives \/ ### Test coverage \/ ### Context Another part has been implemented for QGroundControl to display this new information to users. This feature was proposed during the 2022 Developer Summit and received positive feedback. Messages to report jamming and spoofing state were already in the uORB protocol, but weren't used by any modules. I would love to discuss this during the next Community Q&A call on Wednesday 🙂 - https://github.com/mavlink/qgroundcontrol/pull/11486 - https://github.com/mavlink/mavlink/pull/2110

Jaeyoung-Lim · August 21, 2024, 12:52pm

github.com/PX4/PX4-Autopilot

Follow model in gz GUI

PX4:main ← PX4:pr-gz-camera-follow

opened 09:49AM - 27 Feb 24 UTC

Jaeyoung-Lim

+151 -8

### Solved Problem When running the simulation in gz, the model is not being followed by default. - Fixes https://github.com/PX4/PX4-Autopilot/issues/22659 @frede791 FYI ### Solution Start gz with a follow mode engaged to the model ### Changelog Entry For release notes: ``` Feature/Bugfix Gazebo gui follows model by default ``` ### Alternatives We could also create a custom plugin to follow the model ### Test coverage ``` make px4_sitl gz_x500 ``` ![Screencastfrom02-27-2024104558AM-ezgif com-video-to-gif-converter](https://github.com/PX4/PX4-Autopilot/assets/5248102/5d216ccb-549b-44e5-8a78-889a1af61c2c) ### Context - Thanks for the pointers! @srmainwaring - We probably need https://github.com/gazebosim/gz-gui/pull/515 to make the follow camera smoother