Improving Altitude Hold Performance

[mr.rc-cam]

I understand that the altitude hold feature does not work for everyone. For sure, it doesn't work for me. I'm using firmware V1.8 (dev20110714). My baro sensor is a BMP085. My quad is 22" motor-to-motor diameter, 50 ounces AUW.

I don't have expertise with PID firmware optimization, but I do have reasonable C coding experience. So I've gone through the baro functions to see if I could notice anything unusual. No doubt others have done this too. I can confirm that the BMP085 I/O routines are fine (they meet the data sheet timing requirements). The altitude conversion routines are fine too.

But I noticed that my Baro data was very unstable/noisy. Because the sensor is used in the 3X over-sample mode it should provide 0.25 meter resolution, but the noisy data seems to comprise the integrity. For example, when the baro function is enabled the AltHold variable often latches a randomly noisy value. On my model this causes a significant throttle change when the feature is enabled. I tamed this problem by adding a simple low pass filter (averaging) function to the pressure data. See source file filters.pde

Using some debug code I watched the PID values that are calculated in the altitude hold code section. I found that the VEL PID's dominated the ALT PID values and so I really never could see the effects of the altitude sensing when it reached the throttle code. I was surprised to find that reducing the VEL PID's to zero also disables the Altitude hold feature. I'm not sure if this was intentional, but certainly something to consider when setting the ALT and VEL PID values in the GUI.

To allow me to see the ALT PID debug data I simply commented out the VEL PID code. I found that the ALT's P-term was very good (note: my debug testing used the averaged pressure data from my filter routine). I found that it had good resolution, seemed reasonably stable, and so it appears good enough for what we need.

However, the calculated D term was always zero, not matter how quickly I moved the model up and down. So this term seems to need some work.

The I term has an unusual problem. It integrates fine with positive accumulated errors but the expected negative error values do not have much effect on it (value does not decrement very well). So it eventually has a significant data bias. I tried a variety of I value settings without success.

With the velocity code removed, I flew with just the altitude hold P-term (I and D were zero'd in the GUI due to their problems). I was able to hover an entire pack at low altitude without touching the throttle. However, with just the P term being used (I and D are zero'd) the model yo-yo oscillates up and down, especially when hit with some wind. But it was working!

Long story short, I'm not sure if any of this information helps with the altitude hold improvements. Optimizing the PID code is a bit out of my league, but I am interested in doing what I can to help solve the problem. If anyone has any comments, or has some working beta code to share, then please chime in.

- Thomas

[Covax]

Very interesting, Thomas! Subscribe!

[UndCon]

Good work and inestigation!

I have not yet connected the BMP085 I have @home - but if this issue gets sorted I might give it a go.

//UndCon

[brucedjones]

Thanks for the run down mr rc cam!

I'm not experienced in coding stuff like this but I do understand to some extent (and with extra help from your work) what is going on. From your investigation it sounds to me like the code is very much unfinished for altitude hold.

I've been wondering myself whether or not the altitude hold can incorporate z data from the accelerometer as well. We know the baro is going to be noisy, and the causes of this noise ranges from the manageable (magnetic interference, vibration) to the unmanageable (local pressure/temperature variation etc). We also know that if the copter moves along the z axis by any significant amount then we *should* be able to see an indication of this in the accelerometer data. The way I see this working is to maintain altitude to within a range of baro values, with altitude correction only occuring where accelerometer data correlates to a change in the baro value... Is this sensible?

[mr.rc-cam]

The way I see this working is to maintain altitude to within a range of baro values, with altitude correction only occuring where accelerometer data correlates to a change in the baro value... Is this sensible?

Assuming it is practical, augmenting the baro data with the Z accel data would be a cherry on top. Something like this would be best handled by the velocity PID rather than the altitude PID with the ability to have them work together (similar to how the Mag compass works with the gyro). However, from my experiments the baro sensor's data has sufficient precision to provide pleasing altitude hold performance. My fingers are crossed that the PID guru's soon tackle the ALT code and unleash their magic

Edit:
I'm going to look at the code again to see if I can make more progress. I think the problem with the I and D terms is due to the integer math and a bit more precision may help. Or so I hope. After all, it's only code, so how hard could it be?

[Wayne]

Alt. hold is working OK for me. Stock PIDs too.
I wonder if most problems are with how the Baro is mounted.
Mine is double foam taped to the underside of my Paris Bd. The board is mounted inside a firm plastic sandwich container, lid down. The only holes in the container are two 10mm holes in the lid for the ESC wires. The container is painted black.
Now to get it to hold firm I let the copter acclimate out in the sun for about 10 min. Then fly to the point I want to hover and hold there for a count of five or so. I then get the copter to start a slight drop, flip the Baro switch and within a meter or two it will stop hard and stay there.
It helps if the copter is in almost perfect trim also. If you have to hold yaw or bump the sticks a lot it looses hold.
As for the baro noise, I noticed that when inside the house I can see the fan running in the other room (with the sandwich container off). I bet that outside where I fly the Baro noise is a lot lower (container on).
Wayne
P.S. I know it’s working as after holding a minute or two I turn off the Baro and it drops right away.
Dev.: 0714

[Alexinparis]

Hi,

Using some debug code I watched the PID values that are calculated in the altitude hold code section. I found that the VEL PID's dominated the ALT PID values and so I really never could see the effects of the altitude sensing when it reached the throttle code. I was surprised to find that reducing the VEL PID's to zero also disables the Altitude hold feature. I'm not sure if this was intentional, but certainly something to consider when setting the ALT and VEL PID values in the GUI.

Yes, it was true before the last adaptation by ziss.
The principle was to adapt first the velocity PID and aftet the ALT PID.
I suppose It's the way how cascading PID should work.

To allow me to see the ALT PID debug data I simply commented out the VEL PID code. I found that the ALT's P-term was very good (note: my debug testing used the averaged pressure data from my filter routine). I found that it had good resolution, seemed reasonably stable, and so it appears good enough for what we need.

I'm convinced too we can do something very good, even with this noisy baro.
The current estimator is based on a complementary filter and takes into account the acceleration measurement for short term variation. In order to increase the smoothness, it's possible to increase the CF weight.
Maybe some other adaptations like removing spike could increase the accuracy, but I'm not sure it's needed.

However, the calculated D term was always zero, not matter how quickly I moved the model up and down. So this term seems to need some work.

Yes for sure. D term can really be used.

The I term has an unusual problem. It integrates fine with positive accumulated errors but the expected negative error values do not have much effect on it (value does not decrement very well). So it eventually has a significant data bias. I tried a variety of I value settings without success.

With the velocity code removed, I flew with just the altitude hold P-term (I and D were zero'd in the GUI due to their problems). I was able to hover an entire pack at low altitude without touching the throttle. However, with just the P term being used (I and D are zero'd) the model yo-yo oscillates up and down, especially when hit with some wind. But it was working!

I managed too to find a good settings with a PI ALT loop yesterday
The key was to lower a lot P.
Enough accurate to fly a full pack in a 2m range without altitude variation amplification.
I will post in few days a video about this. and probably the 1.8

[mr.rc-cam]

The I term has an unusual problem. It integrates fine with positive accumulated errors but the expected negative error values do not have much effect on it (value does not decrement very well).

I spent more time watching debug values and found that the I term is working. So pardon my confusion.

I wonder if most problems are with how the Baro is mounted.

Anything is possible, but I don't think it is an issue in my case. My IMU board is mounted on a silicone gel pad (feels like a freshly made gummy bear). The Paris board it sits on is grommet mounted too. There's LC filtering on the baro's analog power and a dedicated 3.3V linear VReg. I've shielded the baro's vent hole from light to prevent the photoelectric issues and some filter foam over the hole also damps air motion. Overall I think I've got good protection, but I never say never.

As for the baro noise, I noticed that when inside the house I can see the fan running in the other room (with the sandwich container off).

Good point. The indoor tests need to be done with care. When I want ideal conditions I turn off the fans and HVAC system. Even so, the baro data noise I see is persistent but it is sufficiently Gaussian that it might be more of a aesthetic issue rather than a data problem.

The principle was to adapt first the velocity PID and aftet the ALT PID. I suppose It's the way how cascading PID should work.

Ok, sounds like everyone already knew this, but it surprised me. I think long term it would be nice to allow them to work independently. But for now, to test the Altitude hold I've removed the VEL's PID code. Hopefully this isn't a bad idea, but it does make it much easier to observe what the ALT PID's are doing to the throttle without being dominated by the VEL's contribution.

I managed too to find a good settings with a PI ALT loop yesterday
The key was to lower a lot P.
Enough accurate to fly a full pack in a 2m range without altitude variation amplification.
I will post in few days a video about this. and probably the 1.8

That is awesome!

[ziss_dm]

Hi mr.rc-cam,

Thanks for releasing V1.8! I've been using the earlier V1.8 (dev 20110714) on a piggish (50 ounce) Quad and wasn't having good success with the Altitude Hold. So the latest V1.8 definitely had me excited. But unfortunately after two days of PID experimentation the altitude hold is still not working well on my model. It is about the same as the earlier 1.8 dev version, which is unexpected because I can see some significant changes in the latest release's baro PID code.

How is your progress? Have you used this instructions to setup PIDs: viewtopic.php?f=7&t=363&start=30?
And if yes, which step actually failed?

regards,
ziss_dm

[mr.rc-cam]

How is your progress? Have you used this instructions to setup PIDs: viewtopic.php?f=7&t=363&start=30?

I am unable to get the altitude hold to work correctly. Nothing exciting to report other than my quad does not hold its altitude (will vary several meters). I have tried your instructions too (didn't experience any "failed" steps).

I've noticed that some users that are reporting success have zero'd out the ALT and VEL PID's and entered only a low value ALT P-term. Because of the disabled I and D terms this suggest to me that the basic baro PID behavior is optimized for their frames, which seem to be smaller and lighter than what I have.

I've put several hours into it without success. So I've decided to sit back and let others report their results in the hopes their feedback provides some clues to what is going on.

[copterrichie]

Personally, I have had very good success with a simple throttle curve flatten right in the hover zone in maintaining altitude. I assume if there was a way to detect 1G from the accelerometer while in flight, the throttle hover zone could be adjusted within the software. I don't know if this is applicable or not, just a thought.

[mr.rc-cam]

Personally, I have had very good success with a simple throttle curve flatten right in the hover zone in maintaining altitude.

I have similar experience because in very calm weather (zero wind) my quad will hold its altitude for > 30 seconds without any baro assistance. So I expect that that the baro feature will be awesome once I get it working.

[copterrichie]

I have a home weather station and the barometric pressure is continuing changing especially in high winds. Personally and I hope I am wrong, I just do not see a baro working within the narrow altitude range for a multirotor copter. within a 30 feet, yes but nothing finer than that on a windy day.

[mr.rc-cam]

I've seen several MikroKopter videos that showed amazing altitude hold performance in a variety of conditions. I don't know what sensor (baro or Z-Accel) they use but it seems to work well.

[copterrichie]

I also am not sure and I know a number of multi-rotor copter flight controllers uses them. I have heard talk where the baro and Accelerometer Z axis are mixed to yield a good solid foundation for Altitude holding, how it is done, I don't have a clue. I am just stating, I personally don't see where one would be that effective when a good throttle curve works with less headaches.

Here is an example of a good Throttle Curve at work with the wiicopter.

http://www.youtube.com/watch?v=rzNlsEfQxUY

[mr.rc-cam]

Your video example was taken on a very calm day so I can see why the altitude was stable. I can achieve the same in those conditions without any baro assistance. However I usually have a breeze to deal with and so I would like a bit more electronic wizardry than is provided by throttle position and luck. Overall, I'm more optimistic than you that the baro can assist in doing this; I just think that the PID function needs more magic in it.

[copterrichie]

I have forgotten the terminology for the effect, but as wind passes over and under the props, more lift is created, on a very windy day, this effect is increased. Again, I just don't see where a baro alone will be enough because it its precision/resolution, there will have to be some Accelerometer Z axis mixing. Now I have heard there is a new baro in the pipeline that MAY have the resolution but to my knowledge, it is not available yet. Anyway, great talking.

[demands]

Only because I have one , I'll throw in:
How about mounting an ultrasonic range sensor, faced down, and mixing with?
Should be good up to at least 7-10 meters, depending on sensor (possibly even more)...
Of course it makes the terrain a new factor, but maybe it also makes it possible to fly e.g. 1m over ground with out changing altitude, just following the terrain topology...

[copterrichie]

Only because I have one , I'll throw in:
How about mounting an ultrasonic range sensor, faced down, and mixing with?
Should be good up to at least 7-10 meters, depending on sensor (possibly even more)...
Of course it makes the terrain a new factor, but maybe it also makes it possible to fly e.g. 1m over ground with out changing altitude, just following the terrain topology...

I believe this is where the major hope for the multi-rotor copter dwells for under 30 feet. Over 30 feet, the present baros may do the job. I have heard talk that there are problems with angularity and obstacles however, I have seen videos of quads following pathway like climbing stages.

I really would like to see more done with laser range finders.

[lucamacs]

I've seen several MikroKopter videos that showed amazing altitude hold performance in a variety of conditions. I don't know what sensor (baro or Z-Accel) they use but it seems to work well.

I have a large experience with Mikrokopters, over 50 units built in the last 4 years I can say that maintaining altitude is not a strong point of MK.
Without baro the multirotor will be hardly kept in a stable altitude only with throttle, it will constantly goes up or down. On this point Mwii is far better compared to MK.
Turning on the baro will keep the MK more or less at a stable altitude but MK bad attitude in maintaining altitude just with throttle will bring to a "combat" more than a smooth operation consuming, I guess some, unnecessary energy.
So IMHO MK performance on altitude hold is quite poor.

I have build just one Mwii based on Quadrino board, after several tries on Altitude PID settings with 1.9 firmware I was able to get a very good Altitude hold with no wind; I will test asap windy conditions .

[dramida]

Can you tell us the PID-s for alt and vel?

[Noctaro]

-

[lucamacs]

My PID values for ALT are 1,8-0-10, my quad have a total weight of 1000 grams, 950 kv motors, epp10x4,7 props, and 3S 2500mah battery. Max hovering time 14 minutes.

Here are some notes fo achieving a good altitude hold :
- protect the baro sensor from light and air turbulence , I used a black plastic tube glued on the pcb with some foam inside.
- tune your multirotor with proper Acc calibration , radio and Acc trims
- consider that you should activate baro only when a stable hover is reached
- Once you activate the baro DO NOT touch anymore throttle
- Once with baro on you should not notice any differences in behavior between Acro and Acc mode.
- When changing PID values begin with I and D values at zero,
- If copter goes up and down with an incremental sinuosid from altitude point (point when you activate baro) decrease P value little by little, when you reach a good result increase D parameter.

In calm air I was able to reach 0.7 - 1.5 meters altitude hold during several minutes.

Here is the behavior of baro with my settings :
Once you reach a stable hover activate the baro, not not touch throttle, if you move any other stick do it in a very gentle way, in this way your copter will loose a limited amount of altitude (around 0,7 - 1,4 meter )and will gently return to original altitude, if you move roll or pitch/nick stick quickly you wil notice a quite important loss of altitude (around 2 - 3 meters) that will be compensate in 3 or 4 seconds.

Finally I must say that now my Mwii have an amaizing altitude hold, very smooth and precise, much better compared to any Mk i build.

[dramida]

Thanks for sharing, i'll try it tomorrow and report back

[lucamacs]

Hello,
A Mwii developper wrote me this:

Code: Select all

But in the latest 1.8 has the following changes:
- the output of Altitude PID is feed forwarded. That means that you can use the ALT PID alone.
- The velocity PID is actually PD controller (I term is ignored)
- The altitude PID is actually PI controller (D term is ignored) 

I do not know if in 1.9 is also like this; that D parameter for ALT is ignored, when I ran my test , increasing it made a difference between Acro and Stable/ACC mode that had a different behavior in A.H. , but if it is so , I was obviously wrong .

[mr.rc-cam]

I do not know if in 1.9 is also like this; that D parameter for ALT is ignored, when I ran my test , increasing it made a difference between Acro and Stable/ACC mode that had a different behavior in A.H. , but if it is so , I was obviously wrong .

It is true, with V1.8 through V1.9:
The GUI's ALT D term is ignored. The ALT's PI data is derived from the baro sensor.
The GUI's VEL I term is ignored. The VEL's PD data is derived from the ACC's Z axis so it must be a "TRUSTED" ACC sensor for reliable results.
The ALT and VEL parameters are used together for baro hold. The unused GUI parameters (as noted) are just place holders for possible future use.

[ziss_dm]

Hi mr.rc-cam,

The GUI's ALT D term is ignored. The ALT's PI data is derived from the baro sensor.
The GUI's VEL I term is ignored. The VEL's PD data is derived from the ACC's Z axis so it must be a "TRUSTED" ACC sensor for reliable results.

This is not 100% true.

TRUSTED_ACCZ=True:

Code: Select all

(Acc1g-AccZ)   ->                                -> EstVel -> VelPID
                   getEstimatedAltitude()
BaroAlt        ->                                -> EstAlt -> AltPID 

TRUSTED_ACCZ=False:

Code: Select all

0       ->                                       -> EstVel -> VelPID
                 getEstimatedAltitude()
BaroAlt ->                                       -> EstAlt -> AltPID 

I mean, everything rderived from pressure AND vertical acceleration.

BTW: Can we summurise problems we have (excluding accelerometers overloading)?

regards,
ziss_dm

[mr.rc-cam]

This is not 100% true.

Thanks for pointing that out. I didn't notice the TRUSTED_ACCZ switch in the EstVelocity code. Sneaky little fellow it was! So I for clarity I will update my comment as follows:
The GUI's VEL I term is ignored. The VEL data is derived from the ACC's Z axis and Baro when it is a "TRUSTED" ACC sensor, else it only uses Baro.

But what is interesting is that if TRUSTED_ACCZ= FALSE you really don't need an ACC sensor because the baro data is all that is used. However, the Alt-Hold feature is *disabled* if an ACC sensor is not installed. It seems to me that if the ACC sensor is missing the code could share the untrusted ACC state and allow the use of the baro for velocity estimation (versus disabling alt-hold). Or am I missing something?

BTW: Can we summurise problems we have (excluding accelerometers overloading)?

The only summary I can offer at the moment is that V1.9 alt-hold does not work for me. I am the using the BMP085 and BMA180 on my big Quad. I am happy to report that it does not shoot into the sky due to ACC-Z overload, thanks to your help. But I can only achieve a ±5m hold performance in calm conditions. Baro data looks fine.

There does not seem to be strong community interest in the baro feature so I have not spent much time with improving it. For now I have set aside my alt-hold performance issues until I get more excited about digging back into the latest baro code. I will certainly do this as time permits, but if you can make improvements then go for it!

- Thomas

[dramida]

My PID values for ALT are 1,8-0-10, my quad have a total weight of 1000 grams, 950 kv motors, epp10x4,7 props, and 3S 2500mah battery.

You gave incorrect settings for Alt PID because is a PI controller and your I term is 0, D is ignored by software. And you also dont say anithing about Vel PID.

Please share.

[Alexinparis]

There does not seem to be strong community interest in the baro feature so I have not spent much time with improving it. For now I have set aside my alt-hold performance issues until I get more excited about digging back into the latest baro code. I will certainly do this as time permits, but if you can make improvements then go for it!

- Thomas

There is at least a huge interest on my side to have a reliable alt-hold.
GPS without this feature would not be really usable.
I managed to have good results on my config, but I think it's not enough robust.
I'm convinced there is no need to couple ACCZ to reach a good alt stability.
The right algorithm is still not here, but fell free to suggest and try

[mr.rc-cam]

I'm convinced there is no need to couple ACCZ to reach a good alt stability.

I tend to agree. Initially I felt that using the ACC-Z was pure genius for increased precision in the velocity algorithm. But during my ET ALT-V4 baro experiments I had decent alt-hold performance without the ACC (better than I could achieve with the ACC-Z, even after the BMA180 saturation fix). When I have the time I intend to try the ALT-V4 trickery on the V1.9 code base.

BTW, I am not a big fan of the 2-PID feed-fwd method being used. Just my opinion, but it needs to be one PID called Alt-Hold. The two PID method is fine for experimentation and debugging, but the final production version should settle on a one PID setup.

[ziss_dm]

Hi,

BTW, I am not a big fan of the 2-PID feed-fwd method being used. Just my opinion, but it needs to be one PID called Alt-Hold. The two PID method is fine for experimentation and debugging, but the final production version should settle on a one PID setup.

It is not possible to archive displacement stabilisation with one PID controller, controlling the thrust, even with super fast and precise information about displacement. For exactly the same reasons we using 2 PID controllers for the level mode:



regards,
ziss_dm

[lucamacs]

My PID values for ALT are 1,8-0-10, my quad have a total weight of 1000 grams, 950 kv motors, epp10x4,7 props, and 3S 2500mah battery.

You gave incorrect settings for Alt PID because is a PI controller and your I term is 0, D is ignored by software. And you also dont say anithing about Vel PID.
Please share.

dramida, unfortunately as you may have seen in this post : viewtopic.php?f=16&t=998
I cannot access to Mwii conf on my notebook so I do not remember Vel PID settings , anyway since I did not change them, values remain stock values. Gladly next weekend I will access to the pc at my vacation house where Mwii conf is installed then I will be happy to share my settings and hopefully I will shot a video about Altitute Hold on my quad.

[mr.rc-cam]

It is not possible to archive displacement stabilisation with one PID controller, controlling the thrust, even with super fast and precise information about displacement. For exactly the same reasons we using 2 PID controllers for the level mode:

Sorry for not being clear. I'm saying the Alt-Hold's user's interface (the GUI) needs to present one Alt-Hold PID setting, not two. The underlying code may need cascaded PID's but the user certainly doesn't need to know that. We need to make it simpler for them.

But I'm not here to complain; I will do everything I can to contribute to the Alt-Hold success (I just need to refresh a bit before getting back into it). If anything, I'm here to cheer on the experts. Frankly, I am hoping that there will be baro salvation from a generous MWC contributor.

[kataventos]

@mr.rc-cam

Thanks for your persistence, I hope you can get there fast, have my eyes on your updates

[didlawowo69]

why don't look into the Arducopter code ? they already have a alt hold stability and gps integration (using BMP085 and GPS) ?

maybe the solution is fully / partialy implementable in multiwiicopter ?

[mahowik]

Today I have found out one more point related to alt hold stability
viewtopic.php?f=7&t=363&p=6831#p6831
It works at least for my config...

[lucamacs]

Hello everybody,
here is the video I promise some days ago.

http://vimeo.com/33899630

Compared to the flight that I was talking in my previous post , the performance is a little bit worst but this time there was a light wind and the quad had recover from a crash and I had to repair a propeller with a firebrand , so performances are not optimal but IMHO it shows a good Altitude Hold attitude.
Consider that i use a wide angle camera , so when the quad comes near the camera a different altitude appears even if it is not so.
@dramida , VEL parameters are 10,0,0

[mr.rc-cam]

There is at least a huge interest on my side to have a reliable alt-hold. GPS without this feature would not be really usable. I managed to have good results on my config, but I think it's not enough robust.

I reviewed the V1.9 (Nov 12 version) baro hold code this week. I started with the stock code on a model with a BMA180 (TRUSTED_ACCZ) and BMP085 Baro IC.

In case it helps anyone that is working on the baro code, here is what I observed:
(1) The EstVelocity does not return to zero after typical vertical movement. It's not a sensor problem, it's a code issue. This affects the VEL-P term.
(2) The EstAlt has a noticeable data update delay (due to the weighting/filtering). The delay is large enough that you can see it by carefully watching the GUI as you move the model up/down. This delay affects the ALT's PI performance.
(3) The VEL-D term requires unusually fast vertical speeds, otherwise it remains zero. In practice, it does not contribute to the VEL PID with sane/normal altitude movement. The inactive VEL-D is not a great loss to me since my revised baro code will not be using it (my evil plan is to simplify the GUI's baro PID).

I made a quickie fix to the EstVelocity (bias problem) so that it would return to zero when there is no vertical motion. I also change the ALT P so it uses filtered BaroAlt data instead of the EstAlt data (to eliminate the baro data delay). These basic changes provided MUCH better baro hold on my model, but more work is needed before I can say for sure if I have made real progress. I plan on spending more time with it next week.

@mr.rc-cam
Thanks for your persistence, I hope you can get there fast, have my eyes on your updates

I'm mostly here to help cheer-on the experts that are improving the MWC project's code. I am hoping that someone will be inspired to improve the baro hold for us. Otherwise I will be back with more of my status updates as time permits.

- Thomas

[Bledi]

I just can say THANK YOU !

[hwurzburg]

Being a neewbie,I'm a bit confused....in V1.9:
1. Which PID values for ALT and VEL are active?
2. I have a BMP085 BAROMETER, should I enable the TRUSTED ZACC define?
3. Suggested starting values for PIDs in VEL and ALT.

I am very interested in a stable ALT hold since I use my Tricopter for HD photography at low altitudes in tight places via FPV...one of the reason I am moving to MultiWii is the hope of better altitude control during the slow moving (in X,Y axis) photography....+/- 1meter is okay, less beter, more than 2m I can do manually...

thanks

[mr.rc-cam]

1. Which PID values for ALT and VEL are active?

The following PID values are used in the V1.9's Baro's Alt-Hold mode:
ALT: P, I
VEL: P, D

2. I have a BMP085 BAROMETER, should I enable the TRUSTED ZACC define?

TRUSTED_ACCZ is decided by the ACC chip, not the Baro chip. The typical test is to hold the model firmly in your hand. While you ensure your safety, slowly Increase throttle to max. If the GUI's ACC Z axis data remains steady (small variation is Ok) when the throttle is increased then your ACC sensor is a trusted device (and you are permitted to enable TRUSTED_ACCZ).

Suggested starting values for PIDs in VEL and ALT.

You will have to experiment. As reported in my earlier post, there are some bugs in the Alt-Hold PIDs. Until they are sorted out, some models will not have success with Alt-Hold.

I am very interested in a stable ALT hold since I use my Tricopter for HD photography at low altitudes in tight places via FPV...one of the reason I am moving to MultiWii is the hope of better altitude control during the slow moving (in X,Y axis) photography....+/- 1meter is okay, less beter, more than 2m I can do manually...

It sounds like your MWC needs an ultrasonic sensor solution, so maybe that type of solution will evolve. But with the common baro sensors it will be a stretch if you need ±1 meter performance in a FPV camera ship (which tend to be heavier/larger MWC models). Even with my recent code tweaking I saw ±2.5 meters in calm conditions for long extended periods (entire battery pack!). It would be reasonable to expect that at some point we will all be able to achieve at least ±2 meters using the popular sensors found in a MWC. But the code needs some refinement; For now, Alt-Hold is a works in progress.

- Thomas

[CactusJackSlade]

Thomas, Mr.rc-cam

Thanks for your investigation into this... as a newbie in auto functions and with little time to learn about all this code work, your input is greatly appreciated Hopefully some kind of fix can be made available to the general public at some point...

I will be watching this thread with interest!

[CactusJackSlade]

The DJI Naza is supposed to have a very good algorithm and hence a pretty good altitude hold

OK, this was kind of a bump.... anything new anyone?

[lucamacs]

I'm quite happy with altitude hold of my mwii , did you look to the video I had post previously ?

[ankimo]

Hi ALL

Write the first to board.
A RTH success was carried out luckily.

My MWC specification
・MOT　CT1811　x4
・ESC　6A　x4
・Props: 5x3 3-blade GWS
・FC　FLYDUINO
・IMU　DROTEC　10DOF
・GPS　LOCOSYS　10Hz
・LIPO　2S800
・Motor shaft distance: 250mm
・278g icl. battery & FPV equipment
・Endurance: 8 minutes

One problem
ALTHOLD does not function well.
Please teach me how to decide ALT and a VEL parameter.

regards
kazz

[ankimo]

Hi

The problem was solved with the following parameter.
ALT：P 3.1　I 0.025　D 0
VEL：P 4.1　I 0.000　D 30
The altitude is stable at ±1 m.

regards
kazz

[Alexinparis]

Hi,
during your PID tuning, did you find VEL PD gave a real plus in alt stabilization ?

[ankimo]

Hi Alex

In dev_20111220, it is rightly effective.
dev_20120121 is tried tonight.

regards
kazz

[mahowik]

Hi,

dev_20111220 and MultiWii_1_9 is the same in terms of alt-hold...

Here is some more facts that alt-vel PI-PD works:
viewtopic.php?f=7&t=363&start=70#p8019
viewtopic.php?f=7&t=363&start=70#p8100
viewtopic.php?f=7&t=363&start=80#p8128

We should not remove the vel PD!
http://code.google.com/p/multiwii/sourc ... no&old=450