Page 11 of 12

Re: Altitude Hold improvement solution

Posted: Mon Jan 14, 2013 2:25 am
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.

Re: Altitude Hold improvement solution

Posted: Mon Jan 14, 2013 3:17 am
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.

Re: Altitude Hold improvement solution

Posted: Mon Jan 14, 2013 4:27 am
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

Re: Altitude Hold improvement solution

Posted: Mon Jan 14, 2013 6:41 am
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

Re: Altitude Hold improvement solution

Posted: Mon Jan 14, 2013 9:17 pm
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 !

Re: Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 5:25 am
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.

Re: Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 6:18 am
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.

Re: Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 6:35 am
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

Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 9:29 am
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.

Re: Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 1:38 pm
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

Re: Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 2:41 pm
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!

Re: Altitude Hold improvement solution

Posted: Tue Jan 15, 2013 9:23 pm
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...

Re: Altitude Hold improvement solution

Posted: Wed Jan 16, 2013 6:04 pm
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...

Re: Altitude Hold improvement solution

Posted: Thu Jan 17, 2013 6:11 pm
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

Re: Altitude Hold improvement solution

Posted: Thu Jan 17, 2013 6:52 pm
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.

Re: Altitude Hold improvement solution

Posted: Thu Jan 17, 2013 6:54 pm
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).

Re: Altitude Hold improvement solution

Posted: Thu Jan 17, 2013 8:04 pm
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

Re: Altitude Hold improvement solution

Posted: Thu Jan 17, 2013 9:19 pm
by nhadrian
in r1315 there are changes in the MS5611 code.
You should try the official r1313 from multiwii repo download site.

Re: Altitude Hold improvement solution

Posted: Thu Jan 17, 2013 10:13 pm
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.

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 12:28 am
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"

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 6:22 am
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.

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 7:26 am
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

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 9:42 am
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

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 10:24 am
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.

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 12:13 pm
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

Re: Altitude Hold improvement solution

Posted: Fri Jan 18, 2013 3:55 pm
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%

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 12:15 am
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 12:38 am
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 12:42 am
by copterrichie
A really Good Throttle Curve is required here, over and out.

Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 1:11 am
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.

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 6:25 am
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 6:45 am
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 8:10 am
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 3:31 pm
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 ?

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 4:10 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 5:17 pm
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

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 5:32 pm
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

Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 6:40 pm
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.

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 6:56 pm
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...

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 7:15 pm
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. :)

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 7:16 pm
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..

Re: Altitude Hold improvement solution

Posted: Sat Jan 19, 2013 11:16 pm
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--;
  }

Re: Altitude Hold improvement solution

Posted: Sun Jan 20, 2013 1:49 am
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.??

Re: Altitude Hold improvement solution

Posted: Sun Jan 20, 2013 7:50 am
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 :-)

Altitude Hold improvement solution

Posted: Sun Jan 20, 2013 3:05 pm
by Mystic3D
More packs, problem for sure solved!
Thank you!

Re: Altitude Hold improvement solution

Posted: Mon Jan 21, 2013 7:17 pm
by Meedoosa
Also tested the 1316 and baro works better than with 2.1.

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

Christian

Re: Altitude Hold improvement solution

Posted: Sun Jan 27, 2013 1:58 pm
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

Re: Altitude Hold improvement solution

Posted: Sun Jan 27, 2013 6:34 pm
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?

Re: Altitude Hold improvement solution

Posted: Sun Jan 27, 2013 7:10 pm
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.

Re: Altitude Hold improvement solution

Posted: Sun Jan 27, 2013 7:22 pm
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]