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.

github.com/PX4/PX4-Autopilot

logger: disable estimator replay logging by default

PX4:master ← PX4:pr-logger_defaults

opened 01:39PM - 27 Jul 20 UTC

dagar

+5 -5

- unnecessarily wearing out cheap sd cards that come with most flight controller…s - default cards often stop functioning entirely within months of operating on the test rack (logging for ~5 minutes at a time 5-20 times/day) - default ekf2 replay really needs logging from boot anyway (@priseborough) - some people actually use USB and Mavlink FTP to transfer log files ### Master - nominal logging rate `~32 KiB/s` (~115 MiB/hour) ### PR - nominal logging rate `~15 KiB/s` (~54 MiB/hour) As a follow up I would look at further optimizing the default logging rate.

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.

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

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.

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

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:

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

Fixed Wing

Multicopter

Progress on land detection, thanks to @dagar :

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

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

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

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

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

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

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

@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.”