Using Accelerometers vs. Thermopiles as tilt/level sensors

[Daniel Wee]

Hi,

I've been following Gary Warner's thread on his yaw correction and his use of the accelerometer as the sensing element. While it worked for his application, some of the raised objections are in fact a problem for my application, namely the static-dynamic-G sensing issue.

Basically my project aims to keep a helicopter level. The controller takes inputs from the receiver for the cyclics and mixes this with corrections based on readings from an accelerometer.

When I tilt the helicopter by hand, I can see the swashplate being tilted in the opposite direction. This is correct behaviour. However, once in the air, I experience several problems. Firstly, I am seeing quite a bit of oscillations. This I've partially addressed by implementing a moving average system, which is a kind of low pass filter I suppose.

Secondly, there's quite a bit of jitter resulting from the vibrations in the heli itself. The moving average also addresses this issue a little bit.

Unfortunately, while in the air, I do not see the compensation/correction effect.

In any case, my question concerns the issue of dynamic acceleration effects on the sensor. Once the heli is moving, the accelerations will corrupt the static tilt readings.

So, suppose the heli is tilting to the left (which usually means the heli is moving to the left), the controller will correct by giving a right aileron input to tilt the rotor disc to the right. But if the heli moving (accelerating) to the left (due to wind for example) this results in the same output as if the heli was tilted to the right, albeit only for the duration of the acceleration.

Does this rule out the use of accelerometers as tilt sensors in dynamic platforms?

I can post some videos if anyone's interested.

Daniel

[Tophinater]

What kind of accel are you using?

Also have you thought about using a mercury switch at all?

[Daniel Wee]

I was using one of the micro-machined accelerometers. Having thought about it, it appears that all gravitometric tilt-sensors/inclinometers will suffer from the same problem. The key is to get a non-gravitometric point of reference, which unfortunately leaves me with Optical/IR or Magnetometric methods. I'm trying to avoid the usual thermopile due to it's susceptibility to environmental factors such as buildings, heat sources, etc. And magnetometric methods tend to require considerable separation, meaning size becomes an issue.

[Comatose]

Daniel,

I played with accelerometer-only stabilization on a fixed wing platform. It can work, with the following caveats

Gain can't be very high
Not suitable for much in the way of aerobatics
not suitable for takeoff acceleration

I had one big "hey that was really cool" moment, when I actualy had the flight battery ejected and hanging on by the wires, and with no control input (and a WAY rearward CG) it just came in extremely smoothly for a landing. I also got stable cruise working with a naturally unstable airframe (rearward CG and anhedral) but boy was it squirreley to launch.

MEMs rate gyros plus accelerometers makes a MUCH better combination. Basically using the gyros to fly second-by-second and using the accelerometers to cancel gyro drift when you're pretty sure you're in a non-accelerating position.

[Mr.RC-CAM]

...gyros plus accelerometers makes a MUCH better combination.That is a very effective way to create the stability system that is sought. The usual implementation uses the gyro and accelerometer with a DSP based Kalman filter.

[Daniel Wee]

I think it's probably a bit easier for planes. With helicopters it gets a lot messier because we can move in 3-dimensions.

I may have a solution based on orthogonally positioned vertical sensor. I'm working on a routine to cancel out lateral accelerations (I hope). It's not perfect but it should reduce the effects of lateral acceleration a little bit and hopefully that will make things easier.

Daniel

[mrbaseballny]

Here is circuit that I just completed that uses a accelerometer that is used to sense tilt and keep your plane level. although its not used for forward flight only for hovering:)


Take a look. I wil lbe posting some more info as well as some questiosn to the rest of the DIY electronics folks for solutions to some features I would like to add, like remote sensitivity gain throug hthe TX, as well as some sleep mode questions.

[Gary Warner]

I can post some videos if anyone's interested.

Daniel

VIDEOS!!! Can't ever see enough videos.

Daniel,

Understand I've put a total of 5 minutes of though in this, but here's my thoughts.

With a 3 axis accelerometer it might work (or 2 x 2 axis sensors). First, I'll address just the roll axis and the use of a single 2 axis accelerometer. I had to consider this in the Hamster project.

One issue of the Hamster involves dealing with vertical acceleration while in forward slipping or skidding flight. An example of this would be changes in the elevator while slipping or skidding, or as in vertical changes due to turbulence, lift and sink. In simple terms, the gain of the yaw axis error is effected by changes in vertical acceleration. The principles would be the same for hovering a helicopter.

Ok, here we go. The sensed axis that is parallel to the ground can be simply read and outputted as roll error data. Since vertical acceleration can change the "gain" of this axis, it's needed to read and correct for the vertical axis too. So, the other axis of the accelerometer can be used to sense vertical acceleration. That data can be used to adjust the gain of the horizontal axis data.

Man, it's had to explain in words... Try this. horizontal axis senses right and left and vertical sensor senses vertical acceleration. Start with the helicopter erect and level. Data from the right/left sense will be 0 G's and the vertical is 1 G. In code, the vertical data would be normalized to show a "zero" value of vertical G's when at rest (1G). Now tilt the helicopter right or left on the roll axis. Data from the roll axis will show an error in that direction (the error you want to correct for). Also, the vertical axis will show a reduction in perceived gravity and its data would indicate a loss of vertical acceleration.

Now, to keep the altitude (vertical acceleration) under control, we need to know the proper value for the vertical sensor data (it's easy to get in a standard math formula) for any given angle of roll. This data needs to integrated into the roll axis data so that the combination of both axis errors in tilt can be calculated as angle of tilt. The whole reason for sensing the vertical axis is that changes in vertical acceleration will apply to both sensors, allowing you to find out what the vertical rate is and to remove the vertical acceleration error component from the roll sensor.

All this said, this would rite a helicopter if the sensor was centered over the roll axis and fixed to the ground on a gimble. But in the real word, a tilt in roll axis creates sideways acceleration too (slip skid theory). Again the two sensors are used in noting differential trends in data. Roll left and it starts to accelerate left. the left error data will reduce and the vertical error data will increases with acceleration. This could be sensed and added into the correction equation. Is your head spinning yet :p?

Be prepared for some major code and math. It's possible to add the 3rd axis (forward and back tilt) in the same fashion. Effectively, you need to know what the vertical acceleration is in order to accurately read the other two axis degrees or error. It won’t address ‘holding’ a given altitude, but it will address vertical acceleration and give you the vertical error data to correct for pitch and roll errors.

Again, 5 minutes thought. I might be nude in a snow storm on this one.

Gary
--

[Daniel Wee]

Have you tried this out on a heli? I'd like to know how it fares. Thanks.

Daniel

[Daniel Wee]

Thanks Gary,

That's pretty much what I had in mind when I mentioned the vertical axis sensor. I'm using it to detect the lateral acceleration component. The drawback here is that the lateral acceleration may not always be parallel to the X or Y sensor. More often than not it's a mixture and as such cannot be fully accounted for unless you have two vertical sensors that are only sensitive in the plane of X and the other on the plane of Y.

The relation of the X and Z (vertical) sensor readings seem to be non-linear, even after I've linearized the outputs individually. Based on this, it looks like I might need to have a table to show what is the expected Z value for every X value and then work out any deviations from there. But because there's the Y component in the Z reading, the table actually needs to be a 3-dimensional array. If this is done, I will know what the Z is for any given X-Y combination (maybe with some linear interpolation for the gaps) when the heli is static. From any deviations from this expected reading I should be able to approximate the X-Y compound acceleration vector that is in effect although I cannot determine it's direction. I do know though that any lateral acceleration compensation cannot be more than the approximated acceleration value.

I'm thinking that at this point, some guesswork is in order. That is to say, based on the readings of X and Y, and what we know about the acceleration, it may be possible to make a good guess as to where the acceleration is in greater effect. Add to this the fact that I am maintaining a history of some 20 to 30 readings, I can actually make use of extrpolated data to confirm the guess.

I'm off to bed now. Will come back here and later post some videos of the progress.

Daniel

[Gary Warner]

Thanks Gary,

That's pretty much what I had in mind when I mentioned the vertical axis sensor. I'm using it to detect the lateral acceleration component. The drawback here is that the lateral acceleration may not always be parallel to the X or Y sensor.
Daniel

That's why I said to use a 3 axis accelerometer. I explained the basics in 2 axis as it would have been too complicated explain in 3 axis. I’m glad to see that you are thinking the same way I am. I hate going out on a limb, just to have it break.

This would be a good start: Setup a 3 axis accelerometer and find/code/use the data to find any degree of roll and pitch (exact angle, not relative angle). The nice thing about accelerometers is that the angle of tilt computes in math reliably.

So get the math worked out to find the true angles of error. Then add the data from the vertical axis and you should know your exact angle of tilt/roll that will account for vertical acceleration. Then use differential data to find lateral acceleration. Do this all right, show practical success and NASA has a job for you.

My head hurts. :)

Gary
--

[Daniel Wee]

I think I solved it. The Z sensor output at that particular point is rather inaccurate though, resulting in jitters. This is because of the non-linearity in the sensor. Now I need a smoothing filter on the Z-axis which may introduce some lag but I think it should be okay.

Daniel

[Daniel Wee]

Just a little update here.

First of all, sorry that the video is not forthcoming yet. I've taken the shots but because the software development is progressing every day, it keeps getting outdated. Furthermore I'm still working on the development so I have little time to edit the video.

In any case, I think I've got the problem solved for a single axis. As it turns out, the Z-axis sensor is not omni-direction and is planar, parallel to the X-axis. This allows me to use that to work out the compensation for the lateral accelerations in the X-axis and this seems to work, generally speaking. However, you need a few tricks to properly get around the quirks of using this system. First of all, the Z-axis sensor is at it's lowest sensitivity at this point and has a very low resolution (jittery) output. You'll have to smooth this out for best performance but I've not gotten around to this just yet. Well, I do have an averaging algorithm but it's not working too well, probably not enough samples. Secondly, your ADC resolution needs to be fast enough, at least twice the frequency of the expected vibrations in the system. This will allow for accurate averaging later on, so you won't have aliasing problems.

On top of this, you need to track the rate of change of the accelerations measured in the X-axis to discriminate the lateral accelerations, as opposed to vibrations and other hover movements. This is not very difficult but you need a sensitive discriminator because there is a lot of noise in the data arising from vibrations. With all these, and knowing the direction of the acceleration, you can compute the lateral acceleration, and from there the required compensation, and apply it in the correct direction on the X-axis.

I've actually implemented this on the prototype and I can see that it is having a correct effect although it's still not where I want it to be. If I can smooth out the jitters and overall response, I will have completely solved this problem in the X-axis.

Now, since I have no secondary acceleration data in the Y-axis, this means I'm stuck unless I specifically add another vertical sensor that is co-planar with and orthogonal to the Y-axis sensor. For the moment though, I'm just going to try and sort out the X-axis because if it works, the Y-axis compensation should also work.

I'm wondering at this point if anyone else has worked on something similar for heli auto-levelling and/or has info to share or design points to offer for consideration. I'd be happy to just hear of your experiences.

Daniel

[Daniel Wee]

Bad news. I'm back to square one here. Having given it a bit more thought, I do not think that any kind of accelerometer will on it's own be able to provide level sensing with respect to absolute gravity alone. There simply is no way to discriminate the data. The basic thing is this, when you're in a plane and if the plane is banking, usually you won't notice it because the relative acceleration vector that you are experiencing is still pointing downwards. Similarly, the sensor mounted on the platform will not be able to tell where the 'true down' is because it is being subjected to compound forces. In other words, this is a cul de sac.

Gotta come up with some other scheme. I wonder how the artificial horizon sensors on planes work. Any one have ideas?

Daniel

[jeffs555]

The conclusion you have come to is one that numerous full scale pilots have learned the hard way, and are no longer with us. Full scale planes use gyros as artificial horizon sensors.

[Terry S]

Like MR RC-CAM and Comatose said, you need BOTH accelerometers and gyros to do the job.

Terry

[Daniel Wee]

Funny you should mention that jeff. I was just thinking last night that I can use a two gyros, one for the X- and another the Y-axis to actually provide me with rate of change of tilt. Integrating this data should give me actual change in tilt angle and by comparing this angle to the angle supplied by the accelerometer, I can work out the difference which should be the lateral acceleration. From there I'm thinking that it should not be too hard to work out a compensation scheme. The thing is that now this gets a bit more complex and I need to get hold of two modular gyro units.

I got thinking about this when reading the blurb on the Crossbow's sensor where they mentioned gyros. Now, I have to re-think my microcontroller choice due to the extra i/o requirements. We'll see where this goes. Still haven't given up yet.

Daniel

[Mr.RC-CAM]

In essence, that is the bases of the Kalman Filter.

[Daniel Wee]

I'm just wondering if there's any technical problem as to why no one else seems to have done this for the r/c market. I know thermopiles are much cheaper and easier to work with but if this thing works, it will have a lot of advantages, including the fact that it will actually attempt to hold a position laterally, as opposed to simply trying to level out. I know there's the issue of cost for the sensors, and am wondering if there's a market out there for these things.

Daniel

[Zlatko]

Daniel,

Cost :)

If I remember right 6DOF 3x accelerometers/ 3 x gyros setup was about $400.
http://www.sparkfun.com click on sensors and scroll to IMU 6 Degrees of Freedom ($350) . There was another one which was programable and had servo signal output but can't remember where I saw it now .

FS8 Copilot complete for $150. :)

Cheers

[Daniel Wee]

Yes, that's true but the 6DOF unit includes a lot of things you don't need such as the bluetooth and USB functions, or even the additional controller stuff. What you really need is just 2 of the Gyro/Accelerometer combo's mounted perpendicularly. Granted that it's still not cheap at $115 a pop - $230 for sensors, but I think this is quite a good deal for the performance you can actually get out of it when working right. I'm thinking of pressing on with this project with those very sensors.

Daniel

[Mr.RC-CAM]

There is an open source stability system project that perhaps you can use:
https://sourceforge.net/project/showfiles.php?group_id=36164
http://autopilot.sourceforge.net/

There are very high end commercial stability systems out there. But they cost several thousand dollars because the development requirements are steep and the market is small. One that reportedly works very well is the Carvec: http://www.carvec.co.uk/

[Gary Warner]

Bad news. I'm back to square one here. Having given it a bit more thought, I do not think that any kind of accelerometer will on it's own be able to provide level sensing with respect to absolute gravity alone. There simply is no way to discriminate the data. The basic thing is this, when you're in a plane and if the plane is banking, usually you won't notice it because the relative acceleration vector that you are experiencing is still pointing downwards. Similarly, the sensor mounted on the platform will not be able to tell where the 'true down' is because it is being subjected to compound forces. In other words, this is a cul de sac.

Gotta come up with some other scheme. I wonder how the artificial horizon sensors on planes work. Any one have ideas?

Daniel

Defeat is not in my credo... (Louder… Say it with me)... Defeat is not in my credo!!

No!!! Don't give up!

Look, if vertical acceleration can be computed from the Z axis, then corrective input to the Y axis is possible. What it sounds like it’s that it's 'too hard' to code. That's cool - coding is not a picnic; it's hard work.

Hey. I'm not going to take on your coding task (and a significant task, it is), but I challenge anyone to find a LEGITIMATE reason why accelerometers can't be used to compute 3-d stability.

For thoughts who would say this or that and that it wasn’t possible, I'll respond in a way that demonstrates that it will, though I'm not going to code the math for them.

I stand by one overwhelming concept... Gravity is what we are trying to overcome and stabilize against. It's a function of perpendicular force stability. With the force in a known attitude and our stability in a known relation to the stable force, it only makes sense that reading and adjusting for those forces of gravity will result in stable attitude and attitude awareness.

There are people that have failed in their attempt to control a device by means of acceleration forces. The list is long and filled with blood (full scale). Don't become just another failure that suppresses the next in-line with thoughts of… 'Not a chance in :censored: ' mentality.

Be a trail blazer. Find the answers. If it was easy, everyone would be doing it, yati, yati, yati...

All this being said, I want to hear from you... what are the factors that exclude acceleration from controlling perpendicular flight/control to gravity? If you can define an absolute example that shows that the laws of physics will be broken, then I'll shut up. Until then, I think you are taking the easy way out.

Now, when you want to get back in the game I have some ideas to address you above comments. But I'm not wasting my time if you are quitting.

(Wow - I sound so mean... but after re-reading my post I stand by its tone. It's tough love... Figure it out or become another failure in re-inventing the wheel of failure)

Gary

P.S. The Hamster needs a FULL REVAMP - I was ready to sell it just a few months ago, but it's not perfect. I understand the frustration of two steps forward, one (no, make that 3) steps back!! Long live TRUE PROGRAMERS (not just coders).
--

[LukeZ]

I'm just wondering if there's any technical problem as to why no one else seems to have done this for the r/c market.
Daniel, I may be wrong on this one but another reason why I don't think it has been done much as of yet is the difficulty of arriving at a stable and workable Kalman filter implementation. I've been hearing the word Kalman all over the place for as long as I've been interested in this stuff, but thus far only a very few people have actually successfully implemented one. The autopilot project that Mr. Cam mentioned is one, and having gotten that down, they then went on to form their own company (Rotomotion). There is info on their filter implemention on SourceForge (RC-Cam gave the link), but they designed it for a heli, not fixed wing, and I understand the differences between the two are substantial.

The Paparazzi people have been talking about going to accelerometers and gyros for some time, but again, I think the reason they have not is because of the Kalman filter beast they have to confront. I could be wrong, but that's my impression.

If this community or some other could come up with a workable Kalman routine for fixed-wing aircraft, it would fill what I see as a pretty big gap in the field at present. Yes there is still the issue of cost of sensors but I believe in spite of that there would still be a market/interest. The fact is thermopiles limit where and how you can fly. For a lot of uses that's fine, but for a lot it's not. If the code could be worked out, even at $400 for a sensor suite, and a little work on the side, you're still way ahead of the game compared to buying an off-the-shelf solution, which all run in the thousands.

Not saying I'm the one to do it... the math is just over my head. I've begun to consider maybe hiring a math professor to help me figure some of it out, since waiting for it to happen by someone else doesn't seem to be going anywhere. Perhaps you could be the one? :D


Luke

[Mr.RC-CAM]

I've begun to consider maybe hiring a math professor to help me figure some of it out...FWIW, Rotomotion claims to offer a UAV Development Kit (including training and phone support). I have no idea what they provide in the tool kit or what they charge, but it might be another way to develop your stability system.

The sad truth is that these sort of applications are serious affairs that usually involve hundreds of hours of engr development and endless test flight sessions. If the open source autopilot project has working source code and hardware details then it could help reduce the task to something that a talented mortal could manage. I would love to see someone do this and then be benevolent enough to share a low cost DiY project that less skilled folks could build.

By the way, the Gyration multi-axis piezo gyroscope is under $40, so that hardware component is very affordable. Add some cheap solid state accelerometers and a whopping heap of software, and you are done. :)

[Daniel Wee]

Okay, a couple of things.

Gary, the reason why the accelerometer cannot be used to stabilize a moving platform with respect to the ground is because the sensor experiences the compound forces of any other acceleration along with the gravity. So, if you're in a plane and the plane was banking, you may not feel the bank because your relative "down" is the same. However, the plane is not level. The accelerometer feels the same, it doesn't know that the platform is not level and thinks it's level.

This can work IF the accelerometer were kept level with respect to the ground, then the readouts would make good sense and you can work out any lateral accelerations. However this is not possible. Any derivative info from the Z-axis is partially useful at best. To be sure, I actually managed to compensate for lateral acceleration in my prototype and tested it to work. BUT this only works when the heli is level in at least one axis. I can't assume this to be the case always.

So, the bottom line is that a blind passenger in a plane flying around cannot pinpoint with accuracy the direction of the ground based on the seat of the pants feeling. This is what we're trying to do. We need a separate point of reference and that would be where the extra gyros come into the picture.

As to the implementation, I've already coded most of the actual servo control and correction code. The passthrough also works and I actually have a working prototype to test this thing on as I develop the code. I've got it strapped to a T-Rex right now and test my code changes on it. The way I see it, the use of the gyro input to implement what is said to be the "Kalman" filter isn't that hard. All I need from the gyro is one additional data point for each axis, ie. relative turn from integrating the rate of turn, and incorporate it into what I already have right now, and we should be good to go. I don't think the data has to be very precise since the platform itself is "floating".

My current code and prototype already attempts to stabilize the heli but the moment any lateral acceleration occurs, the heli will bank in that direction and start going faster in that way. This is because acceleration to the left looks the same as a tilt to the right. So when the code tries to compensate by tilting to the left (to what it thinks is a right-side tilt), it just makes it worse. The readout of the sensor is therefore the sum of your tilt and lateral acceleration. I'm planning to get the tilt amount from the gyro, and then subtract it from the accelerometer's compound output leaving me with lateral acceleration. The stabilization now doesn't work on the basis of tilt, but on lateral acceleration. This is better because it will try to prevent the platform from moving, as opposed to simply keeping it level. This will result in far better performance than any simple levelling scheme can provide.

My code current has a moving average routine that smooths out some of the jitters arising from noise and vibration. The whole thing is coded in assembly incidentally. I'll go look at some of the links above (Thanks RC-CAM).

Daniel

[Daniel Wee]

Hmmm... interesting. It looks like the sourceforge autopilot project started off with the gyros and ended up needing the accelerometer as well. In other words, it looks like we've come to the same logical conclusion. I guess I'll have to pony up for the sensors. Darn, this experiment is expensive.

Daniel

[Gary Warner]

One more time... you must resolve the true angle of tilt error from each sensed axis in order to apply meaningful data to your code. Check accelerometer datasheets about the topics of determining the angle of tilt. Simply put, you need a Sine lookup table when using a PIC, unless you are into head banging bit math.

I used 128 bytes of lookup tables that gave me an average angle resolution of .7 degrees (well enough for me). You could use 256 bytes to double the resolution to .35 degrees. The lookup tables can even be in an I2C EEPROM if more space is needed. I could not use the external EEPROM due to processing time limits.

As I said before, resolve the absolute static angles of tilt before trying to apply sensor correcting data from another axis to the output. If I understand what you are doing and what you've done, think about it and you'll see what I mean.

Example: from 0G's to 50% output change as compared to 1 G on the roll axis is 30 degrees of tilt. I think you are taking the output of the sensors and assuming that 45 degrees is 50% output to the 1G orientation. This is not a big deal for relative error sensing, but if you plan on using another axis to correct for lateral acceleration, you must use the absolute angle data.

Not being right next to you, I can't tell if I'm on the right track based on what you've implemented. Let me know what sensor data translations (if any) you have used.

Then again, if this dead, it's dead. Using rate gyro data can and has been used to detect and control accelerometer gain. Like in the Hamster, a gyro could be used to sence if yaw is felt and open up the gain of the accelerometer correction. If no yaw (or limited yaw) was senced, it would shutdown or reduce the accelerometer gain. I didn't implement the gyro on the Hamster due to excessive costs and that I've been able to use the second axis to detect vertical acceleration (HINT: it can be done).

Gary
--

[Daniel Wee]

Hi Gary, I am in fact using a 512 point arcsine table to resolve the actual tilt angle from the sensor output. The problem though is that you CANNOT get the actual tilt output because the sensor senses acceleration. Now, in order to get actual tilt with respect to the ground, you need to resolve the sensor output into two components, acceleration due to gravity and actual platform acceleration relative to the ground. So now, imagine this, the sensor presents you with an output, which you can translate into angular data using an arcsine table. But this angular data is not pure tilt (gravitational) because it is potentially mixed with any other acceleration that the sensor experiences.

The question you need to address is this - can the sensor distinguish between acceleration due to gravity or due to movement of the heli? Take the following two examples:-

1. Heli is tilting left 90 degrees. The x-axis sensor senses a 1g acceleration and outputs this which is translated into angular data - left 90 degrees.

2. Heli is level BUT is accelerating to the right at 1g. The same x-axis sensor senses a 1g acceleration, and the output is translated into angular data - left 90 degrees.

Now, how do you propose to distinguish between the two scenarios above given that the output is the same?

You may suggest the use of the z-axis sensor but the z-axis sensor has exactly the same problem distinguishing the two types of scenario. If you have a way of solving the above without using an external reference point, I'd like to hear it. Right now, I just don't think this is possible.

Daniel

[Gary Warner]

Ok, I'm thinking...

The Hamster does not worry about continuous lateral acceleration do to the flight dynamics the say if the plane is not skidding or slipping, there is no vertical forces messing around with the side forces, even as vertical forces (read: vertical rate) change. Also, a sailplane is yaw stable. That is it will naturally want to return from a skid or slip. The reason for the Hamster is to reduce the amount of error by starting correction as soon as an error is sensed.

Vertical forces are only considered IF the plane is skidding or slipping. I resolve the issue by adding or taking away the vertical correction data from the perceived slip/skid angles of forces. This is where bringing both parts of the two axis data into the code in reference to angles of error. This makes the math much easier to handle.

I demonstrate this to pilots by holding the plane level. I move the plane up and down and the rudder does not move, a no brainier. Then I tilt the wings in a roll, simulating a slip of skid. The rudder moves to the side of the lower wing and stays there ("stepping on the ball"). Again, I move the plane up and down at this bank angle and the rudder does not move. Actually there is a tinny bit of movement that I need to remove, but nothing like just using one axis input. Using a +/- 2 G sensor, I can remove the vertical component up to a 60 degree bank if the turn remains coordinated (2 G turn).

My original version of the Hamster would have the rudder going nuts in the latter demonstration. This would cause the need for roll and pitch correction as the rudder would move responding to vertical acceleration. Roll coupling would change the bank angle, pitch (elevator) input would change roll and changes in bank angles would requires pitch changes to maintain a correct AOA and so on and so on, each effect intermixing with the other. It made the plane uncomfortable to fly.

So, as I said (at least in my application) vertical acceleration can be removed from raw slip/skid sensor data.

I spent a bit of time responding to your post with more realistic data (say 30 degrees 'sensed' left and 10% increased vertical "sensing" and then finding true roll angle and true lateral acceleration (assuming the pilot uses correct power or collective to maintain height) and hit a few snags, mostly due to not having a scientific calculator here at work. Maybe I'll try again with the proper tools.

Well, if nothing else, this discussion has caused me to identify another issue that needs to be refined, all be it very little.

Gary
--

[Daniel Wee]

This would not be a problem if I were dealing with slip since that would be relative to the plane itself. But in the stabilization of a heli, we're talking about keeping it stationary or level with respect to the ground. It introduces an external reference point for which the accelerometer itself is unable to resolve.

Daniel

[Daniel Wee]

Back on the subject of using gyros to augment the sensing element, I'm having some initial problems - nothing new but problems nonetheless.

Basically anyone who has used heading-hold gyros will know this problem - the gyro doesn't really hold a heading. The cumulative error will mean that even HH gyros eventually drift. I suspect that most HH gyros simply integrate the rate output and integrates it over time in order to derive positional or angular data. However, this is done by discrete samples of the rate output and as such there will be quantization errors leading to cumulative errors over time. (We're not even discussing thermal drift here). For rudder control, the user can easily reset the tail position by giving manual input to the rudder position. This sort of resets the cumulative error and the process starts over.

The higher your sampling rate, the slower the errors will accumulate but they do add up. Maybe this is one of the differences between good and bad gyros.

Now, back to my problem, this cumulative error creates a problem for me in autonomous flight because it doesn't (or shouldn't) need the user to input corrections - that's the whole point of this device. The accelerometer doesn't suffer from this kind of cumulative issues because it senses the instantaneous acceleration on the sensor. Because I am trying to derive angular data from what is essentially a rate gyro, over time, the heli is going to tilt due to the cumulative quantization errors from the rate gyro derived angular data.

What I need is an automatic way of resetting the gyro derived angular data. I gotta think more about this now.

Daniel

[Mr.RC-CAM]

What I need is an automatic way of resetting the gyro derived angular data. I gotta think more about this nowI understand that is the basis of the Kalman filter solutions. In its most basic form, it involves relying on the accelerometers for absolute angular data (static acceleration data), yet using the rate gyro to determine the error term from adverse motion (dynamic acceleration). With those two data sources, the angular data can be accurately predicted. There are several published white papers on the technique, all of which are grand puzzles of mathematical proportions. :)

[Daniel Wee]

Even with the use of Kalman filters, it doesn't look like it would address the problems of the cumulative drift in the gyro's integrated angular data. At 10-bits, you're looking at several degrees within 30 seconds. This is unacceptable, especially when using it as a reference for the accelerometer. Even at 16-bits, there will still be significant drift within a few minutes. This is not factoring in problems with instability in the null output voltage or thermal drift, both of which compound the problem even more. Add to this the fact that the heli is in constant motion, and turning most of the time, leaves us little opportunity to recalibrate - as opposed to planes (passenger) which tends to accelerate/decelerate less and thus affording opportunity to recalibrate using the accelerometer data.

In my reading up, it looks like this is a problem that plagues professional systems as well and some artificial horizon systems come with warnings about how long the horizon will be valid and under what kind of situations it will not be reliable. So it appears that this is a universal problem. Some systems appear to be using 3D-magnetometers to derive the magnetic attitude and rely on this to re-calibrate the gyro from time to time. This is why you'll find that many of the AHRS systems include magnetometer functions.

So, to be honest, I'm stumped at this point. I don't mind throwing in a couple of gyros, but if I'm going to have to include magnetometers, I think it's going a little overboard. Unless I can find some clever way to keep the gyro within working range, the system just won't be stable enough over time to be used as the basis for stabilizing a helicopter.

I'm open to suggestions, and questions if any.

Daniel

[Mr.RC-CAM]

I would be surprised if the usual solutions would not work for your pitch/roll stability system. Are you saying that the performance of a Carvec-like system would not work for you? From all reported accounts, they are very impressive. So if Carvec and Rotomotion can do it, so can you. :)

I agree that for long term Heading accuracy a magnetometer would be helpful (but a WAAS GPS could be used too and be less fussy). I think that is what the other folks use too. But for pitch and roll, the accelerometer/gyro solution should work. Perhaps it would useful for you to talk to some Carvec and Rotomotion users to see what they have to say about their stability performance. Cyberflyer (cyberflyer.com) is one such fellow that would give you an honest technical opinion.

[flieslikeabeagle]

This is also one of the capstones of Einsteins general relativity - you cannot tell the effects of gravitation from the effects of acceleration.

The usual "thought experiment" to illustrate this involves one observer in a windowless room on the surface of the earth, and another in an identical windowless room accelerating through space (far from any gravitational potential due to a star or planet) at a rate of 1 g.

Any experiment performed by one observer (for instance, drop an egg, or measure the weight of a mass, or jump a certain height and time how long it takes to hit the ground again, or shine a light beam parallel to the floor and measure how far it bends by the time it hits the opposite wall) can be performed by the other observer, and both will get identical results. In short, there is no difference between the force of gravity and the force created by acceleration.

-Flieslikeabeagle

[Daniel Wee]

RC-CAM,

Hmm... from the specs of the Carvec system, it appears that they have reduced the error level considerably by using low drift parts and 16-bit sampling for the gyro output. Even so, there must be some drift over time. I wonder how they get around that. I suspect the info may be proprietary. Not sure if they're going to share it with us here. My current controllers only do 10-bit sampling so it looks like I will at least need a new controller with 16-bit ADC.

I've shot off an e-mail to John at Carvec and I'll see what, if anything, he has to say about this drift problem. Offhand, it looks to me like the Carvec system depends on the GPS for positional recalibration. Not sure how precise this is but it could work but would then be dependent on GPS reception.

The Rotomotion solution seems to rely on the magnetometer approach I mentioned earlier.

I guess only experimentation will tell how much drift will occur over time. Hmmm... maybe I'll go pick up some expensive parts and run some tests. Did I say this was an expensive experiment?

flieslikeabeagl,

We're past that stage now and working on using angular data from a rate gyro (integrated) to null out the tilt information from the accelerometer, thus discriminating the dynamic acceleration.

Daniel

[Mr.RC-CAM]

Even so, there must be some drift over time. I wonder how they get around that.I am not sure if you are worried about course/heading drift or pitch and roll drift. Course accuracy can be maintained using GPS during forward flight. Holding a fixed heading during a hover over long term would not be offered by the GPS (without adjunct sensors, they are useless when motionless). 3D magnetometers could be used if your application requires it.

Offhand, it looks to me like the Carvec system depends on the GPS for positional recalibration.I understand that for pitch and roll, they have been using gyros/accelerometers and Kalman filtering. It appears that a correctly implemented Gyro/Accelerometer solution has good long term stability. Think of the accelerometers as the low pass data source and the gyros the high pass data source. One provides short term correction and the other provides long term stability.

I would encourage you to contact cyberflyer. He is very serious about stability platforms and would give you a sincere opinion on what to expect.

[Daniel Wee]

I'm certainly giving this a lot of thought. I'm primarily concerned with pitch and roll drift. Heading drift is easier to correct. As you said, it is possible that properly implemented the Kalman system yields long-terms stability. I've been thinking along these lines as well but there are some limitations. The accelerometer data is no good for calibration unless the heli has stopped accelerating dynamically. I imagine that they can cross calibrate as the opportunity arises but it's a non-trivial exercise.

I think I need to look more carefully at how the Kalman filter is implemented.

Daniel

[Mr.RC-CAM]

The source code (including the Kalman functions) to what eventually became the Rotomotion implementation is posted on the AutoPilot web site. However, I have not kept up with that project and I have no idea if the information, as posted, is fully functional or bug free. If it is, then just re-using the code will probably save you several hundred man-hours of development time.

Of course there other ways to build a stability system (lowly PID loops, witchcraft, etc.), so the Kalman estimator is not the only game in town. However, since others have successfully used it, and appear to have shared some of their efforts, it seems attractive.

I am not sure what your long term goal is. But, I am hoping you are creating a fully functional open source project that mortals can build at very low cost. There would be grand statues created in your image if your did that. :)

[LukeZ]

There would be grand statues created in your image if you did that. :)Hear, hear!!

:D

[Daniel Wee]

Lol, I certainly want to make this available at low cost if I can. Right now all the coding is in assembly so I don't know how useful that would be to others. I did try to download the autopilot source at one point but the archive appeared to be corrupted. I'll give it another try.

Daniel

[BushmanLA]

I've been fighting with this same problem as well. A few friends and I are working on a UAV project for fun and excitement. Our platform is a run of the mill fixed wing RC trainer.

The project seemed very simple at the outset until I started thinking about how you can't distinguish between gravity and other forms of acceleration acting on the aircraft.

These guys have some awesome solutions:
http://www.o-navi.com/products.htm

But what is the fun in letting someone else do all the work? :)

My BIG question is this:
Am I setting my gyros to reference gravity and then relying on them to maintain that refrence?
-or-
Do I not really care how they were originally set, I'm only using the data they give in conjuction with the data from the accelerometer and lots of math voodoo to know how much im tilting, and how much im accelerating?

If the answer is #1 then I need a method for correcting drift.

If the answer is #2 then I need a method to do #2!


I'm a little fuzzy on magnometers. I realize they measure magnetic fields, but can anyone give the short story about what kinda of data they give and how accurate they are? Can they be used to give me a general idea of what is up and what is down?

[Daniel Wee]

Okay, basically here's how it should work.

The accelerometer output is a combination of actual tilt with respect to ground and any dynamic acceleration. In order to resolve this into it's various components, we're going to need to know either the tilt (angular data) or the dynamic acceleration. The plan with the gyro is to use it to provide an independent source of angular data. So therefore if:-

a = accelerometer data = x + y

where x is the tilt (acceleration due to gravity) and y is dynamic acceleration. And

w = rate of turn

which we get from the rate gyro. If we integrate this rate gyro output:-

dw/dt = tilt angle = X

This can be accomplished by simply summing up w/t and this should yield the tilt angle, where t is the sampling period.

Now that we have this tilt angle, lets call it X, we can take the accelerometer output and subtract this X from it:-

a - X = (x+y) - X

and if X is accurate and x is also accurate then x should be equal to X and you should be left with y, which is the dynamic acceleration.

If you integrate this over time you can get velocity of the platform.

Now, this sounds good and easy in theory but in practice we run into several problems, pertaining primarily with the gyro side for the moment.

1. The gyro is susceptible to thermal drift, and this will lead to errors in the derived angular data which really messes up everything. So we need either a low drift gyro, or a temperature compensated output, or both. This is not too difficult to deal with.

2. Quantization errors. Since we are sampling the gyro output at fixed quantums and adding this up - we are assuming that the change from one sample to another is linear. This, however, is not necessarily the case. Over time, these quantization errors will add up and lead to error. This can be addressed by increasing the sampling rate which will lead to better approximation but there will still be cumulative quantization errors (time domain).

3. Noise within the system. This is usually electrical noise, but also output variations arising from vibrations in the platform. This can be addressed by taking an average of readings (which is basically a form of low pass filter). But once you do this, you again introduce errors because the averaging or filtering process is basically a depends on statistical probability.

4. ADC resolution. We have limited ADC resolution and we also have quantization errors in the voltage domain. Using a higher resolution ADC (and lower noise) will help, such as a 16-bit ADC versus a 10-bit ADC.

What the above problems mean is that over time, the angular data (tilt) derived from the rate data from the gyro is going to become increasingly erroneous. So if you are losing 0.1 degrees a second, you're talking about 10 degrees in 100 seconds, which is clearly unacceptable.

So now we need a way of keeping this gyro accurate but what are we going to use as a reference?

Well, it is possible to use the accelerometer output as a means of recalibrating the gyro derived tilt angle. In the simplest instance, when the platform is not accelerating dynamically, we can use the accelerometer's output to reset the gyro derived tilt angle. In order for this to work however, we need a way of knowing when this state occurs. There are several ways of doing this but most of them make some assumptions about the behaviour of the platform. You can compute the acceleration vector all the 3-axis accelerometer output and use that as a basis of making a best guess. This will not work, though, if the state detection is poor, or if the state doesn't occur frequently enough. On a helicopter flying around, I think it simply doesn't happen a whole lot.

This means we will need something more sophisticated. Enter the Kalman filter, which basically re-calibrates the gyro derived data at every step. Ie. it is continually corrected based on the comparison between predicted data and actual data. Now, the question is, what are the inputs to the filter? We know for sure that the gyro output is one input but can we simply use the linearized output from the accelerometer as input data for the filter? I don't see how this can be.

This is where I'm stuck. My guess is that I will need to preprocess the x-axis and z-axis output with some function before feeding it to the Kalman filter. I could be wrong but I don't see how the linearized output of a single axis from the accelerometer can be helpful at all with predicting anything. I have some other preliminary thoughts but basically this is where I'm currently at. I'm not going to actually buy the gyro until I figure out the answer to this problem.

If anyone can help me out here, I'd be most happy.

Daniel

[Daniel Wee]

BushmanLA,

So in reply to your question, it's a combination of #1 and #2. The math itself, though complicated, is not overly daunting. What is daunting is figuring out what are the correct inputs to the math functions, and the fudge factors - ie. working out the Kalman gain, the covariance matrices, etc. That's a bit of trial and error work there. Like you, I'm also after the holy grail of attitude sensing here. I've read a number of papers on this but so far the best bet seems to be the autopilot project on SourceForge. Unfortunately I still haven't tracked down the information on how they are dealing with the accelerometer data before feeding it to the Kalman filter.

As for magnetometers, they are inaccurate over the short term but more reliable over the long term due to local magnetic variations. I don't think it's the way to go though, personally speaking.

Daniel

[Daniel Wee]

Okay, I think the voodoo is getting unravelled a bit for me and I'm finally getting to the assumptions that are being made on the accelerometer part.

Basically, the gyro derived angular data can be considered accurate but over a very short term. The accelerometer derived angular data however, is more reliable over the long term.

So what are the assumptions that are being made:-

1. Acceleration/Deceleration input on the sensors can be regarded as high frequency noise (unwanted input).

2. The acceleration and deceleration will zero out each other over time.

Given these two assumptions then, we can put the accelerometer's linearized output through a low pass filter (such as an long term moving average filter?) and it will yield reasonable angular data over time, but not instantaneously.

So what is being done then is to use the Kalman filter as a way of continually making corrections to the gyro derived data using the accelerometer's filtered data as a contributory factor. How much you want to depend on this, or how dependable this data is, is factored into the equation. This factor is arrived at somewhat through trial and error. So you could say that the output is primarily gyro derived with corrections from the accelerometer.

What are the drawbacks of this system?

Well, first of all the assumptions would not hold true if, for example, you are throwing your helicopter in the sky with some extreme 3D moves. In that case, the dynamic acceleration will become the predominant data and seriously corrupt the accelerometer output and thus making it extremely unreliable for the period of those maneuvers. Now if this occured for a short time, it is okay. But if your gyro has a usable stability over say 60 seconds, and you keep up the 3D for 120 seconds, you are going to accumulate a lot of error in the system. If this should happen, it will take the system quite a while (probably up to 60 seconds) to regain a reliable data stream from the accelerometer's low pass filtering mechanism. During that 60 seconds, especially at the beginning of it, the system will be unable to stabilize your platform before of the erroneous data.

This is the thing that I was trying to undestand for a long time but it is seldom mentioned. It has some implications for usage too. Take the thermopile based systems for example, they have instantaneously valid data if the right conditions are met. So you could be flipping your heli and the moment the system takes over, it can immediately balance it out - ie. fast and accurate response. The gyro/accelerometer based system will probably take a longer time to settle down to a stable position by comparison. This raises the question of it's suitability for failsafe functions, for example, because it may not be able to recover stability in time. It is probably more suited for slower moving platforms - such as camera work, observation platforms, etc.

Now that I understand this, I think I'm ready to move on a bit more.

Please feel free to comment on my conclusions and understanding of the system if you find that I've got it wrong somewhere. I'd be happy to hear any pointers and/or suggestions.

Daniel

[LukeZ]

The Autopilot sourceforge page does seem to be down... I was pretty sure I visited it just a couple months ago. Anyways, Freshmeat seems to have a copy of all the files, though I don't know if they're the most recent versions. You can see it here: http://freshmeat.net/projects/uav/.

Another eZoner sent me a Word document by Dr. PD Joseph on Kalman filtering a while back. You can visit Joseph's site here (http://ourworld.compuserve.com/homepages/PDJoseph/kalman.htm). If you email Joseph he will send you the Word document for free, it's a tutorial on Kalman filters, but it's not complete. For the complete version he asks that you PayPal him $9 bucks. Don't know how helpful it would be... I'm just trying to scrounge around for any of this stuff I had laying around. If anyone wants the free portion of the Word tutorial, PM me and I'll email it to you. I have not purchased the full version so I can't speak to how good it might be.

Luke

[Daniel Wee]

Thanks LukeZ. I'll take a look at the links. At this point my problem is not so much with the implementation of the Kalman filter itself but it was with understanding the basic principles involved in the use of the various data. I think I am now beginning to understand how it works, and the attendant limitations of such a system. (See my previous post).

I'm still evaluating which way to go with this project, now that I understand what we're dealing with. Before the whole Kalman thing was just some magic black box that seemed to promise the solution without any drawbacks. At least I know this is not the case now and knowing the nature of the drawbacks is giving me reason to reconsider the project. I originally envisaged something which could be used as a control recovery mechanism - ie. you're 3D-ing and the radio jams, the system would automatically take over and stabilize the heli until radio control is recovered. This is necessary because a PCM lockout takes a few seconds to occur and clear out (takes a few seconds in the hold phase, and then the lockout phase if hold does not clear after a while). It appears that this system may not be 100% reliable in this kind of scenario though.

There are ways out, of course - most obviously, using a gyro with very low intrinsic drift, low precession effects under G, and high resolution sampling ADC. All these will extend the time over which the gyro derived data will be valid and thus giving the system more opportunity to recover from error. It is these considerations that I'm now grappling with.

Daniel

[Mr.RC-CAM]

I originally envisaged something which could be used as a control recovery mechanism - ie. you're 3D-ing and the radio jams, the system would automatically take over and stabilize the heli until radio control is recovered. If that is the case, then I think a FMA Co-Pilot with Z-sensor, married to a barometric sensor, would offer a simple remedy. For basic recovery, precision navigation is not needed.

[Daniel Wee]

Looking at the autopilot code, there's one bit that's puzzling me a bit.

I notice that they use a dual-axis accelerometer in order to derive the incline. Basically atan2(z-axis, x-axis). I wonder why this is the case. While I understand that this will yield the tilt vector - why can't they do it simply with one sensor since the sensitivity of the system is known?

Furthermore, in using the z-axis sensor, you are introducing additional errors near the level plane because the z-axis sensor is least accurate (has lowest resolution) there due to the non-linearity of the output. Am I missing something here?

Daniel

[Daniel Wee]

RC-CAM,

I'm not all that keen on the thermopile sensors for a few reasons:-

1. It is rather unelegant - from a purist designer point of view :)

2. It raises the complexity of the system beyond what I like (and the cost too).

3. I think I might still be able to solve the problem, within reasonable limits and to some extent, by careful component selection.

4. I intend to slap a GPS module on once the basic AHRS system can be shown to work reliably. So I will need precise navigation at some point.

Do you agree with my understanding of the limitatins of the gyro/accelerometer based system as laid out above? If those conclusions are correct then I think I may go ahead and start looking for suitable parts.

Daniel

[LukeZ]

Looks like we posted at the same time... I'm glad to hear your problem isn't so much in how to implement the Kalman filter: at that point then you're way ahead of most of us!

Perhaps, if you're looking for a recovery solution, IR sensors might make the most sense afterall - unless you enjoy wild heli 3D in the fog! :eek:

I know you weren't keen on using them from your original comments. They do kind of ruin the fun of figuring out this other stuff. But given appropriate environmental conditions, they would give you correct data instantly and consistently.

However, if it's not that you'd be doing 3D in the fog, but that your autonomous vehicle might encounter a bizarre wind gust in the fog, then of course the accelerometer/gyro solution would be best...

Anyways, I'm not telling you anything you haven't already thought about. I'll go back to listening and learning. ;)

Luke

[LukeZ]

Boy you guys sure do post fast...

[Daniel Wee]

LukeZ,

I'm just wondering how far along have you gotten with your project? As for me, I'm just beginning to understand all this stuff, which for me forms the basis of proper application of the Kalman filter. Simply from this alone, I can understand a number of the filter parameters, such as Kalman gain, Q, and so on. Once I saw this, the filter began to make sense and it would seem that the rest would simply be converting the functions into code. Of course, I've not gotten that far but it appears to be simply tediousness thereafter. There's still the fudge factor or working out the weightage to assign to the various inputs, and the optimal gain. Nevertheless, the murky waters is clearing up for me. I'd be interested to know how far you've got along in this process and where you've stopped.

Daniel

[LukeZ]

Daniel -

As it concerns Kalman filtering or even accelerometers/gyros, I've gotten nowhere - not because I haven't tried but because I haven't yet started on those aspects. I'm working on a complete autopilot project and I guess I'm taking the slow route. As interesting things come up I explore them. You can check out my site (http://www.kansasflyer.org) for some more info on what I've done thus far. Primarily I've been fiddling with altitude/airspeed measurements. I have another thread on those going right now. But of course before I even started on that I had to learn what a PIC was, how to program it (Assembly and C), as well as other basic knowledge which I lacked, such as what an op-amp was and how to use it. I pretty much started carte blanche. Now that I've gotten some of the basics down things are starting to move a bit faster.

Anyways, AHRS is coming up fast on my list - but I've not done much with it other than reading. I want to learn this stuff, so I'm not going to go the route of purchasing a system. However, I'm certainly not above letting others do some of the mental heavy-lifting: which is why I follow these threads so closely! :o

I'm learning a lot from your explanations. Your discussion of the difference between gyros and accelerometers and how the former can be used to parse out the angular data from that latter was very nice. Sometimes it just takes someone to explain it in a new way for it to begin to make sense.


Luke

[Mr.RC-CAM]

I notice that they use a dual-axis accelerometer in order to derive the incline. Basically atan2(z-axis, x-axis). I wonder why this is the case. While I understand that this will yield the tilt vector - why can't they do it simply with one sensor since the sensitivity of the system is known?Here's a secrete tip that you must promise not to tell anyone. If you take a 2-axis accelerometer, put it on its side, and then measure both axis, you will eliminate the common mode errors and extend the operating range beyond the typical 60 degrees. The usual math is Angle = atan(AGy/AGx).

I'm not all that keen on the thermopile sensors for a few reasons:-
1. It is rather inelegant - from a purist designer point of viewIt is not the highest tech solution, but it seems to me it would be effective. KISS.

2. It raises the complexity of the system beyond what I like (and the cost too).But you will take a very complex control system methodology that needs a DSP solution, that will possibly consume your life for one to two years, and replace it with $200 (FMA CoPilot, cheap MCU, etc.) and a few weeks of effort. But I agree, it sounds boring. :)

3. I think I might still be able to solve the problem, within reasonable limits and to some extent, by careful component selection.Agreed. That, and some really sophisticated software.


4. I intend to slap a GPS module on once the basic AHRS system can be shown to work reliably. So I will need precise navigation at some point.GPS navigation is easy to integrate. The altitude accuracy is not good, so plan on barometric sensing.

Do you agree with my understanding of the limitations of the gyro/accelerometer based system as laid out above? If those conclusions are correct then I think I may go ahead and start looking for suitable parts.Although I am probably a bit more optimistic about using a Carvec/Rotomotion type stability system, I will agree it will probably not be a slam dunk in your application. My fear is the worst case scenario. A 3D heli pilot is flying the model, loses radio contact just as the model begins a serious tumble. By the time the stability system is enabled, the sensors will be overwhelmed. Sophisticated IR based sensing is about all my feeble brain can consider in such a situation. But, anything is possible. It's only software. :)

[Daniel Wee]

RC-CAM,

Based on your last paragraph in the previous post, I take it that you agree with me on the point about the Kalman system being slower to respond due to it's dependence on averaging the accelerometer data over time. Of course, I don't know what the exact period will be - it could be really fast (but I think at the very least we're looking at some 10 seconds or more)?

Daniel

[Mr.RC-CAM]

I think that is what I am saying. You might want to discuss this worse case issue with Cyberflyer. Perhaps he may be able to offer some practical advice on how a "part time" Carvec-like stability system would work. He may not know, but at least he will be honest about that and not fill you with noise.

[Daniel Wee]

I just got a reply from John at Carvec and he confirms that if the heli is under sustained acceleration, the guidance system will become inaccurate. At least I'm on the right track in understanding how this works now.

Daniel

[Mr.RC-CAM]

Given what your needs are, what sort of design strategy do you think you will use? From your recent comments it sounds like the stability system is more of a failsafe/attitude recovery device. Are you sure you don't want to use thermopiles and barometrics?

[Daniel Wee]

Hi RC-CAM,

Well, it would seem like re-inventing the wheel to go the thermopile way. Truth be told, I think with what I have already, it would be very easy to implement a thermopile solution since it is so much simpler that what we're attempting here.

I think what I'll have to do is to first develop a stable gyro/accelerometer combo before integrating it into the stabilization system. Right now I'm looking for some low drift gyros. I had originally planned on using Sparkfun's combo units but not only are they expensive, I suspect that they're pretty high drift. The gyration mini mechanical units looks good at this point so I'm considering that, but I'm still scouting for affordable low drift gyro parts. I've got half a mind of using a dedicated controller to handle these bits.

I guess a failsafe system is also one of my concerns because if I fly this thing a long way out (which I'd like to do eventually, to fly it way high), I want to make sure it can stay alive in the event of radio lockout.

Daniel

[Mr.RC-CAM]

I suppose the lowest drift gyro sensors are the SMM types used in the high end Futaba GY series gyros and the like.

[Daniel Wee]

Hmm... you think so? Maybe I should just buy a few and rip it apart. Seems like such a waste though. Wonder if there's a place to get them is small quantities.

Daniel

[Mr.RC-CAM]

I don't know which sensor brand they are using, but if you google silicon micromachined MEMS gyro you should be able to find some interesting components to review. Or, perhaps someone will pop the cover off their GY601 and tell you if there are any mfg markings on the sensor's body.

[Daniel Wee]

They're using Silicon Sensing parts. These feature about <0.55 degrees/second bias drift and is quite good compared to those from Gyration which are <2 degrees/second. Even so you can see that at 0.55 degrees/second we're looking at 2 degrees in 4 seconds, assuming the very worst case. In reality the drift is not constantly in one direction so they are a lot better than that. The accelerometer can probably offer some accuracy over a few seconds so it might just work.

I can't seem to find anyone who sells these online though. I'm thinking of the unpackaged CRS03 or CRS07 units. You can find them here:-

www.siliconsensing.com

I'm still looking at several options but this one looks the best in terms of drift so far.

Daniel

[Mr.RC-CAM]

If you are located in the USA then Newark.com stocks the CRS03. But, you do not want to look at the price. A Futaba GY series gyro is much cheaper to hack.

[Daniel Wee]

I know :(

In any case, I'm still a bit confused by the manufacturer specs on noise and drift. Take a look at this very useful table:-

http://www.fastascent.com/Projects/Attitude_Control/Rate_Gyro_s/rate_gyro_s.html

Note the noise parameters and how the Crossbow unit has only 0.85 degrees per hour! (It ought to given how much it costs.)

Daniel

[billyzelsnack]

I went wandering from that fastascent link.. Check this out..

http://www.nec-tokin.com/english/product/3d/overview.html

I didn't see a price.

[billyzelsnack]

hmm. Maybe that's what is going to be in the Nintendo Revolution controller.

[billyzelsnack]

Ok. I found a price..

$1175.00 doh.

http://www.sscnet.ucla.edu/geog/gessler/topics/sensors.htm

[minifly]

I just had a very simplified idea:

if you have two accelerometers on each axis, with space in between them.

if they both give the same readings, you are getting buffeted. if you get opposite readings, it means that there has been a change in the orientation.


sorry if somebody already said this, i didn't read the entire thread properly.

[Daniel Wee]

That might work for determining if you're rotating or being buffetted but it doesn't tell you how much of each is involved. For example, if you're both turning AND being buffeted, this system will not work, basically. It's a good idea though.

Daniel

[minifly]

I think you would be able to check the difference between them, and the bigger the difference the more turning is involved.

so you only correct the difference, and ignore whatever is being sensed by both, no matter how much that may be.

[Gary Warner]

Daniel,

Are you totaly finished with just using the accelerometers to stabilize flight?

I can share with you that I put two hamsters on a 3d foam plane to try and control hover flight. It didn't work (like your example). But knowing what I know now, I think it would work with the vertical axis being used.

Gary
--

[Daniel Wee]

Hi Gary,

Unless I get some new ideas, I don't see how it is possible. I am trying to understand the use of 2-axis to get the tilt (see above posts) and apparently it reduces some common mode errors. That might improve things a little but it won't be sufficient to deal with any dynamic acceleration that arises. When my heli goes into stabilization mode, the moment it accelerates in any direction, it just tilts in that directon and keeps going faster as a result. As long as there is no significant dynamic acceleration, it tries to stay put.

What do you have in mind with the vertical sensor? I'd like to hear your theory on them.

Daniel

[Gary Warner]

I've been trying to get you to come up to your own answer to the problem since I've found 6 different ways to skin this cat (or Hamster in my case :p ).

This is one method:

G's = sq.root (Ysq. + Zsq.)

Y is the roll axis
Z is the vertical axis

(Be sure to pad data back to 1G before using this formula)

Example of flight observation model:

20deg bank, 1.2G's: Solve for REAL bank data regardless of G's

Y = Sin 20 = 0.342 or 34.2 sensor value
Z = sin 70 = 0.939 or 93.9 sensor value

Build theoretical model: (precision to 3 decimal places)

(1.2 is the G's)

Y = (sin 20) * 1.2 = 0.410
Z = (sin (90 - 20)) * 1.2 = 1.128

Real World Data:

Y = .410
Z = 1.128

Pad Data:

Y = Y * 100 = 41.0
Z = Z * 100 = 112.8

Square Each:

Y sq. = 1681
Z sq. = 12723.84

Sum:

Y sq + X sq. = 14404.84

Sq. Root:

Sq. root 14404.84 = 120.02

Adjust Y:

Y = Y * 100 (moving Y back to padding) = 4100

Answer to REAL BANK/ROLL ANGLE:

4100 / 120.02 = 34.16

So:
Theory angle (before G's) was 34.2
Calculated angle is 34.16

**** 34.16 = your usable "Y" data ****

The slight differences in the numbers are due to precision rounding. Rounding to the same standard would give 34.2 for the calculated answer.

Play around with other values. It works.

Does this help? Do you now see why you MUST sense the vertical (Z) axis?

Gary
--

[Gary Warner]

Incase it's not clear, the above formula will compensate for roll IF you are still in control of altitude. This is not an autonomous control, simply one that stabilizes one axis (roll). You must still fly the collective or throttle. Autonomous altitude control must be left to other sensors, like barometric or GPS.

[Daniel Wee]

Hi Gary,

I think you may be misunderstanding the problem here. The issue is not so much the math but your basic assumption that G = sqrt(Y**2 + Z**2). What you're solving for is not G but G+dynamic acceleration. On top of that the G vector doesn't always point down, which I think is what you're assuming.

So, if the real world sensor presented you with the following (using your example):-

Y = .410
Z = 1.128

You can only solve for this if you may some assumptions about the G vector's direction. The fact is that in a real heli, the G vector could be pointing in a whole lot of directions other than down.

Suppose the bank was 20 degrees to the left, but the heli is accelerating to the left, that will affect your readings. In fact, that left acceleration will actually decrease the sensor reading. So if your platform is stationary, and you read Y and Z as above, you may assume a 20 degree bank. However, suppose you are accelerating to the left now, your reading will look exactly the same as if you were at a less than 20 degree bank.

Take a 90 degree left bank but with no acceleration at all (hypothetically). In this case, the Y reading from the accelerometer will indicate a reading corresponding to 1G and the Z reading will correspond to 0G.

Now, take a level platform and let it accelerate to the right at 9.81m/s (1G) AND accelerating downwards at 9.81m/s (freefall). In this case, bank is 0 degrees but what does the Y and Z sensor read? Yep - 1G and 0G respectively. IOW, exactly the same reading as in the first example above but with totally different bank angles.

Okay, now let's get to the task - I give you a the Y and Z readings without telling you which of the above scenarios is happening. You get the 1G and 0G readings from the Y and Z sensor. How can you solve for the bank angle on this basis alone? I mean, seriously, give it a try with this example. I think if you do, you'll begin to appreciate the complexity of this problem. Remember, we are trying to solve for absolute bank angle with respect to ground, not simply the relative bank angle with respect to the platform.

Daniel

[Gary Warner]

I think you are giving lateral acceleration too much credit in the equation. Roll occurs before acceleration starts and an immediate anti-roll commend should be given by your controller. I'm trying to explain why no Z axis input will make stability impossible.

By using just tilt and roll sensing, your device corrected to the Y or X axis to the point where Z was 1G. This 1G came from lateral acceleration. What you make was effectively a rate sensor in an unstable configuration.

In my example, lateral acceleration would be sensed and the error will still be corrected at the correct gain. In your example, the gain was reduced as acceleration increased.

I stand by my theory to stabilize roll and pitch (assuming the addition of the X accelerometer). There will be some latitude drift (wind, lateral acceleration inertia), but the helicopter will remain erect and level.

And why do you keep going back to the 90 degree bank theory? It's not a normal stable hovering flight condition. Your device should never let the helicopter get this far out of hover.

Gary
--

[Gary Warner]

Hi Gary,

I think you may be misunderstanding the problem here. The issue is not so much the math but your basic assumption that G = sqrt(Y**2 + Z**2). What you're solving for is not G but G+dynamic acceleration. On top of that the G vector doesn't always point down, which I think is what you're assuming.

So, if the real world sensor presented you with the following (using your example):-

Y = .410
Z = 1.128

You can only solve for this if you may some assumptions about the G vector's direction. The fact is that in a real heli, the G vector could be pointing in a whole lot of directions other than down.



No, this formula solves the angle of perceived gravity AND the force (G's) of perceived gravity. If vertical acceleration in null (no changes in altitude), exact angle of the roll can be found.

Gary
--

[LukeZ]

And why do you keep going back to the 90 degree bank theory? It's not a normal stable hovering flight condition. Your device should never let the helicopter get this far out of hover.It was my impression that one of the actual purposes of this device is in fact to correct and save the craft from an unstable condition.


Luke

[hugo_vincent]

Hi everyone, I am joining this thread late, and haven't read everything that has been said in much detail, but I will add my thoughts anyway :)

I am working on a UAV project, http://www.albatross-uav.org

We use 3 axes of accelerometers (2 ADXL203) and 3 axes of gyros (3 ADXRS150) (so it's not cheap :) - we have about $150 sensors right there....

Things to consider: (in no particular order)

1) you *NEED* analog low pass filtering on the inertial sensors before sampling them with the ADCs. They have a bandwidth of over a kilohertz, so unless you are sampling really fast, you will see aliasing effects (remember Nyquist?) from vibrations etc. We used two-pole Bessel filters each constructed from 1 opamp gate. We sampled at 100 Hz, and the filters had a cut off of 50 Hz.

2) the Analog Devices ADXRS150's are the best gyros suitable to hobbyists on the market (or at least they were when we designed our PCB 6-9 months ago)

3) no one seems to have mentioned the open-source Crossbow code for their MicroNAV; it contains a "proper" Kalman filter implementation unlike the simplified one in the autopilot code base.
http://sourceforge.net/projects/micronav
http://www.xbow.com/Products/productsdetails.aspx?sid=133

4) the autopilot project on Sourceforge seems to be pretty much dead (not just the broken home page, but there hasn't been any good technical discussions on the mailing list for months and months, there haven't been any releases, and nothing particularly interesting has been happening in the CVS code repository)

5) sensor calibration is both very important and very hard to do (esp. gyros). Accelerometers can be calibrated pretty easily by measuring the output when they are horizontal (0 G) and vertical (1 G) which gives offset and scale for a simple 2-point linear fit calibration. Gyros are harder. Offset is easy (measure and average output when its sitting still), but we really also need scale for a linear fit calibration, meaning we need a rate table (or something else that spins at a constant rate). (Apparently you can also do that calibration by integrating the output and rotating the gyro 90 degrees...)

6) remember that if there are any dynamic accelerations and the accelerometer is not just measuring acceleration due to gravity, the output will not be 1.000 G (think about Pythagorus). I am talking about the overall acceleration vector here, not just the output of any one accelerometer. You can use this information to weight how much you trust the current accelerometer-derived attitude angles. When you have exactly 1 G you can reset your gyro integrations to the accelerometer-derived angles.

7) if you are looking through our source code on our website (www.albatross-uav.org) you will notice many dodgey things :) This is mostly because we wrote almost all the interesting code in about 2-3 weeks of late nights :P before the deadline (we did our UAV for our engineering degree final year project). It can be surprising how bad code written at 4 am is, and how lazy you can be.

8) in the end, you actually need quite a lot of processing power. We used floating point numbers (perhaps not necessary, but sure as hell easier), which further increased processing requirements. A 400 MHz XScale processor (like on a Gumstix) was used, but we had to underclock it to 300 MHz because it was interfering with the GPS.

9) I saw someone said they wrote code for their UAV in assembly.... these days C compilers are pretty damn good, and for modern processors they tend to produce better code in most cases than the average assembly programmer. CPU time is cheap. (P.S. I don't want to start a flame war and I don't mean to insult anyone) Same deal with a 128 byte look up table... memory is cheap :)

10) magnetometers: these aren't just compasses! yes, they give you heading which is nice (because GPS heading will only be accurate if you are moving) but the earths magnetic field vector has a vertical component too (dependent on whereabouts on earth you are) which can be used to find pitch or roll. A 3-axis magnetometer alone won't be able to give you pitch, roll and yaw, but it can be used to reset gyro integrations etc. A good three axis magnetometer is "only" about $50 so its a pretty good addition to an already expensive system :P The disadvantage is that it needs to be mounted away from high current cables, and if it is mounted near lots of iron it will need some kind of calibration.

Sorry for the long, rambling post :)

Hugo

[Daniel Wee]

Hi Gary,

Well, that's what I thought at first, that lateral acceleration is a small factor but I made actual tests and on a heli, it is not a small factor. First of all some of the acceleration sensed actually arises from vibrations, from starting or stopping the heli from FFF, for example. Because of the nature of the sensors, any simple corrections will amplify the acceleration by tilting the heli in the direction of the acceleration vector. On my prototype what happens is that as long as the heli is stationary, the approach you suggested works. But any kind of movement, say due to wind for example, is going to start off a runaway situation. As LukeZ says, the aim of this thing is (partly) to recover from an unstable situation. But I think you're beginning to see the problem now.

Daniel

[Gary Warner]

Hi Gary,

Well, that's what I thought at first, that lateral acceleration is a small factor but I made actual tests and on a heli, it is not a small factor. First of all some of the acceleration sensed actually arises from vibrations, from starting or stopping the heli from FFF, for example. Because of the nature of the sensors, any simple corrections will amplify the acceleration by tilting the heli in the direction of the acceleration vector. On my prototype what happens is that as long as the heli is stationary, the approach you suggested works. But any kind of movement, say due to wind for example, is going to start off a runaway situation. As LukeZ says, the aim of this thing is (partly) to recover from an unstable situation. But I think you're beginning to see the problem now.

Daniel

I'll give you the functional tests, but I understand that they were not done sensing the Z axis. I'll agree: If Y and X are the only sensed axis’s, stability is not possible.

You were quick to show your results using the Y and X axis suggesting that you can produce usable code rather quickly. So, I propose that you implement my math reading the Z axis with you reporting the results. I'd do it myself, but I don't own a copter, let alone able to fly one.

BTW, I jumped in based on your original post that said you only wished to obtained stable hover. The idea of recovering a copter from an unusual attitude was not considered in my comments.

Gary
--

[Daniel Wee]

Hi Hugo,

That was a very helpful post, albeit a little disconcerting because I'm trying to aim for the project to be work on a dsPIC or similar. No X-Scale here for size, cost and power reasons. I'm hoping for something reasonable cheap and small.

We use 3 axes of accelerometers (2 ADXL203) and 3 axes of gyros (3 ADXRS150) (so it's not cheap :) - we have about $150 sensors right there....


How does this compare to the Silicon Micro-Machines CRS03/07 gyros? These were supposed to be very low drift and shows good linearity. I'll take a look at the specs for the ADXRS150 later - thanks for the pointer though.


1) you *NEED* analog low pass filtering on the inertial sensors before sampling them with the ADCs. They have a bandwidth of over a kilohertz, so unless you are sampling really fast, you will see aliasing effects (remember Nyquist?) from vibrations etc. We used two-pole Bessel filters each constructed from 1 opamp gate. We sampled at 100 Hz, and the filters had a cut off of 50 Hz.


I was hoping to keep things simple with a simple RC filter and then doing some averaging in the software. That may not work as well but it may be adequate.



3) no one seems to have mentioned the open-source Crossbow code for their MicroNAV; it contains a "proper" Kalman filter implementation unlike the simplified one in the autopilot code base.
http://sourceforge.net/projects/micronav
http://www.xbow.com/Products/productsdetails.aspx?sid=133


Aha .... thanks. I didn't know about this.


4) the autopilot project on Sourceforge seems to be pretty much dead (not just the broken home page, but there hasn't been any good technical discussions on the mailing list for months and months, there haven't been any releases, and nothing particularly interesting has been happening in the CVS code repository)


Yes but they do have code for a 1-D tilt system and that's handy.

6) remember that if there are any dynamic accelerations and the accelerometer is not just measuring acceleration due to gravity, the output will not be 1.000 G (think about Pythagorus). I am talking about the overall acceleration vector here, not just the output of any one accelerometer. You can use this information to weight how much you trust the current accelerometer-derived attitude angles. When you have exactly 1 G you can reset your gyro integrations to the accelerometer-derived angles.


It's a good idea but even when the vector is exactly 1G you cannot be sure that the accelerometer is level. This is where the Kalman filter code comes in. Instead of looking for the particular point of accuracy (which is indeterminate in any case), it averages over time and makes a best guess at what would be the right value. This way, it makes many minor corrections, none of which will be as good as one single reset but they work in concert to keep things in check.

Daniel

[Daniel Wee]

I'll give you the functional tests, but I understand that they were not done sensing the Z axis. I'll agree: If Y and X are the only sensed axis’s, stability is not possible.


Actually my code had already incorporated the use of the Z-axis in all the calculations so I'm pretty sure of the results.

You were quick to show your results using the Y and X axis suggesting that you can produce usable code rather quickly. So, I propose that you implement my math reading the Z axis with you reporting the results. I'd do it myself, but I don't own a copter, let alone able to fly one.


As mentioned, even at the start I was already working in the Z-axis code but the problem was the need for an external reference, not a derivative.

BTW, I jumped in based on your original post that said you only wished to obtained stable hover. The idea of recovering a copter from an unusual attitude was not considered in my comments.


The fact, I believe, is that even in normal use, you can't ignore any transient accelerations because they factor big in the readings. It only takes a small acceleration for a very short while to corrupt the readings. If it were negligible, I'd have filtered it out but it isn't negligible and hence the whole problem. Any hovering platform that assumes non-acceleration is not much good at all in real life.

When I started this project I made the same mistake of thinking that it would not be a significant factor for a slow moving heli. In fact I tested code on an actual flying heli doing just this. First I hovered the helicopter manually to a standstill and let the code take over the controls. It manages for just a few seconds before minute accelerations get amplified and everything goes out of whack. As such, this isn't just a theoretical exercise but backed by actual tests. Bear in mind too that this is already using Z-axis to compensate for as much as possible.

At the end of the day, I find myself coming back to the problem I presented to you above. Although you'll seldom if ever experience a 90 degree bank, it was only for the purpose of easy calculation and demonstration that I used that example. A 2 degree bank gives the same readout as a 0.34m/s**2 acceleration. So even very small accelerations translate to large errors in reading. This is where I think you're missing the issue. Give it some thought and I think it will be plain.

Daniel

[Gary Warner]

Daniel,

I was just trying to help. Since you say you have tried and considered my approaches, what else can I say. It's your project and I have enough of my own. Good luck.

Gary
--

[hugo_vincent]

Hi Daniel,


That was a very helpful post, albeit a little disconcerting because I'm trying to aim for the project to be work on a dsPIC or similar. No X-Scale here for size, cost and power reasons. I'm hoping for something reasonable cheap and small.

I assume you have seen Gumstix - 32-bit 200 MHz and 64 MB for $99. dsPIC's at Digikey are around $10-15 for 8-bit 30 MHz, 2 kB RAM. Of course there is nothing at all wrong with small and cheap if you can pull it off :)

Have a look at the Philips LPC21xx series: 32-bit ARM7 at 60 or 70 MHz, internal flash, RAM and peripherals just like a PIC etc, TQFT48 or 64 pin packages (hand solderable quite easily), about $3-$12 in one-off quantities on Digikey. There is free programming software for them (for Windows or Linux), free C/C++ compilers (gcc), and they don't need a (hardware) programmer (there is an on-chip bootloader and you load your programs over the serial port).


How does this compare to the Silicon Micro-Machines CRS03/07 gyros? These were supposed to be very low drift and shows good linearity. I'll take a look at the specs for the ADXRS150 later - thanks for the pointer though.

They are both good gyros, but I think the ADXRS150 is better :) It is a BGA part thought, so you might need to buy the carrier boards from Sparkfun. BTW, where are you (planning to) buy those CRS0x gyros from? and what's the price?


I was hoping to keep things simple with a simple RC filter and then doing some averaging in the software. That may not work as well but it may be adequate.

Yeah that should work (a one or two pole RC filter). It will definately help compared to no filtering (many of the circuits on the web seem to have no analog filtering)


<snip autopilot project on Sourceforge...>
Yes but they do have code for a 1-D tilt system and that's handy.

Convenient indeed, but its not quite correct... I spent some time looking at that code and working backwards into equations etc, and while it does works, it is not "optimal", meaning they aren't using all the information available from those sensors.

I wrote a 50-line 1-D gyro-accelerometer function that you can have a look at if you like. Its a rather dirty hack, but at 50 lines it is very simple and should be easy to understand. It just does a 5th order Simpsons rule integration on the gyros, and uses feedback from the accelerometers to bias the gyro integration just enough to cancel drift, and varies the feedback gain based on whether the acceleration vector is 1G. It works well enough and has good bandwidth, latency and low processing requirements, and did the job while we worked on a Kalman filter.



remember that if there are any dynamic accelerations and the accelerometer is not just measuring acceleration due to gravity, the output will not be 1.000 G (think about Pythagorus). I am talking about the overall acceleration vector here, not just the output of any one accelerometer. You can use this information to weight how much you trust the current accelerometer-derived attitude angles. When you have exactly 1 G you can reset your gyro integrations to the accelerometer-derived angles.

It's a good idea but even when the vector is exactly 1G you cannot be sure that the accelerometer is level. This is where the Kalman filter code comes in. Instead of looking for the particular point of accuracy (which is indeterminate in any case), it averages over time and makes a best guess at what would be the right value. This way, it makes many minor corrections, none of which will be as good as one single reset but they work in concert to keep things in check.

Yep, the Kalman filter is a so-called optimal estimator, that is, is the mathematically best way of estimating variables from noisy and/or incomplete measurements (constrained by certain assumptions about the system, e.g. linearity). Also, you don't want things reseting all of a sudden (i.e. attitude estimating changing a big jump), because it will probably do bad things to whatever feedback control system you use, e.g. introduce instability/oscillations.

Can you give an example of where the accel. vector is 1 G and you are not accelerating? The only ones I could think of (e.g. in a banked turn and accelerating laterally along the radius of your banked turn into the center) would not happen in an airplane (I think :)).

(Note that the idea about exactly 1 G can only tell you whether you are accelerating or a static, i.e. whether to trust your accelerometer-derived attitude or not. It can't be used to tell you the actual attitude because you don't have enough information to be able to decompose that vector into its constituent dynamic and static components.)

Hugo.

[TMorita]

Bad news. I'm back to square one here. Having given it a bit more thought, I do not think that any kind of accelerometer will on it's own be able to provide level sensing with respect to absolute gravity alone. There simply is no way to discriminate the data.
...

Daniel

I wish I had seen this thread earlier and saved you trouble.

I could have told you this, as I spent a lot of time thinking about it before.
An "accelerometer" basically measures weight along one axis.

Toshi

[Daniel Wee]

Hi Gary,

I just want to add that I do appreciate your input here - any input is better than none and even though it didn't work out, it is still appreciated. :) I hope I didn't come across as dismissive as that wasn't my intention. Thanks.

Daniel

[Daniel Wee]

Hi Hugo,

What a great reply! I found several points you made really helpful. I understand what you're saying about the covariance matrices and the reliability of the data.

Back to my project goals - I started out really wanting something pretty basic, like the FMA Co-Pilot but with room to grow the code. It was meant to be small enough to fit on a small helicopter like the T-Rex if you've seen one. This will be primarily a helicopter application so it does give rise to more possible scenarios that you may not see in a plane. The decision to go with the dsPIC was due in part to it's small size. At this point though, it appears that I might not be able to accomplish all the processing within that package. In fact I was thinking of building an independent attitude sensor - and so use 2 processors for task sharing but all this means that the size and power consumption will go up - which I'm not real keen on. Now I am reassessing the feasability of this project and the design constraints. I honestly had no idea it would get this complicated when I started, lol :)

I was thinking of buying over some damaged GY401/240 and salvaging the SMM gyro. That was the plan at least. Sparkfun has a gyro and 2-axis accelerometer combo but it's not cheap either at nearly $115 each module (will need two).

I would be most interested to see your code on how you corrected the gyro drift. I'm assuming that all integration would be based on the Simpson's method anyway, given the way we're reading from the ADC. I actually considered an analog integrator but it has it's own problems too.

Thanks for a very informative reply. It is evident that you're been down this road before :)

Daniel

[billyzelsnack]

My accelerometer eval kit showed up in the mail. Here's what I have so far..

http://z425.com/phpBB2tastic/viewtopic.php?p=105#105

I think I am going to give a foolish go at a gyroless IMU.

[Daniel Wee]

I'm using the Freescale part too, with a 10-bit ADC. Keep us posted if you find anything interesting. I suspect you'll end up hitting the same wall that I hit :)

Daniel

[billyzelsnack]

What kind of angular resolution are you able to reliably extract from it?

[Daniel Wee]

Off the top of my head, I think about 0.5 degrees or better, depending on which sensor and what inclination. It's non-linear and the resolution gets really bad near 90 degrees. You should download the application note for the part from their website. It actually has a very good explanation on how to linearize the output and expected precision using 8, 10 and 12 bit ADCs. I've heard that the Freescale part is noisier than Analog Devices parts though but I've not been able to test or verify this for myself.

Daniel

[billyzelsnack]

Pfhew. 0.5 degrees is much better than the 5.625 degrees resolution it is spitting at me now.

If you are using a 2 axis unit for a single angular measurement I'd guess that when one axis starts to get poorer resolution, the other axis starts to get better resolution.

[Daniel Wee]

Yes, it does average out if you use two axis, except that at the extremes, the jitter results in big jumps in readings and the low res side will overwhelm the high res side. You'll have to play with it a bit. In my case, I had the ADC scaled to the supply rails of the sensor and so I was getting pretty good range out of the ADC, which was a 10-bit one.

Daniel

[Gary Warner]

Hi Daniel,

I've been out for Christmas, sorry to not get back sooner. I hope you had a good holiday.

Ok, I'm dense :o . I see what the problem is. Lateral acceleration results in the unstable condition that only gets worse as correction (wrong roll correction) and acceleration increases. My bad. It's been hard to understand since for me, the accelerometer works.

I'm still spending "thinking time" on the use of accelerometers without gyros for this control problem. I still feel that the use of the Z axis is imperative since a roll will reduce the Z data (assuming you maintain 1G vertical acceleration) and a side "slip" acceleration will not reduce Z, again assuming you maintain 1G vertical acceleration. There has to be a way that these two factors can be used to determine if the helicopter is sliding sideways or rolling.

It's not as simple as I describe, but I'm working on the basis of the above logic. What has to happen is that the response control curve has to be stable. As your setup was neutral, once a disturbance is encountered, the response curve became unstable. (at this point I'm just "typing" or thinking out loud).

The system (as you've said) becomes unstable because reference to the ground is not absolute. So, how to get that reference? The thermopiles work because of the constant reference to ground.

Here's an idea that was touched on in the Hamster thread, though I understand it most likely won't be practical for a helicopter, but it still shows I'm thinking.

The helicopter has an axis location somewhere on the frame when it rolls, a roll pivot point of you will. If an accelerometer was placed above this point and another placed below this point, some useful data should be available about the condition of the roll and side slip (lateral acceleration). If a roll was encountered, there would be a differential (opposite acceleration) sensed by the two sensors. In a side slip, the data would be complimentary (agree with each other). But of course, lateral acceleration and roll never exists by themselves in a helicopter. The trick here would be to differentiate between the two over time. Where one or the other can be understood by the controller for a split second, the interference of the other effect needs to actively nulled.

Could the differential of the two sensors be used to control the gain of the roll correction? The problem I see here is not so much with the theory but with obtaining usable data. What the differential sensing does is in effect read roll rate, much as a gyro would do. It really is a gyro of sorts. But the gain of these readings would be directly affected by the physical distance (moment arm) about the real pivot point. In a sailplane we have the luxury of a long fuselage and large moment arms, and vibrations are of little concern.

If nothing else, this gives me (and maybe you) a better picture of what the introduction of a gyro would do for this hovering effect you are trying to get. Effectively, as I see it, the gyro is used to control the gain (from "off" to full "on" and anywhere in between) bases on real sensing of roll. Sensed roll from the gyro would "open" the gain of the correction and no roll sensed would shut down the gain of the correction.

I'm not saying anything new here, I'm just typing out loud like I said.

Gary
--

[hugo_vincent]

Hi Gary,

The accelerometer-based gyro-free sensor arrangement has been researched and analyzed many times before, for instance, read:

http://www.path.berkeley.edu/PATH/Publications/PDF/PRR/2000/PRR-2000-09.pdf
http://www.path.berkeley.edu/PATH/Publications/PDF/PRR/2002/PRR-2002-21.pdf
http://www.google.com/search?q=gyroscope-free+imu+filetype%3Apdf

They use 6 accelerometers mounted at the centers of the 6 sides of a cube. Their conclusion: it drifts an order of magnitude faster than a gyro-based arrangement, e.g. if you can build a gyro/accelerometer unit that drifts 1 degree per second (quite good really) before correction (e.g. Kalman filtering), then the accelerometer-only unit will drift at 10 degrees per second.

P.S. Daniel, Here is that non-Kalman code I was talking about:

#define FUSION_WEIGHTING_ROLL 0.005
#define FUSION_WEIGHTING_PITCH 0.005
#define FUSION_WEIGHTING_YAW 0.005

#define IMU_DELTA_T (1.0 / IMU_RATE_HZ) // I am sampling at 50 Hz, and have 25 Hz low-pass filters before the ADCs.

#define TO_DEGREES(x) (x * (180.0 / M_PI))

/* We use a 6th order Simpsons rule numerical integration. See numerical.pdf linked from the bottom of http://psas.pdx.edu/ImuCalcs */
static const double VelCoeff[6] = {
9.0 / 24.0,
28.0 / 24.0,
23.0 / 24.0,
23.0 / 24.0,
28.0 / 24.0,
9.0 / 24.0,
};

void data_fusion()
{
int i;
static float roll = 0.0, pitch = 0.0, yaw = 0.0; // this is the result
float roll_gyr_int = 0.0, pitch_gyr_int = 0.0, yaw_gyr_int = 0.0; // temporary vars used to integrate gyros
float roll_acc, pitch_acc, yaw_gps; // roll and pitch angle estimates from acceleration vector, yaw/heading estimate from GPS

if (dataValid)
{
/* Do the integration */
for (i = 0; i < 6; i++)
{
roll_gyr_int += InputData[i].gyr[Roll] * VelCoeff[i];
pitch_gyr_int += InputData[i].gyr[Pitch] * VelCoeff[i];
yaw_gyr_int += InputData[i].gyr[Yaw] * VelCoeff[i];
}

/* Scale to account for sampling period */
roll += roll_gyr_int * IMU_DELTA_T;
pitch += pitch_gyr_int * IMU_DELTA_T;
yaw += yaw_gyr_int * IMU_DELTA_T;

/* Compute the Euler angles of the acceleration vector (~gravity) */
roll_acc = atan2f(InputData[5].acc[Y], InputData[5].acc[Z]);
pitch_acc = atan2f(-1.0 * InputData[5].acc[X], InputData[5].acc[Z]);
printf("Roll.acc = %f\tPitch.acc = %f\n", TO_DEGREES(roll_acc), TO_DEGREES(pitch_acc));

/* Get heading from GPS */
yaw_gps = GPSData.heading;

/* Feedback accelerometer angle to track gyro drift/integration error */
roll = roll + FUSION_WEIGHTING_ROLL * (roll_acc - roll);
pitch = pitch + FUSION_WEIGHTING_PITCH * (pitch_acc - pitch);
yaw = yaw + FUSION_WEIGHTING_YAW * (yaw_gps - yaw);
printf("Roll.fused = %f\tPitch.fused = %f\tYaw.fused = %f\n", TO_DEGREES(roll), TO_DEGREES(pitch), TO_DEGREES(yaw));

/* Copy to INS_Data */
INS_Data.dir[Roll] = roll; // These are the outputs
INS_Data.dir[Pitch] = pitch;
INS_Data.dir[Yaw] = yaw;
}
}

The measurements from the gyros and accelerometers are put into the InputData array (the integration needs the current sample plus the last 5 samples, in order - InputData[0] is the oldest sample, and InputData[5] is the newest sample). The measurements are already scaled into real-world units (i.e. m/s**2 and deg/sec) This is a full three-axis implementation (3 gyros, 2 two-axis accelerometers). In my case, Z is acceleration down, X is acceleration forward, Y is acceleration rightwards. Positive pitch is rotating up, positive roll is rotating right wing down, and yaw is rotating clockwise from north.

Let me know if you need any help, and please share any improvements or fixes with me (the code is GPL licensed). This copy of the code does not incorporate the 1.0 G thing for simplicity and because I am not even sure if it's right, but it is simple to add in again (change FUSION_WEIGHT_xxx into a variable and make it a function of the magnitude of the acceleration vector).

[billyzelsnack]

I did a quick scan of those Path papers and it seems like what they were doing was to use accelerometers 'like' gyros. ie.. To get an angular rate. I just don't understand how an accelerometer can "drift" otherwise.