Improving Altitude Hold Performance

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
wektorx
Posts: 8
Joined: Sat Aug 27, 2011 8:08 pm

Re: Improving Altitude Hold Performance

Post by wektorx »


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

Re: Improving Altitude Hold Performance

Post by LenzGr »

Good job! Looks promising. I'm waiting for my Sonar (Devantech SRF02) to arrive, so I can toy around with this, too...

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

Re: Improving Altitude Hold Performance

Post by mahowik »

Hi Wektor!

It looks very stable! Could you share your changes for alt-hold?
integrator IMU? own PID regulator? or just more precised baro?

thx-
Alex

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

Re: Improving Altitude Hold Performance

Post by nhadrian »

Hi,

With my mini hexacopter now alt old looks like works perfectly:
http://www.youtube.com/watch?v=CMAQJtvvILM

I have an idea if we should set up some pre-compensation into the altitude hols algorythm depenging on degrees of leaning. I think for example, 1% increase in throttle value for every 1 degree of lean (compared to level). That should be useful for fast forward flying during alt. hold (and later for GPS RTH, etc... when copter is not in level mode.

BR
Adrian

ankimo
Posts: 30
Joined: Fri Jan 20, 2012 7:31 am

Re: Improving Altitude Hold Performance

Post by ankimo »

Hi Adrian

Is it very stable :o
Is a version DEV_20120121?
Is a PID parameter sharable?

regards
kazz

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

Re: Improving Altitude Hold Performance

Post by nhadrian »

No, I didn't succed with 20120121 since it miss the VEL parameters. For good At hold behaviour you have to syncronize the Accelerometers (VEL) and the barometers (ALT) working.
Now I use the same parameters as EOSBandi (we tested them out together):

ALT P: 2.5, I: 0,023, D: 0
VEL: P: 4,1, I: 0,020, D: 40

I'm on dev20111220 now.

BR
Adrian

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

Re: Improving Altitude Hold Performance

Post by nhadrian »

One thing I have to note is that after I activate the altitude hold, copter slowly climbs 1-1,5 m up and that will be the setpoint. It is independent from the altitude. I couldn't figure out what causes this behaviour, maybe something in the calculations... any idea???

BR
Adrian

KeesvR
Posts: 194
Joined: Fri May 27, 2011 6:51 pm
Location: The Netherlands

Re: Improving Altitude Hold Performance

Post by KeesvR »

I have the same result with only Alt I can't get better result as 3 meter.
I go back to Dev 20111220, the best I get with Alt and Vel was 1 meter with also the same PID's, need some more tuning .

dodecopter
Posts: 35
Joined: Fri Jan 21, 2011 7:37 am

Re: Improving Altitude Hold Performance

Post by dodecopter »

moin,

i just tested my new quad with all PIDs stock setting, using 1.9, trusted accZ.

flies awesome stable , and even altitude hold works almost fine.

i covered the bmp085 breakout with 5mm foam, and put it into a shrink tube..seems to keep the wind away from baro quite good.


altitude hold works between 0,5 and 1m - not really bad , makes me happy :mrgreen: .

but maybe it could be improved.


now the copter doesnt overshoot , and changes altitude slow., kind of "soft"-hovering... almost impossible for me to hold height manually in that calm way... just could be little more accurate, f.e. max 0,5m


need some help there with settings, as i do not know, what ALT and VEL pids do , or which effect this settings have.

which settings in VEL + ALT should i change. to get the height-difference smaller, or make reactions smaller or fasterr?

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

Re: Improving Altitude Hold Performance

Post by Alexinparis »

nhadrian wrote:One thing I have to note is that after I activate the altitude hold, copter slowly climbs 1-1,5 m up and that will be the setpoint. It is independent from the altitude. I couldn't figure out what causes this behaviour, maybe something in the calculations... any idea???

BR
Adrian


Hi,

I think to VEL PID works, but there is still something wrong about the Z velocity estimation.
Without moving, there is a constant non null velocity estimation which I think explains "slowly climbs 1-1,5 m up and that will be the setpoint"
Velocity variation are however well estimated that's why the overall function seems to work.

On the last dev, I removed temporarily the VEL PID because of this.

On the version of today (03/02), I tried to introduce a velocity estimator based on the actual position and refreshed every 0.5s
This velocity is used to decreased the overall throttle correction.
This way, it prevents any over amplification and growing oscillation problem. The throttle correction is just lowered when the Z velocity increases.
This can be tuned via ALT D Term.

Could someone tests the last dev ALT HOLD function with default PID ?
It works fine in my living room with MS baro and BMA180 ACC. (1 meter range)

capt
Posts: 54
Joined: Wed Jan 19, 2011 10:54 pm

Re: Improving Altitude Hold Performance

Post by capt »

Good results with alt hold, I started with Ankimo's PID's. Holds within 1 meter in my garage. It did seem to want to increase in dev amplitude after some time? Will try some more test outside with better wx.
Ver 1.9
Acc Z trusted
Tricopter
750KV motors 10x3.8 APC props
3s 22Mah on seeduino mega controller WMP, bma020, hmc5883l, bmp085.
Flashed HK SS 30 ESC's
Attachments
alt.JPG

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Improving Altitude Hold Performance

Post by ziss_dm »

Hi Alex,

I think to VEL PID works, but there is still something wrong about the Z velocity estimation.
Without moving, there is a constant non null velocity estimation which I think explains "slowly climbs 1-1,5 m up and that will be the setpoint"


I think it is pretty normal, as a baro sensor have jitter +- 1m this produces changes in Z velocity. If you "fix" baro alt, it would produce zero velocity without movement. ;)

regards,
ziss_dm

pm1
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: Improving Altitude Hold Performance

Post by pm1 »

Hi,
I tested the altidude with the 1.9 version and the new dev release. I am not very happy at the moment with the results. The only thing which works more or less predictable for me is a low altitude P term.

My findings at the moment are:

- If I do not average the BaroAlt, I get ridiculous velocity changes due to the jitter in BaroAlt. I get several dm in 25ms. I think, I cannot use these values for any senseful correction. This jitter is still there, if the quad is lying on the ground without any movement and the sensor is covered with foam.

- I coded a moving average to the BaroAlt measurements. I need about 40 samples (1s?), that the values come into a stable range of +- 1-2 dm. The downside is: If I now lift the quad 2 m from the ground, it lasts 1-2 seconds until the value shows correctly the new altitude.

With this in mind, I can't see, how the actual algorithms could work *reliably* at all. At the moment I see only good results by chance. Therfore I am looking for another strategy:

1. supress unwanted vertical movements by a PID on the vertical part of the ACC-values. If the starting vertical velocity is low, I got good stability here even in some windy conditions
2. Correct the height due to changes of averaged BaroAlt very slowly with sampling intervals of about 1s. Up to now, this is only an idea, not realized:

The correction of the height shall be corrected with two different components:

1. bring the quad relatively fast to the desired height
- get altitude error (base: averaged BaroAlt)
- Increase/decrease the throttle for a fixed amount for a limited time. This time is proportiional to the altitude error.
- wait 1 second
- start over again, get altitude error

2. Increase/decrease the throttle permantly in very small steps after each iteration above (I-Term)

Best regards
Peter

capt
Posts: 54
Joined: Wed Jan 19, 2011 10:54 pm

Re: Improving Altitude Hold Performance

Post by capt »

Tested my Tri outside tonight in a light breeze and alt hld was not good, unpredictable "zoom climbs"10-15 meters. Baro is covered in foam under a heli 450 canopy so it might be creating pressure in there while hovering in outside in light wind. Alt control in stable mode only was pretty solid.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: Improving Altitude Hold Performance

Post by mr.rc-cam »

Tested my Tri outside tonight in a light breeze and alt hld was not good, unpredictable "zoom climbs"10-15 meters.

Regarding the unexpected "zoom climbs" that is a common symptom of ACC sensor overload. If you have enabled the TRUSTED_ACCZ (via the config.h defines) then you should retest your ACC sensor to verify that it is indeed a trusted device. With TRUSTED_ACCZ, a vibration free model is essential too. If your TRUSTED_ACCZ define is disabled then please ignore my comments. :)

I've not made any progress (worthy of sharing) with my improvements to the ALT-HOLD feature. Hopefully one of you brilliant programmers comes to the rescue soon!

- Thomas

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Improving Altitude Hold Performance

Post by ziss_dm »

Hi,

[qoute]
Tested my Tri outside tonight in a light breeze and alt hld was not good, unpredictable "zoom climbs"10-15 meters.
[/quote]

There are couple possibilities:
1) acc overloading, as mr.rc-cam mentioned.
2) too high pids, indoor you usually can set higher pids than outdoor.
3) the CF not stabilized, sometimes it takes up to the minute to stabilize.

@pm1
All averaging filters are not effective with baro. Try something non-linear, like median filter (take 5 samples, sort, take 3rd value). You also can increase BW of sensor (currently it takes 2 samples per second, as I remember)

regards,
ziss_dm

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

Re: Improving Altitude Hold Performance

Post by Magnetron »

pm1 wrote:Hi,
I tested the altidude with the 1.9 version and the new dev release. I am not very happy at the moment with the results. The only thing which works more or less predictable for me is a low altitude P term.

My findings at the moment are:

- If I do not average the BaroAlt, I get ridiculous velocity changes due to the jitter in BaroAlt. I get several dm in 25ms. I think, I cannot use these values for any senseful correction. This jitter is still there, if the quad is lying on the ground without any movement and the sensor is covered with foam.

- I coded a moving average to the BaroAlt measurements. I need about 40 samples (1s?), that the values come into a stable range of +- 1-2 dm. The downside is: If I now lift the quad 2 m from the ground, it lasts 1-2 seconds until the value shows correctly the new altitude.

With this in mind, I can't see, how the actual algorithms could work *reliably* at all. At the moment I see only good results by chance. Therfore I am looking for another strategy:

1. supress unwanted vertical movements by a PID on the vertical part of the ACC-values. If the starting vertical velocity is low, I got good stability here even in some windy conditions
2. Correct the height due to changes of averaged BaroAlt very slowly with sampling intervals of about 1s. Up to now, this is only an idea, not realized:

The correction of the height shall be corrected with two different components:

1. bring the quad relatively fast to the desired height
- get altitude error (base: averaged BaroAlt)
- Increase/decrease the throttle for a fixed amount for a limited time. This time is proportiional to the altitude error.
- wait 1 second
- start over again, get altitude error

2. Increase/decrease the throttle permantly in very small steps after each iteration above (I-Term)

Best regards
Peter


Hi pm1,
I have implemented a moving avarage algorithm for gyros, accs, baro and servogimbal. Here I talk about it: viewtopic.php?f=8&t=1190

I think that for baro the moving average is less performer, I think that we need something like weight moving average, the last 3-4 value mesured in exponential formula and about 10-12 before calculated as a simple average.
I am at work for this.

pm1
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: Improving Altitude Hold Performance

Post by pm1 »

@ziss_dm
You also can increase BW of sensor (currently it takes 2 samples per second, as I remember)

Is currentTime not microsends? Then I would get about 20 samples per second, as far as I see in the code (BMP085).

@Magnetron
I have implemented a moving avarage algorithm for gyros, accs, baro and servogimbal. Here I talk about it: ...

I saw. I took the code for my tests ;)

Best regards
Peter

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Improving Altitude Hold Performance

Post by ziss_dm »

Hi pm1,

You right, ~20 samples per second.

regards,
ziss_dm

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

Re: Improving Altitude Hold Performance

Post by timecop »

I dunno if this has been mentioned yet, but the temperature sensor on BMP085 is pretty noisy. This is what actually adds most of the error into the measurements, ya know. Apparently if you sample temperature at say 4Hz and lowpass/average 4 samples to 1Hz, and then use that value as input to more often running pressure measurements, error reduces to 0.3m RMS, which is actually better than datasheet. FYI.

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

Re: Improving Altitude Hold Performance

Post by Magnetron »

pm1 wrote:@Magnetron
I have implemented a moving avarage algorithm for gyros, accs, baro and servogimbal. Here I talk about it: ...

I saw. I took the code for my tests ;)

Best regards
Peter


ah ah ah - do you think the code is well done?
Could you tell me what kind of tests are you doing?

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

Re: Improving Altitude Hold Performance

Post by Magnetron »

I am reading some code for implemetation of baro readings...
In the specific something about MS5611...
Alex could you give me some attention on this argument?
I think that was someting wrong in the overall variable declarations.
I try to explain me.
In the multiwii.pde I read the pressure and BaroAlt variable declaration like this:

Code: Select all

static int32_t  pressure;
static int16_t  BaroAlt;


In the sensors.pde there is the routine that calculate pressure for:

Code: Select all

void i2c_MS561101BA_Calculate() {
  int64_t dT   = ms561101ba_ctx.ut.val - ((uint32_t)ms561101ba_ctx.c[5] << 8);  //int32_t according to the spec, but int64_t here to avoid cast after
  int64_t off  = ((uint32_t)ms561101ba_ctx.c[2] <<16) + ((dT * ms561101ba_ctx.c[4]) >> 7);
  int64_t sens = ((uint32_t)ms561101ba_ctx.c[1] <<15) + ((dT * ms561101ba_ctx.c[3]) >> 8);
  pressure     = (( (ms561101ba_ctx.up.val * sens ) >> 21) - off) >> 15;
}

I think that is a formal error assign a uint32_t to a int64_t due to riductive approssimation...

At the baro calculation:

Code: Select all

void Baro_update() {
  if (currentTime < ms561101ba_ctx.deadline) return;
  ms561101ba_ctx.deadline = currentTime;
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz, MS5611 is ok with this speed
  switch (ms561101ba_ctx.state) {
    case 0:
      i2c_MS561101BA_UT_Start();
      ms561101ba_ctx.state++; ms561101ba_ctx.deadline += 15000; //according to the specs, the pause should be at least 8.22ms
      break;
    case 1:
      i2c_MS561101BA_UT_Read();
      ms561101ba_ctx.state++;
      break;
    case 2:
      i2c_MS561101BA_UP_Start();
      ms561101ba_ctx.state++; ms561101ba_ctx.deadline += 15000; //according to the specs, the pause should be at least 8.22ms
      break;
    case 3:
      i2c_MS561101BA_UP_Read();
      i2c_MS561101BA_Calculate();
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 443300.0f; //decimeter
      ms561101ba_ctx.state = 0; ms561101ba_ctx.deadline += 35000;
      break;
  }
}

So the code operates a
BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 443300.0f; //decimeter
calculation that involves variable in INT 32 format (pressure) with floating point constants and after calculation the value become a 16 bit INT variable... I think this is a variable formal error that introduce approssimation and cutting value error...
In conclusion we try to assign something like BaroAlt, that was an INT at 16bit variable a result deriving from a calculation that involves a 32 bit INT variabile that became a poor accuracy conversion. The data readed from barometer must be (for my opinion) in FLOAT. I think a very high resolution readings are operated in Fabio Varesano sample code on his website at this link: http://www.varesano.net/blog/fabio/ms56 ... ts-results.

Do you think?

pm1
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: Improving Altitude Hold Performance

Post by pm1 »

@dongs
I dunno if this has been mentioned yet, but the temperature sensor on BMP085 is pretty noisy.

That's a new info for me. If I assume, that the sensor is normally surrounded by foam and perhaps a housing, making a temperature average of 1-5s+ seems to be absolutely reasonable: I will try that out next weekend. But this would indicate an error in the temperature compensation. I already had the temperature as a debug variable. I will put that in again...

@Magnetron
Could you tell me what kind of tests are you doing?

I' am coding the algorithm I described some posts ago. I am testing with various averaging methods tot get a reasonable fast and smooth reaction of he sensor.

mr.rc-cam
Posts: 457
Joined: Wed Jul 27, 2011 11:36 pm

Re: Improving Altitude Hold Performance

Post by mr.rc-cam »

I dunno if this has been mentioned yet, but the temperature sensor on BMP085 is pretty noisy.

Thanks for disclosing this issue. For sure, I was very excited to hear about it. So last night I did some experiments with the sensor's temperature readings. On my BMP085 there is some short term (within 10 sec window) data noise that is perhaps a couple bits. With averaging I was able to make the short term temperature data more stable. Unfortunately I did not notice a change in the altitude stability, at least nothing that showed any significance during my late night tests attempts.

What was interesting to me was the long term temperature stability. I could see that the temperature data was on a cycle that slowly rose and fell over a period of a couple minutes. The data would vary as much as 30 points. I had my house HVAC turned off and the MWC was resting on the workbench far away from heat sources such as desk lamps. The location of the BMP085 is not near any components that get warm. So it seems that the BMP085 can detect insanely small changes in temperature. I have no idea if this characteristic matters, but it is interesting info.

FWIW, during my experiments with the EagleTree ALT-V4 altimeter sensor (which is more precise/stable than the BMP085) I achieved slightly better Alt-Hold performance compared to the BMP085. However, it seems to me that the Achilles heel is the Baro PID code, not the messy sensor data. Although improvements to the BMP085 sensor data are welcome, I suspect that any significant Alt-Hold solutions at this point will mostly involve the main code.

- Thomas

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Improving Altitude Hold Performance

Post by Hamburger »

not my realm at all; I just stumbled over some code for the bmp085 sensor used in a smartphone.
Maybe this can be of some help? If not, just blame it on my ignorance of the subject.

code found here git://gitorious.org/freerunner-navigati ... bmp085.git

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

Re: Improving Altitude Hold Performance

Post by timecop »

Hamburger wrote:not my realm at all; I just stumbled over some code for the bmp085 sensor used in a smartphone.
Maybe this can be of some help? If not, just blame it on my ignorance of the subject.

code found here git://gitorious.org/freerunner-navigati ... bmp085.git


Looks useless, basically 1:1 implementation of reference code, and not even any useful usage of the results - they just return pressure/temp as raw values. Sorry :)

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: Improving Altitude Hold Performance

Post by marbalon »

Here is my implementation and tests.

viewtopic.php?f=7&t=363&start=90#p8876

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

Re: Improving Altitude Hold Performance

Post by Alexinparis »

Magnetron wrote:I am reading some code for implemetation of baro readings...
In the specific something about MS5611...
Alex could you give me some attention on this argument?
I think that was someting wrong in the overall variable declarations.
I try to explain me.
In the multiwii.pde I read the pressure and BaroAlt variable declaration like this:

Code: Select all

static int32_t  pressure;
static int16_t  BaroAlt;


In the sensors.pde there is the routine that calculate pressure for:

Code: Select all

void i2c_MS561101BA_Calculate() {
  int64_t dT   = ms561101ba_ctx.ut.val - ((uint32_t)ms561101ba_ctx.c[5] << 8);  //int32_t according to the spec, but int64_t here to avoid cast after
  int64_t off  = ((uint32_t)ms561101ba_ctx.c[2] <<16) + ((dT * ms561101ba_ctx.c[4]) >> 7);
  int64_t sens = ((uint32_t)ms561101ba_ctx.c[1] <<15) + ((dT * ms561101ba_ctx.c[3]) >> 8);
  pressure     = (( (ms561101ba_ctx.up.val * sens ) >> 21) - off) >> 15;
}

I think that is a formal error assign a uint32_t to a int64_t due to riductive approssimation...

At the baro calculation:

Code: Select all

void Baro_update() {
  if (currentTime < ms561101ba_ctx.deadline) return;
  ms561101ba_ctx.deadline = currentTime;
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz, MS5611 is ok with this speed
  switch (ms561101ba_ctx.state) {
    case 0:
      i2c_MS561101BA_UT_Start();
      ms561101ba_ctx.state++; ms561101ba_ctx.deadline += 15000; //according to the specs, the pause should be at least 8.22ms
      break;
    case 1:
      i2c_MS561101BA_UT_Read();
      ms561101ba_ctx.state++;
      break;
    case 2:
      i2c_MS561101BA_UP_Start();
      ms561101ba_ctx.state++; ms561101ba_ctx.deadline += 15000; //according to the specs, the pause should be at least 8.22ms
      break;
    case 3:
      i2c_MS561101BA_UP_Read();
      i2c_MS561101BA_Calculate();
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 443300.0f; //decimeter
      ms561101ba_ctx.state = 0; ms561101ba_ctx.deadline += 35000;
      break;
  }
}

So the code operates a
BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 443300.0f; //decimeter
calculation that involves variable in INT 32 format (pressure) with floating point constants and after calculation the value become a 16 bit INT variable... I think this is a variable formal error that introduce approssimation and cutting value error...
In conclusion we try to assign something like BaroAlt, that was an INT at 16bit variable a result deriving from a calculation that involves a 32 bit INT variabile that became a poor accuracy conversion. The data readed from barometer must be (for my opinion) in FLOAT. I think a very high resolution readings are operated in Fabio Varesano sample code on his website at this link: http://www.varesano.net/blog/fabio/ms56 ... ts-results.

Do you think?


Hi,
I think there is something wrong in the MS code somewhere, because the alt could be different between 2 power on/power off session. I think it's related to the configuration register reading at the init step.

About you assumption about different size variable casting, I don't see any problem. You should understand that working on small variables is more efficient on 8 bit procs.
A cast will always keep the LSB. If you are sure the relevant LSB won't overflow the dest variable, there is no worries.
You can see huge use of this principle in the PID section of multiwii.pde in order to gain some speed efficiency.

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: Improving Altitude Hold Performance

Post by marbalon »

I need to agree that there is something wrong in current MS5611 driver. I read datesheet and there is second level temperature compensation for temperatures lower than 20C and -15C. This is not solved yet but will test it today. But precision is absolutely enough, I only want to get more samples to clear noise, and I think it is possible because dalays are to big. I'm really impressed with BMP085 with my new implementation. I will tune up baro readings fix some problems and I think it can work even better than now.

neverfree
Posts: 2
Joined: Thu Feb 09, 2012 10:50 am

Re: Improving Altitude Hold Performance

Post by neverfree »

hello
what is the difference between our mwiiboard and the naza fc? why naza fc has a very good altitude hold and altitude hold is difficult for our wiiboard ?is the barometer sensor different? or is the firmware very different?
thank you

marbalon
Posts: 107
Joined: Thu Aug 18, 2011 10:59 am

Re: Improving Altitude Hold Performance

Post by marbalon »

neverfree wrote:hello
what is the difference between our mwiiboard and the naza fc? why naza fc has a very good altitude hold and altitude hold is difficult for our wiiboard ?is the barometer sensor different? or is the firmware very different?
thank you


Answer is simple - this is commercial product and many people work on this function more then people here. People here join together and try to code functionality step by step in free time. But we will see what we can do.

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Improving Altitude Hold Performance

Post by rbirdie001 »

Hi guys,
today the weather a little bit improved (temperature went over freezing point and wind under 3 m/s) so I went again out with my tri (50cm motor to center, 800kV motors, 10x4.7props, ~1kg AUW, crius board, (BM085) and MWC1.9) and again tried to adjust altitude hold PID. I was unable to make altitude hold stable but with the values ALT 3.0-0.024-0 VEL 4.2-0-30 it was in the beginning at least not so crazy. For about 20 seconds was altitude in the range of 2 meters but then oscilations started to amplify and also responses at direction change (from down to up and opposite) were more and more dramatic, finally I had to disable AH and hardly avoided a crash. Idea: what about limiting of maximal influence of AH to avoid crazy reactions at bigger altitude errors? Questions: is there any improvement in DEV versions against 1.9? Is there any progress in the close view? (This forum now looks a little sleepy, unfortunately I'm not a coder so can help only with testing...)
Roman

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

Re: Improving Altitude Hold Performance

Post by Alexinparis »

rbirdie001 wrote:Questions: is there any improvement in DEV versions against 1.9? Is there any progress in the close view?

Yes improvements are huge regarding alt hold.

Y.Mita
Posts: 46
Joined: Thu Sep 15, 2011 11:25 pm

Re: Improving Altitude Hold Performance

Post by Y.Mita »

I tested 20120225 version on my quad copter today.
Congraturation every one!!!
It's works with almost default parameter! Stable +-0.5m with defalut parameter!
Great!!!

I thank's to all developer of MultiWii!

My copter:
Arduino Pro mini + DroTek IMU 10DOF_MS
ESC Turnigy Plush 10A
MOTOR Turnigy 2204-14T 19g Quad X
Prop. 7x3.5 GWS CW + copy CCW
Berg stamp 4L modified as serial PPM
flight wheigt 795g

setting ITG3200 LPF_98HZ and TRUSTED_ACCZ

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: Improving Altitude Hold Performance

Post by mbrak »

hi

can someone post the p-i-d values for ALT and VEL?

just tested the dev 20120225 and after switch level,baro and mag ON a had a beautiful flip into the green grass...... wonderful!

javitech
Posts: 8
Joined: Mon Feb 28, 2011 10:19 pm

Re: Improving Altitude Hold Performance

Post by javitech »

mbrak

i have same problem, with 20120225 and baro, must be something wrong, i recomend u go back to 20120219... that version works nice for me... ALT HOLD, and LEVEL.

Y.Mita
Posts: 46
Joined: Thu Sep 15, 2011 11:25 pm

Re: Improving Altitude Hold Performance

Post by Y.Mita »

mbrak wrote:hi

can someone post the p-i-d values for ALT and VEL?

just tested the dev 20120225 and after switch level,baro and mag ON a had a beautiful flip into the green grass...... wonderful!


Yesterday was very windy day, and I couldn't recognize stable or not because I was controlling against wind.
Tonight, not windy, I retry the flight with switch on level takeoff, and few second after takeoff, suddenly one shake the copter! After one shake, its became stable again. I had 3 times of this expeience just after change battery. I think some bugs in 20120225 code.

This is my baro stable settings of quad.
ROLL/PITCH 4.0, 0.030, 23 RATE 0.00
YAW 8.5, 0.000, 0 RATE 0.00
ALT 2.0, 0.015, 5 VEL 0.0, 0.000, 0
no GPS
LEVEL 9.0, 0.045, 100 MAG 4.0
RC RATE 0.90 EXPO 0.65

And I change my hex to 20120225, too.
It's baro is stable same as quad, but when I switch on GPS HOME, its suddenly going to
auto landing mode! ( not crash but supprised me! )

My hex
Flyduino Mega + FreeIMU 0.3.5 MS + MediaTek MT3329 GPS (DIYDRONES) modified code to 10Hz
ESC Hobbyking Super Simple 10A
MOTOR Turnigy 2204-14T 19g Hex X
Prop. 7x3.5 GWS CW + copy CCW
Berg stamp 4L modified as serial PPM
flight wheigt 980g

setting ITG3200 LPF_98HZ and TRUSTED_ACCZ
parameters
ROLL/PITCH 4.0, 0.030, 23 RATE 0.00
YAW 8.5, 0.000, 0 RATE 0.00
ALT 2.3, 0.015, 5 VEL 0.0, 0.000, 0
GPS 2.3, 0.000, 5
LEVEL 9.0, 0.045, 100 MAG 4.0
RC RATE 0.90 EXPO 0.65

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: Improving Altitude Hold Performance

Post by mbrak »

hi y.mita

many thanks for posting your PIDs. it quite useful for me to know how to modify the values.

yesterday i tested the dev20120225 with nearly the same PIDs like your quad. ALT 2.5, 0.025, 0 VEL 0.0, 0.000, 0
the first flight with calm wind was quite very stable. wow i thought that was very very good.

in the late afternoon i tested it with the following PIDs ALT 3.0, 0.024, 0 VEL 4.2, 0, 30
i found this values somewhere here in the ALT Thread.
with this values the copter shake very hard and did a fast flip into the green .....

my result ist to go back to the first values and never try the VEL PID again :)

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

Re: Improving Altitude Hold Performance

Post by Noctaro »

hey,
i did test lastest svn release of dev20120225, altitude hold works quite nice! Stable within 50cm also outdoors :) (not to much wind)
Also drift in stable mode is quite controllable.
Using standart PID and activated ITG600/BMA180/BMP085
greetz Noc

edit: with additional weight of the gopro i guess it needs some P tuning as it seems to have not enugh power for pulling up. (alt hold)

Quad-X ~ 1,3 kg
10x3,6 APC Props
Robbe Roxxy 2827-34 Motors
DYS 30A ESC

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

Re: Improving Altitude Hold Performance

Post by mahowik »

Hi guys!

Could someone tell me if you have success of using alt-hold and bmp085 with official 2.0 version? And which PIDs in this case?
Or it works good only with MS5611?

thx-
Alex

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

Re: Improving Altitude Hold Performance

Post by timecop »

Works fine for me on default settings ~

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

Re: Improving Altitude Hold Performance

Post by mahowik »

dongs wrote:Works fine for me on default settings ~

it works for all cases below or only for 1st point?
1. when you stabilize copter vertically and then turn on alt hold
2. during the vertical up/down movements
3. during the flight
4. with wind

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Improving Altitude Hold Performance

Post by Bledi »

1,3 and 4

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Improving Altitude Hold Performance

Post by Tazzy »

mahowik wrote:Hi guys!

Could someone tell me if you have success of using alt-hold and bmp085 with official 2.0 version? And which PIDs in this case?
Or it works good only with MS5611?

thx-
Alex


Works perfekt with default settings in 2.0 here is a smal video how it works.

http://youtu.be/ji5NMmqzE5U

// Tazzy

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

Re: Improving Altitude Hold Performance

Post by mahowik »

Tazzy wrote:Works perfekt with default settings in 2.0 here is a smal video how it works.

In which range it keeps altitude?
From video it's not so clear...

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Improving Altitude Hold Performance

Post by Tazzy »

mahowik wrote:
Tazzy wrote:Works perfekt with default settings in 2.0 here is a smal video how it works.

In which range it keeps altitude?
From video it's not so clear...

about +- 0.5 m in high altitude with some wind and better in low if it is no wind

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

Re: Improving Altitude Hold Performance

Post by dramida »

Sometimes my copter jumps a meter or so in alt hold, those jumps would be filtered if there were some AccZ taken into account.
When do we integrate the Z acceleration for a better smoothing of baro values in altitude hold?

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Improving Altitude Hold Performance

Post by Bledi »

I saw that the 2 factors that create big jumps are the wind if the baro is not protect and the temperature difference between sun and shadow

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: Improving Altitude Hold Performance

Post by Katch »

I'm getting very different results from the 2 main sensors we use.

BMP085 on default pids - quite good now as long as I am 20m up or so it holds within 1 or 2m

MS5611 on the same frame same settings and same acc etc - yoyos slowly loosing altitude before I have to turn off Alt Hold to avoid landing.

EDIT - hmmm just been out in the field for another 2 packs and the MS5611 was holding really really well. Haven't changed anything and it was holding hands free at about 10 feet off the ground.

Post Reply