ArduConfigurator, a new Ground-Control-Station software based on modern web-technologies

Topic: Funding a developer[me] part-time to get ArduConfigurator to a first release, a modern Ground-Control-Station software based on web-technologies[Node/JS/web/etc]

Proposal type: Hardware [ ] , Software [x ] , Other [ ] :

Description: ArduPilots approach to GCS software has always been a bit hit-n-miss, and current GCS applications suffer from a lack of focus/consistency/growing-pains. Web tech is the past and the future, the browser is king.


  • new-user experience with AP is all ‘through’ it’s GCS’s, and it is poor, not really self-guided.
  • Mission Planner is showing it age, and although fully featured, its also full of bugs. Its cross-platform, but only just. Written using a proprietry language(C#) that is controlled by a monopoly, MS. Many years as a windows-only thing. 90’s styling.
  • MAVProxy has never been a user-experience-focused GCS, and its terrible for users getting started with AP. Its cross-platform, but only just.
  • QGroundControl - its PX4-first focused, Don is retired, and no long-term volunteer’s have stepped forward to upkeep it. Written using a language (QT) that’s scary/undesirable to many devs, and gets only really bug fixes.
  • APM Planner 2 - is abandonware/stagnant , no bells-n-whistles.
  • probably others out there, but lets be honest, its mostly MP with some QGC right now.

ArduConfigurator hasn’t had a release yet [as a volunteer/scratch-my-itch project it didn’t have to], but it has massive potential to be AP’s next-new GCS , its using modern web tech[right now], its got 3D build in[right now], it’s got front-end-back-end split architecture[right now], it can flash your chip with apj or dfu[right now]… it needs more attention just to get it across the line to a ‘usable first release’.


1 - finish code to the point that a brand-new-user[*1] with a brand-new unprogrammed flight controller can configure and fly a copter or plane mission without needing to use any other software, on a linux and/or windows desktop.[we are NOT targetting android/iphone for this first release.]
2 - beginning-to-end video/stream evidence/documentation of the entire process on youtube for both a copter and a plane.

Planned amount $$ (USD): 20000.00/year

Estimated time for completion: < one year

*1 - first-time-user of this GCS, not first-time AP user.


For some context, this is a large investment that would require a full dev team vote to proceed. My suspicion is that this would be valued much more by the community than partners and so I encourage people to voice their opinions - both positive and negative - in this forum. @DavidBuzz some screenshots of what currently works might help give people some additional context.


I know @Michael_Oborne would be a “competitor” developer to this GCS - but it would great to hear if he has any thoughts on this.


This is a good idea, the implementation may be somewhat difficult, mainly because the application-oriented scenarios developed for the ground station software differences are relatively large.

For example, the difference between DJI’s aerial drone ground station and agricultural drone ground station is relatively large, and the difference between agricultural drone ground station and industry application ground station is also relatively large.

I estimate that the future ground station may be diversified, with special ground stations adapted to different industries for different purposes, so that it is more convenient to use.

Most of them are ordinary users, they are not developers, they only care about how good the user experience of the ground station is, whether it is convenient to use, and whether it saves their time.

And this would make add-ons much easier to program and integrate?

this made me hesitant at first until I reread everything I think it may also benefit first time users as well.
When you mention web technologies does this mean it would not work in a unconnected environment?

It’s basically an ardupilot port of betaflight’s configurator which uses chromium, so works fine offline

screenshots of ‘what works’ as requested by @andyp1per :slight_smile:
a selection of a dozen 3d model/s that move around tilt/way when the imu is tilt/yawed:

parameter fetch/edit/save/upload:

basic mission create-edit-upload-download:

not just copter, but also a selections planes/copters preconfigured:

accel calibration , compass calibration, ‘level’ calibration, all work:

also choosing a firmware, fetching it from the internet, and flashing it to a board that is in DFU mode, and/or has an an ardupilot bootoloader on it [both types of flash work]


things that dont work right now:
1 the system has a built-in “library” of a bunch of common vehicle layouts, each of which includes motor/actuator layout info information [ie what params to set to what], and these mixers are untested/incomplete [ parts of the gui exist, but its not connected to mavlink for setting params]
2 - for users wanting their own vehicle layout , which isn’t part of the above library, manually setting up motor mixers/actuator layouts [parts of the gui exist, but its not connected to mavlink for setting params]
3 - once a user sets up their own “custom” profile of settings, there’s no way to ‘save’ that into the library.
5 - Rally points, fence points, and other advanced mission items aren’t handled , also mavftp isn’t implemented. [ not needed for first release]
6 - no camera/gimbals configuration [ not needed for a first release]
7 - graphing/live sensor data - there is some basic graphing of raw sensor/imu data, but nothing else.[ not needed for a first release]
8 - not all pre-arm checks are functional [ they have gui elements, but may not be useful in ardupilot]

The goal with this funding request is to [a] get the software its first ‘release’[b] then get it more visibility [you tube, wiki docs, forum announcements] as it becomes a useful choice for users [c] obviously to extend/expand its capabilities more as time and releases progress. [d] get more web-devs potentially interested in helping with it, etc.

… I think MO is perfectly capable of making a similar funding request if he’d like to. He’s also welcome to get involved in this project as well, if he want/s.
I’m also fine with the scenario where [if the funding $ is approved], and someone other than me stands up to say that want to take lead on this project, that the $ goes to them, or is split between multiple web-devs in some semi-equitable way… so long as they have some evidence to support their skills. [my evidence is the software-to-date].


I did a bit of testing of the current state of ArduConfigator today with @DavidBuzz. I got it installed and used it to install master on a Pixhawk5X (which just happened to be on my desk) and attempt to set it up as a quad. The firmware install worked, and it did use the manifest to correctly allow selection of a firmware.
Not much apart from that worked, it seems all attempts by it to set parameters or trigger actions with MAVLink failed. So I couldn’t set the FRAME_CLASS, RC cal failed, accel cal failed, mag cal failed, setting a parameter manually failed. UDP didn’t work (or we couldn’t work out the syntax).
On the plus side, I could use the mavlink inspector, I could view the 3D model, I could view the sensor graphs for IMU, mag and baro.
Will do some more testing when @DavidBuzz has had a chance to look at why mavlink send isn’t working.

a bit of a correction on the state of QGC and MissionPlanner development. Thanks to the great efforts of @david_sastre for QGC and @robertlong13 for MissionPlanner both are advancing rapidly with new features, bug fixes and UI improvements happening very rapidly over the last few months.


I had a quick look at the contribution levels across the “common” GCS tools, since 1 July 2022, basically to see if there is evidence to support the assumption that using web tech will lead to greater supportability/contributions.
For those interested:

Project Commits Contributors Lines of Code Link
MAVProxy 129 13 3312 Contributors to ArduPilot/MAVProxy · GitHub
MissionPlanner 293 15 82189 Contributors to ArduPilot/MissionPlanner · GitHub
QGroundControl 171 24 66015 Contributors to mavlink/qgroundcontrol · GitHub
iNav-Configurator 153 9 277548* Contributors to iNavFlight/inav-configurator · GitHub
BetaFlight-Configurator 326 20 34046 Contributors to betaflight/betaflight-configurator · GitHub
ArduConfigurator 0 0 0 Contributors to ArduPilot/ArduConfigurator · GitHub

What this shows:
ArduConfigurator has not had a single contribution in that period - so any development is happening in forks.
MissionPlanner and QGroundControl have both had more development that the BetaFlight Configurator
iNav configurator seems to have had a white space cleanup or something - every line of code has changed, which skews the stats - but it has less contributors than MAVProxy.

Food for thought.

1 Like

I do like the idea of this configurator. But I dislike the idea of focusing it as a GCS. I think such a configurator will be popular for community, for setup, and maybe as a quick tool to develop stuff for debugging, etc.

But I think the effort of putting it on pair with mission planner and QGC is huge, I think way way way beyond those 20k USD asked. Both mission planner and QGC backends are really complex and beautifully engineered, they manage multivehicle and missions extremely well, and they are both stable on that regard, which I think is the main point of a GCS.

I think trying to replicate that on ArduConfigurator, thinking it would attract developers by itself would be a mistake. I don’t think the problem with few contributions in Mission Planner and QGC is the framework itself, but the projects being complex themselves. I think if ArduConfigurator at some point gets to be as sophisticated as QGC or MP as a GCS, the complexity will be similar, and the developer availability will be similar as well. Just in maintaining bugfixes and the cross platform maintenance for new features ( different screen sizes, different hardware, etc ) will eat up very easily a developer part time.

There was an interesting thread about this in QGC channel on discord. Both Qt and .NET are very common frameworks, with lots of master developers out there. I don’t think the lack of development is caused by the frameworks themselves being too difficult to work with.

Sure, Betaflight configurator and friends are very popular, easy to work with, but they are not even compared to what QGC and MP offers, it is orders of magnitude simpler, easier to understand and work over. I don’t think it is realistic to think developers will come from everywhere to contribute to ArduConfigurator just because of the framework.

I think both MP and QGC are very particular projects, in the sense of, they have been maintained/developed almost since the beginning by a single person, or very small groups of people, and the only reason they got to the point they are today is because those single person or small groups of people have something like super powers or an infinite source of motivation to continue working on it, although unfortunately as a lot of you already know, that golden era for QGC and MP is ending, because of course it is not reasonable for such small teams to keep investing all that time and energy on those projects, having nothing in return. I know a lot of those developers work on it because they really like it, have passion for it, believe on it, but unfortunately the burden of maintaining, bugfixes, etc is not fun, and that kills the passion and the enjoyment of the core devs working on it for free just for the fun of it. I think some of those devs would come back to keep pushing forward if somebody else could really really take care of maintenance.

A lot of companies are benefiting from them without contributing back, and that is just not fair, so I totally understand the developers are less and less involved. It would be reasonable that the big players benefiting from it could contribute back minimally, so at least the maintaining is covered by them. That would allow core developers to keep working on cool stuff to keep moving the project forward, because that is what the core developers that have put all those resources here love about it. Nobody loves the burden of maintaining such huge projects by themselves, that is not fun. And if ArduConfigurator ever gets to that level of sophistication, it will face similar challenges, because it doesn’t matter how modern a framework is, we are talking about a software that needs to run crossplatform and run on a huge variety of devices, some of them ridiculously underpowered. Maintenance will be required at some point, and it won’t be much easier than maintenance of MP and QGC right now. It is just not realistic to think a project won’t need that amount of resources just for regular mainteinance. And considering what the software is, it is also not realistic to think we can have total hardware abstraction, not at all. It will needs lots of resources to get maintained if it ever gets to be a full sized GCS.

A lot of companies are as well working over both MP and QGC, but there is just not that much contribution rate on those projects. Maybe because of the innovation on them upstream doesn’t justify contributing and keeping their custom branches up to date. It is maybe easier and makes more sense from a company’s point of view to just maintain a closed source version of such GCS. It could be also that as those project have run for such a long time without external resources everybody forgot the insane amount of effort the core devs of such projects were doing, maybe we all took them for granted, I don’t know.

How to fix that for MP, QGC, or any GCS? They probably need to get by themselves enough inertia for companies to be interested in investing on them. We are talking about very complex projects that will need a lot of developer time to maintain. And doesn’t matter how modern and cool a framework is, if a project gets to the sophistication level of MP or QGC, it will need maintainers doing everyday work for it to be attractive/stable enough for the rest of the community and potential new devs to come in. And that means funding.

The funding can come as donations, as companies sponsoring it, whatever, but from my point of view that is the reality of the situation. It is just not realistic to think just a modern framework will attract developers to work and maintain for free on such a project. I would love to be wrong about this, but I really think this is just the way it is on the world we live in right now.

Having said the above, I do think there is space for ArduConfigurator, and I think it has the potential to be a great tool, and I myself would be interested in contributing at some point. I do think using a modern framework has a lot of advantages, and could bring a lot of value to Ardupilot ecosystem. About the 20k funding for it, It is more than reasonable, and I am not opposed to it, but I do think it is necessary for all of us to be aware of what I said above, to be realistic about the road for ArduConfigurator to be on pair in functionality with a full sized GCS, which in my opinion, is orders of magnitude above those 20k asked, and that is why I don’t think it would make sense for it to be a full sized GCS, not in the near future, considering the available resources we are talking about on this thread.

Just my opinion though, I could be completely wrong. Sorry about the long message by the way.


for those that didn’t want to read @david_sastre’s post… he’s in favour of it, i think.

1 Like

@DavidBuzz I am indeed in favour of keep exploring this ArduConfigurator idea.

About the funding, my position is clarified I think in the last paragraph of my previous message, I apologize if it isn’t.

I am not against the funding proposed at all, If the rest of the team agrees with it, I am more than fine with it too. But for me to be completely in favour of it, I would personally need to see it a bit more mature, and understand better the roadmap of it, what this project is meant to be.

What I don’t agree with is with the way you presented it, and that is the point I tried to made on my last message. I know it is huge, sorry about it, but I didn’t know how to explain my thoughts about it in a more compact manner.

1 Like

I think one of the key things that iNav and BetaFlight have that ArduPilot doesn’t is some way to know the hardware tree of the board they are connected to when doing config.
When you use the iNav or BetaFlight configurator then the serial ports line up with the real serial ports, they also show the number of ports you actually have. The GCS doesn’t have access to that information in a convenient form with ArduPilot. In principle the GCS could download and parse the hwdef.dat for the board, but that would be quite fragile and a lot of work.
The same goes for outputs, RC ports etc. The GCS is much more aware of the specific hardware than it is for ArduPilot. This makes writing a setup UI that gives a good user experience a lot easier.


We could use @SYS/uarts.txt for this information

I think it would be great to have something that helps people set up vehicles but a total replacement GCS may not be needed.

It would be helpful to have a configurator that walks one through setting up the recommended defaults, mandatory and optional hardware, setting up the filters on through the autotune process, but after that point something like Mission Planner would be used for mission planning and as a day to day GCS.

This effort could be complementary to existing GCSs rather than replacing them. It could be a configurator rather than a full GCS.


+1 for sure. Simplified MP for setup. Then on to full MP for those who need it.

I am not trying to be against new GCSs here - but what is the benefit of having this as an external application rather than integrated into QGC or MP? Just seems like another software/process that needs to be kept up to date and documented. Could we not use this time/money for improvements to QGC/MP - instead of adding a new GCS to the mix.