April 26, 2023
Join us
Agenda
- Community Announcement
- Community Q&A
- General Discussions
Community Announcement
A.1: Open call for PX4 v1.14 beta testing 
Help us make v1.14 more awesome by testing the beta release, and be the early bird adopter of the newest features 
(announcement in discord server)
Community Q&A (No deep technical discussions)
Guideline for asking a Question
- Specify what you are trying to achieve
- Specify what environment / platform you are using
- Prepare a Link or Document to help understand if possible
- First, ask the question on Discord or create a Github Issue!
- 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.
Answer:
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?
Answer:
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 (main)
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)
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!