Altitude Hold improvement solution

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

Re: Altitude Hold improvement solution

Postby cswiger » Tue Sep 18, 2012 8:43 pm

shikra wrote:
cswiger wrote:just tried Mahowik's IMU.ino and see noticible improvement - just a quick test.
I could not get the crashpilot1000 sketch to work - got lots of i2c errors after setting my config.h defines. builds and loads but those bus errors made me back out.


On your GUI, there is no baro data - suggest you look at baro config - is correct one activated, and on the right address


Yep - that's it, special change for QUADRINO_ZOOM to use the MS561101BA instead of the BMP085 in def.h.
Sorry for the un-helpful noise :(
cswiger
 
Posts: 12
Joined: Wed Jun 20, 2012 11:43 pm

Re: Altitude Hold improvement solution

Postby LenzGr » Wed Sep 19, 2012 9:44 am

I did some more testing with mahowik's code today, tweaking the PID values. Getting there, but my current config reacts very aggressively against changes (you can hear the motors revving up and down quickly). There is a noticeable effect, but I'm still struggling to find the optimal values (it still goes up and down a lot - might be the Baro values deviate too much?). Unfortunately I currently don't have a spare serial port to log the baro data.
User avatar
LenzGr
 
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany

Re: Altitude Hold improvement solution

Postby shikra » Wed Sep 19, 2012 10:31 am

No worries.
cswiger wrote:
shikra wrote:
cswiger wrote:just tried Mahowik's IMU.ino and see noticible improvement - just a quick test.
I could not get the crashpilot1000 sketch to work - got lots of i2c errors after setting my config.h defines. builds and loads but those bus errors made me back out.


On your GUI, there is no baro data - suggest you look at baro config - is correct one activated, and on the right address


Yep - that's it, special change for QUADRINO_ZOOM to use the MS561101BA instead of the BMP085 in def.h.
Sorry for the un-helpful noise :(
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Postby shikra » Wed Sep 19, 2012 10:38 am

Here is a vid from this mornings test. I made a couple of changes wanted to test this morning because the latest releases need a couple of tweaks to get the LEDring working + added extra indicator for horizon.

Only a very small bit of wind early this morning. Just enough to push it around a little.
Check out the results. Its pretty cool to leave in pos hold whilst getting out camera to film! Details at beginning of clip.


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

Oh and tried the drop test too... up high let drop down and flick the PH switch - Works well. Excellent.


r1122 is bundled here with ledring changes for anyone that wants to try out...
http://www.flypix.co.uk/shikra/ftp/
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Postby LenzGr » Wed Sep 19, 2012 10:57 am

shikra wrote:http://www.youtube.com/watch?v=PwntTHftI6Q

"This video contains content from EMI, who has blocked it in your country on copyright grounds"

:(
User avatar
LenzGr
 
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany

Re: Altitude Hold improvement solution

Postby shikra » Wed Sep 19, 2012 11:32 am

Ah nits - sorry - I had mail to say it was Ok, but it changed its mind! Now blocked in 207 countries...

Youtube is replacing soundtrack. Should be good very shortly.

EDIT - soundtrack changed. should be viewable by all.


Well done mahowik et all.....
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Postby LenzGr » Wed Sep 19, 2012 12:08 pm

shikra wrote:EDIT - soundtrack changed. should be viewable by all.

Well done mahowik et all.....

Thanks, now I was able to watch it. Looks good, I haven't reached that level of stability with mahowik's code yet. I will try the ALT PID values you listed at the beginning of the video. Is the I term ("010") a "0.10" or "0.01"? I am currently using "0.01", but lower P and D values.

Also, does this Alt hold setup feel "smooth", or do you observe abrupt changes in motor speed in order to maintain altitude?
User avatar
LenzGr
 
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany

Re: Altitude Hold improvement solution

Postby shikra » Wed Sep 19, 2012 12:33 pm

It's pretty smooth. Changes don't seem at all big or abrupt in hover. It will when needed - i.e. a big drop and flick the hold switch

The alt pids are roughly what mahowik suggests. In GUI terms its 05.0 / 0.010 / 050
But note these are starting ones - I haven't changed them yet.


The alt hold is very good. The GPS wanders around a little - most of time +/-1m in steady conditions. Pretty much as see in the vid. The second part shows the wandering - but note that very little of it is altitude. With tuning it could be made better, but I think for GPS 8 sats I think its good.

I haven't flown a naza or have any other reference, but I'm impressed.
I think mahowik just made it up there with the other multiwii gods :)
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Postby mahowik » Thu Sep 20, 2012 2:34 am

LenzGr wrote:I did some more testing with mahowik's code today, tweaking the PID values. Getting there, but my current config reacts very aggressively against changes (you can hear the motors revving up and down quickly). There is a noticeable effect, but I'm still struggling to find the optimal values (it still goes up and down a lot - might be the Baro values deviate too much?). Unfortunately I currently don't have a spare serial port to log the baro data.

Try to check debug (acc, velocity) values as described some pages ago in two posts... i suppose you have a lot vibrations on your board... which acc and baro?
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby timecop » Thu Sep 20, 2012 2:49 am

I enabled the new mahowik althold in baseflight since r220.
Those with freeflight/afro32 hardware can try it out by grabbing latest build. All the parameters are tunable:
acc_lpf_for_velocity = 10
baro_tab_size = 21
baro_noise_lpf = 0.600
baro_cf = 0.985
Probably start with some fixed looptime as well, 3000 seems to be a good choice.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Altitude Hold improvement solution

Postby LenzGr » Thu Sep 20, 2012 8:16 am

mahowik wrote:Try to check debug (acc, velocity) values as described some pages ago in two posts... i suppose you have a lot vibrations on your board... which acc and baro?

Thanks, I'll look into that. Yes, vibration might be an issue, but wouldn't that primarly affect the accelerometers on the x/y axis?. I'm flying Flyduino MicroWii (MPU-6050 and MS5611 Baro) on a fiberglass frame ("Black Crow" from quadframe.com):
Image
User avatar
LenzGr
 
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany

Re: Altitude Hold improvement solution

Postby Crashpilot1000 » Thu Sep 20, 2012 2:57 pm

Hi!

I did a slight improvement of my interpretation of mahowiks great work.
Just alter my version posted here: viewtopic.php?f=8&t=2371&start=110#p22860
to improve the hightchange with the throttlestick.

*******************************************************************************************************************************
EDIT: This is experimental, with low acc "I" the performance of althold can be worsened
*******************************************************************************************************************************


Find this in the mainprogram (MultiWii_2_1_NewBaroPIDVario3) at line 962 and delete it:
Code: Select all
  #if BARO
    Baro_update();                                                                                               // Do Baro every time!
    getEstimatedAltitude();
    if (currentTime >= ThrTime){                                                                                 //  Get ThrottleRate in Ticks/sec Upmovement=+ Polling at 10Hz
     ThrTime = currentTime+100000;
     ThrottleRate = (rcCommand[THROTTLE]-LastThrottle)*10;
     if (abs(ThrottleRate) < 150) ThrottleRate = 0;
     LastThrottle=rcCommand[THROTTLE];}

    if (rcOptions[BOXBARO]){           // New Logic: When User exceeds neutral zone and stops fiddeling with throttle, then after 1 second a new Althold is defined
      if (abs(rcCommand[THROTTLE] - initialThrottleHold)<ALT_HOLD_THROTTLE_NEUTRAL_ZONE && HightChange==0){
       rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
       rcCommand[THROTTLE] = constrain(rcCommand[THROTTLE],MINTHROTTLE+1,MAXTHROTTLE-50);}
      else {
       HightChange=1;
       if (ThrottleRate==0 && AltHoldBlindTimer==0) AltHoldBlindTimer = currentTime+AltHoldBlindTime;}
      if (ThrottleRate !=0) AltHoldBlindTimer = 0;
      if (currentTime >= AltHoldBlindTimer && AltHoldBlindTimer !=0) f.BARO_MODE = 0;                            // Set new ref hight
     }
  #endif


Replace with this:

Code: Select all
  #if BARO
    Baro_update();                                                                                               // Do Baro every time!
    getEstimatedAltitude();
    if (rcOptions[BOXBARO])
     {
      int16_t ActualThr=rcCommand[THROTTLE];
      if (currentTime >= ThrTime){                                                                 // 10Hz Loop Get ThrottleRate in 10Ticks/sec Upmovement=+
      ThrTime = currentTime+100000;
      ThrottleRate = (ActualThr-LastThrottle);
      if (abs(ThrottleRate) < 15) ThrottleRate = 0;
       else AltHoldBlindTimer=0;
      if (abs(ActualThr-initialThrottleHold)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) HightChange=1;
      LastThrottle=ActualThr;}

      if (HightChange==0) rcCommand[THROTTLE] = initialThrottleHold+BaroPID;
       else{
        rcCommand[THROTTLE] = ActualThr+constrain(BaroPID,-ALT_HOLD_THROTTLE_NEUTRAL_ZONE,ALT_HOLD_THROTTLE_NEUTRAL_ZONE);
        if (ThrottleRate==0 && AltHoldBlindTimer==0) AltHoldBlindTimer = currentTime+AltHoldBlindTime;}
      if (currentTime >= AltHoldBlindTimer && AltHoldBlindTimer !=0) f.BARO_MODE = 0;
      rcCommand[THROTTLE] = constrain(rcCommand[THROTTLE],MINTHROTTLE+1,MAXTHROTTLE-50);
     }
  #endif


I tested it with config.h:
#define ALT_HOLD_THROTTLE_NEUTRAL_ZONE 20
#define AltHoldBlindTime 500000

During hightchange "Baropid" is constantly done with the last althold in mind in the range of ALT_HOLD_THROTTLE_NEUTRAL_ZONE. This smoothes out the transition with the throttlestick.

@Hamburger: Thank you for the config - hint !!
And btw i did a "SUPPRESS_BARO_ALTHOLD" mod - this saves over 900 Bytes.
My approach of moving average with "while" loop is not so nice like marbalons moving average but it saves 25 Bytes (tried both). Adding 8 bytes in a loop and 5 longwords in a loop is done very quickly.
BTW: My getEstimatedAltitude has a good timebase of 30ms. This is done by synchronizing with the baroreadout (newbaroalt). Both baro read outs (MS&BMP) are optimized to put out a new value every 30ms. Acc calculations are done on every runtime and drift is compensated every 30ms.

So long

Crashpilot1000
User avatar
Crashpilot1000
 
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Altitude Hold improvement solution

Postby dramida » Fri Sep 21, 2012 8:22 pm

I flew R1122 from shared trunk with Manhowik Alt Hold routine and it works like a charm on Crius AIO Mega Board. Well done!
Note to perfection: In fast forward flight it tends to slowly loose altitude, about 1 meter. When it stops holding position, the altitude is regained.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby wilco1967 » Sat Sep 22, 2012 7:24 am

That might be airspeed related..... the wind from forward flight may influence your baro reading, showing slightly wrong alt readings.

i noticed the same, and it also dropped 2..3 meter in fast forward flight.

However, I have the FrSky telemetry from multiwii installed, and the reported altitude (from MultiWii) stays the same, even though the copter is actually dropping slightly..... As far as MultiWii is aware from it's sensors, it is maintaining exact altitude....

So I don't think it's the software's fault, but just wind effects on the baro sensor.
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby dramida » Sat Sep 22, 2012 7:34 am

I agree with this explanation.
Also interesting telemetry radio setup you have, would you give more details about connecting MWC to frsky telemetry? (software config related)
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby dramida » Sat Sep 22, 2012 7:59 am

Before moving forward to controlled ascend/ descend mode, we need to document the new alt hold functionality. Here is the official Wiki page for MWC:

http://www.multiwii.com/wiki/index.php? ... l:AllPages

It would be nice to have explained how to setup, how it works etc...
Below i sum up a few guides from the creator of the new AH algorithm.
/Mihai

dramida wrote:I sum up all the important things you wrote about alt-hold in this spammed topic:
- debug[0] - z axis acceleration +/- 2
- debug[1] - baro velocity
- debug[2] - velocity after CF (velocity from acc corrected by baro velocity through the CF) -5..15
- debug[3] - sum of the P+I+D


- cycle time should be about 3-4ms... otherwise you should re-tune LPFs and CF
- pls. make all test on altitude >=2m to avoid ground effect (on less altitudes measurement baro can give -1..2m and become very unstable)

- wait 10-15 sec after power on OR after ACC calibration... all LPFs, velocity integrator and CF need to be syncronized

- for mpu6050 pls turn on 42hz LPF (#define MPU6050_LPF_42HZ)...


PIDs tuning:
1) make shure that velocity calculation works... set P and I to zero (only D=30) and try to activate alt hold when copter goes up (with velocity 1..2m/s). It's should try to stop copter immediatelly (but possible to drift because P and I are zero)! If no effect, something wrong at all and next steps doesn't make sense...
If ok, play with D to find "best stop effect"... probably D=20 it's enough...
2) keep "I" about 0.01... It's should be enough according to baro precision to avoid slow oscillations produced by "I" part
3) set P to 1.0 and try to increase before it start oscillate, then reduce for 20-30%

I tried PIDs 5.0-0.030-30


All necessary changes for new baro+acc alt hold only in one file IMU.ino
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby Magnetron » Sat Sep 22, 2012 8:49 am

Mahowik, your code works very well with ms5611with pid p:1,i:0.01,d:30.
I think that we must implement a bumpless filter due to fast respose when the alt hold function is activated.
I send you a pm please read it and we can do more on multiwii...
Magnetron
 
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Altitude Hold improvement solution

Postby timecop » Sat Sep 22, 2012 8:54 am

Why dont you post your ideas here, what's the point of discussing it in pm?
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Altitude Hold improvement solution

Postby Magnetron » Sat Sep 22, 2012 9:31 am

My idea is out of topic here. My idea is to obtain global acc x and y vector based on mahowik baro idea but only obtained by acc and gyro also. Acc x and y global vector can be used in level mode fly or in a new position hold routine.
Magnetron
 
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Altitude Hold improvement solution

Postby timecop » Sat Sep 22, 2012 9:34 am

Let's start a new topic about that then, because it sounds like something interesting and something that can be easily implemented on proper 32bit platform.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Altitude Hold improvement solution

Postby dramida » Sat Sep 22, 2012 12:00 pm

Magnetron wrote:My idea is out of topic here. My idea is to obtain global acc x and y vector based on mahowik baro idea but only obtained by acc and gyro also. Acc x and y global vector can be used in level mode fly or in a new position hold routine.

+1 for using X Y acceleration in position Hold (Naza does this already) but please start another topic about that. I think documenting the new Alt Hold feature and evolving into controlled climb or descend or even autolanding is the next step to go for Baro-Acc routine.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby Magnetron » Sat Sep 22, 2012 1:49 pm

Magnetron
 
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Altitude Hold improvement solution

Postby Magnetron » Sat Sep 22, 2012 1:51 pm

dramida wrote:
Magnetron wrote:My idea is out of topic here. My idea is to obtain global acc x and y vector based on mahowik baro idea but only obtained by acc and gyro also. Acc x and y global vector can be used in level mode fly or in a new position hold routine.

+1 for using X Y acceleration in position Hold (Naza does this already) but please start another topic about that. I think documenting the new Alt Hold feature and evolving into controlled climb or descend or even autolanding is the next step to go for Baro-Acc routine.

Yes, but in autolanding we can use sonar sensor to do a high precision autolanding... ;) next step... ah... some info on sonar routine?
Magnetron
 
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Altitude Hold improvement solution

Postby mahowik » Sat Sep 22, 2012 6:03 pm

LenzGr wrote:
mahowik wrote:Try to check debug (acc, velocity) values as described some pages ago in two posts... i suppose you have a lot vibrations on your board... which acc and baro?

Thanks, I'll look into that. Yes, vibration might be an issue, but wouldn't that primarly affect the accelerometers on the x/y axis?. I'm flying Flyduino MicroWii (MPU-6050 and MS5611 Baro) on a fiberglass frame


Yes, X and Y axis also sensitive for vibrations BUT we are using strong LPF (with ACC_LPF_FACTOR = 100) in IMU to reduce vibro effect (it's prepared for Gyro/Acc complementary filter with hight gyro factor GYR_CMPF_FACTOR) BUT we can't use so hight factor for accZ calculations because we loose necessary reaction and performance of accZ for alt hold...

So at first check calculated accZ (debug0) in GUI when motors OFF and then when motors ON with 50-60% throttle... accZ still swim near zero( +/-5... check in GUI with 10x zoom)... if you see a lot of vibrations on debug0 try to increase ACC_LPF_FOR_VELOCITY to 15 (max to 20)... hope it helps...

update: I'm also using the following internal LPF for MPU6050. As I remember it's related not only to gyro but also ACC bandwidth!
Code: Select all
#define MPU6050_LPF_42HZ


thx-
Alex
Last edited by mahowik on Sat Sep 22, 2012 7:34 pm, edited 2 times in total.
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby wilco1967 » Sat Sep 22, 2012 6:10 pm

dramida wrote:I agree with this explanation.
Also interesting telemetry radio setup you have, would you give more details about connecting MWC to frsky telemetry? (software config related)


See this thread..... http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929

Hope that also makes it into the main trunk... <Hint>
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby mahowik » Sat Sep 22, 2012 6:13 pm

dramida wrote:I flew R1122 from shared trunk with Manhowik Alt Hold routine and it works like a charm on Crius AIO Mega Board. Well done!
Note to perfection: In fast forward flight it tends to slowly loose altitude, about 1 meter. When it stops holding position, the altitude is regained.


wilco1967 wrote:That might be airspeed related..... the wind from forward flight may influence your baro reading, showing slightly wrong alt readings.

i noticed the same, and it also dropped 2..3 meter in fast forward flight.

However, I have the FrSky telemetry from multiwii installed, and the reported altitude (from MultiWii) stays the same, even though the copter is actually dropping slightly..... As far as MultiWii is aware from it's sensors, it is maintaining exact altitude....

So I don't think it's the software's fault, but just wind effects on the baro sensor.


Thanks a lot for tests!

Yes, I have found out the same... checked with FrSky telemetry...
So as i mentioned before I'm going to integrate "throttle angle correction" from alexmos code base... where Alt hold "I" will be moved to #define (because it doesn't required precise tuning) and used for "throttle angle correction"...
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby mahowik » Sat Sep 22, 2012 6:46 pm

dramida wrote:There are some issues with an initial jump proportional with D term after witch the copter comes down to initial AH level and it keeps that level.

Also reproduced this issue, when copter goes up/down and alt hold activated... I suppose it's related to delay in calculated EstAlt... So to fix that you can just try to replace:
Code: Select all
AltHold = EstAlt;

to:
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;

in MultiWii.ino
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby mahowik » Sat Sep 22, 2012 7:16 pm

dramida wrote:and evolving into controlled climb or descend or even autolanding is the next step to go for Baro-Acc routine.

If you mean auto switch to specified alttitude it's already possible with new alt hold ;)
I have already implemented and tested (~ 2 weeks ago) "Alt to RTH" feature... Works great and get specified altitude without overshooting!

It can be used e.g. as fail safe feature to reach home above trees etc...
Code: Select all
// set altitude to RTH. If Alt-hold activated during the RTH (or RTH during Alt-hold) it will keep specified altitude.
   #define ALT_TO_RTH 1000 // in cm... = 10m

Full sketch posted here http://forum.rcdesign.ru/blogs/83206/blog15204.html
It' was not possible with default 2.1 alt hold and during the activation of alt hold with specified altitude value, it's overshoot necessary altitude ~5..10m and then slowly goes to specified altitude... OR never gets it during the wind... now it's not a problem ;)

Also today i have added one more define for altitude after RTH, i.e. when copter reached to home position (it's not tested yet).

Code: Select all
// set altitude after RTH, i.e. when copter reached to home position.
   // DON'T USE VALUE LESS THEN 200 (2m) BECAUSE BARO ON ALTITUDES <2m WORKS UNSTABLE!!!
   // Correct auto landing will be possible with sonar... soon ;)
   #define ALT_TO_RTH_FINISH 250 // in cm... = 2.5m


Someone interesting with this? Does it make sense to create new thread for this?

thx-
Alex
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby dramida » Sat Sep 22, 2012 8:30 pm

I want to try this feature as soon as it is beta. If the descend speed is slow enough on last leg, it could do a decent controlled crash landing :) An bigger issue will be horizontal speed relative to ground. Thanks.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby Deet » Sun Sep 23, 2012 12:38 am

getting back to the revised alt hold without RTH....

Is this likely to be added to the next release?

If not is it at a point where it can be easily added as a patch by those of use a little less knowledgable
Deet
 
Posts: 129
Joined: Sun Jul 08, 2012 1:54 am

Re: Altitude Hold improvement solution

Postby nhadrian » Sun Sep 23, 2012 9:28 am

mahowik wrote:
dramida wrote:and evolving into controlled climb or descend or even autolanding is the next step to go for Baro-Acc routine.

If you mean auto switch to specified alttitude it's already possible with new alt hold ;)
I have already implemented and tested (~ 2 weeks ago) "Alt to RTH" feature... Works great and get specified altitude without overshooting!

It can be used e.g. as fail safe feature to reach home above trees etc...
Code: Select all
// set altitude to RTH. If Alt-hold activated during the RTH (or RTH during Alt-hold) it will keep specified altitude.
   #define ALT_TO_RTH 1000 // in cm... = 10m

Full sketch posted here http://forum.rcdesign.ru/blogs/83206/blog15204.html
It' was not possible with default 2.1 alt hold and during the activation of alt hold with specified altitude value, it's overshoot necessary altitude ~5..10m and then slowly goes to specified altitude... OR never gets it during the wind... now it's not a problem ;)

Also today i have added one more define for altitude after RTH, i.e. when copter reached to home position (it's not tested yet).

Code: Select all
// set altitude after RTH, i.e. when copter reached to home position.
   // DON'T USE VALUE LESS THEN 200 (2m) BECAUSE BARO ON ALTITUDES <2m WORKS UNSTABLE!!!
   // Correct auto landing will be possible with sonar... soon ;)
   #define ALT_TO_RTH_FINISH 250 // in cm... = 2.5m


Someone interesting with this? Does it make sense to create new thread for this?

thx-
Alex



Hi,

of course it makes sense!!! But, my oppinion is that for this feature, also a climb/descend rate should be defined, to avoid too fast ascending or descending during reaching the target altitude.
Looking forward for this development!

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby mahowik » Mon Sep 24, 2012 3:35 am

dramida wrote:If the descend speed is slow enough on last leg, it could do a decent controlled crash landing :) An bigger issue will be horizontal speed relative to ground. Thanks.

Autolanding will be possible only with sonar I think, because on altitudes less then 2m baro values become very unstable and could not be handled correctly... Probably if we get exact logging of baro raw data during the manual landing of good pilot, it will be possible to get some function or rules how to map baro values to real altitude, but I think it's depends so much on each copter config... also some changes in weather during the flight can produce error, e.g. +/-1m and ground is already not ground :)

nhadrian wrote:But, my oppinion is that for this feature, also a climb/descend rate should be defined, to avoid too fast ascending or descending during reaching the target altitude.


Actually vertical velocity can be regulated by PIDs. Where P is force of magnet (with constraint) to destination point and D is power which is proportional to the inverted vertical velocity, i.e. more velocity - more brake by D part.
I tested RTH yesterday (on short distance 10-20m to RTH point) on my quadrX (about 1kg) with PIDs 5.2-0.020-30. It has vertical velocity about 1-2m/s and reached destination (necessary altitude) almost without overshooting as on ascending or descending during reaching the target altitude...

I'm going to post sketch/code soon...

thx-
Alex
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby Termic1 » Mon Sep 24, 2012 7:32 pm

mahowik wrote:I'm going to post sketch/code soon...


can't wait for this new ALT TO RTH function!

thx Alex!
Termic1
 
Posts: 40
Joined: Tue Aug 21, 2012 11:14 am

Re: Altitude Hold improvement solution

Postby wilco1967 » Mon Sep 24, 2012 7:45 pm

mahowik wrote:Autolanding will be possible only with sonar I think, because on altitudes less then 2m baro values become very unstable and could not be handled correctly... Probably if we get exact logging of baro raw data during the manual landing of good pilot, it will be possible to get some function or rules how to map baro values to real altitude, but I think it's depends so much on each copter config... also some changes in weather during the flight can produce error, e.g. +/-1m and ground is already not ground :)


could you perhaps use averaged motor speed setpoint during the decent by baro (from 10 meters down to 2 meter) to clamp the motor speed during the last 2 meters or so ?
So no active motor speed control based on baro any more for the last 2 meters, but basically a fixed speed that has proven to cause a slow decent.
It would not be very precize, but it would put down the copter relatively gentle....

the same could also be achieved with a fixed speed setpoint (pre-configured), but that is no good for people (like me) who change battery / weight a lot....
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby mahowik » Mon Sep 24, 2012 9:56 pm

Termic1 wrote:can't wait for this new ALT TO RTH function!


ALT_TO_RTH already available in MultiWii_2_1_b1. You can download it here http://forum.rcdesign.ru/blogs/83206/blog15204.html

sketch with ALT_TO_RTH_FINISH will be posted soon in MultiWii_2_1_b2

wilco1967 wrote:
mahowik wrote:Autolanding will be possible only with sonar I think, because on altitudes less then 2m baro values become very unstable and could not be handled correctly... Probably if we get exact logging of baro raw data during the manual landing of good pilot, it will be possible to get some function or rules how to map baro values to real altitude, but I think it's depends so much on each copter config... also some changes in weather during the flight can produce error, e.g. +/-1m and ground is already not ground :)


could you perhaps use averaged motor speed setpoint during the decent by baro (from 10 meters down to 2 meter) to clamp the motor speed during the last 2 meters or so ?
So no active motor speed control based on baro any more for the last 2 meters, but basically a fixed speed that has proven to cause a slow decent.
It would not be very precize, but it would put down the copter relatively gentle....

the same could also be achieved with a fixed speed setpoint (pre-configured), but that is no good for people (like me) who change battery / weight a lot....


I got your idea, but I suppose to control speed as constant, we need one more (or another) PID controller and again 100500 flight tests :)

thx-
Alex
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby Termic1 » Wed Sep 26, 2012 12:47 pm

mahowik wrote:ALT_TO_RTH already available in MultiWii_2_1_b1. You can download it here http://forum.rcdesign.ru/blogs/83206/blog15204.html
sketch with ALT_TO_RTH_FINISH will be posted soon in MultiWii_2_1_b2
.....
thx-
Alex


Alex, that's great! Now I'm just testing dev 1129 with new Alt Hold routine that seems to work very well! If you catch the quad in flight and you try to push it down or up you can see the motors immediately reacting to the change. Very good job! Need some more PID tuning (now 2,5 - 0,015 - 50) in calm weather (today a lot of wind) but I think that new Alt Hold will perform pretty well. As soon as the wind stops I'll try ALT-TO-RTH !

Thank you!

Luciano
Termic1
 
Posts: 40
Joined: Tue Aug 21, 2012 11:14 am

Re: Altitude Hold improvement solution

Postby dramida » Wed Sep 26, 2012 10:05 pm

mahowik wrote:
Termic1 wrote:can't wait for this new ALT TO RTH function!


ALT_TO_RTH already available in MultiWii_2_1_b1. You can download it here http://forum.rcdesign.ru/blogs/83206/blog15204.html

sketch with ALT_TO_RTH_FINISH will be posted soon in MultiWii_2_1_b2

wilco1967 wrote:
mahowik wrote:Autolanding will be possible only with sonar I think, because on altitudes less then 2m baro values become very unstable and could not be handled correctly... Probably if we get exact logging of baro raw data during the manual landing of good pilot, it will be possible to get some function or rules how to map baro values to real altitude, but I think it's depends so much on each copter config... also some changes in weather during the flight can produce error, e.g. +/-1m and ground is already not ground :)


could you perhaps use averaged motor speed setpoint during the decent by baro (from 10 meters down to 2 meter) to clamp the motor speed during the last 2 meters or so ?
So no active motor speed control based on baro any more for the last 2 meters, but basically a fixed speed that has proven to cause a slow decent.
It would not be very precize, but it would put down the copter relatively gentle....

the same could also be achieved with a fixed speed setpoint (pre-configured), but that is no good for people (like me) who change battery / weight a lot....


I got your idea, but I suppose to control speed as constant, we need one more (or another) PID controller and again 100500 flight tests :)

thx-
Alex

Would be preety nice that in Alt Hold, when throttle raised, we have a controlled ascend and when throttle lowered, a controlled descend (verry useful )

I would not go with sonar for autolanding at this moment because a few things:

1- we can't control the rate of descend/ascend with the sonar.
2- sonar would be useless for autolanding if the copter is descending like hell with 5-10m/s.
3- sonar is useful only on low altitudes (below 8m)
4- we need another hardware- sonar

So a first step is a controlled ascend/descend mode based on the new Alt Hold routine. We can control the ascend/descent rate with baro only at any altitude.
Of corse, another PID controller for Z velocity is required but it worth the effort of some new # define P_climb etc...I am ready to be the tester for this mod.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby Imen » Thu Sep 27, 2012 5:54 pm

Dear all, newbie here... I test mahowik code ms5611_IMU.ino with CRIUS SE v1.0 board, hey this really work on BMP085 sensor
my set was 5.0 0.01 30. Is there any suggest PID tune for better AH, thanks
This my video http://www.youtube.com/watch?v=xLcWT_O1nyg
Imen
 
Posts: 20
Joined: Thu Sep 27, 2012 5:11 pm

Re: Altitude Hold improvement solution

Postby mahowik » Thu Sep 27, 2012 6:21 pm

Imen wrote:Dear all, newbie here... I test mahowik code ms5611_IMU.ino with CRIUS SE v1.0 board, hey this really work on BMP085 sensor
my set was 5.0 0.01 30. Is there any suggest PID tune for better AH, thanks
This my video http://www.youtube.com/watch?v=xLcWT_O1nyg

Thanks a lot!
For bmp085 it's make sense to reduce P... the idea is: more precised baro => more P value (5..6 for ms5611 and 2..3 for bmp085)! In the future with sonar i think it make sense to use P=7..8 ...

So just try to 3.0-0.01-30 for your config...

thx-
Alex
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby charbot » Fri Sep 28, 2012 1:13 am

hey guys,
I havent been following along on the alt hold progress so forgive me if Im missing something obvious in config or something...

Ive tried the last two new dev versions- 1129 & 1143, and everything is great except for alt hold (I have a bmp085, PID= default @ 1.6/ .015/ 7)- Starting at a stable hover, when I toggle baro, "on" my quad practically blasts off, vertically accelerating with all its got. Also (Not sure if this is important but ... ) since 2.1 ACC z axis reads 200 when the quad is static (using a nunchuk and motion + )
Is this a bug or does alt hold function differently now?
charbot
 
Posts: 34
Joined: Wed May 23, 2012 8:37 pm

Re: Altitude Hold improvement solution

Postby mahowik » Fri Sep 28, 2012 5:00 am

charbot wrote:hey guys,
I havent been following along on the alt hold progress so forgive me if Im missing something obvious in config or something...

Ive tried the last two new dev versions- 1129 & 1143, and everything is great except for alt hold (I have a bmp085, PID= default @ 1.6/ .015/ 7)- Starting at a stable hover, when I toggle baro, "on" my quad practically blasts off, vertically accelerating with all its got. Also (Not sure if this is important but ... ) since 2.1 ACC z axis reads 200 when the quad is static (using a nunchuk and motion + )
Is this a bug or does alt hold function differently now?


Sorry but as I remember nunchuk and motion+ are too noisy sensors for this alt hold solution... First check it in GUI as described some pages ago and also try special IMU_bmp085.ino...
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby mahowik » Fri Sep 28, 2012 5:59 am

Hi guys,

Here is MultiWii_2_1_b2 ;)

1) controlled ascend/descend mode based on the new Alt Hold routine. It's slowly increase/decrease AltHold altitude proportional to stick movement from point where AltHold activated ( +100 throttle gives ~ +50 cm in 1 second with cycle time about 3-4ms): solution from alexmos

2) /* 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 40

3) /* Correct throttle according to Z-axis inclination
Default is 100. Don't set above 200 */
//#define THROTTLE_ANGLE_CORRECTION 200

4) // set altitude to RTH. If Alt-hold activated during the RTH (or RTH during Alt-hold) it will keep specified altitude.
#define ALT_TO_RTH 1000 // in cm... = 10m

5) // set altitude after RTH, i.e. when copter reached to home position.
// DON'T USE VALUE LESS THEN 200 (2m) BECAUSE BARO ON ALTITUDES <2m WORKS UNSTABLE!!!
// Correct auto landing will be possible with sonar... soon ;)
#define ALT_TO_RTH_FINISH 350 // in cm... = 3.5m

6) // when roll or pitch more than specified value, PH (position hold) will be OFF and when roll/pitch stick released (i.e. in center) PH will be activated with new coordinates
// it will give possibility to fly in PH mode
#define GPSHOLD_DEADBAND 30

7) other changes from 2.1_b1 http://forum.rcdesign.ru/blogs/83206/blog15204.html
http://forum.rcdesign.ru/blogs/83206/blog15180.html

If you like this don't hesitate to buy me a beer by pressing donate button there ;)

thx-
Alex
Last edited by mahowik on Wed Dec 12, 2012 9:33 pm, edited 3 times in total.
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby Vaattari » Fri Sep 28, 2012 8:43 am

Mahovik, thanks for sharing the SW.
I tried b1 version with few flights in my Hex. I could not get Alt hold working at all even after playing with different PID values. Everytime the altitude hold worked worse than with MW2.1 (+-0.5m). During every test flight and after about 10 seconds the hex suddenly jumped up about 3 meters..
The hex does sudden small turns to left when only Level mode is used. Maybe that is caused by " #define GYR_CMPFM_FACTOR 400.0f" which you had in definitions, I have never used it before..
If everything works OK, what values should be seen in GUI debugs? Is there possible fixes in b2?
My setup:
Hex 6X (1.8kg AUW)
Flyduino Mega FC
Allinone +MS561101BA (BMA disabled from ALlinone)

Thanks
Vaattari
 
Posts: 14
Joined: Tue Mar 27, 2012 8:17 am

Re: Altitude Hold improvement solution

Postby shikra » Fri Sep 28, 2012 9:38 am

Alex - very cool indeed. Looking forward to testing next week.
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Postby mahowik » Fri Sep 28, 2012 3:52 pm

Vaattari wrote:I tried b1 version with few flights in my Hex. I could not get Alt hold working at all even after playing with different PID values. Everytime the altitude hold worked worse than with MW2.1 (+-0.5m). During every test flight and after about 10 seconds the hex suddenly jumped up about 3 meters..

At first pls. make sure:
- baro protected from direct sunlight (I saw 3-10m jumps in baro values after 2-3sec of direct sun!!!) and direct wind.
- all test must be made at an altitude higher than 1.5 meters to avoid ground effect.

Then if you have jumps, 99% you have too much vibrations on your board. Probably not balanced propellers etc. Actually algorithm not so sensitive to vibrations BUT much sensitive than LEVEL mode, because for level mode it's possible to use much stronger LPFs.
So you can do the following:
1) reduce vibrations if possible
2) I suppose you have BMA180 acc on your Allinone board. In this case set internal acc LPF from 20Hz to 10Hz in Sensors.ino
replace
Code: Select all
control = control | (0x01 << 4); // register: bw_tcs reg: bits 4-7 to set bw -- value: set low pass filter to 20Hz

to this
Code: Select all
control = control | (0x00 << 4); // set low pass filter to 10Hz (bits value = 0000xxxx)

3) change ACC_LPF_FOR_VELOCITY to 15 (max 20) from 10 in IMU.ino
4) then try to check how described here:
- viewtopic.php?f=8&t=2371&start=80#p22636
- viewtopic.php?f=8&t=2371&start=100#p22667
- viewtopic.php?f=8&t=2371&start=110#p22842

5) PIDs tuning: viewtopic.php?f=8&t=2371&start=90#p22649

6) still doesn't help?! :) go to the point one to balance your motors and props ;)

Vaattari wrote:The hex does sudden small turns to left when only Level mode is used. Maybe that is caused by " #define GYR_CMPFM_FACTOR 400.0f" which you had in definitions, I have never used it before..

High GYR_CMPFM_FACTOR is good protection for MAG noise and variable influence from power cords... BUT as I suppose you have a lot of vibrations on the board and your gyro can't be stabilized in CF with so high factor... just comment it back (by default it's 200)...

thx-
Alex
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Altitude Hold improvement solution

Postby Termic1 » Fri Sep 28, 2012 4:46 pm

Wow! Alex you're fantastic! I haven't my quad with me but monday I will test your code and I'll let you know!

Thanks again!

Luciano
Termic1
 
Posts: 40
Joined: Tue Aug 21, 2012 11:14 am

Re: Altitude Hold improvement solution

Postby dramida » Sat Sep 29, 2012 9:01 pm

Mahowik, you are the Man, i'll be the first who buys you lots of beer cans for your work. Even i didn't had time to test your last development Sw, I am convinced that we will reach a solution. 100$ from me, right now...donation is now complete
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby mahowik » Sat Sep 29, 2012 9:23 pm

dramida wrote:Mahowik, you are the Man, i'll be the first who buys you lots of beer cans for your work. Even i didn't had time to test your last development Sw, I am convinced that we will reach a solution. 100$ from me, right now...donation is now complete

Thanks a lot! But this is too much for beer! :) So I'm little bit confused...
I would like to return your money back ;)
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby dramida » Sat Sep 29, 2012 9:41 pm

I made much more money by using Multiwii copters, take a look at http://www.fotografieaeriana.eu , you are not the only one whom i donated money. Actually you earned it. Please keep it.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby jevermeister » Sun Sep 30, 2012 12:52 am

Wow!Nice one Dragu!
User avatar
jevermeister
 
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 13 guests