May 23, 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.
Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.
v1.14 Final rebase
Got rebased to
main branch at the end of last week. Now no major features will be accepted to the
11:04AM - 17 Mar 23 UTC
Fixed Wing 🛩️
## Describe the bug
While flying a VTOL mission in simulator with WPs with larg
… e altitude difference close together (to provoke loiter to altitude), I experienced that the drone after completing loiter to altitude (WP 4) selected the WP after the next (WP 6, but currently unsure if WP 5 was briefly selected in between) but continued straight east, but adjusting the altitude to that given in WP 5.
## To Reproduce
I have not been able to reproduce yet, but the steps I did when got the error is given below.
Steps to reproduce the behavior:
1. Started simulator `make px4_sitl gazebo_standard_vtol`
2. Uploaded mission [bumpy.zip](https://github.com/PX4/PX4-Autopilot/files/11000338/bumpy.zip)
3. Started mission
4. Error after WP 4, as described/shown in screenshot
## Expected behavior
The drone should have gone to WP 5 and loitered to corrected altitude after WP 4.
## Log Files and Screenshots
![Screenshot from 2023-03-17 10-45-15](https://user-images.githubusercontent.com/108630475/225876863-56d02970-d1de-45a1-9e77-66e21fdbd104.png)
## Drone (please complete the following information):
- Simulator, gazebo_standard_vtol
## Additional context
Used latest main branch version:
Build/run in px4io/px4-dev-simulation-focal docker image.
After the screenshot was taken, I selected WP 6 and continued mission from there. No unexpected behavior after this.
04:32PM - 10 May 23 UTC
Thank you for your contribution!
Get early feedback through
… ode Discord: https://discord.gg/dronecode
- PX4 Discuss: http://discuss.px4.io/
- opening a draft pr and sharing the link
### Solved Problem
RC calibration with the inverted throttle leads to wrong values being sent and eventually prevents arming of the vehicle.
12:49PM - 26 Apr 23 UTC
### Solved Problem
PWM configuration parameters for ESCs have ambiguous meaning
… s depending on the use case and have to manually be adjusted according to the context that the allocator already has.
- Default to PWM 1000us for disarmed (servos still have 1500us)
PWM 900us is out of spec of any ESC I know and they all stop the motor with 1000us
- Default to a range of PWM 1100us - 1900us for motors
This is the most compatible range I can think of with any ESC I worked with. Some have a lower limit of 1050us or 1075us but all turn the motor with 1100us. Some stop the range at 1925us or 1940us but all of them have the range not yet ended with 1900us. The idea is that the conservative defaults work reliably out of the box. If a user carefully follows the steps and e.g. experimentally finds out the exact PWM limits for all ESCs in use they can still configure that. From looking at logs I see that most users don't do that.
- Fixed wings deliberately turn off the forward motors if they are commanded to produce zero thrust.
- StandardVTOL do the same as fixed wings when not hovering
- Tailsitter can now stop motor in fast forward flight, bench and simulation tested
- [x] Tiltrotor simulation test
- Rover ackermann & differential simulation tested only
- [x] Boat simulation test
- [x] Submarine simulation test
### Changelog Entry
For release notes:
Attention: Default disarmed PWM was changed from 900us to 1000us!
Improvement: Default motor PWM limits minimum 1100 maximum 1900
Documentation: Need to clarify in https://docs.px4.io/main/en/config/actuators.html#multicopter-pwm-motor-assignment
I also thought about keeping the ambiguity of PWM configuration and adding some magic again to change it automatically but just for multicopters in one way and for fixed wings the other way. But I think that's not the right solution because it will cause more confusion and corner cases and explicit configuration and use.
### Test coverage
- I tested this on a quadcopter with PWM ESCs both configured as multirotor, fixed-wing and StandardVTOL with 1 or more pushers. It behaves as I expect in these cases.
- ~What's still missing are the VTOL cases. I think I can figure out standard VTOL but might need some help with Tiltrotor, let's see.~ **EDIT:** See above what I covered.
1.14 release has only the new actuator configuration now and I want to make sure we get these PWM problems out of the way from the beginning since many people will switch and reconfigure the actuators once.
Ok with this minimal fix for now
If ESC calibration is active, only actuator test? signal will go through to actuators
Needs testing on FMU and IO, since they are slightly different.
In Actuator Test code, we need to make sure we have correct PWM values for calibration signal pulses
Duplicate RTCM issue
Optical Flow Issue
12:40AM - 14 Jan 23 UTC
release blocker ❗️
In current main, with optical flow fusion enabled, I am unable to arm in altitud
… e or position mode. If I take off in manual I am able to switch to altitude and position no problem.
On a larger quad with long landing gear, this issue doesn't present itself. It appears to be a problem with the optical flow close to the ground.
Currently trying to test with a user with HereFLOW
UAVCAN Button Issue
Potentially specification problem
Our safety button message has no time ‘held’ amount data
Prob not important for holding back 1.14
Multi EKF sensor priority
There’s priority in sensor hub level, and will prioritize to use external over internal currently
MacOS CI failure
MacOS CI is not working now for a while
They are stalling, because the runner is not being given by Github
For now we can skip MacOS CI for PR checks for now
To get better runner access, the organization needs to be ORG (PX4), and payment is proportional to number of people in the org.
Custom runner option: Prob not necessary for now?
About self-hosted runners - GitHub Docs
DSDL is updated now, how do we update
Question: Who has the Dronecan hardware for the affected case anyways?
Some details need to be reviewed & finalized
Needs to be better tamper-proof in the definition
Fully locking the params part etc is up for discussion
Action Item: Need to get hold of mRO/Cubepilot hardware, make documentation for it. Ramon will purchase both of them
Stale bot bringup
Let’s do it, will reduce noise in the repo
Action Item: Bring back stale bot
Any topics to discuss?