PX4 Dev Call: April 15, 2020

April 15, 2020


  • 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


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.


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:



No updates

Fixed Wing

No updates


No updates


  • @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.


No updates


No updates


@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 prefix PX4- 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.

I’m making a PX4 beginning basics video tutorial for new developers based on PX4 1.11. I hope I could use more new tools instead of legacy stuffs in this tutorial.

So, like PX4+AirSim simulation, on PX4 side it’s stable on its part, I‘ll wait AirSim to support it. Then release the video out, new users will use new toolchains follow the video, to avoid legacy caused problems. Everything can move forward.

On PX4+Gazebo part, this version is much stable and more powerful than 1.9 and 1.10. This could makes more new developers’ ideas become true. Which is fascinating.
And PX4 Vision Drone has a very nice design, also a current available product, so I want to use this drone model in Gazebo simulations instead of Iris. Iris is classic, but a little bit old fasion.
Its model already added to px4_sitl repo, but cannot build it out of box. Which makes learning curve not very nice.
I hope this PR could include in 1.11 stable release: https://github.com/PX4/Firmware/pull/14469
Then everything looks frush in my video, introduce more developers to px4 community and I could move editing cmake files and models to later chapers.

Thanks for PX4 team’s works and support. Especially thanks for Jaeyoung Lim’s and Nuno’s works on this part.