April 15, 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
Flight Testing
Need testing:
System Architecture
@daniel Is working on support for multiple EKF instances and what is needed to enable it e.g. running multiple instances of a module and how uORB multiple instances are handeled.
OS / NuttX
Driver
Currently looking into further improving faulty sensors detection on the driver level. For the release all major things are ready on the driver level except for when the EKF2 changes the integration rate (#14676) the IMU update rate needs to be adjusted to align timing.
Commander
Adjustments to have preflight checks for dedicated RC switches like return switch and to have a home position when requiring global position because users expect to be able to RTL with GPS:
Waiting for review/testing:
Estimation
VTOL
No updates
Fixed Wing
No updates
Multicopter
No updates
MAVSDK
- @JulianOes Ongoing work with auto-generated language plugins. Mission was finished over easter.
- @dagar We should start using MAVSDK to do automated HITL testing. Being able to connect easily over serial and what we could immediately test with existing MAVSDK functionality. Maybe needs MAVLink routing because HITL and MAVSDK would use the serial link.
MAVROS / RTPS / ROS2
No updates
Avoidance
No updates
Simulation
- Differential Rover support: https://github.com/PX4/sitl_gazebo/pull/394
Waiting for answer on 3D mesh license from manufacturer.
@bys_1123 asked what’s missing:
There was no time to follow up. We should be able to have it for the release but it will not run avoidance as of this pr.
Roadmap, and Release discussion
Community Q&A
gerjen: From research lab, posted question on slack. They are developing an algorithm to do sensors e.g. magnetometer calibration without moving the vehicle. Wondering about how to coordinate. Suggestion to implement the calibration algorithm in a standalone library that does not use the structure of the current sensor calibration structure but consumes sensor data and outputs calibration parameters. Then ping on slack to get coordination such that people can start using it as an alternative to what’s existing and when we have enough data to show its stability we can make it the new default.
@JingerZ Holybro is getting ready to launch a new autopilot. It’s fmu-v5 architecture in a cube like form factor. Different cube connector than the pixhawk standard and they see it as manufacturer supported board. They’re asking about if we can add a board ID to the bootloader.
It would be very helpful to have a list of differences to fmu-v5 to see if it’s necessary to have it separate. If they just want a separate bootloader ID, that can be done easily. Is that everything they need?
Kai Gottschalk: Generalization of MAVSDK connections. Summary: Was developed mostly to have on the ground station side and connected to a drone. Now connecting from a companion computer to the autopilot it’s the same system. So the idea is to have nodes instead of a drone system and he’s asking for comments on the proposal. @JulianOes agrees with the proposal and identified problems and the question is how to proceed. Anyone interested should chime in on #mavsdk in slack and it will be followed up offline.
In-Depth discussions
- Can/should we rename PX4 component repositories like
Firmware,Bootloader,Avoidance, … with the prefixPX4-e.g.PX4-Firmware? This would clarify the content of the repository when it’s outside the GitHub organization like the folder for the local clone.
We want to get it right with only one rename change and hence have a document to collect feedback and will change it as soon as it’s clear what’s the most useful naming scheme:
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.