PX4 Dev Call: November 18, 2020

November 18, 2020

Agenda

  • Status update by component/project
  • Roadmap, and Release discussion
  • Community Q&A
  • In-Depth discussions

Join Meeting


Component update

System Architecture

Remove ring buffer for MAVLink text messages and use the uORB queueing instead. Saving flash and RAM and was found when looking at calibration status messages.

It would be even better if we’d switch to structured messages instead of strings to communicate with the ground station about the calibration status.

Sending out the local position origin reference in GPS coordinates via MAVLink upon request.

If requested and not available nothing gets sent out. It would be useful to answer the request command with a temporarily not available.

OS / NuttX

@david_s5 Refactoring MTD drivers (memory to store e.g. parameters). If you have a failure with the driver start the startup script uses the SD card instead and next time the failure is gone it will use the MTD again. This should be fixed now since starting the MTD driver is handled based on the board.

Tracking NuttX for critical bugfixes. Release 10.0.0 rc3 has a lot of backports and is currently taking longer to test than expected.

Driver

No updates

Commander

Only print one accelerometer not being calibrated since the action is the same for multiple.

Remove unnecessary # characters for the calibration issue messages since they lead to issues on the ground station.

Estimation

Faster initialization and support for minimally equiped flight control boards.

@bresch How much testing was done on Multi EKF?
It was test flown already multiple times so we expect it to not be high risk. It would be nice to get more real-world logs to analyze if it works like expected.

We have a lot of SITL testing BUT they cannot be considered representative because SITL uses the same sensor for all instances. Also we need to test sensors with different measurement update rates.

@Jaeyoung-Lim is looking into supporting multiple sensors in gazebo. It would be nice to have different rate sensors but it might be hard depending on the available resources in the system. CI already runs into some resource issues. We could solve it with specific tests that run slower than real time and test the failure cases.

VTOL

No update

Fixed Wing

Climb out mode was settled

Multicopter

Another occurrence of this issue on an older version lead to understanding the reason for this fix

Avoidance

No updates

Simulation

MacOS CI is up and running again. ORSF ogre was broken and got fixed and we took it over.

MAVSDK

Small things that will be mentioned with the next release.

When you use any other language than C++ with MAVSDK then you need to run the MAVSDK server (C++ part). There were some issues with building and running that server on certain platforms because of dependency versioning. There was no common dependency list that would build on all linuxes and support C++17. The solution was using a custom static library.

MAVROS / DDS / ROS2

No updates

UAVCAN

No updates

Hardware Workgroups

BMS (smart battery) workgroup open to the community with public meetings.
Yesterday there was a call


Release

New point release PX4 1.11.2 with accumulated bug fixes is out!

Community Q&A

  • Igor Campos: Discussion coming from MAVLink about doing surveys with a tilted camera to have more field of view. This was discussed before on the dev call. Asking for a review of the MAVLink message and PX4 implementation such that it gets merged.

CI build is currently failing because the MAVLink version is not yet up to date.

MAVLink is introducing more strict checks on having an implementation that actually uses a message spec before it gets merged. PX4 is the accepting implementing entity in that case.

Discussion about RC glitches, logging RC switches on every change instead of regularly and possibly having a hysteresis on mode changes.

  • EG: Battery Monitor BatCha https://hackaday.io/project/175612-batcha
    How should the communication protocol work? DS-015 UAVCAN BMS specs or SMBUS are options. How to communicate to a computer? USB, Ethernet / UAVCAN, MAVLink?

In-Depth discussions


Errata and Feedback

Let me know below if we failed to capture anything the right way, and if there are any updates (not present here), or you have feedback you would like to share with the dev-team.

1 Like

I would appreciate if we had the time to discuss:

for reference, it depends on the following Mavlink PR:

1 Like

We recently had an issue with an unexpected mode switch and from raising this issue to the community it seems we are not alone despite being something quite rare. If there’s time I would like to discuss this quickly just to bring awareness.

1 Like

This is the link to the smart battery charger we discussed about: rotoye.com/batcha

Features

  • 2-12S LiPo Charge
  • Two ports. Charge two battery simultaneously. Optional expansion puck to charge 4x smart batteries per port
  • 500 watt total power. Shareable to either ports
  • Max charging current per port: 20A
  • Smart battery data interfaces:
    • I2C: Two wire based protocol such as SMBUS
    • CAN BUS: Two wire differential pair robust protocol for UAVCAN
    • LIN BUS : Single wire communication protocol for micro drones and connectors with single
  • USB interface for monitoring and controlling charge workflow from PC
  • Optional: Integrated Raspberry Pi Compute module for Wi-Fi and Ethernet connectivity
  • User interface engineered for speed and safety. Plug-in to charge-start in less than 4 seconds
  • Design optimized for robustness and repairability
1 Like