… 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
Contributor here. If nothing else, hope it gets more people involved.
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.
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.
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"
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
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.
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
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…
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
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.
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