August 26, 2020
Agenda
Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Join Meeting
Meeting ID : 946 175 205
Join 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
Component update
Hardware Workgroups
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.
Aug 25, 2020
Call Moderators
@rroche
Agenda Items
FMU
Payload
BMS
Community discussion
Dail In
Join Microsoft Teams Meeting
Learn more about Teams
Meeting Minutes
FMU Specs
We are ready to release the FMUv5X spec, we need to get the following items completed
DS-011 document needs a link to the complete pinout or a way to package them together.
The pinout in DS-011 needs to be up-to-date with the pinout spreadsheet
Expo…
System Architecture
PX4:master
← PX4: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.
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
OS / NuttX
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.
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~~
![image](https://user-images.githubusercontent.com/1945821/92165236-94eed900-edeb-11ea-861d-14d383fa8517.png)
- [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.
PX4:master
← PX4:master-pr-nuttx-bp
opened 09:19AM - 26 Aug 20 UTC
Driver
PX4:master
← PX4: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
PX4:master
← PX4:pr-icm42605
opened 04:33PM - 25 Aug 20 UTC
![Screenshot from 2020-08-25 12-34-06](https://user-images.githubusercontent.com… /84712/91202099-51032200-e6cf-11ea-9ae2-2b7f116910b0.png)
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.
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
```
PX4:master
← PX4:pr-ist8308_cleanup
opened 04:12PM - 25 Aug 20 UTC
Commander
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.
Estimation
Updates
There’s now a change indicator detecting any functional change for the yaw estimator used for emergencies. So we can refactor it without the fear of breaking the existing functionality.
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.
![Screenshot from 2020-08-17 18-12-54](https://user-images.githubusercontent.com/23532607/90421298-7aadbf00-e0b9-11ea-8bba-62a0b1c1aa07.png)
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.
Matlab->Python EKF derivation migration completed.
@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
PX4:master
← PX4:pr-ekfSymPySideslipFusion
opened 02:33AM - 15 Aug 20 UTC
Results from before and after replay of a SITL gazebo_plane log show no visual d… ifferences:
Before:
<img width="1289" alt="old" src="https://user-images.githubusercontent.com/3596952/90303672-2f49b400-def3-11ea-9f22-260537fd6628.png">
After:
<img width="1291" alt="new" src="https://user-images.githubusercontent.com/3596952/90303675-31137780-def3-11ea-9b3d-2de210e2a327.png">
Test program comparing matlab and SymPy observation Jacobians and Kalman gains passes with differences within range expected for single precision calculations:
Pass: Sideslip Hfusion max diff fraction = 2.223303e-07
Pass: Sideslip Kfusion max diff fraction = 3.751102e-07
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:
![before](https://user-images.githubusercontent.com/3596952/90096435-94c46600-dd76-11ea-89ff-991e0c0202a5.png)
After:
![after](https://user-images.githubusercontent.com/3596952/90096443-99891a00-dd76-11ea-8816-6556b9c387ff.png)
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">
PX4:master
← PX4:pr-ekfSymPyYawEstimator
opened 11:32AM - 23 Jul 20 UTC
Tested in SITL with horizontal position changes using standard gazebo MC model. … Replay of the log was then used to compare the behaviour of the EKF-GSF yaw estimator before and after. There was no visible difference in outputs. note that this includes two patches from https://github.com/PX4/ecl/pull/870 that add the custom ecl::powf function
EKF-GSF estimates and weights before:
<img width="1146" alt="Screen Shot 2020-07-23 at 9 26 44 pm" src="https://user-images.githubusercontent.com/3596952/88281711-7cd76480-cd2b-11ea-8c04-d2298d9c61b4.png">
After changes:
<img width="1154" alt="Screen Shot 2020-07-23 at 9 30 55 pm" src="https://user-images.githubusercontent.com/3596952/88281906-d9d31a80-cd2b-11ea-84a8-bd4e75fb4dcb.png">
PX4:master
← PX4:pr-ekfSymPyCovariancePrediction
opened 08:37AM - 23 Jul 20 UTC
This is the covariance prediction part of https://github.com/PX4/ecl/pull/868 wh… ich is being implemented in a series of smaller PR's to make review and testing easier.
See https://github.com/PX4/ecl/pull/868 for earlier discussion.
Difference testing agains the matlab output for 100 randomised input P matrices showed difference ratios in two tests over the nominal test Pass/Fail ratio of 5E-5 that had been set, eg:
Fail: Covariance Prediction max diff fraction = 6.775925e-05 , old = 4.104861e+23 , new = 4.105139e+23 , location index = 4,6
Fail: Covariance Prediction max diff fraction = 1.048742e-04 , old = 1.940318e+11 , new = 1.940521e+11 , location index = 3,16
However the results are acceptable given the unrealistically large values for those entries induced by those tests. For the other 98 randomised tests, not a single matrix entry exceeded the 5E-5 difference ratio.
SITL Test log for gazebo_plane: https://logs.px4.io/plot_app?log=49cd1e69-bdd8-492f-99a8-0f2f94c35105
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.
VTOL
No update
Fixed Wing
No update
Multicopter
No update
Avoidance
No update
Simulation
SITL tests run a bit better now but still not perfect. This pr improved it:
Problem was that the land detector detected landing during descend. @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.
PX4:master
← PX4:pr-failure-injection
opened 12:28PM - 09 Jun 20 UTC
Work in progress to implement failure injection using MAVLink (https://github.co… m/mavlink/mavlink/pull/1331) as well as a systemcmd.
Unlike the `SIM_BLOCK_...` param this can be generic to SITL, HITL, reality.
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.
PX4:master
← PX4: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
MAVSDK
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.
mavlink: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.
mavlink: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.
mavlink:develop
← mavlink:disable-timesync-by-default
opened 09:31AM - 19 Aug 20 UTC
It's not completely clear to me when timesync should be enabled: it seems like i… t is a broadcast, so I'm not sure if all the components should send it or only the autopilot.
I disabled it by default, so those who use it (e.g. @irsdkv) should enable it with `system.enable_timesync()`.
MAVROS / DDS / ROS2
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.
UAVCAN
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.
Release
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.
Community Q&A
@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.
In-Depth discussions
Took place in between the updates.
Errata and Feedback
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.