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

Proposals
12

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
13

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.

8 Likes
14

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

1 Like
15

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

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.

5 Likes
17

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

1 Like
18

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.

3 Likes
19

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

20

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.

2 Likes
21

… i originally discussed with tridge the idea of asking for funding to improve all GCS’s… but he pointed out that it[one part-time paid person] would essentually stop all the great unpaid/volunteer work that goes into these already… so it needed to be a more-focused or goal-oriented funding request, not ‘fix all the things’ … so i wrote a request as it interests me. If someone else wants to ask for funding for something specific to qgc/mp/mavproxy/etc, thats a different request, and they’ll have to write it.

1 Like
22

Contributor here. If nothing else, hope it gets more people involved.

23

I would love to see this come into fruition.
I’ve been a long time Cleanflight/Betaflight/iNav/other-forks user. There’s no doubt those systems are much simpler than AP. But to me it’s the ease of use interface that makes the barrier to entry minimal. Once AP has similar interface I’d think a lot more people would jump in and explore what AP has to offer.

I am no developer so the extend of resources needed is beyond me. But I have experiences with technical writing, and even wrote instruction manuals for RC helicopters. I’d love to help with that aspect if the need arises.

24

I’ve been reading through this, just letting you know there is definitely the interest out there!
I’d like to see this web configurator as the initial setup and basic tuning tool, also useful for any parameter changes of course.
From a Copter perspective, there should be some more questions about the copter hardware and the configurator would set same basic params as required and guide to the next step, or be “stuck” until previous mandatory steps are completed.
But leave the log analysis and more advance functions to MissionPlanner and other tools we already have.

25

I STRONGLY support this; putting it all out on the table here… Ardupilot has long been held back by intuitive, new-user friendly GCS support. To my knowledge, nobody has complained about lack of features on the current set of GCS’s, but generally, they are inferior to the competition of iNav and BetaFlight.

It’s been beaten to death over here in this thread, so no need to re-hash the disappointments. Mission Planner "Makeover"

26

I 100% agree that we can and should improve the user interface for Ardupilot. Not only to make it more intuitive, but also to help the stigma that “Ardupilot is too complicated”. Ardupilot has more options, but doesn’t have to be more complicated than other FCs out there.

That said… I’m not convinced that simply listing out all of the parameters on pretty tabs with context help balloons will actually make it easier. For example, the iNav configurator is not easier in my opinion, it just has a lot less rando text fields to fill out.

I’m just saying that we need a plan to actually make things more intuitive. Similar parameters need to be grouped into similar locations with helpful context (automated mode speed, altitude and radius settings come to mind). We should be adding informative pictures and wizards after the setup wizard.

Also… for those of us that know what the settings do, please do not downgrade the Full Parameter List into a CLI tab. One thing Mission Planner does better than BF or iNav configurators is how they handle parameters that aren’t on the UI.

3 Likes
27

Adding my message on Discord here too for all,

Having used betaflight configurator and the elrs configurator a lot recently there are many items AP needs to advance. They are so easy to use.

Legit 15-30 minutes to fly 1-2 times with everything done…
Of course a configurator is different than a full gcs.

I strongly encourage not abandoning this proposal from @DavidBuzz.

One of the coolest things is this page to setup parameters contributed by the community,
Have an HDZero VTx click the preset, tell it the port number (which are sanely and consistently labeled in firmware…). And you are done.

image
image1710×1371 318 KB

So much good for everyone (large commercial vehicles) has come from the hobby community due to @andyp1per 's work on the firmware side. But what about the configuration and GCS sides?

2 Likes
28

I think perhaps the main reason why for example, Betaflight Configurator doesn’t have as active code development is because it’s already pretty well-suited to what people want to do. I’ve watched a fair few videos where people talk about Betaflight configuration and setup, and rarely have I heard people complain about it…

The same cannot really be said for any of ArduPilot’s GCSs.

ArduPilot’s main problem in the GCS area is that we have a whole bunch of GCSs that do one thing well and are bad at other things. That is why, for example, I’m currently using both Mission Planner and MAVProxy (usually Mission Planner for setup and MAVProxy for flying) because though I like MAVProxy, there are some things that are rather hard to do with it, especially on Windows.

If we can instead focus on developing a single GCS that actually works for nearly all users (which means it working well on both Windows and Linux at minimum) then we can aim to have a single GCS that we recommend most people use.

I also agree with @hendjosh’s point about the presets that Betaflight configurator has being a huge advantage. For us, this would especially be having different sets of defaults for different sizes of vehicles. For example, it took me quite a long time to get my original quad tuned. A high powered 7" quad’s dynamics are just so far off what AP normally flies that many of the default parameter values were totally unusable - my first 5 or so “flights” only lasted a second or two each, only to check whether I had lowered the gains far enough yet - I couldn’t fly it long enough to tune while flying or I was likely to smoke motors because the default gains were so high for this quad. Contrast that to when I set up my 5" quad, and I loaded most of my 7" quad’s parameters as “defaults”, and they were close enough that I could easily take off and start flying with minimal tuning needed. If the average person setting up a small quad could load a “small quad” parameter preset they’d probably be up and flying in less than 1/4 the time it would’ve normally taken them.

One of the main reasons why this type of thing is hard for us to do is because we have so many GCSs and it’s so hard to get features added to all of them simultaneously that we end up having to do most things on the flight controller itself, which we just don’t have the flash space for. Betaflight, on the other hand, can do basically anything that isn’t used in flight on the GCS instead (that would include things like parameter range checking in our case) because they know it’s the only GCS people will be using with Betaflight (I’m not aware of any other configurator that can be used with Betaflight?).

I’m not certain that ArduConfigurator is specifically the best way to solve these problems, but it does seem to me like it’s more doable than completely redoing Mission Planner or MAVProxy’s UI’s…

29

BFConfigurator does exactly one thing, it configures betaflight flight controllers.

MAVProxy MissionPlanner and QGroundControl are multipurpose tools that are significantly more complex and capable than BFC. Some people need good mobile support (qGC), some need modabililty (MAVProxy) or good mission support (MP).

3 Likes
30

In such a general sense like that, you could also say all AP GCSs do exactly one thing: Act as a ground station for ArduPilot vehicles…

What I’m saying is we shouldn’t have 3 different GCS that either do mobile, or are moddable, or have good mission support. We should combine them so we can focus our efforts on one GCS.

31

As a question about clarification, I hope the intent of this funding proposal is for ArduConfigurator to eventually become a GCS with the features Mission Planner etc have, not just a “Configurator” right?

1 Like