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: Felix Ruess
Subject: Re: [Paparazzi-devel] Hff Filter Tests
Date: Thu, 6 Mar 2014 14:48:34 +0100

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



reply via email to

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