Mission Planner "Makeover"

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

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.

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

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

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

@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

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

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:

4 Likes

@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.

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

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.

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

@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

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

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

It would be worth it for me.

1 Like

Why not have an annual subscription service of $30 per year that allowed you to download the latest compiled version free. The sources could be on Github for anyone that wanted to compile their own – how many people would not happily pay for this? And would we even care if people griped?

I wonder how many users of Ardupilot and Mission Planner ever pay a single $1 for developer support. It is human nature though as we have not provided a mechanism for them to support it.

In general I think paying a small subscription fee for the convenience of prebuilt binaries for Ardupilot and Mission Planner would be a very fair way to get some steady funding to pay for overheads without undermining the open source nature of the project. Build instructions and could still be there for anyone that wanted to compile their own binaries for free. I mean who would not pay for this convenience? The average FPV plane costs $600 to $1000 and many people have multiple planes/copters. It is an expensive hobby.

1 Like

And this concept in no way goes against the open-source concept. Many of the Linux flavors make their living off value add services.

1 Like

I’ve always thought 3DR made a major strategic error not doing a ‘redhat’ of the drone world, providing a supported, stable, compiled firmware level.

1 Like

If someone wants to maintain it, sure! I however do not think that it should use the Ardupilot name. I think that programs maintained under the Ardupilot name it should be free. Welcome to the ArduPilot Development Site — Dev documentation

1 Like