Copter tune sanity check script?

There seems to be a lot of repeat advice given around here to do things like use the Mission Planner initial tuning step, set INS_ACCEL_FILTER to 10, set ATC_THR_MIX_MAN and PSC Z terms after initial tuning, etc.

I know some of these sanity checks have been discussed for inclusion in the actual firmware, but with flash space at a premium, it seems less and less likely that a comprehensive, native check will actually make it to prime time.

It’d be pretty easy to write a Lua script or even Mission Planner Python script for users to load and see tuning recommendations beyond that which already exists.

Any interest in this? Any preferences as to the type of script? Any “must have” features?

@dkemxr, @xfacta, @andyp1per you seem to be the sources of collective knowledge (or at least the most helpfully vocal) - your thoughts? Maybe something we can point folks toward and ask that they copy and paste the output for quick analysis before even delving into the logs?

1 Like

It’s worth doing, but scripting is not available on every board - might be better done externally

1 Like

I would recommend that from the firmware itself those values to be modify as suggest values as a default to start with …

Not possible. The recommended first flight values are intentionally conservative, and some depend on things like prop size and battery specs. Thereafter, tuning recommendations depend on flight derived data. It’s entirely possible to use a script to crosscheck the results (or lack of attention paid to recommendation), but such a script (or native routine) should very likely not automatically change user-set values.

@andy1piper, agreed that an external approach is likely best. Such a Lua script would really only have utility on the vehicle itself for a few initial test flights. A Python script to load into Mission Planner would be more accessible and less invasive. Such a script could include a command line option to load a parameter file such that Mission Planner is not a requisite, as well.

This sounds like a great idea Yuri. It’s certainly true the same questions are answered day after day. Something very prominent in Mission Planner. But somehow even when configuration screens are shown under Mandatory Hardware it’s not getting done…

1 Like

Here’s a short snippet that you can save as a .py file and load into Mission Planner’s “Scripts” tab (leave redirect output checked).

All it does so far is back prop size out of the gyro filter parameter, but that’s by design. I’m curious if y’all think that is a good place to start? Thereafter, I can crosscheck that the remainder of the params set by the initial setup plugin are within some tolerance while offering a warning against anything that has been left default and needs attention…if that makes sense?

Or is there another methodology you’d use?

try:
    import clr
    clr.AddReference("MissionPlanner")
    import MissionPlanner
    clr.AddReference("MissionPlanner.ArduPilot")
    import MissionPlanner.ArduPilot
    firmware = str(MissionPlanner.MainV2.comPort.MAV.cs.firmware)
    GetParam = Script.GetParam
except ModuleNotFoundError:
    print('Running Standalone')
    firmware = 'ArduCopter2'
    def GetParam(name):
        # TODO: read a parameter file and return values with this function
        return 100

atc_prefix = 'ATC'
mot_prefix = 'MOT'
if firmware == 'ArduPlane':
    atc_prefix = 'Q_A'
    mot_prefix = 'Q_M'
elif firmware != 'ArduCopter2':
    print('{0} not supported by this script.'.format(firmware))
    # TODO: exit if this happens (but IronPython makes that painful...)


# back prop size out of gyro filter value
ins_gyro_filter = int(GetParam('INS_GYRO_FILTER'))
try:
    prop_size = round((ins_gyro_filter / 289.22)**(1./-0.838), 1)
    print('Assumed Prop Size: ' + str(prop_size))
except ZeroDivisionError:
    print('Please connect to a vehicle or load a valid parameter file...')
    # TODO: exit if this happens (but IronPython makes that painful...)