Hover Stability

[Dragos]

Hello everyone,

I'm trying to use the UAV Dev board for a VTOL model application
and I'm addressing this Helicopter discussion thread because I need
stable hovering first.

The DCM algorithm and the board themselves seem to be more than
helpful, thanks everyone involved but, in practice, there is a big
limitation I've encountered...

My idea of achieving stable hovering is to get the absolute
acceleration of the model regardless of it's attitude (taking out the
gravity component obtained through the DCM algorithm from the
accelerometer sensor) and sending the X and Y axis absolute
accelerations to PID controllers that would keep the model stable
(even in windy conditions, etc.).

I've actually went as far as replacing the gyros sensor inside GY401s
with a DAC on I2C interface getting absolute accelerations from UAV
Dev Board - replacing though the angular acceleration with the
absolute acceleration described above.

I was hoping to get a hovering as stable as the amazing head locking
of GY401 in helis... The result was not that good because I was not
able to get the the absolute acceleration precise enough and, worse
than that, drift-less. Yes, due to long time settling of rmat, the
abs. accelerations seems to have drift, huge drift ...

Note that this approach could be used for the Z axis as well, getting
a nice altitude stability ... I'm not a big fan of pure autonomous
flight but rather assisted. I have VFR pilot license BTW ;)

The code for getting the absolute accelerations looks like:

// gravity measured in the frame of reference of the ground
fractional gravity[] = { 0 , 0 , GRAVITY } ;

// gravity measured in the frame of reference of the plane
fractional gravity_p_ref[] = { 0 , 0 , 0 } ;

// gravity component in the plane reference
fractional abs_acceleration_p[3] = { 0 , 0 , 0 } ;

fractional rmat_transpose[] = {RMAX, 0, 0, 0, RMAX, 0, 0, 0,
RMAX} ;

read_accel() ; // to update gplane (acc vector)

setDSPLibInUse(true) ;

MatrixTranspose(3, 3, rmat_transpose, rmat )
// get the gravity component in the plane frame of reference:
MatrixMultiply( 3 , 3 , 1 , gravity_p_ref , rmat_transpose ,
gravity ) ;
// substract the gravity component from the accelerometer
readings:
VectorSubtract( 3 , abs_acceleration_p , gplane ,
gravity_p_ref ) ;
// project the absolute acceleration of the plane frame of
reference to the the ground frame of reference:
MatrixMultiply( 3 , 3 , 1 , absolute_acceleration , rmat,
abs_acceleration_p) ;

The success:

It seems to work: I play with the board and, regardless of the
attitude, the absolute_acceleration shows something only if the
position of the board changes, not the attitude.
Note: Since I only have the IMU setup (no GPS/MAGNETO) and the
drift on Z axis, in about 3-4 minutes Y axis gets replaced by X! So
take care if you try the same and don't know what's going on.

The problem:

after few attitude changes followed by steady position, the
absolute_acceleration converges very slowly to 0 and this would be a
killer for achieving a good hovering. (this slow convergence is in
fact visible in any component of the rmat, etc.)

The question:

Is there a solution to that by using:

1. Much better sensors (high precision accelerometers like
SCA3000 , lower drift gyros, etc.)

2. Tuning of the algorithm for this particular case where tha
acelerometers mesures mostly gravity (I've tried to play a little
with KPROLLPITCH and KIROLLPITCH but couldn't get a difference)
Maybe, I hope, this is the key... maybe Bill can help here.

3. Anything else inertial based or moving to Optical Flow
stabilization (Parrot like) is mandatory...

Note: I've also tried the PNI SpacePoint which is Kalman filter
based but that's even slower.

Thanks and Regards,
Dragos

[olly]

Hi Dragos,

forgive me if I'm speaking out of turn (and perhaps don't understand/
appreciated your methodology).

For the design of an attitude command attitude hold controller one
would seldom use the measured accelerations directly

"and sending the X and Y axis absolute accelerations to PID

controllers".
Acceleration is a noisy measurement (and, from what I understand,
there are no accelerometers available that can provide a suitable
signal for tracking control). The only way to attain a suitable signal
for control is to filter it (or in our case intergrate). This is why a
PID controller is usually fed an error signal based on the desired and
current attitude of the craft; the respective components of the
controller acting on the attitude (P) accumulated error (I) and the
angular rate (D).

Certainly using a gain on the derivative component of the
accelerometer signal would be particularly problematic?

best,

Oliver

[Dragos]

Hello Olly,

Maybe my knowledge in robotics are not very strong (PID controllers)
and that's why I didn't try to "reinvent the wheel".
Instead (as explained above), I've used an existing device (the full
GY401 head-locking system with all that's involved there - filters,
integrals, derivatives, etc.) but feeding it with an absolute
acceleration input instead of the analogical MEMS gyro sensor input).

I don't understand your concern about the noise of the accelerometers.
They do have noise but I'm sure that in a highly vibrating environment
like the helicopter one, the original gyro sensor will also show
plenty of noise too and still be able to lock the tail.

I believe that if I'll be able to get the absolute lateral
accelerations accurate enough (very fast and without accumulating
errors), even being them noisy, I would be able to compete with the
GY401 single Gyro sensor (which by the way will drift at some
point...) and obtain a position locking precision comparable with the
original Head Locking.

As for the accelerometer choice, I was pretty impressed by the VTI's
digital SCA3000 spec, the sensitivity for the +/-2g one is ~ 1mg = 1cm/
s^2

Cheers,
Dragos

[John McClelland]

Hi Dragos

As I mentioned to you earlier, I have also played around with integrating
the accels to get velocity and position. I find the errors build up quickly
and need some other sensor input to "reset" the accel calcs on a somewhat
frequent basis.

Bill has written a Dead Reckoning routine that does just this. He
integrates the accel data at 40Hz then uses the GPS to "reset" the
integration. For the standard GPS this hapens at 1 Hz. I believe he takes
into account the lag in the GPS data due to its internal
filtering/calculations.

This has been flown on airplanes with success. I think Bill may be working
on a Quad version. I intend to impliment on the Heli code at some point as
well. We are looking at a Baro sensor for altitude, but will likely need an
ultrsonic for altitudes near landing. Jerry is doing some testing on both.

I believe he gets accuracies of about 1 meter. We will better for a heli
hover. He liives near an airport so I suspect he may benefit from
differntial GPS resolutions. Since the GPS will not report velocity
information if not moving, things may be a little different for static
hovers, but should work with some mods.

I don't think the accels are the limiting factor on accuracy, but rather the
roll/pitch/yaw attitude estimations from the DCM to do the transforms.

Bill and I have also been developing and testing a Heading Hold replacement
for the 401 with some success as well. This uses a magnetometer. I hope to
release this in the next version of MP-H.

Do I understand that you have a software clone for the 401? This was the
basis for the HH code. I wonder if we can compare notes.

Best,
John

[John McClelland]

Dragos

One other thing I might mention. We did a lot of work on filtering and
gains as part of the HH development to replace the 401. This could be
relevant to your sluggishness problem.

We found that any pre filtering of the gyro data going into the PD (we only
used proportional and derivative gains) caused exponentially growing
oscillations. So only the offset corrected gryo data was used. Setting the
gains was rather tricky. There was a narrow range of gains that worked. We
came up with a tuning procedure that seemed to work. These could only be
observed in flight in the vibrational environment in closed loop...can't
just set them on the bench.

One thing I found useful was to log the HH output in flight and give the
heli a quick yaw input. I could then observe the response of the
controller. This let me map out the gains (together with some relationships
amongst the gains based on modeling the control loop...without these
relationship we may never have zeroed in on the right gains).

Best,
John

----- Original Message -----
From: "Dragos" <drago...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>
Sent: Tuesday, January 11, 2011 3:13 PM
Subject: Re: Hover Stability

[Dragos]

Hello John,

Thanks for the analysis.

I'm doing experiments indoors, I would prefer not to rely on GPS... Of
course, for eventual hovering at higher altitudes, GPS is the best
instrument to use.

I agree with you that the hard/impossible part may be the attitude
estimation. I've just hoped that in the "simple" dynamics model of
hovering the DCM would be easier/more precise to estimate.

If I had much better gyro sensors, being able to disable the
accelerometer correction for awhile without noticeable error, I could
live with stable hover for only let's say 30 seconds. I only need
hoover for takeoff and landing...

As for the 401, no I didn't hack the SW, just the hardware - I've put
a 12bit DAC's output instead of the ceramic Murata gyro sensor (and if
Futaba guys are reading this - they should be happy cause I did it to
a 401 clone, not to the original one). Data was sent through I2C to
the DAC from UAV Dev Board

B.R.
Dragos

On Jan 12, 1:57 am, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[John McClelland]

No Problem.

You should know that Bill is the expert on all this...

I also remember seeing some videos of airplane hovering in the standard
MatrixPilot SW. I think the gyro drifts are not so bad. I have measured
them with the HH software without GPS and it is quite small. You might post
what you want to do on the main MatrixPilot development site:

http://groups.google.com/group/uavdevboard?lnk=srg&hl=en

The airlane guys may have some good info. There are Hover options in the
standard MP 2.5 release.

http://code.google.com/p/gentlenav/wiki/MatrixPilot

Look in the options.h file.

Best,
John

----- Original Message -----
From: "Dragos" <drago...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>