Enhance battery indicator visuals with new SVGs and color coding #11881

Paschalis · 2024-09-15T15:16:21Z

Added new SVG images for different battery levels: Critical, Low, Orange, Yellow, YellowGreen, and Green.
Updated QGCPalette to include color definitions for these new states.
Modified BatteryIndicator.qml to incorporate the new visual elements.
Updated the resource file (qgcimages.qrc) to include the new SVG images.

The following GIFs demonstrate the changes:
Before:

After:

Or you can click on the videos below to see the changes:
Before: before.webm
After: after.webm

zdanek

I like it very much. Gives a nice fresh touch and it's more informative.
One thing, are shades of each colors same / according to existing palette?
At recording they look a bit like from shifted shades palette, not similar to what we have now.

Paschalis · 2024-09-17T18:43:26Z

Thank you for the feedback! To maintain consistency with the existing palette, I used the following predefined colors from QGCPalette:

Green: qgcPal.colorGreen
Yellow-Green: qgcPal.colorYellowGreen (#9acd32) – added to the palette
Yellow: qgcPal.colorYellow (#ffff00) – added to the palette
Orange: qgcPal.colorOrange
Red: qgcPal.colorRed

I’ve now updated the code to use qgcPal.colorYellowGreen instead of the hex value directly. The SVG images might appear darker due to their design, but they follow these updated palette colors. Let me know if any further adjustments are needed!

Light:
light.webm

Dark:
dark.webm

TSC21 · 2024-09-17T18:45:12Z

@gillamkid FYI

zdanek · 2024-09-17T18:50:26Z

@Paschalis dark mode is great. But in light mode, those yellow, green and orange are hard to read.
Don't take it personally, let's look for best solution.

What about black border? Or something else?

We are very close 😊 Can you experiment with something that will allow icons to be visible on white background, in full sun? Remember that often people use QGC in the field 😅

Paschalis · 2024-09-17T20:50:15Z

Hi @zdanek ,

Thanks for the feedback!

Using darker colors will improve readability and contrast better than adding a border. Since the other indicators don’t have borders, adding one only to the battery indicator could disrupt visual consistency. Darker colors will maintain design uniformity and enhance visibility in bright conditions.

Light.webm

DonLakeFlyer · 2024-09-18T01:15:11Z

In general coloring text like this is a bad idea. I just makes it too hard to read in direct sunlight on things like a Herelink or tablet controller. The icon coloring is great. But I'd leave the text color alone. That is optimized for sunlight readability.

DonLakeFlyer · 2024-09-18T01:20:02Z

My other concern is the 80/60/40/20 coloring breaks. I seem to remember QGC having a talking battery warning ages ago with breaks like this and it caused concern. Can't remember if that's still in the code base. I would run that by folks on Discord. I'm guessing the first request will be to be able to make those configurable since different batteries discharge at differing rates. Also I'm guessing there will be questions about how thee values relate to the ArduPilot multi-level warning parameters thingies for battery.

Don't get my wrong, I Iike it. It can just be tough to make most folks happy given the variability of vehicle platforms.

Paschalis · 2024-09-18T06:24:40Z

Hi @DonLakeFlyer,
Thanks for the feedback!

Regarding your concerns about the battery indicator colors:

The current master branch of QGroundControl already uses colors like orange and red for the most critical battery states (colorOrange for low battery states and colorRed for critical and emergency states). These colors are crucial for visibility and alertness in critical conditions. My update introduces additional color thresholds for different battery levels (e.g., colorYellowGreen for 61%-80%, colorYellow for 41%-60%) which are intended to give users a more nuanced view of battery health, particularly in non-critical ranges.

My question is: given that the most critical states already use highly visible colors, why might the upper percentage thresholds be a concern in terms of visibility or readability? I believe that these additional thresholds help in providing detailed battery information without compromising the visibility of the more critical states. The default case in the update still uses qgcPal.text for undefined states, similar to the current implementation.

I completely agree with your perspective. Your approach is very reasonable, and I see the value in making the battery level thresholds configurable. Allowing users to adjust these thresholds based on their specific battery discharge rates and preferences will definitely enhance flexibility. For example, users could change the default thresholds from 80/60/40/20 to more tailored values like 75/55/35/15 according to their needs.

Thanks for your valuable input!

zdanek · 2024-09-18T06:47:09Z

Regarding thresholds, I also immediately thought about users' preferences since, people have their own needs and batteries can be non linear in discharge, so one might want to have own levels to be aware of.

Paschalis · 2024-09-18T12:33:00Z

Light.webm

Dark.webm

I'll proceed with implementing the changes to make the battery level thresholds configurable.

DonLakeFlyer · 2024-09-18T17:42:16Z

why might the upper percentage thresholds be a concern in terms of visibility or readability?

They are only a concern with visibility/readability on the text. The text should not be colored, the icons are fine.

which are intended to give users a more nuanced view of battery health, particularly in non-critical ranges.

As it currently stands QGC shows:

Text color when the battery is reported as MAV_BATTERY_CHARGE_STATE_OK
Orange for when the battery is reported as MAV_BATTERY_CHARGE_STATE_LOW
Red for when the battery is reported as MAVLink.MAV_BATTERY_CHARGE_STATE_CRITICAL and worse
The battery state at which these transitions occur is controlled by the firmware through various parameters.
I think ArduPilot even allows this setup to be different on each individual battery
The parameters used differ between firmwares
Using PX4 as an example the default setting for low battery state is at 15% and critical is at 7%. So the battery color will turn orange at 15% and red at 7%. These settings are global to all batteries

With this new pull the battery display for orange color is hardcoded to the 21%-40% remaining battery range for all vehicles and all batteries on the vehicle. And then red coloring is hardcoded to 20% and below. There is no distinction between Low and Critical states. The hardcoded 20% red trigger sort of relates to mavlink low state. But as you can see in the P4 example, by default it does not match PX4's concept of low battery. It also does not track the vehicles concept of low battery which is configurable.

Although the concept of more nuanced coloring of battery state is good thing the fact that it does not respect what the vehicle considers to be low and critical states is a pretty bad thing.

In order to make this work correctly there needs to be a combination of the two approaches. The telemetry controls the state from MAV_BATTERY_CHARGE_STATE_LOW and worse and the orange to red band of coloring. And then you have a nuanced coloring when battery state is reported as MAV_BATTERY_CHARGE_STATE_OK. The problem is that means you need to know what the percentage is when the transition is made from MAV_BATTERY_CHARGE_STATE_OK to MAV_BATTERY_CHARGE_STATE_LOW.

This would require firmware specific methods in FirmwarePlugin which could report back the percentage associated with the MAV_BATTERY_CHARGE_STATE_LOW transition such that the code can be written correctly. The problem with implementing something like that is that I don't think given the current state of affairs with mavlink and firmware implementations that is possible in all cases. In looking at the parameters in PX4 and ArduPilot it looks like it would be possible for PX4 since the parameters for controlling this are represented as percentages. But for ArduPilot the parameters which control low battery are represented in either milli-amps or voltages, not percentages. Maybe someone familiar with ArduPilot can chime in with some other way to do it?

So it's doable for PX4 but not for ArduPilot. Which then means it would need to be controlled by a supported bit in FirmwarePlugin. We do that for other QGC features which can only be supported by one firmware. So it's not out of the ordinary.

TLDR summary - Can be done correctly for PX4, but not currently (as far as I can see) for ArduPilot.

Davidsastresas · 2024-09-18T21:49:15Z

I second what Don said on the last answer.

For Ardupilot we really would want to get the low and critical values from parameters, and maybe have one additional medium point which could be configurable. But leaving it hard coded or configurable in so many levels is going to be confusing for Ardupilot users, so I would leave this particular to PX4 for the moment, if PX4 friends are fine with it.

I think it would go as creating some new q_properties and getters in firmware plugin and overriding in PX4 firmware plugin, or alternatively creating a whole toolbar indicator particular to PX4 and another for Ardupilot, and move battery indicator from tool indicator to vehicle indicators group ( so we can specify the qml from each firmware plugin instead of being common ).

Thanks!

DonLakeFlyer · 2024-09-19T19:28:47Z

For Ardupilot we really would want to get the low and critical values from parameters,

@Davidsastresas You know ArduPilot better than I do. Do you see a way for QGC to know the battery percentage value for low state given the set of parameters available?

Paschalis · 2024-09-20T19:41:40Z

This update enhances the battery indicator with the following changes:

Battery State Coloring:
- Orange for MAV_BATTERY_CHARGE_STATE_LOW.
- Red for MAV_BATTERY_CHARGE_STATE_CRITICAL.
- Coloring respects the vehicle's telemetry thresholds for PX4.
Function Update:
- The function getBatteryColor() was updated to apply different color logic depending on whether the dark or light theme is used.
- In the dark theme, the function uses thresholds to set color gradients for better visibility, applying qgcPal.colorGreen, qgcPal.colorYellowGreen, and qgcPal.colorYellow.
- In the light theme, a default text color is returned for non-critical states.
New Icons: Added separate battery configuration icons for light and dark themes (BatteryConf.svg and BatteryConfLight.svg).
Configurable Thresholds: Users can now configure battery thresholds.

The following images demonstrate the changes and how users can configure the thresholds, along with GIFs showcasing the battery indicator in both light and dark themes:

Dark.webm

Light.webm

DonLakeFlyer · 2024-09-20T21:18:26Z

Ok, this is getting much, much better. Thanks. Comments:

I still don't think the text for the battery display should be colored. As I said above that just kills readability of the actual values out in the field.
You've got visual indications for 7% and 15% as hardcoded values. In reality you can't show those numbers you can only refer to "low" and "critical" which is I think what you are trying to indicate here. At this point in the code you don't know what the percentage is for low and critical.
I don't quite understand the need for light and dark theme differences in coloring. In reality "light" is meant for outdoor, direct sunlight use. On things like tablets or Herelink type controllers. And "dark" tends to work better out of direct sunlight on things like laptops sitting on a table. At least that's the concept between the two. My take is that if you can find something that is visible in direct sunlight then that is fine for all usages.

Paschalis · 2024-09-21T05:19:26Z

Current Default Master Version: Image and Text Coloring for Both Light and Dark Themes

function getBatteryColor() {
                switch (battery.chargeState.rawValue) {
                case MAVLink.MAV_BATTERY_CHARGE_STATE_OK:
                    return qgcPal.text
                case MAVLink.MAV_BATTERY_CHARGE_STATE_LOW:
                    return qgcPal.colorOrange
                case MAVLink.MAV_BATTERY_CHARGE_STATE_CRITICAL:
                case MAVLink.MAV_BATTERY_CHARGE_STATE_EMERGENCY:
                case MAVLink.MAV_BATTERY_CHARGE_STATE_FAILED:
                case MAVLink.MAV_BATTERY_CHARGE_STATE_UNHEALTHY:
                    return qgcPal.colorRed
                default:
                    return qgcPal.text
                }
            }

Our new Version retains the above approach !

function getBatteryColor() {
    switch (battery.chargeState.rawValue) {
        case MAVLink.MAV_BATTERY_CHARGE_STATE_OK:
            if (qgcPal.globalTheme === QGCPalette.Dark) {
                // Apply the battery color logic only for the dark theme
                if (!isNaN(battery.percentRemaining.rawValue)) {
                    if (battery.percentRemaining.rawValue > threshold1) {
                        return qgcPal.colorGreen 
                    } else if (battery.percentRemaining.rawValue > threshold2) {
                        return qgcPal.colorYellowGreen 
                    } else {
                        return qgcPal.colorYellow 
                    }
                } else {
                    return qgcPal.text
                }
            } else {
                // For light theme, return a default color
                return qgcPal.text
            }
        case MAVLink.MAV_BATTERY_CHARGE_STATE_LOW:
            return qgcPal.colorOrange
        case MAVLink.MAV_BATTERY_CHARGE_STATE_CRITICAL:
        case MAVLink.MAV_BATTERY_CHARGE_STATE_EMERGENCY:
        case MAVLink.MAV_BATTERY_CHARGE_STATE_FAILED:
        case MAVLink.MAV_BATTERY_CHARGE_STATE_UNHEALTHY:
            return qgcPal.colorRed
        default:
            return qgcPal.text
    }
}

Ok, this is getting much, much better. Thanks.

Appreciate your feedback and support !

 *I still don't think the text for the battery display should be colored. As I said above that just kills readability of the actual values out in the field.

The current behavior in the master branch actually changes both the image and text color based on the battery state. My update retains this approach !

* You've got visual indications for 7% and 15% as hardcoded values. In reality you can't show those numbers you can only refer to "low" and "critical" which is I think what you are trying to indicate here. At this point in the code you don't know what the percentage is for low and critical.

The values aren't hardcoded; I'm following the default approach by using MAVLink.MAV_BATTERY_CHARGE_STATE_LOW for orange and MAVLink.MAV_BATTERY_CHARGE_STATE_CRITICAL (and others) for red. The color changes are tied to these MAVLink states rather than specific percentages. However, I can update the display to show

'low'
'critical'

instead of percentage values for clarity !

* I don't quite understand the need for light and dark theme differences in coloring. In reality "light" is meant for outdoor, direct sunlight use. On things like tablets or Herelink type controllers. And "dark" tends to work better out of direct sunlight on things like laptops sitting on a table. At least that's the concept between the two. My take is that if you can find something that is visible in direct sunlight then that is fine for all usages.

I completely understand and agree with the concept you described for light and dark themes, which is why I've kept the light theme the same as in the current master version—using Black, Orange, and Red for both the image and text, as these colors work well in outdoor, direct sunlight conditions. Since no one has raised any issues with the current coloring in the light theme, I've decided to keep it as is for now.

DonLakeFlyer · 2024-09-21T18:01:19Z

So I built and ran this to see what it looks likes. Comments:

Battery coloring from dark theme should be used in all cases
Text shouldn't be colored
The setup for defining the percentages isn't super clear. For examples the icons shown in there don't match what is actually shown in the toolbar. I think something along these lines would be better:
- Basic idea is to show the actual different toolbar icon states with what they mean: 100% - Config 1 - Config 2 - Low - Critical
- I just drew this in Gimp to give an idea. Not fully fleshed out, but hopefully enough to give a directional idea.
- I think it ends up being more understandable as to what is going on

DonLakeFlyer · 2024-09-21T18:04:27Z

Also can you add a note in ChangeLog.md about this new feature?

Paschalis · 2024-09-21T22:27:38Z

Thank you for your feedback and support! All tasks are now complete.

DonLakeFlyer · 2024-09-21T23:16:33Z

Love it. This is fantastic stuff. I'll do a full code review soon.

Davidsastresas · 2024-09-22T09:49:54Z

@Davidsastresas You know ArduPilot better than I do. Do you see a way for QGC to know the battery percentage value for low state given the set of parameters available?

Sure! In order to know the low and critical values for voltage we have:
BATT_LOW_VOLT
BATT_CRT_VOLT

and in order to know the low and critical values for current we have:
BATT_LOW_MAH
BATT_CRT_MAH

and to understand the total capacity of the battery we have:
BATT_CAPACITY

Please note we have a BATTX set of parameters for each battery monitor configured, so all the above parameters will exist for each instance of battery monitor configured.

Considering the above, the logic would go as taking BATT_CAPACITY as 100% battery, and then understand the percentages for Low and Critical from BATT_LOW_MAH and BATT_CRT_MAH.

I don't mind to work on this part for AP, but it would be good to leave it prepared so the widget takes this info from FirmwarePlugin.

@Paschalis that work looks very nice so far, thanks! However, it would be good if you could do a rebase -i, and arrange the commits so we don't have those "merge into master" commits. Whenever you want to rebase, if you do a git rebase upstream/master instead of git merge, your commits will organize on top of upstream/master, instead of having that odd "merge into master" commit. It makes much easier to track commits in a PR. Thanks!

- Added new SVG images for different battery levels: Critical, Low, Orange, Yellow, YellowGreen, and Green. - Updated QGCPalette.cc and QGCPalette.h to include new color definitions for the battery levels. - Modified BatteryIndicator.qml to use the new SVG images and color codes. - Updated qgcimages.qrc to include the new SVG images in the resources.

…eryIndicator to use predefined palette colors

…lors.

…yConf.svg, BatteryConfLight.svg).

DonLakeFlyer · 2024-09-18T16:48:48Z