Altitude Hold improvement solution

nhadrian · Post by **nhadrian** » Fri Jan 11, 2013 7:42 pm

Hi all,

********UPDATE**********
A have just noticed that an official r1311 is released. I checked and there were some small changes (ie. log values or governor or LCD changes) wich were not included in my r12 since I made my merge from _shared previously.
So I merged my code with the official r1311 now, and replaced the attachments!!!!
**********END*************

it's time to introduce my r12 code, based on r1311 Multiwii release!
I have included the autoland in Failsafe_RTH mode too, I even tested it! After landing, RPM will decrease than motors stops.

I completelly reworked the code, removed many redundant parts and also solved some major problems (many thanks to Alexinparis for pointing on them), now all my mods can be used independently too!!!

I have attached two zip files:
1) the COMPLETE code contains all my mods and should be used.
2) 5 more files for developers, with independent functions it is more easy to understand my changes and codes:
- BASIC - only minor changes but nothing new functions (only some led-flasher addons)
- FAILSAFE_ALT - only this function is included
- FAILSAFE_RTH - only this function is included
- VARIO_ALT_MODE - only this function is included
- RTH_ALT_MODE - only this function is included

I tried to explain all parametes correctly in config.h so please read carefully before use any of my mods.
Also please note that even if I made many-many flights during this period, hidden BUGs could be remained, especially with different setups (ie. I2C_GPS) so first test functions with EXTREME CAUTION!
For FAILSAFE functions please take time for previously described Failsafe testing procedure before first take-off!
Please keep in mind that all my functions assumes a well-tuned configuration with all important PIDs tuned (incl. GPS HOLD, BARO, ANGLE, etc...)

I hope you'll enjoy my code, I wish you all safe landings, and looking for any experiences!

BR
Adrian

Mystic3D · Post by **Mystic3D** » Sat Jan 12, 2013 7:15 am

Amazing work!
Please forgive a noob question.
How do code changes like this get into "official" releases from a process/approval perspective?

nhadrian · Post by **nhadrian** » Sat Jan 12, 2013 8:05 am

Hi,

************UPDATE**************
viewtopic.php?f=8&t=2371&p=29042#p29042
*************END*****************

It depends on the developers.
I sent all of these to Alexinparis, if he decides that any part of my job is stable/good/safety enough and also the resource consumption (memory/cycle time/etc) is good enough, he'll put it in.

BR
Adrian

ps.: since I'm not a qualified programmer, I'm sure some of my changes could be written on a more "elegant" way... but the idea itself looks like works!

dramida · Post by **dramida** » Sat Jan 12, 2013 1:02 pm

Adrian, in latest MWC R13_complete, in config.h, confuses me:

I might be wrong, but i see two sets of configs regarding RTH:

firstly:

Code: Select all

    //#define FAILSAFE_RTH_MODE             // if GPS present and ready, copter starts RTH when signal lost. When signal is back, control is back again. 
    #define FAILSAFE_RTH_VARIO    100     // in cm/s - vario for RTH function for failsafe  
    #define FAILSAFE_RTH_ALT      700     // in cm   - minimum RTH altitude for failsafe. If copter is higher than this, it will keep altitude.
    #define FAILSAFE_RTH_HOME     300     // in cm   - home altitude for RTH, copter will descend to this altitude and wait.
    #define FAILSAFE_RTH_DELAY    15      // in s    - safety delay, after reaching HOME altitude, it'll land in FAILSAFE_ALT_MODE when safety delay terminates.

and at the end

Code: Select all

 

    //#define RTH_ALT_MODE             // define RTH custom approach height  
    //#define RTH_KEEP_ALT             // if the altitude is higher than the RTH_ALT, copter maintains that altitude instead of descending to target - according to Dramida's request
    #define RTH_VARIO      100       // in cm/s  - vario used for reaching target altitudes during RTH - lower limit is 25 cm/s!
    #define RTH_ALT        700       // in cm    - altitude during approach
    #define HOME_ALT       350       // in cm    - altitude after reaching home position

nhadrian · Post by **nhadrian** » Sat Jan 12, 2013 2:54 pm

Yes, because the failsafe rth can be set up independently...

Ie. You can set higher altitude for failsafe rth than for normal. Or different vario...

Br
Adrian

subaru4wd · Post by **subaru4wd** » Sat Jan 12, 2013 9:53 pm

I downloaded and setup this build for my Board. I connected using the GUI & went to setup my flight modes and noticed there were already flight modes programmed. So I tried to clear them and it would not let me. I was able to add to the flight mode programming, but I could not remove what was originally there.

I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1

nhadrian · Post by **nhadrian** » Sun Jan 13, 2013 7:20 am

subaru4wd wrote:I downloaded and setup this build for my Board. I connected using the GUI & went to setup my flight modes and noticed there were already flight modes programmed. So I tried to clear them and it would not let me. I was able to add to the flight mode programming, but I could not remove what was originally there.

I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1

Hi,

could you please share a screenshot about these flight modes? I can't understand clearly what you are talking about. You mean BOX items are already checked?
also, please give me the type of your controller (MEGA, 328p), the copter type and the sensor board. I didn't modified any part of the EEPROM file, so it is really strange.

There is one more thing. If you power on multiwii only without RX, and connect to gui, and Failsafe is uncommented (enabled), the ANGLE and MAG will shown as active (green), that's because when in failsafe, these functions are enabled automatically. That is because there is no valid RX data. If you turn on RX too, they must disappear in case are not selected by BOXes.

Regarding ro r9, that was much less completed than r13, although the part of headfree was not touched in the code. You wrote it didn't worked at all, that means you couldn't activate the function, or activated but not worked as it should?

BR
Adrian

subaru4wd · Post by **subaru4wd** » Sun Jan 13, 2013 6:29 pm

Sorry Adrian. I should have provided you with all the information

I am using this board here: http://witespyquad.gostorego.com/flight ... oller.html (easier than typing a list of spec's) flying on my X-Quad

I can't understand clearly what you are talking about. You mean BOX items are already checked?

Yes exactly. I should have got a screenshot, but the last 4 flight modes (BEEPER, LEDMAX, LANDLIGHT, HEADADJ) all had boxes marked at random. They all had multiple boxes checked for all 4 AUX channels too. I tried to uncheck them and write to the board, and the boxes remained marked. I could mark unmarked boxes, and successfully write to the board, but I could not remove the originally marked boxes.

This was all done with the board powered by a LiPo, so the RX was powered and my TX was active. And I have failsafe commented out in config.h, I am more interested in your improvements to AltHold right now, and not so much RTH.

With R9 & Heading Hold I was activating the function with my TX Switch but the aircraft did not act as if it were in headsfree mode. I Tried a couple times by orientating the board in different positions and booting it up. However I did not look at my 3DR telemetry while flying, so I am not 100% the board had activated HeadsFree mode.

nhadrian · Post by **nhadrian** » Sun Jan 13, 2013 7:57 pm

Thanks for detailed description.

That's really interresting indeed. I never had anything like this. Today I tested my code on a small arduino nano board (328p) with a 10DOF panel attached temporarily.
I uploaded many variations and tested to write/read EEPROM many times but I still couldn't reproduce this issue.
And this also presents with my r13? If yes, could you please try the official r1311 from download page on MWI repo?
Also, could you send your config.h in PM? I'd check, maybe you use something which I never had uncommented before and there is something interference...

I had once a similar behaviour with my older config on a Quadrino board around MWI 1.9-2.0 long time go, I don't know the reason till now, but I made a full EEPROM reset with an EEPROM reset sketch and disappeared.

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

Mystic3D · Post by **Mystic3D** » Sun Jan 13, 2013 10:23 pm

Tried 2.2 r1311 on a Avatar Tri., Alt Hold works great with default PID's. POS hold also works much better. High winds like 15 mph and held its own within a few meters

jgrouse · Post by **jgrouse** » Mon Jan 14, 2013 2:25 am

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 · Post by **jgrouse** » Mon Jan 14, 2013 3:17 am

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 · Post by **subaru4wd** » Mon Jan 14, 2013 4:27 am

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 · Post by **nhadrian** » Mon Jan 14, 2013 6:41 am

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 · Post by **wilco1967** » Mon Jan 14, 2013 9:17 pm

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:

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 · Post by **schott1984** » Tue Jan 15, 2013 5:25 am

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 · Post by **nhadrian** » Tue Jan 15, 2013 6:18 am

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 · Post by **nhadrian** » Tue Jan 15, 2013 6:35 am

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

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

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

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

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 · Post by **Eric** » Tue Jan 15, 2013 9:29 am

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

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

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

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

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 · Post by **nhadrian** » Tue Jan 15, 2013 1:38 pm

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

schott1984 · Post by **schott1984** » Tue Jan 15, 2013 2:41 pm

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 · Post by **wilco1967** » Tue Jan 15, 2013 9:23 pm

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

dramida · Post by **dramida** » Wed Jan 16, 2013 6:04 pm

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 · Post by **albertoLG** » Thu Jan 17, 2013 6:11 pm

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 · Post by **nhadrian** » Thu Jan 17, 2013 6:52 pm

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.

nhadrian · Post by **nhadrian** » Thu Jan 17, 2013 6:54 pm

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 · Post by **albertoLG** » Thu Jan 17, 2013 8:04 pm

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 · Post by **nhadrian** » Thu Jan 17, 2013 9:19 pm

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

Alexinparis · Post by **Alexinparis** » Thu Jan 17, 2013 10:13 pm

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 · Post by **subaru4wd** » Fri Jan 18, 2013 12:28 am

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 · Post by **Mystic3D** » Fri Jan 18, 2013 6:22 am

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 · Post by **albertoLG** » Fri Jan 18, 2013 7:26 am

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 · Post by **albertoLG** » Fri Jan 18, 2013 9:42 am

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 · Post by **Alexinparis** » Fri Jan 18, 2013 10:24 am

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 · Post by **albertoLG** » Fri Jan 18, 2013 12:13 pm

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 · Post by **Mystic3D** » Fri Jan 18, 2013 3:55 pm

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 · Post by **Deet** » Sat Jan 19, 2013 12:15 am

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

dramida · Post by **dramida** » Sat Jan 19, 2013 12:38 am

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 · Post by **copterrichie** » Sat Jan 19, 2013 12:42 am

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

Mystic3D · Post by **Mystic3D** » Sat Jan 19, 2013 1:11 am

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 · Post by **nhadrian** » Sat Jan 19, 2013 6:25 am

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 · Post by **nhadrian** » Sat Jan 19, 2013 6:45 am

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 · Post by **albertoLG** » Sat Jan 19, 2013 8:10 am

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 · Post by **Alexinparis** » Sat Jan 19, 2013 3:31 pm

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 · Post by **albertoLG** » Sat Jan 19, 2013 4:10 pm

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

Frosty3k · Post by **Frosty3k** » Sat Jan 19, 2013 5:17 pm

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 · Post by **copterrichie** » Sat Jan 19, 2013 5:32 pm

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 · Post by **Mystic3D** » Sat Jan 19, 2013 6:40 pm

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 · Post by **Frosty3k** » Sat Jan 19, 2013 6:56 pm

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 · Post by **copterrichie** » Sat Jan 19, 2013 7:15 pm

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.