QGC Dev Call: February 04, 2021

Meeting Link

Project Board

Who’s at the meeting

  • Jinger Z.
  • Lorenz Meier
  • Ramón Roche
  • Julian Oes
  • Gus
  • Beat
  • Daniel Agar
  • Nathan T.
  • Patrick
  • Willian G.
  • Arnaud T.
  • David Sastre

Meeting Minutes

Intro to the call and immediate future of the project
We need to have a scope discussion, we are trying to do everything for everybody, It’s impossible to keep up for maintainers and any supporting organizations. We need to work towards a core set of things and align resources. We need to do a team effort to help with the maintenance of the project.

Project Management
There are a few things that we noticed that need to be taken care of. We have some technical debt in the architecture and the usage of git (version control) which leads to QGC being very hard to work with. No clear architecture patterns. Leading to problems with downstream adopters and blocking upstream contributions. We need to stabilize the QGC development process. Code reviews, releases, pull requests, and issues.

Next Steps

  • We set clear expectations on the issue tracker
  • We work through immediate issues on the latest release
  • Understand all the individual intentions from the contributors, see if we can work together while we stabilize in 4.1

Most Pressing Issues

  • Instabilities on the video Pipeline --> Define the pipelines we are supporting, how to test. (Arnauld to talk to Andrew and Patrick to de-feature and stabilize video pipeline)
  • Hardware - Manufacture can fine-tune for their own device
  • White-list the good configuration (@dagar)
  • Integration of gStreamer and Qt (@dogmaphobic)
  • Get a logic out of Qmxl

MAVLink Standard Test Suite: https://github.com/Auterion/mavlink-testing-suite

The Auterion mavlink test suite only targets common.xml. QGC uses ardupilotmega by default / in the releases.

Is APM planning on a test suite for their messages that we can use?

There are several in pymavlink

Thanks for pointing them out, I did in fact found the tests!

What’s the total coverage from the tests on ardupilotmega?

The broader tests are generator specific (ie https://github.com/ArduPilot/pymavlink/blob/master/generator/javascript/test/make_tests.py), and definitely not complete. Things can always improve!
One thing to be aware of is that by using mavsdk, you’re really testing a wrapper around / abstraction of pymavlink: the reference c libraries / headers / helpers which underpin them are generated with pymavlink. I would suggest it is better to test against the canonical reference, rather than a specific implementation. Which is what the tests in pymavlink are seeking to achieve. A test against an implementation is great for system integration etc, but people need to be aware it’s a test against that implementation: not the standard.