June 06, 2023
The maintainers meeting is a meeting for the developer team to coordinate on pressing issues and to plan the development of the PX4 Autopilot project, the community is welcome to join and listen, but won’t be able to speak unless specific access is granted ahead of time.
Meeting Link
We are a community of people who are interested in developing open source technology for drones. PX4, Pixhawk, QGC | 2,294 members
Agenda
Meeting Notes
v1.14 Release remaining issues
Kill gesture
Some people hit the gesture during manual mode. Matthias is suggesting to improve the gesture logic to improve safety & user experience.
Proposal is to use 2 sticks movement to disarm. Land detector based disarm is also relevant.
PR was introduced in the past:
PX4:main
← PX4:stick-kill-gesture
opened 08:15AM - 26 Oct 21 UTC
**Describe problem solved by this pull request**
We received the requirement to… not disarm in Manual/Stabilized mode when not landed but keep an accessible way to be able to kill the vehicle. After a local solution my goal was to find something future proof and I came up with this suggestion.
**Describe your solution**
A rough solution:
- Kill if sticks are held "left stick lower left and right stick lower right" for 10 seconds
- Parameter to be able to disable disarming when not landed in manual thrust modes like Acro, Stabilized
**Describe possible alternatives**
I can confirm what Beat mentioned: We would not have this problem if the arm and disarm gesture would be using both sticks e.g. arm with left stick lower right, right stick lower left and disarming with left stick lower left and right stick lower right. I'm open to hearing more opinions on that as well but would definitely want to support this as a next step in the near future.
**Test data / coverage**
I bench tested this on top of the RC cleanup pr https://github.com/PX4/PX4-Autopilot/pull/17404
Flash issue on v5 target (main
branch)
Starting from lights: Add LP5562 RGBLED driver by julianoes · Pull Request #21649 · PX4/PX4-Autopilot · GitHub , the NuttX target actio n is showing overflow.
Run that failed: lights: Add LP5562 RGBLED driver · PX4/PX4-Autopilot@cd485b3 · GitHub
Mid throttle trim bug in QGC & transition logic PR
PX4:main
← PX4:maetugr/rc-throttle-trim-reverse-fix
opened 12:36PM - 05 Jun 23 UTC
### Solved Problem
When integrating an airframe I found that if the throttle ch… annel is reversed the logic that corrects for QGC calibrating the throttle to half the range (see https://github.com/PX4/PX4-Autopilot/pull/15949#issuecomment-1318728541)
### Solution
- Take care of the case where the channel is reversed because then QGC sets the trim parameter equal to the maximum channel value to achieve the same half range that was in use before #15949.
### Changelog Entry
For release notes:
```
Bugfix: Get full throttle range for QGC RC calibration with reverse throttle channel
```
### Alternatives
This can be removed again once the calibration in QGC is revised and available in a stable release for long enough.
### Test coverage
- I tested this on the real vehicle with SBUS and a reversed throttle.
- I also double-checked that the unreversed normal case still works as expected on the same setup by changing the parameters to a non-reversed throttle case.
mavlink:master
← junwoo091400:pr_remove_rc_throttle_trim_hotfix
opened 09:30AM - 19 Nov 22 UTC
## Descrption
A hotfix [commit](https://github.com/mavlink/qgroundcontrol/commi… t/0577af2e944a0f53919aeb1367d580f744004b2c) from 7 years ago was forcing RC transmitters to always have a trim value set to 'Min', effectively only allowing the [0, 1000] range.
~~While for legacy reasons & to bypass cases of spring-loaded transmitters, this may be ok, it is certainly not true regarding reversible thrust vehicles (e.g. Boat / Rovers), and it is confusing why only the throttle would be in the range [0, 1], and not [-1 ,1], as defined in the [`MANUAL_CONTROL`](https://mavlink.io/en/messages/common.html#MANUAL_CONTROL) MAVLink message definition.~~
## Changes
Removed this hotfix, and allows setting the trim values automatically in the state machine (need to check logic once again)
## Context
The discussion that discovered this flaw is here: https://github.com/PX4/PX4-Autopilot/pull/15949#issuecomment-1318728541
~~We need to also clearly define the point about the definition of `MANUAL_CONTROL`'s throttle (`z`) definition. As it doesn't really make sense to have throttle vector's orientation interfere with the RC transmitter's setpoint values (it should be agnostic to vehicle's behavior to be basic).~~
Also, PX4 will be able to handle this change using this logic (although some legacy parameter translations / user awarenesses would be needed): https://github.com/PX4/PX4-Autopilot/pull/15949
And we need to make sure for ArduPilot this will work out as well. Judging from [the way Steer / Throttle Manual override isn't differentiated](https://github.com/ArduPilot/ardupilot/blob/b2a38c0c6033a56bd4e7f7bffe65b70381d6ea76/Rover/GCS_Mavlink.cpp#L814-L815) in Rover code, I guess ArduPilot already uses full range (-1000 ~ +1000) definition for the internal RC throttle data, @peterbarker. Did you not have problem with QGC, regarding this point?
## TODOs
- [ ] I am still unclear how the rcTrim value would then get set for throttle, need to check the state machine logic to be sure.
EKF2 VIO
Fake EV & when you have a reset, why does the ‘hold’ mode not working as it should?
Notes on ROS2 & DDS user experience
IF you notice any issues from the users on this, please let us know!