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:
https://github.com/PX4/Firmware/pull/15656
Part2: ekf adjustments for multiple instances
https://github.com/PX4/Firmware/pull/15657
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:
https://github.com/PX4/Firmware/pull/15659
We need testing on the new NuttX version:
https://github.com/PX4/Firmware/pull/15139
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.
https://github.com/PX4/Firmware/pull/15330
Rewrites for some magnetometers to bring them into the same for like new IMU drivers:
https://github.com/PX4/Firmware/pull/14383
https://github.com/PX4/Firmware/pull/14384
Improvements for ICM42688P. Looks like a nice sensor on paper and test rack, looking forward to get more data.
https://github.com/PX4/Firmware/pull/15648
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:
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:
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).
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…
[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: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.
