May 20, 2020
Agenda
- Status update by component/project
- Roadmap, and Release discussion
- Community Q&A
- In-Depth discussions
Join Meeting
Meeting ID: 946 175 205
Join using your mobile/desktop
Call in using your phone, find your local number: https://zoom.us/u/aetSYKbiMF
Component update
System Architecture
In progress to move IMU in sensor_combined to a separate synchronized place:
OS / NuttX
@david_s5 working on bringing up FMU v6x on the current version of NuttX. He needs some pieces of NuttX upstream for the H7 architecture. We didn’t build against upstream for months.The effects on code size is a big concern. The extra layer of wrappers on semaphores will for example make a difference.
On IO we need to get rid of the mixers because they don’t fit in the resources. We’ll do that after v1.11 release.
@Jacob_Crabill: Orange cube UAVCAN FDCAN driver copied from ArduPilot to PX4 and got UAVCAN working on that H7. License questions need to be taken care of. Need to redo using ST’s free and open HAL. It’s now in a separate repo as a hacked together proof of concept.
The goal should be to have the NuttX CAN driver work for UAVCAN 1.0.
Driver
@dagar Minor improvements to the Bosch and NXP IMUs to make sure samples are synchronized and there’s no extra useless transactions.
@Jacob_Crabill is looking to supporting some new Invensense sensor ICM20602. @dagar gave some background. (ICM2948 driver evolved from MPU9250.)
@david_s5 found a problem with debugging drivers where some cases failed silently. We should make fail silently be an opt-in option. We’ll get an issue going for that.
@Roman flew with a setup that has multiple baros and asks if we shouldn’t have an easy way to specify which of the multiple available baros should be in use. Right now it depends on the driver startup sequence. @dagar planned to have a solution where priorities for multiple sensors can be configured via parameters on top of the unique sensor ID, calibration and it gets then prioritized through uORB instances. Aligning on the idea is the important part. There will be follow up discussions.
Commander
No updates.
Estimation
Initialize position validity to false. This was a bug that let you do position control takeoff in the first 5 seconds after boot and then after that fusion timeout expired realize you don’t have the necessary measurements and failsafe. This got fixed.
Avoid learning accelerometer biases in temporarily unobservable axes. E.g. when the vehicle is sitting on the ground it will still learn z-axis bias but not update the hardly observable x,y axes and lead to accel bias preflight checks failing. Once in air and moving it learns exactly like before.
VTOL
No updates
Fixed Wing
No updates
Multicopter
Replace RC filter.
Ready and tested. Not perfect but better.
Path forward? Before, after release? Concerns?
MAVSDK
No updates
MAVROS / RTPS / ROS2
No updates
Avoidance
@hamishwillee updated the documentation. We now support Ubuntu 18.04 instead of 16.04 by default.
Simulation
Awsome contribution from @JulianOes: We now support Gazebo 11
H480 simulated gimbal was looking backwards but was working like expected. There were probably multiple issues that allowed it to fly at all because the rotations were wrong.
UAVCAN
@dagar As a replacement for the legacy 0.9 UAVCAN node in PX4 there’s a new UAVCAN v1.0 node being worked on that can bridge uORB data via UAVCAN to communicate any information like IMU, battery, GPS data. It’s still work in progress how to configure all routing on what CAN message goes to what uORB topic.
Discussion with @TSC21 about how to set up the namespaces.
Discussion with @david_s5 about SocketCAN and compatibility with upstream NuttX. SocketCAN needs to go into NuttX upstream and we should carry on with our updates accepting it might be unavailable in between.
UAVCAN v1 is currently in an experimental state on different branches and no nice UI. It’s coming together but we should keep a document tracking the state and pieces to make sure not duplicating work.
@Jacob_Crabill talking about some possibilities how to support v0.9 and v1 and potentially both at the same time with a conversion. We need a nice clean drivers implementation for v1 in place and then we can migrate existing v0.9 functionality to that new architecture. @dagar we need to have a leaner setup which is not as expensive to run.
We should discuss further with the people interested because there are clearly a lot of common goals. There’s a biweekly UAVCAN for drones call on Tuesdays, next one May 26. Find it on the Dronecode calendar: https://www.dronecode.org/calendar/
Roadmap, and Release discussion
We should cut a release candidate for 1.11!
Please report feedback.
@MaEtUgR wants to investigate https://github.com/PX4/Firmware/issues/14945
@dagar is interested if the new estimator improvements for accel bias learning listed above would result in better user experience because of less false positive preflight checks and should be included in the release after testing.
Community Q&A
Mark West: Proposed a dev summit session for “getting started guidance” and got some traction and volunteers. The proposal will only be accepted/declined beginning of June and he asks to know earlier because he would already organize with volunteers and collaborator early and not have it declined at a later stage.
There is a content committee that will decide on the sessions. Generally, the proposal is strong and a getting started session by the community can also be hosted on the PX4 Youtube channel anyways.
@rroche is available for all sorts of related questions e.g. pointers on what is desired for such a session.
In-Depth discussions
Errata and Feedback
Let me know below if I failed to capture anything the right way, and if there are any updates, or you have feedback on the call format.