[Discussion] Let's start planning QGC v5.0

QGroundControl
1

Hey community, we want to start the discussion towards the next big release of QGC v5.0 and gather feedback from the community.

What would you like to see in QGC v5.0?

We are looking for contributors who either have a PR stuck in the queue or plan to submit a PR soon with a fix or new functionality. Let’s plan how to bring your changes in as quickly as possible. Drop a comment below!

What would you like to see fixed?

If you are a user of QGC and know of a few bugs and you have created issues, feel free to drop a link as a comment below, we want to know what are the most urgent, and annoying issues out there.

A note from the maintenance team

We have a few things we want to update from the current maintenance team, mainly the GStreamer implementation, which has amassed enough technical debt to warrant a few changes. In fact, there are a few pull requests in our queue that take us in the right direction. We want to leverage those and improve other aspects like cleaning the code implementation and robustifying our CI tests.

There are tons of minor fixes on our PR queue that we want to start accepting but not before we are sure we have an open discussion with the community about our next release and have a

Moving on to a newer Ubuntu release

One big thing we have identified is the need to break compatibility with Ubuntu 18.04 LTS. We had already done so in the past (by accident, my bad, sorry!) when I updated our CI to Ubuntu 20.04. We found out the hard way AppImages built with a newer libstdc++ library weren’t compatible with OS’es using an older version.

We need to break with 18.04 because the newer GStreamer libraries only work with 20.04 and above. This means the AppImages we release will only target more recent Ubuntu distributions. We gain a clean GStreamer implementation and CI tests for GStreamer. We know Ubuntu 18.04 LTS is still supported by many, including some members of the ROS community. Still, it’s holding a lot of the development back, and we would like to upgrade.

Some of the features on our PR queue that would benefit from this change:

  • Gstreamer needs to be updated to a newer version, which only supports Ubuntu 20.04
    • Including CI testing for gstreamer
  • Deploying AppImages with newer glibc for newer targets
  • Qt6 doesn’t yet support Ubuntu 18.04 (but might do so by the time we get around to upgrading)

Looking for developers to join the team

We are also looking for more contributors to join us on the maintenance team, we need help with issue triaging, PR review, documentation, architecture and release management, if you have been involved with the project before and can contribute some of your time in a recurring basis, we want to hear from you, feel free to drop a comment below, or reach out directly on Slack.

1 Like
2

Hello Ramón, I have thought about adding geo-awareness functions to a version of QGC in the future, integrating with the AIRMAP api to automatically create fences in mission planning. I think that this idea may be very difficult to carry out in this next version but for my part I think it could be a very useful functionality and above all, with the new European regulations on the use of drones they can work very well

2 Likes
3

@fbavaro56, we would be more than happy to help you review and, if you are open, discuss the architecture of the implementation once you are ready to work on it. I think any PR is welcome as long as it passes the quality check.

1 Like
4

Excellent, I will attend the next dev call and if you think so I will tell you a little about what I have thought to see if we can shape it

1 Like
5

GPU Compatibility Mode, which addresses flickering that may occur on low-end devices, does not work. Can you solve this problem? I’m guessing it’s a problem with OpenGL or Qt Framework.

Github issue : GPU Compatibility Mode in QGC is not working. · Issue #9715 · mavlink/qgroundcontrol · GitHub

6

I vote for QGroundControl to have a singular build system (CMake) CMake transition requirements · Issue #8240 · mavlink/qgroundcontrol · GitHub seems this effort was last addressed in 2020 and it is confusing to new comers what if any functionality/features are lost if you build with one vs the other.

I also would like to vote for untethering QGC from a Qt minor version (5.15.2 currently is the only allowed stable version which means that it is missing out on 7 minor versions worth of bug fixes (so at least hundreds) from Qt) from Getting Started with source & builds · QGroundControl Developer Guide and specifically the following paragraph:

“Do not use any other version of Qt! QGC has been thoroughly tested with the specified version of Qt (5.15.2). There is a significant risk that other Qt versions will inject bugs that affect stability and safety (even if QGC compiles).”

I believe this strict minor version tethering is related to the use of private headers and classes from the Qt framework so I’m starting to compile a list of all the places these private classes are used so we can figure out what functionality we need from the public Qt APIs to accomplish our functionality without private api workarounds.

I work at the Qt Company and so would be able to raise priority on bug fixes or feature fixes to eliminate the need for private workarounds.

1 Like
7

Let’s make it easy to connect and operate multiple vehicles at a time with Avahi!

For those who don’t know.

Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. It allows multiple devices to come online to a network, check the network for other devices with the same ID, then publish with a unique ID along with additional info to connect to the device. This could allow for a zero config auto to connect to QGC.

An example: I had 10 muticopters. All identical. All flashed the same. All connected via a mesh radio or WiFi network. As they powered up and connected to the network, the Avahi service would search for other devices on the network using Avahi. Check the Avahi name of the devices. If the same name existed, it would auto increment a number to the end of the name.
In QGC a list of the muticopters using Avahi would publish. You could select a muticopter and control, or config.

Avahi configuration is structured in an XML file. It’s easy to add addition data in a hierarchy. (IP and port for mavlink, mavlink id, video stream ip and port, video format, vehicle type, color, unique readable name, and so on…) could be easy to expand over time based on user experience.

Can be used with static or dynamic IP address.

Needs to run on some kind of processor like a jetson, pi or snapdragon on the vehicle. (Already exists in the modal ai image). Don’t know if it could be ported into px4…

Would need to make mavID updatable on the fly in px4.

That’s what I would like… but I’m not sure if I would be the only person out there.

8

Voice, at least announcing battery voltage.

For example, with Ardupilot/MP in Windows it is possible to launch several MP instances (one per vehicle) with different voices assigned, and hear battery voltage of each with a different voice (and sysid) along the flight.

9

I would like to see a Servo/Motor screen where I can set the function of each servo output on the autopilot. Similar to the “Servos” screen on MP. Could be a standalone page - or just added onto the current Motors page in QGC. Would really help in setting up payloads and fixed wing aircraft on ArduPlane without having to delve into the parameters page. Thanks!

Also - the ability to send PWM values to certain outputs (such as servos) through QGC would be great! Maybe on the same page as Servo/Motor?

10

An improvement on the UI. I’m new to drones and QGC, and I really appreciate all the work and hours you put in to give us the software, but I feel we need to improve the UI.

I feel that a minimalist UI with less items on the screen (the items to be launched by clicking on buttons that will be placed all over the edges of the screen) would look neat, light and modern as opposed to what we currently have.

11

Hey everyone thanks for dropping a comment, and while I appreciate all of it, I want to set expectations right, we are not looking for new features to implement at this point, the maintenance team has enough on its plate for the foreseeable future (although we will create a wishlist to track your submissions).

The intention of this post was to track any incoming PRs so we could plan accordingly for the next release (v5.0), essentially calling for any developer with a near-future contribution, or a PR waiting in the queue.

12

Thanks for the feedback @Brendan, the biggest thing for us is updating gstreamer, but that won’t work with Ubuntu 18, which means we are stuck in a bad place, as it stands if we want to leave Ubuntu 18 behind we need to update to at least 20, but that requires Qt6 (and much more). It’s still an active conversation.

13

I suggested a PR with small fix for the Vibration page (Analyze → Vibration), as it showed no values in the bars (drawing white on white), and no numerical values.
Fixed that and adapted bar drawing to make it similar to MissionPlanner view -

14

I think it would be good to complete this feature so that it can be officially supported by QGC.

It would be nice to add a function to transmit the current location of the vehicle at intervals to support RTK-VRS in addition.