Servers by jDrones

Mission Planner "Makeover"


(mike kelly) #81

I think this would be an important improvement to the Ardupilot community. Unfortunately I think the nature of the beast does not lend itself. I think the people who have spent the effort to learn Ardupilot have a significant investment in the community even if they have never “given back”. I think because of this investment, as well as additional time spend helping others, testing code and hardware etc, should justify a “user advisory panel”.

The devs are smart capable people but they live in their own world. GIT is probably a terrific programmer tool but it creates a block for casual user contributions that is significantly reducing the effectiveness of a community with lots of volunteers contributing. As lordneeko pointed out the documentation editing system is barbaric. Something a programmer would come up with.

But to change these things would require a major contribution by a “civilian” to create a better documentation system and to manage a fair but organized user feedback system. Which would not be a minor effort to just bereferee to a large group of users with wildly differing needs. As an example I have zero interest in a change to Mission Planner. I really like it just like it is. But I would really like and need UAVCVAN/UC4H support. I have zero interest in racing drones and think it is a waste of dev time to play in that sandbox. Everyone’s needs are different. Who is going to run the "House Sub-committee on drone enhancements"and advance certain ones to the floor.

Then no matter what users want they may not get it because the resources, both money and people, along with some self interest may get in the way. The development process is, and always has been, influenced by moneyed interests. 3DR contributed a lot in the beginning to make what Chris envisioned happen. So each dev is driven by what they are interested in, what they can get paid to do and then some vague sense of what the whole group of devs think. There are politics internally, as there are in every group of humans, with conflicting interests.

But I personally believe that the commercial world is leaving Ardupilot in the dust because Ardupilot is so focused on porting flight controller code that the usefulness of the eco-system is being reduced. I just picked up a Parrot anafi which at 320g can fly 25minutes in 30 mph winds. HD video to the smartphone on the ground, 4K recording, 180deg pitch gimbal with Mission control and simultaneous rc controller override during missions. Optical/gps follow me on a 30mph vehicle. 3x zoom camera. It can automatically take and stitch 360deg panoramas etc etc

I could not build an Ardupilot based aircraft with anything close to those specs at anything close to the price. A lot of the features would not be possible at all.

My two cents


(anon67614380) #82

I think Ardupilot needs to understand what it wants to be, than focus and develop in that direction.

Now it looks like there is no path to follow.


(Nathan E) #83

I like your idea a lot. I think this would go a long way toward giving the community a voice.

I also see your point here for commercial multirotors. Fixed-wing and VTOL aircraft aren’t in that situation though. There is not one commercially equivalent system that can beat arduplane in my opinion. Parrot is as close as it gets, and their equipment is very closed, expensive, and not adaptable. Maybe PICCOLO, but it’s so expensive.

There are so many AMA folks and similar that fly totally manual RC airplanes where a cheaper flight controller will expand their horizons with what is possible, so I understand and value the porting to more boards. I think the number 1 way to expand to the largest community (recreational flyers) is to make things easier/simpler for them while still being inexpensive. I want to show that community what is possible, and that’s why I think a more user-friendly Mission Planner should be a priority. Most of us that have stuck it through can deal with MP without changing, however I fear that we will lose a lot of people who turn away because of what they view as complexity. I almost feel embarrassed to point new users to mission planner because it doesn’t follow the same logic as most computer programs.

For example, when you open a text editor program, you probably have a few expectations. On the top will be a ribbon or drop-downs with options for text formatting, etc. On the bottom might be a few buttons like zoom, viewing options, etc. The left and right are generally open or where you might find a toolbar or two. MS Word, WordPad, Notepad, OpenOffice all share this generic layout.

Unfortunately Mission Planner doesn’t follow the same generic layout as any other program that I’ve seen. There’s main tabs on top (I can generally follow that), but some tabs switch to have additional sub-menus on the left (Config/Tuning). Some have sub-menus/tabs on a second window (flight data). Some are on the right and bottom (flight planning). Very useful features are in a menu that’s only accessible by Ctrl+F. The main tabs seem to be flight-stage oriented, but post-flight tools are under the VFR HUD. etc, etc, etc. The “flight data overflow” of Mission Planner cited by Intel’s report on GCS’s is something that won’t be helping our new friends.

On a high level, I think Ardupilot should be looking to expand its community to everyone. If I’m misinterpreting the developer mission statement ArduPilot aims to enable the creation and use of trusted, autonomous, unmanned vehicle systems for the peaceful benefit of all., please let me know. To me, Mission Planner is only catering/focusing development on what advanced users need. That’s not “all” to me.

If Mission Planner’s intent is only to be an advanced GCS for advanced users, I don’t see how that falls in-line with Ardupilot’s developer mission statement or the Versatile, Trusted, Open slogan.


(Peter Hall) #84

Maybe we should have a community vote every month or two on issues to be fixed. Could have a ‘top 5’ user requested issues to be fixed in the code, mission planner the wiki, whatever. This would give devs things to work on if something takes there fancy. The autopilot foundation could then put up a code bounty (of some small amount so its sustainable) to get the top issue fixed.


(anon67614380) #85

Maybe there could be a list of topics and the possibility for the users to help with donations, than a dev could pick it up and get the amount once done. Like a list of topics with the total amount contributed to that time, so a dev could decide to dev that point.

Corrado


( .) #86

That’s not really a bad idea.
Right now, there is just the “Contribution of the Month” prize…which seems to be a bit hit or miss, but I think the devs tagging Issues with “Rewards” might get people (maybe even companies) working on some of them. I know people who make a great “second job” living on doing bug bounties. But what we have here is simply “if you contribute something awesome we might remember to vote on giving you a pat on the back”


(mike kelly) #87

I don’t think Ardupilot is at all made for the recreational user. I think it has always been something for experimenters and people who need to do real work. There are plenty of cheap racing quad boards for recreational users and cheap RTF for the selfie crowd. I don’t see recreational users wanting or needing to do complex missions, interface companion computers to do complex realtime analysis or build a submarine. The more complex jobs are where Ardupilot shines. The VTOL aircraft are an example.
So the last thing I want Ardupilot to do is chase recreational users. They can graduate to Ardupilot after they are finished racing or taking selfies.


(Nathan E) #88

Unfortunately this topic has become a hostage of the broader topic here:

Is it possible that we discuss what should be done with Mission Planner and who should get to decide? If it’s ultimately a single person’s decision or a single company decision, I guess I’ll give up and try to document QGC for the recreational community. I’m sorry that this thread has become a battleground for who we want to support.


(Luís Vale Gonçalves) #89

Is there something missing @Naterater ??

https://docs.qgroundcontrol.com/en/

or here ?

https://dev.qgroundcontrol.com/en/


(Nathan E) #90

Yeah. Tutorials on how to set up planes, multirotors, rovers, etc. Basically what Randy does in his Youtube videos.


(Luís Vale Gonçalves) #91

We already have for TradHeli :wink:

But for other vehicles it tends to be harder, because the variety of configurations can be daunting…


(mike kelly) #92

I think who we want to support and a makeover to Mission Planner are indeed closely tied together. The resources of Ardupilot are very limited. It will never be all things to all people. So it is a triage situation. Do the best you can at what you do best. There are lots of other resources out there for the recreational user. But for the advanced user wanting advanced features there is really only one option. Those users pay the price of learning the tools for the benefits they receive.

There are lots of tutorials on Youtube by Ardupilot members. But as Luis pointed out the vast array of aircraft and components, without a reference build would make it darned near impossible to have an official build tutorial that would be of any value because a few different choices and the tutorial would not longer be valid. Developers generally don’t do a good job of documentation and don’t like doing it. It takes valuable time away from their very special skills no one else can do.

The very fact that Ardupilot is used for so many drastically different craft makes the scope difficult to simplify and condense it for the masses.

As I have lobbied for in other threads, until we get a reference build that is pre-tuned and flies well with commonly available parts and low build skills required, I don’t think putting time into a cosmetic makeover of Mission Planner will change anything.


( .) #93

So, I hope the devs in general don’t agree with this statement. Being in a triage situation with a project isn’t the best place to be. It means you’re just constantly putting out fires and never adding functionality. I don’t think that is the case.

I think a better description is simply limited resources are limiting innovation. So the majority of work goes towards bug fixes and a developer’s favorite projects. Not always, of course, but even looking at the developer discussions on getting rid of NuttX, I can see that when someone (or a group of someone’s) make a decision one way, a LOT of development muscle spins up very quickly to make it happen.

I think what the other thread is discussing is relevant. On the ardupilot.org site, there are explanations of the software and hardware that AP runs on, and there is a link to a Roadmap…but no where is there a “Mission Statement” or a “Vision” or a “Charter” which means each lead developer may have a different vision for their project. I think it is important for AP as a whole to have a mission/vision that is clearly stated so that anytime a discussion comes up that is contrary to that, you can point to the mission/vision and say, that’s outside the scope. Additionally, each project lead could have a sub-vision for their platform, although that is probably already pretty well documented through the roadmap page.

Regardless, it is important to note that “Where there is no vision, the people (projects) perish” :wink: …or are relegated to the Rants & Raves section. :laughing:


(TI) #94

Aiming to “enable to create and use trusted vehicle system”, as stated in the code of conduct, is a great goal to pursue.

Especially when considering that commercial users and companies who integrate the Ardupilot firmware/ Mission Planner into their unmanned vehicles, are making a considerable investment:

  • They need to explore and learn all the deep “ins and outs” of Ardupilot - doable, but not a trivial pursuit.

  • With the autopilot playing a pivotal role, to get a good overall outcome and a competitive product, they will develop/ construct/ adapt their unmanned system tightly around that brain.

  • With such a choice, they are also taking a pretty big risk: the system they are entrusting their vehicles to, must be around and maintained for a good while into the future. (Otherwise their efforts are greatly jeopardized - and possibly their entire product line or even business model. To quickly find, switch to, integrate, test and document another autopilot system is a drastic challenge for a SME with limited resources in a fast developing market.)

I have been prompted to consider what this “trusted” may mean - and tried to flesh out some of what this could entail, with some additional thoughts on each aspect. I think TRUST has to do with:

  • Great TRANSPARENCY and effective COMMUNICATION
    A concrete vision, a tangible road map of what to await from the ecosystem, along with project proposals, timelines and status visible in a clear way, will foster trust of current and future users; they know what’s upcoming.
    Excellent or at least sufficient documentation of processes, features, settings etc. of the system is also key. Insufficiently documented advanced features and hidden, undocumented features, can either hamper adoption, impair performance or even jeopardize a successful integration and can be counterproductive to producing trust. If things are not working as expected, but the user of a software is left in the dark as to why this is, users are less likely to enter a project/ mission with confidence.
    For somebody to commit to an advanced integration of Ardupilot into their systems currently can take a serious amount of persistent cross-research, and can amount to piecing a picture together from a variety of at times rather thin and varied sources. Making the entry barrier high has not been the hallmark of projects that have become industry standards.

  • multi-leveled RELIABILITY
    A reliable, safe, stable autopilot and repeatable, stable, and clear communication with the GCS, along with easy, task-oriented handling, aids in UAVs not falling out of the sky. In performing flawlessly when it counts. By adding safeguards against risks, loss of reputation, investments, time and revenue.
    Predictability regarding releases and proven/ documented interoperability of system components also plays a role in this aspect.
    Besides this, you are trusted more, when you have proven yourself in the field. For this, documenting and publishing case studies of successful integrations - in a variety of channels, even industry magazines - could be one vehicle to consider.
    (I understand there are naturally hesitations of companies to go public with such information, but maybe there are still some cases that can be featured - maybe research institutes are not as reserved about this issue, or featuring project sponsor could accomplish that.)

  • solid PERFORMANCE
    The system has to do what it promises to do and deliver consistent results - or you are not going to trust it.
    To cut down on the need for trial and error for professional users, improved documentation and offering a straight forward, easily accessible way for superior support to quickly gain results could help. (The link to prof. support is of course a decent start, but who to pick? Maybe there’s better/ additional way to centrally channel professional support requests?)

  • sound GROWTH
    Growing the user base is likely a natural outcome of being capable and reliable, along with flexibly listening to user requirements, addressing concerns, and implementing needed changes. It is also conducive to increased adoption (more people check and trust it), and in turn to more funding and a wider base of users, with more testing and further refining. And it also keeps the project vital and thriving.

  • consistent REDUNDANCY
    As regulatory demands ramp up (e.g. the need for risk assessments (SORA) coming up from ICAO/ EASA and the granting of exemptions from FAA), reliable redundancy of systems will certainly play an increasing role in gaining permissions to operate in more challenging environments (e.g. “Specific” category/ urban settings, BVLOS). If your Ardupilot system can demonstrably provide redundancy and be trusted, it will allow for continued operation as regulations tighten, therefore this is an important trust factor for commercial users.

  • safe SECURITY
    This is an increasingly relevant factor for integrators and clients. If this is reliably implemented, tested, handled, documented, and communicated properly, it will add trust in the autopilot’s ecosystem.

  • continued INNOVATION
    For people to put trust in a project, and invest time, money, and resources in it, the value of innovating (not simply change for the sake of change) is not to be underestimated, as it keeps a project relevant in a continuously evolving industry. If innovation is part of a project’s DNA, this must also allow to take a critical look at the status quo and a re-evaluation as things progress.

  • focused EXPERTISE
    Ardupilot/ Mission Planner unlikely can be everything to everyone. It may now make sense to consider sharpening the focus and not try to cater to every hardware and everybody’s needs. As desirable as backwards compatibility may be for some users, reasonable limits have to be drawn, and devs limited capacities instead may be better devoted to hardware that is in line with today’s performance standards, and features that are high on the list of users, trying to get stuff done in the field - with their chosen and trusted solution.

  • accompanying GUIDANCE
    When users encounter (or feel lost in) a feature new to them, usability can be greatly be improved when features are explained in a context-sensitive way. Because users are informed about the outcome of their chosen action, they can then trust that they are accomplishing the desired action. (As long as the functionality as such is ingrained and easily editable in the program, many of the tool-tips could be supplied/ filled in by more experienced users. This may at times even limit the need for more extensive documentation.)

  • embracing COLLABORATION
    Professionals are using drones/ unmanned vehicles to accomplish a task. To do this, simple data delivery often is not enough anymore, but the efficiency of the overall workflow is important. Such users increasingly are looking to develop well-tuned/ highly integrated systems, e.g. with GIS or industrial inspections. Since not everyone can/ needs to be an expert in every last aspect he has to deal with, collaboration is used to achieve increasingly complex tasks.
    Beyond having an autopilot, periphery and sensors are needed. Universal protocols and setting standards which allow for easy, repeatable, performant, reliable, and versatile integration of systems will facilitate adoption.
    If this project’s horizon is widened and forward-looking towards creating an ecosystem with payload APIs, and an active, collaborative outreach to manufacturers and service providers takes place, that will increase trust by users/ integrators, and they are more likely to fund this project (as such a commitment/ development underscores that this project unlikely will just be gone in a year’s time).
    It will also allow and foster opportunities for collaboration with sensor and periphery manufacturers, and other services, e.g. Airmap, and sooner or later remote/ eID and UTM services.

Well, there is likely more to the “trust” aspect in the stated aim and this brief first view could easily be expanded. But I hope these thoughts make a small contribution to spelling out what aiming to be a trusted autopilot could entail and provide some guidance for increased focus to become the trusted autopilot ecosystem.

In order to gain such focus, it will likely help to first knowing your users - because if you don’t know who they are, and how the project’s software are being used, and where you want to focus limited human resources on, you may be at an HDOP of 5 - which is simply not precise enough for people looking to join and invest into a performant ecosystem.

To aim for this trust - and to get to that state of being trusted - some concrete suggestions come to mind:

  • Consider leaving behind any tinkerer reputation this project apparently has (according to a post above). Make the high amount of parameters not a hindrance, but a strength!
  • Give this project a clear and concrete vision of where it is headed, lay out a roadmap of how to get there - and communicate it clearly for all to see.
  • Embrace an openness for rethinking things from fresh perspectives, maybe considering an improved structure (e.g. of parameters), or a more modular and task-oriented/ user-centric approach.
  • Open up a good electronic way for users to voice (describe, explain and vote on) suggestions for improvements and changes - beyond the forum discussions.
  • Consider allocating more funding and man power towards skilled documentation.
    (I don’t see how documentation of advanced features could come from average users in a reasonable amount of time, as that may often entail being able to understand code to grasp the implications of a parameter change and their dependencies. That will likely need to be done or at least closely supported by the ones who have conceived those relationships, or more experienced testers, who really understand how things interrelate, what effect they have. Trial and error is of limited value here and will more often than not lead to wasted time, a giving up or wrong conclusions.)
    Documentation could maybe also be improved by offering a simpler, more direct way of feedback:
    e.g. in it’s simplest form with a popup: “Is this page helpful?” Yes/No > How can we improve?
    Or (preferably) a more advanced pre-grouped feedback, such as "Some information on this page is outdated/ wrong/ incomplete/ confusing/ contradicting/ redundant, along with a mandatory field to provide specific feedback on the issue a reader found.)

As a pre-cursor to more focus - to better understand the user spectrum and their applications - could it be helpful to run an anonymous survey? To then know who are we attracting? I would have a few ideas on how to put that together.
Does anyone know if such a survey tool is already integrated with this platform/ available to it? And - if such an approach makes sense - who would be a leader in the community who could aid in “looking this over from an official side” (before publication), and post it in prominent places (to reach a good representation of users)?

While still somewhat young and possibilities for growth are ahead, nevertheless the UAV industry is seeing it’s first consolidations and there may only be a limited time window to gain a solid relevant - trusted - position.

The full-featuredness that Ardupilot and Mission Planner already offers, along with it being open source and what already has been achieved, has plenty of potential.
Maybe I am missing something, but IMHO this project could now benefit from concrete vision and channeled direction from it’s leadership.

(Edited for clarity)


(mike kelly) #95

The part you are missing is that there is nobody to do what you are proposing.


(Nathan E) #96

The only “nobody” out there is one who says it cannot be done. @camti, your contribution to this conversation is more than welcome, and I respect the time and thought that you have put into your response. Thank you.


(Jakob Schmidt) #97

MP could most certainly do with a make-over. I’m increasingly using QGC for setups, but MP still has the edge in flight planning (just).
I also don’t understand why this is so contentious.

Question for Proficnc: With hiring Michael, will this prevent him working on MP?


(James Pattison) #98

This is quite a thread!
@camti I like a lot of what you posted above. The insight and feedback is welcomed.
@Naterater Similarly, the suggestion for an open voting system on issues/feature requests has merit. The dev team has discussed the concept before, but it was a long time ago and in my view worth revisiting.

Regarding the general feelings expressed regarding transparency and communication: I’m really open to suggestions.
The devcall and minutes are open, the monthly Partners report is published here.
Between email, gitter, Skype, slack, Facebook and here, we try to keep engaged with as many as we can. Ways to provide better coverage more efficiently would be great.

All of that is off topic for this thread, but I wanted to let the participants know that the message has been received.

On the topic of this thread: Michael has provided what is probably the worlds most recognised gcs tool, and deals with bugs and new features incredibly quickly, until now in his spare time. I’m sure he and Hex have seen a lot of the feedback/suggestions here, in Facebook and in GitHub. I for one am looking forward to seeing where he takes Missionplanner now he’s full time.


(TI) #99

@james_pattison thanks for stopping by and communicating that the message is being heard and welcomed. I certainly appreciate the engagement of the team on the channels you outlined, the openness expressed, and am thankful for the work of all the devs and Michael’s huge contribution of skill and time. Add to that some communicated focus, and the HDOP will allow for arming and take off in no time…

I have found the minutes, and this is not only helpful but also quite promising. It’s probably worth stopping by there more frequently.

I have also now found a roadmap (in devs > How the team works).
Yet in order for new/ potential adopters and “general users” to grasp where things are headed, maybe these items would deserve a more prominent place on the website, even the home page (in addition to latest posts)?
Please point me to the partners reports you refer to - I could not find them. If partners could be granted a more visible place where they can feature their integrations and share their successes by using Ardupilot, maybe this encourages more partners to join.

Should the team find that running a survey to get a better picture of the AP/ MP users helpful, and would like assistance in creating one, feel free to PM me.


(James Pattison) #100

G’day @camti, the Partner’s reports are usually linked into blog posts, and can be found here: https://discuss.ardupilot.org/tags/monthly-update. Sorry that they are hard to find - I think you’re right that these should be more visible.

I ran a short survey last year, leading up to the Developers Conference, to help inform the Roadmap. I intend to do the same for 2019, and will put it out over the next month or so (Developers Conference is mid March).

Re marketing/media for Partners: I completely agree! We encourage Partners to make blog posts for product releases (and help with that quite often), and coordinate shared presence at some trade shows, but are really reliant on the Partners to drive their own marketing efforts.