QGC offer the possibility to deploy a custom build . This allow to:
• Define a single flight stack to avoid carrying over unnecessary code
• Implement your own, autopilot and firmware plugin overrides
• Implement your own camera manager and plugin overrides
• Implement your own QtQuick interface module
• Implement your own toolbar, toolbar indicators and UI navigation
• Implement your own Fly View overlay (and how to hide elements from QGC such as the flight widget)
• Implement your own, custom QtQuick camera control
• Implement your own, custom Pre-flight Checklist
Define your own resources for all of the above
This is my personal release with only APM firmware support .
The style of widget has changed to have transparency on video background.
I added some features for battery monitoring. When we use a power module only voltage e current is present. From battery menu will be possible input the cell numbers to calculate the average cell voltage.
A graph below the toolbar will show the the flight time estimated
There is the possibility to select which type of battery function from Advanced
APM Show the battery percent from flight controller
LIPO battery percent remaining approximation is calculated with asymmetric sigmoidal function (green curve)
Flight time estimate
The calculation is done reading the capacity parameter set on flight controller.
The accuracy depend by this value and is only an approximation ( is not to aim to replace an intelligient battery)
If we start a flight with a full battery charged , the time result may be correct estimated.
If we start a flight with a battery not full charged , will not possible to estimate the time if we don’t know wich value of current remained in the battery
The funcion don’t set RTH and LAND , is only an information
That looks great! thank you for sharing! I’ve been also playing around with the custom feature of QGroundControl, and it is really a pleasure to modify it once you get it. Definitely a great approach from the QGC devs!
Great work, good to see someone adding proper flight monitoring for serious use.
QGC never understood the need for proper flight monitoring.
I hope you can push some of it as PR’s to QGC.
QGC is a great project, but is for generic scope. Depend who is the user , which device and firmware is used. Probably it’s time to fork the project for a specific device as tablet or smartphone. I don’t think the PR could be the solution. If some serious programmer in C++ QT (not as me )love the idea to change the design of the app could be time to start a new project
hi @DomenicoPatella
could you please change app id to try install alongside original QGC
with your build we must remove original QGC to install your build
thanks
Just to make sure everyone realizes almost all of these values are available for display from the instrument panel setup. Not sure what is missing other than estimated flight time which could be added as a feature.
If you do this, then you have a version of QGC which will only work with a specific firmware. To make it generic it should plumb through a FirmwarePlugin implementation. It is already mostly there:
/// Returns the data needed to do battery consumption calculations
/// @param[out] mAhBattery Battery milliamp-hours rating (0 for no battery data available)
/// @param[out] hoverAmps Current draw in amps during hover
/// @param[out] cruiseAmps Current draw in amps during cruise
virtual void batteryConsumptionData(Vehicle* vehicle, int& mAhBattery, double& hoverAmps, double& cruiseAmps) const;
But it is only currently used for custom build overrides to provide battery swap counts for long missions. It could be changed to be implemented to the Firmware specific stuff to get the values. Then the flight time based on battery and draw could become a generic feature.
Also to note why QGC does not do a horizontal value layout as shown in this custom build. QGC is targeted to devices from large to small laptops down to 10" tablets. For all of those the layout is in landscape format. The design point for landscape is to preserve as much of the vertical portion of the screen as possible since that is the smaller dimension. Hence QGC puts things on the left/right edges of the screen as much as possible. To keep the center section clear for video and/or mission item display. Happy to discuss if people think that landscape oriented real estate design point is wrong or not.
Also the toolbar and instrument panel ui at this point is pretty stale and hasn’t been updated in ages. Happy to discuss ways to make better.
As it stands now phone sized displays are not a target for QGC. Although work is always done to keep QGC working on phone sized displays. Effort is not put in to make it less of a PITA to use on a phone size screen. Also keep in mind that on phone sized screens the vertical space issue is even more pronounced. It is certainly possible to make phone sized screens work within the same codebase it’s just too much work to support due to all the ui changes needed to make it work with great usability.
I think that would be a huge mistake. There is already a miniscule amount of resources devoted to making good ground station applications. Dividing up that pie into even smaller bits isn’t going to make things better faster.
Also just FYI, i’m not against the horizontal display thing. Just given the design point I don’t think it should be the default. Happy to accept an optional horitontal display. It should be easy to make one that goes both directions though. That said it would be nice to have updated visuals for both a horizontal and visual value display both of which include customizabilty like currently supported and likely a much better set of default values which display out of the box (which hopefully folks like you can comment on what the set should be for each vehicle type).
But why wouldn’t PR’s be a solution, and the forking idea? I doubt there’s anyone more qualified than @DonLakeFlyer to develop and maintain, and he’s also provided great help. Forking would just dilute the project, ultimately at the detriment of all users, imho.
Most wide-screen displays like tablets and laptops have more horizontal screen space than vertical. Very few 4:3 aspect ratio displays in use anymore.
But for tablets and phones where you may tip the device 90deg to have more vertical screen space than horizontal, I can see the possible advantage of the horizontal panel.
I also have a totally custom fork of QGC developed specifically for helicopters and custom firmware. But I retained most of the original “look and feel” of the app so I can pull from upstream and rebase and it doesn’t break anything.
QGC just happens to be my all-time favorite GCS. It has a very nicely designed codebase, easy to work with, cross platform, can make run on anything (except the build environment for Windows is not all that great).
@DonLakeFlyer as much as I respect the visually great GCS that QGC is, and the great work that is put into it, especially it’s mission-planning:
That was a comment on the simple fact that the author added icons, tried to make that data quickly readable.
I can only hope/guess/assume that he’s overlay stays on more than the the flight display, or is detachable as separate window.
What is my experience with current QGC:
One can select xx items in “big” or “small” size, till all the text is hard to monitor, and it is not easy to see status at-a-glance, nor will they always be in expected positions, but sorted by “last added/changed”
There is no analog presentation of IAS(or GS) and altitude in the AHI.
Things I would see for proper flight monitoring:
1- make the data detachable, or make it stay all the time, if I fine-polish the mission while flying, or change/verify settings at a few stages thru the mission, it is not OK to just remove the vital data
2-add icons and let user control which data is displayed where, for example: for performance/redundancy monitoring, or near icing conditions, one would monitor throttle output and current at cruise.
3- add option to change color based on value: is throttle / vibrations unusually high ? , help it getting attention.
4- maybe one need to monitor RPM or charging, did RPM go to >500 ? rise an alarm ! (request for custom thresholds and alarms)
5- With a multirotor with more then 4 motors - I do see smoothed motor difference , or at least can plot 8- graphs of PWM outputs in another window (Mavproxy, or APMPlanner) - by doing so, I’ll instantly be warned, or just see , that the octocopter are flying on it’s redundancy,and something may have failed.
9 ultimately: all the monitoring data should be in it’s own widget, detachable (as one often moves it to another display) - with user-selected positions , sizes, colors, and … option to plot values in small graphs. Option to plot any mavlink value live (like in APMplanner) - do the throttle fluctuate a bit much or not… just plot and see. User may plot pitch attitude and throttle at cruise get higher the last hour ? -then we have icing.
One wants to have all the data at the fingertips.
@Andre-K Thanks, helpful. This doesn’t solve the value stuff your asking for. But have you seen the new mavlink charting support in daily builds? That might be some of #9.
I put your comments here: https://github.com/mavlink/qgroundcontrol/issues/8332 can I can consider what to do in next release. Folks can feel free to add comments there in instrument and value display for future releases.
)love the idea to change the design of the app could be time to start a new project