PX4 Dev Call: July 22, 2020

July 22, 2020


  • Component update
  • Release
  • Community Q&A
  • Any in-depth talks

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

@rroche All the stats and content from the PX4 Developer Summit is live on the Dronecode blog (ALL LIVE VIDEOS ARE UP!!)

Component update

System Architecture

PX4IO discussion about removing the mixer logic out of the IO firmware, doing mixing on the FMU side and having the IO forward the results to the additional pins. The mixer logic alone is 20KB of flash saving on IO AND FMU side. That would also solve a lot of problems where we can only load mixers to the IO on boot. It’s a blocker to move forward with control allocation and also multi EKF.

IO relies on the “old style” mode switch where each mode has it’s dedicated switch. Since we are assuming these are not broadly used we are targeting to remove the “old style” and just use the new mode slot style that most people are familiar with and using.

Downside: Pure manual control fixed-wing failover is not possible anymore. Failsafe and disarmed values are preserved.

Jacob Crabill: Do we have plans to parameterize which output e.g. the rudder or one motor is attached to? Yes, we don’t have the concrete solution yet but the goal is to move these configuration options to the parameter system.

Sounds like we’re all on the same side. So we need to make it happen piece-wise.

OS / NuttX

  • There were backports for CAN operations in NuttX.
  • For the PX4IO that is in the new orange cubes Mirco found out that the IMU heater was connected in a different way.
  • QRT is slowly coming back for the ModalIA board with a Snapdragon. It’s currently being resurrected by Jacob. We had support on master at some point but it broke because of the lack of maintainers for that particular system.


No updates


No updates


  • @Paul_Riseborough is continuing work on getting the existing MATLAB EKF derivations into Python derivations that are much faster and easier reproducable. This work was started by @tumbili and is now getting extended with the latest estimator changes, fully integrated and tested.

    @dagar Request to have separate files for generated code and manually written code to be able to automate things.

  • Updated magnetic lookup table was finished and brought in:

VTOL / Fixed-Wing


Refactoring thrust mapping moved to function, unit tests for all the mathematical functions in the file.

Land detector:

  • Interaction bug with NAN velocity setpoint and ground contact

  • More strict ground contact condition

The change makes it more conservative in terms of safety but there could be a user experience impact if vehicles take longer to land. Let’s do a final pass on it (@MaEtUgR) and then merge it. We then should pay close attention on the logs and feedback.


@JulianOes mentioned he found the threading issue with the rare seg faults in MAVSDK SITL tests and it will be solved with the next MAVSDK release.


UART link broken:


No update


Air ship simulation thanks to Dan-Leo.


@dagar is getting back into UAVCANv1 proof of concept

UAVCAN development team will be more active on the drone specific message definitions DS015 standard effort. The output can be seen in the document. Any early adopters that want to take part of this should join the call. The plan is to get UAVCANv1 on PX4 stable and lock down the message definition.

Hardware call

There was no hardware call this week because it’s alternating with the UAVCAN call.


The land detector is the blocker for the 1.11 release. We’ll get another release candidate for final testing and then we’ll do the release.

After 1.11 we’ll going to do the release schedule much differently like mentioned at the dev summit and last week’s dev call.

Test everything you care about to make sure there are no surprises!

Community Q&A

  • @JingerZ
    Holybro Pix32v5. This should be merged. A final pass and then it should be ready. We (@dagar & @david_s5) don’t have hardware (just got commented in the pr).
  • Kyle Smith: Branch from @dagar for Invensense driver changes that didn’t get merged yet. Are they supported now? The sensors are all supported on master, the branch just contains a collection of small improvements that are not merged yet. If you want to use any of the sensors go ahead, there’s no blocker.

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.

1 Like