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
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
master ← param-reset-specific
opened 02:41PM - 26 Aug 20 UTC
**Describe problem solved by this pull request**
There is currently no way to r… eset just one parameter to the default from shell/startup script.
This problem is bugging me for a long time:
You have an airframe that defines a ton of parameters some are defaults (for whatever reason), some not. Some need to be non-default because they are custom e.g. to enable a new non-default feature. Once the PX4 default is improved the airframe that ever had it custom needs to hardcode the default values and follow any upstream change to that part of the configuration from there on because otherwise existing vehicles don't get updated and are in an undefined state. Were they ever completely reset? Do they still have the old custom parameter?
After seeing `param show BAT_V_EMPTY` and `param set BAT_V_EMPTY 1` I expect `param reset BAT_V_EMPTY` to reset that parameter to its default value. I even did exactly that the first time, what could possibly go wrong.
**Describe your solution**
- `param reset {parameter name}` resets only that specific parameter with the possibility to specify multiple and the * wildcard.
- `param reset_all` resets all parameters with the possibility to have excludes and * wildcards.
- `param reset_nostart` is removed and all calls replaced with `param reset_all SYS_AUTOSTART SYS_AUTOCONFIG`
**Test data / coverage**
I SITL tested this. The only thing I found could be useful is result output e.g. following parameters were reset. There is no output like with all `param reset` before.
Now you can have 4 of each sensor class calibrated. Some were limited to 3. Also there distinguishing for external sensors available now.
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).
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.
master ← 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.
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
Some backports were merged on NuttX e.g. RTR is possible without defines now.
master ← master-pr-nuttx-bp
opened 09:19AM - 26 Aug 20 UTC
master ← battery-param-migration-fix
opened 06:02PM - 25 Aug 20 UTC
**Describe problem solved by this pull request**
@cmic0 tried to change `BAT1_V… _EMPTY`. Parameter was changed, it differed from `BAT_V_EMPTY` and after a reboot (starting simulation again) it was back to the old value.
Battery parameter migration from `BAT_*` to `BAT1_*` had the following issues:
1. In simulation the `SimulatorBattery` broke the chain of ModuleParams parent/child tree which the logic is relying on. Additionally it overwrote the parameters with hardcoded values internally.
1. The parameter migration prefers to migrate old over new if the values differ on boot but the flag `_first_parameter_update` was initialized false and hence always false. This didn't have an effect most of the time because the `previous_old_val` is zero on initialization and if the new parameter isn't zero it went the right path.
1. Some drivers using the battery class e.g. INA266 didn't clear the `parameter_update` subscription once they checked it's updated.
1. Some parts were hard to read.
**Describe your solution**
1. Remove `SimulatorBattery`, it only did harm.
1. Initialize `_first_parameter_update` with true.
1. Copy subscription data to a dummy to reset after it was updated.
1. Refactoring.
**Test data / coverage**
SITL testing.
@dagar added a driver ICM42605 TDK IMU
master ← pr-icm42605
opened 04:33PM - 25 Aug 20 UTC
FYI @BazookaJoe1900 @SalimTerryLi
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.
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.
https://github.com/PX4/Firmware/pull/14384 https://github.com/PX4/Firmware/pull/15613
Needs review:https://github.com/PX4/Firmware/pull/15457
https://github.com/PX4/ecl/pull/895
Get away from using sensor combined but have the individual accel and gyro messages only.https://github.com/PX4/Firmware/pull/15602
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 https://github.com/PX4/ecl/pull/894
https://github.com/PX4/ecl/pull/891
https://github.com/PX4/ecl/pull/890
https://github.com/PX4/ecl/pull/888
https://github.com/PX4/ecl/pull/887
https://github.com/PX4/ecl/pull/880
master ← 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
https://github.com/PX4/ecl/pull/868
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.
https://github.com/PX4/sitl_gazebo/pull/584
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.
master ← 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.
master ← pr-separate-mavlink-hil-interface
opened 09:47AM - 20 Aug 20 UTC
**Describe problem solved by this pull request**
This is the second attempt on … https://github.com/PX4/sitl_gazebo/pull/565 with a few bug fixes that triggered the failures before
The `gazebo_mavlink_interface` acts a. as a bridge interface to package sensor data into mavlink HIL interface b. Manages the connection with the fmu(HITL) or SITL instance. Having the two functionalities mixed make the plugin confusing and hard to add unit tests.
**Describe your solution**
This PR separates out the mavlink HIL interface to its own class from the `gazebo_mavlink_interface`
- Handle mavlink HIL messages and stores the information to enable sending HIL mavlink messages when triggered
- Open/Close sockets /serial to communicate with the fmu or SITL
**Test data / coverage**
Tested models flying in SITL
**Additional Context**
- This is the second attempt on https://github.com/PX4/sitl_gazebo/pull/565
A lot of small fixes, similar problems like on the PX4 sitl tests.https://github.com/mavlink/MAVSDK/pull/1175
Thanks to NicolasM0 for contributing a Windows COM connections fix.
develop ← NicolasM0:fix_serial_windows
opened 08:53AM - 25 Aug 20 UTC
on windows, for serial port > 9, "\\\\.\\" is needed before "COM"
These charact… ers are also compatible with port <= 9
more details here: https://stackoverflow.com/questions/27909666/createfile-serial-communication-issue
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.
develop ← Jonsen94:feature/qgc_complex_item_import
opened 12:30PM - 12 Aug 20 UTC
Currently the import_qgroundcontrol_mission function can only import simple item… s (waypoints).
QGC also supports surveys, corridor scans and structure scans.
This pull should fix the first two and allow importing surveys and corridor scans.
See https://github.com/mavlink/MAVSDK/issues/1116
It's not tested as I have problems connecting the server with my python-mavsdk scripts. (Timeout issues).
But it compiles at least.
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.