Improving Altitude Hold Performance
Re: Improving Altitude Hold Performance
First test of althold with MPXH6115 + ADS1114 + MCP40D18-103 https://picasaweb.google.com/1159846768 ... 3772034674 and new FC https://picasaweb.google.com/1159846768 ... Controller and custom MWC
http://www.youtube.com/watch?v=_VuE-Wkn ... ature=plcp
wektor
http://www.youtube.com/watch?v=_VuE-Wkn ... ature=plcp
wektor
Re: Improving Altitude Hold Performance
Good job! Looks promising. I'm waiting for my Sonar (Devantech SRF02) to arrive, so I can toy around with this, too...
Re: Improving Altitude Hold Performance
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
It looks very stable! Could you share your changes for alt-hold?
integrator IMU? own PID regulator? or just more precised baro?
thx-
Alex
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
Hi Adrian
Is it very stable
Is a version DEV_20120121?
Is a PID parameter sharable?
regards
kazz
Is it very stable
Is a version DEV_20120121?
Is a PID parameter sharable?
regards
kazz
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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
BR
Adrian
Re: Improving Altitude Hold Performance
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 .
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 .
-
- Posts: 35
- Joined: Fri Jan 21, 2011 7:37 am
Re: Improving Altitude Hold Performance
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 .
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?
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 .
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?
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Improving Altitude Hold Performance
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)
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
Hi Alex,
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
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
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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.
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
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
[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
Re: Improving Altitude Hold Performance
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.
Re: Improving Altitude Hold Performance
@ziss_dm
Is currentTime not microsends? Then I would get about 20 samples per second, as far as I see in the code (BMP085).
@Magnetron
I saw. I took the code for my tests
Best regards
Peter
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
Re: Improving Altitude Hold Performance
Hi pm1,
You right, ~20 samples per second.
regards,
ziss_dm
You right, ~20 samples per second.
regards,
ziss_dm
Re: Improving Altitude Hold Performance
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.
Re: Improving Altitude Hold Performance
pm1 wrote:@MagnetronI 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?
Re: Improving Altitude Hold Performance
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:
In the sensors.pde there is the routine that calculate pressure for:
I think that is a formal error assign a uint32_t to a int64_t due to riductive approssimation...
At the baro calculation:
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?
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?
Re: Improving Altitude Hold Performance
@dongs
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
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.
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.
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Improving Altitude Hold Performance
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.
Re: Improving Altitude Hold Performance
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.
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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.
-
- Posts: 178
- Joined: Fri Apr 01, 2011 10:32 pm
- Location: Czech Republic, Prague
Re: Improving Altitude Hold Performance
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
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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Improving Altitude Hold Performance
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.
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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!
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!
Re: Improving Altitude Hold Performance
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.
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.
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
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
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
Re: Improving Altitude Hold Performance
Works fine for me on default settings ~
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
1,3 and 4
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
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...
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
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?
When do we integrate the Z acceleration for a better smoothing of baro values in altitude hold?
Re: Improving Altitude Hold Performance
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
Re: Improving Altitude Hold Performance
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.
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.