Hi Dramida.
I'm not a coder too... only a mechanical engineer.
To understand better, these correction values are added to default PID values, so if you set 0 for all, it means that the code uses the same PIDs for rising than for hovering (default by EEPROM).
Till now I don't have any guide lines, I have to test a lot to figure out the influences of the corection values. But, you can set even negative numbers which mean you reduce the default PIDs. (But don't set higner values in negative than values in EEPROM!!!)
I made these values because I'm sure the perceft PID for HOVERING is not good for rising. And values for rising is not good for descending... (I already handle this difference in code, that's why we have only 3 corrections).
I hope I could help a bit.
BR
Adrian
ps.: once I finished the code itself I'll start to test out the perfect corrections. Or at least some guidelines.
Altitude Hold improvement solution
Re: Altitude Hold improvement solution
I don't belive in magic 
To further test your code, i need to understand how it works, as a principle.
To further test your code, i need to understand how it works, as a principle.
Re: Altitude Hold improvement solution
Generally, you should understand what PID control loop itself makes in case of baroPID regulation.
1) P value is a proportional value, generally spoken, the far the copter is from target alt the more correction in throttle applied.
2) I value is an integrator. That means if copter can't reach target, the I value gets bigger and bigger, because integrates the proportional part.
3) D is not a real derivative part in case of baro!!! Instead it calculates a velocity based on baro/acc sensors. And than corrects the BaroPID according to velocity (that's why I inserted here a correction according to target vario!).
-----so when you start to fine-tune basic BaroPID for hovering, you should understand these first.--------
4)In my code, when target vario is applied (not hovering), it means that code increase/reduce AltHold value in neccessary extent. AltHold value is the input for BaroPID regulation (target for regulation). And the BaroPID regulation starts to follow the changes. At this point I'm not sure where to start tune corrections, in the morning I had the idea of raising I instead of P. I'll try that too.
But first of all I want to finish the base code with working failsafe!!!
I hope my description is clear (at least for me it is...
).
1) P value is a proportional value, generally spoken, the far the copter is from target alt the more correction in throttle applied.
2) I value is an integrator. That means if copter can't reach target, the I value gets bigger and bigger, because integrates the proportional part.
3) D is not a real derivative part in case of baro!!! Instead it calculates a velocity based on baro/acc sensors. And than corrects the BaroPID according to velocity (that's why I inserted here a correction according to target vario!).
-----so when you start to fine-tune basic BaroPID for hovering, you should understand these first.--------
4)In my code, when target vario is applied (not hovering), it means that code increase/reduce AltHold value in neccessary extent. AltHold value is the input for BaroPID regulation (target for regulation). And the BaroPID regulation starts to follow the changes. At this point I'm not sure where to start tune corrections, in the morning I had the idea of raising I instead of P. I'll try that too.
But first of all I want to finish the base code with working failsafe!!!
I hope my description is clear (at least for me it is...
).Re: Altitude Hold improvement solution
Thanks Adrian
You wrote that between ALT p and PIDALTP and consequently I and D, there is a corelation that in my mind shouldn't be as there are two different loops:
Inner P-I-D loop controls altitude through Baro and AccZ as inputs
Outer P-I-D loop regulating speed of altitude variation corelated to throttle stick position as input.
how far apart from your code am i?
You wrote that between ALT p and PIDALTP and consequently I and D, there is a corelation that in my mind shouldn't be as there are two different loops:
Inner P-I-D loop controls altitude through Baro and AccZ as inputs
Outer P-I-D loop regulating speed of altitude variation corelated to throttle stick position as input.
how far apart from your code am i?
Re: Altitude Hold improvement solution
Hi,
no you are wrong. There is only one loop! The BaroPID regulates according to AltHold value, it alwasy would stay in there.
The difference in hover and descending/rising is that the target of AltHold number is changing according to desired vario (this is not a PID loo, it is simple relation between throttle stick position and the AltHold changing). Because PID regulation would keep the AltHold altitude, it'll follow the changes, causing copter to rise/descend.
And since I'm using a 25Hz calculation for AltHold changing, it is accurate enough. Clearly spoken if I want 150 cm/s (ie. full throttle and max vario is set to 150 cm/s), than AltHold value will change with 150 in every second.
is it clearer now?
BR
Adrian
ps.: the reason I think it is neccessary to use the compensations is that when not hovering, the regulation should work like a "follow mode" because the target is always changing (AltHold number).
Otherwise, I handled all situations like switch between hovering/rising, etc... by code, to have smooth transition as possible.
no you are wrong. There is only one loop! The BaroPID regulates according to AltHold value, it alwasy would stay in there.
The difference in hover and descending/rising is that the target of AltHold number is changing according to desired vario (this is not a PID loo, it is simple relation between throttle stick position and the AltHold changing). Because PID regulation would keep the AltHold altitude, it'll follow the changes, causing copter to rise/descend.
And since I'm using a 25Hz calculation for AltHold changing, it is accurate enough. Clearly spoken if I want 150 cm/s (ie. full throttle and max vario is set to 150 cm/s), than AltHold value will change with 150 in every second.
is it clearer now?
BR
Adrian
ps.: the reason I think it is neccessary to use the compensations is that when not hovering, the regulation should work like a "follow mode" because the target is always changing (AltHold number).
Otherwise, I handled all situations like switch between hovering/rising, etc... by code, to have smooth transition as possible.
Re: Altitude Hold improvement solution
Hi,
I have finished work on advanced Failsafe routine with RTH!!!
Here is the result:
http://www.youtube.com/watch?v=C06iXXJfrDo
I attached the code. Please note that this is fully experimental!!!! TRY IT ON YOUR OWN RISK, IN A SECURE ENVIROMENT!!! Also the define for Dramida is included, when copter is higher than RTH it maintains that altitude instead of descending to altitude. If commented RTH works as previously.(RTH_KEEP_ALT)
Here is how it works:
--- if defined the FAILSAFE_RTH, there are two possibilities:
--------1) if the GPS signal is good (is GPS fix and more than 5 satellites), when failsafe, copter starts to come home with the defined options (vario, altitudes) and when reach home, descends to defined altitude and stay there
--------2) if there is no good GPS signal, it starts to descend slowly (according to Failsafe vario defined), and when reaches ground or defined period ends, motor stops (go disarm).
according to these functions I RECOMMEND this small test before try it in air:
1) turn on the copter in a room or with GPS disconnected. Hold the copter on the ground strongly and activate it. Apply at least hovering throttle or even more a bit, and turn off the TX. PLEASE BE PREPARED TO DISCONNECT the battery once problem occures!!!!
If everything works well you should hear that RPM decreases, and motors stops after a while. Turn on the TX again, and while still holding the copter on the ground, arm it again. If everything works, after second try it should arm again and work as it should.
2) now go outside. Turn on copter and wait for good GPS signal. Hold the copter again to the ground strongly and arm it. Apply hovering throttle again, and turn off the TX. PLEASE BE PREPARED TO DISCONNECT the battery once problem occures!!!
If everything works well you should hear changing in RPM, a bit more throttle. That means copter tries to reach RTH altitude and function is active. Now, turn on TX again! Depending on the TX switch-back time, after 2-3 s you MUST HAVE full control again. Otherwise something went wrong, DO NOT TAKE OFF!!!!!!!! If you have control again, try this tests at least 2-3 times. Than you can have a big breath and take off..... GOOD LUCK!!!
Please note the followings:
--I tested it on a CRIUS AIO Pro with extension board (UBLOX GPS). but should work with I2C receivers too. I donn't have any to test...
Could somebody check the code and confirm it works???
--I always tested in ANGLE mode. It should work in ACRO mode too (there is a switch to ANGLE mode when failsafe), but could somebody confirm? My copter is too fast and agile to fly in ACRO mode when higher distances...
--since I tested with only one type of configuration, there could be still some BUGs in code. PLEASE BE EXTREMELY CAREFUL for the first few times!!! ALWASY BE PREPARED for malfunction and before take-off, think through the different possible outcomes!!! That helps a lot solving dangerous situations!!!! (I'm always do so even if I flown my copter hundred times...)
If you have any suggestions, questions, problems, contact me.
BR
Adrian
I have finished work on advanced Failsafe routine with RTH!!!
Here is the result:
http://www.youtube.com/watch?v=C06iXXJfrDo
I attached the code. Please note that this is fully experimental!!!! TRY IT ON YOUR OWN RISK, IN A SECURE ENVIROMENT!!! Also the define for Dramida is included, when copter is higher than RTH it maintains that altitude instead of descending to altitude. If commented RTH works as previously.(RTH_KEEP_ALT)
Here is how it works:
--- if defined the FAILSAFE_RTH, there are two possibilities:
--------1) if the GPS signal is good (is GPS fix and more than 5 satellites), when failsafe, copter starts to come home with the defined options (vario, altitudes) and when reach home, descends to defined altitude and stay there
--------2) if there is no good GPS signal, it starts to descend slowly (according to Failsafe vario defined), and when reaches ground or defined period ends, motor stops (go disarm).
according to these functions I RECOMMEND this small test before try it in air:
1) turn on the copter in a room or with GPS disconnected. Hold the copter on the ground strongly and activate it. Apply at least hovering throttle or even more a bit, and turn off the TX. PLEASE BE PREPARED TO DISCONNECT the battery once problem occures!!!!
If everything works well you should hear that RPM decreases, and motors stops after a while. Turn on the TX again, and while still holding the copter on the ground, arm it again. If everything works, after second try it should arm again and work as it should.
2) now go outside. Turn on copter and wait for good GPS signal. Hold the copter again to the ground strongly and arm it. Apply hovering throttle again, and turn off the TX. PLEASE BE PREPARED TO DISCONNECT the battery once problem occures!!!
If everything works well you should hear changing in RPM, a bit more throttle. That means copter tries to reach RTH altitude and function is active. Now, turn on TX again! Depending on the TX switch-back time, after 2-3 s you MUST HAVE full control again. Otherwise something went wrong, DO NOT TAKE OFF!!!!!!!! If you have control again, try this tests at least 2-3 times. Than you can have a big breath and take off..... GOOD LUCK!!!
Please note the followings:
--I tested it on a CRIUS AIO Pro with extension board (UBLOX GPS). but should work with I2C receivers too. I donn't have any to test...
Could somebody check the code and confirm it works???--I always tested in ANGLE mode. It should work in ACRO mode too (there is a switch to ANGLE mode when failsafe), but could somebody confirm? My copter is too fast and agile to fly in ACRO mode when higher distances...
--since I tested with only one type of configuration, there could be still some BUGs in code. PLEASE BE EXTREMELY CAREFUL for the first few times!!! ALWASY BE PREPARED for malfunction and before take-off, think through the different possible outcomes!!! That helps a lot solving dangerous situations!!!! (I'm always do so even if I flown my copter hundred times...)
If you have any suggestions, questions, problems, contact me.
BR
Adrian
- Attachments
-
- Multiwii dev_r1282_NHA_r8_FINAL.zip
- (141.06 KiB) Downloaded 1379 times
Re: Altitude Hold improvement solution
I know the filename says r1282, but is that the Dev version your R8 is built off of?
just curious, i wanted to check the changelog. Thanks.
just curious, i wanted to check the changelog. Thanks.
Re: Altitude Hold improvement solution
Hi,
It is based on the r1282 indeed (I used the files of Multiwii_shared in r1282 state. And then included my changes.) The following r8 means it is the 8th change by me.
BTW I have already merged with the latest r1303. I also included some LED_PATTERN to VBAT/FAILSAFE additions in it, and tried to make all my changes even clearer and add more detailed descriptions.
Unfortunatelly today there was terrible weather in Hungary, so couldn't test if all functions works properly (theoretically it should since there weren't any major changes between r1282 and r1303...). If you have some patience, I'll upload once I tried in the air (just to be sure there isn't any major BUGs...). Or if you send me a PM I'll send it to you to let you check what's changed.
I'm planning to write a detailed changelog about my additions, but it takes a lot of time, for me the working code was the primary objective.
BR
Adrian
ps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS...
It is based on the r1282 indeed (I used the files of Multiwii_shared in r1282 state. And then included my changes.) The following r8 means it is the 8th change by me.
BTW I have already merged with the latest r1303. I also included some LED_PATTERN to VBAT/FAILSAFE additions in it, and tried to make all my changes even clearer and add more detailed descriptions.
Unfortunatelly today there was terrible weather in Hungary, so couldn't test if all functions works properly (theoretically it should since there weren't any major changes between r1282 and r1303...). If you have some patience, I'll upload once I tried in the air (just to be sure there isn't any major BUGs...). Or if you send me a PM I'll send it to you to let you check what's changed.
I'm planning to write a detailed changelog about my additions, but it takes a lot of time, for me the working code was the primary objective.
BR
Adrian
ps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS...
Re: Altitude Hold improvement solution
Adrian, thanks for your amazing code on alt hold!
I have a few comments about the failsafe handing.
As failsafe should be simple and robust. with a pre defined FAILSAFE_VARIO and FAILSAFE_OFF_DELAY will be very danger if the quad is at a very high altitude, say 3000cm. normally 50cm/s * 20 = 1000cm.
Someone would suggest to change the failsafe off delay to a big value, that is not wise when low battery case happen. If we increase the failsafe vario, that will break your quad when it kiss the ground.
My solution would be like this:
failsafe starts:
failsafe running:
eg. if the quad is at 3000cm height, it drop to 2500cm height with speed of 250cm/s in 10 seconds. And then if drops to the ground with a speed of 50cm/s.
Can you please explain this line?
And if the quad is descending with a high speed, will this value be reached in the air and it disarm?
BTW, why it is -200 here?
Can you please help me to calculate a safe BaroPID value to used here? I do not want the quad to disarm in the air.
I have a few comments about the failsafe handing.
As failsafe should be simple and robust. with a pre defined FAILSAFE_VARIO and FAILSAFE_OFF_DELAY will be very danger if the quad is at a very high altitude, say 3000cm. normally 50cm/s * 20 = 1000cm.
Someone would suggest to change the failsafe off delay to a big value, that is not wise when low battery case happen. If we increase the failsafe vario, that will break your quad when it kiss the ground.
My solution would be like this:
- split the alt into high an speed part and a low speed part
each part spends 50% of the failsafe off delay
first descends with a high speed to a safe alt within 50% of the fail safe delay
then switch to a lower speed and land
failsafe starts:
Code: Select all
int32_t safeAlt = FAILSAFE_VARIO * FAILSAFE_OFF_DELAY / 10 / 2;
safeAlt /= 2; // assure the quad can land in time
int32_t highSpeedAlt = (failsafeAlt - safeAlt)/(FAILSAFE_OFF_DELAY / 10 / 2);
if (highSpeedAlt > FAILSAFE_VARIO)
failsafeVario = highSpeedAlt;
else
failsafeVario = FAILSAFE_VARIO;
failsafe running:
Code: Select all
if (f.FAILSAFE_RUNNING)
{
if (f.FAILSAFE_ALTHOLD_RESET)
{
if (EstAlt < (FAILSAFE_VARIO * FAILSAFE_OFF_DELAY / 10 / 2))
failsafeVario = FAILSAFE_VARIO;
AltHold -= failsafeVario / 25;
dynPidAltPLimit = ALT_HOLD_VARIO_MAX * 3;
dynPidAltP = conf.P8[PIDALT]; dynPidAltI = conf.I8[PIDALT];
dynPidAltD = conf.D8[PIDALT] + (ALT_HOLD_VARIO_D_CORR);
BaroState = BARO_STATE_HOVERING;
}
else
{
RESET_ALT_HOLD();
f.FAILSAFE_ALTHOLD_RESET = 1;
}
f.ALT_VARIO_CHANGED = 1;
}
eg. if the quad is at 3000cm height, it drop to 2500cm height with speed of 250cm/s in 10 seconds. And then if drops to the ground with a speed of 50cm/s.
Can you please explain this line?
Code: Select all
if (BaroPID < -200) // reach the ground.
And if the quad is descending with a high speed, will this value be reached in the air and it disarm?
BTW, why it is -200 here?
Can you please help me to calculate a safe BaroPID value to used here? I do not want the quad to disarm in the air.
Re: Altitude Hold improvement solution
Btw, this is my ground checking code:
Code: Select all
if (
// the sonar said we are on the ground
(SonarErrors < SONAR_ERROR_MAX && SonarAlt <= FAILSAFE_SONAR_ALT)
// BaroPID is very small, can not reach a lower alt in 5 seconds
|| (BaroPID < -(FAILSAFE_VARIO * 5) && failsafeVario == FAILSAFE_VARIO)
// timeout failsafe landing
|| (failsafeCnt > (5 * FAILSAFE_OFF_DELAY) )
// something really bad happen, drops like a rock to avoid worse result
|| (failsafeAlt + FAILSAFE_MAX_RISING_ALT < EstAlt)
)
{
//if we cannot reach target altitude , or landed
// maybe initial throttle was too high, time to stop anyway
f.ARMED = 0;
f.OK_TO_ARM = 0;
RESET_FAILSAFE_FLAGS();
}
Re: Altitude Hold improvement solution
Hi,
I started a dedicated topic to advanced failsafe solutions, I suggest let this topic stay for alt hold.
My reply is also there.
viewtopic.php?f=8&t=2893
BR
Adrian
I started a dedicated topic to advanced failsafe solutions, I suggest let this topic stay for alt hold.
My reply is also there.
viewtopic.php?f=8&t=2893
BR
Adrian
Re: Altitude Hold improvement solution
Hi Eric,
using Flags for barostate, failsafe is a good idea, I'll add them to my next release!!!
BR
Adrian
using Flags for barostate, failsafe is a good idea, I'll add them to my next release!!!
BR
Adrian
Re: Altitude Hold improvement solution
Adrian - the developments look fantastic. Look forward to trying out when the weather gives us a chance. maybe a coupe of weeks... (
Re: Altitude Hold improvement solution
hi adrian
diffmerge also exists for windows and linux systems
http://www.sourcegear.com/diffmerge/downloads.php
ps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS...
diffmerge also exists for windows and linux systems
http://www.sourcegear.com/diffmerge/downloads.php
Re: Altitude Hold improvement solution
mbrak wrote:hi adrianps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS...
diffmerge also exists for windows and linux systems
http://www.sourcegear.com/diffmerge/downloads.php
Hi Mbrak,
thanks for addition!!! I was looking for something really simple only under OSX...
BR
Adrian
Re: Altitude Hold improvement solution
Hi,
I have attached my latest code, I inserted this two-step failsafe vario.
It is fully merged with r1303, and tried to make bnetter descriptions in config.h (sorry for my bad english... )
Please note that since my copter would probably damaged due to a 50 cm/s auto lading (mini Y6 copter...) I didn't tested the failsafe vario mode, only the failsafe rth mode (because in failsafe RTH mode it stays in hovering over home on defined home altitude). I tested all other functions in the air (although there was icy wind outside... :S )
Also please note that I have tested with serial GPS, but I implemented the I2C_GPS, should work also.
Other changes:
- different patterns in LED_PATTERN for VBAT alarms/failsafe mode
- LED_PATTERN is now set for CRIUS AIO PRO pin33
- VBAT pin is set to A1
I'd like to ask you to confirm the followings:
- FAILSAFE_VARIO_MODE works (please be careful and first test according to my previous post!!!, and set high value enough for FAILSAFE_OFF_DELAY!!!)
- I2C GPS FAILSAFE_RTH_MODE works
- My whole code with different boards (differ from CRIUS AIP PRO + EXTENSION BOARD)
Till now I left //NHADRIAN comments after each modified line/part for easier identification, but I'll remove in r10 finally.
BR
Adrian
PS.: mode infos about ALT hold mode in the other topic...
I have attached my latest code, I inserted this two-step failsafe vario.
It is fully merged with r1303, and tried to make bnetter descriptions in config.h (sorry for my bad english...
)Please note that since my copter would probably damaged due to a 50 cm/s auto lading (mini Y6 copter...) I didn't tested the failsafe vario mode, only the failsafe rth mode (because in failsafe RTH mode it stays in hovering over home on defined home altitude). I tested all other functions in the air (although there was icy wind outside... :S )
Also please note that I have tested with serial GPS, but I implemented the I2C_GPS, should work also.
Other changes:
- different patterns in LED_PATTERN for VBAT alarms/failsafe mode
- LED_PATTERN is now set for CRIUS AIO PRO pin33
- VBAT pin is set to A1
I'd like to ask you to confirm the followings:
- FAILSAFE_VARIO_MODE works (please be careful and first test according to my previous post!!!, and set high value enough for FAILSAFE_OFF_DELAY!!!)
- I2C GPS FAILSAFE_RTH_MODE works
- My whole code with different boards (differ from CRIUS AIP PRO + EXTENSION BOARD)
Till now I left //NHADRIAN comments after each modified line/part for easier identification, but I'll remove in r10 finally.
BR
Adrian
PS.: mode infos about ALT hold mode in the other topic...
- Attachments
-
- Multiwii dev_r1303_NHA_r9.zip
- (141.4 KiB) Downloaded 1299 times
Re: Altitude Hold improvement solution
I don't know how to test failsafe as my FrSky PPM receiver sends PPM even with transmitter stopped. I set it to RTH and Alt Hold when receiver is in failsafe. Also i am not using I2C GPS.
Re: Altitude Hold improvement solution
Hi Dramida, if you meant RX failsafe, you can disable Frsky RX failsafe by rebinding the receiver (from frsky user guide).
Re: Altitude Hold improvement solution
Hi all, the trigger for RX failsafe in Multiwii is that one of the first four channel (throttle, roll, yaw, pitch) gets lower than 985us signal.
So it doesn't matter if you use PPM or PWM signals, the only important is that your receiver should be programmed for failsafe function.
I'm using Futaba FASST transmitter with FRSKY TFR4 fasst compatible receiwer in PPM mode. The receiwer can be forgrammed for failsafe. The method is that switch on the transmitter, raise the low-point throttle EPA to maximum, then turn on the receiver and press the button. (this method depends on your receiver type) Then set back the throttle EPA to my default value. Now, once TX signal is lost, the receiver sends a 965 us signal on throttle channel, that triggers the failsafe in Multiwii.
BR
Adrian
So it doesn't matter if you use PPM or PWM signals, the only important is that your receiver should be programmed for failsafe function.
I'm using Futaba FASST transmitter with FRSKY TFR4 fasst compatible receiwer in PPM mode. The receiwer can be forgrammed for failsafe. The method is that switch on the transmitter, raise the low-point throttle EPA to maximum, then turn on the receiver and press the button. (this method depends on your receiver type) Then set back the throttle EPA to my default value. Now, once TX signal is lost, the receiver sends a 965 us signal on throttle channel, that triggers the failsafe in Multiwii.
BR
Adrian
Re: Altitude Hold improvement solution
Hi Adrian
flew your code on my tricopter....
RTH, althold, climbing to RTH height, and lowering on reaching home all seems to work fine.
however, I could not get it to auto land on fail-safe. It returns home alright, but then keeps hovering at 5 meters (that's how I've set it).... it does not land....
not sure if I got the fail-safe properly set in the receiver.... got a frsky receiver. initially just re-bound it, so all failsafe settings are gone, but then it seems to keep sending last value. the copter would just float around as I left it.
Then I set the failsafe settings in the receiver to -125% throttle (GUI does not show anything below 990ish), and aux channels all set to RTH.... Now it would come back, but still no landing.... no different than RTH with transmitter on.
anyway.... cannot test anymore today.... some electrical fault caused a motor to stutter, and it crashed into a puddle
.... have to dry all the electronics first.... 
BTW. when in alt holt, and throttle at minimum, the tricopter starts to slowly yaw.... this is some feature build in long time ago to stop the yaw servo from moving, causing the prop to hit the ground. perhaps this feature should be de-activated when the copter is in alt-hold mode....
Thanks a lot for yet another great addition !
Wilco
flew your code on my tricopter....
RTH, althold, climbing to RTH height, and lowering on reaching home all seems to work fine.
however, I could not get it to auto land on fail-safe. It returns home alright, but then keeps hovering at 5 meters (that's how I've set it).... it does not land....
not sure if I got the fail-safe properly set in the receiver.... got a frsky receiver. initially just re-bound it, so all failsafe settings are gone, but then it seems to keep sending last value. the copter would just float around as I left it.
Then I set the failsafe settings in the receiver to -125% throttle (GUI does not show anything below 990ish), and aux channels all set to RTH.... Now it would come back, but still no landing.... no different than RTH with transmitter on.
anyway.... cannot test anymore today.... some electrical fault caused a motor to stutter, and it crashed into a puddle
.... have to dry all the electronics first.... BTW. when in alt holt, and throttle at minimum, the tricopter starts to slowly yaw.... this is some feature build in long time ago to stop the yaw servo from moving, causing the prop to hit the ground. perhaps this feature should be de-activated when the copter is in alt-hold mode....
Thanks a lot for yet another great addition !
Wilco
Re: Altitude Hold improvement solution
Hi,
regarding your experiences:
1) when using RTH_FAILSAFE, it will NOT autoland, since I expect when copter arrives home, it will be in TX range again... (will autoland in its position only if GPS signal is weak or function not uncommented). Because if for example failsafe vario is 50 cm/s it is still hard touchdown enough to crash most of out copters.
2) I'll look after the tricopter code to check this feature at the weekend.
BR
Adrian
regarding your experiences:
1) when using RTH_FAILSAFE, it will NOT autoland, since I expect when copter arrives home, it will be in TX range again... (will autoland in its position only if GPS signal is weak or function not uncommented). Because if for example failsafe vario is 50 cm/s it is still hard touchdown enough to crash most of out copters.
2) I'll look after the tricopter code to check this feature at the weekend.
BR
Adrian
Re: Altitude Hold improvement solution
Aha.... so then that was my misunderstanding....
I assumed it would autoland if still in failsafe by the time it arrived home, and risk it, rather then floating around until the battery dies
(which is also some kind of auto land).
So everything seems to work as designed then....
My beaten up tricopter would most likely survive a 50 cm/s landing..... many of my 'normal' landings are worse....
Not saying i would prefer an autoland.... the current implentation is perfect..... would just be interesting to watch....
one other thing, which i was not able to test yet.... would it disarm when flying in alt-hold with throttle stick at minumum, and I would give full yaw left, or full roll left ?
I assumed it would autoland if still in failsafe by the time it arrived home, and risk it, rather then floating around until the battery dies
(which is also some kind of auto land).
So everything seems to work as designed then....
My beaten up tricopter would most likely survive a 50 cm/s landing..... many of my 'normal' landings are worse....
Not saying i would prefer an autoland.... the current implentation is perfect..... would just be interesting to watch....
one other thing, which i was not able to test yet.... would it disarm when flying in alt-hold with throttle stick at minumum, and I would give full yaw left, or full roll left ?
-
copterrichie
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Altitude Hold improvement solution
HOWEVER, Auto-landing seems to be the next logical step. Hooray!!!
Re: Altitude Hold improvement solution
copterrichie wrote:HOWEVER, Auto-landing seems to be the next logical step. Hooray!!!
I could think of:
- RTH and keep flying if commanded to come home (no failsafe activated)
- RTH and auto land when home upon failsafe, if fail-safe is still active when it reaches home
- Auto land on the spot when failsafe and no GPS.
if my Transmitter comes back, I can always interrupt an autoland before it happens. if my Tx is no longer working (because I 'forgot' to charge the Tx battery, or some real problem exists), it would try to autoland.
If autoland would possibly cause damage, I could just hand-catch it when it comes down.
If it stays floating, just out of my reach, and I cannot get the Tx back up again, it's not very helpful as well....
just thinking out loudly....
I like already what it does now.....
Let's hope this makes it into the _shared branch !
Re: Altitude Hold improvement solution
Hi,
- I'll make a definable timer for autoland if still no TX after reaching HOME latitude.
- About autolanding, it is really hard to slow down before touchdown without a working sonar...how to determine the ground is close enough?! (waiting for ideas... !!!)
- if you have a big copter or ie. Y6, it is hard to catch by hand...
- about shared branch, my code is FAR AWAY to be clean and safe enough to put in _shared, it is really in testing/development phase!!!
Alexinparis pointed on lot of redundances and other weak points (many thanks to his kind reply!!!), which are caused because I tried to make as safe as I could (so many repeated variable resets, etc...). And also a detailed changelog will be neccessary to understand all changes clearly in code itself.
I'll try to overcome on all of this at weekend, I have already cleaned a lot.
BR
Adrian
ps.: I merged with r1306 already and will include in my next release, I really like to handle all GPS types in one way...
- I'll make a definable timer for autoland if still no TX after reaching HOME latitude.
- About autolanding, it is really hard to slow down before touchdown without a working sonar...how to determine the ground is close enough?! (waiting for ideas...
!!!) - if you have a big copter or ie. Y6, it is hard to catch by hand...
- about shared branch, my code is FAR AWAY to be clean and safe enough to put in _shared, it is really in testing/development phase!!!
Alexinparis pointed on lot of redundances and other weak points (many thanks to his kind reply!!!), which are caused because I tried to make as safe as I could (so many repeated variable resets, etc...). And also a detailed changelog will be neccessary to understand all changes clearly in code itself.
I'll try to overcome on all of this at weekend, I have already cleaned a lot.
BR
Adrian
ps.: I merged with r1306 already and will include in my next release, I really like to handle all GPS types in one way...
Re: Altitude Hold improvement solution
Is it possible to publish your code in a separate branch on google code SVN ?
I mean, here: http://code.google.com/p/multiwii/source/browse/#svn%2Fbranches
it's a lot easier to keep track of your changes (also for us)....
I mean, here: http://code.google.com/p/multiwii/source/browse/#svn%2Fbranches
it's a lot easier to keep track of your changes (also for us)....
Re: Altitude Hold improvement solution
nhadrian wrote:Hi,
...............
- About autolanding, it is really hard to slow down before touchdown without a working sonar...how to determine the ground is close enough?! (waiting for ideas...
Alexinparis pointed on lot of redundances and other weak points (many thanks to his kind reply!!!), which are caused because I tried to make as safe as I could (so many repeated variable resets, etc...). And also a detailed changelog will be neccessary to understand all changes clearly in code itself.
..............
BR
Adrian
ps.: I merged with r1306 already and will include in my next release, I really like to handle all GPS types in one way...
I am glad Alex is keeping an eye on this project.
Keep up the good work Adrian.
About auto-landing, i would make a procedure that try to decrease the speed as copter approach to ground, let's say below 2m the rate of descend is only 20 cm/s. The ground efect will step in at about 20-30 cm cushioning the 20 cm/s impact. Now the copter wants to go below 0m, let-s say it tries to go as far as -2 m or more ( in case of baro presure change). The Alt-Hold PID Algorithm would sense this situation (this check shoud be made only in final landing procedure ) as the error gets bigger and bigger.
-
copterrichie
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Altitude Hold improvement solution
If there were enough memory on the ATMega328, the old computer game Lunar Lander would serve as a perfect example and would not require sonar.
http://lander.dunnbypaul.net/
http://lander.dunnbypaul.net/
Re: Altitude Hold improvement solution
In order you have perfect level ground and accurate altitude reading, is OK.
But once you get 1-2 m drift in baro reading (ie. for temperature change, etc.) during flight, or there is 1-2 m difference in level between takeoff and landing place that's enough to crash the copter...
So hard to figure out. BTW, I'll include automatic descending after defined period in home point failsafe...
BR
Adrian
But once you get 1-2 m drift in baro reading (ie. for temperature change, etc.) during flight, or there is 1-2 m difference in level between takeoff and landing place that's enough to crash the copter...
So hard to figure out. BTW, I'll include automatic descending after defined period in home point failsafe...
BR
Adrian
Re: Altitude Hold improvement solution
nhadrian wrote:So hard to figure out.
you can check the averaged vario for this
e.g. descending is set to -50cm/s... you average the vario by hard LPF (with big factor)... and when averaged speed about zero (~5..10cm/s) it means that you are landed...
Re: Altitude Hold improvement solution
Why should the copter descend so quick (50cm/s)? DJI Naza only descend about 20-25cm/s. I thing, it will be good for us too at first time.
Altitude Hold improvement solution
Is it possible to check the if the BaroPID is always very small, say -200 in 5 seconds?
Re: Altitude Hold improvement solution
Eric wrote:Is it possible to check the if the BaroPID is always very small, say -200 in 5 seconds?
Hi. It is possible, but I found an interresting phenomenon, if BaroPIB reach small enough parameter (around -250), it resets, and gets 0 again. Till now I couldn't find the origin of this. BTW, -200 is small enough as I described in the previous posts, to disarm.
Also, I'd like to let the Failsafe as simple as it can be, since it is not a pleasure function but an EMERGENCY solution, not a controlled autolanding!!!!!
Re: Altitude Hold improvement solution
jpeti29 wrote:Why should the copter descend so quick (50cm/s)? DJI Naza only descend about 20-25cm/s. I thing, it will be good for us too at first time.
FAILSAFE_VARIO is a user-definable parameter in config.h ...
... You can set what you want, the lower limit is 25 cm/s.Re: Altitude Hold improvement solution
About a long range digital PAL video link in 433 Mhz open source project
viewtopic.php?f=7&t=2903&p=28701#p28701
viewtopic.php?f=7&t=2903&p=28701#p28701
Re: Altitude Hold improvement solution
Hi Adrian, any news about vario altitude mode and auto-landing? Can we put a new release based on your work? I built a new dji style quad and i am ready test some landings
Re: Altitude Hold improvement solution
I'm ready with new release, only some final tests are pending....
And yes, the autolanding in failsafe_RTH and also a 2-step descending in failsafe_ALT is ready. And, other small improvements...
Also I made several major changes in code structure to be more clear and universal. Please be patient for 2-3 more days.
BR
Adrian
And yes, the autolanding in failsafe_RTH and also a 2-step descending in failsafe_ALT is ready. And, other small improvements...
Also I made several major changes in code structure to be more clear and universal. Please be patient for 2-3 more days.
BR
Adrian
Re: Altitude Hold improvement solution
I cant wait to see what you come up with next Adrian
I have a problem though. I am trying to use your R9 and when I load it on my flight controller, my GUI (and i assume the board as well) does not see any RX input. My Transmitter has no effect on the board and the GUI shows all channels at 1500 as if the TX was turned off. I am not able to arm the board or anything
When I load 2.1 everything works as normal. Is there something I am overlooking in the code?
Thanks
I have a problem though. I am trying to use your R9 and when I load it on my flight controller, my GUI (and i assume the board as well) does not see any RX input. My Transmitter has no effect on the board and the GUI shows all channels at 1500 as if the TX was turned off. I am not able to arm the board or anything
When I load 2.1 everything works as normal. Is there something I am overlooking in the code?
Thanks
Re: Altitude Hold improvement solution
What's your transmitter?
If the transmitter type like Turnigy 9x, then leave all defines in "PPM Sum Reciver" commented. For example: //#define SERIAL_SUM_PPM
If the transmitter type like Turnigy 9x, then leave all defines in "PPM Sum Reciver" commented. For example: //#define SERIAL_SUM_PPM
Code: Select all
/**************************** PPM Sum Reciver ***********************************/
/* The following lines apply only for specific receiver with only one PPM sum signal, on digital PIN 2
Select the right line depending on your radio brand. Feel free to modify the order in your PPM order is different */
//#define SERIAL_SUM_PPM PITCH,YAW,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Graupner/Spektrum
#define SERIAL_SUM_PPM ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Robe/Hitec/Futaba
//#define SERIAL_SUM_PPM ROLL,PITCH,YAW,THROTTLE,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Multiplex
//#define SERIAL_SUM_PPM PITCH,ROLL,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For some Hitec/Sanwa/Others
// Uncommenting following line allow to connect PPM_SUM receiver to standard THROTTLE PIN on MEGA boards (eg. A8 in CRIUS AIO)
#define PPM_ON_THROTTLERe: Altitude Hold improvement solution
thank you, i will try that. I am using a Turnigy9X TX with a FrSky DHT module & RX.
Re: Altitude Hold improvement solution
Hi all,
********UPDATE**********
A have just noticed that an official r1311 is released. I checked and there were some small changes (ie. log values or governor or LCD changes) wich were not included in my r12 since I made my merge from _shared previously.
So I merged my code with the official r1311 now, and replaced the attachments!!!!
**********END*************
it's time to introduce my r12 code, based on r1311 Multiwii release!
I have included the autoland in Failsafe_RTH mode too, I even tested it! After landing, RPM will decrease than motors stops.
I completelly reworked the code, removed many redundant parts and also solved some major problems (many thanks to Alexinparis for pointing on them), now all my mods can be used independently too!!!
I have attached two zip files:
1) the COMPLETE code contains all my mods and should be used.
2) 5 more files for developers, with independent functions it is more easy to understand my changes and codes:
- BASIC - only minor changes but nothing new functions (only some led-flasher addons)
- FAILSAFE_ALT - only this function is included
- FAILSAFE_RTH - only this function is included
- VARIO_ALT_MODE - only this function is included
- RTH_ALT_MODE - only this function is included
I tried to explain all parametes correctly in config.h so please read carefully before use any of my mods.
Also please note that even if I made many-many flights during this period, hidden BUGs could be remained, especially with different setups (ie. I2C_GPS) so first test functions with EXTREME CAUTION!
For FAILSAFE functions please take time for previously described Failsafe testing procedure before first take-off!
Please keep in mind that all my functions assumes a well-tuned configuration with all important PIDs tuned (incl. GPS HOLD, BARO, ANGLE, etc...)
I hope you'll enjoy my code, I wish you all safe landings, and looking for any experiences!
BR
Adrian
********UPDATE**********
A have just noticed that an official r1311 is released. I checked and there were some small changes (ie. log values or governor or LCD changes) wich were not included in my r12 since I made my merge from _shared previously.
So I merged my code with the official r1311 now, and replaced the attachments!!!!
**********END*************
it's time to introduce my r12 code, based on r1311 Multiwii release!
I have included the autoland in Failsafe_RTH mode too, I even tested it! After landing, RPM will decrease than motors stops.
I completelly reworked the code, removed many redundant parts and also solved some major problems (many thanks to Alexinparis for pointing on them), now all my mods can be used independently too!!!
I have attached two zip files:
1) the COMPLETE code contains all my mods and should be used.
2) 5 more files for developers, with independent functions it is more easy to understand my changes and codes:
- BASIC - only minor changes but nothing new functions (only some led-flasher addons)
- FAILSAFE_ALT - only this function is included
- FAILSAFE_RTH - only this function is included
- VARIO_ALT_MODE - only this function is included
- RTH_ALT_MODE - only this function is included
I tried to explain all parametes correctly in config.h so please read carefully before use any of my mods.
Also please note that even if I made many-many flights during this period, hidden BUGs could be remained, especially with different setups (ie. I2C_GPS) so first test functions with EXTREME CAUTION!
For FAILSAFE functions please take time for previously described Failsafe testing procedure before first take-off!
Please keep in mind that all my functions assumes a well-tuned configuration with all important PIDs tuned (incl. GPS HOLD, BARO, ANGLE, etc...)
I hope you'll enjoy my code, I wish you all safe landings, and looking for any experiences!
BR
Adrian
- Attachments
-
- Multiwii_r1311_NHA_r13_VARIO_ALT_MODE.zip
- (155.13 KiB) Downloaded 1280 times
-
- Multiwii_r1311_NHA_r13_RTH_ALT_MODE.zip
- (155.34 KiB) Downloaded 1306 times
-
- Multiwii_r1311_NHA_r13_FAILSAFE_RTH.zip
- (156.58 KiB) Downloaded 1234 times
-
- Multiwii_r1311_NHA_r13_FAILSAFE_ALT.zip
- (155.2 KiB) Downloaded 1281 times
-
- Multiwii_r1311_NHA_r13_COMPLETE.zip
- (159.16 KiB) Downloaded 1366 times
-
- Multiwii_r1311_NHA_r13_BASIC.zip
- (153.9 KiB) Downloaded 1257 times
Last edited by nhadrian on Sat Jan 12, 2013 8:56 am, edited 2 times in total.
Altitude Hold improvement solution
Amazing work!
Please forgive a noob question.
How do code changes like this get into "official" releases from a process/approval perspective?
Please forgive a noob question.
How do code changes like this get into "official" releases from a process/approval perspective?
Re: Altitude Hold improvement solution
Hi,
************UPDATE**************
viewtopic.php?f=8&t=2371&p=29042#p29042
*************END*****************
It depends on the developers.
I sent all of these to Alexinparis, if he decides that any part of my job is stable/good/safety enough and also the resource consumption (memory/cycle time/etc) is good enough, he'll put it in.
BR
Adrian
ps.: since I'm not a qualified programmer, I'm sure some of my changes could be written on a more "elegant" way... but the idea itself looks like works!
************UPDATE**************
viewtopic.php?f=8&t=2371&p=29042#p29042
*************END*****************
It depends on the developers.
I sent all of these to Alexinparis, if he decides that any part of my job is stable/good/safety enough and also the resource consumption (memory/cycle time/etc) is good enough, he'll put it in.
BR
Adrian
ps.: since I'm not a qualified programmer, I'm sure some of my changes could be written on a more "elegant" way... but the idea itself looks like works!
Re: Altitude Hold improvement solution
Adrian, in latest MWC R13_complete, in config.h, confuses me:
I might be wrong, but i see two sets of configs regarding RTH:
firstly:
and at the end
I might be wrong, but i see two sets of configs regarding RTH:
firstly:
Code: Select all
//#define FAILSAFE_RTH_MODE // if GPS present and ready, copter starts RTH when signal lost. When signal is back, control is back again.
#define FAILSAFE_RTH_VARIO 100 // in cm/s - vario for RTH function for failsafe
#define FAILSAFE_RTH_ALT 700 // in cm - minimum RTH altitude for failsafe. If copter is higher than this, it will keep altitude.
#define FAILSAFE_RTH_HOME 300 // in cm - home altitude for RTH, copter will descend to this altitude and wait.
#define FAILSAFE_RTH_DELAY 15 // in s - safety delay, after reaching HOME altitude, it'll land in FAILSAFE_ALT_MODE when safety delay terminates.and at the end
Code: Select all
//#define RTH_ALT_MODE // define RTH custom approach height
//#define RTH_KEEP_ALT // if the altitude is higher than the RTH_ALT, copter maintains that altitude instead of descending to target - according to Dramida's request
#define RTH_VARIO 100 // in cm/s - vario used for reaching target altitudes during RTH - lower limit is 25 cm/s!
#define RTH_ALT 700 // in cm - altitude during approach
#define HOME_ALT 350 // in cm - altitude after reaching home position Re: Altitude Hold improvement solution
Yes, because the failsafe rth can be set up independently...
Ie. You can set higher altitude for failsafe rth than for normal. Or different vario...
Br
Adrian
Ie. You can set higher altitude for failsafe rth than for normal. Or different vario...
Br
Adrian
Re: Altitude Hold improvement solution
I downloaded and setup this build for my Board. I connected using the GUI & went to setup my flight modes and noticed there were already flight modes programmed. So I tried to clear them and it would not let me. I was able to add to the flight mode programming, but I could not remove what was originally there.
I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1
I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1
Re: Altitude Hold improvement solution
subaru4wd wrote:I downloaded and setup this build for my Board. I connected using the GUI & went to setup my flight modes and noticed there were already flight modes programmed. So I tried to clear them and it would not let me. I was able to add to the flight mode programming, but I could not remove what was originally there.
I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1
Hi,
could you please share a screenshot about these flight modes? I can't understand clearly what you are talking about. You mean BOX items are already checked?
also, please give me the type of your controller (MEGA, 328p), the copter type and the sensor board. I didn't modified any part of the EEPROM file, so it is really strange.
There is one more thing. If you power on multiwii only without RX, and connect to gui, and Failsafe is uncommented (enabled), the ANGLE and MAG will shown as active (green), that's because when in failsafe, these functions are enabled automatically. That is because there is no valid RX data. If you turn on RX too, they must disappear in case are not selected by BOXes.
Regarding ro r9, that was much less completed than r13, although the part of headfree was not touched in the code. You wrote it didn't worked at all, that means you couldn't activate the function, or activated but not worked as it should?
BR
Adrian
Re: Altitude Hold improvement solution
Sorry Adrian. I should have provided you with all the information
I am using this board here: http://witespyquad.gostorego.com/flight ... oller.html (easier than typing a list of spec's) flying on my X-Quad
Yes exactly. I should have got a screenshot, but the last 4 flight modes (BEEPER, LEDMAX, LANDLIGHT, HEADADJ) all had boxes marked at random. They all had multiple boxes checked for all 4 AUX channels too. I tried to uncheck them and write to the board, and the boxes remained marked. I could mark unmarked boxes, and successfully write to the board, but I could not remove the originally marked boxes.
This was all done with the board powered by a LiPo, so the RX was powered and my TX was active. And I have failsafe commented out in config.h, I am more interested in your improvements to AltHold right now, and not so much RTH.
With R9 & Heading Hold I was activating the function with my TX Switch but the aircraft did not act as if it were in headsfree mode. I Tried a couple times by orientating the board in different positions and booting it up. However I did not look at my 3DR telemetry while flying, so I am not 100% the board had activated HeadsFree mode.
I am using this board here: http://witespyquad.gostorego.com/flight ... oller.html (easier than typing a list of spec's) flying on my X-Quad
I can't understand clearly what you are talking about. You mean BOX items are already checked?
Yes exactly. I should have got a screenshot, but the last 4 flight modes (BEEPER, LEDMAX, LANDLIGHT, HEADADJ) all had boxes marked at random. They all had multiple boxes checked for all 4 AUX channels too. I tried to uncheck them and write to the board, and the boxes remained marked. I could mark unmarked boxes, and successfully write to the board, but I could not remove the originally marked boxes.
This was all done with the board powered by a LiPo, so the RX was powered and my TX was active. And I have failsafe commented out in config.h, I am more interested in your improvements to AltHold right now, and not so much RTH.
With R9 & Heading Hold I was activating the function with my TX Switch but the aircraft did not act as if it were in headsfree mode. I Tried a couple times by orientating the board in different positions and booting it up. However I did not look at my 3DR telemetry while flying, so I am not 100% the board had activated HeadsFree mode.
Re: Altitude Hold improvement solution
Thanks for detailed description.
That's really interresting indeed. I never had anything like this. Today I tested my code on a small arduino nano board (328p) with a 10DOF panel attached temporarily.
I uploaded many variations and tested to write/read EEPROM many times but I still couldn't reproduce this issue.
And this also presents with my r13? If yes, could you please try the official r1311 from download page on MWI repo?
Also, could you send your config.h in PM? I'd check, maybe you use something which I never had uncommented before and there is something interference...
I had once a similar behaviour with my older config on a Quadrino board around MWI 1.9-2.0 long time go, I don't know the reason till now, but I made a full EEPROM reset with an EEPROM reset sketch and disappeared.
If you can disconnect ESCs, you can test hearfree in your hand, arm the copter, apply some throttle, push roll or pitch. So you will see the motor outputs on GUI like they're trying to moce copter (2 of 4 motors will increase other will decrease). Now rotate copter around z axis (yaw) by 90 degrees, apply the same stick movement, and if headfree is active indeed, you will see that different motor outputs will increase or decrease...
BR
Adrian
That's really interresting indeed. I never had anything like this. Today I tested my code on a small arduino nano board (328p) with a 10DOF panel attached temporarily.
I uploaded many variations and tested to write/read EEPROM many times but I still couldn't reproduce this issue.
And this also presents with my r13? If yes, could you please try the official r1311 from download page on MWI repo?
Also, could you send your config.h in PM? I'd check, maybe you use something which I never had uncommented before and there is something interference...
I had once a similar behaviour with my older config on a Quadrino board around MWI 1.9-2.0 long time go, I don't know the reason till now, but I made a full EEPROM reset with an EEPROM reset sketch and disappeared.
If you can disconnect ESCs, you can test hearfree in your hand, arm the copter, apply some throttle, push roll or pitch. So you will see the motor outputs on GUI like they're trying to moce copter (2 of 4 motors will increase other will decrease). Now rotate copter around z axis (yaw) by 90 degrees, apply the same stick movement, and if headfree is active indeed, you will see that different motor outputs will increase or decrease...
BR
Adrian
Altitude Hold improvement solution
Tried 2.2 r1311 on a Avatar Tri., Alt Hold works great with default PID's. POS hold also works much better. High winds like 15 mph and held its own within a few meters