Alt. Hold Ideas and discussion

ziss_dm · Post by **ziss_dm** » Tue Jun 28, 2011 12:37 am

Hi,
Looks like it is working with latest dev changes and because my quad going to service and bad weather, it would be interesting to see if somebody could repeat results with other setups. So, I would try to explain latest changes in soft. and GUI and setup precedure.

GUI changes:
1) The baro currently displaying altitude above see level in meters.
2) The baro graph automatically scaled with range +-1 m, so you can see alt. variations quite preciselly
3) The Estimated altitude is displayed on top of baro graph, it uses the same scale as baro graph. So it is possible to see how baro data is smoothed.
4) The additional PIDs added to configuration area.

How it works:
Complimentary filter: Mixing data from baro and accelerometers, to get estimation of vertical speed and altitude.
Velocity PID: Uses estimated vertical speed and adjusts throttle to hold desired vertical speed.
Altitude PID: Uses estimated altitude and adjusts vertical speed (Outpud is feeded to the Velocity PID)

Setup procedure:
1) Set Vel. and Alt. PID values to the zero
2) Start increasing Vel. D. You should start feeling that quick throttle stick movements are dampened. Increase until really fast osculations starts in response on quick throttle stick movement. Than drop a little bit. My current value: 30
3) Start increasing Vel. P. Throttle response should be softer and softer and quad should start holding altitude. The tricki part here, that CF using baro data for vertical speed and it is fluctuating, but you can roughly assest amount from GUI. The good values for Vel. PID should give you the following behavior: After flicking switch the quad should stop and slowly drift.
4) Start increasing Alt. P. The quad should stabilize around set point. Increase until it start oscilating, the value could be really high: I have 20
5) Start increasing Alt. I. The stabilization should become more precise.
6) experiment..

It would be nice to collect statistics of working PID values, as we need to decide do we really need full PIDs for both Alt. and Vel. and probably re-adjust PID ranges.

regards,
ziss_dm

ziss_dm · Post by **ziss_dm** » Sat Jul 02, 2011 8:52 am

Hi,

First outdoor test:
http://youtu.be/TQE07uFLO68

Conditions:
wind spd: 15Km/h
wind gust: 31Km/h

Mode: Level+Baro

regards,
ziss_dm

ziss_dm · Post by **ziss_dm** » Mon Jul 04, 2011 1:03 am

Hi Alex,

In the latest dev, the auto-repeat functionality was removed from LCD configurator. Was there some problem with it or just accident

? I thought it is nice feature..

regards,
ziss_dm

Alexinparis · Post by **Alexinparis** » Mon Jul 04, 2011 9:47 am

Hi,

I suppressed the auto repeat functionality because it caused sometimes an immediate exit without save from the LCD configuration loop.
But I’m not against this functionality if it’s restricted to only param switch & param modification

About the baro:
Your video is quite demonstrative, it seems to work well on your setup.

I tried yesterday and here is what I noticed:
- it worked well (very well) for 10-20s and the multi began to rise without limit progressively, I had to swith to a non baro mode to keep the control.
- when I activate the baro mode in flight, I noticed a sudden variation of the motor speed => the init conditions when the baro mode is activated should be refined

=> there is still something wrong somewhere, the most annoying part is the rising with no limit effect.

ziss_dm · Post by **ziss_dm** » Mon Jul 04, 2011 1:39 pm

Hi Alex,
As you are the first one, who actually tried this I have lot of questions for you

:
1) What PID's you had?
2) Have you managed to setup velocity PID separately from Alt. PID?
3) How it was flying with only velocity PID?
4) When it started raising, it was looking like something overflowing or it started oscillation? I had something similar than I had too big Alt. P, it is starting oscillation with amplitude, I would say 50m. And it is really fast.
5) Is CF working well in GUI?
6) I have also noticed, that CF require some time to stabilize after quad stay on the ground inclinated. Was your attempt was immediately after takeoff or after some time in the air?

But you are right, there are lot of work to do..

regards,
ziss_dm

Alexinparis · Post by **Alexinparis** » Mon Jul 04, 2011 11:57 pm

Hi,

1)
I have:
VEL: P 9.0 I 0.0 D 19
ALT: P: 9.0 I 0.0 D: 10

2)
yes, more or less, it works as expected

3)
I tested it only inside a room, not in open space.
and the test with ALT PID was done outside

4)
it was looking like something overflowing

5)
yes perfect
I modified some code (after my test)
I move baro est to expected baro value
I move baro raw value to a debug variable
(by default it is not graphed, you have to click on debug1 to see the graph)

6)
I modifed some code (after my test) to cancel the CF with ZACC when the quad is tilted.
My attempt was after some time in the air.
But anyway, I think it's not normal to have a sudden motor variation at the alt hold activation.

ziss_dm · Post by **ziss_dm** » Tue Jul 05, 2011 1:59 am

Hi Alex,

I think, that ALT: P: 9.0 I 0.0 D: 10, could actually start oscilation. I think ALT pid should have I term. In my latest tests I was using only PI term for ALT stabilization.
The D term in ALT pid could be usefull, but only in case setpoint is far from the current position (i.e. autonomous flight).

I have also noticed, that you switched back to relative alt. Is it because of OSD?

I think, it is better to leave sensors to report "raw" absolute altitude and for OSD we could have separate adjustment, which we could initialize on motors arming. There are couple of reasons for this:
1) Easier to debug sensor data (I had cases, than relative altitude was "hiding" mistakes in calculations)
2) Will be easier in future to fuse GPS alt to the CF.
3) Code will be smaller

regards,
ziss_dm

Alexinparis · Post by **Alexinparis** » Tue Jul 05, 2011 7:33 pm

you're wise, I switched back to absolute reading.
I will retry a baro hold experience latter.

ziss_dm · Post by **ziss_dm** » Tue Jul 12, 2011 4:26 am

Hi Alex,
Did you have a chance to test Alt. Hold? I have made some adjustments to the CF and PID regulators, but it also involves changes to the current Acc trimming procedure (current one changes magnitude of the ACC vector). So it would be nice to have second opinion.

regards,
ziss_dm

Alexinparis · Post by **Alexinparis** » Tue Jul 12, 2011 4:18 pm

ziss_dm wrote:Hi Alex,
Did you have a chance to test Alt. Hold? I have made some adjustments to the CF and PID regulators, but it also involves changes to the current Acc trimming procedure (current one changes magnitude of the ACC vector). So it would be nice to have second opinion.

regards,
ziss_dm

Hi,
I've not the chance to test it recently.
There is no problem to modify the current ACC trimming as the trim accuracy depends on the acc_1G value. So it's currently not perfect and should be adjusted to be ACC agnostic.

dynai · Post by **dynai** » Sat Jul 16, 2011 11:42 am

Hi,

i have tried 8" and 10" props... on the 10" i had that "rise without limit" effect... (default values)

then i followed the setup procedure.. could raise Vel. D over 60 without any signs of oscillation (1kg Quad) didn't go further...
as soon as Vel. P went over 6 "rise without limit"

that was the point when i switched from 10 to 8"... now no problems with a Vel. P of 10

next i rose Alt. P and i reached the LIMIT without major signs of oscillation

but as soon as i introduced a bit (0.01) Alt. I oscillation began... till i reached a I of 0.1 (YES).... i even went for 0.2

everything seems fine during the first 10-30 seconds as alex described but then quad drops/rises for approx 2-3 meters then stops climbs and after around 1 sinus it stabilises.. just to go 30secs later through the same procedure

my "findings" (if one wants to call them that way) Alt. D lead to worse results whereas Vel. D seemed to make things smoother.
Alt. P of 10-20 seems reasonable and delivered good results (reaching limits of functions always gives me some headache although 25 without Alt. I looked good)

but sometimes i wished i had a sonar

Vel. P makes me realy wonder... why does the quad start to climb that much... and why if you lower throttle does the stabilization stop before the quad stops climbing...

and last but not least could one of the experts have a look at this video of my gui... i wonder if my baro works as expected... thanks

http://youtu.be/9ZoRj-AdruY

the video was taken with the quad only powered over usb.. so it is resting on the table.. no movement, door to the room closed.

kind regards

Christoph

iacei2 · Post by **iacei2** » Sat Jul 16, 2011 6:34 pm

Hi, I have the same behaviour I hope those are not meters because it fluctuates from 1 to 2m when the quad is standing still.

Even worse if I throttle up forcing stable altitude the values jump to 2-3 m difference.

I did protect my board and the baro with a shell to avoid wind blowing on it but it does not change this behaviour.

Maybe my arms are too short: 47cm motor to motor with 10 inch props.

I did not try it during flight atm because I fear it will fly away. On hand I already felt that it wanted to rise or drop.

ziss_dm · Post by **ziss_dm** » Tue Jul 19, 2011 3:50 am

Hi dynai,
Thank you for detailed report. Currently I'm trying to re-scale PID's to have more usable ranges, so your report just in time.

According to your graph, you should be able to stabilize it inside 1m range (whole window is +-1m from center point). Ofcorse you need to protect sensor from the wind and props, but also make sure nothing touching the metal case of the sensor (according to the datasheet the minimum distance 2-3mm). So, you was not able to setup Alt. PID to avoid overshoots?

regards,
ziss_dm

Alexinparis · Post by **Alexinparis** » Tue Jul 19, 2011 10:28 am

Hi,

some brainstorming:

The current altitude estimator is very good. With the help of ACC integration, we regain the latency we lost using only data from the baro.
We can see clearly the effect of the filter with the first debug box in the 1.8 GUI (hide/show raw baro value, hidden by default). We can click on it for those you don't know

We have now something more closer to an ultra sonic sensor regarding response time.

So, one first thought:
- I know that in other project the altitude stabilization is very good using an ultra sonic sensor with a simple PID. Don't you think it can't be achieved here by a single PID using the current alt estimator ?

- the current code relie only on Z_ACC, and I corrected it to relie only on this under 10deg inclination (last dev). It is better to use the real magnitude, but the code&CPU time is longer

Code: Select all

  InstAcc = (sqrt((int32_t)accADC[YAW]*accADC[YAW]+(int32_t)accADC[ROLL]*accADC[ROLL]+(int32_t)accADC[PITCH]*accADC[PITCH]) - acc_1G) * AccScale;

- the reason why we encounter a sudden jump of altitude loss when we switch the baro mode is due to EstVelocity. It might be better to zero it at the switch activation (assuming the mode is engaged only when the multi is nearly alt table)

- there is nothing to constrain EstVelocity.
int32_t VelError = EstVelocity*1000.0f – AltPID;
PTerm = VelError*P8[PIDVEL]/1000;
I think it's the explanaition of the “rise without limit effect”. I didn't find out why such a divergence could occur, because it should be regulated by (Kp1 * Kt) * AltError , but it's the only explanaition for me.
I think there is a simple way to prevent this by adding a long term 0 convergence in the IMU loop. Something like

Code: Select all

  EstVelocity *= 0.99;

Alexinparis · Post by **Alexinparis** » Tue Jul 19, 2011 10:32 am

@dynai,
you baro works very well.
you can see it staying in a quite narrow range around -6.3m.
don't be afraid about the huge curve magnitude as there is an "autozoom" function in the gui for the altitude.

EOSBandi · Post by **EOSBandi** » Tue Jul 19, 2011 5:56 pm

Alexinparis wrote:Hi,

some brainstorming:

The current altitude estimator is very good. With the help of ACC integration, we regain the latency we lost using only data from the baro.
We can see clearly the effect of the filter with the first debug box in the 1.8 GUI (hide/show raw baro value, hidden by default). We can click on it for those you don't know
We have now something more closer to an ultra sonic sensor regarding response time.

So, one first thought:
- I know that in other project the altitude stabilization is very good using an ultra sonic sensor with a simple PID. Don't you think it can't be achieved here by a single PID using the current alt estimator ?

- the current code relie only on Z_ACC, and I corrected it to relie only on this under 10deg inclination (last dev). It is better to use the real magnitude, but the code&CPU time is longer
Code: Select all
  InstAcc = (sqrt((int32_t)accADC[YAW]*accADC[YAW]+(int32_t)accADC[ROLL]*accADC[ROLL]+(int32_t)accADC[PITCH]*accADC[PITCH]) - acc_1G) * AccScale;
- the reason why we encounter a sudden jump of altitude loss when we switch the baro mode is due to EstVelocity. It might be better to zero it at the switch activation (assuming the mode is engaged only when the multi is nearly alt table)

- there is nothing to constrain EstVelocity.
int32_t VelError = EstVelocity*1000.0f – AltPID;
PTerm = VelError*P8[PIDVEL]/1000;
I think it's the explanaition of the “rise without limit effect”. I didn't find out why such a divergence could occur, because it should be regulated by (Kp1 * Kt) * AltError , but it's the only explanaition for me.
I think there is a simple way to prevent this by adding a long term 0 convergence in the IMU loop. Something like
Code: Select all
  EstVelocity *= 0.99;

Hi Alex,
The idea to zero out EstVelocity seems to work. Perviously I got "shoot to the sky" or "drop like stone" when activating alt hold, now it activates smooth and flawless. Still need to adjust PID's but it's definitely better. Change for Z_ACC to use full magnitude of inclination seems to work also, however I did not noticed any sigificant behavior change.
Regards,
EOSBandi

ziss_dm · Post by **ziss_dm** » Wed Jul 20, 2011 9:17 am

Hi Alex,

So, one first thought:
- I know that in other project the altitude stabilization is very good using an ultra sonic sensor with a simple PID. Don't you think it can't be achieved here by a single PID using the current alt estimator ?

I think, it is not really possible to archive good control with one PID here, for the same reason(s) as it is not possible for level mode: We are controlling acceleration, measiring absolute displacement. The single PID are not able to generate acceleration profiles.

the current code relie only on Z_ACC, and I corrected it to relie only on this under 10deg inclination (last dev). It is better to use the real magnitude, but the code&CPU time is longer

I'm investigating it, but it ais also involves changes in existing Level Mode trimming.

- the reason why we encounter a sudden jump of altitude loss when we switch the baro mode is due to EstVelocity. It might be better to zero it at the switch activation (assuming the mode is engaged only when the multi is nearly alt table)

It is most logical explanation, but nobody yet reported jumps with Vel. PID only. (yes there is short bump while PID stabilizes, but no uncontrolled rises or drops). The jumps usually starts with Alt. PID. Which currently makes me to belive, that something wrong with PID controller itself.

The idea to zero out EstVelocity seems to work. Perviously I got "shoot to the sky" or "drop like stone" when activating alt hold, now it activates smooth and flawless. Still need to adjust PID's but it's definitely better. Change for Z_ACC to use full magnitude of inclination seems to work also, however I did not noticed any sigificant behavior change.

Be carefull, in case of big difference the CF could start scillating.

regards,
ziss_dm

ziss_dm · Post by **ziss_dm** » Thu Jul 21, 2011 12:31 pm

Hi Alex,

I think, we need to start merge changes ;(

Short overview of changes:
1) Level trim - separate from accZero, has constant step 0.1 deg
2) LCD - slightly optimized + Auto repeat
3) PDF for level mode (good for indoor tests

)
4) getEstimatedAltitude() - adjusted gains and uses Acc vector magnitude projected on local Z (.99 removed so far). Looks better in GUI and looks like have better velocity tracking. (with Vel. PID only has quite good transition to the Baro mode)
5) Velocity PID changed to PD scaled to the 16bit and constrained to avoid overflows.
6) Alt.PID - unfinished yet.
7) In Sensors.pde last changes reverted for BMAs ;(

regards,
ziss_dm

dynai · Post by **dynai** » Thu Jul 21, 2011 12:38 pm

hi Ziss_dm, hi Alex,

i had that rise - effect with only Vel. PID set up (Alt PID zeroed out) and it only occured when P reached a certain "limit", depending largely on the Props i had mounted.
the velocity fade-out could be a solution as it seemed that the software was thinking the quad is allready mooving when it wasn't

the baro is shielded inside a hull (large bottom opening) and has aroud 4mm space to all sides

i tested around 8 charges (around 50 changes of the pid) and could'nt get a better result than having it in a window of around 1m and after a certain time starting slowly starting to rise/drop for 3-4m before reaction catching itself after total up/down cycle (5-10m)....

with your confirmation of the baro-"resting"-curve i can't await to do some testing on the weekend.

kind regards

Christoph

edit: removed picture to shorten entry

Alexinparis · Post by **Alexinparis** » Thu Jul 21, 2011 11:16 pm

I've done some merges in R214

1) excellent
2) Auto repeat is now ok because the first blink sequence prevent from exiting immediately with the same stick sequence used to enter in conf loop. The autorepeat behavior is very convenient.
3) added as define
4) still ok, it's difficult to notice a difference in the GUI.
One thing I noticed more since last time: it's possible to fool the estimator by shaking rapidly the copter up/down.
It may explain sudden divergence in flight due to ACC vibration. probably one thing to investigate
5) ok
6) added some int32_t cast to avoid overflows
7) ok, it worked fine before. and sensor eeprom stuffs need more investigation.

8) I noticed a deadband function. added as a #define. I'm personally not a fan of this because it prevent the use of fine TX trim, but I understand the need.
9) no more MAX_CORRECTION

ziss_dm wrote:Hi Alex,

I think, we need to start merge changes ;(

Short overview of changes:
1) Level trim - separate from accZero, has constant step 0.1 deg
2) LCD - slightly optimized + Auto repeat
3) PDF for level mode (good for indoor tests )
4) getEstimatedAltitude() - adjusted gains and uses Acc vector magnitude projected on local Z (.99 removed so far). Looks better in GUI and looks like have better velocity tracking. (with Vel. PID only has quite good transition to the Baro mode)
5) Velocity PID changed to PD scaled to the 16bit and constrained to avoid overflows.
6) Alt.PID - unfinished yet.
7) In Sensors.pde last changes reverted for BMAs ;(

regards,
ziss_dm

jevermeister · Post by **jevermeister** » Thu Aug 25, 2011 9:51 am

Hi there,
I try to get forward with the baro mode.
I have all PID (VEL/ALT) set to zero and start incrementing ALT P.
I circled into 11 as a good value, everything else is set to 0.

The copter oscilates +/-0,5m in the air, I think this is very good for the beginning but can be optimized.

But now I started thinking: Is this the correct approach? I read that one should start with vel.

Can you tell me what vel does exactly? I understood that it changes the velocity of the copter, but does that even have an effect if baro mode is turned off? I don't want to loose agility when baro is off.

I am still not happy with my shielding, I strapped the sensor to my centerplate and put some foam onto it and shield it with adhesive tape. I read about a min distance to the case, anyone can tell me any details?

nils

ziss_dm · Post by **ziss_dm** » Fri Aug 26, 2011 1:40 pm

Hi jevermeister,

But now I started thinking: Is this the correct approach? I read that one should start with vel.

I'm usually adjusting PID's in the following order:
1) VEL D
2) VEL P
3) ALT P

More details here: viewtopic.php?f=7&t=363&start=30

How it works:
Complimentary filter: Mixing data from baro and accelerometers, to get estimation of vertical speed and altitude.
Velocity PID: Uses estimated vertical speed and adjusts throttle to hold desired vertical speed.
Altitude PID: Uses estimated altitude and adjusts vertical speed (Outpud is feeded to the Velocity PID)

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)

regards,
ziss_dm

jevermeister · Post by **jevermeister** » Mon Aug 29, 2011 7:47 am

We should write stuff like this into a beginners guide,
I had a hard time finding this, and people are asking it over and over again in rcgroups, even in PM.

I would volunteer for that, but I am not an expert in all the funtions, but if you guys would help me...

Nils

crashlander · Post by **crashlander** » Sat Sep 24, 2011 5:14 pm

ziss_dm wrote:Hi,
1) Set Vel. and Alt. PID values to the zero

O.K.

ziss_dm wrote:2) Start increasing Vel. D. You should start feeling that quick throttle stick movements are dampened. Increase until really fast osculations starts in response on quick throttle stick movement. Than drop a little bit. My current value: 30

I can't see no oscillations from D=0 to D=50 (max.) so I settled at 37

ziss_dm wrote:3) Start increasing Vel. P. Throttle response should be softer and softer and quad should start holding altitude. The tricki part here, that CF using baro data for vertical speed and it is fluctuating, but you can roughly assest amount from GUI. The good values for Vel. PID should give you the following behavior: After flicking switch the quad should stop and slowly drift.

My current P=0.3 With anything higher etc. 5,6,7,... my Wii starts to gaining hight really fast (or sometimes drops like stone) without stop, direction of altitude goes into opposite direction of slow drift at the time of switch change (alt. hold activation).

ziss_dm wrote:4) Start increasing Alt. P. The quad should stabilize around set point. Increase until it start oscilating, the value could be really high: I have 20
5) Start increasing Alt. I. The stabilization should become more precise.
6) experiment..

It would be nice to collect statistics of working PID values, as we need to decide do we really need full PIDs for both Alt. and Vel. and probably re-adjust PID ranges.

regards,
ziss_dm

After 4 LiPo packs I stopped here and will try to change Alt. P and D in following days.

So my current state is Vel. D=37 and Vel. P=0.3 with that my Wii drifts from ground (where bounces) up to 5m high.

Any comments or suggestions are welcome!

My setup is:
-Atmel AVRSBIN1,
-BMP085
-Ardu. ProMini,
-Turnigy Plush 10A,
-2213N 800Kv motor,
-10x4.7 props.,
-QuadX (simetrical), 60cm motor to motor, 900g flying weight
-ITG3200_LPF_20HZ or ITG3200_LPF_42HZ

mr.rc-cam · Post by **mr.rc-cam** » Sat Sep 24, 2011 6:40 pm

So my current state is Vel. D=37 and Vel. P=0.3 with that my Wii drifts from ground (where bounces) up to 5m high.
Any comments or suggestions are welcome!
My setup is:
-Atmel AVRSBIN1,
-BMP085
-Ardu. ProMini,
-Turnigy Plush 10A,
-2213N 800Kv motor,
-10x4.7 props.,
-QuadX (simetrical), 60cm motor to motor, 900g flying weight

I'm having the same alt-hold problems. My setup is very similar to yours but my Quad is a bit heavier (~1300g). I've noticed that the users that have had alt-hold success have models that are smaller, lighter, and more agile.

I've used the recommended procedure, also tried every combination of PID settings, some witchcraft and chants, and nothing yet has helped me achieve useful alt-hold. So I am hoping you solve your problem and share your success!

copterrichie · Post by **copterrichie** » Sun Sep 25, 2011 6:14 pm

MultiX4 ALT Hold no GPS

http://www.youtube.com/watch?v=RA1a-Ya4xag&feature=colike

Altitude hold with BOSH BMP-085

ultrahigh resolution mode 17/25.5 millisecond refresh rate
temperature compensate calculation

pressure = p + (x1 + x2 + 3791)/4
b4 = (b7 / b9) * 2
x1 = (p/8) * (p * 16); ( set to 65535 step )
x1 = (x1 * 2038) *16;
x2 = (-7957 * p) *16; ( res For Thailand )

Katch · Post by **Katch** » Sun Oct 02, 2011 10:34 pm

Just starting to try and get my Alt hold dialed in too.

Having similar experiences as mr.rc and crash. Getting a yo-yo-ing quad but no real hold yet. This is on the MS version of Fabio's freeIMU.

Feels like the motor compensation takes too long to respond and then over-corrects.

Not very good at PID tuning yet so it's a bit like throwing dice.

Alexinparis · Post by **Alexinparis** » Sun Oct 02, 2011 11:14 pm

Hi,
Before trying to tune the VEL PID, I would suggest to tune only the ALT P parameter and leave everything else to 0 (ATL I, ATL D, VEL P, VEL I, VEL D = 0)

Katch · Post by **Katch** » Mon Oct 03, 2011 10:17 am

Thanks Alex,

I'll try that next time I get out in the field.

ziss_dm · Post by **ziss_dm** » Tue Oct 25, 2011 3:41 am

Hi mr.rc-cam,

With the BMP085 baro sensor, and the patched (but otherwise stock) code, I could reliably achieve ±5 meter Alt-Hold precision. This is awesome considering the performance I was getting with the original code. And left alone I think it would make most users very happy. But I tried to squeeze out more performance with the BMP085. With some additional code changes I am now experiencing reliable ±2 meter precision, which is not bad at all. I think it could be less than 1 meter with the EagleTree Baro sensor, but I will continue to use the BMP085 for the time being.

Some basic things that helped me out:
Added baro data filter.
Rescaled ALT I term.
Reworked I term integrator.
Changed some constrains.

In case anyone wants to try it, I can add my experimental Alt-Hold code to a clean MultiWii file set. But I want to wait for the next formal release that has all the latest fixes to V1.8p_2. Any idea when that will be?

Can you just post your changes with comments for now?

Added baro data filter.

Is it just LPF? Have you noticed changes in raw baro graph (debug1) in GUI? Have you increased refresh rate accordinly?
When I was experimenting with that, I have found that BMP noise is not really gaussian and all types of "averaging" filters not really working. Better results I was getting just by reducing refresh rate.

Reworked I term integrator.

Do you mean decreased update rate?

regards,
ziss_dm

mr.rc-cam · Post by **mr.rc-cam** » Tue Oct 25, 2011 5:44 am

Hi mr.rc-cam, Can you just post your changes with comments for now?

Sure. I'm still refining the code so this is a good time to discuss it in case we can find areas to improve. When Alex publishes the next formal release (with the fixes to V1.8p2) I will post a file set with these edits in it so others can try it out.

Here's a summary of some changes I've made so far:

[1] Baro Data Filter:
I'm currently using modified-medium (Olympic scoring) averaging to remove some of the random values from the BMP085 baro sensor. It helps out, but the BMP085 baro data is still nothing to brag about. This is the code:

Code: Select all

#define BUFFSZ 4                              // DO NOT Change this value.
float baro_filter(float fdata) 
{
    int8_t i;
    float d_big = 0;
    float d_small = 0;
    static uint8_t offset = 0;
    static float filter[BUFFSZ];

    filter[offset] = fdata;                  // Store filter data in table.
    fdata = 0;
    for(i=0; i<BUFFSZ; i++) {        // Add up all data values.
   fdata += filter[i];
    }

    d_small = filter[0];                        // Prime the sort engine.
    d_big = filter[0];              // Prime the sort engine.
    for(i=1; i<BUFFSZ; i++) {            // Find extreme values.
   if(d_small > filter[i]) {        // Find smallest value.
     d_small = filter[i];
   }
   if(d_big < filter[i]) {           // Find largest value.
     d_big = filter[i];
   }
    }

    fdata = fdata - (d_big + d_small);   // Remove extreme values.
    fdata = fdata / 2.0f;                  // Obtain avg using medium.

    if (++offset >= BUFFSZ) offset = 0;   // Wrap around.
    
    return(fdata); 
}

[2] I rescaled the ALT I term to reduce its weighting. From my recent tests I think I needs to be reduce some more, but that can come later. Here are my current values:

Code: Select all

      errorAltitudeI = constrain(errorAltitudeI,-4000,4000); // Was previously ±5000.  
      ITerm = (int32_t)I8[PIDALT]*errorAltitudeI/8000;  // Was previously decimated by 4000.

[3] I found the I term would regularly overshoot the intended correction. So data squelching was added (error accumulation is no longer symmetrical):

Code: Select all

      //**** Alt. Set Point stabilization PID ****
      error = constrain((AltHold - EstAlt)*10, -100, 100); //  +/-10m,  1 decimeter accuracy
      errorAltitudeI += error;                  // Integrate error.
      
      if(error>0 && errorAltitudeI<100) {       // Overshoot protection.
          errorAltitudeI += 10;                 // Quickly Squelch I error.
      }
      else if(error<0 && errorAltitudeI>100) {  // Overshoot protection.
          errorAltitudeI -= 10;                 // Quickly Squelch I error.
      }

[4] The throttle constrain was a bit limiting so I expanded it, as follows:

Code: Select all

rcCommand[THROTTLE] = initialThrottleHold + constrain(AltPID - (PTerm - DTerm),-125,+125)  // Was previously limited to ±100. ±150 may be better choice for some models.

[5] My model is a battery pig. If I hovered in the same spot for more than 45 seconds the Alt-Hold begins to lose altitude. This is because of the PID code constrains don't allow enough headroom in the throttle calculations as the battery voltage decreases. The reasonable solution was to add voltage loss compensation to alt-hold. The GUI's unused ALT D term is used to adjust the weight of the voltage compensation. This works great for my model and if it is not needed the D value can be set to zero. Here is the code:

Code: Select all

      rcCommand[THROTTLE] = initialThrottleHold + constrain(AltPID - (PTerm - DTerm),-125,+125);  // This is the existing throttle PID.

      // **** Battery Voltage Compensation *****
      #ifdef VBAT
       if(initial_vbat > vbat) {        // Battery voltage is decreasing.
        delta_vbat = initial_vbat - vbat;  // initial_vbat value was set when alt-hold was enabled.
       }
       else {
          delta_vbat = 0;              // Battery voltage has not decreased.
       }
       vbatThrCompensation = (D8[PIDALT] * delta_vbat)/4;  // Use ALT-D GUI value for compensation weight.
       vbatThrCompensation = constrain(vbatThrCompensation,0,+150); // Limit the compensation for safety.
       rcCommand[THROTTLE] = rcCommand[THROTTLE] + vbatThrCompensation;  // Add the voltage compensation to the throttle.
      #endif

dramida · Post by **dramida** » Sun Dec 11, 2011 12:49 pm

Testing the VEL parameter, i shaked up and down the octo and saw that Z axis effect on engines was not the same. Some times the amplitude of engine speed variation was larger, other times, insignificant.Test conducted using V1.9 MWC with trusted acc, ofcorse, ADXL345, ALT pid 0,0,0, vel PID 20,0,0

mahowik · Post by **mahowik** » Sun Dec 11, 2011 9:50 pm

As for me, I got very good results +/-0.5..1m when it's not windy outside

PID ALT: 3.0 - 0.015 - 0
PID VEL: 5.0 - 0.000 - 45

dramida · Post by **dramida** » Mon Dec 12, 2011 12:51 am

What accelerometer and software version are you using? i'll test your settings tomorrow, thank you.

mahowik · Post by **mahowik** » Mon Dec 12, 2011 8:26 pm

dramida wrote:What accelerometer and software version are you using? i'll test your settings tomorrow, thank you.

bma020(set to 8g range: acc_1g=63)
software 1.9

most of all you should keep high VEL D... then play with VEL P and ALT P

thx-
Alex

mahowik · Post by **mahowik** » Mon Dec 19, 2011 4:08 am

One more note about alt hold stability...

At the beginning I got a good results and stable alt hold with using accSmooth instead of accADC in getEstimatedAltitude().
And today I tried to use original version (i.e. with accADC) and have found out that is not working for me... It became very unstable and unpredictable...

Code: Select all

//InstAcc = (accADC[YAW] * (1 - acc_1G * InvSqrt(isq(accADC[ROLL]) + isq(accADC[PITCH]) + isq(accADC[YAW])))) * AccScale +  AltErrorI / 1000;
InstAcc = (accSmooth[YAW] * (1 - acc_1G * InvSqrt(isq(accSmooth[ROLL]) + isq(accSmooth[PITCH]) + isq(accSmooth[YAW])))) * AccScale +  AltErrorI / 1000;

So in case of you have unstable alt hold you can try to use accSmooth as solution.

thx-
Alex

ziss_dm · Post by **ziss_dm** » Mon Dec 19, 2011 5:12 am

Hi Alex,

With normal ACC bandwith (10-25 Hz)?

regards,
ziss_dm

mahowik · Post by **mahowik** » Mon Dec 19, 2011 6:19 am

ziss_dm wrote:With normal ACC bandwith (10-25 Hz)?

Bandwidth 190 Hz
but ACC LPF ~= 2..3Hz

Code: Select all

static float accTempF[3];
.......
        #define lfpFactor 0.987f 
        accTempF[axis] = accTempF[axis]*lfpFactor + accADC[axis]*(1.0f - lfpFactor);
        accSmooth[axis] = accTempF[axis];

Yes! I see what you wanna to say!

It (190hz) was too high for the altitude calculation?
In any case with LPF 2..3Hz it gives very stable ALT hold...

thx-
Alex

ziss_dm · Post by **ziss_dm** » Mon Dec 19, 2011 7:04 am

Hi Alex,

Not really that..

I think, increased bw is good for Alt.Hold. (in theory)
But integrator currently skipping cycles, assuming bw: 20Hz. So, for increased BW, you need to adjust that. (busically integrate every cycle, for around 200Hz)

BTW: What a waight of your model? What power system you have? (the increased bw is good for light and powerful models, I think...)

regards
ziss_dm

mahowik · Post by **mahowik** » Mon Dec 19, 2011 5:19 pm

My config quadX:
- turnigy 2209 28turn 1050kv 15A Outrunner
- props HK 9x5
- plush 18a
- mega1280 + itg3205 + bma020(bw 190hz + LPF 2..3Hz) + hmc5883 + bmp085
- accum 3S 20C 2200mah or 2650mah

Total weight ~800..900g

https://picasaweb.google.com/lh/photo/G ... directlink

thx-
Alex

ziss_dm · Post by **ziss_dm** » Tue Dec 20, 2011 4:36 am

Hm...

2Hz is enough? How you testing? I'm usually do the following tests, to assest dynamic:
1) Enter to alt. hold with vertical speed (better to do it with baro clamped to constant value)
- go up - flick switch - should stop
- go down - flick switch - should stop
2) Set a set point 2-3 meters higher than current position

regards,
ziss_dm

mahowik · Post by **mahowik** » Tue Dec 20, 2011 4:52 am

ziss_dm wrote:2Hz is enough? How you testing? I'm usually do the following tests, to assest dynamic:
1) Enter to alt. hold with vertical speed (better to do it with baro clamped to constant value)
- go up - flick switch - should stop
- go down - flick switch - should stop
2) Set a set point 2-3 meters higher than current position

probably I'm mistaken but for the first look intuitively it give 2..3hz with cycle time ~3000
I have found lfpFactor=0.987 empirically when float LPF almost cut the ACC noise but still has enough of speed for IMU...

Code: Select all

        #define lfpFactor 0.987f //(1.0 / ACC_LPF_FACTOR)
        //lfpFactor = 0.9f + constrain(rcData[AUX2]-1000, 0, 990)/10000.0f; // k=0..0.99
        accTempF[axis] = accTempF[axis]*lfpFactor + accADC[axis]*(1.0f - lfpFactor);
        accSmooth[axis] = accTempF[axis];

I'm also using slightly increased GYR_CMPF_FACTOR=340.0f
It reduces the ACC value and increases the system feedback

so the answer: for me it enough

p.s. will do the tests as you described and post feedback soon..

mahowik · Post by **mahowik** » Wed Dec 21, 2011 5:34 pm

ziss_dm wrote:2Hz is enough? How you testing? I'm usually do the following tests, to assest dynamic:
1) Enter to alt. hold with vertical speed (better to do it with baro clamped to constant value)
- go up - flick switch - should stop
- go down - flick switch - should stop
2) Set a set point 2-3 meters higher than current position

I have done the 1st test this night. Yes, it looks a little bit crazy! Imagine some guy playing with copter IN THE NIGHT near the supermarket (it has big free area)...

)))
So the results:
- go up with vertical speed ~1m/s => flick switch => it's starting do reduce the vertical speed and after 1..2 meters smoothly goes down to position where the alt hold was activated...
- particularly the same for "go down"

mahowik · Post by **mahowik** » Tue Jan 17, 2012 11:45 pm

Hey Alex!

Why you remove velocity PD controller (i see that in trunk)?!
I'm sure it will not work without PD (particularly without D part)... I'm trying to integrate the sonar now and (this sensor has good precision... ~0.3cm), but i didn't get stability with only PI regulator (played with PID params and diff code variations about 2 weeks) but hasn't good results... it always has overshoot or low power to keep it stable in constant altitude...
So I suppose to compensate the altitude inertion I think we should use PI-PD as was before (i.e. ziss is right here

). You exactly know how our PI-PD regulator works for stable mode, where for PD the high frequency gyro data is used. For the ALT hold case it was velocity based on Z acc axis...

thx-
Alex

Alexinparis · Post by **Alexinparis** » Wed Jan 18, 2012 10:44 pm

Hi,
I removed it because:
- most of the working alt hold configs don't use the VEL PD
- velocity estimation is not very accurate (doesn't return to 0 when the copter is not moving), even with 8G settings

But I understand the analogy with GYRO/ACC. It's maybe be a temporary code.

Scotth72 · Post by **Scotth72** » Sat Jan 21, 2012 4:09 pm

I have two quads that hold altitude quite well using the VEL PD. Both are of different weights, and power systems. They just needed some fine tuning to get them dialed. I get up to a meter of fluctuation, in the wind. Most of the time less than a meter. BMA180 for accel.

mahowik · Post by **mahowik** » Mon Jan 23, 2012 4:40 am

Scotth72 wrote:I have two quads that hold altitude quite well using the VEL PD. Both are of different weights, and power systems. They just needed some fine tuning to get them dialed. I get up to a meter of fluctuation, in the wind. Most of the time less than a meter. BMA180 for accel.

just for the statistics... what PIDs do you use for the ALT and VEL?

ziss_dm · Post by **ziss_dm** » Mon Jan 23, 2012 6:10 am

Hi Scotth72,

Can you also share your tuning methods?

regards,
ziss_dm

shikra · Post by **shikra** » Mon Jan 23, 2012 11:19 am

Actually mine work very well too.
No tuning method for me - pure trial and error. Very close to default settings

Maybe it is luck, but the one thing maybe that is possibly a hint - I use a heli tx and spend time to make sure the throttle curve suits me and most relevant - the centre "notch" point of the throttle is bang on the hover. So the code maybe has an easier time to start from. Just putting tx to throttle midpoint makes it very close to hover. Not sure it would be so accurate without heli tx

Not really looked at Baro code as not of interest to me until GPS hold is there (so now becoming very interested

(in other words -

I wonder following suggestions...
- Tuning mode. No idea how to implement easily...
- A constrained +- MAXBAROVAR change value around a BAROMID value. Set in sketch following testing.
- Moving average - learn BAROMID
- Using vbat to help determine any bias over time. Horrible, but my bat changes 20% from full-->flat. Most is within 10% variation though
- Reset I to zero when passing midpoint

For last one...
Has come from some different FPV/level mode flying options I have been exploring...
Because of the relatively long time to recover to the desired position I think I is maxing out to its constrained value. Even when it passes the required point, the accumulated I is causing an issue with overshoot.
I wonder what the result would be to reset I to zero each time it passes midpoint. Maybe can run a higher I value without bad effects?

Again - I'm saying this without reading the code... I way be completely wrong with interpreation.....

Scotth72 · Post by **Scotth72** » Mon Jan 23, 2012 4:04 pm

I took the defaults someone posted on this thread: viewtopic.php?f=7&t=363&start=10#p6619.

I tuned from there. A screenshot from one of my quads.

I had an oscillation, so I turned down the ALT P. I then messed with the other parameters to fine tune.

I had little luck getting it to work until I turned on trusted accel z. Once enabled, the quad seemed to react quite a bit faster to up/down movements. Both baros are covered. One has a ear bud foam over it, the other a cotton ball. The larger quad also has a cd spindle case cover, with 2 3mm holes in in for air passage. The cd case seems to help with wind gusts.