Open mstrens opened 1 year ago
I understand now, its a converging learning process, hence the need to stop it when the user wants... Very clever !
For my second question, I do not want to change anything in the code, just use it as is but with the sticks inputs channels the same as the mixed ones... The question was rather
For the second question, I do not think that the program could crash. The issue is to detect the neutral, min and max positions. If the user had to trim the model, oXs would not detect the center positions. The same for the end positions if the user limit the movement with mixer ratio or with min/max. So the learning process will fail in most cases (not detecting the 7 cases). For a simple model without mixers between 2 sticks, this should be possible in you add a parameter to inform oXs that this scenario has to be used. It would also require one more step in the learning process to identify the neutral position.
I do not see real advantage because for a simple model, there is plenty of channels available so using 3 for stick positions is not an issue.
You're right, center positions in case of trims will make the learning process fail...
Speaking of trims, where does trimming fit in the process? I assume we fly the plane without gyro and trim it, then run the calibration so the new neutral is detected during calibration? What if we have to adjust the trim after that? Do we fly without gyro again, trim it and repeat the calibration process?
Flex Innovations' Aura series has a "quick trim" function you can perform after you land. On the FT Aura 5 this is done by:
The idea is that the radio is always at zero-trim. The gyro handles the actual trim. I assume in this case we wouldn't want to have the trims on the gyro, just know that neutral has changed?
-zeb
Speaking of trims, where does trimming fit in the process? I assume we fly the plane without gyro and trim it, then run the calibration so the new neutral is detected during calibration? What if we have to adjust the trim after that? Do we fly without gyro again, trim it and repeat the calibration process?
Flex Innovations' Aura series has a "quick trim" function you can perform after you land. On the FT Aura 5 this is done by:
- Press and hold the TRIM button (LED slow flashes)
- Press and hold the TRIM button again (LED fast flashes)
- Zero the trims on your radio
- Press and hold the TRIM button again to restart with new trims.
The idea is that the radio is always at zero-trim. The gyro handles the actual trim. I assume in this case we wouldn't want to have the trims on the gyro, just know that neutral has changed?
-zeb As said in the concept I am developing, oXs has to know the "original" stick positions (so the values when there is no mixer, no min/max applied) in 3 extra Rc channels.. With openTx, Edge, Ethos and probably other, it is possible to let the handset send those value without taking care of the trim. In this case, if the user move the trims after the "learning" process, I expect it should have no impact on the gyro corrections.
If the handset does not allow to sent stick positions without the trim, then it makes sense to make a new "learning" process even if it should not have a big impact because it is limited to the value of the gains being applied (I think).
As said in the concept I am developing, oXs has to know the "original" stick positions (so the values when there is no mixer, no min/max applied) in 3 extra Rc channels.. With openTx, Edge, Ethos and probably other, it is possible to let the handset send those value without taking care of the trim. In this case, if the user move the trims after the "learning" process, I expect it should have no impact on the gyro corrections.
If the handset does not allow to sent stick positions without the trim, then it makes sense to make a new "learning" process even if it should not have a big impact because it is limited to the value of the gains being applied (I think).
I've used openTx/Edge/Ethos exclusively and had no idea you could output the "original" stick positions! Interesting. It won't work for stuff like mid/low-end Spektrum.
For Rate mode, adding trim I don't think will make any difference. For Hold, it might (ie. the gyro needs to know when the stick is neutral so it can start maintaining position). Some gyro's get around this by adding a "center dead-band" where it will assume the stick is neutral within that band. Still, might be better to have some sort of learning process for any trim changes?
I think that some gyro have a process where the "center" position is reset (based on the trim) when the switch controlling the gyro mode is switched e.g. more than X time within y seconds while sticks are not to far from center.
This could be implemented. Thanks for the idea.
I'm more concerned by huge mixings (crows on a glider) than with the effects of trims... As long as we input the mixed TX outputs and that the gyro compensation is added on top, I think too that the trims will be applied to the mixed outputs and do not need to be changed for the gyro (at least for RATE mode).
I repaired a very old crash proof 3D plane which is not really stable when wind is blowing. I'm ready to experiment in flight with it ;-)
Just for information, I build a second OXS with the GY86 board. It works fine but after the gyro learning process, I get jerky servos in both modes. While with the other board the gyro has no effect on the servos.
Both boards with my gyro code behave the same...
Version 2.9.10 does not work properly. During the copying process/flash device, all settings except the sequencer were deleted. After entering PRI= and PROTOCOL= and all other entries, the LED only lights up red and no telemetry is transmitted, because the I2C Bus is not initialized.. No SBUS_OUT
Lost of all settings (except sequencer) is "normal" because it is a "major" release for the config parameters. In principe, new entries are stored and restored during next reflash.
I will try to see why led stay red (e.g. do you get a message saying that config is valid)?
Since switching to "pio_sm_set_enabled(gpsPio, gpsSmTx, false);" The GPS no longer initializes with 10Hz
Error in parameters: when gyro mode/gain Rc channel is defined (not 255), all 4 channels must be different from each other
Attention: error in config parameters Press ? + Enter to get help about the commands
Since I'm not a model pilot, Could you please fill out the settings for the next tests here?So that I understand it, thank you.
Gyro mode/gain GMG = YY To select mode/gain
Gyro Stick Aileron GSA = YY Gyro only : Original aileron stick (without mix/limits/trim)
Gyro Stick Elevator GSE = YY elevator
Gyro Stick Rudder GSR = YY rudder
Gyro Gain on Roll GGR = YYYY Gain on roll axis (-127/127)
Pitch GGP = YYYY pitch
Yaw GGY = YYYY Yaw
Gain on stick Throw GGT = Y 1 (corr. on full throw) , 2 (on half) , 3 (on quater)
Max Rotate GMR = Y 1 (Very low) , 2 (low) , 3 (medium) , 4 (high)
stick Rotate Enable GRE =Y 1 (disabled) , 2 (enabled)
2.9.10 working here but I had to clear the errors in config with commands
GSA = YY
GSE = YY
GSR = YY
And with these, the MPU was recognized. Before those commands no gyro no accelero detected
@satcomix Just set GSA=10 GSE=11 GSR=12 which are the channels (for me) where I copy the original sticks inputs.
Error in parameters: when gyro mode/gain Rc channel is defined (not 255), all 4 channels must be different from each other
This should be solved by version 2.9.11 Now you could have a valid config.
As long as config is not valid, oXs does not setup the gps nor other functions
Thank you Aeropic Can i put these values for the program tests, not for real fly tests
GMG=??
GMG = YY To select mode/gain
GSA = 10 Gyro only : Original aileron stick (without mix/limits/trim)
GSE = 11 elevator
GSR = 12 rudder
GGR = 127 Gain on roll axis (-127/127)
GGP = 127 pitch
GGY = 127 Yaw
GGT = 2 1 (corr. on full throw) , 2 (on half) , 3 (on quater)
GMR = 3 1 (Very low) , 2 (low) , 3 (medium) , 4 (high)
GRE =2 1 (disabled) , 2 (enabled)
You can set 100 into GMG, this means gyro mode = RATE, gain = 100
No: GMG is Gyro Mode Gain. It is the nr of the channel used to control the gyro mode and the gain. It is the channel with a switch. The mode is selected depending of the sign of the Rc channel value (-%/+%) (so less or above 1500 us). How closed to -100% or +100+ how big is the gain( 0 => null gain).
I fixed a bug in 2.9.12 about the channels nr and the array index (channel 1 = index 0). so check again the value you set for GMG...GSR
I download the version number 2.9.12
processing cmd
Version = 2.9.11 Function GPIO Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 12 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 13 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29) RGB led . . . . . . . . . = 16 (RGB = 0, 1, 2, ..., 29) Logger . . . . . . . . . = 0 (LOG = 0, 1, 2, ..., 29) ESC . . . . . . . . . . . = 255 (ESC_PIN= 0, 1, 2, ..., 29)Esc type is not defined
Protocol is Fbus(Frsky) CRSF baudrate = 420000 Logger baudrate = 115200 PWM is generated at = 50 Hz Voltage parameters: Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 One temperature sensor is connected on V3 RPM multiplier = 1.000000 Baro sensor is not detected Acc/Gyro is not detected Airspeed sensor is not detected Vspeed compensation channel = 5 First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox (configured by oXs) :GPS is detected and has a fix Led color is normal (not inverted) Failsafe type is HOLD
Gyro configuration is:
Channels for : mode/gain=5 , Ail stick=1 , Elv stick=2 , Rud stick=3
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
Gain on throw is 2 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 3 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 2 1 (disabled) , 2 (enabled)
Gyro mixers must be calibrated
No sequencers are defined
Config parameters are OK Press ? + Enter to get help about the commands
I download the version number 2.9.12
This seems ok. Then you have to execute the learning process. Look at the file about gyro in the doc folder.
I'll read up on the doc and try my best, I'm just not a flyer. Otherwise everything in the telemetry appears as expected. I'll try out the camera stabilizer and sequencer tomorrow with the flight gyro deactivated, if this function is possible.
to deactivate the gyro, just set GMG = 255 (no channel used for the mode/gain)
I compiled the 2.9.12, everything in config seems OK. Now I cannot succeed to enter in learning process. I'll try again tomorrow...
Here I am : Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = -5227 , 3364 , -5595 Gyro offsets X, Y, Z = -275 , -251 , -42 Airspeed sensor is not detected No Vspeed compensation channel defined; oXs uses default settings First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox (configured by oXs) :GPS is not (yet) detected Led color is normal (not inverted) Failsafe type is HOLD
Gyro configuration is:
Channels for : mode/gain=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=100 Pitch=100 Yaw=100
Gain on throw is 2 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 2 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 1 1 (disabled) , 2 (enabled)
Gyro mixers must be calibrated
No sequencers are defined
Config parameters are OK Press ? + Enter to get help about the commands
I will try to morrow the learning process. I did not tested it today since the changes.
Good morning everybody,
I'm currently trying to initialize the gyro. I made the following settings for this: Aileron RC CH1, GPio6 Elevator RC CH2, GPio7 Rudder RC CH4, GPio8 Gain/Mode RC CH5. GPio9 Now I have: CH1=100% right corner CH2=100% up corner CH4=100% right corner and CH5 4 times within 5sec 0% to 100%, Somehow it doesn't want to initialize, what am I doing wrong? Greetings, Torsten
processing cmd
Version = 2.9.13 Function GPIO Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 12 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 13 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 6 7 255 8 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 9 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29) RGB led . . . . . . . . . = 16 (RGB = 0, 1, 2, ..., 29) Logger . . . . . . . . . = 0 (LOG = 0, 1, 2, ..., 29) ESC . . . . . . . . . . . = 255 (ESC_PIN= 0, 1, 2, ..., 29)Esc type is not defined
Protocol is Fbus(Frsky) CRSF baudrate = 420000 Logger baudrate = 115200 PWM is generated at = 50 Hz Voltage parameters: Scales : 1.000000 , 1.000000 , 0.100000 , 1.000000 Offsets: 0.000000 , 0.000000 , 2.000000 , 0.000000 One temperature sensor is connected on V3 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 1262 , 38 , -2790 Gyro offsets X, Y, Z = 22 , -162 , -190 Aispeed sensor is detected using MS4525 Vspeed compensation channel = 5 First analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Second analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Foreseen GPS type is Ublox (configured by oXs) :GPS is detected and has a fix Led color is normal (not inverted) Failsafe uses predefined values Chan 1...4 = 1500 1500 1500 1500 Chan 5...8 = 1500 1500 1500 1500 Chan 9...12 = 1500 1500 1500 1500 Chan 13...16= 1500 1500 1500 1500
Gyro configuration is:
Channels for : mode/gain=5 , Ail stick=1 , Elv stick=2 , Rud stick=4
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=64 Pitch=64 Yaw=64
Gain on throw is 2 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 2 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 1 1 (disabled) , 2 (enabled)
Gyro mixers must be calibrated
No sequencers are defined
Config parameters are OK Press ? + Enter to get help about the commands
I will try now. I worked with a previous version but as I made many changes, it could be a bug.
Good morning everybody,
I'm currently trying to initialize the gyro. I made the following settings for this: Aileron RC CH1, GPio6 Elevator RC CH2, GPio7 Rudder RC CH4, GPio8 Gain/Mode RC CH5. GPio9 Now I have: CH1=100% right corner CH2=100% up corner CH4=100% right corner and CH5 4 times within 5sec 0% to 100%, Somehow it doesn't want to initialize, what am I doing wrong? Greetings, Torsten
It's not only you (see 2 posts above) the learning process is corrupted in last release. Michel will fix this for sure !
@mstrens I do not understand what you do with the variable j line 692. it increments i while i is the index of a for loop ?
for (i=0;i<16;i++) {
// look at the channels that have to be controled by the gyro.
// channel is used if there are differences and channel is not a stick
temp.used[i] = false;
**uint8_t j=i++;**
if ( ((j != config.gyroChan[0] ) and (j != config.gyroChan[1] ) and (j != config.gyroChan[2]) and ( j!= config.gyroChanControl ))\
and ((abs(rightUpUs[0][i]-leftDownUs[0][i])>MM) or (abs(rightUpUs[0][i]-centerCh[i])>MM) or (abs(leftDownUs[0][i]-centerCh[i])>MM)\
or(abs(rightUpUs[1][i]-leftDownUs[1][i])>MM) or (abs(rightUpUs[1][i]-centerCh[i])>MM) or (abs(leftDownUs[1][i]-centerCh[i])>MM)\
or(abs(rightUpUs[2][i]-leftDownUs[2][i])>MM) or (abs(rightUpUs[2][i]-centerCh[i])>MM) or (abs(leftDownUs[2][i]-centerCh[i])>MM))) {
temp.used[i] = true;
}
Indeed it was one of the bugs but not the only one. I uploaded 2.9.13 At least learning process seems ok on my side.
V2.9.13 is very nice:
it seems I get much too much gains... I will have to play with it ;-)
I will make some more changes:
I played with gains and PID settings... I find that gains are working as a range limitation of the gyro (amplitude of the compensation). But they have no effect on how "nervous" is the gyro. I tried to remove PID and keep only P terms. I cannot manage to "quiet" the gyro effect in other words to remove high frequencies.
Indeed my low frequencies pass filter was here to filter the gyro data as I foud them to agressive...
I will go on reducing the Kp terms to see if I can lower the response. In theory it should !
With the only other gyro I use (NX3) moving the gains tend to make the plane oscillate. So I thing it's more a Kp than an amplitude?
for the inflight calibration of HOLD mode. My feeling is that the reference shall be captured everytime the pilot activates the HOLD mode (switch going from OFF to HOLD). This would allow to include the trims positions into the attitude setpoint ?
I just checked the original flightstab settings and those used by oXs for the MPU6050. Flightstab uses a DLPF of 5 Hz while oXs use a DLPF of 188Hz (reduced to 20Hz but only during accelerometer calibration).
I would like to keep MPU6050 DLPF at 188 as this is the value used for other purpose (Vspeed, ..) So it makes sense to keep the filter you had implement. At this stage, I will keep it. Perhaps it can even be increased by a factor 2 (so having e.g. gyroY = (31*gyroY + entry.data) >>5
Yeap, I think it would be good to keep the filter and as suggested to increase it ..
Meanwhile I played with different Kp and I come to the conclusion, it has no effect :-) Setting all terms to 0 should fully kill the gyro compensation. However in RATE when shaking the board with all Kp Ki Kd set to zero in config.h, the servo go ON moving. (I removed all mixers to get pure axis answer)
I think it works.
processing cmd
Version = 2.9.13 Function GPIO Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 12 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 13 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 6 7 255 8 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 9 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29) RGB led . . . . . . . . . = 16 (RGB = 0, 1, 2, ..., 29) Logger . . . . . . . . . = 0 (LOG = 0, 1, 2, ..., 29) ESC . . . . . . . . . . . = 255 (ESC_PIN= 0, 1, 2, ..., 29)Esc type is not defined
Protocol is Fbus(Frsky) CRSF baudrate = 420000 Logger baudrate = 115200 PWM is generated at = 50 Hz Voltage parameters: Scales : 1.000000 , 1.000000 , 0.100000 , 1.000000 Offsets: 0.000000 , 0.000000 , 2.000000 , 0.000000 One temperature sensor is connected on V3 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 1262 , 38 , -2790 Gyro offsets X, Y, Z = 22 , -162 , -190 Aispeed sensor is detected using MS4525 Vspeed compensation channel = 5 First analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Second analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Foreseen GPS type is Ublox (configured by oXs) :GPS is not (yet) detected Led color is normal (not inverted) Failsafe uses predefined values Chan 1...4 = 1500 1500 1500 1500 Chan 5...8 = 1500 1500 1500 1500 Chan 9...12 = 1500 1500 1500 1500 Chan 13...16= 1500 1500 1500 1500
Gyro configuration is:
Channels for : mode/gain=5 , Ail stick=1 , Elv stick=2 , Rud stick=4
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=64 Pitch=64 Yaw=64
Gain on throw is 2 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 2 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 1 (1=disabled , 2=enabled)
Gyro mixers must be calibrated
No sequencers are defined
Config parameters are OK Press ? + Enter to get help about the commands stabMode changed to 1 stabMode changed to 0 stabMode changed to 1 stabMode changed to 0 stabMode changed to 1 stabMode changed to 0
The learning process started centered Ail right Ch1=2005 Ch2=1500 Ch3=1412 Ch4=1500 Ail left Ch1=994 Ch2=1500 Ch3=1412 Ch4=1500 Elv up Ch1=1500 Ch2=2004 Ch3=1413 Ch4=1500 Elv down Ch1=1500 Ch2=989 Ch3=1412 Ch4=1500 Rud right Ch1=1500 Ch2=1500 Ch3=1413 Ch4=2009 Rud left Ch1=1500 Ch2=1500 Ch3=1412 Ch4=994 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 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 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 1 at 99
Stick Elv Up on channel 2 at 99
Stick Rud_Right on channel 4 at 100
Gyro corrections (from center pos in %) on:
End of learning process; result will be saved in flash read error ads1115stabMode changed to 1 Pwm channel 2=1500 stabMode changed to 0 stabMode changed to 1 stabMode changed to 0 stabMode changed to 1 Pwm channel 2=1500 Pwm channel 2=1500
for the inflight calibration of HOLD mode. My feeling is that the reference shall be captured everytime the pilot activates the HOLD mode (switch going from OFF to HOLD). This would allow to include the trims positions into the attitude setpoint ?
I think that some reference is captured each time the switch change (reset of PID). oXs does not know the trim positions. It knows the "current" stick positions but does not know if the stick are centered. If Hold mode is activated while sticks are not centered, it is not possible to know the actual neutral of the 3 sticks. So, I expect that the user has first to center the stick and then take an action (with the switch) to instruct oXs that there is a new neutral position to register (at least for the 3 sticks). This process is not required if the handset allows to transmit the real stick positions without the trim (I think).
I also expect a major difference between flightstab and oXs about the MPU6050. In oXs code, gyro use a setting with 250°/sec while flightstab uses 2000°/sec. I copied the code from flightstab but did not changed the formula in the calculation. This could also explain that the corrections are to big.
I have to look at the impact of using a setup with 2000°/sec on the other functions of oXs. Anyway, I expect that 250°/sec could be valid for a gyro. So I will first adapt the calculation in the gyro part.
Yes, for sure 250°/sec is more than enough ;-)
Well I tried with much more agressive filtering of gyro data... It's becoming correct with this low pass filter :
gyroX = (**127***gyroX + entry.data) >> **7**; // here some filtering
gyroY = (**127***gyroY + entry.data) >>**7** ;
And changing Kp has no effect. I tried to read the code but I'm lost when transferring pointers to structures :-)
Meanwhile I played with different Kp and I come to the conclusion, it has no effect :-) Setting all terms to 0 should fully kill the gyro compensation. However in RATE when shaking the board with all Kp Ki Kd set to zero in config.h, the servo go ON moving. (I removed all mixers to get pure axis answer) Are you sure you set all kp, ki,kd to zero? When I look at the formula's the corrections should be 0. Did you checked with an ENTER command to see the values. Take care that changing the values in the config.h has no effect when there is already a set of parameters saved in the flash. At each power on, oXs gives priority to saved parameters. You have to run the nuke program (in doc folder) to erase all the flash memory. Then the values in the config.h are used as default. I could change this just for the PID parameters because they are the only one that can't be edited with usb commands.
OK... I did not nuke at all ;-)
So it seems nearly very good with default kp Ki Kd parameters and a filtering of 64 gyroX = (63*gyroX + entry.data) >> 6; // here some filtering
I think I could even try this in flight !!!!
Master gain on the RX is set at 30% (min max of channel 13 for me)
Gyro configuration is:
Channels for : mode/gain=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=100 Pitch=0 Yaw=100
Gain on throw is 2 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 2 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 1 (1=disabled , 2=enabled)
Gyro mixers are calibrated:
Gyro corrections (from center pos in %) on:
Channel 1 center=0 rollRight=99 rollLeft=-100 pitchUp0 pitchDown=0 yawRight=0 yawLeft=0 min=-100 max=99
Channel 2 center=0 rollRight=0 rollLeft=0 pitchUp99 pitchDown=-100 yawRight=0 yawLeft=0 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
I put a version 2.9.14 with:
Short question, Do I need to recalibrate the gyro with version 2.9.14 if I previously calibrated with version 2.9.13? Otherwise the version works well, all telemetry data is transmitted properly in the FBUS protocol.
Gyro configuration is:
Channels for : mode/gain=5 , Ail stick=1 , Elv stick=2 , Rud stick=4
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=64 Pitch=64 Yaw=64
Gain on throw is 2 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 2 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 1 (1=disabled , 2=enabled)
Gyro mixers are calibrated: Sticks centered at: Ail=0 % Elv=0 % Rud0 % Gyro corrections (from center pos in %) on:
No sequencers are defined
Config parameters are OK Press ? + Enter to get help about the commands
Now amplitude of gyro compensations are very small... I reduced your division by 8 of GyroXYZ to get a bigger amùplitude...
pid_state.input[0] = constrain(gyroY, -8192, 8191)>>2; // divided by 8 by mstrens because oXs uses 250*/sec while flightstab uses 2000°/sec
pid_state.input[1] = constrain(gyroX, -8192, 8191)>>2;
pid_state.input[2] = constrain(gyroZ, -8192, 8191)>>2;
with this and all gains set to default and RX master gain set to 100%, the amplitude of correction on servo arm is about 60° in rate mode
Short question, Do I need to recalibrate the gyro with version 2.9.14 if I previously calibrated with version 2.9.13? Otherwise the version works well, all telemetry data is transmitted properly in the FBUS protocol.
No need to recalibrate. Anyway, you can always see all parameters with the enter command
please leave the division by 8, as we can compensate with Kp gain (PS: Kp Ki Kd are anow indeed kept from config after a new firmware is uploaded. I think it is very convenient thanks)
RATE mode is fine (on ground) with those values
Gyro configuration is:
Channels for : mode/gain=13 , Ail stick=10 , Elv stick=11 , Rud stick=12
PID Kp Ki Kd
Normal Roll 1000 0 100
Normal Pitch 1000 0 100
Normal Yaw 1000 0 100
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
Gain on throw is 1 (1=on full throw, 2=on half, 3=on quater)
Max rotate is 3 (1=Very low , 2=low , 3=medium , 4=high)
Stick rotate enabledi in rate mode is 1 (1=disabled , 2=enabled)
and code compiles with other defaut values: your values (1/16) for filtering gyro xyz gyroXYZ divided by 8 (to take care of gyro full scale being 250 instead of 2000)
I'll stop here for some hours, I'll go and fly some planes maybe with a gyro :-)
In this issue, I propose to discuss the best way to implement gyro functionality