PX4 Dev Call: July 29, 2020

rroche · July 29, 2020, 2:59pm

July 29, 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

Call in using your phone, find your local number: Zoom International Dial-in Numbers - Zoom

Component update

Hardware Workgroups

Payload / FMU / BMS

Last call FMUv6 was discussed. The design is close to be released. Some documents are still being checked. Standard will be announced. Gumstix will make a prototype board.

System Architecture

Logger changes about the default logger profile. Potentially remove the replay logging from default profile to make sure we can use cheap SD cards for longer.

https://github.com/PX4/Firmware/pull/15425

Make sure gaps in logging are recorded and get noticed.

https://github.com/PX4/Firmware/pull/15440

Better handling of buffer overflow.

https://github.com/PX4/Firmware/pull/15439

OS / NuttX

@david_s5 was looking into a problem with telemetry related to Nuttx.

NuttX release is out, we can go back to working on upgrading.

@dagar F412 backport or wait for the update? Depends on the effort also on testing.

Driver

Contribution of fixes in optical flow driver

https://github.com/PX4/Firmware/pull/15433

DSM RC parsing more robust

https://github.com/PX4/Firmware/pull/15430

Crazyflie was not booting in master. @dagar fixed it and looked into using the new MPU driver to support the Crazyflie 2.

github.com/PX4/PX4-Autopilot

crazyflie fix and i2c mpu9250

PX4:master ← PX4:pr-crazyflie_fix_and_mpu9250

opened 01:44AM - 27 Jul 20 UTC

dagar

+846 -2206

This gets the Bitcraze Crazyflie 2.0 (not 2.1 yet) working again with a new MPU9…250 driver using the FIFO. Eventually this I2C MPU9250 should be merged with the SPI version after interface changes are made. - fixes https://github.com/PX4/Firmware/issues/13946, https://github.com/PX4/Firmware/issues/12996, https://github.com/PX4/Firmware/issues/11750 Surprisingly, we can actually handle 1 kHz IMU on 400 kHz I2C (if done carefully).

Hex was renamed to CubePilot and the autopilot are called CubeYellow, CubeOrange… We renamed them.

https://github.com/PX4/Firmware/pull/15415

@JingerZ The board Yellow and Orange are not listed as supported currently. They should be listed as experimental/community supported. There will be a follow up discussion with @dagar

Commander

No updates

Estimation

Progress on Python EKF derivation:

github.com/PX4/PX4-ECL

EKF: replacement of autocode with sympy generated output

PX4:master ← PX4:pr-ekfSymPyDerivationConversion

opened 08:05AM - 16 Jul 20 UTC

priseborough

+9215 -1475

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.

Master of Firmware is out of date with ecl. New geo table doesn’t fit FMUv2. We might want to compensate the flash size increase with the auto code generation (Python derivation) savings.

What path should we go update everything at the same time or small pieces and save flash with other means in between.

Goal: Have a validity flag. Additionally @dagar found a bug with the delta-time.

https://github.com/PX4/Firmware/pull/15370

VTOL

VTOL attitude controller runs with 1200Hz when there’s no attitude setpoint published:

github.com/PX4/PX4-Autopilot

vtol_att_control: limit excessive scheduling

PX4:master ← PX4:pr-vtol_att_throttle

opened 03:50PM - 20 Jul 20 UTC

dagar

+16 -0

This is to prevent `vtol_att_control` running at absurdly high rates (kilohertz)… from every single actuator controls publication from both the multicopter and fixed wing controllers. I don't really like this solution, but it works for now until there are larger VTOL architectural changes in place. It's not really an issue if `IMU_GYRO_RATEMAX` is set appropriately for these platforms, but currently it's still possible to slip through with the defaults intended for a small multicopter.

Fixed Wing

Multicopter

Progress on land detection, thanks to @dagar :

Testflights needed after check of @MaEtUgR comments. No major change anticipated.

Avoidance

No updates

Simulation

@JulianOes CI: we changed gazebo to be able to load different models. There was a race condition where gzserver was not yet present when trying to load the model and then there was no model and the tests failed.

https://github.com/PX4/Firmware/pull/15432

Script to run multiple simulation instances

github.com/PX4/PX4-Autopilot

Update gazebo_sitl_multiple_run.sh

PX4:master ← iwishiwasaneagle:patch-1

opened 03:27PM - 20 Jul 20 UTC

iwishiwasaneagle

+1 -1

**Describe problem solved by this pull request** If `make px4_sitl_default` is …run, and not `make px4_sitl_default gazebo` then each model instance will throw the following errors: ``` [Err] [Plugin.hh:178] Failed to load plugin libgazebo_gps_plugin.so: libgazebo_gps_plugin.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_multirotor_base_plugin.so: libgazebo_multirotor_base_plugin.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_motor_model.so: libgazebo_motor_model.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_groundtruth_plugin.so: libgazebo_groundtruth_plugin.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_magnetometer_plugin.so: libgazebo_magnetometer_plugin.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_barometer_plugin.so: libgazebo_barometer_plugin.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_mavlink_interface.so: libgazebo_mavlink_interface.so: cannot open shared object file: No such file or directory [Err] [Plugin.hh:178] Failed to load plugin libgazebo_imu_plugin.so: libgazebo_imu_plugin.so: cannot open shared object file: No such file or directory ``` **Describe your solution** Add the info into the `gazebo_sitl_multiple_run.sh` **Test data / coverage** Vagrant VM running Ubuntu 18.04 LTS, not much else to test.

MAVSDK

New release today: 0.29.0

Main difference how user callbacks get called. Before there was a thread pool for the callbacks that caused potential threading issues. Now the callbacks are called from one thread and you have to do short callbacks and/or start new threads yourself if you call other blocking code.
There’s a new feature and tutorial to be able to use a joystick.
MAVSDK on ARM improvements
Failure injection.
Bug fixes, see notes

MAVROS / DDS / ROS2

Testing of the serial link with ROS2 using a Pixhawk 4 and seeing good throughput with parallel topics.

What happened with Serial TX DMA in NuttX? There are issues like the GPS ones we had before. That’s what @david_s5 meant we need to look into it before updating NuttX.

UAVCAN

PX4 UAVCANv1 work ongoing, no particular updates at the moment.

Release

For the 1.11 release we have the land detector issue that is pending. It’s now reviewed and needs final testing.

We should revive the tester GitHub group and add community volunteers such that they easily get notified when tests are needed.

Community Q&A

@JingerZ has a pr from CUAV Fix CUAV CAN_PMU power display as 0%, unable to unlock by CUAVcaijie · Pull Request #15314 · PX4/PX4-Autopilot · GitHub
@dagar Does anyone have the hardware? He is looking into it and answering.

@nrogelio found an issue: Pixhawk 4 + Drotek Sirius RTK GNSS compasses inconsistent · Issue #15312 · PX4/PX4-Autopilot · GitHub
He has an external compass issue that seems to be starting with the commit hash he posted. But it’s strange because the commit doesn’t change the magnetometer parts of PX4. It sounds like the mag orientation is wrong but it has to be debugged. Maybe other GPS modules with the same mag have different orientation. The mag auto rotation ([WIP] commander: auto set external mag rotation during calibration if possible by dagar · Pull Request #15120 · PX4/PX4-Autopilot · GitHub) would catch the problem if it’s that.

In-Depth discussions

Parameter meta data compressed on-board

github.com/PX4/PX4-Autopilot

Generate param metadata as MAVLink-compatible JSON component info

PX4:master ← hamishwillee:json_param_metadata

opened 07:27AM - 21 Jul 20 UTC

hamishwillee

+171 -11

MAVLink has defined a standardised way for a GCS to query a component's paramete…r metadata (in this case autopilot) in [Using COMPONENT_INFORMATION to obtain vehicle metadata](https://github.com/mavlink/mavlink/issues/1346). This does the first part of that work by automatically generating the parameter metadata in Json format. The generated output for the FIRST version of this can be found here: https://gist.github.com/hamishwillee/3779fcfb6bd368b1cd9fd3f84cbcb5b6 The parser works, but is not ready for merging because the schema defined in https://github.com/mavlink/mavlink/issues/1346 is incomplete/incorrect with respect to the test code provided. Once schema is signed off by @DonLakeFlyer the output here can be validated/updated. Further modifications for changes should be fairly simple. Some of the questions I have outstanding: - Should every value be defined whether or not empty? - Does this also apply to "values"? If values are not defined what should these look like? - Note that min value and max value on test and schema mismatch. - When is additionalProperties declared, and where? - How is "required" used - is this a param property or a higher level property [unclear in schema]. @DonLakeFlyer I have not looked at the translation file - do you have test code for that/workable schema? FYI @julianoes @dagar I was planning on leaving the next part of this project - the COMPONENT_INFORMATION implementation and working out how to include this file in the Firmware file system for someone else. Also, does this need to include the param metadata for params that are defined as "injected"?

Would be good to have @hamishwillee and/or @bkueng in the call for further discussion.
@dagar motivates to think about trying to not miss out on any opportunities to rule exclude e.g. value ranges. Check MAVLink FTP performance, it’s probably not performing as well as it could/should.

QGC uses a different protocol than MAVLink FTP to download logs. We need a mechanism to slow everything else down while transmitting the file and then switch back to normal operation.

UAVCAN rangefinder support

github.com/PX4/PX4-Autopilot

UAVCAN Rangefinder Support

PX4:master ← avionicsanonymous:uavcan_rangefinder

opened 12:38AM - 13 Jun 20 UTC

avionicsanonymous

+267 -2

**Describe problem solved by this pull request** Add support for rangefinder co…nnected via UAVCAN. **Describe your solution** Added sensor bridge for "rangefinder" sensor, which accepts the included AvAnon rangefinder message. This custom message is added because the standard UAVCAN rangefinder message does not include the necessary data to fill out the PX4 distance_sensor topic, such as the min and max range of the connected sensor. **Describe possible alternatives** The standard UAVCAN rangefinder message could be used, but we would have to come up with some other way to convey the limits of the rangefinder. Since I'm not aware of any currently-existing devices that use that message, this should be just as good. If any exist in the future, we can add handlers for that message to this sensor bridge and solve the missing data at that time. **Test data / coverage** Bench and flight tested using the AvAnon rangefinder UAVCAN interface. "distance_sensor" data was logged as expected.

@dagar everything seemed fine except for they add their own custom DSDL which we should not carry that in PX4. We should forward the information into parameters.

@JingerZ FMUv5x Holybro is making a new prototype. Does @dagar and @david_s5 want one?
@david_s5 has the old prototype and we need to communicate the required changes for the updated specs clearly.

Errata and Feedback

Let me know below if I failed to capture anything the right way, and if there are any updates, or you have feedback on the call format.

hamishwillee · July 30, 2020, 2:45am

Generate param metadata as MAVLink-compatible JSON component info

The protocol is designed to fetch data from the vehicle that is invariant after boot - parameter metadata, version info, supported mission items etc.
It could also be used to get all actual parameters on boot (instead of existing param protocol) and then monitor for changes on individual params. This would be more efficient than what we do now.
It is tempting to say well why don’t we allow requesting this dynamically at any time, and further that we then take a particular split that we’re interested in. This is do-able but I’d prefer we looked at a new API for that.

@DonLakeFlyer might take a different view.

For MAVFTP efficiency, @bkueng and @JulianOes more likely to add value than me.

DonLakeFlyer · July 30, 2020, 4:41pm

I don’t understand what that means.

hamishwillee · July 31, 2020, 12:55am

@DonLakeFlyer

I don’t understand what that means.

We are currently thinking about requesting the values of all parameters after boot using the component_info approach. This might be more efficient than getting them using the normal PARAM_REQUEST_LIST approach. This is in line with the protocol.

You may recall Tridge talking about a maybe having a new param protocol where params could be more efficiently packed and requested in big chunks. I think the suggestion is that we allow something similar in the COMPONENT_INFO message - ie you be able to request smaller chunks than “all params”. What I am saying is that I do not think this aligns with our thinking around the protocol.

Nor do I think it necessary because once you have uploaded most params in a file, keeping track of individual changes is easy enough and you no longer have the big inefficiency of the current protocol.

Ardupilot probably agree - since they now have a model where they upload params in a file on boot just as we are planning.

What we could do is provide a mechanism to request that the information be dynamically regenerated. That makes sense for parameters and would not be outside of our current thinking.

DonLakeFlyer · July 31, 2020, 7:31pm

I get all that part and agree. I specifically don’t get this: “It is tempting to say well why don’t we allow requesting this dynamically at any time, and further that we then take a particular split that we’re interested in. This is do-able but I’d prefer we looked at a new API for that.”