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
Multi-ekf, @dagar is working on getting it easily reviewable in multiple save change stages.
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
Part1: Refactoring for improved uORB multi topic and instance support:
PX4:master ← PX4: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
PX4:master ← PX4: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
PX4:master ← PX4: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:
PX4:master ← PX4: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:
PX4:master ← PX4: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.
PX4:master ← PX4: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:
PX4:master ← PX4: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.
PX4:master ← PX4: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.
PX4:master ← PX4: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
PX4:master ← PX4: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:
PX4:master ← PX4:pr-failure-detector-improvements
opened 04:47PM - 30 Jul 20 UTC
**Describe problem solved by this pull request**
I found:
1. Commander contain… ed two very similar conditions to process failure detector output
1. Failure detector used different naming conventions
1. Failure detector contained extensive logic to keep track of the state getting updated or not. This can be done by just comparing the one-byte state before and after.
1. Failure detector reactions to attitude tracking checks are not independent of reactions to ESC checks
**Test data / coverage**
No tests done.
@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:
PX4:main ← PX4:pr-failure_detector_rate_ctrl
opened 11:23PM - 31 Aug 20 UTC
Monitor rate controller for failure at takeoff (roll or pitch rate error divergi… ng) to prevent flipping on takeoff if there's an issue with motors, props, etc.
Needs testing/tuning. I'm hoping we can find a good threshold where it can be safely on by default without risk of false positive.
No updates
No updates
No updates
Small bug
PX4:master ← PX4:mixer-hotfix
opened 07:20PM - 26 Aug 20 UTC
**Describe problem solved by this pull request**
Taking off with a powerful eno… ugh multirotor which has hover thrust < 50% leads to a vertical flyaway. E.g. SITL jmavsim
By bisecting I found that #15563 introduced that and after inspection I found that only the idle thrust part has enough influence to make that happen. Apparently the output was scaled with [0,1] instead of [-1,1].
**Describe your solution**
The variable `_idle_speed` which was removed in #15563 was always -1.f so I just followed where it was used before and replaced the previous use with the number.
**Describe possible alternatives**
We should probably reconsider suddenly changing the output scaling in the middle of the mixer. This is just a hotfix to restore previous functionality without `_idle_speed`.
**Test data / coverage**
SITL flying works again :tada:
**Additional context**
Bug is not on v1.11
Contribution to go fast when the risk for a collision is low. The risk is calculated based on altitude:
PX4:master ← ldg810:risk_based_speedup
opened 11:31AM - 13 Aug 20 UTC
In global planner, the setpoint to follow global path is updated periodically at… "GlobalPlannerNode::publishSetpoint()"
The speed of drone is keep constantly (2.0 m/s at current situation).
However, it would be efficient to speed up in low-risk environment.
I added following two parameters to apply risk-based speedup algorithm.
- max_speed_(double) : maximum speed of drone in safe environment.
- use_risk_based_speedup_(bool) : boolean to use risk based speedup algorithm
The algorithm is simple
1. get current cell from global_planner
2. get risk of current cell (=cur_risk)
3. if risk is high(>=0.5), set speed to slow (1.0m/s)
else, set speed to fast (1.0 + (global_planner_.max_speed_ - 1.0) * (1 - cur_risk))
4. isCloseToGoal is also changed to determine the drone is close to goal if distance from destination and drone is within current speed setpoint. (If not, the drone would oscillate in fast flight)
Following graph is comparison between default algorithm(red line) and risk based speedup algorithm(green line) from a point to another point
No updates
Bugfix contribution for memory usage within the library:
mavlink:develop ← NicolasM0:fix_log_file_chunks_received_size
opened 12:24PM - 27 Aug 20 UTC
I have always an error at the end of downloading a log file :
I use a mavsdk_server compiled on develop branch on Windows.
After digging a bit, I found that if log part size in not a multiple of MAVLINK_MSG_LOG_DATA_FIELD_DATA_LEN
(it seems that there is no reason to be of a particular size),
chunks_received size must be "part_size / MAVLINK_MSG_LOG_DATA_FIELD_DATA_LEN +1"
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.
PX4:master ← PX4:pr-smaller_microRTPS_tweeks
opened 02:15PM - 27 Aug 20 UTC
In the process of leveraging the [agent_protocol_splitter](https://github.com/Au… terion/agent_protocol_splitter), some problems were found on the transport code that resulted on unneeded dropouts of certain msgs. This PR:
1. Solves a small (big) bug on the parsing of the packets when a packet is found to have a CRC error;
2. Adds verbosity control to the timesync functionality;
3. Reduce the number of RTPS streams (a lot didn't make sense to expose on the mission computer).
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…
[Port v1.11] Fix Battery Parameter Migration by MaEtUgR · Pull Request #15654 · PX4/PX4-Autopilot · GitHub 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:Mixing and Actuators · PX4 Developer Guide )
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.
