Page 4 of 12

Re: Altitude Hold improvement solution

Posted: Tue Sep 18, 2012 8:43 pm
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 :(

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 9:44 am
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.

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 10:31 am
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 :(

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 10:38 am
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/

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 10:57 am
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"

:(

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 11:32 am
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.....

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 12:08 pm
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?

Re: Altitude Hold improvement solution

Posted: Wed Sep 19, 2012 12:33 pm
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 :)

Re: Altitude Hold improvement solution

Posted: Thu Sep 20, 2012 2:34 am
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?

Re: Altitude Hold improvement solution

Posted: Thu Sep 20, 2012 2:49 am
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.

Re: Altitude Hold improvement solution

Posted: Thu Sep 20, 2012 8:16 am
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

Re: Altitude Hold improvement solution

Posted: Thu Sep 20, 2012 2:57 pm
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

Re: Altitude Hold improvement solution

Posted: Fri Sep 21, 2012 8:22 pm
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.

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 7:24 am
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.

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 7:34 am
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)

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 7:59 am
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

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 8:49 am
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...

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 8:54 am
by timecop
Why dont you post your ideas here, what's the point of discussing it in pm?

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 9:31 am
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.

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 9:34 am
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.

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 12:00 pm
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.

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 1:49 pm
by Magnetron

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 1:51 pm
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?

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 6:03 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 6:10 pm
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>

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 6:13 pm
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"...

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 6:46 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 7:16 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Sep 22, 2012 8:30 pm
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.

Re: Altitude Hold improvement solution

Posted: Sun Sep 23, 2012 12:38 am
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

Re: Altitude Hold improvement solution

Posted: Sun Sep 23, 2012 9:28 am
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

Re: Altitude Hold improvement solution

Posted: Mon Sep 24, 2012 3:35 am
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

Re: Altitude Hold improvement solution

Posted: Mon Sep 24, 2012 7:32 pm
by Termic1
mahowik wrote:I'm going to post sketch/code soon...


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

thx Alex!

Re: Altitude Hold improvement solution

Posted: Mon Sep 24, 2012 7:45 pm
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....

Re: Altitude Hold improvement solution

Posted: Mon Sep 24, 2012 9:56 pm
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

Re: Altitude Hold improvement solution

Posted: Wed Sep 26, 2012 12:47 pm
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

Re: Altitude Hold improvement solution

Posted: Wed Sep 26, 2012 10:05 pm
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.

Re: Altitude Hold improvement solution

Posted: Thu Sep 27, 2012 5:54 pm
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

Re: Altitude Hold improvement solution

Posted: Thu Sep 27, 2012 6:21 pm
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

Re: Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 1:13 am
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?

Re: Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 5:00 am
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...

Re: Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 5:59 am
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

Re: Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 8:43 am
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

Re: Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 9:38 am
by shikra
Alex - very cool indeed. Looking forward to testing next week.

Re: Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 3:52 pm
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

Altitude Hold improvement solution

Posted: Fri Sep 28, 2012 4:46 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Sep 29, 2012 9:01 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Sep 29, 2012 9:23 pm
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 ;)

Re: Altitude Hold improvement solution

Posted: Sat Sep 29, 2012 9:41 pm
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.

Re: Altitude Hold improvement solution

Posted: Sun Sep 30, 2012 12:52 am
by jevermeister
Wow!Nice one Dragu!