Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Meeting ID : 946 175 205Join using your mobile/desktop
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Call in using your phone, find your local number : Zoom International Dial-in Numbers - Zoom
Updated schedule starting in November 2020
Nov. 2 - FMU WG
Nov. 10 - UAVCAN WG
Nov. 17 - BMS WG
Nov. 24 - Payload WG
Check-out the full calendar of events on the calendar below
No update this week.
Getting ready to bring in NuttX 10.0 upgrade with RAM savings from 3k to 4k depending on your board because of dynamic file tables
PX4:master ← PX4:pr-nuttx-next
opened 01:18PM - 15 Oct 20 UTC
Replaces https://github.com/PX4/Firmware/pull/15905
This will track nuttx mas… ter, hence the name NuttX Next
Rewrite for Bosch BMM150 There were problems and a rewrite seemed necessary because of some questionable parts.
PX4:master ← PX4:pr-bmm150_rewrite
opened 11:01PM - 25 Oct 20 UTC
- same pattern as other new drivers (state machine, checked register mechanism, … no sleeps, etc)
- self test has been rolled into regular startup sequence
- still I2C only, but will be expanded soon
- configure to high accuracy preset
<img width="898" alt="Screen Shot 2020-10-25 at 7 28 38 PM" src="https://user-images.githubusercontent.com/84712/97121938-59400380-16f8-11eb-8c3b-733475a15312.png">
@dagar General idea to get e.g. Bosch drivers that are designed for SPI also working generically over I2C e.g. for new Crazyflies. Only hacks for testing but no draft yet.
No updates
Muli-EKF support is finally merged and enabled by default in simulation. It needs a lot of testing e.g. failing all different sensor combinations and real world testing. There are different levels of how many EKFs you can run depending on the microcontroller resources. E.g. the goal on H7 boards to run all possible IMU combinations. On M4 memory is tight for multiple combinations.
PX4:master ← PX4:pr-ekf2_selector
opened 01:56AM - 13 Apr 20 UTC
**WORK IN PROGRESS**
Multi-EKF will be a focus of the v1.12 release cycle. I’m … opening this early so we can begin to identify and address the architectural changes that will need to be in place to make this viable.
### Multi-EKF Background/Motivation
WIP
Currently in PX4 most commonly supported boards have 2 or 3 IMUs that are typically different models, sometimes with wildly different output data rates, and often on the same bus, or with no synchronization mechanism. As a result our sensor hub module isn't able to effectively compare raw sensor data and "vote", so it simply selects a highest priority sensor based on a simple set of fault metrics (timeouts, stale data, etc) and passes that on to the estimator. This allows the system to continue operating if a sensor is completely lost (a hard fault), but this is actually quite rare in operation. In reality most problems encountered in typical usage are soft faults that impact navigation like high vibration (aliasing, clipping) or erratic sensor problems that still produce output.
To effectively utilize the current suite of heterogeneous IMUs to mitigate the most common real world pain points I'm proposing moving to an architecture of running (at least) one estimator per IMU.
- in multi-mode each ekf2 instance publishes
- `estimator_attitude` (vehicle_attitude)
- `estimator_local_position` (vehicle_local_position)
- `estimator_global_position` (vehicle_global_position)
- a new `ekf2_selector` module consumes all estimator_* messages, selects a primary (latching), and republishes vehicle_attitude, vehicle_local_position, vehicle_global_position
- `ekf2_selector` handles resets and deltas when switching between estimator instances
- At the moment a switch will only occur if there's a fault while another estimator instance with a better combined test ratio (vel + pos + hgt) is fault free. Opportunity to identify (and store) the best sensor combination
- sensors hub is now configurable to either provide the single highest priority IMU or publish all
- new parameter `SENS_IMU_MODE` to configure IMU output
- 0: publish all vehicle_imu instances
- 1: publish only highest priority as primary
- On F7 we can start with one estimator instance per IMU. On F4 continue as is, user configurable if desired (lots of room for optimization on F4).
### TODO:
- proper multi-module support (https://github.com/PX4/Firmware/pull/12191)
- sensor_combined kill? (migrate to vehicle_imu)
- ekf2 replay review (logging all raw data for all instances probably not a good default)
- ecl analysis script updated to be aware of multiple instances
- factor in initial sensor priorities (or kill this entire concept?)
- the initial primary/preferred IMU should probably be configurable
- preflight estimator_status (commander logic updated to only care about primary or should it check all?)
- different origins?
- each estimator instance will have a slightly different origin (or worse), does it matter or can we get away with it if resets between instances are carefully handled everywhere?
- SITL add multiple sensor instances
- sensor metadata should belong to each sensor instance, not `EKF2_*` parameters
- offsets, rotations, possibly even noise
- uORB multi-instance assumptions, we can't be sure all ekf2 publications are the same instance number. Maybe time to rethink uORB with namespaces? `estimator_status0 -> estimator/0/status`
- lockstep implications (ekf2_timestamps)
- Do we potentially need/want a separate level calibration per IMU?
- per instance parameters (EKF2_MAGBIAS_{X, Y, Z}, accel and gyro noise?)
### Future
- entire matrix of sensor combinations (more sensors module configuration)
- combine onboard AND offboard estimators (UAVCAN v1)
- testing ideas, run new and old changes side by side safely
More detailed and easier interpretable logging of optical flow data to facilitate optical flow testing, tuning, debugging. Some configuration issues with the existing PWM flow sensor were found using these tools.
https://github.com/PX4/Firmware/pull/16050
Bug report for tailsitters: Thrust setpoint incorrect during transition. Reportedly reproducable in SITL.@RicardoM17 for help on that topic. We should also reenable tailsitter tests once this is fixed.
https://github.com/PX4/Firmware/pull/16057
Final part of a long series of changes to enable more intuitive stick input in multicopter position mode. Feedback so far is very positive. Confidence on stability is high. Please test fly the mode and give your feedback:
https://github.com/PX4/Firmware/pull/16052
Effort went into finishing the separation of flight tasks into its own module. The intermittent SITL test failures are the biggest remaining problem.
PX4:master ← PX4:separate-flight-tasks
opened 12:52PM - 14 Apr 20 UTC
**Describe problem solved by this pull request**
The FlightTasks library was de… signed to separate the core multicopter position control from the position, velocity, acceleration setpoint generation to fulfill various tasks. The separation hepled a lot in terms of modularity and debuggabilty and the main data flow is through generated message structs like `vehicle_local_position_setpoint` (, `vehicle constraints`, `landing_gear`) but the two pieces are not completely separate. The FlightTasks library is technically still inside the position control module. Also there are certain dependencies e.g. for landing takeoff limiting and similar cases that still lead to unexpected problems every now and then.
**Describe your solution**
I strated seprating out the FlightTasks library to live in a separate module that I called `flight_mode_manager` with the plan of the Navigator Architecture planning in mind that we aim towards having flight mode classes like flight tasks for all setpoint generation in the future. It's unfinished and I'm trying to separate certain dependencies in a good way to be able to cut a clear line between the modules.
The main pain points so far are:
- [x] **Position state preprocessing** - The position control module should use the state as published by the estimator and not generate its own mixed state that is not available to other modules or in the log.
**EDIT:** This has to be solved in a idfferent pr but I made sure it's no blocker anymore here.
- [x] **Emergency failsafe** - I think the position control module should be able to handle the situation where setpoints are gone for a certain time or forever and the setpoint generation would stop publishing when things go really wrong.
- [x] **Hard limits vs specified constraints** - We should get rid of specified constraints that get applied in the controller, we already started to do that. The hard limits stay to have sane execution.
**EDIT:** This has to be solved in a idfferent pr but I made sure it's no blocker anymore here.
- [x] **Land/Takeoff special cases** - Out of limits, more restrictions, safety critical land detection.
- [x] **WeatherVane mess** - It's a global object that gets instanciated dynamically and passed around by pointer. It works around the entire architecture and we should move to the local scope where it's actually used.
**EDIT:** This has to be solved in a idfferent pr but I made sure it's no blocker anymore here.
**Test data / coverage**
SITL flies no. Testing for correct takeoff ramp and so on still pending.
**Additional context**
Discussed starting point from https://docs.google.com/document/d/1N59JHFqL_E9X4b-U0CzxW_eydqXUHZMxAH_FTD30ilk/
Bigger picture tracked in https://github.com/PX4/Firmware/projects/34
Onbaord FFT for gyroscope:
@dagar got it pretty close to usable. The goal is to have feedback for a notch filter frequency to filter out the vibrations. An ESC rpm feedback based version would also be nice to add.
https://github.com/PX4/Firmware/pull/16048
Fix for geotagging not working properly in simulation:
https://github.com/PX4/sitl_gazebo/pull/640
Allow MAVSDK to receive commands from the autopilot side:
https://github.com/mavlink/MAVSDK/pull/1236
There are still CI issues with the SITL tests based on MAVSDK failing. It’s really hard to find the root cause(s). We should create a discussion about that to efficiently get rid of these problems. (JFYI @JulianOes )
https://github.com/px4/firmware/issues/15940
Join us for ROS World 2020!
Reached an important milestone: First releasable draft of DS-015 standard. Aims to be the de-facto standard for CAN on drones.
Result of months of work. The focus from now on is implementing the spec and drive the adoption of UAVCAN v1 and the message definitions on PX4 and products of participating manufacturers. Final version of the document will be hosted as pdf on GitHub.
Oct 27, 2020
Call Moderators
@rroche
@JingerZ
@TSC21 (WG tech lead)
Dail In
Direct link to the meeting:
https://bit.ly/3gNLZ4F
Attendees:
Daniel Agar
Farhang Naderi
Pavel Kirienko
Peter van der Perk
Ray Stits
Iain Galloway
Dmitry Ramensky
David Sidrane
Agenda Items
Updated draft standard doc
Clarify and define WG name
Standard release roll-out steps
Support mechanism for post-release
Meeting Notes
DS-015 v1 ready for release, call for comments before Friday (will create a post on uavca…
Point release for 1.11 coming up. The battery parameter migration backport is already with it.
PX4:release/1.11 ← PX4:multi_battery_fixes_1.11
opened 07:32AM - 20 Oct 20 UTC
https://github.com/PX4/Firmware/pull/15985 to v1.11
Release notes workflow needs to be improved. We need to keep track of the changes while they get merged as part of the workflow such that it does not add up as a lot of work when cutting the release.
Join us at OSS+ELC for the “Open Source Drones Mini-Summit”
Renaming of the autopilot repository:
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.
