paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Hff Filter Tests


From: Kadir ÇİMENCİ
Subject: Re: [Paparazzi-devel] Hff Filter Tests
Date: Fri, 7 Mar 2014 18:07:41 +0200

Hi everyone,

Today i make tests with Hff filter for speed estimations. I turn off the Gps speed data for the filter input by disabling "HFF_UPDATE_SPEED". It seems that the noise on filter's speed output is less than the Gps speed data. 
1) "Hover_speed.jpg" image , multicopter was in horizontal hover mode successfully within a circle of 1 meters and the speed data of filter(blue line) seems more realistic and with less noise than the Gps speed(Red line)

2)"xd_vs_xd_measurement" image shows that filter output has less noise and i can confirm according to my naked eye observations, that in case of sudden turns (sudden turns on the graph ->filter output/blue line is more compressed at local min/max points) filter has more rapid response and has more realistic output.

I guess it will be more appropriate to use the Hff filter without speed data from Gps. I don't fly with waypoint navigation mode yet, but i can easily say the horizontal hover mode is more successful with Hff. Im expecting the same behaviour for the Navigation flights. As a result, i can advice this filter if you have a good acceleration data with little noise, otherwise filter can make worse outputs for the horizontal loops. On the other hand, i believe by reducing the effect of the acc. data on the filter (by increasing the variance value of the accelerations with Accel_Noise , Im using "4" right now) the filter will be still useful to get more data samples rather than 4 Hz, like using the filter to fit polynomial or simple lines between the last two GPS datas.

By the way im not planning to use GPS LAG option, since my acceleration values a little bit noisy.
Lastly, if you have a stronger AHRS with FPU support(like F4 devices) and a good isolation on accelerometers, the GPS LAG option may be useful too, and the Hff filter will make better results i believe. If you have a chance the Hff in  an environment such this, i will be happy to hear about the results..

Best regards

Kadir


2014-03-06 15:48 GMT+02:00 Felix Ruess <address@hidden>:
Hi Kadir,

thanks, order in HFF_DBG is fixed in master...

Cheers, Felix


On Thu, Mar 6, 2014 at 2:02 PM, Kadir ÇİMENCİ <address@hidden> wrote:
Hello everyone,

First of all i guess there is a little bug in /conf/messages.xml;

<message name="HFF_DBG" id="165">
      <field name="x_measure"      type="float"/>
      <field name="y_measure"      type="float"/>
      <field name="yd_measure"     type="float"/>
      <field name="xd_measure"     type="float"/>

the order of "yd_measure" and "xd_measure" is switched. It took 2 hours two find out why measured GPS speeds and filter output speed states are so different from each other :)

On the other side, good news from the Hff. Here are the results i have made, (all these logs are taken while flying)

1) On "x_measure_vs_x" image I observe the Gps  position measurements and Hff filter position estimates are so similar, there is no huge errors on the filter output.
2) On "zoomed_in_version" image, it can be monitored explicitly that the Gps output has a little delay according to the filter output, and the filter has lots of samples rather than 4Hz. It has a smooth structure without spikes like in the GPS positon data.

For the position estimates, Hff filter seems very useful, at least more data samples for an equivalent data even if there is so little lag compensation. Note: I don't use GPS_LAG option yet...

3)  On "xd_measure_vs_xd" image, it seems the estimated speed state and the Gps speed data are so similar, at least there is no huge error because of the wrong accelerometer inputs..
4) On "zoomed_in_version_speed" image, the filter output has little noise according to the GPS speed data. And the filter has more data samples rather than 4 Hz. But there is no
prominent positive effect of filter.

For the speed estimation i guess the usage of Hff has no effect at this phase. But there is another option for the Hff, not using the speed measurements from the GPS for the filter input. Since the speed data from the GPS has a huge noise and some delay, it may be useful to ignore the GPS speed data and to use only position measurements for the input of  Hff filter.  Im sure ublox has deeper knowledge and effort on speed estimation from the position data but we have acceleration data for our frames which ublox does not.

The next step for the Hff filter tests, is disabling the speed measurements from the GPS for the filter input. I will try to give the test results...

Best regards

Kadir


2014-03-05 13:56 GMT+02:00 Kadir ÇİMENCİ <address@hidden>:
Hello everyone ,
Today i start to test the hff filter on my quadrotor. First of all i observe the acceleration inputs for the filter ('b2_hff_xdd_meas' and 'b2_hff_ydd_meas'). The output is 'xdd.jpg' at the attachment(don't care about the label of the data, this is 'b2_hff_xdd_meas'). Here i want to mention the local tangent plane approximation works good. This log is holded while the rotorcraft flying, I believe the main source of noise  on this output is the vibration. Secondly i observe there is some noisy effects while the multirotor changes its orientation, due to some errors and delays on Ahrs side, but this effect is little then i expected. In conclusion the real horizontal accelerations can be seperated from the noisy output and i have decided that this acceleration input  may be useful with some little healings.

Here i have two options on my mind, what is your opinion?
1) The source for 'b2_hff_xdd_meas' is derived by taking LTP of 'acc_body_mean' which is the arithmetic mean value of the latest 16 acc. values coming from imu. Maybe more sharpener (IIR may be useful) filter with smaller phase delay (4-5 order etc) can be used rather than mean value of 16 inputs?

2) A filter on 'b2_hff_xdd_meas' directly before the input of Hff filter may be useful. I am not sure about this idea, it may cause the loss the meaningful data of horizontal acceleration.

Anyway with this point, i have decided to move a step forward without any modification in the source code. Afternoon, i will try to make deeper tests with position and speed estimates. By the way, i make settings on Hff as;

Accel_Noise = 4;

USE_GPS_ACC4R = TRUE  (I observe the pacc and sacc values coming from GPS, they seems correct to me)

HFF_UPDATE_SPEED =TRUE

Best regards,

Kadir


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


Attachment: Hover_speeds.jpg
Description: JPEG image

Attachment: xd_vs_xd_measurement.jpg
Description: JPEG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]