Is AutoTrim in Arducopter Still Necessary?

[Robert Lefebvre]

It was brought up in the dev call last night, the possibility of deprecating the AutoTrim flight mode from Arducopter.

To be clear, this is the mode where you fly and "nudge" the sticks around, and each time you nudge, it integrates a small angle correction.  I never use this mode, as I find it dangerous.  You have to keep "poking" the the copter to offset drift, but at the same time, every poke integrates correction.  I almost crashed 2 years ago, or so, because I had forgotten I left AutoTrim on a switch, I thought it was Simple mode.  When I engaged the switch in flight, my stick inputs became permanent trim offsets, and I was basically chasing the copter around the sky.  It was a miracle I saved it.

Arducopter would still retain the function "Save Trim".  This is the mode where you use the transmitter trim buttons, to get the angle correction desired, then you land , and after landing, you flick the switch and it saves the settings.  Then you re-center your trims, and are done.  I much prefer this one as the trim buttons are precise, you can still nudge the copter to stop a drift, and there's lesser chance of improper operation because the save trim only happens once, while on the ground.

Does anybody have any opinion on this?  There's an issue about AutoTrim not working properly, but I'd rather just deprecate it than fix it.  Not out of laziness, but because I think it's not a good option anyway.

Rob

[Robert Lefebvre]

This is the issue here:

This highlights another failure mode of Autotrim. 

https://github.com/diydrones/ardupilot/issues/1282

Some users may accidentally kick off autotrim while the vehicle is landed by holding throttle down and yaw right for 10 seconds after arming. Their roll and pitch inputs will update the trims of the vehicle whether it's flying or not. This can lead to users messing up the trim values and their copters will not fly straight.

It's probably best to avoid this by:
1. only updating the trims if the vehicle is flying
2. improve communication with the user by sending text messages to the ground station (or add special autotrim status message) and adding some tone-alarm sounds (pixhawk only) as the process starts and finishes.

[Jonathan Challinger]

It is a bit silly. We could have an auto-level part of autotune that holds position and slowly rotates 360deg maybe 5-10 times, and averages the target tilt over that period.

We can do it at the same time we add station-keeping to autotune! Its like a unicorn!

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marco Robustini]

Hi Rob, imho AutoTrim is a great feature, absolutely necessary.
I also believe that the procedure is correct, and of course as many others do not allow errors, is normal.

Marco

[Holger Steinhaus]

I think the approach of in flight trimming by judging the position holding behavior in Stabilize/AltHold  (without yawing constantly as mentioned by Jonathan) is broken by design. Even 1 m/s of wind has 10 times more effect on position than lets say a trim deviation caused be an Pixhawk mounted 1° off from horizontal. And how many days do you have with less than 1m/s (I would estimate 10 per year here)? Even when yawing automatically while trimming I would expect that turbulence would lead to a rather random result when not averaging over at least a few minutes.

My trimming procedure currently is the following: place the copter on a table, align it perfectly level (I this nice device: http://www.hangar-9.com/Products/Default.aspx?ProdID=HAN192 , but a conventional bubble level will certainly do). Then, after some good time for IMU warmup, I manually adjust the AHRS_TRIM_ params, until the horizon is exactly zero on average. The result is nearly perfect for one of these rare days with zero wind (or when flying indoors) - never felt the urge to change a trim that I got in the described way. 

For my feeling, auto-trimming could be safely removed. 

Holger

[Leonard Hall]

This is the only method I use to trim the copter and strongly disagree that it should be removed (Marco and I both argued strongly to get it put back in last time this part of the code was updated). While there maybe some features that might make it safer for people that somehow enter it accidentally, I think it is a very valuable feature.

I use the yaw to the right for about 15 seconds after arming with the throttle at minimum. I use this because I don't have to specially set up a ch 7/8 switch before I do it. This means that I can get a reasonable level from the normal accel calibration routine then, when I find myself in some dead air, I can fine tune it to perfection.

Dead air is very regularly found early in the morning or in the evening in Australia and based on my interaction with RC and full sized glider pilots around the world, this isn't unusual.

[Jonathan Challinger]

All pretty moot before we have temperature stabilized IMUs, anyway. A 0.2 m/s/s change in bias error due to temperature will result in about 1 degree of trim error, causing your copter to fly away at about 20 cm/s/s. So, ignoring drag (which tends to be small at these kinds of speeds)
Second 1: 10 cm, 20 cm/s
Second 2: 40 cm, 40 cm/s
Second 3: 90 cm, 60 cm/s
Second 4: 1.6 m, 80 cm/s
Second 5: 2.5 m, 1 m/s

This, of course, increases if you get more temp drift than 0.2m/s/s

--

[David Price]

If it's a poll then I use the feature and feel it is very useful,. I've used it to set level quite a few times in the field

the problem about some people could put in this mode and cause themselves issue is the same argument for not having acro mode or a host of other things,. I think there must be some assumptions made that sometimes people will cause themselves issues and that will be part of their learning experience

[JOEL L SILVERMAN]

The Save Trim feature works well, and AutoTrim just seems to violate the KIS principle. I'd say go ahead and deprecate it.

Joel

[Josh Welsh]

Ever since I was introduced to this feature, I’ve used it religiously when setting up new copters as well as after making any changes to a copter.  Good on those folks who don’t feel its useful, there’s nothing saying anyone HAS to use it, but to remove it simply because some folks don’t use it doesn’t seem to bring any value.

 

I’m in favor of some kind of is_flying() check but the feature, especially as Leonard described with activating it, should not be deprecated.  If temp compensation goes in or there is a future change to Autotune that allows for station keeping as Jon described, then great, but for now the feature works quite well as-is.  Just because some folks don’t use it doesn’t mean it should be removed from the ones that do!  And I think the use-case Rob described is due to not using it properly, not with a defect in the option itself.  Could be wrong though!

--

[Robert Lefebvre]

Hey guys, calm down. ;)  Message received.  We honestly did not know if anybody was using it.  So I just asked the question.

I would like suggestions from the users about how to solve the issue here then.  One of the big problems really is that people who don't intend to user the feature, may accidentally get it, simply by a stick combination.  You know, I'm actually a pretty heavy user of the system, and I did not know that stick combination would enable it, until this issue was assigned to me!  So how many users really do?  I would like to make it so it can only be enabled by Aux Channel Function, but I can already tell Leonard won't like that.

So what is the solution?  We can't assume users have read the manual, fully, every single page.  And we can't assume they have a GCS connected.  If they can enable a feature by using a stick combination that is not unlike the normal arming procedure... it just seems a bit dangerous?  In the past, when users make mistakes with settings because they haven't read the manual, we use that as defence.  But this isn't the case of using a feature without reading it's instructions.  It's accidental usage of a function, because the setting is invoked with a normal stick combination.  This is a big part of the issue.  We can't say "you should read the instructions of the feature you are going to use", we would somehow need to force them to read the AutoTune page whether they want to or not.  At the very least, this needs a big red warning somewhere prominent in the wiki, on the same page we tell them how to arm.

And simply waiting until it's airborne doesn't solve the problem of accidental feature usage.  It just delays it.  It would help intentional users though, to not make a mistake on the ground.

[Leonard Hall]

This feature already requires the user to hold the yaw stick over for 15 seconds. Just make sure it really is 15 seconds, add a reversing beep sound to it, and call it done.

The user already has to hold the yaw stick over for 15 seconds with the throttle down, I don't have any idea why someone would do this.

To be honest I think this so rare it isn't a problem.

Leonard

[Robert Lefebvre]

Ok, sound would be another layer of protection.  Should we be stopping integration of the correction unless !ap.land_complete ?  There's no reason to accept correction inputs while on the ground?

[Leonard Hall]

Yeh, that sounds reasonable.

[Josh Welsh]

If people are doing it on the ground, add the is_flying check and then call that done. Weird case but I've seen weirder.

[Robert Lefebvre]

I don't know that anybody is doing it on the ground, but you just have to *touch* the pitch or roll stick to accumulate correction which is a bit sub-optimal.  I didn't write the issue, I'm just trying to solve it.

[Leonard Hall]

NOOOOOOO :)

The fact you only touch the sticks to make the adjustment is what makes it so accurate and nice to use. So don't change that mate.

Thanks for all your work mate!!!!

Leonard

[Robert Lefebvre]

You think it should continue to accumulate correction on the ground?  How would one assess the effectiveness of the correction on the ground?

[Randy Mackay]

Rob,

 

     Yes, I think that would be good.  We should also perhaps not start the timer until that flag clears (I think the user gets about 20sec of flight to set the trims).

 

-Randy

[Marco Robustini]

After reading all your comments i've changed my opinion, i agree with Rob, SaveTrim is necessary but AutoTrim might cause problems to inexperienced user.
Moreover many features can be made only from the GUI, as the compass calibration, that instead as DJI would require being able to do with the tx, would be more important, but they want these features combined with audible and visual indications that Pixhawk can give, to minimize possible errors.
Yaw left for 15 seconds is a command really hard to do unintentionally, but I know who did it and the results were guaranteed crash.
My two cents,

Marco


On Tuesday, March 17, 2015 at 9:21:29 PM UTC+1, robert.lefebvre wrote: