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
jgrouse
Posts: 5
Joined: Thu Jun 14, 2012 12:20 am

Re: Altitude Hold improvement solution

Post by jgrouse »

Really liking the way the baro alt hold works now.

On a separate line of code, there is a working baro/sonar alt hold. Using my MaxBotix MB1200 sonar this works really well when the alt is in sonar range. Anywhere out of that range and the baro code is really erratic. Probably does not help that there are trees around me and the sonar is probably bouncing lower than actual cm to the code as the hexacopter floats above the trees.

So two separate code bases which do great jobs for either sonar or baro alt hold, just not both.

I did try Multiwii_r1311_NHA_r13_COMPLETE with just baro and that is great, but then I thought I would try to replace the BaroAlt value with the sonarAlt value when BaroAlt < 300 and sonarAlt < 300 -

Code: Select all

  // pressure relative to ground pressure with temperature compensation (fast!)
  // baroGroundPressure is not supposed to be 0 here
  // see: https://code.google.com/p/ardupilot-mega/source/browse/libraries/AP_Baro/AP_Baro.cpp
  BaroAlt = log( baroGroundPressure / (baroPressureSum/(float)(BARO_TAB_SIZE - 1)) ) * (baroTemperature+27315) * 29.271267f; // in cemtimeter
  #if SONAR
    if ((BaroAlt < 300) && (sonarAlt < 300))
    {
       BaroAlt = sonarAlt;
    }
  #endif
  debug[0] = (int16_t)BaroAlt;
  debug[1] = sonarAlt;
  EstAlt = (EstAlt * 6 + BaroAlt * 2) >> 3; // additional LPF to reduce baro noise (faster by 30 µs)


But as soon as I enable BARO mode, the hexacopter goes ballistic regardless of the alt being < 300 or > 300. The altitude read from wireless telemetry is spot on across the whole range from the ground to 10+m so I cannot see how feeding BaroAlt the sonarAlt value would cause the max throttle condition when the only difference is that the sonar is more accurate at < 300cm. Even stranger when only the original BaroAlt value is being used when I am sitting at 10m, and it still wants to go ballistic. If I comment out the extra if test, the baro alt hold goes back to normal. I thought the issue might be that sonarAlt is int16_t, however EstAlt is showing the correct value and the debug[0] is showing the sonarAlt correctly.

Has anyone managed to meld sonar values into this offshoot of the 1311 code? I know there was talk about using sonar on the last few meters of a RTH auto landing.

jgrouse
Posts: 5
Joined: Thu Jun 14, 2012 12:20 am

Re: Altitude Hold improvement solution

Post by jgrouse »

Just dug a little deeper and it looks like the Multiwii_r1311_NHA_r13_COMPLETE baro alt hold code is time critical - if I comment out the analogRead(2) call for the sonar, baro alt hold behaves itself. I'm only calling it at the same frequency the baro sensor is read. Just looks like it's too much extra time for the alt hold to work reliably. I wanted the sonarAlt to be read in before the BaroAlt is set. This is where my analogRead sub is called (case 1)-

Code: Select all

  } else { // not in rc loop
    static uint8_t taskOrder=0; // never call all functions in the same loop, to avoid high delay spikes
    if(taskOrder>5) taskOrder-=6;
    switch (taskOrder) {
      case 0:
        taskOrder++;
        #if MAG
          if (Mag_getADC()) break; // max 350 µs (HMC5883) // only break when we actually did something
        #endif
      case 1:
        taskOrder++;
        #if SONAR
          MaxSonar_update();
        #endif       
      case 2:
        taskOrder++;
        #if BARO
          if (Baro_update() != 0 ) break;
        #endif
      case 3:
        taskOrder++;
        #if BARO
          if (getEstimatedAltitude() !=0) break;
        #endif   
      case 4:
        taskOrder++;
        #if GPS
          if(GPS_Enable) GPS_NewData();
          break;
        #endif
      case 5:
        taskOrder++;
//        #if SONAR
//          Sonar_update();debug[2] = sonarAlt;
//        #endif
        #ifdef LANDING_LIGHTS_DDR
          auto_switch_landing_lights();
        #endif
        #ifdef VARIOMETER
          if (f.VARIO_MODE) vario_signaling();
        #endif
        break;
    }
  }


Looks like a single analogRead eats up 100us. Is that a lot in the scheme of things?
Might need to go back to using the SRF02 I2C sonar. Bit more noise in the values, but far less processing time to get a value out of it.

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Post by subaru4wd »

nhadrian wrote:
If you can disconnect ESCs, you can test hearfree in your hand, arm the copter, apply some throttle, push roll or pitch. So you will see the motor outputs on GUI like they're trying to moce copter (2 of 4 motors will increase other will decrease). Now rotate copter around z axis (yaw) by 90 degrees, apply the same stick movement, and if headfree is active indeed, you will see that different motor outputs will increase or decrease...

BR
Adrian



I will try this tonight or tomorrow. I took my quad out to fly after completely rebuilding my motors (new bearings, perfectly balanced bells) and I had a silly grub screw vibrate loose sending my quad crashing into the pavement. Turned my new frame into a mess of broken plastic. Just needs 2 arms and a new set of props... hopefully my electronics survived the impact. I will have the frame on the bench and will do some further tests and send you a config.h

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

Re: Altitude Hold improvement solution

Post by nhadrian »

subaru4wd wrote:I will try this tonight or tomorrow. I took my quad out to fly after completely rebuilding my motors (new bearings, perfectly balanced bells) and I had a silly grub screw vibrate loose sending my quad crashing into the pavement. Turned my new frame into a mess of broken plastic. Just needs 2 arms and a new set of props... hopefully my electronics survived the impact. I will have the frame on the bench and will do some further tests and send you a config.h


And what about EEPROM issue? Could you overcome on it? Do you have the same behaviour with the untouched official r1311 too?

BR
Adrian

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

Re: Altitude Hold improvement solution

Post by wilco1967 »

Tried failsafe RTH with autoland with the 1311 R13 yesterday with my BMP085 equipped tricopter, with mixed results....

after turning off the transmitter, the copter started heading back... it went to RTH altitude correctly.
when it arrived at home, it started descending.... but after a few seconds, while still up at approx 10 meters, it decided, it had landed, and it disarmed.... :roll: :shock:

quite funny to see how it decided to quit, and it fell down like a brick..... :lol: however, I don't think this was intended behaviour...
only some props broken, and a stripped gear of the tail servo.... all repaired already... 8-)

I guess the issue could be my BMP-085 not being very acurate... alt holt works reasonable, but has always been a bit bumpy... when decending, it always overshoots, and climbs back up before making another drop that overshoots.....
I suspect the alt PID output reached -200 (or whatever it max value is), causing it to think it landed, thus causing the motors to disarm.... actual 'landing' then happened a few seconds later, but with slightly higher vertical velocity... :lol:

Perhaps adding a few seconds delay after reaching max alt PID output could prevent it from disarming while still in the air ?
tuning of the the alt PID controller could also be helpfull, but I don't want to risk it like this..... I only have limited supply of props :roll:

It did the same thing some time back with rev 9 (i think)... when decending after reaching home....

Anyone else using this with a BMP-085 baro ?

Overall it seems to work quite well..... just some minor 'tweaking' required
Thanks !

schott1984
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold improvement solution

Post by schott1984 »

Anyone notice the AP_MODE define is commented out of nhadrian's uploaded code? I

What gives here?

I'm new here. Nice to meet you all.

I could use a little bit of explanation regarding this deadspan and how it works. I know it's off-topic... Sorry.

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

Re: Altitude Hold improvement solution

Post by nhadrian »

schott1984 wrote:Anyone notice the AP_MODE define is commented out of nhadrian's uploaded code? I
What gives here?


Hi, this is a deadspan for roll/pitch. If you apply mode roll/pitch during hold mode, it will release from hold mode and once stick is back to centre, it'll save the new position as home. It must be uncommented, unless Arduino gives a compilation error.

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

Re: Altitude Hold improvement solution

Post by nhadrian »

wilco1967 wrote:Tried failsafe RTH with autoland with the 1311 R13 yesterday with my BMP085 equipped tricopter, with mixed results....

after turning off the transmitter, the copter started heading back... it went to RTH altitude correctly.
when it arrived at home, it started descending.... but after a few seconds, while still up at approx 10 meters, it decided, it had landed, and it disarmed.... :roll: :shock:

quite funny to see how it decided to quit, and it fell down like a brick..... :lol: however, I don't think this was intended behaviour...
only some props broken, and a stripped gear of the tail servo.... all repaired already... 8-)

I guess the issue could be my BMP-085 not being very acurate... alt holt works reasonable, but has always been a bit bumpy... when decending, it always overshoots, and climbs back up before making another drop that overshoots.....
I suspect the alt PID output reached -200 (or whatever it max value is), causing it to think it landed, thus causing the motors to disarm.... actual 'landing' then happened a few seconds later, but with slightly higher vertical velocity... :lol:

Perhaps adding a few seconds delay after reaching max alt PID output could prevent it from disarming while still in the air ?
tuning of the the alt PID controller could also be helpfull, but I don't want to risk it like this..... I only have limited supply of props :roll:

It did the same thing some time back with rev 9 (i think)... when decending after reaching home....

Anyone else using this with a BMP-085 baro ?

Overall it seems to work quite well..... just some minor 'tweaking' required
Thanks !


Hi,

I'm happy to hear that code works, and sad to hear your crash!!!
The BaroPID off-condition is raised to -250 in r13, so it can't be the reason.

BUT! For safety reasons, FAILSAFE_OFF_DELAY condition is still active in all my FAILSAFE modes, that means, once this time ends, it will disarm!!! (I mentioned somewhere earlier, maybe should highlihgt again...).
So, it must be set high enough to allow get home before this time ends. In my code it is 500 by default, it means only 50s. I suggest to raise this value to the neccessary extent!
I'll highlight this fact in my config.h, sorry for that!!!

Regarding to bumpy behaviour, first of all, you should fine-tune alt hold PIDs during hovering. If you have already stable and good enough hovering behaviour but still very bumpy in raising/descending, I'll think on how to setup the correction values.

BR
Adrian

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Altitude Hold improvement solution

Post by Eric »

nhadrian wrote:
wilco1967 wrote:Tried failsafe RTH with autoland with the 1311 R13 yesterday with my BMP085 equipped tricopter, with mixed results....

after turning off the transmitter, the copter started heading back... it went to RTH altitude correctly.
when it arrived at home, it started descending.... but after a few seconds, while still up at approx 10 meters, it decided, it had landed, and it disarmed.... :roll: :shock:

quite funny to see how it decided to quit, and it fell down like a brick..... :lol: however, I don't think this was intended behaviour...
only some props broken, and a stripped gear of the tail servo.... all repaired already... 8-)

I guess the issue could be my BMP-085 not being very acurate... alt holt works reasonable, but has always been a bit bumpy... when decending, it always overshoots, and climbs back up before making another drop that overshoots.....
I suspect the alt PID output reached -200 (or whatever it max value is), causing it to think it landed, thus causing the motors to disarm.... actual 'landing' then happened a few seconds later, but with slightly higher vertical velocity... :lol:

Perhaps adding a few seconds delay after reaching max alt PID output could prevent it from disarming while still in the air ?
tuning of the the alt PID controller could also be helpfull, but I don't want to risk it like this..... I only have limited supply of props :roll:

It did the same thing some time back with rev 9 (i think)... when decending after reaching home....

Anyone else using this with a BMP-085 baro ?

Overall it seems to work quite well..... just some minor 'tweaking' required
Thanks !


Hi,

I'm happy to hear that code works, and sad to hear your crash!!!
The BaroPID off-condition is raised to -250 in r13, so it can't be the reason.

BUT! For safety reasons, FAILSAFE_OFF_DELAY condition is still active in all my FAILSAFE modes, that means, once this time ends, it will disarm!!! (I mentioned somewhere earlier, maybe should highlihgt again...).
So, it must be set high enough to allow get home before this time ends. In my code it is 500 by default, it means only 50s. I suggest to raise this value to the neccessary extent!
I'll highlight this fact in my config.h, sorry for that!!!

Regarding to bumpy behaviour, first of all, you should fine-tune alt hold PIDs during hovering. If you have already stable and good enough hovering behaviour but still very bumpy in raising/descending, I'll think on how to setup the correction values.

BR
Adrian


Why don't you think BaroPID is not the reason about crash?

The Baro drifts in about 3m.

As I suggested before, check if the BaroPID is contiguously very low in 5 seconds.

And we do not know how long the failsafe delay will be enough. Even if we set an very big value, we do not know if the battery can last that long.

So we'd better to calc a speed for it to go home in about 10 seconds.

The longer the quad stays in air without RC, the more chance for it to crash.

Hope you think about it. That was how I implemented my quad.

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

Re: Altitude Hold improvement solution

Post by nhadrian »

Hi,

The BaroPID is between +-80-100 during normal altitude working. Just test out what's happening when you reduce the throttle from hovering position by 250 during manual mode. It will fell down from the sky...
The drift in alt reading is not important unless it drifts 3m between two baro sensor readings. (Because drift is relative drift, so the only caused by sensor drift is that it will hover 2-3 m away from target altitude)

The reason why I dont have any timer after BaroPID gets under -250 is to aovid further damages when copter couldn't land perfectly. (Ie. Burning ESCs caused by stucked props, when landing in high grass)

Failsafe_off_delay can be set to high enough (ie. if you know your flight time is 8 min, set it to 8000).
Anyway, it must be kept in mind that Failsafe is a safety function, not a leisure one, the only function of faisafe rth is to bring the copter back if possible inside RC range or near take-off zone and prevent crashes from high altitude, not to make a perfect auto landing. (At least this is my oppinion).

Br Adrian
Last edited by nhadrian on Tue Jan 15, 2013 4:20 pm, edited 2 times in total.

schott1984
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold improvement solution

Post by schott1984 »

nhadrian wrote:
Hi, this is a deadspan for roll/pitch. If you apply mode roll/pitch during hold mode, it will release from hold mode and once stick is back to centre, it'll save the new position as home. It must be uncommented, unless Arduino gives a compilation error.

Thank you for the reply!

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

Re: Altitude Hold improvement solution

Post by wilco1967 »

nhadrian wrote:BUT! For safety reasons, FAILSAFE_OFF_DELAY condition is still active in all my FAILSAFE modes, that means, once this time ends, it will disarm!!! (I mentioned somewhere earlier, maybe should highlihgt again...).
So, it must be set high enough to allow get home before this time ends. In my code it is 500 by default, it means only 50s. I suggest to raise this value to the neccessary extent!
BR
Adrian


That must be the 50 seconds setting that caused it to fall..... checked it was indeed set at 500 (50s).... :roll:
raised it to 5000, so should not interfere anymore.... will try again next time if weather allows...

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

Re: Altitude Hold improvement solution

Post by dramida »

Here is how it flies R13 with Crius AIOP

http://www.youtube.com/watch?v=BdaN-ddVmi8

Last edit:

I activated RTH function with altitude control during RTH. I found out that copter starts moving immediately twards home, even the RTH altitude is not achieved. Practically, before reaching RTH altitude, the copter makes about half of distance back. In this case trees and houses could not be avoided. A more healthy approach for failsafe RTH is when altitude is below RTH altitude, first position hold until safe altitude is reached, then continue with RTH and autoland...

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

with latest revisions my altitude hold is messed.... when I switch on the BARO the quad just shoot in the air at full throttle like a rocket... if i revert back to my latest working (r1298, haven't tried others) then it's fine... happened to somebody else?

CRIUS AIO PRO V1.1

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

Re: Altitude Hold improvement solution

Post by nhadrian »

dramida wrote:Here is how it flies R13 with Crius AIOP

http://www.youtube.com/watch?v=BdaN-ddVmi8

Last edit:

I activated RTH function with altitude control during RTH. I found out that copter starts moving immediately twards home, even the RTH altitude is not achieved. Practically, before reaching RTH altitude, the copter makes about half of distance back. In this case trees and houses could not be avoided. A more healthy approach for failsafe RTH is when altitude is below RTH altitude, first position hold until safe altitude is reached, then continue with RTH and autoland...


It is much harder to solve this problem, and takes a lot of time. I'll try to figure something out.
Last edited by nhadrian on Thu Jan 17, 2013 7:19 pm, edited 1 time in total.

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

Re: Altitude Hold improvement solution

Post by nhadrian »

albertoLG wrote:with latest revisions my altitude hold is messed.... when I switch on the BARO the quad just shoot in the air at full throttle like a rocket... if i revert back to my latest working (r1298, haven't tried others) then it's fine... happened to somebody else?

CRIUS AIO PRO V1.1


Hi, could you please describe what release did you try? Perhaps the official r1315 from multiwii repo?

For me the latest change for MS5611-01 (in official r1315) isn't working, perhaps there is something around dT calculations (in latest r1315 the dT is changed from 32 to 64 bit integer).

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

nhadrian wrote:
albertoLG wrote:with latest revisions my altitude hold is messed.... when I switch on the BARO the quad just shoot in the air at full throttle like a rocket... if i revert back to my latest working (r1298, haven't tried others) then it's fine... happened to somebody else?

CRIUS AIO PRO V1.1


Hi, could you please describe what release did you try? Perhaps the official r1315 from multiwii repo?

For me the latest change for MS5611-01 (in official r1315) isn't working, perhaps there is something around dT calculations (in latest r1315 the dT is changed from 32 to 64 bit integer).


Yes, tested 1315 and don't work, 1310 wasn't working too... tomorrow i can try all the revisions, from 1298 to 1310, and I'll try to find where is the problem... the only changes I can see right now are in the IMU.ino and Multiwii.ino, rev1303
http://code.google.com/p/multiwii/sourc ... ed/IMU.ino

http://code.google.com/p/multiwii/sourc ... ltiWii.ino

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

Re: Altitude Hold improvement solution

Post by nhadrian »

in r1315 there are changes in the MS5611 code.
You should try the official r1313 from multiwii repo download site.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Post by Alexinparis »

nhadrian wrote:
albertoLG wrote:with latest revisions my altitude hold is messed.... when I switch on the BARO the quad just shoot in the air at full throttle like a rocket... if i revert back to my latest working (r1298, haven't tried others) then it's fine... happened to somebody else?

CRIUS AIO PRO V1.1


Hi, could you please describe what release did you try? Perhaps the official r1315 from multiwii repo?

For me the latest change for MS5611-01 (in official r1315) isn't working, perhaps there is something around dT calculations (in latest r1315 the dT is changed from 32 to 64 bit integer).


Hi,

There was effectively a bug in r1315 about the last change on baro MS.
I've just corrected it and made a new dev release.

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Post by subaru4wd »

Alexinparis wrote:There was effectively a bug in r1315 about the last change on baro MS.
I've just corrected it and made a new dev release.


"giggity giggity"

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Re: Altitude Hold improvement solution

Post by Mystic3D »

Alexinparis wrote:
nhadrian wrote:
albertoLG wrote:with latest revisions my altitude hold is messed.... when I switch on the BARO the quad just shoot in the air at full throttle like a rocket... if i revert back to my latest working (r1298, haven't tried others) then it's fine... happened to somebody else?

CRIUS AIO PRO V1.1


Hi, could you please describe what release did you try? Perhaps the official r1315 from multiwii repo?

For me the latest change for MS5611-01 (in official r1315) isn't working, perhaps there is something around dT calculations (in latest r1315 the dT is changed from 32 to 64 bit integer).


Hi,

There was effectively a bug in r1315 about the last change on baro MS.
I've just corrected it and made a new dev release.


There is some timing problem with Baro and r1316, when I first take off, it will either give full power, or seems like 30% power, it's random, as to which way. If I land, disarm,rearm, then it seems to "correct" itself. It does not matter if default PID, on Alt Hold, or not, Positive/Negative values, no difference. same behavoir in r1311.

When it does "hold" , it's like you san hear it "switch"
Sorry just a noob, 3 weeks into Multi's, if I am not following protocol, please advise.

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Alexinparis wrote:
nhadrian wrote:
albertoLG wrote:with latest revisions my altitude hold is messed.... when I switch on the BARO the quad just shoot in the air at full throttle like a rocket... if i revert back to my latest working (r1298, haven't tried others) then it's fine... happened to somebody else?

CRIUS AIO PRO V1.1


Hi, could you please describe what release did you try? Perhaps the official r1315 from multiwii repo?

For me the latest change for MS5611-01 (in official r1315) isn't working, perhaps there is something around dT calculations (in latest r1315 the dT is changed from 32 to 64 bit integer).


Hi,

There was effectively a bug in r1315 about the last change on baro MS.
I've just corrected it and made a new dev release.


Thanks Alex, today I'll try the 1316 and report back

regards

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Tested the 1316 and the problem is still the same... BARO ON my quad is launched like a rocket :-(

as I said the problem is earlier than 1315

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Post by Alexinparis »

Mystic3D wrote:
There is some timing problem with Baro and r1316, when I first take off, it will either give full power, or seems like 30% power, it's random, as to which way. If I land, disarm,rearm, then it seems to "correct" itself. It does not matter if default PID, on Alt Hold, or not, Positive/Negative values, no difference. same behavoir in r1311.

When it does "hold" , it's like you san hear it "switch"
Sorry just a noob, 3 weeks into Multi's, if I am not following protocol, please advise.


Hi,

In all current releases including the last r1316, the default baro mode is alt hold.

In this mode, the baro switch must not be enable on the ground, but only once in the air to "lock" the current alt.

If you enable it on the ground before the take off, you could encounter high variations of throttle at the beginning and think it doesn't work.

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Alexinparis wrote:
Mystic3D wrote:
There is some timing problem with Baro and r1316, when I first take off, it will either give full power, or seems like 30% power, it's random, as to which way. If I land, disarm,rearm, then it seems to "correct" itself. It does not matter if default PID, on Alt Hold, or not, Positive/Negative values, no difference. same behavoir in r1311.

When it does "hold" , it's like you san hear it "switch"
Sorry just a noob, 3 weeks into Multi's, if I am not following protocol, please advise.


Hi,

In all current releases including the last r1316, the default baro mode is alt hold.

In this mode, the baro switch must not be enable on the ground, but only once in the air to "lock" the current alt.

If you enable it on the ground before the take off, you could encounter high variations of throttle at the beginning and think it doesn't work.


I don't enable it on the ground, I fly around, then when I switch it on, the quad shoot in the air like a rocket... as I said with previous version (1298) it is perfect... maybe 20 cm. up or down, and when I switch it on the copter just stay there, no full throttle is given.

P.S.
I can make a video when the weather will be better

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Re: Altitude Hold improvement solution

Post by Mystic3D »

I do not enable ALT_HOLD on the ground, I take off, flip to Angle Mode, Hover, then flip to ALT_HOLD = Baro+Angle+Mag.

Other note: I do clear EEPROM before I load new code, I do have Sirius and it's got a tube over the baro sensor with cotton as a "buffer" inside
Not sure if this matters, but expo on throttle 30% and Midpoint of TH is 70%

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

Re: Altitude Hold improvement solution

Post by Deet »

Mystic3D wrote:I do not enable ALT_HOLD on the ground, I take off, flip to Angle Mode, Hover, then flip to ALT_HOLD = Baro+Angle+Mag.

Other note: I do clear EEPROM before I load new code, I do have Sirius and it's got a tube over the baro sensor with cotton as a "buffer" inside
Not sure if this matters, but expo on throttle 30% and Midpoint of TH is 70%



Why do you have midpoint of throttle @70%, that may be your problem

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

Re: Altitude Hold improvement solution

Post by dramida »

Please consider that mid point for alt hold is 1500us for throttle, regardless where your copter hovers. If you like to hold altitude in a undefined position of your throttle, you should comment this line:

Code: Select all

#define ALT_HOLD_THROTTLE_MIDPOINT        1500  // in us    - if uncommented, this value is used in ALT_HOLD for throttle stick middle point instead of initialThrottleHold parameter.


This could be the cause of " jumps"when activating Alt Hold with throttle more than 1550 with #define ALT_HOLD_THROTTLE_NEUTRAL_ZONE 50

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Altitude Hold improvement solution

Post by copterrichie »

A really Good Throttle Curve is required here, over and out.

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Altitude Hold improvement solution

Post by Mystic3D »

Good Info, I will reset the midpoint TC from .7 to .5. I had it set to .5 in 2.1 without this behavoir.

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

Re: Altitude Hold improvement solution

Post by nhadrian »

dramida wrote:Please consider that mid point for alt hold is 1500us for throttle, regardless where your copter hovers. If you like to hold altitude in a undefined position of your throttle, you should comment this line:

Code: Select all

#define ALT_HOLD_THROTTLE_MIDPOINT        1500  // in us    - if uncommented, this value is used in ALT_HOLD for throttle stick middle point instead of initialThrottleHold parameter.


This could be the cause of " jumps"when activating Alt Hold with throttle more than 1550 with #define ALT_HOLD_THROTTLE_NEUTRAL_ZONE 50


Hi dramida,

thanks for the explanation!
In fact, MISTIC3D is trying to use the official r1316 release I think.
In that there isn't ALT_HOLD_THROTTLE_MIDPOINT parameter.
Just to avoid confusions.

BR
Adrian

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

Re: Altitude Hold improvement solution

Post by nhadrian »

Hi all, I started a new topic for my development, copied the important conversations to there.
I'd kindly ask you to continue all conversations regarding to my code there!

viewtopic.php?f=8&t=2965

BR
Adrian

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Did some more tests, the problem is introduced with the rev1303 (tested 1299 and is working fine), before this the BARO is working fine, with the 1303 it act like I described:
- hovering, switch on BARO and the quad jump in the air, I need to switch it off before it is too high and I can't see it.
Of course I tested 1316 and is the same

regards

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Post by Alexinparis »

albertoLG wrote:Did some more tests, the problem is introduced with the rev1303 (tested 1299 and is working fine), before this the BARO is working fine, with the 1303 it act like I described:
- hovering, switch on BARO and the quad jump in the air, I need to switch it off before it is too high and I can't see it.
Of course I tested 1316 and is the same

regards


Hi,
One my side, everything works fine with the last dev, with both baro type.

So let's try to debug your case.
fact: 1299 works and not 1303 on your side. you've got a crius aiopv1.1 => with MS baro.
so no problem with BMP085 code change

what conf are you using, which specific def ?
is the baro line in the gui as stable as before ?

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Alexinparis wrote:
albertoLG wrote:Did some more tests, the problem is introduced with the rev1303 (tested 1299 and is working fine), before this the BARO is working fine, with the 1303 it act like I described:
- hovering, switch on BARO and the quad jump in the air, I need to switch it off before it is too high and I can't see it.
Of course I tested 1316 and is the same

regards


Hi,
One my side, everything works fine with the last dev, with both baro type.

So let's try to debug your case.
fact: 1299 works and not 1303 on your side. you've got a crius aiopv1.1 => with MS baro.
so no problem with BMP085 code change

what conf are you using, which specific def ?
is the baro line in the gui as stable as before ?


Thank you Alex, yes, mine is a Crius AIOP v1.1 with the MS5611, my config is attached here, nothing strange, I changed only the MAXTHROTTLE to 1960 from the default 2000. The PIDs are default, checked in the GUI and everything works as expected, same baro line with the 1299 and 1303, same behaviour, if I pull up the copter, the baro line rises. Really I don't know what's wrong with mine, I repeat, 1299 working perfect, 1303 throttle up and never stops, only enabled the ANGLE+BARO (honestly haven't tried only BARO, right now it's raining so I can't do it) in both revisions. Any other test I can do it's welcome.

thank you
Attachments
config.zip
(18.09 KiB) Downloaded 798 times

Frosty3k
Posts: 3
Joined: Sat Jan 19, 2013 4:57 pm

Re: Altitude Hold improvement solution

Post by Frosty3k »

Hi,

same thing happens to me 2. I have a Holybro HK 328P, that has the BMP085 baro on it. I wanted to try out the AltHold only, so i enabled only the BARO and as soon as i armed the motors the quad started to lift off quickly and it rotated about 90 degrees to the left...this was done indoors so I immediately disarmed the motors.

Just to clarify ... after I armed the motors the throttle was bottomed out...no throttle input at all...even by the sound the props where making you could tell something was...different. My throttle range is 1100 to 1940.

Without the baro enabled, everything's fine... I now use rev1311 and before i was using the mw 2.1 one..the default for my board; the baro was was okish with the default firmware....+/- 50 cm error.

Looks like rev 1316 is out...maybe its fixed

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Altitude Hold improvement solution

Post by copterrichie »

Frosty3k wrote:Hi,

same thing happens to me 2. I have a Holybro HK 328P, that has the BMP085 baro on it. I wanted to try out the AltHold only, so i enabled only the BARO and as soon as i armed the motors the quad started to lift off quickly and it rotated about 90 degrees to the left...this was done indoors so I immediately disarmed the motors.

Just to clarify ... after I armed the motors the throttle was bottomed out...no throttle input at all...even by the sound the props where making you could tell something was...different. My throttle range is 1100 to 1940.

Without the baro enabled, everything's fine... I now use rev1311 and before i was using the mw 2.1 one..the default for my board; the baro was was okish with the default firmware....+/- 50 cm error.

Looks like rev 1316 is out...maybe its fixed


I am just curious, are you using the MOTOR_STOP? I understand when you had the baro enabled.

Code: Select all

/* motors will not spin when the throttle command is in low position
       this is an alternative method to stop immediately the motors */
    //#define MOTOR_STOP

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Altitude Hold improvement solution

Post by Mystic3D »

Okay reset TC to default,Mid .5, Expo .0
Same behavior with 1313, 1316, BP085, Motor Stop =yes

Important point, it happens after I arm take off, turn on Baro+Angle+Mag. When I land and disarm, rearm, it "usually" works fine.

Frosty3k
Posts: 3
Joined: Sat Jan 19, 2013 4:57 pm

Re: Altitude Hold improvement solution

Post by Frosty3k »

copterrichie wrote:I am just curious, are you using the MOTOR_STOP? I understand when you had the baro enabled.


no, I've never touched that, I've checked and its commented.

but you should know the issue is resolved (at least for me) in the latest rev (1316)
I have tested baro only and its cool now...Ive only checked if its in rocket mode, but it looks fine now...

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Altitude Hold improvement solution

Post by copterrichie »

yea, the MOTOR_STOP would only effect the rocketing as soon as the copter is armed, not the rocketing itself. Just wanted to know if that segment of the code was affected. :)

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Mystic3D wrote:Okay reset TC to default,Mid .5, Expo .0
Same behavior with 1313, 1316, BP085, Motor Stop =yes

Important point, it happens after I arm take off, turn on Baro+Angle+Mag. When I land and disarm, rearm, it "usually" works fine.


hhmm... I'll need to test if arming/disarming/arming change someting..

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Post by Alexinparis »

albertoLG wrote:
Alexinparis wrote:
albertoLG wrote:Did some more tests, the problem is introduced with the rev1303 (tested 1299 and is working fine), before this the BARO is working fine, with the 1303 it act like I described:
- hovering, switch on BARO and the quad jump in the air, I need to switch it off before it is too high and I can't see it.
Of course I tested 1316 and is the same

regards


Hi,
One my side, everything works fine with the last dev, with both baro type.

So let's try to debug your case.
fact: 1299 works and not 1303 on your side. you've got a crius aiopv1.1 => with MS baro.
so no problem with BMP085 code change

what conf are you using, which specific def ?
is the baro line in the gui as stable as before ?


Thank you Alex, yes, mine is a Crius AIOP v1.1 with the MS5611, my config is attached here, nothing strange, I changed only the MAXTHROTTLE to 1960 from the default 2000. The PIDs are default, checked in the GUI and everything works as expected, same baro line with the 1299 and 1303, same behaviour, if I pull up the copter, the baro line rises. Really I don't know what's wrong with mine, I repeat, 1299 working perfect, 1303 throttle up and never stops, only enabled the ANGLE+BARO (honestly haven't tried only BARO, right now it's raining so I can't do it) in both revisions. Any other test I can do it's welcome.

thank you


ok thank you
I think I found the bug.

I introduced return 0; here:

Code: Select all

  if(calibratingB > 0) {
    baroGroundPressure = baroPressureSum/(BARO_TAB_SIZE - 1);
    calibratingB--;
    return 0;
  }

because there is no reason to calculate an alt without the stabilization of moving average baroHistTab[] and baroGroundPressureSum . It lasts around 10s.

however, accZoffset needs to be right updated just before take off, and it can't be updated if return0; is present during the alt calibration.
=> if you arm the multi before the end of alt calibration, there will be a permanent accZ offset which explains what you encountered.
if you arm the multi after lets say 15 or 20s after power up (or after disarm/arm steps), no problem.

simple fix: remove return 0; in IMU.ino

Code: Select all

  if(calibratingB > 0) {
    baroGroundPressure = baroPressureSum/(BARO_TAB_SIZE - 1);
    calibratingB--;
  }

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Re: Altitude Hold improvement solution

Post by Mystic3D »

Yes that code change fixed the problem.
4 packs and no shooting up.


What is strange now is the Baro Display in the GUI is very erratic, I would have thought the display is data direct from the sensor before it goes through the routines.??

albertoLG
Posts: 57
Joined: Fri Sep 07, 2012 8:14 am

Re: Altitude Hold improvement solution

Post by albertoLG »

Alexinparis wrote:
ok thank you
I think I found the bug.

I introduced return 0; here:

Code: Select all

  if(calibratingB > 0) {
    baroGroundPressure = baroPressureSum/(BARO_TAB_SIZE - 1);
    calibratingB--;
    return 0;
  }

because there is no reason to calculate an alt without the stabilization of moving average baroHistTab[] and baroGroundPressureSum . It lasts around 10s.

however, accZoffset needs to be right updated just before take off, and it can't be updated if return0; is present during the alt calibration.
=> if you arm the multi before the end of alt calibration, there will be a permanent accZ offset which explains what you encountered.
if you arm the multi after lets say 15 or 20s after power up (or after disarm/arm steps), no problem.

simple fix: remove return 0; in IMU.ino

Code: Select all

  if(calibratingB > 0) {
    baroGroundPressure = baroPressureSum/(BARO_TAB_SIZE - 1);
    calibratingB--;
  }


Thank you Alex, this solved the problem, no more shoot in the air :-)

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Altitude Hold improvement solution

Post by Mystic3D »

More packs, problem for sure solved!
Thank you!

Meedoosa
Posts: 4
Joined: Sat Dec 22, 2012 3:22 pm

Re: Altitude Hold improvement solution

Post by Meedoosa »

Also tested the 1316 and baro works better than with 2.1.

http://www.youtube.com/watch?v=G-16IOc3pZI

Christian

defkom
Posts: 9
Joined: Sun Jan 06, 2013 10:27 am

Re: Altitude Hold improvement solution

Post by defkom »

Hi guys,
this might be a little OT, but:
I had some bumps when turning on Altitude hold last night (Horizon Mode + Mag was turned on before hitting baro).
Is this a regular Baro line in the GUI? The Copter is sitting on my bench. The baro is covered with open cell foam.
Or anything wrong here?
I tested it with multiple power sources (4,8V Pack, UBEC, USB Power, With/without surge Protecor, with BT and/or GPS unplugged - no significant changes in behavoir)

Board is Crius AIOP Rev 1.1, Multiwii R1311.

Cheers
Christian
Attachments
GUI Readings Benchtest
GUI Readings Benchtest

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 am unclear about new calibration startup procedure:

1-After PowerUp MWC, is any clue that AccZ calibration, giro calibration and baro calibration ended succesfully?
2- If we calibrate manually giro, yaw left- throttle down- pitch back, any other calibrations are made?

How can i be shure that sensors are well calibrated when taking off?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Post by Alexinparis »

defkom wrote:Hi guys,
this might be a little OT, but:
I had some bumps when turning on Altitude hold last night (Horizon Mode + Mag was turned on before hitting baro).
Is this a regular Baro line in the GUI? The Copter is sitting on my bench. The baro is covered with open cell foam.
Or anything wrong here?
I tested it with multiple power sources (4,8V Pack, UBEC, USB Power, With/without surge Protecor, with BT and/or GPS unplugged - no significant changes in behavoir)

Board is Crius AIOP Rev 1.1, Multiwii R1311.

Cheers
Christian


Hi,
With the baro accuracy, it's impossible to have a perfect flat line.
Your baro line is normal. With your board, as long as you are in the range +/- 50cm, the situation is normal.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Post by Alexinparis »

dramida wrote:I am unclear about new calibration startup procedure:

1-After PowerUp MWC, is any clue that AccZ calibration, giro calibration and baro calibration ended succesfully?
2- If we calibrate manually giro, yaw left- throttle down- pitch back, any other calibrations are made?

How can i be shure that sensors are well calibrated when taking off?


Hi,
1) after a power up, there are:
- baro calibration - no end indication / it lasts around 15s
- gyro calibration - end indicated via a blink LED indicator
- accZ offset for baro compensation is determined automatically just before you arm the multi, no need to worry about this.
2) manual gyro calibration implies also: a reset home position and a small baro calibration (less than 1s)

>How can i be shure that sensors are well calibrated when taking off?
- baro line should indicate an average of 0 meter
- all gyros should be 0 with no movements
- on a flat surface, accX/AccY = 0 and accZ = accAG for your sensor (generally 256 or 512)
- on a flat surface mag Z positive and magX/Y in the rangne of [-150;+150]

Post Reply