Mission Planner "Makeover"

Ground Control Software Mission Planner
121

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” :wink:

3 Likes
122

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.

123

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
124

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
125

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
126

This is totally inaccurate. No one project is catered to over another. That’s not how this OS community works. They are each maintained by project leaders. MP just happens to have @Michael_Oborne who is pretty stellar at pushing out changes and patches quickly.

3 Likes
127

Sure, so support shows up in MP first, like I said. MP has a close connection to ArduPilot, while QGC is more agnostic. What I mean is that if you look at the development discussions on ArduPilot features requiring GCS support, there is usually a push by the ArduPilot developers to get the feature into MP, as that is seen, probably correctly, as being the most commonly used GCS.

128

It’s quite accurate - MissionPlanner is closely tied to Ardupilot and seems to be the primary GCS of the lead copter developer Randy so has historically had the top tier support from Ardupilot - that’s not a secret, nor is there anything wrong with it. Apm_planner2 is essentially dead (sadly), and Mavproxy is of course continuously developed and improved but being text/console based has a limited audience. Qgroundcontrol is part of dronecode (px4) project and historically does not appear to have had the same level of support/cooperation/interaction. There are no doubt good reasons for this - political, license, developers etc but personally I feel it has been a big strategic downside for Ardupilot as a whole.

1 Like
129

This whole discussion is funny because it shows the divide and inconsistency. Ardupilot is closely tied to Mission Planner for features, but totally untied and separate when it comes to UI design and having other devs contribute to it. Maybe that’s because it’s…

One of the reasons that I’m focusing on Mission Planner improvements is because I also see that “strategic downside” of marrying a program that is not tied to ardupilot in any way. Tomorrow they could completely remove support - albeit unlikely, but it’s possible. Ardupilot should at least have some control of their primary GCS. Unfortunately I feel that it’s constantly overlooked.

1 Like
130

Well … :slight_smile:

Perhaps in between imo, but I’d lean on first view.

While QGC was originally a PX4 project indeed, donlakeflyer has taken over for quite some time and is now pretty much the sole maintainer. And he is very responsive with support for Ardupilot and working with dev team, also very good at being “politically” neutral. Note also that QGC is GPL like Ardupilot, as opposed to BSD like PX4/Dronecode.

5 Likes
131

@OlivierB, thanks for your view in detailed feedback, that is encouraging to hear in what areas the various items are addressed.
Just to clarify - with sharing my thoughts on what “trusted” might entail in our context here, the intention was by no means to imply that this is all missing. (Rather it was originally prompted by the question for a high-level roadmap in the “Who are we attracting” post and a perceived lack of a vision - the pointer to the devs vision statement just seemed somewhat slim, as it seems to transport more of a code of conduct.)

Anyways, that stated aim of being a trusted autopilot definitely seems like a worthy goal, but I felt prompted to think about and lay out some of what this really means to a user/ company when investing in such a system (be that time, money, resources), what the implications are.

As mentioned earlier, I believe to be successful in adding/ changing anything, it greatly helps to first take the high-level perspective into view - WHO needs to achieve WHAT HOW, WHEN and WHERE (with the tools available at Ardupilot).
The answers to these questions will differ to varying degrees, also depending on your user-groups (and who will give feedback, of course). For good steering to happen, I thought it’d be helpful to get a clearer vision of who the target user groups are - or are to be, for long term sustainability - and to then be able to come up with a sharpened focus.
When guided and guarded this way, the outcome of any efforts and funding will be most effective.

It may also help to take a fresh look at the ecosystem from a user’s perspective as a suite of tools, modules which tightly intermesh like gears. Clearly defined, where other “suppliers” can successfully plug into with their solutions.

One outcome should hopefully be leaving a tinkler/ experimenteer image behind, as one more step to becoming the trusted open source autopilot :slight_smile:

1 Like
132

Well it’s still hosted under px4/dronecode github/control, integrated into the PX4 buildchain, and it’s dual licensed to Apache which essentially means it’s permissively licensed like the rest of dronecode. Historically MP has been much closer tied to Ardupilot (hosted and integrated into Ardupilot github) and was used to quickly implement features as they came up because of the existing relationship and the great responsive support from MP. The majority of GCS support/effort in Ardupilot for years went towards MP. This is great, nothing wrong with that, but no point trying to rewrite history otherwise.

There’s been a big step forward in the recent past with qgc compatibility/development with Ardupilot which is great. donlakeflyer seems to be super responsive, which is great. qgc is quickly becoming the goto GCS particularly cross platform. I used to use apm_planner2 which had a lot of benefits but quite a few problems as well, now I use QGC. Several of us in the community have asked several times over multiple years for more support for QGC from Ardupilot project so we have a viable cross-platform GCS, rather than focus on a Windows solution. I used to have to run a windows VM just to run MP, recently I find I have to fall back to that less and less, which is a huge win for the ecosystem as a whole as the number of people running Windows decreases by the day and particularly in techie/gadget circles is probably in the minority by now. Choice is always a good thing, but in Ardupilot case I’m not sure it has been very productive as there has not been enough resources to support the different choices - I feel a combined effort would have produced a better single useful product.

1 Like
133

You probably know this already but just in case, or for others. No need for windows VM on Linux to run MP, just install mono and copy from windows MP. (Yep, needs to be documented …)

Here’s a screenshot of MP, Mavproxy and QGC all happily coexisting on Linux :slight_smile:

screenshot
screenshot1920×1080 536 KB

4 Likes
134

@fnoop QGC is effectively only permissively licensed if you have a commercial Qt license. If you compile with the free version of Qt, it can only be done as GPLV3.

135

Are you sure about that? QT is LGPLv3 not GPLv3, and if it’s dynamically linked then shouldn’t be a problem anyway.

136

https://dev.qgroundcontrol.com/en/contribute/licences.html
In general Qt is LGPL, but some modules are GPL. It’s a bit of a maze.

137

How is your experience with Mission Planner on Linux via Mono? I’ve got this solution ‘basically’ working on my Ubuntu 18.04 machine. MP can connect to my FCs and to the SITL simulator. Log download/graphing and Mavlink inspector are not working at the time of writing.

Responding to the general problem of Mission Planner Makeover, imo one meaningful step to take is to break out some of the less readily visible features (which also tend to be less well documented), such as the Ctrl-F page.

QGC is probably only limited by two factors: No motor testing tab, and very rudimentary mission planning features. Improving its mission planning interface might make it competent for basic use with Ardupilot.

1 Like
138

@proficnc, do you have any updates on Mission Planner’s progress or outlooks? I’m sure many people are excited to see what can happen with full-time dedication!

1 Like
139

We will be keeping things under wraps till we are ready to release our plan. :slight_smile:

140

What a thread. Tried to get through as much as I could.

I am one of the people that makes a monthly standing contribution to Ardupilot. It is only $5 but with NPR, NYTimes, WAPost, Guardian etc it all adds up.

It is pretty crazy that one person has managed to stay on top of Mission Planner and make it such a feature rich application. Glad he is getting a pay-check now.

I have one observation that I think is pretty true – people value what they pay money for. Has anyone ever figured out how many active MP users there are? Why not introduce a subscription model of $5 a month that offers cloud storage of flight logs, log analysis tools, and also allows data to be mined that allows developers to get feedback. There could always be a free version. This may develop a steady stream of revenue that could allow continuous development. You could also have a Pro version that would be quite a bit more expensive. If some $$ was kicked back to Ardupilot I would think this could work.

2 Likes