Announcements
Release Discussion
Q&A
@farhang asked how the situation is with this PR
PX4:main ← dirksavage88:remote_id_arm
opened 01:27PM - 28 May 23 UTC
-Changed operator position to Live GNSS: To test you will need a tablet/laptop … with built-in GPS or a USB GPS receiver module. Using QGC daily (they have merged the Remote ID support) you will need to select remote ID in the settings -> https://github.com/mavlink/qgroundcontrol/pull/10600
-Added prototype arm status through the health and arming checks module. This is just for testing purposes and the actual implementation can be different. If you have remote ID enabled but don't have a module plugged in, you will still be able to arm. However if you have a module plugged in and it is not receiving valid GPS or some other failure in operator ID or basic ID it will result in a preflight fail and not allow you to arm.
-Added mavlink receiver support for drone ID arm status
According to David Sastre we are trying to verify the following settings:
**GPS indicator:** If set to FIXED, it will go green if valid lat/long is introduced. If it is set to LIVE, it will go green if valid GPS is received, and latest GCS GPS info is received less than 5 seconds ago. It will go red otherwise. Also, if it is set to LIVE, but region is set to FAA, it will go red if GCS GPS doesn't provide altitude ( needed for FAA region ), but for EU this doesn't apply as altitude is not mandatory.
**Basic ID:** will go green if the armstatus message received is "GOOD_TO_ARM". It will go red if armstatus message reports an error string "missing basic_id message". This is not ideal, but it is the only way given the circumstances of detecting precisely when it is just Basic ID failure. A bitmask or something in armstatus message will be more appropriate, but these are the cards we can play with.
**Arm status:** will go green if armstatus message is good. If armstatus message contains errors it will go red.
**Comms indicator:** will go green as soon as we receive an armstatus message. Will go red as soon as the timeout ( 2.5 seconds ) expires with no message received.
**Operator ID:** will only check if the data set in QGC is valid, not empty and valid ID type.
@dannytoone
PX4:master ← saosebastiao:update_python_for_virtual_environments
opened 12:35AM - 05 Jun 24 UTC
Hello, this pull request adds virtual environment support for the docker builds.… This is necessary because newer versions of macos and ubuntu are using python3.12 by default and 3.12 blocks installation of pip dependencies using user level packages and require you to install all libraries using virtual environments. I'm currently working on a PR for this in https://github.com/PX4/PX4-Autopilot/pull/23228, but cannot progress past the CI/CD failures which depend on this package being available.
@thomasfrans
PX4:main ← flyingthingsintothings:pr-extract-septentrio-driver
opened 09:25AM - 19 Mar 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
Making changes to the PX4 GPS drivers was hard because new features needed to be implemented for every driver. This isn't possible for most people as they don't have access to the hardware required for testing. During the previous PX4 community Q&A on Discord (2024-03-13), I discussed with @dagar what the options were to simplify this. The solution that was proposed was to separate all the drivers as they all want to specialize more than originally planned. This would allow the drivers to have their own parameters and implement features more rapidly. It would also simplify testing, as people who want to implement a new feature only need access to the hardware for a single driver.
Fixes \/
### Solution
- Extract the Septentrio GPS driver out of the submodule into its own directory, included in the PX4 autopilot repository.
### Changelog Entry
For release notes:
```
Feature/Bugfix XYZ
New parameter: XYZ_Z
Documentation: Need to clarify page ... / done, read docs.px4.io/...
```
### Alternatives
We could also ...
### Test coverage
- Unit/integration test: ...
- Simulation/hardware testing logs: https://review.px4.io/
### Manual Testing
- Pixhawk 6C & mosaic-go heading:
- Automatic GNSS receiver configuration works
- Position shows up in QGroundControl
- Number of reported satellites is correct
- Corrections from base station, forwarded by QGroundControl work
- Automatic startup of driver works
- Connection to receiver is stable and doesn't drop
- `status` command works
- Driver start and stop work
### Context
- [Forum post about developer call where this was discussed](https://discuss.px4.io/t/px4-community-q-a-march-13-2024/37190)
- [Original idea to split up driver](https://github.com/PX4/PX4-Autopilot/pull/22874#issuecomment-1992516897)
- [Teseo GPS driver used as reference](https://github.com/AlexKlimaj/PX4-Autopilot/tree/60a14ce240a09855e4ddf5e9690ca20a46e34aa2/src/drivers/teseo_gps)
- Other drivers in the PX4 autopilot repository were used as a guide (barometer, distance sensor...) because they are also split into separate drivers.
@Rowan_Dempster asked about how to handle ekf replay and timestamps
@dagar and @bresch recommended to add logging ekf replay at the boot or prior to the arming couple seconds. Also maybe a more general way is available . EKF Reply overhaul PR maybe expected from dagar.
@bresch recommended to try this PR which is tested on hardware:@AlexKlimaj will test it .
PX4:main ← PX4:pr-ekf2_terrain_state
opened 03:39PM - 12 Jun 24 UTC
### Solved Problem
- The terrain estimator depends on the EKF2 states so it's n… ot possible to use a distance sensor or an optical flow in both estimators at the same time.
- Uncertainties of the altitude above ground are also not handled correctly when used for optical flow fusion.
- Range height fusion requires to estimate a height bias while this bias is the actual terrain height.
### Solution
Add a "terrain height" state to the EKF and modify the range and optical flow measurement jacobians to use it. This allows to simultaneously use those sensors for altitude, terrain height and velocity estimation.
Using optical flow without a range sensor is also possible as the EKF would run as a poor man's VIO system.
The height above ground uncertainty is also now correctly handled and oscillations at higher altitudes due to over corrections from optical flow should be reduced. (To be tested)
### Changelog Entry
For release notes:
```
TBD
New parameter: XYZ_Z
Documentation: Need to clarify page ... / done, read docs.px4.io/...
```
### Test coverage
- Unit tests
- Indoor bench tests
- Range + flow fusion:
- Flow only (dist sensor data logged for comparison):
Indoor flight tests (range + flow and flow only)
TODO:
- [ ] outdoor flight testing
- [ ] names cleanup (rng_hgt vs hagl)
@dagar
PX4:main ← PX4:pr-ekf2_symforce_cmake_targets
opened 03:50PM - 03 Jun 24 UTC
- if symforce available always regenerate in build and use output in build direc… tory
- add new helper target (ekf2_generate_symforce_default) to regenerate default in tree symforce output
When is px4 1.15 released?
1 Like
Is there a reason for the delay in the release of version 1.15.0 stable? If a new release date has been set, I would like to know it.
@realstone1 @kiti1013
until the release tag is cut and can be done directly via QGC!
