PDA

View Full Version : Discussion Reasonable min features for IMU autopilots?


dmgoedde
Jun 18, 2009, 03:50 AM
Let's say consumers want to see low priced IMU autopilots enter the market, as in << the $3 to $8k we are used to seeing. The potential low priced unit might be with reduced feature sets and be suitable for simple jobs.

please pick your personal single top choice from the list below and tell me which of the following features you feel are "must have" for a bare-bone 6 DOF IMU autopilot. Which feature, if missing, would make you think "what's the point of buying if I can't have X?"

* Airspeed sensing and throttle control
* Payload control (my personal pick)
* Onboard data logging
* 3D waypoints (but would have hard-coded 400' AGL limit that user can't override) (My 2nd pick)
* More waypoints (like 100) but hard-coded distance from home limit like 1km (ala Tom Harper's recent suggestion) or similar
* Failsafes (power sensing, or user-defined from analog sensors) (My other 2nd pick)
* Higly simplified setup and operation
* Short range modems included
* Auto takeoff or landing (simple like a deep stall)

The upcoming Atto-IMU is full feature, however for purposes of this discussion I am trying to feel out for a potential 2nd IMU product what people want and need as the lowest level feature set, but stripped down in order to be priced close to $1000 retail. In other words, to get a roust $1000 6 DOF IMU autopilot what are you willing to give up and why?

BeefStake
Jun 18, 2009, 05:07 AM
I think the 1km hard limit is a little silly.
It could appeal to universities and other small eduational institutions if you only gave up on hardware features and left the software fully functioning.
In the end software isn't what sets the price of the mass produced unit.
I would think you would need these features:

* 3 axis gyro
* 3 axis accelerometer
* Differential pressure sensor & barometer
* Digital compass (single axis magnetometer)
* GPS... I would think 4 or 5hz is cheap enough these days
* RC inputs with a multiplexer for full manual control
* 8 PWM outputs - dont cost much you could do 12 cheaply
* UART serial interface for standard communications
* MiniSD or other storage card for logging
* GPIO pins for general purpose payload use etc

I think that covers it for hardware.
Software like I said is hardware independent and not really what determines the price of the unit.

brakar
Jun 18, 2009, 08:32 AM
If the two autopilots are fysical identical and the difference between the two is only due to different software, I am not shure if it this kind of diversification is the best idea. Why, is that two software versions would also mean more work for you - support, manuals etc.

What about including more support / service in the pro market? They are likely to be more demanding customers.

By the way, any news on the export process for the termopile version?

boyisabird
Jun 18, 2009, 11:39 AM
I would vote most highly for ACCURATE 3D waypoints, but w/o the ceiling limit (just as there is not a max speed on cars...)

All the other things are great, esp payload control.

When do you think the IMU version will hit the streets (ballpark?). Is there a beta?

Jack Crossfire
Jun 18, 2009, 01:16 PM
Indoor VTOL with automatic camera blocking & image composition.

dmgoedde
Jun 18, 2009, 01:51 PM
I think the 1km hard limit is a little silly.
It could appeal to universities and other small eduational institutions if you only gave up on hardware features and left the software fully functioning.
In the end software isn't what sets the price of the mass produced unit.
I would think you would need these features:

* 3 axis gyro
* 3 axis accelerometer
* Differential pressure sensor & barometer
* Digital compass (single axis magnetometer)
* GPS... I would think 4 or 5hz is cheap enough these days
* RC inputs with a multiplexer for full manual control
* 8 PWM outputs - dont cost much you could do 12 cheaply
* UART serial interface for standard communications
* MiniSD or other storage card for logging
* GPIO pins for general purpose payload use etc

I think that covers it for hardware.
Software like I said is hardware independent and not really what determines the price of the unit.Let me clarify - the fully functional IMU-Atto I have been flying for a while (and am getting ready to send to 3 or 4 betas next week) already has all that stuff you list, sans the digital compass. It is a fully developed and featured system. The proposed cheap cheap cheap version would be different from a hardware standpoint: sure it will navigate and stabilize any fixed wing plane, but what minimum feature set would get the job done for people on the most limited budget? I heard several request in e-mails and phone conversations asking if I would break the $1000 barrier in the IMU Atto... which would only work if it was the simplest possible unit from a hradware and software standpoint.

I was not asking "what feature set should be in a general purpose IMU autopilot" and then have people list off everything they would want.. then we are getting back up in price, when for some simple close-in missions the simplest possible unit would do for some people.

Basic 2D navigation and stabilization are a MUST, but most everything else is not a "must have" necessarily. For example, sample-and-hold altitude kind of sucks, but could get the job done. No trigger from the autopilot is pretty shoddy, but could be circumvented by RC control of that channel. No airspeed sensor and no throttle control is pretty weird, but could be achieved by locking throttle where you last left it (like was used in the early beta Atto v1.8 units).

Lowest cost = simple embedded code and having a lot less components on board. If the airspeed sensor and SD card are left off, and less Rx and servos (down to the min required... pitch and roll servos) then we are getting to a very tiny unit that is easier to make and support. In fact the setup by end-user would detail just 4 parameters:
1) pitch control direction (norm or reverse)
2) roll control direction (norm or reverse)
3) Pitch gain response
4) Roll gain response

Compare what I am saying against the new U3550 autopilot, which is listed for $1500: it is almost nothing more than a Pico-NA but adds 5 DOF sensors to have an IMU. It only does sample and hold altitude, no airspeed, no throttle control (you plug it into the RC Rx), no trigger control, and just 32 waypoints that are only 2D. OK, it includes the Xbee modems, which retail for around $30 each.

My reactions were twofold:
1) Whoa! They stripped out ALL the features... that is barely an autopilot.
2) Hey wait a sec... are people actually going to buy that thing?

If #2 is correct, then I can also make a highly denuded IMU autopilot and beat $1500. If there is market interest then I will do it. The full-feature 6 DOF is of course my main concern, but to make a $1000-$1500 uber simple autopilot would take about 2 hours of PCB layout design time, and recycling code I already have. Testing would be awfully fast.

>>> I never thought anyone would make a commercial product so completely stripped of functionality just to hit a semi-low price target, that's all <<<

brakar
Jun 18, 2009, 03:50 PM
It seems I have a nasty habit of looking at things in different ways then most people, and by that caucing anoyance. Usually not by intention.

Well, I probably would have started to look at what customers I would want to sell the different autopilots to/ "the market", and then focus on the characteristics of each group of customers/ "segment" of the market, price, software (GS, wp-checking software, software for tuning of set-up files, etc), used design standards/ proof of design / proof of reliability / proven in use, anticipated service level/ tlf. support time, etc. would then be the first issues to address - secondly, specify the technical features of the autopilot.

To try to decrease the annoyance-level, I shall quick-jump to some possible results based on this approach right away. First, to some extent the market probably isn't there (yet), so you might have to define it - or guess at what it might look like if you started to provide a variety of autopilots:

1. Kids -> no, would be irresponsible. . .
2. Adult AMA RC-flyers -> lots of money? techniclly interested? what would they want to do with an autopilot? simple and easy to use, not pricy?
3. Enthusiast aerial photographers -> yes, existing market-segment ->
a) close to base, matrix pattern flying aerial photographers ->not in need of highly asophisticated autopilot? pay out of their own pocket,
b) inspection of distant sites-> advanced features needed, video streaming, pricy, ...
4. Pro market aerial photographers -> exiisting market, main focus on reliability, ease of use, service, price not really the biggest question - man-houres spent is what is most costly,
..
..
Army

Irv
Jun 18, 2009, 04:17 PM
Dean,

This may be a bit "off the top" but what about a basic IMU stable platform that could be used for flight stabilization of aerobatic aircraft, helicopters, tri or quad copters, etc.

Other functionality such as onboard data logging, altitude sensing and control, airspeed sensing and control, gps could all be extra cost add ons.

ios
Jun 18, 2009, 06:28 PM
Don’t get distracted with what u-nav is doing. We all know they have an inferior product.

- Attopilot v1.8 is already ideal for the entry-level/hobby/amateur market, and full featured to boot. (and given the features of Attopilot, still priced to beat the U3550)
- IMU Attopilot is ideal for the high end amateur and Pro market.

I don't think you should compromise on any features. Once you have both of these Attopilots in the market, attack the helicopter and payloads market.

TastyWheat
Jun 18, 2009, 10:10 PM
I don't think including modems or auto takeoff/landing would be critical, and I imagine these 2 options would cost the most to implement.

The rest appear to be mostly software restrictions (from my admittedly ignorant perspective). If they were done just to differentiate it from your more expensive IMU autopilot (i.e. just turned off in code), I'd personally be a bit disappointed, and less likely to choose it over Attopilot v1.8.

I'd understand if they were limited to get around export restrictions though, I eagerly await the day Attopilot is available in Australia :)

OGM94
Jun 19, 2009, 03:37 PM
Dean please call me on my cell phone.
Bill
Royal Hobbies :)

dmgoedde
Jun 19, 2009, 07:12 PM
I don't think including modems or auto takeoff/landing would be critical, and I imagine these 2 options would cost the most to implement.

The rest appear to be mostly software restrictions (from my admittedly ignorant perspective). If they were done just to differentiate it from your more expensive IMU autopilot (i.e. just turned off in code), I'd personally be a bit disappointed, and less likely to choose it over Attopilot v1.8.

I'd understand if they were limited to get around export restrictions though, I eagerly await the day Attopilot is available in Australia :)ECCN 9A012. Wrapping up final stuff. Bill (who probably wants to wring my neck) wants me to call, him so I will. Bill is part of the Export stuff. Will probably tell me to 'quiet down' on RCGroups, and he is right of course.

Ios: I would never dilute what I have. Even just the current IMU unit I am beta testing will be a FIERCE competition force, and guess what? What: I don't have the overhead of several $80k+/year engineers on my staff like some of the other small autopilot companies. I can't help but beat them on price. My costs are comparatively low. So the no-compromise IMU Atto will 'have it all' except dead reckoning and magnetometers. I was considering recycling code and excluding hardware in order to go head-to-head with U-know who Nav on their 3550... somewhat baffled that there could even be a market for something with no features except IMU and moving map/re-tasking.

ios
Jun 19, 2009, 07:36 PM
U-who !?

;) :p :D :rolleyes:

airmcn_3
Jun 20, 2009, 12:16 AM
U-who !?

;) :p :D :rolleyes:

Hey isn’t that a drink in the USA.......... :D

Oh ya and are these features considered reasonable?????

Autopilot that will circle the earth with an error no more then 2% from start to finish. Rain, sleet, snow or shine?? Oh ya and I want to take a picture every 4ft.

How about having it pre-program its own missions so that we will not have to.

Oh ya and last but not least can it have a flux capacitor??????

BeefStake
Jun 20, 2009, 01:56 AM
Let me clarify - the fully functional IMU-Atto I have been flying for a while (and am getting ready to send to 3 or 4 betas next week) already has all that stuff you list, sans the digital compass. It is a fully developed and featured system. The proposed cheap cheap cheap version would be different from a hardware standpoint: sure it will navigate and stabilize any fixed wing plane, but what minimum feature set would get the job done for people on the most limited budget? I heard several request in e-mails and phone conversations asking if I would break the $1000 barrier in the IMU Atto... which would only work if it was the simplest possible unit from a hradware and software standpoint.

I was not asking "what feature set should be in a general purpose IMU autopilot" and then have people list off everything they would want.. then we are getting back up in price, when for some simple close-in missions the simplest possible unit would do for some people.

Basic 2D navigation and stabilization are a MUST, but most everything else is not a "must have" necessarily. For example, sample-and-hold altitude kind of sucks, but could get the job done. No trigger from the autopilot is pretty shoddy, but could be circumvented by RC control of that channel. No airspeed sensor and no throttle control is pretty weird, but could be achieved by locking throttle where you last left it (like was used in the early beta Atto v1.8 units).

Lowest cost = simple embedded code and having a lot less components on board. If the airspeed sensor and SD card are left off, and less Rx and servos (down to the min required... pitch and roll servos) then we are getting to a very tiny unit that is easier to make and support. In fact the setup by end-user would detail just 4 parameters:
1) pitch control direction (norm or reverse)
2) roll control direction (norm or reverse)
3) Pitch gain response
4) Roll gain response

Compare what I am saying against the new U3550 autopilot, which is listed for $1500: it is almost nothing more than a Pico-NA but adds 5 DOF sensors to have an IMU. It only does sample and hold altitude, no airspeed, no throttle control (you plug it into the RC Rx), no trigger control, and just 32 waypoints that are only 2D. OK, it includes the Xbee modems, which retail for around $30 each.

My reactions were twofold:
1) Whoa! They stripped out ALL the features... that is barely an autopilot.
2) Hey wait a sec... are people actually going to buy that thing?

If #2 is correct, then I can also make a highly denuded IMU autopilot and beat $1500. If there is market interest then I will do it. The full-feature 6 DOF is of course my main concern, but to make a $1000-$1500 uber simple autopilot would take about 2 hours of PCB layout design time, and recycling code I already have. Testing would be awfully fast.

>>> I never thought anyone would make a commercial product so completely stripped of functionality just to hit a semi-low price target, that's all <<<

Hmm. I think I could put together that featureset sub $1000.
True I would not be including development or software costs but it could be done. Sensors have come down in price alot these days, specifically gyros and accelerometers with the advent of them being in nearly every embedded consumer device these days. I suppose it comes down to whether or not an autopilot would be commercially viable..
That really comes down to how you want to do things I suppose.
Considering you already have a control system written I would imagine such things as a Kalman filter etc have already been implemented. In this case then moving the codebase to a new platform could be rather simple especially if you kept your current architecture and kept things as similar as possible then yes as you say it would be ready with minimum testing and issues of course development costs.
I would like to see a product like this, obviously it won't benifit me because of the whole lets not export APs from the US thing but yeah.
It can be done and I would like to see someone do it.

brakar
Jun 23, 2009, 04:01 AM
I just had a look at the UNAV3500 at http://www.u-nav.com/3550.html

My first impression was pretty similar to what Dean described:
Originally Posted by dmgoedde
1) Whoa! They stripped out ALL the features... that is barely an autopilot.
2) Hey wait a sec... are people actually going to buy that thing?

After have given the subject some more thought, I think the product is close to genious. Why? Based on how the product is presented it looks like this autopilot is:
- the most plug and play ready autopilot ever seen, completly preassembled, and sealed up,
- the easyest autopilot to program and use,
- aparantly built in accordance with the proposed FAA regulations, standards and based on years of experience.

Who would want to buy such a product? My guess is people/companies that has some sort of specific and basic aerial photographying they want to carry out, and whith little general interest in autopilots or aerial photographying. If this autopilot can get the work done, it's probably also the product you could convince your boss to fund.

Secondly, it is cynical but reasonable to assume that companies who buy and succeds with this bare-bone autopilot, soon will want to buy a full-feature one. This way UNAV could sell two autopilots, using the first one as bait.

Who would not buy this product? well, besides myself, probably most of the people active at this forum.

To me it seems a pitty that UNAV with this product not only cutted the features to the bone, but also half way cutted away the bone itself.

So Dean, bring on something like this, but with 3D waypoints, trottle control, and whitout any sort of unneccessary software restrictions!

brakar

brakar
Jun 23, 2009, 06:25 PM
Ok, I take the silence as a proof that everybody agree with my previous post... brakar :D

Unfortunately (from a consumers point of view), the stripping down of features in the low-end UNAV3550 was possibly regarded as neccessary for UNAV - from a commercial point of view. If not, the low end product might end up beeing their owns top-end products worst competitor. This is based on an assumption that they have a relatively high profit margin on their high end autopilots and little or no profit on the low-end one. I think this is how suppliers of technical equipment often price-differentiate their products.

On the other hand, for a new business, a different but also viable strategy might be to put a more or less flat rate profit margin on all products. Might lead to some interesting results in the supplying end of the market too.

dmgoedde
Jun 25, 2009, 03:46 PM
I don't know about the large profit margin thing you wrote. Now that I am fully immersed in this and gearing up to sell a competing IMU autopilot, profit margins get eaten quickly by liability insurance, sales and marketing, customer support, hiring people to do things, having GCS written, etc... After all these expenses, you still need to turn a profit and base the markup on expected sales volume. Hobby people sit down and add up the cost of components and come up with a sum of a few hundred $, then think autopilot companies are raping the consumer by charging $3-6k for small 6 and 9 DOF autopilots. The hobbyist might develop a great autopilot, but they don't consider how much of their time it took to get there... they just had fun doing it.

I see the U3550 strategy as being this:
1) make it VERY simple. Less need for customer support.
2) take out triggers, require RC Tx to control throttle, and require link to the ground station or else a fail safe causes RTL.
3) Hard-wire a short range modem to it (the Xbee) and with required GCS link, you have prevented ability for this to be used as a fire-and-forget weaponized system to be sent to a target 10 km away.

I still think that at $1500 their profit margin is not large at all, even if the components to make one add up to say only $300, and they used a lot of recycled code from the U3500.

Nonetheless, I still wonder what the point of using an autopilot is, if it has to be stripped down this far to meet suppposedly upcoming FAA regulations. It hits 32 waypoints at constant altitude and no triggers to do stuff. Pitch and roll control + simple navigation and that is it. Nothing more and nothing less. What's the point anymore?

Jack Crossfire
Jun 25, 2009, 04:24 PM
The cost of developing anything in U. Know. Where. is so high compared to the value of a durable good that you can't really make any money producing anything. If you invest $100,000 & break even, you could have done better in a savings account (lending it out). The cost of production is determined by the availability of credit & not the value of any product.

How can an economy function if nothing produced can recover the cost of production? It doesn't produce anything. It survives by borrowing money & producing less than it borrows.

Dave Perry probably doesn't make money on autopilots. Like most Washingtonahans, he uses his work to qualify for loans & borrows 10x his income for food & shelter. The only way to make money is to get a government contract where the customer (the taxpayer) can't say no, use someone else's money, or refinance under TALF.

Mecha
Jun 26, 2009, 12:50 AM
I think a good sub 1k autopilot must have:

1. Triggers (a must)
2. air speed and altitude control (GPS or Pitot does not matter)
3. Waypoint navigation (100 is more than enough)
4. Ability to upgrade (a must)

if it also had:

5. Autonomous take off and landing
6. A good software package (moving maps or SDK)
it would kick butt.

brakar
Jun 26, 2009, 05:04 AM
I am not arguing that a close to null feature autopilot is a good one, or one that I would want to possess. (At this forum this would be like suggesting to car enthusiasts that Lada is a very good car). What I try to say is that I do see a numer of possible applications for such an autopilot, e.g. on construction sites, where they need to provide daily documentation of progress, businesses that have fixed objects/installations that need to be inspected regularly, and other applications where they want to fly the same route every time. Given that the simple AP can do the job, for such users simplicity might even be regarded as an advantage over more advanced systems.

brakar

Gary Mortimer
Jun 26, 2009, 11:09 AM
I guess overseas customers will benefit by going straight to a cut down IMU rather than 1.8.

But the long process of export control will start again!

Perhaps the IMU family could all be put on the same form??

If restricting the operating area for the device makes it easier to export I'm all for that. For my needs flight within VLOS is all I require.

Deep stall landing and safe launch for wings.

3D waypoints.

Variable speed waypoint manouvering.

Data logging

Moving maps

Circle hold.

Lots of flashing lights, any device built to impress should have at least 7 or 8 lights that flash. No good at all for impressing people without. Oh and a sticker that says Danger or Warning.

Do Ladas still come with the tin of paint Brakar??

-------

Wow I fell over laughing when I saw the UNAV update.

You have to love Xbees wrapped in yellow plastic

kbosak
Jul 10, 2009, 08:22 AM
Could anybody justify WHY you want the airspeed control.
For what type of mission you want variable airspeed.
Consider under 200AGL, VLOS.
What is so fantastic that can be achieved.
Remember most ariframes have 1:2 ratio between stall speed and max speed.
What is so advantegous in achieving 45mph on one leg and 65mph on another (which has nothing to do with groundspeed).
Suppose there is a product X without, and Y with,
how much would you pay for the feature.
100USD? 200USD?

kbosak
Jul 10, 2009, 08:27 AM
Indoor VTOL with automatic camera blocking & image composition.
With data relay capability from room to room (digital mesh flying for indoor-outdoor uplink connectivity)

brakar
Jul 13, 2009, 03:28 PM
kbosak, I hold you as a possible expert on aerial photographying. I therefore would very much appreciate your own answer to your question about the value of airspeed control. Do you use it on your missions? If not, has it ever happend that you had to re-do a mission due to the lack of such? brakar

mmormota
Jul 18, 2009, 07:17 PM
Considering calm flight (aerobatics out of scope), what is the benefit of IMU vs accelerometers only?
At first glance accelerometers (gravity vector) capable of holding the roll and pitch axis, for yaw the GPS speed vector seems to be enough.
Too much risk for a death spiral when accelerometers fooled, or what is the main reason of using gyros as well?

jglenn
Jul 18, 2009, 07:35 PM
I have tried to use just an accelerometer, in the tilt mode, to stabilize the
pitch axis on a hand launch glider. When you hold it horizontal, and tilt it,
on the ground, the elevator would correct for up/down movements. But on a flight test, it only works when the plane is about level. Useless, other than
detecting very close to level conditions. The gyros give you more data.

I have gotten some interesting results from a horizontal earth flux sensor, still
working on it. Can work well in limited cases, that is the challenge, to make it
more robust. In theory, it is possible you do not need IMU or thermopiles to
maintain level flight. Perhaps $100 worth of junk can do it. :cool:

dmgoedde
Jul 18, 2009, 09:49 PM
Could anybody justify WHY you want the airspeed control.
For what type of mission you want variable airspeed.If your question is not purely rhetorical, my answer is to ensure the craft stays above stall speed at all times. I know for a fact that you can get by with locking throttle at a good cruise speed because that is how AttoPilot worked up until about 1 year ago before I added airspeed sensing and control. However, it's nice data to have (airspeed) and it is also nice not being locked at one airspeed. For example, if you want to "punch it" and get home quick at the expense of efficiency.

More good reasons to have airspeed control and/or sensing:
2) By comparing airspeed of the aircraft, GPS ground track speed, and aircraft ground heading (those 3 pieces of data) you can work out the wind heading and speed. This wind data then can be used to schedule the amount of roll applied to achieve the desired turn rate, depending on how the UAV is flying relative to the wind direction.

3) Post-flight analysis of motor power consumption as a function of airspeed.

4) To keep airspeed well within limits even in steep climbs, and to save power in descents.

dmgoedde
Jul 18, 2009, 09:57 PM
Considering calm flight (aerobatics out of scope), what is the benefit of IMU vs accelerometers only?
At first glance accelerometers (gravity vector) capable of holding the roll and pitch axis, for yaw the GPS speed vector seems to be enough.
Too much risk for a death spiral when accelerometers fooled, or what is the main reason of using gyros as well?Using only accels has several problems:

1) You'll need to seriously RC dampen the accel analog outputs in order to reject vibration noise. Problem with RC filtering (the Kestrel 2 apparently uses 9Hz RC filter cutoff, I am using 20Hz in the AttoPilot IMU) is the induced lag. To get around the lag, the Kestrel uses a scheme that weights the IMU more heavily towards gyro predicition whenever the gyro rates get high. Atto IMU does the same thing. No gyros... then no way to continue the attitude predicitions by de-weighting accel input: you only got accels!

2) Without gyros you have no clear idea of the body rates, meaning the pitch/roll/yaw rates of rotation. You need these (and forward speed) to get an idea of centripetal forces for correction purposes. I got into HUGE arguments on another thread with people that didn't agree that centripetal corrections are needed or helpful in an IMU. What I know is that my IMU is freakishly robust, and theirs...??? I am not sure about theirs (they aren't posting results, or their results show gross issues like centrip effects screwing up roll estimate). Without these centrip force corrections the accel's output is a mixture of attitude and centripetal effects. If you don't have gyros, then you cannot calculate and subtract centrip effects. You will be doomed with only accels to suffer from a banking turn showing up like level flight.

mmormota
Jul 19, 2009, 08:10 AM
Thank you very much.

mmormota
Jul 19, 2009, 02:50 PM
I learnt a bit more about IMU, Kalman filter etc.

My next problem:
we have angle input from the accelaration sensor and angle derivative input from the gyro.
Using Kalman filter we combine them into an angle estimation with inherent delay.

Then we are using this filtered, delayed position as input of a PID loop to get stability.

It seems to be very ineffective use of the gyro's derivative signal. We use it to smoothen the position, got a delayed estimation of the real position, then use the derivative of this delayed thing as the derivative input of the PID loop...

Am I wrong if it's just because there are known ready made algorithms for Kalman filtering and PID loops, but not for direct (optimal) use of these inputs for a control loop?

Maybe better to use the gyro signal itself as derivative input of the loop?

dmgoedde
Jul 20, 2009, 06:10 PM
My next problem:
we have angle input from the accelaration sensor and angle derivative input from the gyro.
Using Kalman filter we combine them into an angle estimation with inherent delay.

Then we are using this filtered, delayed position as input of a PID loop to get stability.

It seems to be very ineffective use of the gyro's derivative signal. We use it to smoothen the position, got a delayed estimation of the real position, then use the derivative of this delayed thing as the derivative input of the PID loop...

Am I wrong if it's just because there are known ready made algorithms for Kalman filtering and PID loops, but not for direct (optimal) use of these inputs for a control loop?

Maybe better to use the gyro signal itself as derivative input of the loop?Why would you have much delay (lag)? Is your RC filtering of the analog sensors too high?

In my case, the gyro has an internal R of 180 k Ohms, and I chose 2.2nF external cap... 1/(2PiRC) = 401.9 Hz. I can get away with minimal RC filtering because the gyro design is inherently vibration resistant (engine vibration). Accels are the one I RC dampen much more: 32k Ohm internal with 0.22uF external = 1/(2PiRC) = 23 Hz. Because the accel data is so heavily RC filtered it has inherent lag, so my IMU code de-weights the accels when the gyro rates are above some moderate limit.

Why do you describe differentiating the gyro outputs? I think you mean integrating them, right? You take the last known position, and over a time delta you integrate the gyro rate to estimate the change, then add the change to the last know state in order to get an updated estimated position.

kbosak
Aug 13, 2009, 05:21 PM
kbosak, I hold you as a possible expert on aerial photographying. I therefore would very much appreciate your own answer to your question about the value of airspeed control. Do you use it on your missions? If not, has it ever happend that you had to re-do a mission due to the lack of such? brakar
I am far from being an expert here.
However one clear mark on the sky says, that with IMU autopilot, if it tries to maintain reasonnable course or heading, it almost automatically becomes spin-proof.
Now if it is spin-proof, you can afford reasonnable autolanding with less victims among the crew because you can fly slower.

For sure one of the limits is the overall flight speed vs windspeed: you want to have usually at leas 10-15km/h groundspeed. You could say, the winds are strong? The tempting idea is to define more airspeed, or define fixed groundspeed on waypoint legs.
In practical application, there is a problem. If you take any motoglider, anything an put more throttle, the autopilot wil retune everything, looks good, but the airplane itself has worse longitudal stability at non optimal airspeeds.
The end result is that you stil fly that damn plane, in higher winds, usually assisted with more turbulence, with airplane that is stabilising itself a little less.
You will start observing some pumping, oscillations around 2-5s period from most phtotplatforms. But then, you can fight it with tight pitch control curve based on gyro, IMU. Alas, the best method of obtaining smooth ride is to USE the plane stability instead of overusing control surfaces, as you will introduce some shaky high frequency oscillations on some airspeeds, and they will never be gone (they can have only 2deg in amplitude, yet the video will be unprofessonal and the photos blurred). The net effect is, when the weather is not good, boosting airspeed and playing as if it would be Gripen with inherently instable config, is not good for stability of the camera.
It is much better increase wind loading and glide speed for stron wing, move COG forward, more uptrim on elevator and try. Trying tightly controlled flying wings is not bringing the same crispness to my the photos as I see. Unless you spent a few years on platform analysis.
An airplane is not like a car, it def likes some selected airspeed you can shift +/- 10km/h using trimming, COG and wind loading.

The old joke is that the plane wants to fly by itself smoothly, the stupid RC modeller is just trying to prevent it doing so. The same story can be told about autopilots.

The airspeed is a very useful IMU input simplyfying a life of the autopilot developer.
However with great care taken and some assumptions on plane dynamics, you can make it with GPS speed and good accelerometers.
I agree the life with airspeed is so much easier and beneficial for the quality of the autopilot however it is a nightmare in the field.
My principal reason for not using airspeed is that you need to connect the tubing for the pitot if you have a plane that has removable wings, also the pitot tube has very short MTBF because of landing in the grass. Pitot tube in plane's nose is a joke as it picks mostly propeller action. Good for estimating rudder sensitivity, but not better for IMU quality or navigation.

Gary Mortimer
Aug 13, 2009, 05:29 PM
Very often it matters not a jot how stable the system is, if the suns in the wrong place or not there then the images can be rubbish!!

Lots of special sauce involved in bringing all this together.

Your platform looks very good for its tak Kbosak, I'm sure selecting better weather, maybe getting up for just after sunrise when winds are lighter makes a huge difference with imaging. Of course less light then.

The next round of the T3 competition should suit, it will probably be a photo mapping mission!

kbosak
Aug 13, 2009, 05:34 PM
The next round of the T3 competition should suit, it will probably be a photo mapping mission!
Try selecting sightseeing missions, or we will destroy 40 cameras lenses during the vertical photo contest ;-)
BTW at this stage maybe we chose for precision flying instead of making camera shoting. There is a lot of fuss about putting the camera, not related to the autopilots. This is simply 200EUR more to crash, in a very bad place (nose). For me this is done, but every piece of equipment in the contest halves the number of participants.

Gary Mortimer
Aug 13, 2009, 05:37 PM
I tend to agree with you, but its a crowd sourced thing!!

We definitely have to have a Pole Dancing contest in honour of yourself in the future!

kbosak
Aug 13, 2009, 05:38 PM
Very often it matters not a jot how stable the system is, if the suns in the wrong place or not there then the images can be rubbish!!

UV and polarising filters necessary, then you must maintain level wings since polar filters have special directions vs reflecting target. Lots of filters means longer exposition time neeeds more stable platform and so on.
In short you must fly nicely make lots of photos and select a few of them.

brakar
Aug 14, 2009, 08:34 AM
kbosak, thank you very much for the thorough explanation of trottle- and speed control with regard to aerial photographying in post #33. Lots of usefull information.

brakar

kbosak
Aug 16, 2009, 10:10 AM
This may be a bit "off the top" but what about a basic IMU stable platform that could be used for flight stabilization of aerobatic aircraft, helicopters, tri or quad copters, etc.
Basic IMU works on the table, point.
Anything more than that needs info about flight dynamics and different set of sensors.
There is no IMU plugin possible.
What PCB mfg houses claim to be IMU is a PCB with sensors.
Letting the user tune IMU for a platform means exposing ALL its software functionality.
Flying IMU needs airspeed or magnetometer or both. Who is going to integrate that? Who is going to provide calibration parameters?

This is like 'engine plugin' for cars.
Theoretically possible, but nobody does that: you would need to retune transmission, then suspension then everything.
Tanks have engine plugins. For a price and a good operational reason. Yet, one plugin fits one tank.

dmgoedde
Aug 23, 2009, 09:35 PM
...

airmcn_3
Aug 23, 2009, 11:52 PM
BTW - I am not an ego maniac, and I am not smarter than most people, (unless your initials are MH or DP).


Bahhh!!!! I just about fell out my chair :D