Upon request of @Naterater the posts were moved to a new topic
Thank you for the clarification. I also hope that my stance can be clarified a little. It’s no doubt my stance on how MP should be improved, however I do not blame anyone or hold anyone here accountable. I’m not demanding that anything be dropped or re-prioritized, I can only suggest. I do, however, expect some communication to know what’s going on and what’s being planned. That helps me and everyone expand and focus their efforts without waste. If I go fully document MP right now, and then in a month it goes through this awesome change, you might see that everything must be re-done.
I think it would be great if there was more focus on finding more resources or personnel to support MP. I hope that @proficnc follows through and MP is actually focused on, but I still don’t know. Just like an unstable market, there’s little certainty without communication, and the volatility doesn’t make it attractive to invest (contribute). I don’t know if there is/was a search to have more people help on MP, and it didn’t really appear on the roadmap.
I think that we already discuss the MP makeover many times and each time we don’t manage to agree on something.
To be honest, I don’t like it for 3 reasons : C#, not really cross platform, and a big mess inside its codebase…
Instead of a makeover, I would really love a clean new GCS that people can easily contribute too… But as always, that is not the same amount of works and knowledge (without speaking about the transition for user and branding or commercial mess)
Sorry, @khancyr I splitted the thread upon request of the original poster. Perhaps, if you feel appropriate, could you repost this message to the MP thread?
edit:
I splitted again here, per request of the requester 
1 Like
@khancyr that is invaluable information related to this thread. You appear to know what’s going on a lot better than most of us. Said another way, I’m hearing that it’s more worthwhile to start new than improve MP. Is that correct?
Is it really that much effort to change GUI’s?
Yep, that is my opinion. But as always, not everybody share the same point of view.
Moreover, the task to make people accept a lot of change at once is a real challenge… You can see that with chibios for example! People complain that it is a waste of effort, suddently find issue due to chibios(without reason), etc. Or you can still see people using old apm2.5 board…
Creating a new gui will be costly and need some guys that know gui development but should be a huge gain in future.
Agreed, I think it was a strategic mistake a long time ago not to support qgc but continue with a windows software.
100% agree with you
Corrado
We do support QGC.
As a little history, APMPlanner2 started out basically being a new UI over QGC, as users (at the time) preferred the Missionplanner interface. Both APMPlanner and QGC are valid cross-platform options (as is MAVProxy).
I think there’s merit on having options for users. QGC is the option of choice if using iOS.
2 Likes
If this is the route that we end up going (QGC for user friendliness and cross-platform), then I’ll put more effort toward it instead of MP. I just really love MP features and wish it could really shine for everyone.
I can’t use qgc because it doesn’t support rc override so i can’t use joystick with it. It does support manual but arducopter doesn’t support buttons in manual.
You could always ask for that feature over there: http://discuss.px4.io/c/qgroundcontrol/qgroundcontrol-developers
Already did, they say it is arducopter that should support manual including buttons and i already asked here if it is possible to work with them to solve the issue but never got anywhere.
It looks like even is Ardupilot supports manual (for joystick) it doesn’t release the button usage, so if you try to configure joystick in QGC it says buttons are reserved for firmware.
Hello,
@anon67614380 could you open an issue about that on ardupilot github. It shouldn’t be long to make a an AP_Virtual_Joystick class that implement and handle both rc_override and manual control.
Ok done. Hope will work
I dunno. Maybe I am biased because I’ve used MP for a long time, but I don’t see it in its current form as needing a complete rewrite or makeover. Sure its not perfect and there are definitely a few clunky things, especially the control-F advanced or beta items page that could benefit from it’s own tab, perhaps some sort of ribbonized UI would also help navigate better.
But I also wonder if some of MP’s criticism comes not from MP itself, but from the inherent complexity of Ardupilot, (and as such is not MP’s “fault”), unavoidable imo because of its power and its aim at both the casual user and high end professional alike. Which explains why there are close to 1,000 parameters, many ways to connect, etc … But on that point I have yet to find a copter than won’t fly nicely (perhaps not “perfectly” without some autotune and tweaks) keeping all defaults values, and after just a few clicks in MP. In other words completely ignoring all advanced functionality where MP may get, well, complicated. And that for any kind of cheapo HK’s plastic frames with cheap motors/escs/props etc …, to 20kg octos with 30" props and 80A escs. (Heck, I even won a bet once with a friend (stupid bet in retrospect, admitedly, but I won, lol) flying an 8kg octo with a missing prop, and then no missing prop but one installed backwards. All on stock settings, and again after only a few setup clicks in MP). Hard for me, therefore, to fully agree that MP requires a complete makeover from it’s current form.
Another consideration that might be germane to this discussion is the opinion that a makeover will always leave something to be desired, and while it could benefit some users, it won’t others. If you don’t believe that come up with one program, or OS for that matter, that doesn’t have many perceived flaws by many. Win 10, MacOSX or Linux in any of its incarnations, desktop environments, etc … MS office suite, Adobe products, etc … Remember the first time you used Photoshop or Gimp, 3DS Max, or for that matter even something like Excel? etc …? Felt a bit lost if you didn’t seriously study documentation? Ramp up time? And even if you are an expert now, are you really fully satisfied with it’s UI? If you are, I’ll bet there’ll be a slew of users who will tell you the exact opposite.
In summary this is not a plea to keep things the same but a word of caution that any drastic makeover may very well end up pleasing some, yet alienate others. With the net result, after all the work, being a wash. Also explains why, as you say, “we already discuss the MP makeover many times and each time we don’t manage to agree on something” 
3 Likes
Just to make my concept clear what i mean is that QGC is miles ahead of MP in user interface. I am not using it just because it misses rc_override for joystick use (QGC supports manual wich is not supported by AC).
I am not talking about parameters and setup stuff, just user experience at the field or during professional use.
Don’t know if i am the only one thinking it.
Another GCS to consider if MP is not your cup of tea is QGroundControl. As James mentioned it’s fully supported by Ardupilot and vice versa, with several dev team members often working with its author.
It only misses a (very) few high end MP capabilities (like FFT or support for some Geospatial Data Formats) yet has a different UI and works very well for even the most hardened pros or high end users. It’s also a breeze to install, and works on everything, Win, Mac, Linux, Android, IOS.
On the subject of ease of use and UI and some comparisons seen elsewhere, it seems most are not applicable. I don’t have much experience outside of Ardupilot main GCS, besides DJI and Betaflight. (not INAV). But I think any reference to DJI or other platforms like INAV are misguided. Sure DJI is easy to use, but we are talking a GCS targeted at one specific vehicle, specific hardware, radio, etc … So of course it’s easier to use, because the GCS doesn’t have to support anything else. Nor does it support perhaps a quarter of advanced functionality that MP and Ardupilot offer.
Likewise Betaflight, say, with support for a few flight modes, nor, well, mission planning, basic or advanced. And btw while the betaflight UI is good and simple imo when things work, it’s just as much a pain to deal with as MP when things don’t go according to plan. I am sure anyone that had to deal with zadig and obscure device drivers will agree. In other words perhaps some of the gripes against MP are just the result of the inherent complexity of drone “communication”, and can’t be avoided no matter what the GCS is.
One last opinion, if you’ve read this far, sorry for the length … One area that would result in the greatest bang for the proverbial buck for MP is documentation. There are just too many undocumented features, too few use examples, etc …, and that just adds to the perceived clunkiness and complexity. As an aside, how many of us know that the HUD can be detached, just by double clicking it? (I found out completely by chance). Or that MP can run (with mono) on Linux with just a few limitations?
This is one area where lots could be done imo. And where the community can definitely easily contribute.
2 Likes
I’d like to second @OlivierB on considering QGroundControl. I think a problem is that the main ArduPilot devs tend to view MP as the canonical GCS, so any new ArduPilot features are usually catered for in MP first.
To those who are currently using MP, do the community a favour and try out QGC. If you find it is missing features you need, or documentation is unclear, create an issue here https://github.com/mavlink/qgroundcontrol/issues .
2 Likes
Honestly that’s all I think needs to be done for the makeover - a little UI work that doesn’t touch the functionality - it just helps all users navigate better. I don’t think the scale of this “Makeover” has to be massive. To me, a makeover is adjusting a few little things here and there (applying makeup, plucking eyebrows, etc.). Not a total reconstruction or recreation (plastic surgery).
I can understand and attest to this because a lot of the developers say that ease of use falls on GCS makers because they handle User Interface. Ultimately I disagree that any of these firmwares are that complex. There are about 20 parameters on each vehicle that need to be explained/tuned to get solid performance. ONLY 20. After that, there are tons of extras that enable awesome features, but unfortunately those extra parameters are burying those 20.
I think it should probably be a goal for ardupilot to identify those top parameters so that GCS creators can make use of them. The Mission Planner Tuning wizards get most of those parameters, but there are still some missing. Making the those parameters easier to identify/modify should be step 2 to the makeover in my opinion. First should be getting the UI and organization adjusted to make sense.
This doesn’t need to be dramatic - however it does need to be intuitive. I remember the massive MS word 2003 to 2007 UI changes where everything moved into a ribbon. It didn’t touch functionality. At that moment, it was a wash, however 12 years later it was definitely for the best. I think it’s time for Mission Planner to evolve like that (even if everything in the background is done the same). If it’s done right, I don’t see who will be alienated. Maybe we could talk about what NOT to makeover to avoid alienating users.
1 Like