add gyro functionality

[mstrens]

In this issue, I propose to discuss the best way to implement gyro functionality

[Mike-HRC]

mstrens

here is an explanation of the latching - it would affect PID calculations

2. Stick priority controls how fast the Cortex "lets" go of the plane and stops stabilizing it. So the further one moves the sticks away from center the more the Cortex stops stabilizing the plane. In a 3D plane this setting is better if higher since a higher setting will cause the Cortex to let go of the plane earlier. Higher setting equals the stick taking priority.

3. Latching controls how fast the Cortex starts to stabilize the plane again as the sticks are returned to center. In a 3D plane this setting should be lower as a lower setting means it take longer or the sticks to be closer to the center before the Cortex starts to stabilize the plane again.

Mike

[mstrens]

About stick priority :

• I understand that when the correction on one axis is calculated on the PID, it is not always applied at 100% but with a ratio that depends on the original stick position;
• when stick is centered, we apply 100% of correction (but taking also care of the ratio provided by the global gain and of the per axis gain).
• When the "Stick priority" is set on 50% of max (= 10 on 20 in bavarian setup), does it means that if the stick is e.g at 75 % offset from the center, then the correction is not applied at all. When stick has less than 50% offset (e.g. 30%), the correction is apply proportionally to the offset (so with 40% if offset is 30%). Is this right?

About the latching control. It is not yet clear how this applies:

• does it means that when the stick was in a position (enough far away from center e.g. more than 50% in my previous example) where no correction was applied and then it moves again to the center, it has to be close enough to center (e.g. offset less than 25%) before a correction is immediately applied again. So this would be a kind of hysteresis.
• you said also that "it can take longer". Does it means that when the stick stays at e.g. 40% offset, then the correction foreseen for 40% offset will progressively be applied and reaches his "normal" value after some delay (e.g. 2 sec)

[aeropic]

I reset my pswd on Github :-)

stick priority : what I did on my prototype is working quite well in RATE mode. Define the Stick priority setpoint (eg 50%) this means that between neutral position and 50% the correction applied proportionally to the stick position. Above 50% the correction is 0. Yes a linear decrease of the correction is OK. If the user does not want any stick priority just set the setpoint at 1000% or so...

latching: It is not clear for me neither how it should behave. I understand this is mainly usefull for the HOLD mode to define the initial attitude. A kind of delay to learn in real time the new attitude setpoint. The delay should start when the stick is over the "stick prio" setpoint and returns to the neutral position. If we assimilate the stick order to an angular rate order, when the angular rate order is 0 (again) this means that the pilot has finished his manoeuver on the given axis.... Obviously this approach is very empiric: when hovering a 3D plan, I'm not sure the ELE sticks comes very often in neutral position !

[Mike-HRC]

Some of these vary from manufacturer to manufacturer - I have read of some that immediately over-ride all "corrections" if there is a stick input for that axis (I often have my gyros set up a low-ish gain so that it will pick up a big change, but I still correct small extraneous inputs myself - it helps the plane fly more naturally.

My understanding (perhaps wrongly) that it was how quickly / aggressively it corrects for wind. Some FBL systems had different modes for different types of flight - 3D flight might select "Mechanical" as it wants fast / aggressive corrections whereas for a war-bird the user might select "Fluid" which would give gentler, longer return to position to reflect scale flight. This would be reflected in different PIS settings for different styles.

Th 2 paragraph that I pasted earlier were copied from a Bavarian Demon thread on RCG explaining the Latching and stick priority. My assumption (based upon other gyros) is that these are used to change the "feel" of how the plane flies...

[mstrens]

@aeropic About stick priority: Flightstab code does not have this concept and applies the correction proportionally to the stick position (100% when stick is centered, 0 % when stick is at the end). I could add this parameter in a second phase.

Latching: I will not take care of this now.

I still have a conceptual issue. I will try to explain. This issue occurs when size of Pwm changes depends on the direction of the stick movement. Imagine a glider with 2 ailerons where we apply aileron differential in the handset mixer. Imagine that when Ail stick goes 100%

• to the left, left servo moves up and PWM changes from 1500 to 1900us. (so max travel = 400)

• to the right, left servo moves down and PWM changes from 1500 to 1600us. (so max travel = 100) Those values are registered during the learning process. The correction takes care of the original stick position (linear stick priority) and then is applied to each servo based on the rate discovered during the learning process.

  So, imagine that the original stick position is currently 1550. So oXs get a PWM value for left Ail of about 1540 (I did not calculate the exact value) For each axis, oXs calculates gyro corrections (in us) without taking care of the mixer. So it just like there is a 1 to 1 relation between the stick and the servo (with 100% mixing). Imagine that oXs calculated that a correction of 300 us should be applied to the right (as reaction of a wind effect). Please note that I take a quite big correction for the example but it could happens because the stick is nearly centered.

The easy way to apply the correction would be just to add (subtract). So the servo would get a value of 1540-300 = 1240us. It should be possible to limit it to the min value (=1600) but this would not be logic.

A more clever way (the one I expect to implement) is more complex and is the following. The original stick position (OP) = 1550. The expected position (EP) that the stick should have to apply the correction would be 1550-300 = 1250. As OP and EP are on opposite sides compared to the neutral position (1500), the correction will be split in 2 parts Upper (left) correction = 1500 - 1550 = -50 Lower (right) correction = 1250 - 1500 = -250. On the upper part, we take care of the max travel for moving left : -50 400 / 500 = -40 On the lower part, we take care of the max travel for moving right : -250 100 / 500 = -25 Then we sum the 2 parts -40 -25 = -65 And we apply it to the uncompensated PWM channel of ail left: 1540 - 65 = 1475us

[aeropic]

I understand the conceptual issue... My feeling is keep it simple. Apply the stick damping with only one coefficient : the max side one. Apply the same correction both sides of the given axis. If we get some ail differencial, I assume that compensations will be most of the case at small angles... Effect of differencial or not at compensation level should be neglectible...

[aeropic]

I looked at the code (not deeply enough for sure) and I have few questions/comments:

• param.h : I do not understand what is the enum STICK_GAIN_THROW for? What does throw mean ? Why setting discrete values 1,2,3,4 ?

• gyro.cpp : Are ...

  define IDX_AIL 0

  define IDX_ELV 1

  define IDX_RUD 2

  ... the index of AIL, ELV and RUD ?

• gyro.cpp correction and correctionpos/negside are expressed in microsec (+/-500 µsec ?), If yes I would add it in a comment: int16_t correction[3] = {0, 0, 0}; // gyro compensation applied to the 3 axis (micro seconds range -500/+500) int16_t correctionPosSide[3] = {0, 0, 0}; //gyro compensation after having taken into account possible differential on servos int16_t correctionNegSide[3] = {0, 0, 0}; // as above

• apply gyro correction rcPwmChannelsComp[i] = rcPwmChannels[i] = fmap( rcSbusOutChannels[i]) ; I'm not familiar with this double "=" syntax. Is it equivalent to those 2 lines ? : rcPwmChannels[i] = fmap( rcSbusOutChannels[i]) ; rcPwmChannelsComp[i] = rcPwmChannels[i]

• I need to understand what is calibration_wag : same for me ! from the code I understand it is shaking the axis (+/- 150 micro sec) and this every 200msec but what for ? To see if the gyro is compensating ?

So far no other comment... Good start :-)

[Zebble]

In case it helps, there's this code:

https://github.com/John-RB/FlightStab

It's a replacement firmware for some really simple gyro's (8-bit Atmel MCU's w/MPU6050). It works really well. Even includes firmware for programming boxes that work nicely in the field.

Nothing fancy. No stick priorities. Just master gain, individual gains and configuration of wing type (delta, v-tail, std).

-zeb

[mstrens]

Thanks for the feedback.

• parameter STICK_GAIN_THROW is used to manage the gain per stick depending on the position of the stick. // see enum STICK_GAIN_THROW. shift=0 => FULL, shift=1 => HALF, shift=2 => QUARTER //int8_t shift = cfg.stick_gain_throw - 1; int8_t shift = config.stick_gain_throw - 1;

  // stick_gain[] [1100, <ail*|ele|rud>_in2_mid, 1900] => [0%, 100%, 0%] = [0, STICK_GAIN_MAX, 0] stick_gain[0] = stick_gain_max - min(abs(ail_in2_offset) << shift, stick_gain_max); stick_gain[1] = stick_gain_max - min(abs(ele_in2_offset) << shift, stick_gain_max); stick_gain[2] = stick_gain_max - min(abs(rud_in2_offset) << shift, stick_gain_max);

stick_gain will give a % of correction on each axis depending on the position of the stick. stick_gain_max = 400 (number of us between mid and min). 400 means that correction has to be applied at 100% when stick is centered, stick gain will always be 400 (parameter has no impact) when stick is at 100%, stick gain will always be 0 (parameter has no impact) when stick is at 25% offset, stick offset = 100 us (nearly) and stick_gain = 300 (when param =1), or 200 (when param =2), or 100 (when param = 3). So this parameter allows to apply gyro correction on a smaller part of the stick offset.

[mstrens]

gyro.cpp : Are ...

define IDX_AIL 0

define IDX_ELV 1

define IDX_RUD 2

... the index of AIL, ELV and RUD ? It just a way to remember in which order the axis are define in some array (it is easier to read code)

[mstrens]

gyro.cpp correction and correctionpos/negside are expressed in microsec (+/-500 µsec ?), If yes I would add it in a comment: int16_t correction[3] = {0, 0, 0}; // gyro compensation applied to the 3 axis (micro seconds range -500/+500) int16_t correctionPosSide[3] = {0, 0, 0}; //gyro compensation after having taken into account possible differential on servos int16_t correctionNegSide[3] = {0, 0, 0}; // as above

This part has to be reviewed. I made an xls sheet to check the formula about splitting correction in pos and neg part. Code will be adapted.

[mstrens]

apply gyro correction rcPwmChannelsComp[i] = rcPwmChannels[i] = fmap( rcSbusOutChannels[i]) ; I'm not familiar with this double "=" syntax. Is it equivalent to those 2 lines ? : rcPwmChannels[i] = fmap( rcSbusOutChannels[i]) ; rcPwmChannelsComp[i] = rcPwmChannels[i]

YES

[mstrens]

I need to understand what is calibration_wag : same for me ! from the code I understand it is shaking the axis (+/- 150 micro sec) and this every 200msec but what for ? To see if the gyro is compensating ?

I am not sure buy I expect it is used during some manual set up. It probably move the servo to confirm that a command/setup has been applied.

[mstrens]

In case it helps, there's this code:

https://github.com/John-RB/FlightStab

It's a replacement firmware for some really simple gyro's (8-bit Atmel MCU's w/MPU6050). It works really well. Even includes firmware for programming boxes that work nicely in the field.

Nothing fancy. No stick priorities. Just master gain, individual gains and configuration of wing type (delta, v-tail, std).

-zeb

Thanks for the link. It is the one I used to define the main parameters and calculate corrections. On top of it, I try to avoid having to define the type and wing and let the gyro uses the mixers as defined on Tx side. For this I apply principles found in Bavarian gyro

[Zebble]

Thanks @mstrens.

Sounds great! If you need guinea pigs, I have a simple tester plane with elevons...

-zeb

[aeropic]

Thanks for the feedback.

• parameter STICK_GAIN_THROW is used to manage the gain per stick depending on the position of the stick. // see enum STICK_GAIN_THROW. shift=0 => FULL, shift=1 => HALF, shift=2 => QUARTER //int8_t shift = cfg.stick_gain_throw - 1; int8_t shift = config.stick_gain_throw - 1; // stick_gain[] [1100, <ail*|ele|rud>_in2_mid, 1900] => [0%, 100%, 0%] = [0, STICK_GAIN_MAX, 0] stick_gain[0] = stick_gain_max - min(abs(ail_in2_offset) << shift, stick_gain_max); stick_gain[1] = stick_gain_max - min(abs(ele_in2_offset) << shift, stick_gain_max); stick_gain[2] = stick_gain_max - min(abs(rud_in2_offset) << shift, stick_gain_max);

stick_gain will give a % of correction on each axis depending on the position of the stick. stick_gain_max = 400 (number of us between mid and min). 400 means that correction has to be applied at 100% when stick is centered, stick gain will always be 400 (parameter has no impact) when stick is at 100%, stick gain will always be 0 (parameter has no impact) when stick is at 25% offset, stick offset = 100 us (nearly) and stick_gain = 300 (when param =1), or 200 (when param =2), or 100 (when param = 3). So this parameter allows to apply gyro correction on a smaller part of the stick offset.

Thanks for your answers. Not sure I've all understood, I have to draw some curves... ! Anyway my concern was just to avoid steps on the values of gains. A continuous variation of gains function of the sticks inputs is needed to avoid jerky servos. But maybe this Algo gives a continuous gain...

[aeropic]

I need to understand what is calibration_wag : same for me ! from the code I understand it is shaking the axis (+/- 150 micro sec) and this every 200msec but what for ? To see if the gyro is compensating ?

I am not sure buy I expect it is used during some manual set up. It probably move the servo to confirm that a command/setup has been applied.

Yes, for sure it is to get a visual feedback when teaching different axis...

[mstrens]

Thanks for the feedback.

• parameter STICK_GAIN_THROW is used to manage the gain per stick depending on the position of the stick. // see enum STICK_GAIN_THROW. shift=0 => FULL, shift=1 => HALF, shift=2 => QUARTER //int8_t shift = cfg.stick_gain_throw - 1; int8_t shift = config.stick_gain_throw - 1; // stick_gain[] [1100, <ail*|ele|rud>_in2_mid, 1900] => [0%, 100%, 0%] = [0, STICK_GAIN_MAX, 0] stick_gain[0] = stick_gain_max - min(abs(ail_in2_offset) << shift, stick_gain_max); stick_gain[1] = stick_gain_max - min(abs(ele_in2_offset) << shift, stick_gain_max); stick_gain[2] = stick_gain_max - min(abs(rud_in2_offset) << shift, stick_gain_max);

stick_gain will give a % of correction on each axis depending on the position of the stick. stick_gain_max = 400 (number of us between mid and min). 400 means that correction has to be applied at 100% when stick is centered, stick gain will always be 400 (parameter has no impact) when stick is at 100%, stick gain will always be 0 (parameter has no impact) when stick is at 25% offset, stick offset = 100 us (nearly) and stick_gain = 300 (when param =1), or 200 (when param =2), or 100 (when param = 3). So this parameter allows to apply gyro correction on a smaller part of the stick offset.

Thanks for your answers. Not sure I've all understood, I have to draw some curves... ! Anyway my concern was just to avoid steps on the values of gains. A continuous variation of gains function of the sticks inputs is needed to avoid jerky servos. But maybe this Algo gives a continuous gain...

This give a continuous gain on a range selected by the user (on whole range of the stick, on first 50 % only, on first 25% only)

[mstrens]

I put on Rc groups a proposal on the way to execute the learning process. It seems me reasonably simple. Comments are welcome.

[mstrens]

So the bug is probably when I reused the PIO/SM from GPS. I will try to check it but I am not available this PM and I also try to concentrate on gyro up to some clean point.

So I also presume that there is no issue with the sdk being used. It is only oXs related (and depend on options activated in config)

[Satcomix]

Thanks for the info, I can't test this evening either because work calls. I would have time again from tomorrow morning.

[aeropic]

gyro HOLD conceptual question If I understand well, the gyro compensation in HOLD mode is based upon gyro angular rates (gyroX/Y/Z) and some gyro gains config.vr_gain[i] all this inserted in a PID loop. There is no absolute attitude but only integrated angular rates...

Don't you fear some drift after few seconds of integration?

At the opposite the estimated attitude (the one used in camera stab) is computed in the OXS Mahony filter taking into account the 3 gyro rates and the 3 accelero data. The Mahony filter thus recalibrates the initial attitude of the gyro trying to avoid drifts. Of course, in yaw, the accelero is blind if the plane flies level and this is the reason why you observe some drifts in yaw in OXS.

But with the PID algo based only on gyro rates, I'm afraid all axis will drift?

Do I miss something ?

[mstrens]

You are right. Still I think (not 100% sure) that there are 2 different concepts HOLD and STABILIZE that differs when sticks are moved and then release to center. In HOLD, when sticks are centered after having been moved, the gyros tries to keep the current position (the one when sticks have been released). Indeed in HOLD mode with stick centered, there could be slow change of attitude but this has to be corrected from time to time by the pilot.
In STABILIZE, when sticks are centered after having been moved, the gyro tries to set the plane hozizontal (so corrections are based on the plane attitude and not on gyro rates).

I am not sure that it makes sense to ask the gyro to maintain the attitude of the plane as it was when HOLD has been engaged if the sticks have been off center in the meantime.

Perhaps I am wrong. I have no experience with gyro.

[aeropic]

From what I understand with the definition you give of HOLD and STABILIZE, both modes share the same equations , the only difference is the setpoint attitude. In Hold, it is the last attitude when stick was centered. The gyro tries to keep the last attitude. In STABILIZE, whatever the intital attitude, the gyro tries to keep the plane horizontal. Except from the setpoint (last attitude/horizontal) both shall be based on an absolute attitude estimation. Any drift of gyro due for instance to a bad estimate of the scalefactor or to integrated numerical errors, will be translated into a drift of attitude. This will be the case unless an absolute attitude sensor (for us an accelero able to sense and estimate the gravity vector) will reinitialize the gyro from time to time (job of the inertial measurement Unit filter for us the Mahony filter).

This is the reason why the RATE mode is much simpler to code and make it work. The gyro only removes the wind and compensates angular rates. When a plane is stabilized, whatever its attitude, the angular rates are equal to zero. For this mode using only gyroX/Y/Z is fine.

RQ: I worked in Space business, in satellites we get the same issues. gyros are drifting, we compensate all this inside a big kalman filter which is mixing gyro values and absolute attitude given by star trackers. Star trackers may be unlocked, unable to find the attitude, when the satellite is rotating too fast, during those periods of time, the kalman relies on gyro angular rates to estimate the attitude. When the satellite attitude is quiet, star trackers give again an attitude measure which is used by the Kalman filter to reinitialize the gyros... gyros are good for high frequencies while absolute sensors (acceleros, star trackers) are noisy but good in low frequencies...

[Satcomix]

Hello Aeropic, "RQ: I worked in Space business, in satellites.....", welcome to the club :-)) Look at my nickname and cross out the last two letters (ix) Greetings, Torsten

[aeropic]

Hi Torsen, For me it was Earth Observation sats ... We will open a club indeed ;-)

[Mike-HRC]

You are using the terminology differently to how most people use it for gyros (plane or FBL), generally

Stabilised - means correction of changes of attitudes due to "outside forces" (wind, turbulence etc.) in this case the gyro will generate "corrections" to counter the "outside force", it does not know or care then attitude of the plane or if it is level. This is what AS3X does and how most people fly with gyros - much less set-up needed. This is only using the 3-axis gyro.

Auto-level - in this case the gyro will try to return the plane to the attitude that it learned at set-up time (i.e. flat and level) - this uses 6-axis gyros to learn flat and level in the initialisation. This is used mainly by beginners or as a "rescue" if people get badly out of shape. I have heard of many gyros struggling in this mode.

Hold - not many gyros have this - it is similar to "Heading Hold" where the gyro will try to keep the plane at the attitude commanded when the last stick input was received (i.e. not necessarily flat and level).

These are certainly the way that the different modes are know in HobbyEagle, FrSky, Spektrum and most heli FBL units that I know

[Zebble]

The terminology seems to be used inconsistently, which makes it even more confusing. @Mike-HRC 's description is what sits in my brain too. Some differences I've seen:

Stabilised = Normal, Auto-Level, Rate Auto-Level = Stabilised, Trainer, or often combined with Angle/Horizon or other modes Hold = Lock, POS, 3D

I know the code @mstrens is using has both Rate and Hold modes and I'd be happy with just the Rate mode.

[mstrens]

Thanks for the clarification. I expect that most gyro in HOLD mode uses only the rates (angles/sec) provided by the sensor. And that they accept a low drift. This is for sure the way flightstab gyro program works.

This would for sure not be the case in AUTO_LEVEL mode.

[mstrens]

FYI, I put on github test a version 2.9.5 with some more code in order to support a gyro. You can test it if you want but take care:

• there are for sure many bugs (I did not yet tested)
• there are no USB commands to edit the parameters that should be stored in the config. Currently you have to edit 4 define in gyro.cpp in function initGyroConfig(); Currently I put:

  define GYRO_CHANNEL_CONTROL 9 // 0 means channel 1

  define GYRO_CHAN_AIL 10 // 0 means channel 1

  define GYRO_CHAN_ELV 11 // 0 means channel 1

  define GYRO_CHAN_RUD 12 // 0 means channel 1

• there are dummy parameters for gyro mixers (only one Ail is compensated). You can edit the function initGyroMixer() to add more corrections or you can try the learning process. This process is coded but the result is not yet saved in flash. You can still see the new (current) parameters with the ENTER usb command.

To test it you have to connect oXs to a receiver with a wire that provides Rc channels (sbus,, fbus,...) and to a MPU6050 (scl/sda)

Note: the learning process has been modified. Please read the file "gyro concepts.md" in the folder "doc" The led changes in the learning process are not yet implemented.

[aeropic]

It compiles ! I will test it tomorrow. Thanks

[aeropic]

just one question, the switch used to program the mode is a 3 positions switch ? The OFF position is the middle one ? During learning process, to which position shall we turn the switch ? To full 100% or -100% or it doesn't matter ?

[mstrens]

The switch is a 3 pos. When the Rc value is 0% ,it means OFF Positive Rc values (>0%) are for Normal mode; the value between 0% and 100% gives the general gain in this mode (100% = max gain). Negative Rc values are for Hold mode; the value between 0% and -100% gives the general gain in this mode (-100% = max gain in hold mode). Depending on the way you define the RC values for the 3 positions in the handset, you can set OFF in any of the 3 positions. The easier solution (for the mixer on handset) is still to use the middle pos for OFF

[aeropic]

perfect thanks! I assume that during learning process the 4x switchs ON/OFF are NORMAL/OFF positions? (I will try)

[mstrens]

I do not understand the question. There are not 4 X switchs. Just one that has 3 pos. For the learning process, it does not matter in which position you set the switch. You have to change from normal to hold or the opposite at least 5 times within 5 sec to start the process. And then to change once more to start step 2 and once more to close the process. Only changes from NORMAL to HOLD and the opposite are considered as a change (OFF is discarded to count the transitions). So if OFF is in the middle, moving UP - MIDDEL - UP does not count as a change. Moving UP - MIDDEL - DOWN is counted for 1 change. Moving DOWN - MIDDEL - UP is also counted for 1 change. Moving UP - DOWN is also counted for 1 change. Moving DOWN -UP is also counted for 1 change

[aeropic]

Sorry, I was not clear but you answered my question : "For the learning process, it does not matter in which position you set the switch. You have to change from normal to hold or the opposite at least 5 times within 5 sec to start the process. Only changes from NORMAL to HOLD and the opposite are considered as a change (OFF is discarded to count the transitions)."

The 4x in my question was refering to the number of changes hold/normal required to start the process. in the gyro_concept.md I read : "To start the learning process, the user has to simultaneously to:

• put AIL and RUD sticks in right corner
• put ELV stick in up corner
• move the switch used to control the gyro mode more than 4 X within 5 sec. And more than 4x is at least 5 times (I get it !!!!)

[aeropic]

one set of questions for the channels used:

[aeropic]

define AIL1_CHANNEL 0 //here the ID of the output channels where compensation apply

#define AIL2_CHANNEL 4
#define ELV1_Channel 1
#define ELV2_Channel 8
#define RUD_Channel 3

It's written this is the output channels where compensation apply. That's clear. I assume I can also use them as input channels from TX to OXS before compensation is applied ?

While those are the "raw" stick values ?
#define GYRO_CHAN_AIL 9 // 0 means channel 1
#define GYRO_CHAN_ELV 10 // 0 means channel 1
#define GYRO_CHAN_RUD 11 // 0 means channel 1

Am I right ?

[aeropic]

Well, I tried it, but I'm not sure it was successfull as I don't see any change in the display here: Config parameters are OK Press ? + Enter to get help about the commands Gyro configuration is: Channels for : gyro control=13 , Ail stick=10 , Elv stick=11 , Rud stick=12 PID Kp Ki Kd Normal Roll 500 0 500
Normal Pitch 500 0 500
Normal Yaw 500 0 500
Hold Roll 500 500 500
Hold Pitch 500 500 500
Hold Yaw 500 500 500
Gain per axis (-128/127): Roll=127 Pitch=127 Yaw=127 Gyro corections on 1 (1=on whole stick, 2=on half, 3=on a quater)

Gyro mixers are calibrated: Gyro corrections (%) on: Channel 1 center=0 rollRight=-79 rollLeft=58 pitchUp0 pitchDown=0 yawRight=0 yawLeft=0 min=-100 max=99

[mstrens]

In fact you MUST use them as input channels before compensation. The same are used to output PWM. You still have (as usual) to specify the gpio where the PWM will be generated for the channels driving a servo.

PS: I started testing and It is not OK. When I have some progress (e.g. learning process working) I will update on github

[mstrens]

I put 2.9.7 on github. With this version I can execute the mixer calibration (learning process) and see the result. There are some messages useful to follow the steps at this stage. They could be removed afterwards.

There are still some issues:

• Changing the LED color during the process does not yet work (some code but wrong)
• the result is not yet saved (no code yet)
• leaving the first step before all 7 steps have been performed does not work as expected (should avoid some error messages)

I did not yet stated tests about the gyro corrections.

[mstrens]

I put 2.9.8

LED is OK It is now possible to start twice the mixer calibration No other changes.

[aeropic]

Oh YES, it's working now. (2.9.7) I did my first calibration Gyro mixers are calibrated: Gyro corrections (from center pos in %) on:
Channel 1 center=0 rollRight=-79 rollLeft=58 pitchUp0 pitchDown=0 yawRight=0 yawLeft=0 min=-79 max=78
stabMode changed to 1 stabMode changed to 0 stabMode changed to 1 stabMode changed to 0 stabMode changed to 1

The learning process started centered Rud left Ch1=1500 Ch2=1500 Ch3=988 Ch4=988 Elv down Ch1=1250 Ch2=1250 Ch3=988 Ch4=1465 Elv up Ch1=1743 Ch2=1744 Ch3=988 Ch4=1500 Ail right Ch1=1750 Ch2=1250 Ch3=988 Ch4=1500 Ail left Ch1=1255 Ch2=1745 Ch3=988 Ch4=1500

I'll jump into 2.9.8

[aeropic]

It's very cool to see the LED changing... I'm here : The learning process started centered Rud left Ch1=1513 Ch2=1514 Ch3=988 Ch4=988 Rud right Ch1=1488 Ch2=1488 Ch3=988 Ch4=2011 Elv up Ch1=1746 Ch2=1746 Ch3=988 Ch4=1500 Elv down Ch1=1253 Ch2=1253 Ch3=988 Ch4=1500 Ail right Ch1=1750 Ch2=1250 Ch3=988 Ch4=1500 Ail left Ch1=1250 Ch2=1750 Ch3=988 Ch4=1500 Cal mixer is done; switch may be changed Cal mixer is done; switch may be changed Cal mixer is done; switch may be changed Cal mixer is done; switch may be changed Cal mixer is done; switch may be changed

Second step of learning process started

Gyro calibration: Stick Ail_Right on channel 10 at 99
Stick Elv Up on channel 11 at 99
Stick Rud_Right on channel 12 at 99
Gyro corrections (from center pos in %) on:
Channel 1 center=0 rollRight=48 rollLeft=-49 pitchUp48 pitchDown=-49 yawRight=-3 yawLeft=2 min=-100 max=99
Channel 2 center=0 rollRight=-49 rollLeft=48 pitchUp48 pitchDown=-49 yawRight=-3 yawLeft=2 min=-100 max=99
Channel 4 center=0 rollRight=0 rollLeft=0 pitchUp0 pitchDown=0 yawRight=99 yawLeft=-100 min=-100 max=99
Channel 5 center=0 rollRight=-100 rollLeft=99 pitchUp0 pitchDown=0 yawRight=0 yawLeft=0 min=-100 max=99

End of learning process

I do not exactly remeber what we have to do in the second step ? I moved the sticks by pair to the corners but nothing changed... I then moved back the switch and it displayed this...

Anyway, huge progresses with this version! Kudos

EDIT: no effect of gyro motion on the ouputs...

re-EDIT: mixers progrmmed in EDGE-TX are: AIL = 50% AIL + 50% ELE ELE = 50% ELE -50% AIL RUD = 100% RUD

So I think it captured quite a good matrix :-)

[mstrens]

The second step is foreseen to get the opportunity to detect extended servo limits. Can be useful e.g. for a V stab where ELV and RUD stick alone does not reach the end point (min max) defined in the handset. When the 2 sticks are moved simultaneously, oXs can discover other limits for the Rc channels impacted by the gyro.

[mstrens]

What is your channel 5? Why does it change with the Ail. Is it just for a test?

[aeropic]

Ah OK I rembember now, so we have to move by pairs to corners. I expected some debug messages to show the progress, but useless as it is working fine.

My edge tx is AETR 1 = AIL1 2 = ELE 3 = Throttle 4 = RUD Then I add the other servos 5 = AIL2 6 and 7 = flaps

==> it is normal AIL2 moves with AIL1 even if with a delta mix, ther is no need of AIL2 ;-)

[aeropic]

With a very simple plane (AER, no mix) do you think we can avoid the extra channels copies of stick inputs and set them to the mixed inputs channels? Something like that

define AIL1_CHANNEL 0 //here the ID of the output channels where compensation apply

define AIL2_CHANNEL 4

define ELV1_Channel 1

define ELV2_Channel 8

define RUD_Channel 3

define GYRO_CHAN_AIL 0 // 0 means channel 1

define GYRO_CHAN_ELV 1 // 0 means channel 1

define GYRO_CHAN_RUD 3 // 0 means channel 1

[aeropic]

### simplification proposal I do not understand the need to have a switch change to enter second step. From what I understand, OXS automatically detects the end of previous step (see code here after). It even asks to change the switch. // detect when all cases have been performed at least once (all flags are true) if ((centerFlag==true) && (rightUpFlags[0]==true) && (leftDownFlags[0]==true)\ && (rightUpFlags[1]==true) && (leftDownFlags[1]==true) && (rightUpFlags[2]==true) && (leftDownFlags[2]==true)){ ledState = STATE_GYRO_CAL_MIXER_DONE; learningState = LEARNING_MIXERS_DONE; // this will change the led color static uint32_t prevPrintMs = 0; if ((millisRp() - prevPrintMs) > 1000){ //printf("Ail=%i Elv=%i Rud=%i\n", stickPosUs[0] , stickPosUs[1] , stickPosUs[2] ); printf("Cal mixer is done; switch may be changed\n"); prevPrintMs=millisRp(); }

    } 

Wouldn't it be simpler to automatically go into next step? something like: (maybe adding some delay and other needed initializations)

// detect when all cases have been performed at least once (all flags are true) if ((centerFlag==true) && (rightUpFlags[0]==true) && (leftDownFlags[0]==true)\ && (rightUpFlags[1]==true) && (leftDownFlags[1]==true) && (rightUpFlags[2]==true) && (leftDownFlags[2]==true)){ ledState = STATE_GYRO_CAL_MIXER_DONE; learningState = LEARNING_MIXERS_DONE; // this will change the led color static uint32_t prevPrintMs = 0; if ((millisRp() - prevPrintMs) > 1000){ //printf("Ail=%i Elv=%i Rud=%i\n", stickPosUs[0] , stickPosUs[1] , stickPosUs[2] ); printf("Cal mixer is done; switch may be changed\n"); =======> learningState = NEXTSTEP ; <=============== prevPrintMs=millisRp(); } }

[mstrens]

oXs uses some margin to detect the end and center positions. Imagine that the margin is 5% It means that e.g. when ail is already at 95%, oXs consider that stick is the corner and set a flag to say that this case is done. Even if the flag is already set, oXs continues to look if the stick is moved further (e.g. up to 98%) and if so register the channels from this position.

The idea is also that the user does not have to look at the LED (some board does not have a RGB led). So it is easier (and safer) for the user to decide him self when he switch from one step to the next one. I think that the process is reasonably simple: activate switch to begin (5X or +) and to change from one step to the next one., This let him also the opportunity to make as many moves he want during the first step to be sure all cases are registered.

About you previous question about avoiding having to use 3 channels to know the stick positions for a basic plane. it would make the program significantly more complex because it requires a completely set of rules and some extra parameters. So I prefer to avoid it.