Altitude Hold improvement solution

scrat · Post by **scrat** » Fri Nov 23, 2012 10:01 pm

Not good...with r1275 if I arm my board with BARO ON - motors start's spinning.

So can anybody check the code and repair it because of this DANGER bug.

NikTheGreek · Post by **NikTheGreek** » Sun Nov 25, 2012 5:56 pm

Hi.
I'm using 1240r and i want to test AltHold.
What should i do ?
Can i go directly to r1257 and merge the changes or sould i do it step by step from 1240 to 1257 ?

vpb · Post by **vpb** » Mon Nov 26, 2012 6:05 am

You can jump over to the latest dev version if you want. try ALTHOLD_FAST_THROTTLE_CHANGE & ALT_HOLD_THROTTLE_NEUTRAL_ZONE

copterrichie · Post by **copterrichie** » Mon Nov 26, 2012 9:00 am

If I am not using a Baro, I should be able to use R1277 correct?

scrat · Post by **scrat** » Mon Nov 26, 2012 11:08 am

copterrichie wrote:If I am not using a Baro, I should be able to use R1277 correct?

Why not. Is there a problem in r1277?

copterrichie · Post by **copterrichie** » Mon Nov 26, 2012 12:15 pm

scrat wrote:
copterrichie wrote:If I am not using a Baro, I should be able to use R1277 correct?

Why not. Is there a problem in r1277?

It is now up to R1279, just minor fixes.

vpb · Post by **vpb** » Mon Nov 26, 2012 4:50 pm

copterrichie wrote:If I am not using a Baro, I should be able to use R1277 correct?

yeah it's sure

scrat · Post by **scrat** » Tue Nov 27, 2012 8:18 am

scrat wrote::shock: Not good...with r1275 if I arm my board with BARO ON - motors start's spinning.

So can anybody check the code and repair it because of this DANGER bug.

Anyone please?

Polleke · Post by **Polleke** » Tue Nov 27, 2012 6:47 pm

I'm using this version: MultiWii_2_1_NewBaroPIDVario4Final. (standard settings)
This is what happens when I switch on the ALT Hold (in the air), it's gaining height (slowly)

So it does'nt hold alt.
When I switch off the ALT hold and try to descend it holds alt untill I lower the throttle so much that the copter falls from the sky like a rock.
Almost throttle shut before I even get a reaction. :shock:

Next, I quickly have to give a lot of throttle to "catch" the copter from crashing and try to land by "pumping" the throttle up and down and up and down. :!:

Anyone got this behaviour?

Crashpilot1000 · Post by **Crashpilot1000** » Fri Nov 30, 2012 11:59 pm

Anyone got this behaviour?

LOL, yes,me ! It is a feature! Please read the instrucions in config.h !!!!! If you want althold turned off immediately use " #define Rapid_Exit_Barologic2".
Please check your ACCZ direction and evaluate the use of the LPF. Then tune P and I. Here are some infos in german: http://fpv-community.de/showthread.php? ... post224135

So long
Rob

Polleke · Post by **Polleke** » Sat Dec 01, 2012 11:24 am

Crashpilot1000 wrote:Anyone got this behaviour?

LOL, yes,me ! It is a feature! Please read the instrucions in config.h !!!!! If you want althold turned off immediately use " #define Rapid_Exit_Barologic2".
Please check your ACCZ direction and evaluate the use of the LPF. Then tune P and I. Here are some infos in german: http://fpv-community.de/showthread.php? ... post224135

So long
Rob

Hi Rob (Crashpilot1000, what a name :lol:

)
First of all, thanks for the fine job on the ALThold, great job.......
Because I'm rather new at this, still got a question. :mrgreen:

What do you mean by "Please check your ACCZ direction and evaluate the use of the LPF"

Greatings Paul (the Netherlands)

tovrin · Post by **tovrin** » Sat Dec 01, 2012 5:34 pm

I believe he means for you to make sure that the Z axis of your accelerometer is set right and reacting properly in the GUI (move your quad up and down while watching the GUI and make sure Z axis moves appropriately.)

then go into the arduino software sketch and enable the LPF of your accelerometer to help reduce the affect of vibrations to your flight controller

Vaattari · Post by **Vaattari** » Sat Dec 01, 2012 5:57 pm

Hello,

What is the accuracy in altitude hold mode you guys are getting with the latest dev? In MW 2.1 I can easily tune out +/-20cm but in latest dev the hex goes up and down like +/-1m... I'm out of options as everything is tried to get the vibes off from motor/props. I have separate jig to balance the set accurately. Balancing motor/hub/prop seems to improve MW2.1 side but not with dev side :roll:

I'm using BMA180 and MS5611.

Thanks,
Janne

Polleke · Post by **Polleke** » Sat Dec 01, 2012 7:45 pm

tovrin wrote:I believe he means for you to make sure that the Z axis of your accelerometer is set right and reacting properly in the GUI (move your quad up and down while watching the GUI and make sure Z axis moves appropriately.)

I did.
I cant see the grafics move, but I can see the value changing. (see attachment)
Moving up is going from 258 to 270
Moving down gives a lowering value 258 to 230.
Is that right????

Changed also the LPF to 42hz (did that allready in previous flights, because of the wobbling

)

Crashpilot1000 · Post by **Crashpilot1000** » Sat Dec 01, 2012 11:12 pm

Hi Polleke!
Moving your copter up should rise the value (for a short period of time, and then values swing back). So this is correct. By using 42Hz Hardware LPF i assume you have a FREEIMUv04 ? You can activate the software LPF as well #define AccBaroLPF 50. You can visualize the values with running motors like described in the config.h. I still use the original mwii gui.

So long
Kraut Rob

P.s. Too bad Steenbergen is 260km away.

jy0933 · Post by **jy0933** » Sat Dec 01, 2012 11:25 pm

Polleke wrote:
tovrin wrote:I believe he means for you to make sure that the Z axis of your accelerometer is set right and reacting properly in the GUI (move your quad up and down while watching the GUI and make sure Z axis moves appropriately.)

I did.
I cant see the grafics move, but I can see the value changing. (see attachment)
Moving up is going from 258 to 270
Moving down gives a lowering value 258 to 230.
Is that right????

Changed also the LPF to 42hz (did that allready in previous flights, because of the wobbling )

you gotta change the scale ... it is default +/-150.... but acc is around 250

Polleke · Post by **Polleke** » Sun Dec 02, 2012 10:36 am

"you gotta change the scale ... it is default +/-150.... but acc is around 250"

Did'nt know that this is possible in this GUI version :oops:

Still learning though .............. :mrgreen:

Thanks a lot

nhadrian · Post by **nhadrian** » Thu Dec 20, 2012 6:11 am

Hi all,

I tried the r1282 with the "vari" based altitude hold code. OK, basically I can move up or down, or stay in position. But it is far not exact. I modified the code for changing the AltHold parameter with exact values, so theoretically ascending/descending speed could be set to any value.
But, I had to realize that the PIC regulation can't follow big AltHold value changes, the maximum is about 80 cm/s...

So this method for vario-based alt changing is not the real solution.

My oppinion we should rethink the althold algorythm. My idea is that instead of regulating based on EstAlt parameter, we should use the Vario number. For example, for hoovering, target value is 0, for ascending/descending, 100-150 cm/s, or any . Once we have such a regultion, changing altitude during RTH, or automatic landing, etc would be as easy as it can be! Just tell the target vario and the target altitude...

Or the other possibility would be a PI-PID cascade regulation like in GPS code...

But I can't do this, too comlpicated for my knowledge in Arduino.

BR
Adrian

PS.: for this, first we should have a rock-solid vario calculation...

dramida · Post by **dramida** » Thu Dec 20, 2012 10:54 am

nhadrian wrote:Hi all,

I tried the r1282 with the "vari" based altitude hold code. OK, basically I can move up or down, or stay in position. But it is far not exact. I modified the code ...........

BR
Adrian

Adrian, my test with vario altitude mode with Mahowik code where look promising in altitude hold and variation. I don't know how much "exact" is the controller. Please see this video: http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

vpb · Post by **vpb** » Thu Dec 20, 2012 1:06 pm

Hi Dramida, the vario altitude looks promising, but do you feel sometime it's not continuos, especially in height gaining. But overall it's still very nice, I'll merge back the vario altitude with latest dev.

nhadrian · Post by **nhadrian** » Thu Dec 20, 2012 6:42 pm

dramida wrote:
nhadrian wrote:Hi all,

I tried the r1282 with the "vari" based altitude hold code. OK, basically I can move up or down, or stay in position. But it is far not exact. I modified the code ...........

BR
Adrian

Adrian, my test with vario altitude mode with Mahowik code where look promising in altitude hold and variation. I don't know how much "exact" is the controller. Please see this video: http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

Hi,

it looks in your video that you have only one rising/descending speed available, depending on your cycle time, Baro PID, config, etc...

for further RTH/waypoint/etc. functions it would be neccessary to handle the vario. I mean, if you set up 100 cm/s than it has to be 100 cm/s independently from your config, Baro PIDs, etc. And, for example, it the full throttle is 100 cm/s than 3/4 throttle should mean 50 cm/s. This couldn't be rached using Baro PID approach...

BR
Adrian

nhadrian · Post by **nhadrian** » Sun Dec 23, 2012 10:29 am

Hi guys,

Finally I finished my first implementation of a vario based alt-hold code.
Basically it runs on 25 Hz, and changes AltHold variable regarding to throttle stick position. So the more/less throttle is applied, the faster the rising/descending is.
For proper code working when higher vario rates needed, I use variables in BaroPID calculations instead of stored eeprom values, which are modified according to ALT_HOLD code state.These parameters still needs some fine-tuning. (The problem is that BaroPID calculations are tuned for hovering, and can't allow high rising/descending speeds, even if AltHold parameter itself is changing as fast as it has to.)
Also, I implemented a solution for fixed RTH altitude ang HOME altitude. It only works when BARO mode is active! When RTH is activated, copter rises to the desired altitude, and when reaches the home point, it descends to the home altitude.

If you would try my code, please BE AWARE of these facts:
- I implemented the code on a small Y6 copter (AUW is 500 g!!!) so maybe parameters needs to be fine-tuned on a bigger copter!!!
- I'm using P=50 I=30 D=30 for PIDs
- In cold conditions, let the sensors cooling down for some minutes, because when temperature falls down during flight, it can cause 5-10 m change in altitude reading!!! So then RTH altitudes will become false!!!
- USE IT ON YOUR OWN RISK!!! I suggest study the code itself before take-off, to understand how it works!!!
- The code works ONLY when BARO is active!!!!!!! So once you switch off the BARO mode, you WILL HAVE full manual throttle control again!!!!!!
- I use it in a MEGA based controller (Crius AIO PRO), so maybe code size is too big for 328p controllers with GPS.

Looking forward to any test results, suggestions!

BR Adrian

PS.: I can't upload any videos right now.

Polleke · Post by **Polleke** » Sun Dec 23, 2012 10:52 am

Thanks Adrian for keeping up the good work.
Gonna try this on my Quad CRIUS SE (modified the config.h allready)
But I need some nice weather :!:

nhadrian · Post by **nhadrian** » Mon Dec 24, 2012 2:20 pm

Hi,

please DO NOT UPLOAD my code untill I release the new one.
Unfortunatelly I found a BUG inside code...

:(:(

BR
Adrian

nhadrian · Post by **nhadrian** » Thu Dec 27, 2012 9:40 am

Hi guys,

FINALLY I reworked my code completelly, works as it was described previously, the more/less throttle is applied, the more/less vario will used for rising/descending.
Now it works as it should, comments are added into config.h and in the code itself too, and tried to clean the code for further applications/modifications! There is a change in imu.ino too! (Any modified rows are marked with //NHADRIAN for further merging)

I made a code for automatically reaching target altitude, now if is linked to RTH mode (so RTH altitude/HOME altitude can be set for RTH independently!!!), but can be used for further WP navigation too!!!

Also a modification to the servo-tilt function is added, generally there are tunable parameters for compensating servo-speed, inertia, etc. Basically allows to reduce small moves in the video. There is a mix built in for FPV flyers too!

I also added a throttle-angle correction (based on Alexmos code!!!), and works in ANGLE/HORIZON mode all time,not only in BARO mode. It helps keep altitude in manual throttle mode too.

I tested all functions, works great with my 500 g AUW Y6 copter and CRIUS AIO PRO board (MS5611-01 baro), still no video, so any videos and experiences are wellcome!

PLEASE NOTE that you should have a well-tuned ALT PID, so first please set up them correctly in hoovering (so activate the BARO mode but don't touch throttle stick to check the PID settings). Also, please let sensors cool down in cold temperatures before take-off, otherwise RTH altitudes will maybe act like false, causing dangerous situations!

I wish you all good luck and Happy New Year from Hungary!!!

BR
Adrian

PS.: the code of EOSBandi for GPS modifications in r1292 is also added.

dramida · Post by **dramida** » Thu Dec 27, 2012 10:17 am

Great news Adrian! I'll test it today along with Eos patch for mag. Best regards, Mihai.

nhadrian · Post by **nhadrian** » Thu Dec 27, 2012 10:43 am

I forgot to tell that since 150-200 cm/s is quite fast for descending, first of all you should have perfect PIDs on all axes, and perhaps should have some TPA adjustments too. For me, the value is 0,35 in GUI (helps prevent oscillation during desending). Basically it can be said that before test my code, set up the copter as perfect as you can!!!

I suggest:
1) set up basic PIDs in Acro mode
2) fine tune Angle/Horizon mode
3) tune PIDs for Baro in hoovering
4) fine-tune GPS parameters (for hold, home)
5) fine-tune servo-tilt (if you have any)
6) Fly-fly-fly!!!!!!

BR
Adrian

pd.: Mihai, good luck on test!!! Looking forward to your experiences!!!

nhadrian · Post by **nhadrian** » Thu Dec 27, 2012 10:21 pm

Hi,

I also added a fixed vario descending feature to Failsafe mode.
I have never tested the failsafe routine itself before, I hope I'll have time to do that tomorrow. Any input are wellcome!
PLEASE BE CAREFUL when testing failsafe!!!

BTW, It should work because is based on the previous code part...

BR
Adrian

carlonb · Post by **carlonb** » Thu Dec 27, 2012 10:36 pm

nhadrian wrote:I forgot to tell that since 150-200 cm/s is quite fast for descending, first of all you should have perfect PIDs on all axes, and perhaps should have some TPA adjustments too. For me, the value is 0,35 in GUI (helps prevent oscillation during desending). Basically it can be said that before test my code, set up the copter as perfect as you can!!!

I suggest:
1) set up basic PIDs in Acro mode
2) fine tune Angle/Horizon mode
3) tune PIDs for Baro in hoovering
4) fine-tune GPS parameters (for hold, home)
5) fine-tune servo-tilt (if you have any)
6) Fly-fly-fly!!!!!!
BR
Adrian

Hi Adrian, I will test tomorrow.... but after about 1 year that I already have a copter and fly great in acro/stable mode as far today for me (after read and read topics/forums etc..) is not so clear how to setup PID for:
3) ....Baro PID tuning

4) ....GPS parameter tuning

So, please, as you do this software, you sure know the better way for baro and GPS tuning, please...please...please write down few words to exlain how to.

Tx, Carlo

nhadrian · Post by **nhadrian** » Fri Dec 28, 2012 5:49 am

For GPS, here is a good description of the PI-PID parameters:
http://code.google.com/p/i2c-gps-nav/do ... f&can=2&q=
reading this, and understanding the parameters it will be clear, I hope, what to do...

For BARO, I don't have any practice, I have flew out many - many batteries, trying different setups and check the behaviour. So now it works.

BR
Adrian

nhadrian · Post by **nhadrian** » Fri Dec 28, 2012 11:15 am

Hi all,

Regarding to this comment of BuckSwasher on the following video:

"Very nice ADRIAN, that IS A impressive video. BUT could you please refrain from releasing your buggy code to our community, as we don't like playing POKER with our expensive toys."

I removed all my codes.

http://www.youtube.com/watch?v=NG0eRldeJ2k

BR
Adrian.

Ps.: if you are interrested than send a mail on nhadrian:)gmail.com ... I wish you all good luck, happy landings!!!

dramida · Post by **dramida** » Fri Dec 28, 2012 3:32 pm

My "expensive" toy costs about 150 USD and i am ready to crash it every time it needs to evolve this software, so please, Adrian, don't bother to respond to all. And of corse, i need your R4 file as i downloaded only R2.

copterrichie · Post by **copterrichie** » Fri Dec 28, 2012 3:40 pm

Adrian,

Please be advised, there are some very Jealous folks about, pay them no mind and keep up the GREAT Job!

nhadrian · Post by **nhadrian** » Fri Dec 28, 2012 3:43 pm

OK, r5 is here.

I still have to work some on Failsafe, but will be great! My goal is to rise with defined vario and stop motors once on the ground. I'm close to this...

BR
Adrian

nhadrian · Post by **nhadrian** » Fri Dec 28, 2012 5:11 pm

I have finished the failsafe code.

Basically when Failsafe, copter starts descending with defined failsafe vario.
Once hits the ground, the Baro PID starts to reduce RPM to force descending. Because it can't, after reaching low BaroPID enough (or reach the defined disarm failsafe time), failsafe disarms. That also means higher altitude failsafe needs more time!!!

I couldn't try in the air because my Y-6 copter is small and doesn't tolerate hard landings in grass (and since other channels are set to 0, I wouldn't test inside...).
But, the code itself works like this:

http://www.youtube.com/watch?v=9wNJt2_5R9w

I attached my r6 code with failsafe. Please BE CAREFUL, this is full EXPERIMENTAL, try it on YOUR OWN RISK! (I tested all previous functions, worked well for me.)

BR
Adrian

dramida · Post by **dramida** » Fri Dec 28, 2012 5:51 pm

just uploaded R 5 to my tri and i am glad to see the latest release R1298 is present

good job . Now i am leaving to fly it:)

subaru4wd · Post by **subaru4wd** » Fri Dec 28, 2012 5:56 pm

Adrian Great Work!!! This project needs more people like you. And less people like BuckSwasher.

Believe me... the majority of members here are using DIY Scratch Build quads and are not worried about crashing. I sure am not... i built my quad by hand, and i am not affraid to do it again... and again... and agian..... :mrgreen:

alexia · Post by **alexia** » Fri Dec 28, 2012 6:03 pm

thanks adrian for you share
it s very nice!

dramida · Post by **dramida** » Fri Dec 28, 2012 9:29 pm

I just flew R5 from Adrian on a Crius AIOP with Ublox 6M serial GPS.
Remarks:
-Alt Hold works as expected
-Vario works also but some times has some bumps (tried throttle max and while rising the speed was not constant relatively)
- The ALT HOLD position of throttle stick is the position in where ALT HOLD was engaged. After a few climbs- descends, this variable ALT HOLD position of throttle could lead to confusion when piloting very high or in fpv mode. Also for this reason i could not take off in alt-vario mode. Also in receiver failsafe, it might be a possibility to not keep the altitude in rth if the throttle is moved from AH point.
- In RTH mode, the copter climbed to standard altitude (10m) , come home at this altitude but instead of landing, it keep rising and i have to disengage RTH because it was night and i couldn't see it anymore. Later i found out that i put 10000 instead of 100 to home altitude

so the algorithm works

- i didn't tested if yaw left disarms copters in Alt Vario mode when throttle at minimum.
- i didn't tested if the altitude of copter is higher than rth altitude, the copter descends or keeps its greater altitude. (i hope it keeps the higher altitude to regain receiver signal in case of receiver failsafe rth)

Keep the good work Adrian and please describe us the algorithm you adopted.

nhadrian · Post by **nhadrian** » Fri Dec 28, 2012 9:56 pm

Hi,

thanks for the tests!
Trying to answer some questions:

1) about middle point. I was in hesitating a lot in between that 1500 or the activation throttle should be the middle of vario (0 cm/s). Now, the activation throttle is the midpoint. But, it could be defined in config.h to give the choice to everyone (I'll do that tomorrow!)

2) about small "bumps". There are some correction parameters defined (for P, I, D). Maybe different copter needs different corrections in PID parameters during rising/descending.
You should try to adjust them, if you use negative value, it means it reduces the preset PID values. Unfortunatelly I don't have any heavier copter to test the behaviour.

3) in RTH mode, now it every time rises/descends to the target altitude, doesn't matter where the copter is when activated. I think it is the responsibility of the user to set high enough RTH altitude taking into consideration the circumstances on field (trees, etc.). Basically I wrote this alt_to_target code for universal usage, so it can be called during future WP navigation too.

4) in r6 in failsafe code my "only" modification is that copter descends to the ground with constant vario instead of using a fix throttle. And when lands, it disarms (before timer ends) to prevent further damages caused by spinning props.

5) now it looks for me like a more featured failsafe could be established. As you mentioned, in failsafe (when GPS presents and available) copter starts RTH on a safety altitude, but lands and disarms after reaching home. What do you think, would it have sense? (It is quite difficult to give back the control during RTH when copter is in failsafe mode. )

BR
Adrian

PS.: and do not forget to set up the THROTTLE_ANGLE_CORRECTION without alt_hold enabled!!! Set hoovering throttle and try to move ie. roll left-to-right with some meters of flying between, and watch the reaction. The value is OK when it quite holds altitude without correcting throttle.
This is a really useful feature even is flying in ANGLE mode without ALT_HOLD enabled! (and also helps BaroPID regulation in windy conditions!)

nhadrian · Post by **nhadrian** » Sat Dec 29, 2012 9:15 am

Hi,

I attached the r7.
Now, in config.h the middle stick position can be set by value. If commented, the initial throttle position is used.

BNR
Adrian

dramida · Post by **dramida** » Sat Dec 29, 2012 9:23 am

Sometimes I fly kilometrs away in fpv mode for AP photos of large areas. Imagine i am 800m height and i have a short receiver failsafe.
You realise that if is taken the control from me in this point till copter reaches home ground, i fail the photo shoting.I need control asap when signal gets stronger.
More over, lets say the terain is not flat and i have a rth altitude of 50 m. Firstly i lose the signal completly as the copter descends and secondly it will crush into groud.
So in rth mode you should check if current altitude is greater than rth altitude and if is so, use current. It is difficult to change this altitude by recompiling the code on the field. I use only my android phone to set the copter, thanks again Bart for EZ-gui.
Anyway your code is an amazing evolvment. Keep up the god work Adrian.

nhadrian · Post by **nhadrian** » Sat Dec 29, 2012 9:48 am

Hi,

OK, I'll make some changes in RTH altitude code, making definable this feature.
BTW, I'm ready with the advanced failsafe code (I hope...

) I'll do the first onfield tests in the afternoon. If everything works fine, it should start RTH once signal lost and give back control when signal is back. (It GPS signal is weak, it lands where it is...)

BR
Adrian

dramida · Post by **dramida** » Sat Dec 29, 2012 12:51 pm

We need a procedure to adjust the Vario PID.

Code: Select all

 
    #define PIDALTP_CORR 30  // For test and developer purposes only!!!  -  ALT-P correction during rising
    #define PIDALTI_CORR 0  // For test and developer purposes only!!!  -  ALT-I correction during rising
    #define PIDALTD_CORR 20   // For test and developer purposes only!!!  -  ALT-D correction during rising

My guess is :
Set I=0, D=0
Fly with max throttle and increase P until the climb becomes bumpy
Decrease P to 0,6 of the previous value
Increase I until climb becomes bumpy
Decrease it to latest good climb and then verify the descent rate to be smooth.
I don't think we need D controller for a momment because can induce bumps by derivating noise.

ps: I suggest to rename PIDALTP variable notation a more apropiate one like VarioAltP, VarioAltI, VarioAltD
my two cents.

nhadrian · Post by **nhadrian** » Sat Dec 29, 2012 4:05 pm

Hi,

And, if you check out in multiwii.ino, they are used with different multiplyers and ways on rising / descending.
So If I'd be correct, 6 parameters should be changed not 3... but I'm sure with the good multiplyer 3 is enough like now.

The desired vario is added to vel_tmp before calculate "D", so theoretically there won't be more noise than in hovering. The reason I left D in was that when changing between hoovering and rising, there was always a bump caused by D turned on. BTW, maybe another solution is available...
The suggestion is great. But my main problem is that there is two vario called function at the same time, maybe the beeper should renamed to vario_beeper, or similar like this. I'll think on it!!!

BR
Adrian

pr.: I'm ready with the failsafe RTH and high altitude variation of RTH asked bny Dramida. I'll do the final tests tomorrow and if everything works correctly, I'll share along with a sample video!!!

copterrichie · Post by **copterrichie** » Sat Dec 29, 2012 4:14 pm

Would it be possible to monitor the Acc Z axis at take-off and set a variable to establish the point on the throttle curve at which the copter becomes airborne? This I believe would take out the guess work of determining the right point where the copter will hover.

nhadrian · Post by **nhadrian** » Sat Dec 29, 2012 5:11 pm

The problem is that the hovering point moves up as voltage drops down (because of cold, emply battery, etc...).
So you will need to apply more and more value to the ESCs for hovering, so can't say there is a specified value for hovering.
BaroPID makes this compensation during regulation.

copterrichie · Post by **copterrichie** » Sat Dec 29, 2012 5:15 pm

Yea, I can clearly see this now. All most seems as if we need a RPM feedback system from the ESCs, but that can get VERY Complicated. The idea of I2C ESCs died awhile back and just seems unrealistic at the time.

nhadrian · Post by **nhadrian** » Sat Dec 29, 2012 6:55 pm

Maybe a compensation to voltage could be set. But instead of adding to the Throttle, maybe should added to the output values. Than the other 3 axix PID could be conpensated, giving constat behaviour through the whole flight...
The question is that has it sense? (Because the system works quite well right now...)

dramida · Post by **dramida** » Sat Dec 29, 2012 7:11 pm

Adrian, i am no coder, please give me some guide lines on how to setup VarioPID's.
Is I term useful? Can I make D=0 and experiment with I only?