January 27, 2021
- Status update by component/project
- Roadmap, and Release discussion
- Community Q&A
- In-Depth discussions
Roadmap Project Board
High-Priority Queue Project Board
Eohan: UAVCAN v1 BMS messages ready? When should a manufacturer adopt? How to get involved?
At the moment it’s usable/ok but you should not expect long-term full compatibility to the current state. If you’d like to develop on CAN and contribute it’s perfect to jump in. Focus at the moment is not on v1.
UAVCAN v0 is stable and in a good shape. Use the PX4 UAVCAN node implementation to ensure you’ll have backwards compatibility and bootloader flashing implementation that will allow you to upgrade to v1 with the open-source implementation for that.
UAVCAN v1 is in the current state only recommendable for people that control all nodes on the network and need a truly modern flexible system and are ok with a still changing message interface.
Matthias: RC override was usually triggered by detecting the change in RC signal and we switched it to detecting based on sticks being off-center. This was done because the state of the detection was spread over the entire commander and we had really bad corner cases that were close to impossible to foresee.
This has two issues:
- Very bad user experience with non-spring loaded throttle
- If the RC signal for some reason goes stale there is no way to recover the vehicle
The suggestion to go back to detecting a signal change but solving the initial corner cases with an improved implementation raised the following feedback:
- It needs to be local scope such that behavior is deterministic
- It should not trigger in single sample glitches but recognize an actual stick movement
Mark Sauder: There’s a lot of stale branches. Every branch author should go through and clean up his remaining requests. It helps a lot to be able to follow up and get things merged. A smaller pull request count makes things better everyone because maintainers will see the important parts and be able to process quickly
Pieter-Jan: What’s the timeline for the next release?
The release 1.12 is planned just around the corner without a fixed date. We need to go through all the supported boards and make sure they don’t see any regressions. Then we can branch off. Pieter appreciates all the great work that went into PX4 and would like to see the wider community to get access through the release. He’s personally interested in Multi-EKF support.
The main concern is finding hardware support has a regression once the user holds it in his hands through the release. Lorenz is suggesting to encourage community testers by organizing sponsored always up to date hardware for regular testing. e.g. top three flight hours award, PX4 tester T-shirt. For the provided hardware the reference kit would certainly help. Possible hardware setup: Mid size 250-500mm frame, fmu-v6, CAN GPS, optional raspberry pi and realsense camera that fit on the base frame.
It would be nice if we can organize manufacturers to sign off testing the new release on the hardware they sell. Engagement with the manufacturers works better than ever before but we need to follow-up and also be there when they have good test reports to encourage that communication.
MAVROS / DDS / ROS2
@TSC21 Has a documentation update and an almost ready protocol splitter:
Pure renaming of the plugin because a lot of people got confused with the previous name
There were a lot of coefficients missing and Pieter contributed them
Errata and Feedback
Let me know below if we failed to capture anything the right way, and if there are any updates (not present here), or you have feedback you would like to share with the dev-team.