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
Hardware call was yesterday
FMU-v5X DS-011 standard spec is close to the final release (current version 0.5) todo list is almost worked off
If you’re interested join the Pixhawk SiG.
@rroche
Join Microsoft Teams Meeting
Learn more about Teams
https://github.com/PX4/Firmware/pull/15624
Now you can have 4 of each sensor class calibrated. Some were limited to 3. Also there distinguishing for external sensors available now.
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).
Get GPS aggregation and blending out of EKF into the sensors module. Good questions in the pending review. It’s a good time to address those questions about the original architecture now.
PX4:master ← PX4:pr-sensors_vehicle_gps_position
opened 07:24PM - 20 Mar 20 UTC
Brought the work from this PR https://github.com/PX4/Firmware/pull/13584 up to d… ate with current `master`
Need to test still.
FYI @dagar @JacobCrabill
NuttX update: @david_s5 has it passing CI and is quite far. He considers it ready and was waiting for the release to go out. The release is branched off so it’s fine as soon as we have all main supported boards verified.
https://github.com/PX4/Firmware/pull/15139
Some backports were merged on NuttX e.g. RTR is possible without defines now.https://github.com/PX4/Firmware/pull/15621
https://github.com/PX4/Firmware/pull/15616
@dagar added a driver ICM42605 TDK IMU
https://github.com/PX4/Firmware/pull/15614
Rewrites for some magnetometers. They handle reset scenario better. The rotations will be as close a possible to the datasheet. Internal rotations are handheld like before. The external rotation assumption magic is going out. There’s now an automatic rotation detection during calibration for external mags.
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
```
https://github.com/PX4/Firmware/pull/15613
Needs review:https://github.com/PX4/Firmware/pull/15457
PX4:master ← kamilritz:ekf_gsf_replay
opened 04:43PM - 17 Aug 20 UTC
This following plot shows the quaternion state in the change indication output. … The reset can be seen clearly.
Get away from using sensor combined but have the individual accel and gyro messages only.
PX4:master ← PX4:pr-sensor_combined_transition
opened 06:40PM - 22 Aug 20 UTC
In multi-EKF we have a `sensor_combined` (now `vehicle_imu`) for every EKF insta… nce. Most remaining `sensor_combined` usage in the code base can be easily replaced by `vehicle_acceleration` or `sensor_selection` + `vehicle_imu`.
https://github.com/PX4/Firmware/pull/14650
The multi EKF pr is getting closer to a mergeable state where the default is what we have but you can opt-in to using multiple EKFs and have a voter decide on what output is best.
@Paul_Riseborough completed the last bit and everything is now replaced with PySym derivation output. The outcome is except for numerical differences the same.
Benefits include:
It’s much faster to derive
you don’t need a Matlab license
it’s lower CPU load and memory footprint.
Here’s the full list of PRs in the project
PX4:master ← PX4:pr-ekfSymPyDragFusion
opened 03:55AM - 16 Aug 20 UTC
Before and after innovations, innovation variances and wind state estimates from… replay of gazebo SITL log data with EKF2_AID_MASK set to 33 to activate drag fusion.
Before:
<img width="1352" alt="before" src="https://user-images.githubusercontent.com/3596952/90326107-af414e00-dfc7-11ea-9e0c-934373cb1131.png">
After:
<img width="1353" alt="after" src="https://user-images.githubusercontent.com/3596952/90326109-b2d4d500-dfc7-11ea-8b27-4622d2e1915d.png">
Output from the auto-code comparison test program shows expected amount of difference between Matlab and SyPmy generated code:
Pass: Specific Force X axis Hfusion max diff fraction = 0.000000e+00
Pass: Specific Force X axis Kfusion max diff fraction = 1.161862e-06
Pass: Specific Force Y axis Hfusion max diff fraction = 0.000000e+00
Pass: Specific Force Y axis Kfusion max diff fraction = 2.331720e-06
https://github.com/PX4/ecl/pull/891
PX4:master ← PX4:pr-ekfSymPyAirspeedFusion
opened 10:19AM - 13 Aug 20 UTC
Replaces matlab symbolic toolbox generated equations with equivalents generated … using the SymPy library.
The following innovation and innovation variance sequence was generated from replay of a gazebo_plane SITL log. The sequences are visually identical.
Before:
<img width="1295" alt="before" src="https://user-images.githubusercontent.com/3596952/90123252-dd454900-dda1-11ea-89fb-50904c2b3c2b.png">
After:
<img width="1290" alt="after" src="https://user-images.githubusercontent.com/3596952/90123329-fb12ae00-dda1-11ea-808f-ad9e97efb311.png">
Output from the test program comparing the Jacobians and Kalman gain values from the Matlab and SymPy method is shown below. Differences are within the expect range for single precision operations.
Pass: Airspeed Hfusion max diff fraction = 0.000000e+00
Pass: Airspeed Kfusion max diff fraction = 3.226521e-07
PX4:master ← PX4:pr-ekfSymPyOptFlowFusion
opened 05:09AM - 13 Aug 20 UTC
Replaces the Matlab symbolic toolbox auto generated code used by the optical flo… w fusion method with code generated using the SymPy library.
Innovation and innovation variances before and after the change generated using replay of a SILT log are visually identical:
Before:
After:
Output from the test program comparing the Jacobians and Kalman gain values from the Matlab and SymPy method is shown below. Difference s are within the expect range for single precision operations.
Pass: Optical Flow X axis Hfusion max diff fraction = 7.477993e-08
Pass: Optical Flow X axis Kfusion max diff fraction = 3.627760e-06
Pass: Optical Flow Y axis Hfusion max diff fraction = 1.010612e-07
Pass: Optical Flow Y axis Kfusion max diff fraction = 1.309633e-06
PX4:master ← PX4:pr-ekfSymPyYawEstimator
opened 12:13AM - 11 Aug 20 UTC
PX4:master ← PX4:pr-ekfSymPyGpsYawFusion
opened 05:49AM - 30 Jul 20 UTC
This PR replaces the Matlab generated equations with sympy generated equations. … Continues on from #870.
Modifies the methods used for fusion of GPS receiver yaw angle.
Includes comparison test scripts that compare the observation Jacobians and Kalman gain equations generated for the Matlab symbolic toolbox and SymPy.
**Testing**
gps_yaw_fusion_generated_compare.cpp output:
Pass: GPS yaw Hfusion max diff fraction = 1.796981e-07
Pass: GPS yaw Kfusion max diff fraction = 3.981467e-07
SITL testing TODO
PX4:master ← PX4:pr-ekfSymPyMagFusion
opened 05:04AM - 30 Jul 20 UTC
This PR replaces the Matlab generated equations with sympy generated equations. … Continues on from #870.
Modifies the methods used for fusion of 3-axis magnetometer data, declination angle and yaw angle.
Includes comparison test scripts that compare the observation Jacobians and Kalman gain equations generated for the Matlab symbolic toolbox and SymPy.
**Testing**
3Dmag_fusion_generated_compare.cpp output:
Pass: Magnetomer X axis Hfusion max diff fraction = 0.000000e+00
Pass: Magnetomer X axis Kfusion max diff fraction = 7.846418e-08
Pass: Magnetomer Y axis Hfusion max diff fraction = 0.000000e+00
Pass: Magnetomer Y axis Kfusion max diff fraction = 1.035609e-07
Pass: Magnetomer Z axis Hfusion max diff fraction = 0.000000e+00
Pass: Magnetomer Z axis Kfusion max diff fraction = 0.000000e+00
mag_decl_fusion_generated_compare.cpp output:
Pass: Mag Declination Hfusion max diff fraction = 0.000000e+00
Pass: Mag Declination Kfusion max diff fraction = 1.228912e-07
yaw_fusion_generated_compare.cpp output:
Pass: 321 yaw option A Hfusion max diff fraction = 2.090426e-07
Pass: 321 yaw option B Hfusion max diff fraction = 1.139841e-07
Pass: 312 yaw option A Hfusion max diff fraction = 1.333159e-07
Pass: 312 yaw option B Hfusion max diff fraction = 1.998272e-07
Comparison of mag fusion innovations and field estimates before and after the change:
Before:
<img width="1338" alt="Screen Shot 2020-07-30 at 2 59 46 pm" src="https://user-images.githubusercontent.com/3596952/88882463-5bb7cc00-d275-11ea-93d3-faef5fff6cea.png">
After:
<img width="1338" alt="Screen Shot 2020-07-30 at 3 00 37 pm" src="https://user-images.githubusercontent.com/3596952/88882500-75591380-d275-11ea-9bb9-167c477afffa.png">
Comparison of yaw innovations and innovation variances before and after the change:
Before:
<img width="1333" alt="Screen Shot 2020-07-30 at 3 35 12 pm" src="https://user-images.githubusercontent.com/3596952/88884616-56a94b80-d27a-11ea-93cb-c18fd5893e3f.png">
After:
<img width="1341" alt="Screen Shot 2020-07-30 at 3 33 40 pm" src="https://user-images.githubusercontent.com/3596952/88884504-1a75eb00-d27a-11ea-8cd9-6132b02e160d.png">
https://github.com/PX4/ecl/pull/871
https://github.com/PX4/ecl/pull/870
PX4:master ← PX4:pr-ekfSymPyDerivationConversion
opened 08:05AM - 16 Jul 20 UTC
This is a work in progress. Derivations and conversions in c++ code are complete… , however test benches and SITL/flight testing require further work.
This is built on proof of concept work by @RomanBapst - see https://github.com/RomanBapst/ecl/tree/ekf_python
Test comparison programs have been written that compare the output from the sympy generated code to the legacy code in master. The largest fraction difference defined as (new_value - old_value)/old_value is found and printed. For example the covariance prediction gives:
max_diff_fraction = 2.074566e-06 , old = -1.490614e+17 , new = -1.490610e+17 , location index = 4,7
Comparing the observation Jacobians for the various yaw fusion methods gives:
321 option A max_diff_fraction = 1.322706e-07 , old = 9.012533e-01 , new = 9.012532e-01 , location index = 3
321 option B max_diff_fraction = 3.555763e-07 , old = 1.005770e+00 , new = 1.005769e+00 , location index = 2
312 option A max_diff_fraction = 1.696653e-07 , old = -2.810457e+00 , new = -2.810457e+00 , location index = 2
312 option B max_diff_fraction = 5.844245e-07 , old = -4.589488e-01 , new = -4.589485e-01 , location index = 1
Differences have so far have been the last significant figure.
**Testing**
Comparison test programs for the covariance prediction and observation methods. See https://github.com/PX4/ecl/blob/pr-ekfSymPyDerivationConversion/EKF/python/ekf_derivation/run_test_programs.sh
SITL testing that exercises all observation methods. See the following:
SITL gazebo test https://review.px4.io/plot_app?log=a08ff241-6840-456b-b509-491235c4267d
SITL gazebo_iris_opt_flow test https://logs.px4.io/plot_app?log=9c29150e-ab23-4245-869c-bb2a978cebc6
SITL gazebo plane test https://logs.px4.io/plot_app?log=a568008f-92f8-48c8-93ed-694b7a94dd19
TODO: SITL testing for MC body frame specific force fusion and GPS yaw fusion.
No update
No update
No update
No update
SITL tests run a bit better now but still not perfect. This pr improved it:@Jaeyoung-Lim found a better thrust value for the simulated model.
PX4:master ← PX4:pr-lower-iris-motor-consstants
opened 06:44PM - 21 Aug 20 UTC
**Describe problem solved by this pull request**
Previously SITL tests were fai… ling because the hover thrust was too low, which was decreased in PX4/sitl_gazebo#575
Now, SITL tests have been failing since we decreased the motor constants on the iris since the hover thrust was too high
@bresch FYI
The MAVROS mission and the safe landing test are still failing. Discussion about next steps to solve the issues and have CI always passing if there was nothing broken in a pr to avoid people ignoring the result. There will be more insights with the failsafe injection. @JulianOes is working to get that in.
https://github.com/PX4/Firmware/pull/15063
Ping to the VTOL team. @Jaeyoung-Lim tried to fix the tiltrotor but it kept on failing. It would be nice if someone from VTOL control could look into it.
PX4:master ← PX4:pr-fix-tiltrotor
opened 03:14PM - 24 Aug 20 UTC
This PR fixes the tiltrotor model that was failing SITL testing before, and adds… the tests to mavsdk testing
Separate out HIL interface such that it doesn’t need to be implemented and maintained for each simulator we support but resides in a standalone library.
https://github.com/PX4/sitl_gazebo/pull/582
A lot of small fixes, similar problems like on the PX4 sitl tests.
mavlink:develop ← mavlink:pr-fix-ci
opened 09:09AM - 25 Aug 20 UTC
Hopefully this fixes the 404 for the cURL libs, as well as a bunch of other CI b… uild and test failures that have been added up.
Thanks to NicolasM0 for contributing a Windows COM connections fix.https://github.com/mavlink/MAVSDK/pull/1174
Allows one set of complex mission item to be exported from QGC and uploaded to the autopilot. But there’s no API apart from importing and uploading. It complains it doesn’t understand the content.https://github.com/mavlink/MAVSDK/pull/1163
Time sync is now an opt-in feature and disabled by default because there were issues when wasn’t actually in use.https://github.com/mavlink/MAVSDK/pull/1169
This year ROScon is not happening but there’s ROS World 2020 and we’ll take part, meet the ROS community, present our ecosystem: ROS World 2020
That’s the first time we’re as close to the ROS community. We plan to take part in next year’s ROS con.
No updates this week. The standard is being further settled. Please look into the ESC messages of the DS-015 document. They are close to getting fixed
TODO @rroche : Add DS-015 document.
v1.11 close to the stable release. We feel good about the stability. Do we have insights from flight review on testing frequency?
@rroche Is preparing a changelog and layout for the blog post. It would be nice if the maintainers could make sure the release highlights are capturing the important changes.
@rroche : Some community members can’t join this dev call because Zoom is banned from certain company network configurations. We look into switching to Microsoft Teams, Jitsi or maybe Google Meets. @rroche will do some tests and post open test meetings on the #dev-call channel on slack.
Took place in between the updates.
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.
Updates
Matlab->Python EKF derivation migration completed.