Altitude Hold improvement solution

mahowik · Post by **mahowik** » Thu Oct 25, 2012 6:47 pm

dramida wrote:I prefer to work with dev files R1177 would be fine, i like to test

pls. use the following define in config.h to switch between "alt change" solutions:

    // Natural alt change for rapid pilots. It's temporary switch OFF the althold when throttle stick is out of deadband defined with ALT_HOLD_THROTTLE_NEUTRAL_ZONE
    // but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). It's slowly increase/decrease 
    // altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms)
    #define ALTHOLD_FAST_THROTTLE_CHANGE

diyboy · Post by **diyboy** » Mon Oct 29, 2012 3:12 pm

mahowik wrote:

dramida wrote:I prefer to work with dev files R1177 would be fine, i like to test

pls. use the following define in config.h to switch between "alt change" solutions:

Code: Select all

    // Natural alt change for rapid pilots. It's temporary switch OFF the althold when throttle stick is out of deadband defined with ALT_HOLD_THROTTLE_NEUTRAL_ZONE
    // but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). It's slowly increase/decrease 
    // altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms)
    #define ALTHOLD_FAST_THROTTLE_CHANGE

Hi Alex,

Is this new routines already implement to MultiWii_dev_r1232?
Can i test it with MultiWii_dev_r1232?

Thx
Diyboy

mahowik · Post by **mahowik** » Mon Oct 29, 2012 11:05 pm

diyboy wrote:Is this new routines already implement to MultiWii_dev_r1232?
Can i test it with MultiWii_dev_r1232?

I have merged these solutions with last MultiWii_shared sources... you can take it here http://code.google.com/p/multiwii/sourc ... %2FMahowik

thx-
Alex

dramida · Post by **dramida** » Mon Oct 29, 2012 11:26 pm

Are you aware about ALT bug from R1188 afterwards? viewtopic.php?f=8&t=2678

Crashpilot1000 · Post by **Crashpilot1000** » Tue Oct 30, 2012 12:32 am

Don't download or even look at my version http://fpv-community.de/showthread.php? ... post224135.
I tried the current Dev and i see it's severe limitations in windy and forward flight conditions. I will just look here and take the best parts for my needs. All i can tell you is, that changing the throttle relative to the throttlestick middle will not do a good job. I did it and already switched to changing the target hight (like naza) but that will require fast recognition of the current hight - and the current DEV (even with working baro readout) will never do this because everybody is afraid to increase the cycletime - ROFL, at least Timecop will understand me. The day when the baro is polled at 1HZ i will have a big laugh.

Sebbi · Post by **Sebbi** » Tue Oct 30, 2012 2:39 am

Two things here:
1) without GPS activated baro is read out almost as fast as possible for some time now ... true, altitude gets only calculated at 40 Hz, that's something that can be improved
2) Is your code free to use AND this is exactly what some of use talk about, having patches or zip files with versions floating around all over the internet. Use source control (git prefered) damnit ;-)

P.S.: I looked at your code. It will probably suffer the same problem as the code posted here: temperature change will cause acc_1G to be a different value and accZ might be off a little bit. You do the baro stuff after computeIMU(), is there a reason for this change? Your code is very similar to mahowiks code except for some averaging and an interesting new PID controller. But flips when touching down - however briefly - would be a no go for me. Do you have a video of this in action?

nhadrian · Post by **nhadrian** » Tue Oct 30, 2012 5:52 am

Dear mahowik!

I like your idea of having throttle-stick based altitude change during alt. hold! BUT!
I'm not a programmer at all but I learnt about regulations during my university studies.
My oppinion is that once we would like to control the altitude too, there should be two different altitude hold modes (just like in mikrokopter, I used it for a while)

1, The first mode should work like throttle stick is showing a conctere altitude. So when throttle stick is moved up or down, multiwii changes the altitude with constans vario to that desired point. So a relation between throttle stick range and altitude range should defined (ie. full throttle stick range is 20m in altitude...). Also that is important that once function is disabled, it gives back the throttle control continously within 3-5 seconds (to avoid fast movements, let pilot reduce or incease throttle for manual piloting.)
What is the hard job in this? For proper working, not altitude but VARIO should be regulated via PID controls!!! Then, it would be easy to ascend or descend with any vario continously.
This function also could be the basic of the later Waypoint navigation!

2, The second mode is similar like yours. But, in this mode, throttle stick position gives a desired vario. So, I think the regulation should be divided into two parts, when throttle stick is inside ALT_HOLD_DEADBAND, thne current altitude regulation should be used (but, angle correction is neccessary for proper forward flight or wind resistance!!! It is only some lines in code but gives much more better solution, I use it too). When throttle stick is out of deadband, it means we need to ascend or descend with a desired vario. So from now on, altitude regulation should use the vario ar segulated parameter, for smooth moving, instead of altitude PID!!!

I'm unfortunatelly not good enough to program these and test myself, but perhaps there is any ideas which could be used...

Thanks for reading.

BR
Adrian

nhadrian · Post by **nhadrian** » Tue Oct 30, 2012 6:02 am

My simple (but working) altitude correction is (origin from alexmos):

1, define this in config.h :

Code: Select all

#define THROTTLE_ANGLE_CORRECTION 400

2, add this into imu.ino , at the end of getEstimatedAttitude:

Code: Select all

cosZ =  EstG.V.Z / acc_1G * 100.0f; // cos(angleZ) * 100   
  throttleAngleCorrection = THROTTLE_ANGLE_CORRECTION * constrain(100 - cosZ, -150, 150) / 100;

3, add this to multiwii.ino, around the beginning:

Code: Select all

static int16_t throttleAngleCorrection = 0;    
static int8_t cosZ = 100;

4, in multiwii.ino, after this part:

Code: Select all

  #if BARO && (!defined(SUPPRESS_BARO_ALTHOLD))
    if (f.BARO_MODE) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) {
        f.BARO_MODE = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
    }
  #endif

add this:

Code: Select all

  #if THROTTLE_ANGLE_CORRECTION > 0   
      if(f.ANGLE_MODE && cosZ > 0) {
      rcCommand[THROTTLE]+= throttleAngleCorrection;
      }
  #endif

The value of THROTTLE_ANGLE_CORRECTION should be figured out on every multirotor, I don't have any pre-defined values for bigger copters (bigger than 35cm...

), start from value 200 and raise until you get good behaviour.

This correction works not only when BARO mode is active but every time.
Since I have a small Y6 copter which has to compensate wind with high angles, it is really useful in manual piloting too!!!
This correction helps for the BARO PID regulation, since this correction is a control, not a regulation, there is not any delay in compensation... (I hope you understand what I would say).

BR
Adrian

shikra · Post by **shikra** » Tue Oct 30, 2012 4:51 pm

Not tried the latest, but the r1177 still working well for me....

I couldn't resist the challenge set ...

http://www.youtube.com/watch?v=6gRhEFCi8A8

mahowik · Post by **mahowik** » Tue Oct 30, 2012 5:05 pm

Crashpilot1000 wrote:Don't download or even look at my version http://fpv-community.de/showthread.php? ... post224135.

Could you upload your ZIPs here, because I had some trouble to register on German resource

Crashpilot1000 wrote:changing the throttle relative to the throttlestick middle will not do a good job

If you are talking about first solution (2.a) from link below I found it useful for fast flying... i.e. when you need to have possibility to change throttle immediately...
viewtopic.php?f=8&t=2371&start=280#p25699

Crashpilot1000 wrote:I did it and already switched to changing the target hight (like naza) but that will require fast recognition of the current hight

As for me more than less it's implemented in second solution (2.b) and yes it's required up-to-date current altitude... this is why I used almost raw altitude (BaroAlt) when returning to center/deadband zone...
viewtopic.php?f=8&t=2371&start=280#p25699

Code: Select all

  // much usefull to use BaroAlt instead of EstAlt because it has less delay value when alt hold activated during the vertical movement
  AltHold = BaroAlt;

dramida wrote:Are you aware about ALT bug from R1188 afterwards? viewtopic.php?f=8&t=2678

already yes

but in any case it will be useful in case of BOSSes will decide to include this to release

thx-
Alex

Crashpilot1000 · Post by **Crashpilot1000** » Tue Oct 30, 2012 7:45 pm

@Sebbi @All: Sorry for my impolite post from above ....

@Mahowik:
Thank you for your interest! Btw there seems to be a very interesting implementation from MIS as well!
I included the zip file in this post.
There are some changes:
The "PID" controller is simpler but working good.
The "P" is what you would expect, the "I" is now a "variometerbrake" that will stop oscillations and the "D" is the throttle - angle - correction (something like nhadrian). So only 2 parameters for althold itself. I flew a complete lipo in althold. The missing real "I" is not a great problem. I do something like an "I" in the changing althold part of "barologic2".
I have two possibilities of changing the hight, explained in the config.h. "Barologic1" is similar to the original method but using a variometerbrake on lowering altitude for a specified time (0,5s default). "Barologic2" is throttlestick middle related and changes the target hight. I omitted Barologic3 - that was based on throttlechange.
I extended your forumla by an angle dependend factor to reduce acc misreadings in forwardflight. I found out that the obligatory baroacclpf is not necessary for my bma180 (20Hz hardwareplf by default) so i made this optional. The value in "//#define AccBaroLPF 50" is a percentage (0-100%) to make it more human usable than floatpoints.
I reduced the "constrain"s to reach desired target hight.

Please have a look at it, perhaps there is something of use.

So long
Kraut Rob

dramida · Post by **dramida** » Sat Nov 03, 2012 2:45 pm

Hi, i just test-flight the quad with Mahowik branch MWC R1248 ( http://code.google.com/p/multiwii/sourc ... %2FMahowik)

The focus was on controlling the altitude.
config.h

Code: Select all

  /* Natural alt change for rapid pilots. It's temporary switch OFF the althold when throttle stick is out of deadband defined with ALT_HOLD_THROTTLE_NEUTRAL_ZONE
   * but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). It's slowly increase/decrease 
   * altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms)
   */
  #define ALTHOLD_FAST_THROTTLE_CHANGE

Altitude hold works like previous and when rising throttle, the copter constantly gain height- nice

But when lowering throttle, the copter descend too fast in an accelerated manner. I couldn,t make the copter descend slowly in this configuration....
The nice thing is when throttle stick is back to middle to counter the descend, copter suddenly powers its motors 100% for a fraction to stop descending and hold altitude.

2 questions i have:
1- Aboyt calibrating 1G AccZ: I have a buzzer mounted on copter and three status leds(Crius AIOP). Is any sign that Giro and ACC calibration is successfully? Or at least is done and i can move the copter?
2- About howering throttle position: If my copter is loaded and hower position is at about 75% of throttle, how it will behave when enable ALt Hold? Is any variable to define Altitude Hold throttle position? Is it presumed by default 1500us? Is it presumed the throttle at witch ALt Hold is enabled?

Latest edit: as i wrote the post, i realized that i was on "natural for rapid pilots" mode. I have to comment the define to enter in Aerial Photographer mode

Now back to parking lot for testing the AP mode

vpb · Post by **vpb** » Sat Nov 03, 2012 5:34 pm

Hi dramida, can you share your ALT PID? Do you keep I as 0.01 as Mahowik guided?

dramida · Post by **dramida** » Sat Nov 03, 2012 9:47 pm

AP mode of altitude hold works very nice in Mahowik trunk(http://code.google.com/p/multiwii/sourc ... %2FMahowik). With a little tweaking, it could be a standard feature of MWC.
Here is a demonstrative video in witch you may see the stick position and the altitude of the copter. An auto-landing attempt is also made successfully

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

I strongly advice you to test this feature, it's so pleasant to see the copter coming down slowly:)

Also there is a little bug and a little tweaking with define needed:
BUG: In Alt Hold, put throttle to maximum, the copter slowly rise-Good. Now disable Alt Hold and copter shoots in the sky. Re-enable Alt Hold and copter stops and steadely gain altitude again, but, you will observe that the copter is no more able to be altitude controlled, you have to disable alt hold to be able to land.
TWEAKING: The speed of rising should be more "flexible", from alt hold to full speed up, you can observe that with full throttle, the copter barely rise.

@vpb, about ALT HOLD PID: I left the "I"- term untouched, i rised D = 60, P= 6.

shikra · Post by **shikra** » Sat Nov 03, 2012 10:05 pm

That was a really impressive demo video... really.... wow. It's getting good.

Looking forward to testing mine. Unfortunately my GPS board from my test copter is on top of someone's house ... don't ask ..... :shock:

!!

Polleke · Post by **Polleke** » Sun Nov 04, 2012 12:00 pm

Hi,
I'm a newbee at this so this may be a "stupid" question, so..... :mrgreen:

I want to try this Mahowik setup, especial for the ALT hold improvement part and my question is: do I need to load ALL the files (like the "ino" files) in my Crius SE AIO or just the "config.h" ?

scrat · Post by **scrat** » Sun Nov 04, 2012 1:17 pm

You have compile all files.

Polleke · Post by **Polleke** » Sun Nov 04, 2012 2:31 pm

scrat wrote:You have compile all files.

Thanks scrat,
Is this the right zip-file?

scrat · Post by **scrat** » Sun Nov 04, 2012 2:45 pm

It is not the latest from mahowik. But I think will do.

Mahovik branch is here: http://code.google.com/p/multiwii/sourc ... %2FMahowik

wilco1967 · Post by **wilco1967** » Sun Nov 04, 2012 7:51 pm

Hi....

I tried today dev 1248, with the variable alt hold feature. (with //#define ALTHOLD_FAST_THROTTLE_CHANGE commented out)
It works great on my tricopter :!:

But there are some strange side-effects I noticed.

When in alt holt, one can put the throttle stick to complete minimum and get a nice slow decent. However, having the throttle stick at minimum appearently also disables some part of heading hold / yaw control (not sure what exactly). When throttle is above minumum, the tri is holding the heading ok.... however, when throttle stick at minimum, it suddely starts to slowly yaw by itself.
This might be specific to a tricopter. It is probably an old feature to prevent the tail servo from slowy turning, while idle on the ground.

I'm not a programmer, but I think this hidden feature to disable yaw control should be made inactive if:
- alt hold is active
- motors are armed
- //#define ALTHOLD_FAST_THROTTLE_CHANGE is commented out
- motor RPM above MINTHROTTLE
Perhaps just replacing throttle stick at minumum with RPM at MINTHROTTLE to disable yaw should be sufficient already...

It's no big issue, but just something I noticed today.... it probably showed up more pronounced because my tri tail servo is not yet straight (it crashed yesterday, and I had to mount a new servo arm, which affected the mid position... still have to properly allign and/or set TRI_YAW_MIDDLE).

Another thing (pilot related).
While in alt holt, and min throttle, to make a slow decent, I made the silly mistake to counter the slow rotation, by giving full yaw left for a moment..... :shock:

.... which is disarm

It fell from approx 10 meters up..... luckly it 'landed' absolutely level in the long grass, so no damage done whatsoever.

Perhaps we could add some feature to prevent disarm when in alt-hold, and MOTOR RPM (not throttle stick) is above MINTHROTTLE.... :roll:

just to prevent silly pilot mistakes....

And maybe another idea to prevent pilot error....
When at alt hold, and min throttle (slow decent). If I would disable the alt-hold switch (which is my 'panic' reaction if I get into trouble), it would suddenly drop out of the sky (hasn't happened yet to me, but it's just a matter of time)....
Perhaps we could keep the copter in alt-hold (even though the switch is off), until the throttle-stick is well above minthrottle.

just an idea..... what do you think ?

Thanks again for this great addition....!

Wilco

dramida · Post by **dramida** » Sun Nov 04, 2012 8:05 pm

Good finding Wilco! How do you fell about the rate of climb? I would prefer to have a wider range of climb rates.

wilco1967 · Post by **wilco1967** » Sun Nov 04, 2012 8:14 pm

dramida wrote:Good finding Wilco! How do you fell about the rate of climb? I would prefer to have a wider range of climb rates.

It's rather slow, but that's probably just a parameter change.....

Perhaps something like expo..... Slow at small deflections, and increasingly fast towards full stick (all the way up to full power at full throttle stick) perhaps ?
Now it seems lineair to throttle stick position.... I'm thinking about equiprocentual (expo).
But not to minthrottle at min stick..... it needs to maintain a little more so it remains stable (with min throttle, it just tumbles out of the sky uncontrollably).

It's all a matter of taste I guess..... some defines would make everyone happy I guess.....

I really like this feature

dramida · Post by **dramida** » Sun Nov 04, 2012 8:26 pm

Me too, and it opens the door for auto-take-off and landing. It shoud be nice to have scriptable commands witch could be given from CLI, something like:

Code: Select all

Takeoff 10
Wait 5
Head 320
GoTo 120
While VBAT >14.6 do {crazy stuff :)}
RTH 30
LAND

Crashpilot1000 · Post by **Crashpilot1000** » Sun Nov 04, 2012 8:53 pm

@wilco:
There is always a problem with transitions between different throttlestickmodes. And an automatic fiddeling with the throttlestick as well. It would be interesting to know how many Dji Naza users crashed their copters by turning off "Attitude mode" in flight. I did several things in my derivate (posted above) to circumvent some of the problems to make it LESS dangerous.
I describe my approach of hightcontrol with throttlestick middleposition ("barologic2"):
1. In baromode it is not possible to arm/disarm the copter or turn off the flightregulation completely. That is why starting and landing in this Baromode is not possible or very dangerous (flip on ground, depending of baroacclpf). One exception from the "can not turn of regulation in baromode rule": You have an armswitch defined. When turning off the armswitch in flight it is possible to disarm the copter by putting throttlestick to "zero".
2. Entering the Baromode. On activation of Baromode the althold is engaged immediately but the code waits for the pilot to reach the throttlestick centerzone before it accepts any change of targethight relative to centerposition.
Two ways of exiting the Baromode:
A) (#define Rapid_Exit_Barologic2) Turn OFF the baroswitch IN THE AIR and althold is disengaged immediately. So the current throttlestickposition is the real gas immediately.
B) Turn OFF the baroswitch IN THE AIR and althold KEEPS ON RUNNING UNTIL YOU REACH THE CURRENT VIRTUAL THROTTLE WITH YOUR THROTTLESTICK - then you take over. The "Alt PIDs" must be already tuned for this, otherwise it is potentially dangerous of course. Once tuned it is very comfortable and save way to disengage althold.
(Tuning Alt PID should be done in the old way - Barologic1)

So long
Rob

wilco1967 · Post by **wilco1967** » Mon Nov 05, 2012 6:56 pm

Crashpilot1000 wrote:1. In baromode it is not possible to arm/disarm the copter or turn off the flightregulation completely.

Well.... I still managed to get it to disarm.... fell like a brick..... I'll try again holding it, to make sure I did not mistake this with idle throttle....
BTW: I do not have any armswitch defined.... just deactivate on throttle min&yaw left and also throttle min&roll left (both options enabled).

2. Entering the Baromode. On activation of Baromode the althold is engaged immediately but the code waits for the pilot to reach the throttlestick centerzone before it accepts any change of targethight relative to centerposition.

Ahh.... It felt there was something, but could not figure out yet how exactly it was supposed to behave.... thanks for clearing this up.

Two ways of exiting the Baromode:
A) (#define Rapid_Exit_Barologic2) Turn OFF the baroswitch IN THE AIR and althold is disengaged immediately. So the current throttlestickposition is the real gas immediately.

This is what I'm afraid of.... perfect if the old alt-hold logic is used (where I would never have throttle at absolute minimum), but not so good when //#define ALTHOLD_FAST_THROTTLE_CHANGE is commented (i.e. with slow raise / lower)....

B) Turn OFF the baroswitch IN THE AIR and althold KEEPS ON RUNNING UNTIL YOU REACH THE CURRENT VIRTUAL THROTTLE WITH YOUR THROTTLESTICK - then you take over. The "Alt PIDs" must be already tuned for this, otherwise it is potentially dangerous of course. Once tuned it is very comfortable and save way to disengage althold.

I like the way this sounds....... Is this possible already with the current code, or is this some new idea ?

Thanks for this great code.....
Just don't let my silly ideas interfere.... I really like it already as it is.... just thinking out loudly. :roll:

Crashpilot1000 · Post by **Crashpilot1000** » Mon Nov 05, 2012 11:07 pm

Hi, wilco!
Thank you very much for your kind reply. I referred to my Version posted here: viewtopic.php?f=8&t=2371&start=300#p26094
everything i posted is already done in this version and described in the config.h, just give it a try - but read the safety instructions in the config.h under " TX-related ". In short: just avoid landing in "barologic2" because you risc a flip on the ground. Besides this i found a possible situation i didn't think of while programming: Flying in barologic2 and not having activated Rapid_Exit_Barologic2 and an occuring failsavesituation. In this case the copter will autolevel and stay in althold forever...... A simple reset of one bytevariable in FS code solves the flaw. As said, i didn't think of that situation while coding. I can reload a fixed version, if there is any demand. Otherwise uncomment #define Rapid_Exit_Barologic2 but you will loose the mercedes-benz-style exit of Barologic2. The code has been downloaded over 100 times - happy users (including myself). The flaw has not occured in reality but it is possible, because i didn't think of it

.
So long
Crashpilot // Kraut Rob

dramida · Post by **dramida** » Mon Nov 05, 2012 11:22 pm

Anything new to test and make a video in this area?

Crashpilot1000 · Post by **Crashpilot1000** » Tue Nov 06, 2012 12:29 am

@Dramida: Don't know, have you tried my version (viewtopic.php?f=8&t=2371&start=300#p26094) already?

vpb · Post by **vpb** » Wed Nov 07, 2012 2:41 pm

My Y6 with gps lock & alt hold, r1177 with Mahowik algorithm.
http://www.youtube.com/watch?v=rXxY2wNFI9Q

I've tried AP mode also, height controlling is very slow now, and yes I saw it landed automatically when throtling down a bit.

mahowik · Post by **mahowik** » Thu Nov 08, 2012 7:14 am

Hi guys,

First of all thanks a lot for your ideas and tests. Sorry for delay... unfortunaly I have a lot of work now...

Nice to hear that solutions for alt changing works and you found lots of points to improve! But as I told before that solutions more or less acceptable... So I would like to say that we need controlled vario (vertical velocity) with their own PID controller. I agree with Adrian viewtopic.php?f=8&t=2371&start=290#p26073 and tried to implement PD controlled VARIO to manage altitude (second solution from Adrian's post):

Code: Select all

#if defined(VARIO_ALT_CHANGE)
    
      #define VARIO_P 20
      #define VARIO_D 10
      
      int16_t throttleDiff = rcCommand[THROTTLE]-initialThrottleHold;
      if (abs(throttleDiff) > ALT_HOLD_THROTTLE_NEUTRAL_ZONE) {
        
        int16_t targetVel = throttleDiff - ((rcCommand[THROTTLE] > initialThrottleHold) ? ALT_HOLD_THROTTLE_NEUTRAL_ZONE : -ALT_HOLD_THROTTLE_NEUTRAL_ZONE);
        
        int16_t velError = constrain(targetVel - vel, -300, 300);
        
        static float accScale = 980.665f / acc_1G; // don't worry, it's calculated only one time because it's static init ;)
        
        //rcCommand[THROTTLE] = initialThrottleHold + VARIO_P*velError/20 - VARIO_D*accZ*accScale/40;
        rcCommand[THROTTLE] = initialThrottleHold + constrain((VARIO_P*velError/20 - VARIO_D*accZ*accScale/40), -300, 300);
        
        isAltHoldChanged = 1;
        
        debug[0] = VARIO_P*velError/20;
        debug[1] = VARIO_D*accZ*accScale/40;
        debug[3] = rcCommand[THROTTLE] - initialThrottleHold;
        
      } else {
        
        if (isAltHoldChanged) {
          // much usefull to use BaroAlt instead of EstAlt because it has less delay value when alt hold activated during the vertical movement
          AltHold = BaroAlt;
          errorAltitudeI = 0; 
          isAltHoldChanged = 0;
        }
        
        rcCommand[THROTTLE] = initialThrottleHold+ BaroPID;
      }
      
    #endif

It's tested only in GUI (my copter on vacation now after last damage

) and I'm not shure about values for VARIO_P and VARIO_D, where:
VARIO_P - it's force to get desired vario
VARIO_D - regulate the speed of vario change and prevent oscillations of PID controller (i.e. actually D part - it's already calculated accZ acceleration with coef.), e.g. if VARIO_D=0 it means that speed to get desired vario (by throttle stick) will be max

I'm going to add this code to my branch soon... hope tomorrow... and one more time sorry for delays...

thx-
Alex

vpb · Post by **vpb** » Thu Nov 08, 2012 3:01 pm

Cant wait to test your new improvement, Mahowik! Throttle sticked with vertical velocity! now alt hold is very good in AP mode (ALTHOLD_FAST_THROTTLE_CHANGE commented out) but it's very slow to control height with throttle stick outside deadband.

And can I merge this code to my current r1177?

mahowik · Post by **mahowik** » Thu Nov 08, 2012 6:42 pm

mahowik wrote:I'm going to add this code to my branch soon...

Done:

1) Vario PID controller implementation.

Code: Select all

/* In this mode, throttle stick position gives a desired vario. Regulation is divided into two parts, when throttle stick is inside ALT_HOLD_THROTTLE_NEUTRAL_ZONE, 
   * the current althold regulation is used. When throttle stick is out of deadband, it ascend or descend with a desired vario.
   *
   * but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). 
   * It's slowly increase/decrease altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms).
   */
  #define VARIO_ALT_CHANGE
  #define VARIO_P 20    // it's force to get desired vario
  #define VARIO_D 7     // regulate the speed of vario change and prevent oscillations of PID controller, e.g. if VARIO_D=0 it means that speed to get desired vario (by throttle stick) will be max

Try to play with VARIO_P and VARIO_D...

Max vertical speed limited about +/-3m/s. But I suppose you can get 4-5m/s because calculated vario (vertical velocity) based on accZ with deadband and during integration acceleration to velocity "part of that" will be lost and actually measured 100cm/s equal to real 130..160cm/s. Where algorithm works with the measured values with defined limitation of 3m/s which can be equal to real 4-5m/s...

And some features from my last B[x]-releases:
2) possibility to set predefined initial throttle for AltHold from GUI by setting MID (middle/hover) point of expo throttle.

Code: Select all

/*  Predefined initial throttle for AltHold will be calculated from MID (middle/hover) point of expo throttle from GUI 
   *  (BUT not taken from current throttle value on AltHold activation).
   *  I.e. pls. use GUI to set MID point of throttle expo as initial throttle.
   *  Note: Value specified by define it's additional compensation for battery consumption 
   */
  //#define INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT 50

3) protection from ARM if BARO activated
4) condition to keep "I" parts on throttle less then MINCHECK for acc, gyro if BARO activated. To avoid lost of the stability accumulated by "I" part of PID controller... It's related to stability of heading, acro, stable modes...

Pls. note that is not tested on the fly yet. Only some initial GUI night testing... So keep your finger on the switch...

svn revision: http://code.google.com/p/multiwii/source/detail?r=1257

thx-
Alex

mahowik · Post by **mahowik** » Thu Nov 08, 2012 6:43 pm

vpb wrote:now alt hold is very good in AP mode (ALTHOLD_FAST_THROTTLE_CHANGE commented out) but it's very slow to control height with throttle stick outside deadband.

In that solution vertical speed can be regulated by ALT D pid param. I suppose you used D>50. Try to use 30..40
In my config with ALT D=30 max speed was as desired about 2m/s...
Also to increase max vertical speed you can change delimiter here in MultiWii.ino:

Code: Select all

        // Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +50 cm in 1 second with cycle time about 3-4ms)
        AltHoldCorr+= rcCommand[THROTTLE] - initialThrottleHold;
        if(abs(AltHoldCorr) > 500) {
          AltHold += AltHoldCorr/500;
          AltHoldCorr %= 500;
        }

e.g. 250 to get double speed, i.e. +100 throttle should give about +100cm/s

Code: Select all

        // Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +100 cm in 1 second with cycle time about 3-4ms)
        AltHoldCorr+= rcCommand[THROTTLE] - initialThrottleHold;
        if(abs(AltHoldCorr) > 250) {
          AltHold += AltHoldCorr/250;
          AltHoldCorr %= 250;
        }

vpb wrote:And can I merge this code to my current r1177?

yes, you can compare the sources and add the changes...

thx-
Alex

diyboy · Post by **diyboy** » Sun Nov 11, 2012 2:35 pm

mahowik wrote:
mahowik wrote:I'm going to add this code to my branch soon...

Done:

1) Vario PID controller implementation.
Code: Select all
/* In this mode, throttle stick position gives a desired vario. Regulation is divided into two parts, when throttle stick is inside ALT_HOLD_THROTTLE_NEUTRAL_ZONE, 
   * the current althold regulation is used. When throttle stick is out of deadband, it ascend or descend with a desired vario.
   *
   * but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). 
   * It's slowly increase/decrease altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms).
   */
  #define VARIO_ALT_CHANGE
  #define VARIO_P 20    // it's force to get desired vario
  #define VARIO_D 7     // regulate the speed of vario change and prevent oscillations of PID controller, e.g. if VARIO_D=0 it means that speed to get desired vario (by throttle stick) will be max
Try to play with VARIO_P and VARIO_D...

Max vertical speed limited about +/-3m/s. But I suppose you can get 4-5m/s because calculated vario (vertical velocity) based on accZ with deadband and during integration acceleration to velocity "part of that" will be lost and actually measured 100cm/s equal to real 130..160cm/s. Where algorithm works with the measured values with defined limitation of 3m/s which can be equal to real 4-5m/s...

I also added useful feature: when you activate the althold, initial throttle taken from stick (or calculated from INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT, see below), but actually it's not precised throttle for hovering... after one-two second it's become stabilized by althold PID regulator and BaroPID it's correction for initial throttle... And when we start regulate altitude, initial throttle will be corrected for hovering...
Code: Select all
if (!isAltChanged) {
          // apply real initial throttle hover (it's stabilized when alt hold activated) here before changing the altitude
          initialThrottleHoldOutput = initialThrottleHoldOutput + BaroPID; 
          isAltChanged = 1;
        }
And some features from my last B[x]-releases:
2) possibility to set predefined initial throttle for AltHold from GUI by setting MID (middle/hover) point of expo throttle.
Code: Select all
/*  Predefined initial throttle for AltHold will be calculated from MID (middle/hover) point of expo throttle from GUI 
   *  (BUT not taken from current throttle value on AltHold activation).
   *  I.e. pls. use GUI to set MID point of throttle expo as initial throttle.
   *  Note: Value specified by define it's additional compensation for battery consumption 
   */
  //#define INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT 50  
3) protection from ARM if BARO activated
4) condition to keep "I" parts on throttle less then MINCHECK for acc, gyro if BARO activated. To avoid lost of the stability accumulated by "I" part of PID controller... It's related to stability of heading, acro, stable modes...

Pls. note that is not tested on the fly yet. Only some initial GUI night testing... So keep your finger on the switch...

svn revision: http://code.google.com/p/multiwii/source/detail?r=1257
prepared archive: http://multiwii.googlecode.com/svn/bran ... _r1248.zip

thx-
Alex

Alex,

Thank you! Today I tested the r1248 with my 330frame X4 the BARO working fine.

DIY Boy

mahowik · Post by **mahowik** » Sun Nov 11, 2012 4:57 pm

diyboy wrote:
mahowik wrote:svn revision: http://code.google.com/p/multiwii/source/detail?r=1257
prepared archive: http://multiwii.googlecode.com/svn/bran ... _r1248.zip

Today I tested the r1248 with my 330frame X4 the BARO working fine.

Many thanks! I think you was first

I hope you are talking about testing "prepared archive" or "svn revision" from links above? i.e. not just r1248, because it hasn't latest changes...

Also could you tell more details or probably you have video how VARIO controlled altitude change works?

thx-
Alex

dramida · Post by **dramida** » Sun Nov 11, 2012 5:43 pm

I just tested the latest archive release with vario. It works very good with default pids. The video will post this night. A must se video with gps hold and vario baro mode and autolanding.

mahowik · Post by **mahowik** » Sun Nov 11, 2012 6:22 pm

dramida wrote:I just tested the latest archive release with vario. It works very good with default pids. The video will post this night. A must se video with gps hold and vario baro mode and autolanding.

Wow! Thanks a lot! Nice to hear that it works from first implementation attempt!

And yes, with vario controlled altitude ascend/descend it even doesn't required sonar for autolanding. I.e. talking about "ground effect" related to low altitudes and baro sensor, but with vario pid conroller only ACC used, where baro only corrects ACC errors... cool!

dramida · Post by **dramida** » Sun Nov 11, 2012 9:49 pm

And here is the video in witch the variation of altitude is controlled by throttle stick position, regardless of the mass and power of your copter like this:
Throttle at about 50%= altitude hold
Throttle more than 50%= altitude is increased at a rate proportional to throttle deviation from middle point
Throttle less than 50%= altitude is decreased at a controlled rate proportional to stick deviation from middle position (good for easy descending )

http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

Using the default vario PIDs 20- 7 as suggested by Mahowik.

I think this implementation is very good for novices, its so easy to land as the descent speed is moderated according with throttle position. I even tried an autoland in gps position hold with absolutely no effort. A new failsafe routine shoud be implemented asap.

copterrichie · Post by **copterrichie** » Sun Nov 11, 2012 10:09 pm

Now it is time for waypoints. Nice..

alexia · Post by **alexia** » Mon Nov 12, 2012 12:19 am

copterrichie wrote:Now it is time for waypoints. Nice..

for this there are already apm2

mahowik · Post by **mahowik** » Mon Nov 12, 2012 12:37 am

dramida wrote:And here is the video in witch the variation of altitude is controlled by throttle stick position

Many thanks for nice demo!

Only one note here. Althold point/zone - it's where it's activated, but not center position.

So I will add VARIO code to MultiWii_shared branch and will reduce pids to 15-10 because it seems little bit rapid/sharp for default behaviour...

update: code was added to MultiWii_shared branch

thx-
Alex

Crashpilot1000 · Post by **Crashpilot1000** » Mon Nov 12, 2012 10:35 am

I wonder if your solution will do a decent job on keeping the altitude during movement (real flying).

So long
Kraut Rob

dramida · Post by **dramida** » Mon Nov 12, 2012 1:28 pm

I tested in-flight altitude hold and in does a far better job than previous R1170. For me was good enough the altitude hold behavior during fast flight. I can see it compensate the throttle when leaning also.

Improvement: setting hower throttle to the point where Alt Hold is activated is strange , i prefer 50% throttle. (or at least a define)
Why? because i want to know it keeps its altitude even if it's far above and i can't say if it is climbing or not and after some ups and downs you may be loosing the alt hold spot on your remote.... (aerial photos)

I hope you get my point.
Mihai.

alexia · Post by **alexia** » Mon Nov 12, 2012 1:38 pm

i could only say you felicitation for all you hard working!
baro mode seem to be far better than original code.i am not a coder but i am very happy to see that this great project become more and more famous and better..and that is thanks to you.
i know you take your free time for this and i hope lots of people are reconnaissant(i don t know how to say that in english..lol.french word ).

diyboy · Post by **diyboy** » Mon Nov 12, 2012 2:21 pm

mahowik wrote:
diyboy wrote:
mahowik wrote:svn revision: http://code.google.com/p/multiwii/source/detail?r=1257
prepared archive: http://multiwii.googlecode.com/svn/bran ... _r1248.zip

Today I tested the r1248 with my 330frame X4 the BARO working fine.

Many thanks! I think you was first

I hope you are talking about testing "prepared archive" or "svn revision" from links above? i.e. not just r1248, because it hasn't latest changes...

Also could you tell more details or probably you have video how VARIO controlled altitude change works?

thx-
Alex

Hi Alex
I just tested the prepared archive "http://multiwii.googlecode.com/svn/branches/Mahowik/MultiWii_varioPID_based_on_r1248.zip".

My testing process: (Using the default vario PIDs)
1. Quadx fly to 5M high
2. Throttle at about 50% then active Baro, the QuadX hold on about 5M.
3. Throttle move up to 70%, the quadX goes up
4. Throttle return to 50%, the quadx hold on it's height
5. Throttle move down to 30%, the quadx goes down.
6. Throttle return to 50% the quadx hold on it's height

I also test Baro+GPS hold with about process.

But I haven't taken video.

DIY Boy

vpb · Post by **vpb** » Mon Nov 12, 2012 3:39 pm

Crashpilot1000 wrote:I wonder if your solution will do a decent job on keeping the altitude during movement (real flying).

So long
Kraut Rob

Hi Rob, I use Mahowik alt-hold 100% the time I fly arround, solid height holding, I just use left stick to yaw.

mahowik · Post by **mahowik** » Mon Nov 12, 2012 4:47 pm

Crashpilot1000 wrote:I wonder if your solution will do a decent job on keeping the altitude during movement (real flying).

In my 2.1_B[x] releases I tried to play with with solutions (my own and from alexmos)for throttle angle correction:
(+) it works for fast forward flight
(-) it make a big jumps (3-5m) when you change rapidly the direction of the flight

So we can introduce this feature with define to have a choice...

vpb wrote:I use Mahowik alt-hold 100% the time I fly arround, solid height holding, I just use left stick to yaw.

Actually the issue with reducing altitude exist when you start to move with inclination about >20degrees, but it's can be critical only on low altitudes...

thx-
Alex

Crashpilot1000 · Post by **Crashpilot1000** » Mon Nov 12, 2012 4:54 pm

@vpb @mahowik

Thank you for the info!
I guess i will have to test it myself

So long
Kraut Rob

mahowik · Post by **mahowik** » Mon Nov 12, 2012 6:11 pm

dramida wrote:I tested in-flight altitude hold and in does a far better job than previous R1170. For me was good enough the altitude hold behavior during fast flight. I can see it compensate the throttle when leaning also.

Improvement: setting hower throttle to the point where Alt Hold is activated is strange , i prefer 50% throttle. (or at least a define)
Why? because i want to know it keeps its altitude even if it's far above and i can't say if it is climbing or not and after some ups and downs you may be loosing the alt hold spot on your remote.... (aerial photos)

In first attempt the main goal was to check VARIO pid controller works or not. And of course now we can improve and add some features there

Let's discuss and sort out possible solutions, because i have too much points in my mind on this

Current implementation:
(+) when you activate the althold it will keep altitude immediately, i.e. it can be used to safe your copter during the activation
(+) initial throttle, i.e. throttle for hovering is taken as current throttle value on althold activation
(-) center is not 50% throttle, but if you need to have this in center, you can just reactivate the althold. I.e. just set the throttle stick to desired position and turn off/on the switch of althold quickly.
(-) as for now, predefined "throttle expo curve" also used for setting desired rate/vario and it's good if you activate the althold at the MID expo point (it's set in GUI and in right tuned config it equals to hover point, i.e. value of the initial throttle for hovering)
BUT if althold activated in point of throttle which in diff with MID expo point, it will be not usefull for vario regulation, e.g. MID_expo=40% and althold_activation=60%, it means ascending will be too fast, descending will be too low, because you are not in the center of expo curve...

Desired implementation:
1) center is 50% throttle
2) max rate/vario set with define
3) to have a beeps/light signaling during ascend/descend altitude OR best choice to have feedback/telemetry from flight controller to pilot (i'm experimenting with frsky downlink telemetry to have beeps on my TX)
4) need to predefine own expo curve with 50% center OR probably we don't need expo for rate/vario stick controlling at all, if all range about +/-3..5m/s?
5) (not obligatory but nice to have) safe function when althold deactivated... e.g. when you turn off the althold, throttle will be changed smoothly (in 2-3 seconds) from last althold's throttle to current throttle value to have time to react and adapt throttle after althold deactivation...

(+) proportional stick movement to have the same ascend/descend rate
(-) you need to tune initial throttle, i.e. throttle for hovering, because with this approach you should have possibility to activate althold with any thottle stick position. E.g. with #define INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT (Predefined initial throttle for AltHold will be calculated from MID (middle/hover) point of expo throttle from GUI).
But probable it has more advantage than disadvantage

(-) visible disadvantage - it will required to move stick to center after activation

Pls. provide you thoughts on this. I.e. we need to collect requirements before the next implementation step

thx-
Alex

scrat · Post by **scrat** » Mon Nov 12, 2012 8:39 pm

Hi guys.

If I download mahowik's zip file: http://code.google.com/p/multiwii/sourc ... _r1248.zip

Is it ok to use it or it's not good. Then which MultiWii Conf to use with it?

Thx!