Altitude Hold improvement solution

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

Re: Altitude Hold improvement solution

Postby defkom » Sun Jan 27, 2013 8:10 pm

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

Board is Crius AIOP Rev 1.1, Multiwii R1311.

Cheers
Christian


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


Hi alex,
Ok thanks for the fast reply.
Am i correct in assuming 0,50 means 50cm?
So a line between 0,60 an 1,1 e.g. would be Ok, right?
Coming to accuracy: which board is better ? (enough outputs for y6, gimbal, spektrum satelite would be awesome, gps, bt etc...)
Cheers christian
defkom
 
Posts: 9
Joined: Sun Jan 06, 2013 10:27 am

Re: Altitude Hold improvement solution

Postby Alexinparis » Sun Jan 27, 2013 8:32 pm

defkom wrote:
Ok thanks for the fast reply.
Am i correct in assuming 0,50 means 50cm?
So a line between 0,60 an 1,1 e.g. would be Ok, right?
Coming to accuracy: which board is better ? (enough outputs for y6, gimbal, spektrum satelite would be awesome, gps, bt etc...)
Cheers christian


yes 0.50 means 50cm
a line between 0,60 an 1,1 is normal after some time (because the atmospheric pressure which is used to determine the altitude is also not constant)
>Coming to accuracy: which board is better ? (enough outputs for y6, gimbal, spektrum satelite would be awesome, gps, bt etc...)
any recent board with a mega 2560 should do the job
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Postby KasparsL » Fri Feb 08, 2013 10:23 am

I have a question about VARIO and altitude hold. Maybe I am missing something.

If I bring the copter to hoovering state and enable the baro, it will hold it and the vario will work as expected (until battery voltage doesnt drop until certain level).

But if I enable the baro at low RPM (below hoovering) I will not be able to take off or, if in air, will drop out of the sky (no mater what throttle position)!
If I enable baro at full throttle, I will not be able to bring the copter down (no mater what throttle position), it will continue to climb up!

Why it is working like that? Why the throttle control range is limited?

I am using dev1247. I have not seen any major changes in newer versions regarding this.
User avatar
KasparsL
 
Posts: 75
Joined: Wed May 16, 2012 3:31 pm

Re: Altitude Hold improvement solution

Postby Apdude58 » Fri Feb 08, 2013 3:43 pm

I'm running r1371 now. I haven't found any problems at all so far. The Alt Hold is amazing! Thanks guys.

@KasparsL - you really should move up to the newer r1371, then see if you still have the same problems.
Apdude58
 
Posts: 1
Joined: Thu Jan 31, 2013 2:46 am

Re: Altitude Hold improvement solution

Postby KasparsL » Sat Feb 09, 2013 7:10 pm

Apdude58 wrote:I'm running r1371 now. I haven't found any problems at all so far. The Alt Hold is amazing! Thanks guys.

@KasparsL - you really should move up to the newer r1371, then see if you still have the same problems.


I had a serious crash http://youtu.be/pwfPgkLNW2Y because tilting issue (broken 3 props, both landing gear and bended one arm). I have updated to version dev1317 ( i didnt before of lazyness - i have custom routines for navigation lights and redefined some output pins, different voltage dividers, etc). The issue I mentioned is gone there. Now I can take off with altitude hold enabled and disarm also.
But what abaut Vario? is it still there? It felt like switching hold Off-On-Off when I increase or decrease the throttle. I was not able to descent at 1m/s for example.
User avatar
KasparsL
 
Posts: 75
Joined: Wed May 16, 2012 3:31 pm

Re: Altitude Hold improvement solution

Postby KasparsL » Mon Feb 18, 2013 11:47 pm

Anoter question:
Altitude hold works good only if activated at hoowering throttle.
Isn't it possible to make altitude hold work without that?
In failsafe conditions it is a problem, because if for example you were flying in plain acro and then suddenly loose rx and "return to home" with alt hold is activated, not at hoovering throttle(at low or high throttle), copter will fly away or fall out of the sky!
User avatar
KasparsL
 
Posts: 75
Joined: Wed May 16, 2012 3:31 pm

Re: Altitude Hold improvement solution

Postby BRTZ » Sun Mar 03, 2013 2:19 pm

Hi,
Iam new and trying to turn on alt hold in my quad.
there is something I do not understand
Image
if my TX is on - Baro line seems to be very noisy and oscilates from 0 to 9,00 (left dg side)
if its off - the line flattens and vary from 0,00 - 0,70 only (right)
anyone have an idea how to solve the problem?
flying HK328P (BMP085) and MW R1356

thanks BRTZ
BRTZ
 
Posts: 2
Joined: Sun Mar 03, 2013 1:27 pm

Re: Altitude Hold improvement solution

Postby BRTZ » Mon Mar 04, 2013 8:45 am

OK. Problem solved (RX or antenas was too close to the board). It's enough to turn RX upside down - baro line becomes flat. Thanks anyway.
BRTZ
 
Posts: 2
Joined: Sun Mar 03, 2013 1:27 pm

Re: Altitude Hold improvement solution

Postby SvGuy » Tue Apr 02, 2013 7:58 pm

Hello. This is my first post here and I recently got my first mwc controller. I have a NAZA and a KK2 on two of my quads and they are working great. My only complaint with the KK2 is that it doesn't hold altitude. With the naza, I can ZOOM around the backyard at high speeds and it keeps the altitude really close. SO FUN!

My quad is a basic H design made of mostly aluminum. I have flown it with KK2 and Naza, and it flies great.
Turnigy Aerodrive SK3 - 2822-1090kv
12a SimonK esc's
8x4 balanced props
3s 1350 Lipo
my new controller, witespy FLIP with MS5611 baro (wrapped in open cell foam).
Multiwii, 2.2

I keep hearing about how great the multiwii is, so I bought a couple "FLIP" controllers with the MS5611 barometer from witespy a few weeks ago. Since then, I have spent MANY HOURS trying to make them work. These are the first MW flight controllers I've owned. I can see how these could be really powerful controllers because of all the options, but after hours and hours, I am still trying to get basic flying working. First, I would like to say I didn't know you needed to be an engineer to get these functional. Luckily I AM an engineer, and do have some arduino experience!

I have a ton of questions, but to stay on this topic, I'll keep it related to the altitude hold.

When I fly with the baro off, I have it flying close to the same as the KK2 (not quite as well but getting there). When I turn on the baro, take off and fly around, it's as if I have NO BARO whatsoever, and the quad bounces around even worse than with the baro off.

On accident, I noticed if I take off with the baro off, and then turn it on as I am ascending, it stops the quad from rising. The hold is not so good, but it's a start (I'm assuming I need to keep tweaking my PID settings.)

FOR ALT, I have PID: 1 / .01 / 20 right now.

1. I should be able to leave baro on all the time and when stick is centered, the software should hold my altitude, correct? How do make this baro function correctly?

2. Does anyone have any known working baro PID settings? I have scoured around and can't find anything that works for me. It holds for a bit then it will bounce around, then hold a bit, etc... I have been tweaking PID settings myself but have gone outside and in 30 times with nothing acceptable as of yet.

It doesn't seem like this should be that difficult? The naza holds altitude on every multirotor I've used it on, and I've never had to adjust anything on it. MWC users are always dogging the naza so I would expect better performance from the mw but I am sure frustrated right now.

Thanks in advance for any help you can provide,
Tom
SvGuy
 
Posts: 1
Joined: Tue Apr 02, 2013 6:42 pm

Re: Altitude Hold improvement solution

Postby Alexinparis » Thu Apr 04, 2013 10:01 am

SvGuy wrote:On accident, I noticed if I take off with the baro off, and then turn it on as I am ascending, it stops the quad from rising. The hold is not so good, but it's a start (I'm assuming I need to keep tweaking my PID settings.)

FOR ALT, I have PID: 1 / .01 / 20 right now.

1. I should be able to leave baro on all the time and when stick is centered, the software should hold my altitude, correct? How do make this baro function correctly?

2. Does anyone have any known working baro PID settings? I have scoured around and can't find anything that works for me. It holds for a bit then it will bounce around, then hold a bit, etc... I have been tweaking PID settings myself but have gone outside and in 30 times with nothing acceptable as of yet.

It doesn't seem like this should be that difficult? The naza holds altitude on every multirotor I've used it on, and I've never had to adjust anything on it. MWC users are always dogging the naza so I would expect better performance from the mw but I am sure frustrated right now.

Thanks in advance for any help you can provide,
Tom


With Multiwii, Alt Hold works great only when you activate it at your target alt, with a throttle value near the hover point.
Alt Hold switch should not stay on when you plan to change throttle.

It's not currently the best implementation, but things will evolve with a kind of vario mode.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Postby felixrising » Thu Apr 04, 2013 9:48 pm

You might like to look at some experimental code by Adrian "NHA", it's got some extra code with regards to vario. http://www.multiwii.com/forum/viewtopic.php?f=8&t=2965&start=160
felixrising
 
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold improvement solution

Postby iosonologio » Tue Sep 24, 2013 9:32 am

Hi everybody.
Well, let's just say that i started flying around last month, but i have some experience in arduino coding (and that's why i got to use multiwii).
I like the job that has been done with multiwii and i hope to be helpful in the future.

I was reading trough the Altitude hold code as of r1555. I noticed that, although the baroPressureSum is calculated quite often, the LPF for alt.EstAlt uses it only every 25ms.

I was wandering, did somebody took a look at the spectrum of the noise of the baro sensors? Are we fighting against long time drifts or still we could use more point in LPF for alt.EstAlt to increase stability even further?

Anyhow, does anybody have a fast way to provide me with a bunch of reading of different baro sensors (fast and unfiltered) to take a look at the noise spectra?

I have to admit i have not fully checked the timing of baro pressure sum and the LPF of the EstAlt.

Giovanni
iosonologio
 
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

Re: Altitude Hold improvement solution

Postby Alexinparis » Wed Sep 25, 2013 2:03 pm

iosonologio wrote:I was reading trough the Altitude hold code as of r1555. I noticed that, although the baroPressureSum is calculated quite often, the LPF for alt.EstAlt uses it only every 25ms.


not so often in fact.
in Sensors.cpp line 731, you can see (for MS baro) that a new pressure measurement in only available after 2x10ms (10ms to get the temperature + 10ms to get the raw pressure) + some ms due to task schedule management.

So we shouldn't be far from 25ms
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold improvement solution

Postby iosonologio » Fri Sep 27, 2013 12:22 pm

Yep.. i suspected so. I will test the actual code a deeply and see if it needs improvement :)
iosonologio
 
Posts: 13
Joined: Sun Sep 22, 2013 5:46 pm

Re: Altitude Hold improvement solution

Postby FHoevi » Tue Jun 10, 2014 8:34 am

When I release my copter from my hand it usually shows a heading-dependent ability to hold altitude which is not quite nice. But I think it is linked to the following lines of code (at least in MW 2.2 which I'm still using):

if (!f.ARMED) {
accZoffset -= accZoffset>>3;
accZoffset += accZ;
}
accZ -= accZoffset>>3;

Clearly, accZoffset is still updated even after the copter has been levelled and Acc has been calibrated successfully (which I do before any flight). But this could lead to errors in a situation as described above or if the sensors get calibrated on a level surface and the copter is moved to a non-level starting position afterwards. I would like to suggest to move that to the Acc calibration section where it should be to my taste.

If I make sure that the copter starts from the same position as where Acc has been calibrated properly the effect is not present and the copter holds altititude independent of heading and (with some limits) speed very well.

I think there's no real need for linking accZoffset calculation to f.ARMED but instead to calibratingA or one could use global_conf.accZero[YAW] directly.

What do you think?
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby happul3 » Tue Jun 10, 2014 5:29 pm

Calibrating on level surface followed to moving to non-level surface should not adversely affect validity of accZoffset. That value is affected only by acceleration. In other words, do not arm if copter it is not stationary. It may be helpful to you if you make slight modification to code: debug1=accZoffset and observe for yourself in multiwii gui how that particular variable responds to movement and position.

Personally, I'd prefer to leave the code the way it is. It provides more current and accurate accZoffset value, which is needed for very important inertial component of altitude hold. The only drawback is that copter must not move during arming, which is not really a problem for me - can't hold copter, radio and arm with my only two hands :)
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby FHoevi » Wed Jun 11, 2014 10:27 am

Well, earth's gravitational field is always acting on a copter, even if it's at rest. But if the acc vector at rest does not point into the right direction (i.e. down in the copter's frame, accX = 0, accY = 0, accZ = 1g equivalent) it does not work properly, especially if it is in a stationary state (nearly so when released from hand which is not really complicated with a strap around one's neck, as well as catching) but on a non-level surface. I already did what you suggested (monitoring accZoffset) and it really changes if the copter is not properly levelled, and that's the reason for potential problems for any code which uses this value. Usually this value should be rather close to 512 (depends on the sensor, e.g. for MPU6050) but it is not in situations as described below. And that could lead to errors while being airborne, especially if altitude gets estimated via a sensor fusion.

OK, I will apply changes accordingly in my own version and go for it.
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby happul3 » Wed Jun 11, 2014 7:52 pm

I don't have copter handy to verify experimentally at the moment, but as far as I remember the accZ is not supposed to change with orientation (at least when approximate math is in acceptable range?) The raw acc values are indeed affected by orientation relative to gravitational vector, but the accZ is supposed to be rotated properly and therefore independent of orientation. The following line of code may be illuminating:

// projection of ACC vector to global Z, with 1G subtructed
// Math: accZ = A * G / |G| - 1G
int16_t accZ = (accSmooth[ROLL] * EstG32.V.X + accSmooth[PITCH] * EstG32.V.Y + accSmooth[YAW] * EstG32.V.Z) * invG;
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby FHoevi » Wed Jun 11, 2014 8:40 pm

Right, that's what a mathematician calls projection, namely the acc vector gets projected onto the EstG32.V vector, both are floating objects. On a level surface EstG32.V.X and .Y are very close to zero, just EstG32.V.Z is equal to 512 which in turn is equal to acc_1G which is a sensor dependent constant. That's how it should be at rest. Now, at rest accSmooth[ROLL] and ...[PITCH] are zero, just accSmooth[YAW] is equal to the magic 512 again. Hence, the scalar product of these two vectors is 512 * 512, in the formula from above this gets divided by accZ_1G = 512, thus accZ = 512 in that case. So far, so good, in that case both vectors are pointing into the same direction (down to the earth's center of gravity) and both have the same length. But remember, the acc vector measures acceleration wrt. the copter's inertial frame. You already pointed out the important accZ = A * G / |G| - 1G, G stands for the "global" gravitation, i.e. measured in the earth's frame when at rest. accZ is just the part of the acc vector which points into that direction. 1G still needs to be subtracted, thus you finally have to subtract accZ_1G = 512 and that's currently the role of accZoffset if averaged while being at rest on a level surface.

Let's suppose that after proper acc calibration but right before arming the system your copter is tilted in Pitch and/or Roll direction by just 3 degrees due to a small stone under your copter's frame, for the z component the cosine is important: cos(3°) = 0.99862953, multiplied by 512 (desired value) and subtracted from 512 itself yields 0.7something which rounds to 1, so 511 instead of the desired 512. Now, in terms of accZ the accZoffset component corresponds to a different vector. So, it's not the direction (heading) which is important but the z component which is affected as well as long as not only heading gets changed between calibration and arming. In general that will make a difference and therefore it does not quite make sense to decouple accZoffset calc from acc calibration in general.
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby happul3 » Wed Jun 11, 2014 11:49 pm

I've just verified it with my copter: accZ is zero whenever copter is stationary, regardless of whether it is level or tilted 45 degrees. It only deviates from zero when the copter's vertical velocity is changing, exactly as intended by good people who wrote multiwii. Note that its primary use (the only use?) is in altitude hold mode, as main contributor to D-term. The change you were suggesting would therefore only affect althold mode and not in a good way.

Some additional details. Despite the label, the actual accZ variable is not displayed in multiwii config real time display (at least the version I am using). The raw ACC values are displayed instead (well, after smoothing). The mislabeled "Z" component is not accZ! Its one of accSmooth values, which are indeed providing acceleration values in copter's frame. The whole point of math involving EstG32's is to translate from copter's frame to global frame, which is what's needed for inertial "navigation".
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby FHoevi » Thu Jun 12, 2014 8:53 am

Exactly, the acc vector in the copter's inertial frame gets projected onto the estimated acceleration vector which lives in the earth's inertial frame. If the copter moves horizontally as seen in the earth's frame, the vertical part of this projection should be 1G. It is only differing from that if the copter's motion has a vertical (earth's frame) component, but that's exactly what you are interested in when it comes to AltHold after subtracting earth's constant gravitation. Absolutely right again, accZ in its final form is reduced by accZoffset, that's why it's zero at rest on a level surface after calibration. But now my point again, I think the detour with accZoffset is not necessary since after arming this value remains constant anyway (at 512?) and could easily be replaced by accZ_1G, a sensor specific constant. And right a third time, it is only interesting for AltHold as I was mentioning in the beginning. But again, at rest accZ is just the rebased acceleration in the copter's frame where rebasing means subtracting exactly 1G which is always present. As viewed from the copter the only linear forces which could act are a) gravitation (could be pointing into any direction in this frame) and b) the copter's own thrust which always only could point up or down in the copter's frame. The other forces/accelerations are angular ones (pitch, roll, yaw). Thus, at rest, the raw, smoothed value for acc_yaw you could see in real time is indeed the real one, it should indeed show the value of 1G pointing down. accZ measures only additional accelerations on top of the earth's gravitation which are acting on the copter.

Imagine the case if you did anything well before launch, accZ = 0, let the copter fly to a different location, get it down there and disarm. The accZoffset calculation starts over, leads to a different value for (almost) sure when arming again. But nothing fundamentally changed in the meantime but you lost control of accZoffset since you do not know whether the copter lifts off from levelled ground. The earth's gravitational field's direction certainly did not change in the meantime. But now, at least in terms of the AltHold mode, the copter "thinks" it was different. And that leads to problems in AltHold mode which I would like to point to. Just imagine the case if the bank/pitch angle were 90° when arming, accZOffset would be vanishing.

If you always arm at the same level place as where acc gets calibrated there should not be material problems. But the only thing I'm saying is that there may be if not. In my case there were such odd things happening but anything is fine after removing that accZoffset which, again, should be at 512 anyway. OK, I'm using a different signal for AltHold but the general principle is the same.

Now, the "raw" vertical acc value gets reduced by a value which actually is too small (512 * cos(tilt angle)). So, even if the copter is hovering the vertical component accZ is not equal to zero as it should be in that case, right? In the next step the vertical velocity gets estimated by numerically integrating a properly scaled accZ over time. The constant offset of accZ translates to an increasing offset or a drift of the vertical velocity vel. In the plain version of AltHold this value enters the "D" section of the AltHold PID, perhaps you lose a bit of the effect by all the applications of the deadband function like

//D
int16_t vel_tmp = vel;
applyDeadband(vel_tmp, 5);
BaroPID -= constrain(conf.D8[PIDALT] * vel_tmp >>4, -150, 150);

which cuts off potentially interesting information but which in turn could lead (after some tuning) to a more stable AltHold. But anyway, as the vel error piles up the D correction erroneously kicks in, the copter reduces throttle and goes down since it "thinks" its vertical velocity vel is too big. After a while P and I should kick in by lifting the copter again to reduce the error in respect of the desired altitude according to the barometrically measured value when the AltHold mode has beeen switched on. That means that instability enters the system even if the PID calibration for AltHold has been done thoroughly. The D correction to BaroPID from above is limited by +/- 150 but this could offset the similar range of initial BaroPID P values if the signs were opposite. Just the I correction could help in that case.
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby happul3 » Thu Jun 12, 2014 3:34 pm

FHoevi wrote:Just imagine the case if the bank/pitch angle were 90° when arming, accZOffset would be vanishing.


I think this particular quoted sentence provides perfect illustration of the point of confusion. To put it bluntly, contrary to your expectation, the accZOffset is not at all vanishing when copter is tilted 90 degrees and kept stationary at that angle. The accZOffset value is actually nearly the same (should be exactly the same with perfect hardware and non-approximate math) as it is when copter is level.

Digging a little deeper, you seem to think that the math yielding accZOffset causes it to scale with cosine of tilt angle. That is quite incorrect. What you are forgetting is that the calculation of accZ includes all *three* accsmooth outputs of accelerometer. So, when copter is tilted 90 degrees and the component that is confusingly labeled Z in real time display becomes small, one or two other components (confusingly labelled PITCH and ROLL) respectively increase, keeping actual accZ approximately constant.

I repeat my suggestion to see all this for yourself rather than speculate. It takes only few minutes to modify code to display accZ and accZoffset in debug variables, re-program your microcontroller, and see the responses to different tilt angles as you change orientation of copter by hand (obviously you can even arm/disarm it safely because the esc/motors do not need to be powered).
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby FHoevi » Thu Jun 12, 2014 4:08 pm

happul3, you are right, I'm deeply sorry.

In the situation above EstG32.V vector is changing accordingly, which could potentially lead to only minor effects due to rounding or sensor noise. At rest, irrespective of the copter frame's relation to the earth's one, both vectors are pointing down in the earth's frame.

But still, accZoffset should be 512 * 8, right?
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby happul3 » Thu Jun 12, 2014 5:01 pm

I am glad we got this sorted out.

And, yes, the accZoffset is approximately 512*8. For example, last time I examined it, it varied from 4980-4982 when copter was level, and 4960-4963 when tilted 90 degrees.
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby Benik3 » Thu Jun 12, 2014 5:39 pm

Or just wait to Q4 2014 http://www.murata.com/new/news_release/2014/0129/index.html :)
This could be really useful in quads...
User avatar
Benik3
 
Posts: 25
Joined: Mon Aug 26, 2013 1:06 pm

Re: Altitude Hold improvement solution

Postby happul3 » Thu Jun 12, 2014 6:56 pm

Limited experimentation I did suggests that the limiting factor in purely barometric altitude control is NOT the sensor itself but the pressure transients produced by props and airspeed (that includes both wind and horizontal movement of copter). As hang glider pilot I have experienced firsthand just how unstable air is, especially close to ground and in presence of wind. That's without having 4 props chopping air in immediate vicinity of sensor.

I'd even go as far as say that even an ideal pressure sensor would not allow normally-dimensioned copter to stay within, say, 5 cm window vertically. Therefore it is the job of accelerometer to provide short-timescale altitude control (and baro sensor's jobs is to correct for long-timescale ACC drift and unavoidable inaccuracies in numeric integration of accZ).
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby FHoevi » Fri Jun 13, 2014 7:10 am

Yep, I could confirm that. In my copter there's a MPU6050 and an MS5611 which are working in tandem for AltHold in the way happul3 indicated. It's really working well.

Yesterday in the evening with slightly bumpy wind conditions I did another test flight after I commented out that accZoffset stuff and simply subtracted acc_1G instead from the accZ value. Anything works fine even if the wind is blowing dynamically in strength and direction and the copter is not parallel to the ground due to GPSHold switched on (needs to compensate for significant wind drag).

But I'm a bit surprised by this statement about accZoffset:

happul3 wrote:...it varied from 4980-4982 when copter was level, and 4960-4963 when tilted 90 degrees.


At rest and levelled and after properly calibrating acc my MPU6050 provides a value of exactly 4096 = 8 * acc_1G, rarely floating by +/- 1. When I tilt the copter this value changes by roughly 10 like in happul3's statement. Question one: Does that mean that acc_1G in that case is equal to 622/623? I was not able to find a sensor type in Sensor.ino which should go with acc_1G set to this value. Question two: If accZoffset value indeed depends on the tilt angle as indicated above one should indeed make sure that the UAV is levelled when arming since the most common application of AltHold is when it's flying (or hovering in case of a copter) horizontally, right?

Just to add: I did a couple of experiments with BMP085 as a barometric sensor. The noise of this sensor is way too big to produce a stable signal, even if coupled with an appropriate acc sensor. But I think that's not new to this forum.
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby Benik3 » Fri Jun 13, 2014 5:03 pm

Maybe we should start to search solution from the second side - from HW.
These Barometers are very noisy, so what to try to use some external one. Also advantage of the external sensor is, that you can put it out of the board on some better place, where it will be protected from the wind and not affected by heat of the board or heat from sun.

What e.g. LPS331AP? It has I2C connection, you can buy this baro for 12$ on eBay.
It has internal averaging of pressure to eliminate the noise and of course also built-in temperature sensor...
2Pa RMS (about 20cm)
http://www.st.com/web/en/resource/technical/document/datasheet/DM00036196.pdf

Or better LPS25H, which has even 1Pa RMS (about 10cm resolution).
But it's hard to find them to buy...

The best what I found is XP-6000CA with 0,3Pa
and BME280 with 0,2Pa

(BMP085 has 3Pa RMS in ultra high res BTW)
Last edited by Benik3 on Fri Jun 13, 2014 8:03 pm, edited 1 time in total.
User avatar
Benik3
 
Posts: 25
Joined: Mon Aug 26, 2013 1:06 pm

Re: Altitude Hold improvement solution

Postby happul3 » Fri Jun 13, 2014 7:39 pm

FHoevi wrote:
But I'm a bit surprised by this statement about accZoffset:

happul3 wrote:...it varied from 4980-4982 when copter was level, and 4960-4963 when tilted 90 degrees.


At rest and levelled and after properly calibrating acc my MPU6050 provides a value of exactly 4096 = 8 * acc_1G, rarely floating by +/- 1. When I tilt the copter this value changes by roughly 10 like in happul3's statement. Question one: Does that mean that acc_1G in that case is equal to 622/623? .


Nope, it only means that I did not bother to calibrate ACC for no-flying experiment. And, yes, I am sure everyone would agree that it is preferable to launch when copter is close to being level. But, in practice, I do not see a problem taking off from 10 - 20 degrees incline (note however that I never fly in acro mode).

By the way, I do agree that BMP085 is substantially inferior to MS5611 for our application. My point about baros is that there is a performance ceiling. Once baro sensor gets there, further improvement in sensor quality is pointless because of pressure transients inherent to flying, and especially powered flying. I think that MS5611 is already there, but if someone demonstrates better performance solely due to better baro sensor, I'll happily accept that.
Last edited by happul3 on Fri Jun 13, 2014 7:47 pm, edited 1 time in total.
happul3
 
Posts: 44
Joined: Mon Apr 21, 2014 1:54 am

Re: Altitude Hold improvement solution

Postby FHoevi » Fri Jun 13, 2014 7:46 pm

I could only recommend MS5611, have a look at this: http://www.meas-spec.com/downloads/MS5611-01BA03.pdf. It's also very cheap, you could even buy a whole 10DOF IMU breakout board for about 15€, like the GY-86 (MPU6050 acc/gyro, MS5611baro, HMC5883 mag).

And I support happul3's opinion about the performance ceiling, even after properly surrounding it with tissue or something like that. In a moving copter there are disturbances by floating air. But nevertheless, it is possible to hold altitude within a small range as long as you fly at moderate speeds.

accZoffset again: I still don't see the point about it if acc_1G could be used.
FHoevi
 
Posts: 11
Joined: Sun Dec 29, 2013 5:55 pm

Re: Altitude Hold improvement solution

Postby ravid824 » Mon Aug 17, 2015 8:20 am

mahowik wrote:Hi guys!
http://www.youtube.com/watch?v=nePjkz_leR8

It's:
- take into acount inclinations
- doesn't see horizontal accelerations
- keeps altitude on the wind (tried with 15-20km/h)
- has very good reaction for pushing
- has accuracy +/-20..40cm in calm weather according to baro accuracy
- has accuracy about +/-1m during the flights... flying 4 packs with initial PIDs without any tuning because I was too satisfied with results ;)

Alex


Alex,
Multiwii ALT Hold code is bad. Your video looks promising.
What code base you have applied the changes on? I am using 2.4 it is OK?

Anyone else tried Alex improvement and have any success?

David
ravid824
 
Posts: 26
Joined: Wed Jul 29, 2015 3:59 am
Location: California

Previous

Return to Software development

Who is online

Users browsing this forum: No registered users and 1 guest

cron