PX4 Community Q&A: April 26, 2023

April 26, 2023

Join us


  • Community Announcement
  • Community Q&A
  • General Discussions

:loudspeaker: Community Announcement

A.1: Open call for PX4 v1.14 beta testing :tada:

Help us make v1.14 more awesome by testing the beta release, and be the early bird adopter of the newest features :yum: (announcement in discord server)

:people_holding_hands: Community Q&A (No deep technical discussions)

:exclamation: Guideline for asking a Question

  1. Specify what you are trying to achieve
  2. Specify what environment / platform you are using
  3. Prepare a Link or Document to help understand if possible
  4. First, ask the question on Discord or create a Github Issue!
  5. If you take over 5 minutes for the question, please continue in Discord or a Github Issue.

Q.1 : DroneCAN sane number of servos to support - Daniel

Currently using vehicle with 10 Motors, but when moving to CAN, bumping up the limit to 12 would be desirable.

Right now, 12 motors and 8 servo is supported with Control Allocation.
With DroneCAN, it is more limited.

Question: Should we move to 20? 12? 15?

Answer: Let’s identify real use case (e.g. vehicle) and base the maximum number of actuators off of that.

Action Item: Bring up to developers on any history / reason why the actuator number was set like that - maintainers

Q.2: Iridium PARAM_VALUE message fix PR - Ludovic

Answer: Will check it out. Overall MAVLink structure needs some review - Daniel

Also, it is weird that mavlink ‘receiver’ code is sending back a message (transmitting)!

Q.3: New airframe in Gazebo SITL issues - Arief

Original post:

Is original IRIS airframe SITL working? → Yes
Running Ubuntu WSL with GUI.

Probably SITL naming specifics (naming convention).

Action Item:
Create Issue and tag Daniel, as this is likely a bug.

Q.4: Migration notes for changing uORB message definitions - Farhang

uORB messages are changing between releases.

E.g. vehicle_status and failsafe flags, if they change, do we have migration notes?

We could do developer-focused migration notes for such details, or just treat these case by case basis.

Also, we could have some ‘hierarchy’ for messages to define better structure in the future.

Also, we could document better within the uORB message file definitions itself! Since they are document-ized automatically anyways: uORB Message Reference | PX4 User Guide

v1.13 → v1.14 major changes would be probably:

  • Commander
  • Flags in (failsafe) vehicle status

Note: Message definition associated with ROS2 going forward may prevent big changes.

Action Items:

  • Clarify units in the uORB messages (ROS, etc) (bring up to maintainers)

:thinking: General Discussions

D.1 : EKF2 Aid Mask depreciation PR - Mathieu

D.2: V5X overflow in main branch - Thomas

Would be nice to have a pointer for what can be broken down to reduce V5X flash usage.

Answer: LPE & Attitude estimator Q could be removed (they are only used for flash-constrained boards with 0.5MB Flash).

Note: If there are existing use cases for LPE / Atittude estimator Q, please let us know (forum, discord, github), so we don’t miss any use cases!

I would like to discuss this PR: Support 15 servos on DroneCAN by henrykotze · Pull Request #21502 · PX4/PX4-Autopilot · GitHub
especially what number of motors/servos it would make sense to support so we can get this done in a proper way.

1 Like

I’ve discussed an issue last week and I think I have a fix for it and would like to check with the community if that’s good enough.

Here’s my issue: Sporadic PARAM_VALUE message being sent through an Iridium interface · Issue #21496 · PX4/PX4-Autopilot · GitHub

The tldr is that there’s PARAM_VALUE messages being sent after a certain delay on a MAVLink instance on an interface. I want to avoid this on Iridium interface because that’s costing us money for data that we don’t really need, because we are running PX4 on a balloon at 20 km altitude.

I created a PR that add a simple condition around the send that check if the MAVLink instance is in Iridium mode and if it is it skip the sending. Here’s the link to the PR: Add condition for Iridium mode to not send params change after a timeout by lvanasse · Pull Request #21510 · PX4/PX4-Autopilot · GitHub

1 Like

I would like to discuss an issue when simulating with a new airframe in gazebo.

The full description of my issue can be found in this link. Discussion.

In summary, I have a SITL error return value of ‘32512’ when building the airframe.

1 Like