Create an open source INU-module project? [Archive]

skogsvargen

Oct 06, 2006, 08:52 AM

One of the hardest units to design in a home made autopilot system is the INU with it's sensors and filtering. Many people lack the knowledge to understand the math’s involved

Complete INU units with both sensors and filtering software are still expensive to buy.

There are a number of open source projects, for example autopilot.sourceforge.org, but they are often part of a complete AP-system or designed for a specific task.

The sensors costs have dropped. You can buy six degrees of freedom for approximately $100.

My idea is to form at team to design a INU module and load it with the necessary software to supply an Autopilot with stable angular positions and velocities.

The UAV Development Platform from Sparkfun would be an ideal starting point, but i think a more general design containing just gyros and accelerometers would be better.

The unit can send data over a serial connection and for example an I2C bus for easy interfacing with other modules.

Code from existing open source projects could probably give the project a flying start.

By doing this I we would help many hobbyists overcome a hurdle that is stopping them/us from moving forward with their projects.

I am certain that we can find all the resources needed in this forum to accomplish this task.

I am willing to coordinate the effort and take the costs involved to build the prototype.

Resources needed :
* System design/project management. To coordinate the project and define the protocols needed to communicate with the unit.
* C-programming. Preferably one that has implemented Kalman filtering code in a project already
* Hardware design. I think some people will build their own design with their preferred CPUs etc. But a good reference design is necessary.
* Testpilots
* People with knowledge with similar units that could help with input on features etc.
* Documentation/web editing.

The idea is to start SIMPLE. Take readings from two or three gyros and Three accelerometers, sample, convert and filter the data and present it to other units. If the project is a success we could add additional features and build units with other sensors etc.

Anyone interested?

/Magnus
Stockholm, Sweden

Unterhausen

Oct 06, 2006, 11:42 AM

Too bad the sparkfun 6dof imu doesn't have gps and 3 axis magnetometers, it would be nearly perfect I think the Kalman filter should be offloaded from the IMU.

skogsvargen

Oct 06, 2006, 01:45 PM

OK, thats the first thing to decide.What goes into the actual IMU? If you make it just a sensor board with only A/D conversion and unit conversion. Where is the best place for the Kalman filter. Is it better to combine Kalman Filtering all sensor data with PID-loop, and servo control. Why do you thing this is better? I don't say you are wrong! I'm open to any idea.

/Magnus

sergey123

Oct 06, 2006, 02:41 PM

and sparkfun 6dof does't have pressure sensors too and accelerometer could be 3x digital on i2c
real good IMU for UAV: 3x accelerometer, 3x gyro, 3x magnetometer, gps, 2 pressure sensors (air speed + altitude), infrared range meter…. and 100$ max :)

Unterhausen

Oct 06, 2006, 04:09 PM

I just looked at the Sparkfun V3 IMU, and it does have a 2 axis magnetometer. Depends on how out of shape your airframe gets as to how much you'll miss the 3rd axis. Trouble is that it's going to be only bluetooth, no serial. Bummer.

$100 max might be dreaming for the forseeable future :)

TheBobby

Oct 06, 2006, 08:12 PM

I'm not sur that a second pressure sensor for air speed have something to do with an IMU. Th IMU have to return the position and the attitude of the UAV. But air speed is not part of that. How will u integrat air speed in the expended Kalman Filter ? GPS, magnetmeter and altimeter, i'm agree. But for Air Speed (Pitot), I'm not so sure.

for 100$, u can't have the GPS :s if u want a very good one.

LukeZ

Oct 07, 2006, 02:06 AM

I agree with Magnus, start SIMPLE. Otherwise this project will end up nowhere, as so many others that have been tried here. You can always add MORE to a successful design later. The hard part is getting started.

Magnus is quite right. A workable, inexpensive IMU is a major obstacle for do-it-yourself UAVers at this point in time. Most people have instead resorted to horizon sensing, which has its limitations. There have been many discussions of starting just this sort of project, but so far none of them have taken off. Perhaps this will be the one that does. Even in the last six months I've noticed the arrival of several new and very intelligent people here. Getting the right folks together at the same time is half the battle.

My personal opinion is, start with what Magnus originally proposed - three accelerometer and three gyros, and the associated firmware. Or even just accelerometers on their own, to begin with. GPS, altitute, airspeed, all that stuff is much easier to do and there are solutions for some of it already. In any case it's just cherries on top. Get your three-axis attitude control mechanism working, and the rest will be simple enhancements to add later.

Unterhausen, I believe that the guys at SparkFun will sell you an IMU with serial instead of bluetooth if you ask for it. At least they used to, and the good thing was that it knocked a bit off the price. I think I'll shoot them an email to see if they still do. If so, the SparkFun unit would not be a bad one to prototype on, as it saves us a good deal of hardware work up front. A more integrated (and perhaps compact) circuit could be developed later, once the code was ironed out.

These are just my two cents... I would be happy to help in any way. I can program in C and have a few other minor skills. But I know nothing about Kalman or PID; even my trig is pretty shaky. Nevertheless, I think this is a very important project, and would like to be a part of it, when it finally does take off (as I'm sure it will someday here in this forum - maybe not now, but eventually I have no doubt).

Luke

skogsvargen

Oct 08, 2006, 02:55 PM

Well, I think that the kalman filtering belongs in the IMU, module. Otherwise Its just a unit that samples the gyros, accelerometers and other sensors. My idea is to have a module that helps the autopilot to keep the aircraft level. An altimeter/vario module can do the same thing with height data etc.

The IMU module could be expanded with additional sensors, magnetometers for example without changing the protocol and thereby make it compatible with simpler units. It’s even possible to build a module with horizon sensing which can be replaced with a more advanced unit when it’s ready.

I actually have gyros and accelerometers waiting in a package in my office tomorrow, and my first goal will be to connect them to my cpu and sample de data.

Then I will try to measure the attitude with filtered accelerometer data only…

My first thoughts of outputs and inputs:

Output

Filtered data:
X, Y, Z attitude, absolute angles
VX,VY,VZ turn speed, degrees per second
Other?

Raw data:
Gyro velocities
Acceleration

Input

Kalman filter gain.
Communication settings
Other?

I’m not that good at the theory of Kalman filtering yet and maybe we can get additional information with additional input to the filter. GPS data for example.

Well the project is on its way. I will continue to post my thoughts here and all comments, ideas and HELP from people with experience in the area!

What additional information would for example adding a GPS or magnetometers give us?

/Magnus

skogsvargen

Oct 09, 2006, 10:04 AM

Every one is talking about Kalman filtering. This document (lowcostuavs16.pdf (http://recuv.colorado.edu:8080/plone-site/pubandpres/lowcostuavs16.pdf#search=%22lowcostuavs16.pdf%22) suggests ) ) suggests an alternative approach that does not require as much floting point operations. It is quite straight foreward and worth reading.

/Magnus

sergey123

Oct 10, 2006, 01:29 PM

I am really enjoying reading this forum guys, lets continue talking and lets build really good IMU for HOBBY UAVs :)
Yes TheBobby, it is true all sensors and etc cost much more 100$ ( I would say about 400-600$) but I am sure that all in one chip IMU is on development now and probably we will see it soon. My point was - market needs it for cars (to drive by itself) for home robots to clean a houses and for hobby use too and as more we will be talking about really cheap and good IMU modules as soon we will see them :)
But for now we have only 2 options:
1) Buying what is already available (like from spark fun)
2) Building new (completely new or based on another open source project)

I do not know about you guys buy I just like doing/building something so in this case instead buying IMU form sparkFun (reasonably priced and well done) I would prefer building one. Now what kind of IMU, what sensors, what filters, what CPU it should have? I agree with LukeZ first of all it should be simple but by simple I mean simple concept, simple excellent idea how it can be expanded for new maybe not existing now sensors, simple for people for adding they own ideas. With this type of simplicity I would completely agree but with simplicity like (ok now we have only 2 sensors and later on will think how to add more not agree at all). I sow hundreds IT related projects and know exactly that if project from starting point not ambition, not based in good future vision and great ideas it will end up with amount simplicity to fail project at all.

Filtering: one thing I know exactly - no good data filtering no good results. A lot of hobby UAV projects failed or almost failed because not enough attention was given to filtering and autopilot software. Actually it is much more easy to build IMU/UAV hardware comparing with building software part. Software much more complex and has much more parts(modules) to make mistakes and have some bugs. What is why I am sure good IMU just should have good software otherwise it is will not be good IMU at all. Simple Kalman or Extentend Kalman filtering I would say not good enough in these days and something like Square Root Sigma Points Kalman should be used (if not something mode sophisticated)

Number of Sensors and GPS: For stabilizing plane 3x gyros and 3x accelerometers more than enough.
Magnus what you will do with perfectly flying plane with constant speed in all directions but inverted? Don’t ask me how it became inverted – lets say high and short side wind rotated it 300 degree a sec and sensors just did not run at that rate and filter just ignored it?
Now GPS, what the sense to build IMU for UAV if you will not able to setup waypoints for the plane? How to use a UAV plane without knowing its position, how autopilot will work? We need GPS for knowing plane position and we need magnetometers too for correcting its position on time when satellite not visible. Actually position can be calculated just by using magnetometers (it is another story). Altimeter – it should be in IMU for UAV too. Airspeed – good to have.

So my opinion: 3x gyro, 3x, accelerometer, 3x magneto, altimeter, AND GPS (may be airspeed and range finder for landings) and yes good CPU with floating point operations and C (C++) support. Preferable with Linux support too :)

Guys it was just some my thoughts about IMU for UAV, correct me if I am wrong :)

Unterhausen

Oct 10, 2006, 04:41 PM

I agree, but you left out the GPS. Except I would probably be inclined to go with multiple processors. For example, you could do pre-processing filtering of the data. That's often done with full-scale systems. Using something like the Gumstix to tie everything together is pretty attractive.

Unterhausen

Oct 10, 2006, 08:05 PM

I have a few of the Sparkfun IMU's. Today I was searching for code on the web, and found this post on the Sparkfun forums: http://www.sparkfun.com/cgi-bin/phpbb/viewtopic.php?t=4273
Looks pretty good if all you have is gyros and accelerometers.

sergey123

Oct 10, 2006, 08:34 PM

Ops for GPS,
for me having it on the board is so obvious that I did not mention it (edited now) :)

Agree with multiple processors – it is the best config. One CPU for internal filtering and second for waypoints management, communication with the ground station, second plane in an air (???) and etc. Real time Linux would be my preference as a second CPU because it is open, easy to use and has almost everything needed like communication protocols and etc.

Unterhausen thanks a lot for the link to Sparkfun forum, will read it too !!!

skogsvargen

Oct 11, 2006, 02:57 AM

I agree that a complete autopilot system would have more sensors than gyros and accelerometers. A GPS is off course for example necessary for positioning.

What I was trying to describe was a first step of a modular multi processor system. The first step was to build an IMU that just calculated the aircraft attitude with a minimum of sensors.

With a well defined protocol to use between modules it’s possible to add sensors without having to rebuild the complete system. It is also possible to add sensors to the basic modules I a later version.

An attitude module with its own filtering is (i think) one of the most complicated units, but could actually be based on IR horizon sensing in a first version and then upgraded to a gyro/accelerometer version with the same protocol to feed the AP.

A speed and altitude module is not as complicated to design and a positioning and waypoint sequencer is already under developed in another project in this forum.

Other interesting units/modules:

Mission controller (In its simplest form the waypoint sequencer)
* Holds the waypoint list and communicates with the ground station.
* Controls cameras and other payload
* Navigation calculations is probably performed here

Autopilot (RCAP is one unit to start with)
* Contains the control algorithms to keep the plane flying based on sensor and command input.
* The only module that needs to know what kind of airframe we are using.
* Altitude hold
* Speed hold
* Landing
* Take off
* Turn to X drgrees with turnangle Y
* etc.

Servo control/Failsafe
* Takes input from the AP
* Takes input from the R/C receiver
* Controls servo position
* Implements servo channel mixing for complex control surfaces

To save space two or more modules may off course be built on the same PCB, but I think that is a later discussion.

Please feel free to:
* Question my module definitions
* Add other modules
* Add features for modules

Sergey, are you able to design the Kalman filter you suggest? It would be interesting to make some calculations of what kind of CPU it requires. I am currently most interested in the filtering of attitude data, and at a later state doing positioning estimates.

All for now from a grey and rainy Stockholm

/Magnus

Blue Sky

Oct 11, 2006, 03:26 AM

Magnus, that is a very interesting paper, very understandable.
One thing I found interesting was that the filtered data most closely
resembled the accelerometer output with the rate gyros mostly sharpening
the response time. It made me think that it might be possible to use RC hobby
rate gyros that simply operate in series with the servos to act as a "spinal reflex"
to quell sharp transients while the more accurate, less drift prone, and less expensive
accelerometers are used with the gps for navigation.

-Dave

skogsvargen

Oct 11, 2006, 03:40 AM

Dave,
Interesting idea, It would definitly simplify things if it works. The only argument against is probably that Two r/c gyros is more expensiv than adding a dual gyro in tht IMU.

The discussion at the Sparkfun forum (http://www.sparkfun.com/cgi-bin/php...opic.php?t=4273) above is REALLY promising. If the code presentet there is performing as well as it looks we are one big step to making a working attitude module.

/Magnus

sergey123

Oct 11, 2006, 11:49 AM

Magnus don’t complain about rainy day in Stockholm, in Toronto it is exactly the same :) plus very-very slow traffic :) :)

Talking about Kalman filter. I just started reading some papers and examples…
It is difficult to estimate what CPU will be required. Currently I have some kalman modules/examples running on pc but still not sure what the best approach will be.

It looks like I like idea building model in some king of PC simulation software, get data from it, filter it, send into autopilot module, return commands into SIM and see how plane perform. After that all this code could be compiled into hardware CPU….

200volts

Oct 12, 2006, 05:58 PM

Count me in.
I have access to advanced surface mount equipment and personnel. I can also provide real pcb layout if needed.

The micro BGA packages used in most gyros and accelerometers will require a SMT reflow oven to do it right.

Analog Devices for the gyros. Note the older ADXR... series have been updated to an ADIS.... series that include signal conditioning. About $35 each(single axis). Dual axis available.

Analog Devices also has a 3 axis acceleromter for $12 each. ADXL330 with signal conditioning.

Pitot (airspeed) sensors are expensive air pressure sensors in the $75 each range.

BTW the Segway personal transporter uses gyros from Japan that cost about $300 each.

skogsvargen

Oct 13, 2006, 03:57 AM

PCB design and surface mounting would off course be a great addon to this project! I have received gyros and accelerometers (on break out boards) and are looking into the first version of the Kalman filtering project referenced above. I don't have that much time at the moment, but I hope I will have a prototype up and running in a week or two.

The specification on this first module will be:

* Three axis accelerometer
* Two axis gyro
* Serial output and input(for config)
* I2C bus
* Aux serial input for GPS receiver (I thing i will have spare capacity in the cpu to decode nmea and put it on the I2C bus and into the serial stream).

If i manage to get this setup working i would need help to design a PCB for it.

/Magnus

sergey123

Oct 13, 2006, 04:31 PM

Kalman from SparkFun is regular Kalman filter (KF). For having something to start work with it is good enough and will work with different boards. It could be used sequentially too for example 1 step row sensors data filtering and second step attitude filtering. Timing should be good too. Accuracy will be in 3-6 meters range.

I am looking for SRUKF (16-20 data values) but it is definitely will take longer 2 weeks :( and I dont have any HW yet .....

Magnus: why you don`t want 3x gyro and 3x magneto on first board? With them it will be almost full IMU unit.

200volts: Could you estimate cost for all sensors package? Like 2x + 1x gyro, 3x acc, 2x + 1x mag, Pitot, gps, altitude pressure

ADXL330 15$, 2x IDG300 – xx$, SiRFStar-III about 100$, ……….

For sensors candidate lets have a look at albatross open-source project:
http://www.albatross-uav.org/index.php/Version2:Hardware

Unterhausen

Oct 13, 2006, 10:48 PM

this thing is really cool:
http://www.sparkfun.com/commerce/product_info.php?products_id=8128
Barometric Pressure Sensor MEMs - SCP1000-D01

LukeZ

Oct 14, 2006, 01:27 AM

Holy cow Unterhausen! That is just the thing I need. Thanks for the tip. I may actually get a working altitude hold circuit done now...

Luke

hugo_vincent

Oct 14, 2006, 04:48 PM

Hi sergey123,

Can you tell me more about your Square-root UKF? I have been trying to implement one too, on and off, over the last few months. I wrote a non-SR UKF, but it had the numerical stability problems that are the reason people use the square-root version. It crashed after only 30-100 iterations because the P matrices became non-positive definate (due to numerical noise).

What processor are you going to use to run the SRUKF? I am speccing up a new board with the Philips LPC3180 processor - ARM9 @ 208MHz, with hardware floating point (so for floating-point math, it will be around 10-20x faster than a 400MHz PXA255 like the Gumstix).

p.s. I am the person behind the Albatross verison 2 hardware (well, someone else is doing the engine control board, but I will be designing the main CPU and IMU board). I can't really offer that much help to another open source IMU/INS project because my IMU needs to be integrated into my main board, but will be following this one interestedly, and we could probably collaborate on the software.

Hugo

sergey123

Oct 15, 2006, 06:35 PM

Hi hugo_vincent,

Albatross is a great project and you guys very lucky that you can work on it :). Keep it going and keep it open source !!!

For now I am not sure that we have HW designer here (I’m not good with HW) but I’m sure we can share some ideas and code or even can design HW part the way it could be used for both projects. From my side I’m completely open and will publish open source any good results :).

About SRUKF: In two words SRUKF filter has much better numerical stability (during state covariance update) comparing with EKF and UKF. Very good sensors (like in Seway) cost a lot and really not affordable to hobby purpose what is why with cheap sensors it is better to use good filtering.
I am not really sure what CPU we going to use but hopefully I will have soon some performance results to compare with.

Rudolph van der Merwe, Eric A.Wan and A. Bogdanov have a lots of publications about data filtering and autonomous systems:

http://choosh.ece.ogi.edu/
http://choosh.ece.ogi.edu/spkf/spkf_files/SPKF-INS-Overview.pdf
http://choosh.ece.ogi.edu/spkf/spkf_files/WAML2003.pdf

Sergey

hugo_vincent

Oct 16, 2006, 05:28 AM

Thanks sergey123,

Thanks for that. The papers by van der Merwe et al are the ones I have been working from. I am well aware of the problems with cheap sensors :-) and have experienced the numerical stability problem first hand.

I would appreciate if you could share some code with me for your SRUKF INS design, in what ever state of development it is in. In turn, our project might be able to help you out with hardware.

Cheers

brianhomer

Oct 17, 2006, 02:25 AM

Dear all,

I am also working on that, I am trying using PIC16F877 as the controller and using the sensor instead of sparkfun 6DOF IMU, I thought in the software design and control may be more flexible.

Will share my progress and problems which encounter. Hope to receive your comments.

Brian

sergey123

Oct 17, 2006, 11:25 AM

Hi, hugo_vincent,

honestly speaking I am just on initial stage of writing SRUKF. Currently I am concentrating on reading docs, looking for good examples and etc… Still have some questions what the best approach will be :).

What I have for now: really not too much…
1) .m example files for different filters
2) ReBEL filters tool kit (not open source but free for academic use)
3) some cpp examples for KP, EKF, UKF, SRUKF (gsl based) and QSRUKF (by David Sachs from MIT)

What exactly my project plan:
1) Build data generation model in scilab or matlab ( real data + noised data).
2) Build and test the srukf filter in scilab or matlab. Something like: load data from files, filter, output into result files, plot graphics, estimate average errors
3) Write .m model in cpp (or may be modify some examples)
4) Test model with data files generated by scilab. Compare cpp results with results generated by scilab(matlab).
5) Test filter on real 6dof IMU

My questions for now:
1) Can gsl library be used on ARM9 or it is to heavy.
2) How filter will be used on deducted CPU or shared with autopilot and etc

Filters average iteration time what I have:
UKF: 0.000310832, SRUKF: 0.000311566, QSRUKF:0.000511995 on P4,3.6CPU

Have a look on David Sachs SRUKF http://web.media.mit.edu/~dsachs/, what do you think about it? Can it be reused in ARM ??? I have compiled his examples on PC and it looks like it can output stable results. If you want I can upload somewhere complete VCPP project ….

Thanks,
Sergey :) :) :)

sergey123

Oct 19, 2006, 11:07 AM

hugo_vincent

Oct 19, 2006, 06:26 PM

Hi Sergey,

1) I think GSL should be usable on an ARM9, although I didn't try compiling it (it would probably need some, hopefully small, amound of effort to port).
2) I'm not sure exactly what you're asking, but I think it wouldn't be a problem to have the (SR)UKF and the autopilot/control algorithm on the same CPU, in fact that would probably make things easier. That is the approach we are taking with Albatross.

I have had a look at David Sachs SRUKF, and modified it to build with GCC/G++ on Linux. I get similar performance to you (around 0.0005 on an Athlon64 3000+). It looks like it will be possible if not trivial to port it to ARM9 embedded Linux, assuming GSL can be ported and compiled (which it should). I haven't had a close look at the code, as I will be writing my own SRUKF anyway (I don't want to use GSL, even if it probably could be used).

As for who is committed to this project... as I said before, I would like to help where I can, but have my own project to work on. If you end up using embedded Linux on ARM9, I expect our software should be of use to you.

Hugo

sergey123

Oct 19, 2006, 08:54 PM

Hi Hugo,

I know that you are busy with Albatros... Mostly I was asking LukeZ, Unterhausen, skogsvargen, and 200volts … if they really committed to build IMU.

Cool, I am surprising that we have the same opinion. I also don’t want to use GSL and also like Linux (GSL just a backup plan, I found that is already ported to ARM). Actually Linux is my personal preference – for very small reason – I like it. Ok, will keep you guys posted with my filter development ….

Sergey

LukeZ

Oct 19, 2006, 09:32 PM

Sergey and the rest, I am quite happy to help where I can. This Kalman filtering stuff is really over my head. I'd like to learn it, but I wouldn't expect it any time soon. My time is fairly limited.

Still, I will monitor the progress here closely. At any point that it looks like there's something I might know how to do, I'll jump right in.

Luke

skogsvargen

Oct 20, 2006, 03:27 AM

I’m still here and I am committed to the project. I think the Kalman filtering discussion is extremely interesting, but unfortunately I can’t add much. I have a question though. Is a Kalman filter for positioning similar (or the same) as a filter for predicting attitude or are we talking of two different filters, one for positioning and one for attitude?

At the moment I am focusing on getting my IAS and altimeter module working. Everything looks all right on the breadboard, and I have a friend that will help me to design a PCB for it. The module will output speed and altitude data on a serial port and will (eventually) act as an I2C slave. There might also be one or two additional ports for sensor data that is useful on the serial or I2C bus.

What precision do you think is necessary for an altitude hold autopilot? What error from the set altitude would be acceptable to you?

/Magnus

mikel

Oct 23, 2006, 04:23 PM

My final project is going to be UAV-related - something that would help me to build a complete UAV later. One of the options is an INU with some sort of filtering - complimentary/kalman. Another option is to build something like a gps guided car that doesn't need 6DOF and (probably) requires less filtering.
I don't know if I can be any help with this OS INU project since my experience with embedded stuff is very limited.

Mike

200volts

Oct 27, 2006, 05:33 PM

Brand new 3 axis accelerometer with tilt and gravity outputs.
http://hdk-america.com/ look for HAAM-325B
$26 ea.
note the 3 x 3 mm package

PFTrvlr

Oct 27, 2006, 11:13 PM

Sent to TS NG in Singaporer.

I wanted to start my own UAV project a while ago, but never get around to do it. I got rid of some of the stuffs. What is left I can send out for free if anybody is interested:

2 x ADXL202JE,
1 x Pic18F4620 and some Pic A/D chips

Let me know your address so I can post to you.

tedrobphoto

Nov 24, 2006, 07:36 AM

Brand new 3 axis accelerometer with tilt and gravity outputs.
http://hdk-america.com/ look for HAAM-325B
$26 ea.
note the 3 x 3 mm package

Hi, I normally post on another forum, namely multirotor helis.
The machine I am flying (or trying to) is the X3d upgrade(from Germany) of the Silverlit XUFO which is a four rotor helicopter originally stabilised with a mechanical gyro but now this is replaced with the multi piezo gyro X3d module. The flying characteristics are such that only four channels are needed viz. pitch, roll, rudder and throttle (for height). Can you suggest an easy way of adapting the GPS technology so that when the machine is at the right height and orientation it can be (more or less) fixed in that position even though it is subject to external inflences ie wind .

I am an oldish (70years young ) guy who has been dabbling in aerial photography for a number of years

Ted R (Cheshire UK)

treehog

Nov 24, 2006, 11:20 AM

I am interested in monitoring this project hopefully it will bear fruit within a few months or years as not in so much of a hurry
to do UAV

I think open source projects are the way to get affordable solutions for us average joes

tedrobphoto

know the feeling not guite 70 but nearing the half centry so need some distractions in life

figure for you expermintation wil be much easier to verify your set up with slow acting units that seem to exist nowadays on the net

if you tether the model to the ground and use a large fishing rod to tether the top and you can get it to hover in a fixxed position low down say 5 feet then it should be OK after that to go higher untethered

Much easier than moving planes or unstable heli versions which will probably need fastest speeds and more expensive units like what I need for ground avoidance in DS ( my on board electronic connections to fingers are not fast eneogh )

you should check out the paparatizzi (http://www.nongnu.org/paparazzi/ ) guys they got a lot of small UAV problems licked and its open source and I dont think they will hold it against you your not french :D

UAV and MINI uav links

http://www.rcgroups.com/forums/showthread.php?t=423667

http://www.us-euro-mav.com/teams_participating.aspx
http://www.delfly.nl/?lang=en

team up with a modeller who can solder together the PIC and gps that paparazzi combo do and you should be up and flying the uav in weeks rather than months but it will still cost a bit a few hundred pounds thereabouts not counting crashes so cheaper to tether

In north america the gps will be considerably more accurate from extra info downloads that EU dosnt have acces to as it comes from geo stationary satilite over north south america footprint so in the UK expect more drifting up to 10 metres

Ralf

tedrobphoto

Nov 24, 2006, 01:37 PM

brianhomer

Nov 24, 2006, 10:49 PM

this thing is really cool:
http://www.sparkfun.com/commerce/product_info.php?products_id=8128
Barometric Pressure Sensor MEMs - SCP1000-D01

Well I just got it...and this can be simply connected with Armmite and using ArmBasic to get the info. However, before Armmite can use GCC utilities, I might need to consider PIC16F877 as the Kalman filter calculation, and Armmite mainly for sensors information collection purpose

brianhomer

Nov 24, 2006, 11:13 PM

Hi, brianhomer,
Certainly software design should be flexible but I am not sure if it is possible to use floating point operations on PIC16F877. It will be very difficult to write good kalman with no integer logic only….. .
What exactly you are working on IMU or software? (Software for filtering, or positioning /navigation). I am not sure if we have anybody how is writing postitining/navivational part yet, so you (as EVYONE ELSE !!!) help will be is greatly appreciated.

If anybody wants to check out squkf by David Sachs: here is attachment
… and also picture with filtering results (Why UKF and SRUKF are better)

Questions:
a) Guys do you think we can double check who is committed to this project and what part exactly (hardware design, altitude sensors, software and etc)???
b) What the current status of you progress???

1) Me (Sergey): Kalman filters for row sensors data filtering (no positioning, no navigation for now)

Hi sergey123,

sorry I missed your message as I overlook the attention name is to me...really apologise.
You are absolutely right. since I am only concertrate on my desktop computer. I didn't have too much study to mirgrate the software to hardware. If considering the weight, at present only one notebook (Sony) has the palm size and the weight is acceptable. But it would be to expensive to use this computer as the main control. Now I am concerntrate the sensor assembly, and studying (recover my memory) the Matlab and Kalman filter.

tedrobphoto

Nov 28, 2006, 05:44 AM

skogsvargen

Nov 28, 2006, 07:09 AM

LukeZ

Nov 28, 2006, 10:29 AM

Magnus, that is indeed very good progress. Good luck with the rest, I'll be watching.

Luke

Unterhausen

Nov 28, 2006, 12:14 PM

Magnus, what processor are you using? I don't think a kalman filter is going to to be reasonable to fit on an AVR.

Did you look at the code from rcpilot and the xbow micronav? Both are on sourceforge.

Eric

skogsvargen

Nov 28, 2006, 02:45 PM

Currently I'm running on an ATMega168 but i'm not sure if the code will fit. If not i'm moving up to a ATMega128. My idea is to run as little as possible on each CPU end the Kalman filter i'm starting with (take a look at http://www.dev6.com/) has been run on an ATMega before. It's to early to tell if it will work for me, but i'll give it a try.

The only thing this CPU will do is to read attitude sensors and estimate the airframe attitude. To begin with i'm only using gyros and accelerometers, but in the future i might try to add a compass and/or GPS heading.

Taking one small step at a time is my way getting forward...

/Magnus

sergey123

Nov 28, 2006, 05:36 PM

I'm still here too :))
Status update:
1) have working kf, ekf, ukf and srukf in matlab with raw data filtering for now
2) looking for best/simplest C++ library with *+-/' matrix operations support
3) reading navigation papers ...

About required CPU: Looks like ukf/srukf will need a lots of cpu power and more sensors mean more CPU too ..

Sensors: New Analog Devices Tri Axis Inertial Sensor ADIS16350 (IMU) 3x (gyros + 3x acc) http://www.sparkfun.com/cgi-bin/phpbb/viewtopic.php?t=5060&start=0&postdays=0&postorder=asc&highlight=

brianhomer

Nov 29, 2006, 10:49 PM

Just wanted to let you know that I’m still working on my project. Lots of “real” work and a puppy has taken most of my time, but I am making slow progress.

Status:

Done
• Reading values from accelerometers and gyros and converting data to angles.
• Sending data to the PC over serial line
• Develop PC-app to display IMU attitude

Working on
• Adapt the Kalman filter code published on the Sparkfun forum
• Add temperature compensation to gyro data

My goal is to have the Kalman filter working with sensor data before Christmas.

The biggest threat to the project right now is that the dog loves to eat all my cables!

I’ll keep you posted!

/Magnus

Hi skogsvargen,

I am also have the similar planning with you. even the pace is similar. this week I will completed the 6DOF IMU and data reading. Then will communicate with computer by RS232. At the same moment, I assembly a wireless RS232 modem, for me to collect the 6DOF flight data at site (RC plane usually flying within <500M half radius.)
I don't have dog (no time to manage), but my neighbours have more than eight just opposite my apartment and barking everyday. Usssh......

Nice to read your progress again.

Brian

skogsvargen

Dec 12, 2006, 06:09 AM

Kalman filter or not...
I have been playing with the data from my gyros and accelerometers and i would like your feedback. Is it realy necessary to implement a Kalman filter as long as we are aiming to control the attitude of a fairly stable fixed wing aircraft.

Will the following idea fail?

* Use the gyro data to control attitude.
* Use lowpass filtered acceleromter data to continously adjust the gyro drift.
* As soon as i can sample stable accelerometer values for X number of samples set gyro angle = to angle.

Of course this is a very simple filter and it will not be able to provide data to save the plane from an uncontrolled situation, but could it be a start?

/Magnus

sergey123

Dec 13, 2006, 10:33 AM

Hi Magnus,

It is always better to filter data (if not required) and based on what you want to achieve will be different filter implementations. I already have all filters in matlab and they seams working fine but converting them into hardware it s big step and as more sensors as difficult it will be.
I don't have hardware yet and publishing something untested I think is completely useless.

Have a look at MNAV autopilot (if has two stages EKF filters inside)
http://sourceforge.net/project/showfiles.php?group_id=146680
and kalman from sparkfun too.

BTW: Do you have log files from you sensor board (they can help me with testing)

Sergey

skogsvargen

Dec 13, 2006, 10:55 AM

Only logfiles from flying the board in my livingroom in my hand... Still some work before i will share them. :)

/Magnus

yuri_base

Dec 14, 2006, 01:19 AM

Yo!

Although I'm not an RC enthusiast - I'm a skydiver/wingsuit pilot and a BASE jumper - I'm trying to build a system which will provide a feedback to wingsuit pilot to improve the glide ratio. Currently, I'm trying to use Eagle Tree Systems' flight recorder for this purpose, but looking forward to using gyros for sensing the pitch angle and angle of attack. This is an interesting project!

If you're curious what wingsuit flying is all about, visit www.phoenix-fly.com.

Well, I guess, this is just an elaborate way of saying "Hi!" :) I'll chime in with the results when I have them.

Yuri

Tom Harper

Dec 14, 2006, 09:08 AM

Magnus,

How do you 'cage' the system? By that I mean what is your reference to level? Both for an initial state and ongoing.

Very interesting project - keep up the information.

skogsvargen

Dec 15, 2006, 05:29 AM

Tom,
This is still to be decided. Currently i am using the accelerometer data to initialize the system. As long as the system is still the accelerometers will give me an absolute reference At system boot or after a signal the gyro signals are measured and calibrated to minimize drift. I am still lacking gyro temperature calibration.

/Magnus

Tom Harper

Dec 16, 2006, 02:33 PM

Magnus,

Have you considered using electrostatic sensors on the wing tips as an 'absolute' reference?

Tom

skogsvargen

Dec 18, 2006, 05:37 AM

electrostatic sensor? = Thermophile sensors? I'm not sure what you mean? Thermophile sensors are of course an alternative, but i think the combination of gyro andaacelerometers will give me a more flexible system.

/Magnus

Tom Harper

Dec 18, 2006, 07:27 AM

Magnus,

Years ago Maynard Hill made some systems that sensed the earths electrostatic field with wingtip probes. The electrostatic field increases at about 180 volts per meter of altitude (Ben Franklin kite experiment) so you can get a sizable signal from a small tilt of the wings. It is very high impedance but within the capability of modern op amps.

This link has a schematic. Looks like 100Megohms is enough:

http://www.charlesriverrc.org/articles/asfwpp/lelke_alb2electronics.htm

dleroi

Dec 18, 2006, 10:59 AM

Tom Harper

Dec 18, 2006, 12:38 PM

Don,

Thanks - great link.

It might be possible to use needle points in place of the Ion sources for coupling into the electrostatic field. Otherwise need to find a cheap source of photo brushes.

Also, it is not an absolute level sensor. At low altitude it will tend to follow the terrain. That offers some interesting possibilities.

Tom

dleroi

Dec 18, 2006, 03:01 PM

Tom,

You're welcome. It would be really good to get Helmut Lelke's take on this. He's the guy that posted the plans at the site whose link you posted earlier. I've tried, unsuccesfully, to contact him. The listed email address is no longer valid, so I emailed the site administrator and asked him to forward my memo. He said he would, but I never heard from Mr. Lelke.

- Don

Tom Harper

Dec 18, 2006, 06:25 PM

Don,

Somewhere in my catacombs I have some articles and literature from Maynard Hill. I'll see if I can make them surface.

I'm sure I don't have the article you refer to. It certainly would be worthwhile.

However, the schematic in the link looks simple enough to try. Electrostatics work best out of doors and away from objects. But there may be a signal even on the workbench. I have had low loss capacitors take on a charge from leads that hung off of the bench top.

When I finish the present project I might give it a try.

Tom

dleroi

Dec 18, 2006, 08:18 PM

Don,

When I finish the present project I might give it a try.

Tom

Tom,

Let me know and I'll share with you what I've already done. BTW, I saw some of your posts in other threads. Seems that many of our interests run parallel.

- Don

naren

Dec 18, 2006, 11:34 PM

Hello,
Just wanted to ask you some questions.
1) What is your weight constraint and what are your flight dimensions?
I asked this question because you have to be careful with the sensors gyros, accelrometers and magnetometers. As there is a saying VIBRATION IS THE WORST ENEMY FOR INERTIAL SENSORS. So please look into it before you do the designs.
2) How long is the duration of the flight?
The gyros have the tendency to deviate. And as of the present techonolgy , you have to correct for every 5 minutes. So that's when the GPS comes into effect and the Kalman filtering you guys are talking about. I can't promise, but i'll be posting a document soon in this thread about the kalman filtering. I'll do my best to explain with a simple example of how to implement it. Also, recently in the technical community there is a talk of an inertial measuring unit with out gyros. There are atleast 5 papers i know of which talk about it and all of them use accelerometers.

Any ways i recently joined this group, and i'll do my best to see what i can help with. Onething i'm sure to help you is with KF. So i'll talk with Sergey123 and see what i can do.

yuri_base

Dec 18, 2006, 11:57 PM

I can't promise, but i'll be posting a document soon in this thread about the kalman filtering. I'll do my best to explain with a simple example of how to implement it.

Please do.

I'm trying to implement Kalman filter for wingsuit flying (it's a kind of RC glider with a human being being a glider ;) ). As far as I understand, the current use of Kalman filter in INU does not take aerodynamics into account, just kinematics (v=v0+a*t, x=x0+v*t). A set of equations for non-powered flight (see http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=2563135#2563135) (which can be modified for powered flight, too) can be used to provide a better Kalman estimate.

What do you think?

naren

Dec 19, 2006, 12:23 AM

In my application, i'll be using the system dynamics. I took a look into the link you sent, and i'll get back to you soon

Tom Harper

Jan 01, 2007, 11:23 AM

Magnus,

What's happening on your project?

Tom

OlegZarianski

Apr 18, 2007, 07:37 AM

Hi,
I trying to realize the same project.
At this moment I have written INS algorithm only, and module for GPS data reading, and decoding NMEA sequences.
the inertial sensors board now in progress.
As I haven't build the sensors board yet, maybe anyone can help me for testing my algorithm???
It will very nice, if anyone take for testing my algorithm (*.m files in Matlab)

2) The second problem that I have, it is filtering signals from noisy sensors.
In book "Kalman Filtering: Theory and Practice using Matlab" I have found information, that signal from sensors better prefiltered by low-pass filter, and then filtering by Kalman filter, as biases, drifts, scale factors of sensors are unknown.
Can anyone help me for realizing this information from this book in practice? (in Matlab)

wireflyer

May 13, 2007, 10:58 AM

Hi All
has this topic "died a death" or is there still some interest?

wireflyer

May 13, 2007, 06:30 PM

Hi
I am also trying to assemble a workable stability system using 2 rate gyro's and a accelerometer.This weekend I managed to complete the accelerometer daughter board.In the next few weeks I hope to finish the main board carrying the gyro pair and AVR micro.

all the best Lyn.

Jack Crossfire

May 14, 2007, 03:37 AM

> has this topic "died a death" or is there still some interest?

This is an open source project. What do you think happened?

The stuff on autopilot.sourceforge.net is nowhere near enough to do the job. Ranges and signs for the sensor output are missing. Magnetometer and GPS conversions are missing. PID loops aren't implemented.

I have filled in most of the missing pieces, but their Kalman filter still has issues.

skogsvargen

May 14, 2007, 10:23 AM

Well, Since I started this thread i have learnt one thing or two. The task of constructing an INU is to complicated for me to do, at least at this time. It is hard work to build something that is beyond what i will need for a long time, and i want to fly rather than just sitting behind my computer. I have selected a quicker way to a stable platform by using the CoPilot. I think an autopilot much like the paparazzi or the one MX is designing is the way to go at the moment, at least for me.

Wulffy

May 15, 2007, 06:59 PM

Ok, I have read the thread.

I concur on the majority of what has been presented.

Yes, IMUs are not easily constructed, nor cheap. The darned MEMS sensors are just too new and too expensive. The prices are so discouraging. I love the xsens unit and there are many others out there that possess similar size, power, and communication features, but they all cost an arm and a leg.

I too am at a point in my project where I need to focus on pitch/roll/yaw positions/accelerations/rates, and heading.

As info, I am using the ARMbasic solution from Coridium Corp - my source is here and will continue to be updated as things progress: http://tech.groups.yahoo.com/group/ARMexpress/files/UAV_Project_Files/.

I have spent the last month doing three things - tweaking the Navigation Solutions (Horizontal and Vertical), finally giving up on CORDIC (I just do not possess the math depth needed...) and Incorporating the MicroMegaCorp Floating Point Co-Processor (HIGHLY RECOMMENDED!!!), and studying up on implementing an IMU. The realization that I'd be chasing my tail for many months led me to resign that I needed to get a math solution in place for my existing hardware - the uM-FPU is Wicked Kewl - definitely worth the $20.00 I spent on it - I should have done that ~40 man-hours earlier, but I was being stubborn on implementing CORDIC - silly me....

OK, back to the IMU. Yes, most folks agree that TriAxial Angular Rates, Accelerations, and Magnetometer functions are pretty important to a truly 6DOF implementation. MEMS technology is the way to go. MEMS is somewhat noisy and requires filtering of some sort. Yes, SRUKF, EKF, KF, etc. are all means to an end. (my floating point co-processor is has a future rev coming out that will broaden it's capabilities regarding 2x2 and 3x3 Matrix math - wicked kewl...).

I have been studying (searching for) the right sensors to use. My initial design goal (I borrowed from another post in the UAV forum) is that of a Riser-Less IMU - I believe that it can be done using the attached partial-BOM.

I had hit information overload as I had studies literally hundreds of spec sheets, and read about a million different things on KF - it all started to run together. Accordingly, I stepped away from active persecution of the information and let things stew for a few days. I had recently came back to it, when all of the sudden it hit me - I had what I call a pseudo-epiphany (won't be a legit epiphany until some testing can substantiate my suppositions): Angular rates can be derived mathematically from acceleration pairs, I believe...

Instead of using gyros and accelerometers (gyros being darned expensive), why not use 4ea 3-axis accelerometers (12 axial acceleration sensors), one at each corner of a perfectly square PCB. Axial accelerations would affect sets of accelerometers with same amplitude/vector forces, but pitch/roll/yaw angular rates would result in deltas in the vectors. It seems that the math to separate out axial accelerations vs. angular rates would be do-able, and then the resultant numbers could be ran through some (more?) Kalman filtering to arrive at a smoothed representation of Pitch/Roll/Yaw Accelerations, Angular Rates, etc.

Someone countered me with a good question: "I don't think that permits you to differentiate between simple acceleration and tilt. A rate gyro on an axis eliminates ambiguity, right? How else can you tell the difference? Suppose your square of sensors is moved horizontally; how doesn' t that look like pitch?"

My response is: "All four corners have 3-axis sensors. Moving the board forward only, results in all 4 of the y axis accel sensing the movement, but not the x or z sets of accel. If the unit was pitched up, the fore z axis accel pair will sens upward accel and the aft z axis accel pair will sens downward accel, during the rotational transition. i.e. statically, I understand your supposition, but it is during the actual traversing from horizontal to a pitched attitude that the delta Z acceleration pairs would be indicative of a pitching moment - i.e. angular rates... Angle Rate Sensors output null when not rotating around an axis, correct?

He skeptically indicated that there may be some minor merit to my suggestion, and countered with a concern about the 4 sensors being co-planar and suggested a pyramidal arrangement - equidistant, equiangular... (blows my riser-less-single board approach right out of the water, if his supposition holds any...).

This is the reason that I am writing. A lot of people smarter than I am, when it comes to math, browse the forums. I wanted to throw the jello at the wall to see if any of it would stick. Can someone shoot holes in either of the proposed accelerometer-only arrangements - coplanar vs. pyramidal?

I saw in an earlier post where someone indicated that the real killer for an accelerometer-only solution was that beast called linear accelerations. I dunno if the sheer volume of displaced acceleration sensor axis' would help to alleviate that concern or not. Maybe Orthogonal orientation of the 3 axis acceleration ICs would serve to help alleviate some of the issues with the system being spoofed by linear accelerations, or other issues.

The reason that this came to mind is when I was reading how a MEMS gyro works - mass deflections are corrected and force required to correct is representative of the angular rates (grossly simplified) - it struck me as if it were two accelerometers on a perpendicular axis and the delta in accelerations were representative of angular rates. Low-Power TriAxial Accelerometer IC with Digital Output are becoming more and more prolific. So much so that the price point is sub $14.00 USD from a few of the MEMS IC OEMS. The 4 chips could be procured for the price of a single axis of an ADI Angular Rate Gyro...

Am I treading on thin ice or blazing a new trail here? Seems MUCH TOO SIMPLE to not have been thought of before, but then so were a lot of other things that ultimately worked. Gotta ask or we won't know. Please advise if you have any input.

Thanks.

-t

EDIT: YES!!! There is precedence (http://www.ri.cmu.edu/pub_files/pub4/ang_wei_tech_2003_2/ang_wei_tech_2003_2.pdf)...

OlegZarianski

May 16, 2007, 01:23 AM

Hi,
I trying to reduce noise from accelerometers using Kalman filtering. But I can't realize it, maybe someone help me to write code for it?
The algorithm is the following:

%The midpoint acceleration error in terms of the unknown accelerometer parameters is given by:
dbm=bm*psi+ba+ha*bm+(bm^2)*(FI1-FX1)+db;

ba - (3x1) vector of unknown accelerometer biases, normalized to the magnitude of gravity

ha - (3x3) matrix
|S1 d12 d13|
ha= |0 S2 d23 |
|0 0 S3 |

S1,S2,S3 - unknown accelerometer scale factor errors.

d12,d13,d23 - unknown accelerometer axes nonorthogonalities (misalignments)

db - represents other error terms, some of which are observable; for reason of practicality they are only compensated with factory calibrated values.

FI1 - (3x1) unknown acceleration-squared nonlinearity for acceleration along the accelerometer input axis

FX1 - is a (3x1) unknown acceleration-squared nonlinearity for acceleration normal to accelerometer input axis

bm - is a three vector (b1, b2, b3)' of midpoint components of acceleration in platform coordinates
|b1^2 0 0 |
bm^2= |0 b2^2 0 |
|0 0 b3^2|

%The difference equation for the accelerometers is
Xa(j)=Fa(j,j-1)*Xa(j-1)+Wa(j-1);

Fa(j,j-1)=I;

%The 12x1 accelerometer error state vector Xa is composed of
Xa=[ba S1 d12 S2 d13 d23 S3 (FX1-FI1)]';

%Wa(j)~ N(0,Q) is white noise which includes accelerometer modelling and truncation errors.

%The accelerometer observation is
Za(j)=Ha*Xa(j)+Va(j);

Ha=[b1 b2 b3 b1^2 b1*b2 b1*b3 b2^2 b2*b3 b3^2 (1-b1^2)*b1 (1-b2^2)*b2 (1-b3^2)*b3];

%Va(j)~ N(0,R) is white noise which includes sensor errors.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%EKF applied to obtain accelerometer estimates.%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%State Vector Extrapolation
Xa(j)=Fa(j,j-1)*X(j-1)

%State Vector Update:
Xa(j)=Xa(j)+K(j)*[Z(j)-Ha(j)*X(j)]

%Error Covariance Extrapolation
P(j)=Fa(j,j-1)*P(j-1)*F(j,j-1)'+Q(j)

%Computing the Kalman Gain
K(j)=P(j)*Ha(j)'*[Ha(j)*P(j)*Ha(j)'+R(j)]^-1

%Error Covariance Update
P(j)=[I-K(j)*Ha(j)]*P(j)*[I-K(j)*Ha(j)]'+K(j)R(j)K(j)'

OlegZarianski

May 16, 2007, 01:28 AM

I have made sensors board, and now for debugging connected it through USB port to PC before creating whole autopilot module on on board.

First problem - to filter signal from noisy senors with unknown parameters.
Second problem - create Strapdown INS algorithm (almost done)
Third problem - complex INS and GPS
Forth problem - develop control laws for autopilot module.

Daniel Wee

May 16, 2007, 08:36 AM

I'm joining this thread a little late but this is something I've been thinking about for a long time. My personal goal, initially, is to develop a simple 1D inertial system based on a gyro and at least two accelerometers. The actual hardware I am using is the 5DOF unit from Sparkfun. The lack of a third DOF means that the unit will not be able to track yaw.

On the issue of filtering, I think you're better off using an active low-pass filter at about double your sampling rate. You can easily implement this using some of the quad-opamp packages available. This will take the computational load off your processing unit and keep things a lot simpler. The software will only have to deal with the Kalman algorithm and the integrator.

My big unknown at this point, is if we base the unit purely on gyros and accelerometer, how would the long term stability be? Is it mandatory to have some absolute data to correct for drift? (be it GPS, magnetometer, etc.) To put it in another way, can the Kalman filter average the accelerometer inputs over time to yield an average vector that corresponds to true gravitational vector and thus allow the strapdown to occur with just the gyros and the accelerometer?

The most difficult part of this problem is not the other parts of the IMU such as GPS, speed, altitude, pressure - those are fairly straightforward. It's the attitude stuff that is the hardest, and in some ways crucial. As such it is my hope that some of you braniacs will be able to come up with a standalone prototypical solution for attitude based only on gyros and accelerometers.

The problem is mainly with the (rate) gyro drift, which gets compounded by the integrator (which yields angular shift). An uncorrected gyro will be unusable in the order of seconds or tens of seconds. My question, can the accelerometer, making some reasonable assumptions, correct for that drift? Just a proof of concept project will be a great door opener for many other projects to follow.

The Autopilot project on sourceforge actually has a code for this but I don't know anyone who has tested it and is able to give us the test results. Apparently that project uses an extended Kalman filter but the code cheats and is not completely optimal. Basically this is as far as I can get. Hopefully some of you can go alot further than this.

Daniel Wee

Daniel Wee

May 16, 2007, 08:46 AM

Wullfy, I have read of a university project that attempted to implement the cubic configuration of accelerometers that you are suggesting and the results, if I recall correctly, was that the system itself drifted 10 times worse than a comparable gyro based system. So in other words, it will work but it won't work better than a gyro based solution, which basically puts us back at square one.

Daniel

Wulffy

May 16, 2007, 06:48 PM

I understand the concern. However, I have been doing a lot of reading on KF, EKF, UKF, SRUKF, and other filtering algorithms. I am of the belief that the newer filtering - specifically SRUKF or Double Exponential Smoothing may be able to address some of the divergent tendancies with the more traditional implementations of the Predictive Machine State Filtering and Smoothing algorithims. I have attached a number of papers that I have collected specific to the subject matter, as the filters seem to be the most intensive element in getting a hardware solution to perform. Maybe someone smarter than I can comment on them.?.

-t

OlegZarianski

May 17, 2007, 03:52 AM

I planned to use this filter algorithm, as I do not know accelerometer parameters, as bias, drift, axis nonorthogonalities, scale factors and so on.
And this algorithm as I understand 'cut' the noise from the signal.

savuporo

May 21, 2007, 07:35 AM

how much MIPS are we talking about here ? from the gut estimate i think an ARM9+DSP ( something like a Blackfin ) would run this as a breeze.

i think one mistake that people tend to make is to feed the sensor signals into IMU calculations directly, without prefiltering and signal conditioning.

You really have to run some lowpass or median filters with these MEMS units on them, before making use of the data, and only after that feed that signal further into Kalman filter.

Also, a few robotics guys have found that a hand-tuned loop may work better than a Kalman filter for integrating gyro and other sensor readings, look up "gyrodometry" on google. It could get complicated in 3 dimensions however.

One more thing. IIRC these sensors are highly temperature-sensitive, and pretty much need a temperature correction on signals. This would involve first measuring the signals in open-loop recording application with external position and temperature measurement, and from the recorded data figuring out the appropriate correction factors.

just my few cents of input. im hoping to start working on similar stuff once my backlog of TODO tasks is shorter than a few meters again.

EDIT: oh, another thing. dont try to do filtering and signal processing on analog inputs. Processing power is cheap, and in analog elements the data gets lost. with digital filtering even if you discard some of the data while using it for one purpose ( i.e. lowpass filtering the gyro reading to feed it into Kalman ) the same discarded data might be simultaneously useful for another purpose ( you may be able to infer the "reliability" of signal or amount of vibrations from the high peaks you are filtering off for example, and use this to switch to backup landing method or safe abort or something )

in other words, every bit of data that you can get from these relatively low-res sensors is valuable, discard them only when 100% that you should.

Unterhausen

May 21, 2007, 01:04 PM

Also, a few robotics guys have found that a hand-tuned loop may work better than a Kalman filter for integrating gyro and other sensor readings, look up "gyrodometry" on google. It could get complicated in 3 dimensions however.

I don't think that gyrodometry is going to work for an airplane. In the paper I read, they are just relying on odometry for most of their odometry. If there is a big jump in the gyro reading, they use that.

savuporo

May 21, 2007, 05:59 PM

right, thats what i said, it could get complicated with larger array of sensors and 3 dimensions. however, my point was that in some cases hand-tuned sensor loops may prove better results, because it may be difficult to incorporate all the error factors properly into a single complex filter. Thats why i am also suggesting separate digital prefiltering and conditioning on sensor signals.

Tom Harper

Jul 07, 2007, 04:50 PM

Magnus, Unterhausen,

What's happening with this project? Any progress?

I am interested in using solid state accelerometers to sense the response of the model to control movement, to limit the rate of response in order to make the model response predictable during navigation. Does that take Kalman filters and all of the above or can it be treated simply as an input to a feedback loop?

Tom

Jack Crossfire

Jul 08, 2007, 03:04 PM

The main problem is differentiating translation movement from rotation movement. In a low vibration environment, it may not be a problem, but in a high vibration environment you have to use lowpass filtering. Finding integrating lowpass filtered, IDG300 gyros produces enourmous drift even during a single turn. The accelerometers aren't much help either. They don't detect tilt after the rotation because the perceived g force during a coordinated turn is straight down.

The trick is to use gyro data when you know the gyro data is good and use acclerometer data when you know the accelerometer data is good. That may be during the turn, shortly after the turn, or long after the turn, but no-one on the internet has real data showing which one.

What's really needed for the high vibration environment is a MEMS gyro that detects absolute rotation and we suspect such things will exist soon.

skogsvargen

Jul 09, 2007, 04:00 AM

Tom,
My INU-project is not moving (at least I don't sens any movement :) ). I have come to the conclusion that it is over my head to do the programming. I want to spend more time flying ant testing things and less time at my workbench.

I think the FMA-Copilot is good enough for me and i might try to integrate that sensor to my own autopilot board in the future. My plan at the moment it to use the Copilot, preasure sensors for ALT ans IAS and GPS for Navigation. Since i want to use ailerons to turn the aircraft i am i might try to put the Copilot on a servo-platform and let the AP tilt it to achieve roll and pitch changes.

This is the ugly way to integrate the Copilot with the AP. Off cource I should tap into the cable between the Copilot sensor and the control module and introduce a small offset to the signals to initiate turns... Hm... I think i will look into that.

/Magnus

trappy

Jul 09, 2007, 02:59 PM

just wanted to let you guys know that the guy at www.poor-robot.com is working on a IMU. I've talked to him on and off for a couple of times and he estimated a working prototype end of july 2007 (in other words: pretty soon). let's hope for the best ;)

Edit: in my hurry I forgot some of the specifics... here we go

hardware:
* 3 axis gyro
* 3 axis accel
* 3 axis magnetometer

adc, "software filtering"

Pricing is expected to be "$380 - I'm being conservative on the high side with my estimates"

Tom Harper

Jul 09, 2007, 07:11 PM

Jack,

Thanks for the clarification. Sounds reasonable.

Tom

mwhazard

Jul 10, 2007, 01:35 AM

--Drop the gyros
An approach I've read about (and since lost the link to) uses a simpler set of sensors to estimate the aircraft's attitude. It uses a GPS and a three-axis accelerometer triad. Any GPS can deliver the position of a vehicle. Most GPS units can also give velocity information, measured separately using doppler phase measurements. It is simple to differentiate velocity to get the *inertial-frame* accelerations, that is, the actual dynamic accelerations of the body measured relative to the earth. The accelerometers measure these accelerations, but also measure the force due to gravity. Simple vector math can be used to sum the earth frame accelerations (specific forces) and the gravity vector (9.8m/s^2 down) to get the sensor value the accelerometers would read if they were oriented exactly in the direction of flight and level with the ground. Of course, the actual accelerometer readings are rotated due to the pitch and roll of the airplane. Calculating the angles between the two vectors gives you an estimate of the pitch and roll of the airplane that may be sufficient for basic control and navigation functions. For a hobbyist-level autopilot in a conventional airframe (read - NO 12" zagis or helicopters) it may be a great starting point.

--Advantage over conventional IMU solutions
They interesting feature of this approach is that by differentiating GPS velocity to synthesize attitude, it precludes the primary source of error in most INS systems - the integrated rate gyros. The errors typical of MEMS accelerometers can be easily compensated since they generally aren't subject to drift. And a simple lowpass filter may suffice in place of a more complicated Unscented Kalman Filter. With fewer floating point calculations, all the processing could reasonably be done on a Atmega128 using integer math or even better on a Gumstix running full Linux. Plus the whole system is cheaper since you don't need to buy the gyros in the first place.

--Improving the system
From a controls standpoint, the gyros are useful (as some others have mentioned) to stabilize the aircraft at a relatively high bandwith. Most gyros can sample > 200 Hz as opposed to a 4 or 10 Hz gps, making them extremely useful from a stabilization standpoint e.g., for wing leveling. But it may make sense to separate them from the navigation unit. Other sensors could be added to complete the system as necessary. Pressure altitude and airspeed sensors let you maintain better flight control (and not stall) and estimate wind direction. A magnetometer could improve heading calculations (the gyro free attitude method cannot calculate heading since it is a rotation *about* the gravity vector, ) otherwise you have to settle for GPS heading.

There's tons of stuff in controls literature on this topic. A search for gyro-free INS will get you many results on systems that use magnetometers and accelerometers to work around the basic issues with cheap gyros. Also try this link http://lrcs-srv3.lr.tudelft.nl/docs/mscthesis/233.pdf for tons of information about navigation using only a GPS. While not quite the same, its a good starting point. If you can find any of Richard Kornfeld's papers from MIT, definitely check those out as well.

Hope this helps,

Matt Hazard - Senior, NC State Aerospace Engineering

O.L. Adcock

Jul 10, 2007, 12:02 PM

I'm no rocket scientist but I've been following this thread with interest. My question is with GPS giving us position data, why do we need an IMU or INS?? Playing with full size IMU's they seem to be only a good back up to the GPS. We need attitude reference but don't need a stand alone IMU/S to do it. Matt, I agree with you, at least the parts I can understand! :)....O.L.

mwhazard

Jul 10, 2007, 03:10 PM

Although you can synthesize a kind of pseudo-attitude using GPS alone, I think combining it with an accelerometer and magnetometer suite would make for a more robust system.

Many commercial autopilots use GPS for navigation and the IMU sensors mainly for stabilization. As far as I can tell, the basic Piccolo fixed wing controller (as of 1.3.2) banks the airplane to maintain a desired turn rate. Turn rate can be calculated using GPS velocity measurements alone. But the additional sensors let you impose important sanity checks on maximum pitch/roll and damp any high-frequency motion the gps can't detect at 4 or 10 Hz. Extremely simple systems can be made using a GPS and a simple thermopile array e.g, FMA Copilot. Look into the Paparazzi project (which has matured a lot since this thread started) for more info.

Matt

mwhazard

Jul 10, 2007, 03:19 PM

If that wasn't clear, you should definitely be able to create a simple autopilot that can fly an airplane with GPS alone, provided the airplane has sufficient natural damping characteristics. That's why you see people building camera-computer-gps systems inside Senior Telemasters and other trainers.

If you want to get faster/more sophisticated state estimation than a gps will provide, you'll need to add the higher bandwidth sensors and start doing Kalman filtering.

clolson

Jul 10, 2007, 04:29 PM

I'll weigh in with a couple comments here.

I question how well an open-source hardware project could work.

The beauty of open-source *software* (and in my opinion, the key reason why it works so well) is that there is essentially zero cost to replicate and distribute the product. (Ok, for the nit pickers, there is a cost, but this is almost always absorbed into other things so you don't see it ... i.e. hosted on a university server that is already net connected, downloaded to your computer but you already are paying for a net connection anyway, etc. etc.)

Free replication and distribution just isn't possible with hardware. An open-source "design" might be interesting, but assembling components to the tolerances required by an IMU is time consuming and requires some special skills beyond soldering a couple wires together. I wonder how many folks out there in reality would have the skills and time to put together an IMU "kit"? Maybe I'd be surprised, but I'd guess there wouldn't be too many people that could actually pull it off and make it work at the end of the day ... (?)

If you add up all the time and cost it would take to develop and assemble something basic yourself, (charge some minimal amount per hour for your own time), even if it was just assembling an already designed kit, then I suspect something like a $1500 MNAV wouldn't seem nearly as expensive as it does at first glance.

In my view, there's no getting around the fact that getting a good quality sensor suite on your desk is going to be somewhat costly, either in $$$ or in time, probably both.

What I would love to see is more effort put into developing high quality open-source attitude/location estimation code that would run on top of various available hardware. I think that is where the power of open-source could provide a real benefit. Imagine something that is at least as powerful/capable as a micropilot or kestral or picolo. Maybe you have to pay $2k for the hardware, but the software would be completely open source. You can get in there and modify it, examine it, extend the code, adapt it to some other purpose, whatever you want to do.

Most likely there would be just as many people out there wanting this sort of system as there are who can build their own IMU, but in my mind, this seems like a good way to minimize cost so you are only paying for raw hardware, but still have the functionality of a full 6 degree of freedom location/position estimate, the ability to control 8-9 servo channels, the ability to impliment simple proportional control systems, full PID based systems, or even modern fly-by-wire style systems.

But at the same time, there are an awful lot of people getting a lot of mileage out of a co-pilot for stabalization and some simple bit of electronics that will steer your rudder to follow handheld gps routes. You can fly a long way for pretty cheap if you can make that sort of system work for your needs. I am amazed at the variety of solutions that people are using to accomplish autonomous flight, seems like everyone here is coming at this from a slightly different perspective, different budget point, different end goals ... so clearly there isn't one size that fits all.

Curt

trappy

Jul 10, 2007, 05:03 PM

curt, I agree with you fully. however, if you look at the manufacturing cost for IMUs (MNAV, for example), the margins are simply too big. As I said earlier, I found zac wheeler (www.poor-robot.com) who is currently building a 6DOF IMU, which is interfacable with the gumstix. Cost for this system was said to be around $400. Add a GPStix ontop of that and you've got everything the mnav does and more, for less than $1000.

I'm not saying MNAV isn't worth the money, I just think that there are few people out there willing to lay down $1500 for a "electronic component" that comes with crappy software.

I agree with you, however, that there is more opportunity in opensourcing the autopilot software itself (by the way, how is you project coming along? :) )

mwhazard

Jul 10, 2007, 06:11 PM

Code that runs on Atmel microcontrollers will be written differently than code for a Gumstix or an ARM with floating point support. That's part of the reason open source hardware is essential - it gives developers a common ground to test with. An autopilot software project will be severely challenged if each developer is attempting to use a different sensor/processor set, since each set will present its own challenges.

Matt

Jack Crossfire

Jul 11, 2007, 01:55 PM

U need a hardware standard base to do any realistic open source IMU. A standard base is easy in software because it's free. Just make everyone download the same Linux derivative. It's a little harder to make everyone download the same gyro derivative. Invensense is supposed 2 have a 3 axis gyro in a few months. Good luck making everyone standardize on IDG300's.

The autopilot.sourceforge.net code is worthless #1 because the electrical characteristics of 2002 are totally different than what today's parts generate. The IDG300 is probably the noisiest of the noisiest and that may explain the instability in Hudson's Kalman filter.

sergey123

Jul 11, 2007, 02:21 PM

It looks like paparazzi is the best open-source UAV project for now:http://www.recherche.enac.fr/paparazzi/wiki/index.php/Main_Page

Hopefully they will have IMU PCB boards soon: http://www.rctechnix.com/index.php?cPath=21

Bulma

Jul 12, 2007, 04:04 PM

Somehow I am getting the feeling that what you are trying to build (fast attitude estimator) is impossible. As someone pointed out accelerometers are more or less useless in planes because you can't make a distinction if you are getting acceleration from turning or current attitude (gravity). Magnetometers are problematic in that they are pretty noisy and won't give you correct attitude in some directions. And as we all know, gyros are drifting as hell, and they need correction. GPS are also more or less useless because they can lose a lock a give totally garbaged values here are there. As result, you'll have to rely mosty on gyros, and pray to god that magnetometer will give you correct data to compensate for drift. In my opinion, that is gambling, and whatever "magic" you use, Kalman filter or not, it will work sometimes, but it will not work always, probably causing a crash here and there. This all reminds me on using sonars on mobile robots for map based positioning, there was a lot of research, but common conclusion was that sonars are crap for that purpose, and that you have to use laser scanners if you want any serious map based navigation.

OlegZarianski

Jul 13, 2007, 02:19 AM

I am trying to use Klaman Filter for increasing quality of the signals from 3 Gyros and 3-axis accelerometer, when signal from GPS disappear.
In that case, signal quality will be much better, if simply lowpass filtering.
But I want to you digital low pass filter in the output from the ADC, and then after low pass filtering want to send them to the Kalman filter.
Logic will be the following:
If Signal from GPS fixed, then using Kalman filter for GPS/INS integration.
If signal disappear, then Kalman filter use different algorithm, to increase signal quality.
INS/GPS Integration works fine. But IMU Kalman filter I can't write code yet :(((

Bulma

Jul 13, 2007, 07:49 AM

If signal disappear, then Kalman filter use different algorithm, to increase signal quality.

So you will be using gyros/accelerometers as INS (with both attitude and position)?
How are planning to use Kalman filter in that case? By estimating gyros/accelerometers errors (bias, gain, etc...) or by using uav dynamic model with control inputs? Both? Something else?

Unterhausen

Jul 13, 2007, 09:57 AM

Jack Crossfire

Jul 13, 2007, 01:35 PM

Had pretty good results blending gyro integrals with instantaneous accelerometer angles and no Kalman filter. The trick is to blend just enough accel component to keep the gyro integrals from drifting. 0.005 accel parts for every 0.995 gyro parts for the IDG300 & ADXL330. Not bad considering how noisy this gyro is and the response is faster than a Kalman filter. The IDG300 is up 10% since last year, so it's probably not the best deal anymore.

O.L. Adcock

Jul 13, 2007, 02:37 PM

Bulma, You bring up some good points. I'm not a "designer" by any means but
I've had to try to survive with what "designers" have built. I'll throw out
some thoughts, take them for what they are worth...I'm having trouble
crossing terminology from military terms used years ago to that being used
today. Please correct me if I'm wrong but "IMU" is/was a device intended to
provide velocity vectors that could be used in a navigation computer to
determine present position, ground track, speed, all the things needed for
navigation, without external sensors or input. An IMU combined with a
navigation computer becomes a INS. One of the off shoots of this is data
that can be used for attitude reference. To the best of my knowledge IMU's
have been and will continue to be "drifty" and somewhat unreliable without
regular/accurate external updates, just due to the complexity of the beast
and limitations of the components. Lowering costs and making parts smaller
will further complicate matters.

I've never played with RPV's or UAV's other then the ones that have a hair
covered computer sitting in the cockpit or standing on the ground with a
transmitter. "Navigation" now days with GPS is a moot issue because of it's
reliability and losing nav data for a few seconds or a few minuets for that
matter is not a life or airframe threatening situation as long as you have
enough altitude. Attitude reference however is.

In small, close range, inexpensive UAV's, or very stable airframes, maybe
running the risk of losing attitude reference isn't a big concern but as the
risks/costs go up, reliable attitude reference has to be priority number 1.

Single source attitude reference is a problem. There are so many sources
where a single point failure may cause the loss of the airframe with some
being more critical then others. Attitude reference is one of them. Some
would say adding a second redundant source is the answer, it's not...When
those wheels leave the ground, it's pitch black with no horizon, and all of
a sudden both attitude references systems disagree with each other. Which
one do you believe?? It comes down to a flip of a coin. The right choice and
the airframe goes on it's merry way, the wrong choice and it goes splat or
exceeds Vne.

I'd like to see a reasonably priced IMU available but what I'd rather see is
an autopilot board that will accept 3 attitude reference inputs with logic
comparison that will use a primary attitude input but monitor the other 2.
If any 1 of the 3 disagrees with the other 2 the oddball will be locked out.
Variation tolerances could be built in depending on the usable/normal
accuracy range of the devices. Ideally the 3 attitude reference devices
would be different architecture so if a flight condition causes an
inaccuracy or failure in one, odds are it won't effect the other 2. The
"third" could be the pilot/operator if he can monitor the other 2 real time
and select between them based on video or visual reference with the horizon.

Does an autopilot board exist that would give us these functions??....O.L.