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)