New ArduPilot methodic configurator GUI

I muddled through this for the first time today on a Copter I hadn’t flown in a while. I used v0.6.6 (v0.7.0 was released amidst my tuning sessions). A few thoughts:

It was frustrating to connect/reconnect multiple times, and often I found myself stepping backwards in order to re-trigger the dialog to download from the FC (like the autotune results). That was very clunky.

Likewise clunky was a repeated message that access was denied to the serial port in use for telemetry. Happened with SiK radios as well as over USB. Mission Planner had no trouble connecting, but the configurator refused multiple times. I confirmed the port was open and available more than once (i.e., not in use by another app like MP), but it stubbornly refused to connect pretty often (Windows 11).

The only template I found was the original Taycan, which is tiny by comparison to the Copter I was using, so I needed quite a bit of previous knowledge to arrive at the correct starting point(s). I was also using a Cube with heated IMUs, which significantly changes the first few steps.

Minor bug report: selecting a CAN GPS auto populates the associated parameters with “CAN1_” and “CAN2_” prefixes, which are in error. They should be “CAN_P1_” or similar.

The new harmonic notch web tool is pretty slick, but it could use some more detailed explanation of what you’re looking at and how to optimize. I think I did a pretty good job, and I arrived at a minimally configured notch that seems effective.

The online MagFit tool is awesome, but one of my attempts resulted in a prearm error stating the compass wasn’t calibrated (after updating with the results from MagFit). I couldn’t for the life of me figure out why that happened (all the calibration params seemed complete and valid). I flew another attempt, and it fixed itself up.

I already have some wind estimation data for this Copter, and it was easy to just fill in the known values and move on.

It got dark by the time I got to the sys id section, which is probably for the best. I have no idea what’s going on there. That’s a tuning regime I’ve never attempted. I’ll read up.

For what it’s worth, I attached my param files and associated config below (nothing past 42_system_id_roll.param was accomplished).

All in all, the Copter’s back in the air and flying well. There are a few details I’ve likely previously overlooked that were covered by this method, so that’s a plus. However, I think it’s got a long way to go before it’s user friendly enough to take a brand new user from zero to hero.

ReadyToSkyZD550.zip (500.0 KB)

1 Like

That is the first time I get such a report. Never had that issue in my tests either.

I will try to reproduce that with SiK telemetry. So far never had issues with direct USB.

Yes, that is normal, but it will improve as the number of templates increases. May I use your parameters as a template and release them under GPLv3?

That is actually a known bug, thanks for reporting.

The credits on that go to @iampete

The credits on that go to @iampete

Thanks

With detailed and proper feedback like this I will keep on improving it. Thanks for the feedback.

This feature is now implemented, just select “Use parameter values from connected FC, not from parameter template files” while creating a new vehicle configuration directory

2 Likes

Thanks for advising me. A huge improvement!!

v0.8.0

Latest

@github-actions github-actions released this 11 Jun 15:37

v0.8.0

beca928

Commits

  • 3 More templates are available, including yours
  • Fixed the CAN renaming bug

No problem on sharing the template under GPL.

Maybe the app is supposed to auto reconnect between steps where flight is required and USB is in use. I had to close and reopen the app every time and then goof around with the drop downs to re-trigger the dialog options. Experienced similar with SiK, though sometimes I could maintain the connection throughout the step and keep things moving along.

Computer in use has a lot of third party drivers from projects like these. I owe it a fresh start. Even so, I bet I’m not the last to experience that type of behavior.

For those following, the ZD550 frame uses 10-15 inch props, has folding prop arms and long, spindly fixed skids. It’s not a great frame, but it’s inexpensive for what it is, and it’s better than some of the floppy plastic BS that’s out there. I’ve never had an issue with the folding arm mechanism, and vibes are quite low overall.

Now I found the issue. It was a regression I introduced in the last couple of days. I fixed it now. Thanks for reporting. New 0.8.1 release is in CI

1 Like

v0.8.1 Latest

Commits

Related to the differences between your template and mine (if this is a big tangent, I’ll start a new topic):

You used PILOT_TKOFF_ALT of 0. I prefer to set that to 300cm (10 ft). When I used 0 and had the remainder of the TKOFF parameters set correctly for this frame, I noticed that it would take off (in alt hold), gain a few feet, and then nearly land again before climbing up and away (usually commensurate with a big throttle input from me). If I set 300cm, the takeoff was smooth with no altitude oscillation. Could that be indicative of a thrust expo issue? Or is PILOT_TKOFF_ALT=0 the likely culprit all by itself? Hover thrust was set correctly and verified by log review. I don’t have the log on hand to share, and I don’t think you want this topic to turn into a log review topic, anyway.

Which leads me to my next related question - how is the average user supposed to arrive at a good thrust expo value? Tridge’s script seems dead in the water, and most have no access to thrust test stands.

Very interesting find, your description matches almost perfectly a problem we observed with the Taycan that I brought up here: Discrepancy between EKF altitude and barometric altitude in AltHold
I don’t know if the PILOT_TKOFF_ALT value should be visible in the desired altitude though…

Altitude control was rock solid after the initial takeoff bobble. Leads me to believe your exploration of EKF fixes was probably not the place to look. Also leads me to believe it’s not a thrust expo issue, though I still want an “every man’s” solution to properly setting that.

I did edit your template and moved PILOT_TKOFF_ALT=300 from 07_esc.param to 13_general_configuration.param.

Those are good questions, we will need to do some flight tests to test that. Then I can add that to our template as well.

The current method is still to use the “spreadsheet” calculation that I re-implemented in the configurator. (step 11_initial_atc.param)

Yes, that is a pity.

v0.8.3

Latest

@github-actions github-actions released this 12 Jun 22:02

v0.8.3

9b42c92

Commits

Commits

v0.8.4

Commits

v0.8.5 Latest

Commits

v0.8.6

Commits

v0.8.7 Latest

Commits

How do I insert the drone photo?? I tried to upload it in the indicated directory but nothing appears.

It has to be called vehicle.jpg and be in the same directory as the param files.