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
cswiger
Posts: 12
Joined: Wed Jun 20, 2012 11:43 pm

Re: Altitude Hold improvement solution

Post by cswiger »

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 :(

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

Re: Altitude Hold improvement solution

Post by LenzGr »

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
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Post by shikra »

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

Post by shikra »

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/

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

Re: Altitude Hold improvement solution

Post by LenzGr »

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
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Post by shikra »

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.....

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

Re: Altitude Hold improvement solution

Post by LenzGr »

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
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Post by shikra »

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 :)

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Altitude Hold improvement solution

Post by timecop »

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.

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

Re: Altitude Hold improvement solution

Post by LenzGr »

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
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Altitude Hold improvement solution

Post by Crashpilot1000 »

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
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Post by wilco1967 »

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.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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

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

Re: Altitude Hold improvement solution

Post by Magnetron »

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...

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Altitude Hold improvement solution

Post by timecop »

Why dont you post your ideas here, what's the point of discussing it in pm?

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

Re: Altitude Hold improvement solution

Post by Magnetron »

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.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Altitude Hold improvement solution

Post by timecop »

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.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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.

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

Re: Altitude Hold improvement solution

Post by Magnetron »


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

Re: Altitude Hold improvement solution

Post by Magnetron »

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?

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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.

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Post by wilco1967 »

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>

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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.

Deet
Posts: 129
Joined: Sun Jul 08, 2012 1:54 am

Re: Altitude Hold improvement solution

Post by Deet »

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

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

Re: Altitude Hold improvement solution

Post by nhadrian »

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

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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

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

Re: Altitude Hold improvement solution

Post by Termic1 »

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


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

thx Alex!

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Post by wilco1967 »

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....

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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

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

Re: Altitude Hold improvement solution

Post by Termic1 »

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

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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.

Imen
Posts: 20
Joined: Thu Sep 27, 2012 5:11 pm

Re: Altitude Hold improvement solution

Post by Imen »

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

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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

charbot
Posts: 34
Joined: Wed May 23, 2012 8:37 pm

Re: Altitude Hold improvement solution

Post by charbot »

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?

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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.

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

Re: Altitude Hold improvement solution

Post by Vaattari »

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

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Post by shikra »

Alex - very cool indeed. Looking forward to testing next week.

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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

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

Altitude Hold improvement solution

Post by Termic1 »

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

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Post by mahowik »

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 ;)

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold improvement solution

Post by dramida »

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
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Altitude Hold improvement solution

Post by jevermeister »

Wow!Nice one Dragu!

Post Reply