Inflight ACC-calibration

[Hamburger]

Jevermeister,

it seems your auto leveling code has gone a long way. I would like to chime in, if you don't mind. Your thread had started me thinking about it - especially when last time I did level-tuning with fly-land-disarm-sticks-arm cycle over and over again.

1.
your code is about the acc (level) calibration done during flight instead of iteratively changing offsets with THR-up + PITCH/ROLL increments while disarmed, right?

2.
Idea: Basically just fly and whenever you think copter is in a good level, hit the 'snapshot level' button on your TX and be done.
the procedure I would like to see is
a. fly copter in level mode
b. use sticks for yaw, nick, roll so copter is trimmed out
c. take 'level snapshot': push button or flick switch at TX (auxN) to take current RX-values and change mwii internal offsets accordingly (and write them to eeprom)
done.

As always, this LearnLevel function could be assigned to any AUXn high/mid/low value the user wanted.
Actually, what I describe is much more. It could the same way be used as a direction hold. Set copter according to wind into direction, learn, and fly with that orientation without any more active stick input (apart from throttle).


Now, I am not sure if this is that much different from what you described. My description is shorter and the usage procedure seems simpler?

[jevermeister]

I am happy you are joining us.

1. You are right: I compute the offset to the current ideal position and safe it to eeprom.
2. I use acro mode to find the perfect function because I use the failsafe to trigger the offsetmeasurement. I did this to avoid using aux and block other functions.
Problem is: my Aux1 is: OFF, ARM+ACRO ARM+HOVER.
Leveling out in Acromode is pretty easy but I can try your way too. Either use failsafe trigger or an aux switch.
- writing to eeprom should be done while on the ground, sometimes the cicletime increases drastically and you might crash...

Can you descirbe you last statement reagird the wind for stupid people like me .

nils

[Hamburger]

I am happy you are joining us.

Nils, my pleasure. I got bored with the current level tuning procedure lately. I read you are close to submitting your version to _shared. So bear with me if what I write has been thought through before (I am late and maybe just catching up).

1. You are right: I compute the offset to the current ideal position and safe it to eeprom.
2. I use acro mode to find the perfect function because I use the failsafe to trigger the offsetmeasurement. I did this to avoid using aux and block other functions.
Problem is: my Aux1 is: OFF, ARM+ACRO ARM+HOVER.
Leveling out in Acromode is pretty easy but I can try your way too. Either use failsafe trigger or an aux switch.

For me, I almost always fly in level and that is when I want this learn-level function.

- writing to eeprom should be done while on the ground, sometimes the cicletime increases drastically and you might crash...

yes, writing to eeprom is slow. You could drastically reduce time required if you only wrote the relevant 4 (?) bytes. Not sure how to compute the relevant offfsets into eeprom.

Can you descirbe you last statement reagird the wind for stupid people like me .

I thought of flying in windy conditions. To hover stationary, you have to apply some nick/roll constantly. Provided you can keep heading, you could learn-level the neccessary tilt angles by pressing that tx button and from then on use that as your new level-values (and not have to fight the wind as long as you head in same direction)

Let me ramble on and offload some thoughts:
you do use the angle trims for this, right?
Just a thought, we could instead read the deltas for rx-inputs from midrc for yaw,nick,roll. Not sure how that would differ.
Second:
About using the new learnt offsets right after pressing the tx-button:
- need to find a good time for writing to eeprom, or maybe not if it is easy enough to do during flight
- after having learnt the new offsets (either for angles or rx-inputs); should these be applied right after that? Beware, the pilot still gives some tx-input for nick&roll like before; but that is not required anymore -> copter shoots in that direction; maybe not good.
But maybe not too bad, if the original tilts wer not too extreme. So a good idea to instantly use the new learnt offsets.

I would like to have the system learn the yaw value delta from midrc the same way. For TRIs I have made the servo midpoint value a configurable item already (via LCDconfig).
About how to trigger the learning of the offsets to level :
the procedure you have described earlier using failsafe sounds kinda scary to me. It is so contra to usual flight behaviour. I think having an auxN button/switch is much more following the usual user experience. Again, using an auxN switch brings up a question: detect the change of this auxN state and do the learn-level thing once and from then on ignore the auxN status? Or start learning constantly and take the last (averaged?) values before the auxN state is left again?

aux buttons - we are short on those always. So the sequence you described would help with that.

My expectation on a use case would be:
1. fly as much as I want, then fly level (in acro or level mode) and suddenly decide 'want to learn this as level'
2. hit button/flick switch (or trigger another way, but stick combos are no-go during flight)
3. at that moment of positive ramp up of signal take offsets
4. use learnt offset from that moment on (yes, if flying in level mode, expect some unwanted movement before pilot moves sticks back to center)
5. ignore auxN from then on (unless switched off and on again - new positive ramp up)
6. at disarm, write offsets to eeprom
7. if you know you made mistake/do not like the level offsets, then do calib acc; it zeroes out the acc trim values.

What do you think?

[Noctaro]

Hey,
i did read your posts about auto level.
Are you sure it would be an good idea to have a constant level offset? Think of landing, or windspeed drops (Maybe an angle limitation?)(GPS should be able to counteract wind also)
If you land and do forget that you have applied a big offset, wouldnt it drift off as crazy at next startup? Will eeprom be cleared?
What if pulling the wrong aux switch during flight, would we have to counteract the new level position?

greetz,
Noctaro

[jevermeister]

Hey,
i did read your posts about auto level.
Are you sure it would be an good idea to have a constant level offset? Think of landing, or windspeed drops (Maybe an angle limitation?)(GPS should be able to counteract wind also)
If you land and do forget that you have applied a big offset, wouldnt it drift off as crazy at next startup? Will eeprom be cleared?
What if pulling the wrong aux switch during flight, would we have to counteract the new level position?

greetz,
Noctaro

I wanted to say the same,
just think of an offset to the west, and you accidently turn your copter and have wind from west and an offset to the east, you will definetily loose the copter, it happenend to me once, I pushed hard against the wind and accidently jawed , I was unable to recover the drift and the copter crashed badly.

I will try to do the following:

Arm the function alike I do now to use the failsafe method to store the offset.
additionally I will include the aux switches.
I will test storing to eeprom inflight, but I do not think this is a good idea because you are still correcting the drift with the tx and suddenly the drift is gone, because the new trimming kicks in, so you will drift to the opposite site without doing somethin, some people might be confused and crash.

cya
Nils

See u later.

[Hamburger]

ok, you code, so you decide. (and it is open source, so we get to change).
Go for it and let Alex have his say so.

[jevermeister]

Hi,
I just tested it, EEPROM writing while airborne is a really bad idea I was lucky nothing was broken.
Your Idea of changing a single variable sounds good, but I have to ask alex how to do it.

I did the following:
Armin the function over combo sou you can use the failsafe method.
Alternatively: Flick a switch while flying and hover without drit and the offset is stored, land and flick the switch back. Values are stored to eeprom.
Now I need a aux binding in the GUI.
@Alex, can you give me a variable and a representation for this function in the coming gui?

Nils

[Hamburger]

you can add another var to the checkboxes mechanism yourself. We changed the code to make that a lot easier than it was before.

[jevermeister]

Okay, and does it show up in the gui aotmatically!?

About the checkin:

1.Checkout the shared trunk
2.applay the changes
3.commit changed checjout into shared tunk

Correct!?
Nils

[Alexinparis]

Hi,
I would prefer to not add another checkbox item for this. The GUI is nearly full...
You can maybe use the pass trough checkbox: this checkbox is only relevant for fix wing configs and has currently no usefulness for multi rotor configs