I tried to add HFF filter a few times without success: the
hovering becomes unstable.
Can you describe this a bit more precisely?
I suppose the HFF filter adds some delay to the position and
speed estimation, leading to this unstable behaviour.
It *should* not add any delay, on the contrary it *should* have
less delay, since the acceleration and velocity is propagated to a
position (by default at 32Hz). Hence there should be less delay in the
position than with GPS only (normally 4Hz).
I'm working in V3.9 branch, with lisa m V2.0 and ublox lea 6H
GPS
Is it possible to tune the HFF filter parameters in order to
improve the filtering, and maybe obtain better position and speed
updates? I noticed the flag "USE_GPS_ACC4R" which adapts the filter
coefficients to the GPS speed and position accuracy. Does it help?
That should help quite a bit, yes. But not all GPSs provide the
position accuracy that is used for this (but the ublox do). Maybe you
should even try to define a smaller HFF_R_POS_MIN in your airframe file
(default is 3m accuracy).
Or, does anyone have recommendations to tune the HFF filter,
in particular:
This is the accel noise (variance of a gaussian) in m/s². Best
would be to take some measurements (with running motors) and compute
the variance of the scaled accel measurements.
If you have a lot of noise on the accels, increase this value.
Should be better with USE_GPS_ACC4R as long as the pos and vel
accuracty values reported by the GPS are ok (should be good for the
LEA6, but check them via messages).
Is it efficicient to specifiy the GPS delay in
the filter, with "GPS_LAG" parameter? What is this delay for let's say,
a Lea 6 GPS?
That is hard to say as the values are already filtered inside
the GPS and we have no clue what exactly is going on there... the delay
is definitely less than 1/gps_output_frequency.
Probably better to ignore the delay on a lea6, but you could
experiment with 0.1s, much more does not make sense due to the gps
internal filtering...
To some extent, yes.. it is not completely correct if you only
get new accel values at 500Hz instead of 512Hz.
I pushed a small fix to take this into account. Assuming you
have an aspirin2 with the MPU6000 you should add
<configure name="AHRS_PROPAGATE_FREQUENCY" value="500"/>
to the ap firmware in your airframe file.
But I don't think this has a big effect here, there are other
approximations that have a higher influence:
* simply take the mean of all the accel measurements since the
last propagation as measurement
* assumption is that the attitude was the same during that time
* assumption is that the attitude estimate was correct
Also make sure that these calculations don't result in a delay
of the rest of the main loop. Check with the sys_mon module.
So to summarize: it is easy to get worse position estimates with
hff if it the configuration does not match your actual sensors and you
have high noise on the accels.
On my old quad it really helped (compared to using my crappy GPS
directly), but on the other hand the hff probably hasn't really been
used since...
In the end hff is sort of a hack and should be completely
rewritten (or better even replaced by a full INS)... but to do it
properly we would really benefit from a floating point unit and more
importantly from a RTOS where we can let this run as a lower priority
task without corrupting the timing of the rest.
So much for now...
Cheers, Felix