Norritt

Thanks, interesting input. I will keep that in mind when I will test the new setup.
/Johan

RoyLB

Hi Gabe,
My goal is to build an indoor/outdoor quad using relatively cheap (MEMS) sensors. I envision 3 modes: "acrobatic" with rate command attitude/heading hold in the 3 angular axes and pure thrust control in the vertical axis; "precision or hover", with velocity command/position hold in X&Y, rate command/heading hold in yaw, and rate of climb command/altitude hold in vertical; "autonomous", which is controlled completely from on-board and/or a wireless laptop / groundstation connection. The first 2 will be r/c joystick based. The last might feature simple keyboard (or even voice activated) commands. Our first iteration will be based on an 8-bit AVR chip and MEMS gyros & accels. We'll add magnetometers, sonar/baro, GPS, and perhaps even vision eventually, and move to a 32-bit chip. But a lot is already being done out there in other projects with just the AVR and 6DOF sensors.

My thought on the complementary filter is that the MEMS gyro bias won't change too rapidly over the (15-20 min) battery life. I only use the accelerometer input in the complementary filter when the observed angles are small and when total accel is around 1 g. Otherwise, the filter maintains a constant gyro bias compensation and just integrates the gyro without any accelerometer input. As long as the quad hovers or moves at constant velocity for enough time to correct for the drift in the gyro bias, it should be OK (I hope!). This should also avoid the issue you mention above where the comp filter is corrupted because it continues to use accelerometer inputs during long periods of accelerated motion.

I'd like to eventually use a Kalman filter, if for no other reason than to understand how it works. I'm also considering an implementation inspired by this advanced SO(3) comp filter based on Mahony's papers http://gentlenav.googlecode.com/files/MahonyPapers.zip Have you seen them before?

- Roy

RoyLB

Huy,

There are several approximations / assumptions going on here:

- The vehicle has to have zero acceleration - either hovering or flying at a constant velocity. In this case, the acceleromter will measure gravity only and therefore can be used to determine the tilt of the airframe. (I mis-spoke earlier when I said the vehicle had to be hovering only.). We can check this by calculating the net acceleration and only using the sensors if the magnitude (sqrt of the sum of the squares) is close to one g.

- Attitude or orientation is a simple vector quantity, with the range of pitch, roll, and yaw being 0 to 360 degrees (or -180 to + 180). In fact attitude is a highly non-linear function (look up euler angles or quaternions). The closer the attitude is to zero, the better the approximation. If you want to have a quad capable of 360 degree flips, you'll have to manage the estimated attitude properly. I have ideas on this, but they aren't shown in the psuedo code snippet I linked to above.

The atan() calculations resolves the acceleration into the airframe body axes. The asin() one resolves it into a non-orthognal axis system that is based on the instantaneous acceleration vector - which is moving relative to both inertial space and the airframe. I don't see any reason to use it, and it may be causing the issues you are experiencing

- Roy

anthrax

Thanks for great answer, that's what I have been looking for .I'm getting clear now. It would be great if you share your idea to estimate attitude when quad performs 360 degree flips
Very good idea indeed, I will implement it into my Kalman filter code. Before I was using acc information to correct for gyro integration regularly without checking this condition

anthrax

ADI,
Thanks for your closeup pics and additional info.
I think it's not easy for me to find center 4 way joiner in my location and the washing baskets as well, unfortunately.
Anyway, I will walking around some shops to find them.
Huy

RoyLB

Huy,

My idea is to maintain an attitude command for each axis. Typically this command is an integrator on the joystick input. So the stick provides a rate command, which is integrated to calculate an attitude. Whenever the filtered (sensed) attitude exceeds +180 degrees, then subtract 360 from both the filter value and the command value. Similarly, if the filtered attitude goes below -180 degrees, add 360 to both command and filter.

The downstream PID (or other) feedback scheme only cares about the difference between the commanded and sensed (filtered) values, so there's no transient. But, the attitudes are always maintained between +/- 180 degres, no matter how many flips you perform. If you don't employ something like this, then your integrated gyro will wind up at 360 degrees after a full flip, but the accelerometers will read 0 degrees. Your filter probably won't like that too much.

- Roy

ADI

Hi anthrax,

Here's a pic of a 3 way uncut joiner. Available in 2, 3 & 4 way. They're sold in gardening department of hardware store.

Cheers ADI

anthrax

ADI,
Thanks for your useful info.
Roy,
Thank you for sharing idea,

I wonder how can you achieve position hold in X&Y without additional sensors such as GPS? or you integrate acceleration and gyro to obtain relative positioning information?

RoyLB

Yes - that's the idea. It won't be very good position hold without some sort of additional sensor...

gmhoffma

Hi Roy,

From our experiences, you're right. The gyro bias is fairly constant. The one caveat is that we use temperature compensation built into the 3dmgx1 IMU that we use (I think it's a feature of the analog devices chips that the IMU uses though). Without this, the bias can change more in-flight. It's an interesting idea to only use the accelerometer when accel is around 1 g. That should alleviate the chronic problem that I mentioned. However, just be aware that it can read 1 g even when it isn't at a constant velocity; you can apply 1 g of thrust any time you want to, and there are many flight patterns where one would transition through 1 g of thrust frequently. It really would help with the problem I mentioned though.

Kalman filters are really nice. If you want any advice, let me know. Don't bother unless you have a velocity reference from GPS or a camera though. Mahony's work is quite good. He's a nice guy, does great work. It still makes the same accelerometer-measures-attitude assumption as other complementary filters, but it is formulated well.

Cheers,
Gabe

RoyLB

Gabe,

Yes I am aware that there are flight conditions for which the accelerometer will register 1g even though velocity is not constant. I have also instituted a check for the estimated angle to be small (say between +/- 30 degrees of level) before the accelerometer data is used by the comp. filter. I hope these two conditions will be sufficient. In fact, during "precision/ hover" mode, I will probably just limit pitch/bank angle commands to +/- 30 degrees. This is the mode that we'll really need attitude information, mostly to compensate for the "unobservable" gravity component.

I know the MEMs gyros we're using have outputs that would allow us to provide temperature compensation. I don't think we're using them, though in the current board design.

- Roy

gmhoffma

Say Roy,

Are you doing this on your own? Or through a research project / work?

RoyLB

Gabe,

I am a rotorcraft controls engineer by day, but this project is just for "fun". There are a few other guys working with me, but I am the only controls or aero engineer. The others are EEs or interested hobbyists.

- Roy

gmhoffma

Roy,

Mind if I ask where you work?

RoyLB

Boeing.

RoyLB

Gabe,

I was just wondering what your thoughts were on using a (perhaps nonlinear) observer instead of a Kalman filter to estimate the vehicle states? I see claims in the literature that observers can attain similar performance with less complexity than the Kalman filter.

- Roy

RoyLB

Anthrax,

I don't know if you're still out there, but I think you are correct that the atan2() calculation is in error.


We've used anglex = -atan2(Y_Accel,-(Z_Accel)) to figure out the x-axis accelerometer based rotation angle. This works fine for a pure rotation around the x-axis. However, for a pure rotation around the y-axis, this computation will be in error. In the latter case, the Y_Accel value will be (roughly) constant, but the Z_Accel value will change. This will result in a computed angle that is changing even though the actual angle isn't changing at all!

Here's how to fix this: Replace the atan2() calculation with the following:

X_Z_Vector = sqrt(X_Accel^2 + Z_Accel^2) * sign(Z_Accel)
anglex = -atan2(Y_Accel,-(X_Z_Vector))

(note the minus signs are a result of my sensor configuration - you should keep the sensor signs that you have in your code).

This computes a length of a new vector which is the sum of the X and Z accel components and uses this in the atan2() calculation to give you the true perpendicular component of the axis of interest. For angle_y, just swap X_Accel with Y_Accel.

(I still don't have a real flying quad, but I'm making progress on algorithms. My friend also completed his board design and other software routines - http://www.rcgroups.com/forums/showthread.php?t=1075426)

- Roy