PX4 Dev Call: July 29, 2020

July 29, 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

Hardware Workgroups

Payload / FMU / BMS

Last call FMUv6 was discussed. The design is close to be released. Some documents are still being checked. Standard will be announced. Gumstix will make a prototype board.

System Architecture

Logger changes about the default logger profile. Potentially remove the replay logging from default profile to make sure we can use cheap SD cards for longer.

Make sure gaps in logging are recorded and get noticed.

Better handling of buffer overflow.

OS / NuttX

@david_s5 was looking into a problem with telemetry related to Nuttx.

NuttX release is out, we can go back to working on upgrading.

@dagar F412 backport or wait for the update? Depends on the effort also on testing.


Contribution of fixes in optical flow driver

DSM RC parsing more robust

Crazyflie was not booting in master. @dagar fixed it and looked into using the new MPU driver to support the Crazyflie 2.

Hex was renamed to CubePilot and the autopilot are called CubeYellow, CubeOrange… We renamed them.

@JingerZ The board Yellow and Orange are not listed as supported currently. They should be listed as experimental/community supported. There will be a follow up discussion with @dagar


No updates


  • Progress on Python EKF derivation:
  • Master of Firmware is out of date with ecl. New geo table doesn’t fit FMUv2. We might want to compensate the flash size increase with the auto code generation (Python derivation) savings.

What path should we go update everything at the same time or small pieces and save flash with other means in between.

  • Goal: Have a validity flag. Additionally @dagar found a bug with the delta-time.


VTOL attitude controller runs with 1200Hz when there’s no attitude setpoint published:

Fixed Wing


Progress on land detection, thanks to @dagar :

Testflights needed after check of @MaEtUgR comments. No major change anticipated.


No updates


@JulianOes CI: we changed gazebo to be able to load different models. There was a race condition where gzserver was not yet present when trying to load the model and then there was no model and the tests failed.

Script to run multiple simulation instances


New release today: 0.29.0 :tada:

  • Main difference how user callbacks get called. Before there was a thread pool for the callbacks that caused potential threading issues. Now the callbacks are called from one thread and you have to do short callbacks and/or start new threads yourself if you call other blocking code.

  • There’s a new feature and tutorial to be able to use a joystick.

  • MAVSDK on ARM improvements

  • Failure injection.

  • Bug fixes, see notes


Testing of the serial link with ROS2 using a Pixhawk 4 and seeing good throughput with parallel topics.

What happened with Serial TX DMA in NuttX? There are issues like the GPS ones we had before. That’s what @david_s5 meant we need to look into it before updating NuttX.


PX4 UAVCANv1 work ongoing, no particular updates at the moment.


For the 1.11 release we have the land detector issue that is pending. It’s now reviewed and needs final testing.

We should revive the tester GitHub group and add community volunteers such that they easily get notified when tests are needed.

Community Q&A

@JingerZ has a pr from CUAV https://github.com/PX4/Firmware/pull/15314
@dagar Does anyone have the hardware? He is looking into it and answering.

@nrogelio found an issue: https://github.com/PX4/Firmware/issues/15312
He has an external compass issue that seems to be starting with the commit hash he posted. But it’s strange because the commit doesn’t change the magnetometer parts of PX4. It sounds like the mag orientation is wrong but it has to be debugged. Maybe other GPS modules with the same mag have different orientation. The mag auto rotation (https://github.com/PX4/Firmware/pull/15120) would catch the problem if it’s that.

In-Depth discussions

  • Parameter meta data compressed on-board

Would be good to have @hamishwillee and/or @bkueng in the call for further discussion.
@dagar motivates to think about trying to not miss out on any opportunities to rule exclude e.g. value ranges. Check MAVLink FTP performance, it’s probably not performing as well as it could/should.

QGC uses a different protocol than MAVLink FTP to download logs. We need a mechanism to slow everything else down while transmitting the file and then switch back to normal operation.

  • UAVCAN rangefinder support

@dagar everything seemed fine except for they add their own custom DSDL which we should not carry that in PX4. We should forward the information into parameters.

  • @JingerZ FMUv5x Holybro is making a new prototype. Does @dagar and @david_s5 want one?
    @david_s5 has the old prototype and we need to communicate the required changes for the updated specs clearly.

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

Generate param metadata as MAVLink-compatible JSON component info

  1. The protocol is designed to fetch data from the vehicle that is invariant after boot - parameter metadata, version info, supported mission items etc.
  2. It could also be used to get all actual parameters on boot (instead of existing param protocol) and then monitor for changes on individual params. This would be more efficient than what we do now.
  3. It is tempting to say well why don’t we allow requesting this dynamically at any time, and further that we then take a particular split that we’re interested in. This is do-able but I’d prefer we looked at a new API for that.

@DonLakeFlyer might take a different view.

For MAVFTP efficiency, @bkueng and @JulianOes more likely to add value than me.

I don’t understand what that means.


I don’t understand what that means.

We are currently thinking about requesting the values of all parameters after boot using the component_info approach. This might be more efficient than getting them using the normal PARAM_REQUEST_LIST approach. This is in line with the protocol.

You may recall Tridge talking about a maybe having a new param protocol where params could be more efficiently packed and requested in big chunks. I think the suggestion is that we allow something similar in the COMPONENT_INFO message - ie you be able to request smaller chunks than “all params”. What I am saying is that I do not think this aligns with our thinking around the protocol.

Nor do I think it necessary because once you have uploaded most params in a file, keeping track of individual changes is easy enough and you no longer have the big inefficiency of the current protocol.

Ardupilot probably agree - since they now have a model where they upload params in a file on boot just as we are planning.

What we could do is provide a mechanism to request that the information be dynamically regenerated. That makes sense for parameters and would not be outside of our current thinking.

I get all that part and agree. I specifically don’t get this: “It is tempting to say well why don’t we allow requesting this dynamically at any time, and further that we then take a particular split that we’re interested in. This is do-able but I’d prefer we looked at a new API for that.”