Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Meeting ID : 946 175 205Join using your mobile/desktop
Call in using your phone, find your local number : https://zoom.us/u/aetSYKbiMF
Multi-ekf, @dagar is working on getting it easily reviewable in multiple save change stages.
master ← 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
Part1: Refactoring for improved uORB multi topic and instance support:
master ← pr-uoRB_Subscription_ChangeInstance
opened 05:57PM - 01 Sep 20 UTC
In a few areas of the code base it's necessary to switch between different insta… nces of a uORB topic. For example `sensors/vehicle_angular_velocity` subscribes to the current primary gyro, but might change if the primary selection changes. Currently this is done by maintaining an array of uORB::Subscriptions.
This PR adds a new mechanism to uORB::Subscription that allows you to change the instance of an existing subscription. It's a small piece broken out of https://github.com/PX4/Firmware/pull/14650.
Part2: ekf adjustments for multiple instances
master ← pr-ekf2_misc_before_multi
opened 06:51PM - 01 Sep 20 UTC
A number of small changes broken out of https://github.com/PX4/Firmware/pull/146… 50 for individual review.
Part3: shortcut estimate voting as long as we don’t have it
master ← pr-sensors_multi
opened 07:01PM - 01 Sep 20 UTC
This PR introduces parameters for configuring the behavior of the `sensors` hub … module to optionally skip voting/selection and publish all instances. By themselves they aren't that useful, but it enables the multi-EKF use case where the sensor voting/selection moves from the `sensors` to the ekf selector and we need access to all instances of sensor data (calibrated in vehicle body frame).
Yet another small piece broken out of https://github.com/PX4/Firmware/pull/14650.
Goal is to have it mergable turned off by default which then allows enabling it for testing to stabilize.
Part4:
master ← pr-simulator_sensors_multi
opened 07:05PM - 01 Sep 20 UTC
The data is currently duplicated, so we could handle it differently for the sake… of testing later.
Broken out of https://github.com/PX4/Firmware/pull/14650.
We need testing on the new NuttX version:
master ← pr-nuttx-9.1.0-
opened 05:11PM - 18 Jun 20 UTC
@dagar FYI: @MaEtUgR @TSC21
I am adding the todo list we discussed yesterday… . All Please add what I am missing.
- [x] Investigate SD error messages on debug config on FMUv5
PR is in https://github.com/apache/incubator-nuttx/pull/1741/files
- [x] vet FMU1062
- [ ] run serial_test on DMA and non DMA UxARTS
- [x] Run the I2C killer on F4, F7, H7
- [x] F4
- [x] F7
- [x] H7 Passes with https://github.com/PX4/NuttX/pull/117
~~H7 Is failing~~
- [x] Add the BDMA (def config, like map must have ".sram4") to the H7 FMUs and test SPI6
- [ ] Add pass/fail criteria on sd_bench on test rack and document card ageing.
- [ ] resolve Windows build support issues
- [ ] Test, Test Test,
- [ ] Did I mention Test? :)
after this comes in
- [ ] Rework ROMFS to use source (.) and fix the paths to be relative on nuttx/linux see c99ff32 and back out excludes from shell_check
- [ ] Update and Merge these https://github.com/PX4/Firmware/pull/14691/commits/1afb7d947e7137477491c0e69ae37bd7337a0746 and https://github.com/PX4/Firmware/pull/14691/commits/60a97d861426c9827e23b7c22798c4ae3cd39291
Advantage: New NuttX is faster and supports new compilers
The reality is probably that after basic checks we need to merge it to get more thorough testing.
Monitoring the CPU load in detail is adding a significant amount of CPU load. Top adds ~5-8% load.
master ← pr-cpuload_updates
opened 04:45PM - 14 Jul 20 UTC
This saves about 5% cpu (stm32f7) when `top` isn't running.
- Nuttx only p… rocess all suspend & resume scheduling notes when top is
running, otherwise only track IDLE
- convert cpuload and print load to c++
- delete unused fields from print_load struct
Rewrites for some magnetometers to bring them into the same for like new IMU drivers:
master ← pr-ist8310_new
opened 02:04AM - 13 Mar 20 UTC
This is a cleanup/rewrite of the iSentek ist8310 driver in the style of the new … IMU drivers.
- simple state machine to reset, configure, etc (all sleeps removed)
- checked register mechanism
- if you disconnect and reconnect the sensor it will detect the bad settings and reconfigure itself
- configured in 16 bit mode (1320 LSB/Gauss instead of 330 LSB/Gauss)
The other thing to note here is that I'm changing the rotation convention to something that makes more sense (consistent with the other new drivers) and finally killing the copied "convention" from the original 3dr compass/gps.
<img width="327" alt="Screen Shot 2020-03-12 at 10 20 56 PM" src="https://user-images.githubusercontent.com/84712/76583516-c37c9e80-64af-11ea-836c-a5e3eca30375.png">
The old driver kept z as is (down is up?) and swapped x & y.
The "new" convention I'm going with is to always respect what's obviously up (-z in this case), keep X as an anchor, and then flip Y as necessary to maintain the right hand rule. https://github.com/PX4/Firmware/pull/14184#issuecomment-588273190
The downside is having to update the rotations everywhere. The upside is it's quite a bit more intuitive to set it properly per board.
master ← pr-QMC5883L_new
opened 04:57AM - 13 Mar 20 UTC
Similar to https://github.com/PX4/Firmware/pull/14383, this PR is a cleanup/rewr… ite of the QST QMC5883L driver.
- simple state machine to reset, configure, etc (all sleeps removed)
- checked register mechanism
- if you disconnect and reconnect the sensor it will detect the bad settings and reconfigure itself
- old driver had a SPI interface (that doesn't physically exist)
TODO:
- [x] review ODR selection
- [x] review range
- [x] review rotation (test on mRo GPS, etc)
<img width="1044" alt="Screen Shot 2020-03-13 at 12 56 47 AM" src="https://user-images.githubusercontent.com/84712/76591068-8b805600-64c5-11ea-8705-c955615f9b58.png">
``` C++
// Sensor orientation
// Forward X := +X
// Right Y := -Y
// Down Z := -Z
```
Improvements for ICM42688P. Looks like a nice sensor on paper and test rack, looking forward to get more data.
master ← pr-icm42688p_improvements
opened 01:59AM - 31 Aug 20 UTC
- use full 20 bit data (18 bit accel, 19 bit gyro)
- increase ODR to 16 kHz
… - disable all filters (anti-aliasing, notch filter, and UI filter all disabled or minimized for now until we want to set them intentionally)
The 20 bit data format is a bit weird (see below). To handle this and not grow our existing 16 bit sensor_accel_fifo/sensor_gyro_fifo messages I truncate the least significant bits as needed with a corresponding change to the scale factor. For example, since accelerometer data is is 18 bit dynamic range 16G it can fit within int16_t up until 4Gs.
General improvements for sensor drivers e.g. rotation for any external
master ← pr-external_accel_gyro
opened 01:57AM - 26 Aug 20 UTC
There isn't a huge need for this, but occasionally someone tries to use an exter… nal IMU and hits the limit. Four seems like a good magic number because it's the current ORB multi limit and what we already have for mag.
The 2nd change here is to start handling external accels and gyros like magnetometers where each instance has a configurable rotation parameter (CAL_ACCx_ROT/CAL_GYROx_ROT) that's only applicable to externals.
In contrast to external magnetometers, the default priority for an external accel or gyro is lower than an internal. A common example is the external icm20948 (with ak09916 mag). In most cases even if we only want the included ak09916 mag at a minimum we must also run the icm20948 to put it into i2c passthrough mode. This change allows us to actually use the IMU in some capacity (logging, analysis, etc), but at a much lower priority where it's never going to be used by the estimator or controllers.
TODO: set external for each accel/gyro or automatically determine from device id (preferred).
Failure detector still needs review:
https://github.com/PX4/Firmware/pull/15457
@dagar is thinking about extending the failure detector to monitor the rate controller just on takeoff to detect wrong a wrong IMU motor setup before flipping:
https://github.com/PX4/Firmware/pull/15650
No updates
No updates
No updates
Small bughttps://github.com/PX4/Firmware/pull/15626
Contribution to go fast when the risk for a collision is low. The risk is calculated based on altitude:
https://github.com/PX4/avoidance/pull/601
No updates
Bugfix contribution for memory usage within the library:
https://github.com/mavlink/MAVSDK/pull/1180
microRTPS: Fixed bugs on the transport code that were causing the bridge to not parse all the packets of the buffer, leading to the read buffer getting full rather quick.
https://github.com/PX4/Firmware/pull/15631
the agent_protocol_splitter, that allows to get and send both MAVLink and RTPS data on the same serial link is available in https://github.com/Auterion/agent_protocol_splitter . Documentation on how to properly use it and configure it, together with the PX4 (FMU) protocol splitter, will be added soon to the PX4 Devguide.
We got contributions for ESC messaging
Working over some confusions people had of the standard DS-015
Sep 01, 2020
Call Moderators
@rroche
Agenda Items
DS-015 Update
Dail In
Direct link to the meeting: https://bit.ly/3gNLZ4F
Join Microsoft Teams Meeting
Learn more about Teams | Meeting options
Meeting Minutes
Physical Layer
DS-015 now has the Physical Layer recommendations on it, which will be extended with a more clear description of the current topologies being considered (Han from NXP) and with the recommended electromechanical design of the ESC’s (maybe we can leverage the FETTech on…
https://github.com/PX4/Firmware/pull/15654 was merged so we cut the stable release:
https://github.com/PX4/Firmware/releases/tag/untagged-c883f5022b470f1eab67
It’s a draft since we didn’t write the highlight changelog and announce it yet.
Changelog gist: PX4 v1.11 Changelog · GitHub
Please make sure your contributions are mentioned and highlights are stressed.
@MaEtUgR and @dagar sync on the multicopter section.
Should drivers have a separate section? Yes
Announcement for the release should be ready by end of the week and published in time for the next dev call.
Ian Galloway from NXP question about mixer:
Junwoo Hwang:
Junwoo Hwang:https://dev.px4.io/master/en/concept/mixing.html#control-group-0-flight-control )
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.
