Open DonLakeFlyer opened 4 years ago
DonLakeFlyer
commented
4 years ago nor will they always be in expected positions, but sorted by “last added/changed
Yeah that is monumentally crappy.
There is no analog presentation of IAS(or GS) and altitude in the AHI.
@AndKe Can you explain what this is?
AndKe
commented
4 years ago @DonLakeFlyer "no analog presentation of IAS(or GS) "
This is the main AHI (artificial horizon indicator) of QGC:
It does provide basic pitch and non-quantified roll information.
Here are some examples of a PFD display:
Please observe the Left side vertical scrolling display of IAS (indicated air speed). - we may also have the standard "bugs" for stall speed, overspeed etc based on paramters. Then, please observe the right side vertically scrolling indicator of speed.
This are the maybe the most important instruments all in one place, imagive you fly by a joystick, as you turn, you watch the bank angle, and have perfect at-a-glance impression of the speed and altitude during the turn.
IAS= indicated air speed (based on pitot) , or GS=Ground Speed (lateral GPS-speed)
You monitor a flight and expect a flight level change, the RPAS should climb, you can easily see whatever it climbs nicely at a normal/expected rate - because of the smooth travel if the altitude indicator.
The "analog" feel does that.
Without that, the plane approaches a mountain range and is expected to climb over, you see pitch increase, throttle go up, and then you start reading altitudes, and estimate in your head whatever the numbers increase by a expected amount every second, or not..
I will use this opportinity to ask for VSI indicator right away too :) I know that the update rates of the telemetry are not very high, so it is required to do a little inter/extrapolation from the recieved data to make those gauges behave well.
Antiheavy
commented
4 years ago Then, please observe the right side vertically scrolling indicator of speed.
@AndKe I think you may mean the right side is typically altitude? Here is a mock-up I did a while back for an altitude indicator:
Edit: here is another idea that has speed too (hopefully a better graphic artist than I could make something really nice looking):
For what it's worth, I think Altitude is critically important information and should always be shown to the small drone pilots. In QGC one can see the vehicle's position on the map and even roughly how fast over the ground it is flying by how fast it flies across the map, but there is no good visual context for altitude. Here is an open issue post I made a long time ago: https://github.com/mavlink/qgroundcontrol/issues/7035
Speed indicator would be the second most important value to always be show to the user (airspeed if available, otherwise ground speed). In my opinion, after that we ride the slippery slope of more and more "great" data to show the "pilot" and we quickly override the ability of a typical small drone user to bother looking or understanding.
The PFD "standard" is okay, but I'd argue for the vast majority of small drone users, a highly simplified and understandable approach should be prioritized. It is possible to have a highly simple (cartoony) PFD.
For what it's worth: I'm an advocate against things like 6-pack displays, overly complicated PFDs, and other possible "instrument" visualizations unless they are turned off by default (optionally enabled by those that want/need them).
AndKe
commented
4 years ago In aviation, there is a huge focus on the readability of instruments, also that the information should be easily accessible in related clusters, hence the classic PFD.
While I do understand it can be "scary" to new users, once they learn it, (nobody is forced to take in all the information at the same time in the beginning) it is unbeatable.
One of the main thing one learn in aviation is "fly the plane" - hence PFD, that shows all necessary information to stay airborne as speed is well marked with min/max,attitude,sink/climb rate.
While reading a number representing speed is fine, especially the new pilot, not to say a stressed pilot, will gain much more information and have a better chance to act accordingly when seeing a proper speed-bar that at-a-glance shows stall speed and overspeed by color, and even safe flap-speeds.
This said, if anyone will keep simplified instruments as an option, or en/disable certain parts.. that's ok too.
dogmaphobic
commented
4 years ago In aviation, there is a huge focus on the readability of instruments, also that the information should be easily accessible in related clusters, hence the classic PFD.
That's true if you are building a ground station for the Predator. For the type of drones we're talking about, people are accustomed to something more like this:
The whole idea behind allowing custom UIs to be built was to tailor it to a specific target audience. QGC on its own can at best, be a generic tool. These new (custom) UIs could easily be implemented and pushed to QGC. You could then at build time, decide what UI you want. The problem I see is people going out, forking it and never contributing back. That gives me little to no incentive in continue working on helping customization.
AndKe
commented
4 years ago @Antiheavy looks good. @dogmaphobic if having decent instruments that resemble aviation standards is a bad thing, then AP2, MissionPlanner, and many others did go very wrong.
If Predator is a requirement to have higher and better UI ambitions than toys from DJI, then the RTK support and advanced survey tools should be removed as well ...in the spirit of "professionalization is bad", and the spirit of "people are not accustomed to" (RTK, ADS-B or good background maps with elevation info.. are not things DJI people are "accustomed to")
Look for what is ICAO is working for, professionalization, we are heading towards a time where more and more of us needs LAPL or PPL or at least the theory part to operate from an airport, or in controlled airspace. The CAA is integrating UAV's into normal airspace and expects us soon to handle radio comms like anyone else, have ADS-B info/transponder and so on.
"The problem I see is people going out, forking it and never contributing back" If there were a system where more of it would be achievable for average amateur programmers, you would not have this problem or at least more contributions.
This is why I requested a plugin/widget feature where one could easily program and display things based on r/w access of all params & telemetry.
If that existed, people could contribute "plugins/widgets" that handled many different needs.
As QGC is today, there is no natural place to hack in a "flaps setting warning" or that would be less than perfectly well programmed and useful for all.
DonLakeFlyer
commented
4 years ago then AP2, MissionPlanner, and many others did go very wrong.
The target audience of QGC and the focus on ease of use is radically different than either of these two products. So if they were trying to achieve the same thing QGC is trying to do, then I would say yes they did go very wrong . If flying a drone safely continues to be rocket science and requires rocket science instrument clusters to match then the industry as a whole has failed as far as I'm concerned. The reason I started on QGC in the first place was to try to help prevent that from happening.
AndKe
commented
4 years ago @DonLakeFlyer I almost respect you too much to disagree, but just almost :)
Those "rocket science instrument clusters " give a very quick and good undestanding of the situation, very quickly. You say something that I understand like: your goal is to provide a simple and safe flight monitoring.
As is, QGC provides the basics, for a basic quadrotor or traditional heli, where only some EKF warnings may be of interest, and if something fails, well. then it crashes ... done.
I wish the smooth planning & interface of QGC were a tool for more advanced pilots/aircraft too, those who want to discover icing before it brings down the RPAS, those who need to know whatever redundancy is being used to keep the RPAS in the air, right now, I feel that current approach is like those examples below:
1 "Have a safe flight, but if your servo rail voltage tends to fade as you deploy flaps, or in some maneuvers, you do not need to care about that.. the bad servo did not permanently overload the voltage regulator...yet."
2 "Have a safe flight, did the engine drop to 100 RPM? - you are free to discover that later, when you read your altimeter number, or later when you lose telemetry due to too low altitude - you could have been warned at good altitude once the RPM dropped, but try to have a safe landing now."
3 "did the vibrations on your quad suddenly increase? - no problem, it is still hanging together, you WILL see that there is a problem when the propeller disintegrates fully, even with basic instruments. "
In the end, happy endings depend on flight monitoring, eighter automatic, or by a human that is provided with the tools to avoid disaster or reduce consequences of failure.
DonLakeFlyer
commented
4 years ago I would say that that those sort of things should be dealt with in a way that isn't done through staring at a pile of values or graphs on the screen. In some cases that may be the solution, for example a graphical altitude indicator. Since that is an indication that covers a pile of problems. But in most cases I think it would be better served by the ability to monitor these things as safety checks on the vehicle. Just like the vehicle is in control of auto-RTL when the battery drops beyond a level. That sort of thing. And then if it really needs to be done at the gcs then it's more like being able to setup up your own warning levels for telemetry values which then tell you when they go wrong. As opposed to always having to stare at them.
QGC were a tool for more advanced pilots/aircraft too, those who want to discover icing before it brings down the RPAS
That's a bunch above the target audience at this point.
AndKe
commented
4 years ago "And then if it really needs to be done at the gcs then it's more like being able to setup up your own warning levels for telemetry values which then tell you when they go wrong."
exactly, hence the plugin system request, where user can add plugin/widgets that have access to parms & telemetry data, and can process it, and visualize/do audio feedback as needed. Such plugings "RPM / throttle demand montitor" or "vibrations monitor" could be community maintained & contributed.
DonLakeFlyer
commented
3 years ago The new instrument panel stuff is a step in the right direction
aplotskin
commented
3 years ago Apologize if this is addressed elsewhere but, while I like the newer instrument panel in a lot of ways, it being separate from the AHI is a choice I don't understand. Can at least an option be offered to keep them together? Those both need to watched closely and it's kind of impossible when they are top right and center bottom of the screen.
patrickelectric
commented
3 years ago @aplotskin this is what #9778 does
aplotskin
commented
3 years ago @aplotskin this is what #9778 does
Excellent, thank you.
czarnajama
commented
2 years ago 1. I really, really wish there were a proper PFD HUD for QGC, as there is in MP. I very much want to use QGC under Linux, since I'm also using 4G/LTE UAVCast Pro with on-board RPi Zero 2 W, and I use Linux for everything. There used to be a PFD for QGC, and APM has one. I think that the standard PFD layout should be familar to many people now, it's part of the culture (all those "air Accident Investigation" etc. films on TV, flight sims, Youtube videos and so on). With digital FPV imaging, it's so much better to assemble the HUD display in the GCS computer and not in the flight controller OSD as for analog FPV, with the PFD overlaying the FPV video. 2. I would love to have the Joystick Enable function, which transfers control of the aircraft from the RC channel (e.g. ELRS) to the MAVlink channel (4G/LTE), mappable to a switch on the TX and/or "joystick". Doing it on the GCS PC via a mouse click while flying is a pain.
czarnajama
commented
2 years ago It seems the lead developers of QGC don't want a proper PFD HUD, saying it scares off novices... It could be made optional, with every element optional and configurable, as on typical OSDs. QGC used to have a PFD. I very much regret I'm not in a position to develop one myself. P.S.: One way to make it more "friendly" is to have the option of Western or Russian artificial horizon. In the Western one, the model reference stays put, the horizon tilts just like the real one seen outside or through a fixed camera. In the Russian AH, the horizon stays flat, the model moves. The Russian AH is by far the more intuituve one especially for models, but then the user may want to develop the reflexes for IFR flying on crewed aircraft, and that means the Western AH. (Pilots who first trained on old Russian aircraft have crashed Western airliners due to confusion and reversion to old skills under great stress...).The PitLab FPV system, a very good Polish product, has a Russian-style OSD option (Zbig sells a lot to Russia...). PS: I see that the Mission Planner HUD PFD has a Russian-style option.
AndKe
commented
2 years ago @czarnajama "It seems the lead developers of QGC don't want a proper PFD HUD"
I think you diagnosed the issue perfectly. I've been nagging for proper flight monitoring tools myself years ago and realized that it is not really wanted. Unfortunately, anything more than simple hobby use is unwanted, as proper/(efficient) parameter settings are missing too.
The only good thing that will come is the terminal access, but without proper flight monitoring tools, you still need to use other GCS for decent situation awareness.
czarnajama
commented
2 years ago @AndKe "Unfortunately, anything more than simple hobby use is unwanted, as proper/(efficient) parameter settings are missing too." This surprises me, because I thought QGC would be a more professional GCS than, say, Mission Planner, since it can run natively under Linux. For me, Mission Planner's restriction to Windows is an impediment.
AndKe
commented
2 years ago @czarnajama - yes, mee to - I dislike involving windows in anything flying, or anything that is expected to work when I travel to some other place to do a job. Also, MP is a one-man-show with fresh bugs when you least expect them, and some crashing - it's limited to windows because of the ".net" framework (programming for those who can't and do not need speed) .
QGC has several very professional aspects: A very neat mission drawing interface, very nice "plug and play" RTK support, and so on, however - it lacks in the mission monitoring department and fast/easy parameter editing. For example: changing failsafe configuration based on flight phase, is still best done in mavproxy or AP2. Graphing is not as nice as AP2 ,and several actions make them disappear, but it is a good step in the right direction.
ES-Alexander
commented
2 years ago As a Sub user this isn't something I'm hugely invested in, but I'm curious what the thoughts are on something like DJI's PFD, as presented in this blog post. It seems to have been kept quite simple, while at the same time providing key flight telemetry in visually meaningful ways, instead of just as numbers.
More generally, here are some thoughts on the current state of affairs, and the discussion here so far :-)
From what I understand of the discussion here, it seems that there's a somewhat important use-case distinction between
In the "pilot" use-case, the interface goal is to provide vital information as efficiently as possible to the pilot, to help keep the vehicle suspended and enable them to avoid crashes. A PFD-style view can be very helpful for this, because losing some central video space is a reasonable trade-off if it makes the vehicle easier to fly.
In the "operator" use-case the focus is more on where the vehicle is (the map, waypoints, and flight path), and what can be seen through it (video stream), rather than actively preventing it from crashing. In this case, the telemetry is valuable for monitoring vehicle health, but front-and-center flight-vital telemetry that's covering part of the video stream is problematic - it likely provides little benefit to the operator, but costs some of the primary 'deliverable'. The "vehicle health" aspects for this style of control are expected be recognised (as "safety checks") by the vehicle firmware (which would generally notify the operator), and are sometimes/often also handled by the firmware (e.g. by compensating for the issue, or landing/surfacing safely).
Of course, in real life usage there's more of a spectrum than a clean distinction between those use-cases, depending on firmware/vehicle capabilities, as well as to a degree user preference.
As I understand things:
*Having looked a bit into the existing UI configuration options, it seems like there are some docs on fly view customisation, and there's been some work on a widget system, but there's seemingly no side-loading support (I'm not sure how difficult this would be to add - possibly very), and the "Custom Command Widget" page in the Developer Tools apparently doesn't exist (not sure if #5438 just never got completed, or if the link has since been broken or something).
Some comments from @AndKe:
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.
Sorry if I were a bit harsh. Best Regards André