Community, the PX4 Developer Team is working towards the next stable release (v1.12), we are hoping this release will come out soon, but we don’t yet have a solid timeline. We are trying to get as much testing as possible, and as always, we are really interested in your feedback.
The main focus areas for this release are:
Overall system stabilization
Performance
Enhancing our User Experience
If you have been paying attention to the last developer calls (#weekly-dev-call:px4-dev-call), you will notice that there have been quite many changes coming in, essentially refactors and architecture changes for the better. The team has felt that this work has been long overdue, and we are all very focused on making this release the most stable baseline we can.
We need all the help we can get with both bench and flight testing on the release, on as much hardware as possible.
Help with release notes
If you have a few minutes to spare, please help us contributing to the release notes. It’s super important we capture all of the new features and changes. Since this is such a big improvement release, we want to make sure everyone knows all the upcoming benefits.
Join the weekly calls
Make sure you join the public dev calls and follow the conversations on the dev-team channel on Slack. We are making our best effort to keep everyone informed on progress.
Bench testing
Take-off the props
Flash the beta (you can build from source, or use QGC)
Pick a nice location outside, make sure there’s enough space for you to fly (and social distance!)
Arm, and Takeoff
Try the features you would normally try. Maybe your workflow involves missions. Maybe you like flying in stabilized mode and just moving around. Try anything that you would normally do.
Make sure to write down any inconsistencies you might catch from past experiences
We are going through a transition period. We are not going to accept any new features until we make the final stable release of v1.12, after which we are moving to a much aggressive six weeks release cycle. Don’t worry; your PRs aren’t being ignored. We are just waiting for things to progress on the release, and we will start merging again soon afterward. It’s also important to note that we are thinking of adopting a new branching model that will allow for development not to stall, which we know can be frustrating.
I thought the Safety Switch was disabled by default? I still ended up with arming rejected because of a missing safety switch until I manually disabled it in the params. (This is on plane)
Apologies for re-asking, but I’m hoping to not waste too much time.
The kill switch will work under the following conditions:
IOP and FMU are alive - I have verified this is true
FMU is dead but IOP is still alive - I will verify is this claim unless someone tells me otherwise
I would like to avoid testing #2 if no one expects it to work, anyway.
Here is why I have to ask (exposing my ignorance/inability to follow the code):
It looks like the FMU polls (and pulls) “raw” rc status from the IOP and determines whether to issue kill back to the IOP (assuming thrust actuators are connected to MAIN). I cannot see how the thrust actuators will get killed if FMU does not issue the command(s).
Code tracing raw rc channels input on IOP to kill switch functionality on FMU.
I updated to the latest daily build, and now the QGC error looks like this (it also takes a long time to download all the params, about 2x what it used to be). Firmware is VTOL latest beta
Looks like 1.12 makes IMU_DGYRO_CUTOFF default value to 10, (was 0 in 1.11.3)
I spend 2 hours trying to understand why my quad becomes unflyable whe i switching from 1.11.3 to 1.12.beta. Is this a feature or a bug? My 450mm quad with pixhawk 4 FC can’t fly with default parameters. Here it oscillates and flips on takeoff
With IMU_DGYRO_CUTOFF=0 flies pretty well, with IMU_DGYRO_CUTOFF=30 and IMU_GYRO_CUTOFF=50 also looks good but not tested enough