AttoPilot V3.0 6DOF IMU Q&A [Archive]

View Full Version : Discussion AttoPilot V3.0 6DOF IMU Q&A

Pages : [1] 2 3

airmcn_3

Jul 09, 2009, 07:01 PM

Hello,

This thread is for AttoPilot V3.0 6DOF IMU Q&A. We decided it a better suited title for the thread as we are still wrapping things up.

Further information and links to the AttoPilot V3.0 will be posted in this thread as the information comes. Please check back frequently.

We are starting a list of individuals that are interested in purchasing the new AttoPilot V3.0 6DOF IMU autopilot. Exact prices are not yet set in stone but we can guarantee it will be very competitive with current autopilots on the market. The AttoPilot V3.0 6DOF IMU will include the following:

• 4 servos / 4 Rx channels, for the simplest UAV’s requiring only 3 flight control and 1 trigger.
• Dedicated expander port (serial com at 230.4 kbaud) to drive up to 30 additional servos
• 11g accelerometers and 300 deg/sec gyros. Fully 3D capable IMU
• Improved airspeed filtering and gain scheduling
• Dedicated 2-way telemetry with GPS data in the $ATTO string. User defined baud rate from 4800 to 230.4 kbaud
• SD data logging is now an on-board capture of the serial stream, as a backup in case of COMS loss along with a physical SD card.
• 9 parameters are temperature compensated over the full mil spec -40 to +85C range, using 14 point linear interpolation.
• Uncorrected gyro drift is < 1 degree / minute

• SD logging

• Professional GCS software

- Optional antenna tracking will be available for sale as separate item.

If you are interested in purchasing a AttoPilot V3.0 6DOF IMU autopilot please post your interest and questions here.

If you do not want to publically submit your name to the list please contact me via PM or Info@attopilot.com

This is not a solid order list but a way for us to get a rough determination of how many autopilots we need to make for the first batch. There is absolutely no obligation if your name is on the list.

This list will be passed on to the distributor and will help them in assisting you with information and technical questions.

Prices, availability and export information will follow.

Thank you,

Chris McNair

Mecha

Jul 10, 2009, 01:00 AM

massimo

Jul 10, 2009, 01:34 AM

Hi Chris, USA export is possible?

regards

ios

Jul 10, 2009, 04:57 AM

Count me in for a couple of units! :)

2jers

Jul 10, 2009, 05:24 AM

Count me for one unit

Connexxion

Jul 10, 2009, 06:06 AM

Could you tell us more about export abilities?

At this moment we non-us citizens can't even get our hands on the "standard" Atto,let alone an IMU one! :cool:

d_wheel

Jul 10, 2009, 12:07 PM

Would love to say I am in, but only after getting some idea of price.

Later;

D.W.

airmcn_3

Jul 10, 2009, 01:21 PM

can you elaborate more on what kind of expansion servo board is needed?

Is the expansion port working on this model version? I ask because Atto 1.8 has many parameters that do not work or are suppose to be operational in future firmwares.

In regards to the GCS what does professional mean? is this GCS compatible with v1.8

Can you list the differences between the actual GCS and the professional version.

You do not need a servo expansion board to fly. The main board comes with 4 in/outs.

Every pin will work on the main board...... There are only two sets of pins that are not used on the V1.8 and those are for Pan and Tilt, these were put there for future development. Dean wants to have the ability to provide you with new firmware at a later date so you may have more functions then you initially received. If there are any other parameters that do not work on the V1.8 I would be interested in knowing what they are. Would you please elaborate???

Professional GCS is exactly that. Lots of $ spent to have high quality professional look and functionality.

I will get a list of the differences and let you know.

Thanks,

Chris

airmcn_3

Jul 10, 2009, 01:28 PM

Hi Chris, USA export is possible?

regards

USA export??? We are in the USA....... Do you mean is export to other country’s possible? If so. Yes would be the short answer. There is a dedicated individual that is working on Export licensing. All you need to do is fill out the paperwork and turn it in to us. For export information please contact Bill at info@attopilot.com

He has been very helpful in making the export process as smooth as possible. I am afraid I can not tell you exactly how long it takes from the time the paperwork is received by the state department.

Thanks,

Chris

airmcn_3

Jul 10, 2009, 01:33 PM

Could you tell us more about export abilities?

At this moment we non-us citizens can't even get our hands on the "standard" Atto,let alone an IMU one! :cool:

The reason for the hold up was that AttoPilot was waiting on their license to come in from the state department. AttoPilot needed to have a license that allows selling to overseas customers.

The License was received yesterday morning. For export information you can contact Bill at Info@attopilot.com Bill has all the paperwork you need to fill out.

Thanks,

Chris

brakar

Jul 10, 2009, 03:47 PM

Chris, could you please elaborate some more about the differences between atto v1.8 and atto IMU and intened areas of use? Pros and cons with regard to aerial photographying? brakar in Italia :cool:

airmcn_3

Jul 10, 2009, 09:33 PM

Chris, could you please elaborate some more about the differences between atto v1.8 and atto IMU and intened areas of use? Pros and cons with regard to aerial photographying? brakar in Italia :cool:

brakar,

I sure can.

1. Lack of XY and Z sensors and the fuss that comes with them: external wires and their clutter, and the wires picking up RF interferences.

2. You can fly in any weather condition.

3. The body rates (pitch and roll rates) were inferred in v1.8 thermopiles by differentiating the attitude positions, whereas with an IMU they are measured directly by rate gyros. The IMU also has a MUCH faster internal rate of calculations (200Hz vs ~50Hz at best for thermopiles). This means that the IMU gives a much cleaner and more precise attitude solution than thermopiles.

4. AttoPilot IMU uses 11g accelerometers with proper RC filtering and code "tricks" so that engine vibration is not much of a deal. In other words, some vibration padding might be needed for the IMU, but it is nothing to lose sleep over. Today Dean and I were flying the IMU in a 20 ounce 3D aerobatic plane with the IMU glued directly to the airframe and had zero problems. In fact the IMU handled not only 115 F temperatures and gusty wind it was also tested in torturous 3D RC and assisted flight without losing attitude solution or having drift.

5. Thermopiles do not have any clue about yaw rate were the IMU does. What this means is for smooth navigation you can use yaw rate to come out of turns slightly early which prevents over steering. The thermopile autopilot more relies on GPS data and good lock where the IMU uses more data coming from the internal sensors to give you a better flight.

So the moral of the story is you will receive a smoother flight thus giving you better video and or pictures.

Attached is a picture of the aircraft Dean and I have been testing today with the IMU attached directly to the airframe with no real vibration mounting.....

Chris

mpoyneer

Jul 11, 2009, 03:08 PM

Add me to the list...thanks.

brakar

Jul 11, 2009, 03:26 PM

I might sign up, depends on price, evt. avalability of a full feature AP and time frame for a export licence. Dean allready has my personalia. Joined forces with Dean Chris?

airmcn_3

Jul 11, 2009, 03:32 PM

I might sign up, depends on price, evt. avalability of a full feature AP and time frame for a export licence. Dean allready has my personalia. Joined forces with Dean Chris?

LOL, you could say that ;) We make a good team and get a massive amount of work done. Both of us work like freaks and enjoy it. We get along very well and have a good time doing it. I would say I have a good friend before I would say joined forces.....

Prices are still getting hammered out. I apologize for not posting a number but we do not want to give you false information. There are considerably more expenses that have to be worked into the final price other then physical hardware..... I promise you will see a number soon.

Thanks,

Chris

borneobear

Jul 13, 2009, 12:51 AM

Would love to say I am in, but only after getting some idea of price.
D.W.

Same here. Need price before committing. AP $ hard to get nowadays. :o

airmcn_3

Jul 13, 2009, 02:39 AM

Same here. Need price before committing. AP $ hard to get nowadays. :o

We hear you there..... There are going to be multiple options to purchase AttoPilot and its accessories, I believe most of you will be pleased with the results. I can tell you one thing, customer service is the upmost priority and you are going to receive the best service you could ask for. There are only a couple of things that need to be resolved and then we will post the info on this forum.

Thank you,

Chris McNair

Cort

Jul 13, 2009, 12:44 PM

I am very interested....and like the others curious about the price

spitfiremk9

Jul 13, 2009, 02:29 PM

I'l have a go at one of those also, I have all the rest so lets not be discriminatory.
One thing I'm concerned about owning one, if they are as good as you say they are and the after sales brigade is even half helpful, then there is a possibility that I might start saying nice things about it and become unpopular with $ome of the preacher$ on here!

Dennis H.

Jul 13, 2009, 03:25 PM

airmcn_3

Jul 13, 2009, 07:16 PM

I to might sign up, depends on price.

This is new to me, so when you said it controls / 4 servos / 4 Rx channels, for the simplest UAV’s requiring only 3 flight control and 1 trigger.

Trigger = meaning an off/on switch for the auto pilot?
And the other controls lets say, T/A/E?

!!!!CORRECTION!!!!

Sorry if I was not describing it as you would expect. The main autopilot board will have controls for A/E/T/ as well as one trigger (photo or alike). The rudder would be connected to the expander board. Again sorry for the mistake...

Again as soon as I get the price sheets I will post info. We apologize for the delay although it was planned this way.

Thank you,

Chris McNair

Dennis, when I get back to OKC from Deans I will give you a shout. My father lives in McKinney and I have to get down there to show off the new IMU, maybe we can hook up and you can play as well.........??????

Let me know Via PM.

Dennis H.

Jul 13, 2009, 07:27 PM

Sorry if I was not describing it as you would expect. The main autopilot board will have controls for A/E/T/R as well as one trigger (photo or alike).

Again as soon as I get the price sheets I will post info. We apologize for the delay although it was planned this way.

Thank you,

Chris McNair

Dennis, when I get back to OKC from Deans I will give you a shout. My father lives in McKinney and I have to get down there to show off the new IMU, maybe we can hook up and you can play as well.........??????

Let me know Via PM.

Ok, now I understand.

That a deal! you can pm me, when you plan to be over, and a cell number,
I don't know Mckinney very well. But I'll leave my plan book open. :D

dmgoedde

Jul 13, 2009, 08:25 PM

I to might sign up, depends on price.

This is new to me, so when you said it controls / 4 servos / 4 Rx channels, for the simplest UAV’s requiring only 3 flight control and 1 trigger.

Trigger = meaning an off/on switch for the auto pilot?
And the other controls lets say, T/A/E?Chris is going to correct his response. The servos controlled directly by the Atto IMU are just Aileron/Elevator (or elevon1 and elevon2), throttle and a trigger. The trigger will be just like Atto v1.8 wherin the user can configure it as a logic driver or a servo PWM driver, and setup the active and rest positions.

If you want rudder or all the extra things like flaps, then you need the expander board.

Price is not set, but I can tell you it will be competitive. Keep in mind this autopilot is severely torture tested and refined based on data feedback from countless flights under adverse conditions, mil-spec ranges, and has many sophisticated features for navigation, self trims, gain scheduling, and generally very high resolution in everything it does. I would happily put it up against ANY other IMU autopilot that currently sells for < $10k.

Mecha

Jul 13, 2009, 11:17 PM

You do not need a servo expansion board to fly. The main board comes with 4 in/outs.

Every pin will work on the main board...... There are only two sets of pins that are not used on the V1.8 and those are for Pan and Tilt, these were put there for future development. Dean wants to have the ability to provide you with new firmware at a later date so you may have more functions then you initially received. If there are any other parameters that do not work on the V1.8 I would be interested in knowing what they are. Would you please elaborate???

Professional GCS is exactly that. Lots of $ spent to have high quality professional look and functionality.

I will get a list of the differences and let you know.

Thanks,

Chris

Thank you for the replay. yes I was referring to the pan/tilt as well as some of the parameters in the set file, like reverse sings for ch7, or D term for servo 3-7 or the plane mass $51. Don't get me wrong Atto v1.8 does more than I need and I love it.

I am interested in the IMU based because I’ll be moving near DC and the weather there is not as pleasant as in Miami, FL. Also I like the idea of been able to control things like flaps, airbrakes, rudder and pan/tilt amongst a cool GCS with moving maps.

Will the GCS have a OnePoint targeting, or a configurable no-fly zone (other than distance from home)?

boyisabird

Jul 14, 2009, 01:50 AM

Keep me in the loop...

airmcn_3

Jul 14, 2009, 02:31 AM

Keep me in the loop...

No problem! All names are being stored in a list. I will PM each member individually to get further information such as e-mail addresses and names. Again this is not binding by any means; we are simply trying to get a good idea of possible sales.

Thank you for your interest.

Chris McNair

tekrunner

Jul 14, 2009, 09:00 PM

airmcn_3

Jul 14, 2009, 10:33 PM

What's the scheme on the antenna tracker? ImmersionRC from the FPV forum sells one but it requires calibration everytime you move the antenna and you have to have their OSD device inside the plane. Can you elaborate on yours?
The antenna tracker is a separate item that will be available. You will not be required to re calibrate each time if you move it, but you will have to make sure it is pointed north. If you move it 400m away then I would expect you would need to recalibrate it.

The unit we are going to offer will come with bubble level and compass built on the system.

If there is any further info you need please let me know and I will try and answer your questions.

Thank you,

Chris McNair

d_wheel

Jul 16, 2009, 08:43 AM

Since no one will state a price, I will say I'm in if it is under $2000.00.

Later;

DW

airmcn_3

Jul 16, 2009, 12:30 PM

Since no one will state a price, I will say I'm in if it is under $2000.00.

Later;

DW

DW,

A price will be posted as soon as we receive the numbers. The Marketing and Sales Company is taking care of the numbers....................

Chris

Soulglow

Jul 20, 2009, 04:39 AM

Yep !

Question: would'nt that be simpler from devlopment pt of view to "simply" offer a IMU module to upgrade the already available Atto v1.8 ?

The caracteristics of v1.8 are very good, and permits a wider choice of airframes: with 3 channel for control...... flying wing or high wing glider?

SO... if i need an aileron plane.... i will have to put a thermopile stabilisator on top of Atto ? :confused:

Payload control eliminated ( camera stabilisation) ?

I will take a Atto v1.8 with an IMU unit option right now, but not if it have been stripped of most of his hot features.

My .02 $

Alain

dmgoedde

Jul 20, 2009, 06:00 PM

Question: would'nt that be simpler from devlopment pt of view to "simply" offer a IMU module to upgrade the already available Atto v1.8 ?This is not possible because of the available IO pins left over on Atto v1.8: there are none. The only available trick is to have a seperate IMU module, then the IMU attitude solution is converted by DACs into thermopile-equivalent analog signals (to look like XY and Z thermopiles) that plug into Atto v1.8. This is pretty convoluted way of doing it, plus then we wouldn't have the body-rates of the IMU directly inputed into the Atto controller. It is too Frankenstein-ish. Also, the IMU alone is much more complex than anything inside Atto v1.8 requiring special calibrations which consume lots of time and are painstaling. I bring that up because of the cost... there are GREAT reasons why no commercial company sells an IMU autopilot for less than $3,000 (if you don't count the U3550 at $1500)... I would expect that with an $800 Atto v1.8, people would NOT feel OK to pay an additional $1000 or more for an IMU add-on.

The caracteristics of v1.8 are very good, and permits a wider choice of airframes: with 3 channel for control...... flying wing or high wing glider?Atto v1.8 actually has FOUR channels for flight control, then 3 more, one of which is the trigger controller. The remaining 2 are currently un-coded pan and tilt. 7 "channels" total. The 50Hz attitude control of both the v1.8 and 3.3 IMU are 100% suited to flying wings and full house trainers.

SO... if i need an aileron plane.... i will have to put a thermopile stabilisator on top of Atto ? :confused:No. If you have an Atto v1.8, it is a complete 3 axis autopilot. If you instead have the v3.3 IMU autopilot, it also is a complete 3 axis autopilot. In fact, both of these autopilots excel with small aileron planes... and by 'small' I mean between 8 ounces up to 20 ounces... 32 ounces. All that is OK. Of course your 10 Lb (160 ounce) 8' Telemaster is fine too.

Payload control eliminated ( camera stabilisation) ?Payload control for triggers is inside both Atto v1.8 and the IMU version.

I will take a Atto v1.8 with an IMU unit option right now, but not if it have been stripped of most of his hot features.I have prototype IMU autopilots that are based on a modified v1.8 control board, but this will never be a production unit. Besides, even if this were to become a product, it would not cost just a little more than the v1.8 at $800. It would be more by about 2-3X.

Dutchboy

Jul 20, 2009, 10:14 PM

Count me in for one of these IMU units.

Dutchboy (Torin Segstro)

Mecha

Jul 22, 2009, 12:33 AM

will the new GCS have a Mission Simulator? can anyone comment on this

airmcn_3

Jul 22, 2009, 12:43 AM

will the new GCS have a Mission Simulator? can anyone comment on this

The short answer is NO but Dean and I have been talking about this. It has to do with code and how it’s written; the system would need to run through the autopilot in order to be accurate.

Stand by on this one. Its one more major item to add to the giant list we already have........

Chris

Cort

Jul 22, 2009, 12:54 AM

Cort

Jul 22, 2009, 01:21 AM

airmcn_3

Jul 22, 2009, 01:26 AM

okay i re-read my post....I am willing to pay for the development of simulation in the end cost of the autopilot......not willing to pay for the development outright....LOL. Sorry guys wish I could do that for you but that unfortunately would be my sons college education or more.

Keep up the good work!

Cort
LOL, We got what you meant ;)

Don’t worry we will work on it, but...... We currently have a lot on our plate and Dean is way overworked. I will continue to bring it up to him and the GCS software designer.

Chris

tekrunner

Jul 22, 2009, 10:10 AM

For what it's worth simulation is huge for my needs. we operate in very tight environments and simulate all missions before they are flown. As you may have read in other threads I am currently using and MP 2128G and have the ability to simulate all missions. Mission simulations include terrain avoidance warnings (assuming you have loaded a DEM), indicators when cameras are being triggered, relative ground coverage of what is being captured by the photos (this is relatively crude but helpful), etc. I am very excited about the new ATTO and love the way that Dean and all that are involved with it are constantly posting their experiences and supporting the product. I would strongly support development of simulation and be willing to pay for it

Cort

Interesting, just read the Wiki on DEM
http://en.wikipedia.org/wiki/Digital_elevation_model

Any chance you could share more info on this? I've been interested in how the various autopilots work on a "hug the earth" concept.

So if I understand correctly micropilot lets you load one of these DEMs and helps maintain a certain altitude over various terrains? So if you approach a mountain it maintains the same altitude relative to a mountain it flys over and if it flys over a valley would it dive down and maintain the same altitude relative to the valley floor? Anyone know how Atto for example treats varying terrain without a DEM?

jtprouty

Jul 22, 2009, 10:41 AM

Atto doesn't know how high the terrain is at this point. When you do your flight planning you have to tell it how high to fly in meters. The altitude is based on height above ground and is relative to your home position when you initialize it. If you use Google Earth to make your waypoint file one of the thing you have to do is verify that your target altitude will be clear of all terrain. You can set different altitudes for different waypoints by hand editing the WP.txt file.

I may be wrong but I believe you'll be able to do all of this via a GUI in the near future.

Jimmy

tekrunner

Jul 22, 2009, 11:02 AM

^^^

Ok thanks for the synopsis. And yeah I think configuring your flight plan via GUI should be coming, Airman can you clarify?

Mecha

Jul 22, 2009, 06:39 PM

From this thread link http://www.rcgroups.com/forums/showthread.php?t=1083347

The pan tilt function is being turned on this week! As you may or may not know Dean is extremely busy trying to get all the functions and reliability you are looking for.

Chris those this means that V1.8 user will get pan/tilt too?

Will the new GCS have target tracking on the pan/tilt?

airmcn_3

Jul 22, 2009, 06:54 PM

From this thread link http://www.rcgroups.com/forums/showthread.php?t=1083347

Chris those this means that V1.8 user will get pan/tilt too?

Will the new GCS have target tracking on the pan/tilt?

Yes you are correct users will get the updated firmware.

Not sure if target tracking is being planned, I will ask Dean. I personally hope so!!

Chris

borneobear

Jul 22, 2009, 09:09 PM

Sorry if I missed it, but has the system been approved for international sales?

jtprouty

Jul 22, 2009, 09:12 PM

Yes. Send a message to "info@attopilot.com" for more info.

Jimmy

Cort

Jul 25, 2009, 03:13 AM

TeKrunner,

sorry I did not respond earlier but I have been out of town. The DEM information is used in mission simulation to warn you that you are to close to terrain (If i remember correctly you set what you want the limit to be). During flight it will also warn you that you are getting to close to terrain.

Cort

tekrunner

Jul 25, 2009, 11:33 AM

Hey Cort,
Thanks for that info, I found it quite interesting.

tekrunner

ssassen

Jul 28, 2009, 05:43 PM

What's the scheme on the antenna tracker? ImmersionRC from the FPV forum sells one but it requires calibration everytime you move the antenna and you have to have their OSD device inside the plane. Can you elaborate on yours?

Well, think about if for a minute. If you move the antenna, how would it know where North is? Or where you moved the antenna to? The EzAntennaTracker Pro will have a built in GPS (required for self calibration) and a few other handy features so it can be used on a moving object and still track the plane/UAV.

Cheers,

Sander.

airmcn_3

Jul 28, 2009, 05:56 PM

Well, think about if for a minute. If you move the antenna, how would it know where North is? Or where you moved the antenna to? The EzAntennaTracker Pro will have a built in GPS (required for self calibration) and a few other handy features so it can be used on a moving object and still track the plane/UAV.

Cheers,

Sander.

Sander is correct, unless you have a GPS on the tracker you will always need to point the tracker north to calibrate.

Chris

brakar

Jul 28, 2009, 06:19 PM

...

tekrunner

Jul 28, 2009, 09:04 PM

Well, think about if for a minute. If you move the antenna, how would it know where North is? Or where you moved the antenna to? The EzAntennaTracker Pro will have a built in GPS (required for self calibration) and a few other handy features so it can be used on a moving object and still track the plane/UAV.

Cheers,

Sander.

Can you PM more information on the pro tracker? Any idea when it'll be available?

airmcn_3

Jul 28, 2009, 10:00 PM

Can you PM more information on the pro tracker? Any idea when it'll be available?

Sure, or I can just post it here.

The tracking system is currently set up for Atto but we have provisions to make it work with other autopilots as well.

It is capable of moving 50kg although that is crazy overkill. Our system weighs 25lbs with counterweights. The extra ability is to withstand high wind loadings.

The tripod is a professional system with a single handed air assisted pole that can be raised and lowered to a height of 3m.

Availability is almost immediately although there is at least a 2 week lead time due to ordering of parts.

The price has not been set and is dependent of the components you choose for video and telemetry and the pan tilt gimbal you decide to go with. There are two options.

It is not cheap!!!!! It’s professional.

It may be a bit pre-mature just yet but if its an absolute necessity in a very short time we can chat about the time restraints you may have via e-mail or phone.

Thank you,

Chris

Cort

Sep 30, 2009, 11:14 PM

Hey guys what going on with this any updates?

dmgoedde

Oct 01, 2009, 01:21 AM

Sander is correct, unless you have a GPS on the tracker you will always need to point the tracker north to calibrate.

ChrisCorrection: It would need a built in megnetometer t have any ide of North. The only thing you'll gain from having a GPS on the tracker station is that the tracker can be moved and because it knows where it is, there is enough information for the trig. You would still need to rotate the tracker to point it at the UAV as a one-time calibration per setup location, that is without a magnetometer in the tracker.

airmcn_3

Oct 01, 2009, 08:25 AM

Correction: It would need a built in megnetometer t have any ide of North. The only thing you'll gain from having a GPS on the tracker station is that the tracker can be moved and because it knows where it is, there is enough information for the trig. You would still need to rotate the tracker to point it at the UAV as a one-time calibration per setup location, that is without a magnetometer in the tracker.

Got ya! Thanks for the clarification.

Kisssys

Oct 01, 2009, 09:43 AM

Dean

If you have to calibrate it by pointing it to the aircraft why does it have to set down pointing North.

I set my tracker down and point in the general area I'll fly, it turns left and right 200 degrees. I adjust a pot that tells the tracker where north is. I basically just use that as the one time calibration by adjusting it to point to the aircraft.

Kisssys

Mecha

Oct 01, 2009, 11:37 AM

airmcn_3

Oct 01, 2009, 11:57 AM

What is the IMU unit finally going to look like in terms of payload and control surface controls?

I remember there was going to be a daughter board with support for X many extra servos.

Also, the included GCS will be same as the one included with the 1.8V? or is the new one "professional" included with the IMU.

Dean is finalizing everything on the design. It will be a control unit and a separate IMU cube you can install anywhere. The first reason for this is we want you to be able to mount the IMU out of the way of wires and payload. Second reason is to give you the ability to buy just the IMU and integrate it into their own system. Third is in case you need to replace the IMU and do not want to dismantle your wiring in the bird. Plugging everything in and cleaning it up can be tedious.

The current GCS is the one that will be offered with the IMU. The "professional" version will be sold as a separate product if one needs.

Chris

Mecha

Oct 01, 2009, 12:40 PM

airmcn_3

Oct 01, 2009, 03:44 PM

will the control unit (support for how many controls) be purchase separately or included with the IMU.

I think you guys hit the nail on the head with ATTO 3.XX by separating both. Great idea!

Please update us with a tentative release month and a ball park price if available. I already have saved the $2500 for it.

I will talk to Dean on how many control outputs it has. I have a prototype and I do not want to make the wrong statement. There will be an expander board available.

I will also talk with the guys so we can finalize a price. It would be fair to say it will be around the $3000.00 USD range.
The control board comes with the system when you buy a full Autopilot.

Chris

boyisabird

Oct 02, 2009, 11:14 AM

dmgoedde

Oct 03, 2009, 02:32 AM

Second reason is to give you the ability to buy just the IMU and integrate it into their own system.Bit of a clarification... it is a 6 DOF AHRS, not just an IMU sensor suite. There is a processor inside, and it spits out a complete set of attitude solution data. You may also stream into it airspeed data for full corrections of centrifugal forces. You may also configure and flash to it desired update rate, data format, baud rates, etc.

It is like a highly expanded 6 DOF sensor that Analog devices sells for $700 (ADIS16355 (http://www.analog.com/en/mems/imu/adis16355/products/product.html)). Theirs is only 6 DOF sensors with a marginal temp compensation performed on the gyros across mil-spec range, inter-axis alignments as part of the calibration, and the relatively advanced features of G-force corrections on the gyros. What mine adds is:
1) Fully hermetically sealed. Use it below the dew point if you wish.
2) More accurate gyro bias calibration (note the ADIS pdf spec sheet (http://www.analog.com/static/imported-files/data_sheets/ADIS16350_16355.pdf) 1 sigma of bias comp on page 9, 2nd plot from top on the right... it is HUGE at about 0.25 deg/sec!!!). My 1 sigma is on the order of 0.04 deg/sec as indivicually calibrated for each assembled IMU.
3) 12 seperate corrections for intrer-axis alignment of the accels and gyros
4) 9 parameters temp-compensated. This is 3 gyro biases and both bias and scaling factors of the 3 accel axes.
5) Full AHRS solution output. Not just a compensated sensor suite.
6) Internal update rates > 200 Hz. This is now possible because I have thrown an ENTIRE 8 core Prop chip inside the AHRS and split up the tasks across several cores. No need to be conservative on the code now.

I'm happy to be finishing development of this product since work began last November.

dmgoedde

Oct 03, 2009, 02:36 AM

Hi guys, one question, one comment.

Tracker... sounds like these things are already out. Is this true? I'm assuming its basically just a rotating antenna w/ xbee or similar and small chip that does the trig to keep the antenna pointed near the plane?

Price. For what its worth, $3,000 is what federal government types can put on a credit card without having to go through a painful (and often losing to another vendor due to the possibility of a sole source justification not being approved) requisition process... :)Tracker logic controller makes assumption that the UAV home position was locked nearby the tracker. Then, only a few bits of data in the downlinked $ATTO telem stream are required for the tracker control board to do the required trig, and tell the pan/tilt servos where to point. There are servo-specific calibrations to do in each tracker control board. The root cause need for this is the pots in each servo have a different scaling factor.

Team Melbourne UAV used an AttoPilot Tracking antenna. My understanding of the crash is the tracker followed the UAV down to the ground!

spiggo89

Oct 03, 2009, 02:45 AM

1) Fully hermetically sealed. Use it below the dew point if you wish.

Does this mean that there is a vacuum present inside the seal? If not howcome the internal air doesn't dew too?

2) More accurate gyro bias calibration (note the ADIS pdf spec sheet (http://www.analog.com/static/imported-files/data_sheets/ADIS16350_16355.pdf) 1 sigma of bias comp on page 9, 2nd plot from top on the right... it is HUGE at about 0.25 deg/sec!!!). My 1 sigma is on the order of 0.04 deg/sec as indivicually calibrated for each assembled IMU.

Would you mind elaborating on how you were able to get it so low?

3) 12 seperate corrections for intrer-axis alignment of the accels and gyros

4) 9 parameters temp-compensated. This is 3 gyro biases and both bias and scaling factors of the 3 accel axes.

Again, more details would be appreciated :)

5) Full AHRS solution output. Not just a compensated sensor suite.

Is this the equivalent to a commercial Kalman IMU? (e.g. the x-sens mti-g)

6) Internal update rates > 200 Hz. This is now possible because I have thrown an ENTIRE 8 core Prop chip inside the AHRS and split up the tasks across several cores. No need to be conservative on the code now.

I'm happy to be finishing development of this product since work began last November.

Nice work, and good to hear. I'm glad there are people like you helping the hobbyist community against these grubby corporations. :)

surf89

Oct 03, 2009, 07:13 AM

all this sounds great. count me in as long as its not to many $$$$

Surf

kbosak

Oct 03, 2009, 08:07 AM

1.
For operation below dewpoint you need to make all hermetically sealed... Any short in digital interface is fatal anyway. Claiming that you can fly sealed IMU and unsealed digitals is same as taking unsealed IMU and letting it go. Yes it will fly perfectly for thousands of flights if there is good bias filtering algorithm.
2. Gyro accuracy error is one thing, but gyro integration error during maneuver is another.
Whatever you do, you must average towards accelerometer (or magnetometer) in order to eliminate both drifts.
I can have as much as 25deg/s gyro drift on my gyro setup over temprange, yet the Kalman filter is filtering the bias out, together with integration error, even in infinite loiter. It is just recentering the virtual gyro offset as it flies, using BOTH accelero data and gyro data (basically 'unconfirmed' accelero movements not followed by gyro are rejected and vice-versa, all is handled by the Kalman filter model).

I believe you are throwing all research in one direction, forgetting that 200Hz is inherently less resistant to vibration than lower sampling frequencies from the other autopilots. This is not the issue whether 10, 50 or 200Hz is better for calculation (200 is), the problem is that 200Hz lowpass filter has some sensitivity to 500Hz vibration as well, exactly where the things spin (30K RPM).

The real benefit is that when calibrating the sensor for temperature and using insanely high sampling frequency you are making simple filtering algorithms work better. So by choosing obsessively good gyro temp conditioning and sampling rate you can spend less time on heavy math, and time is money.

dmgoedde

Oct 03, 2009, 04:00 PM

kbosak: I started out with all the "heavy math" of auto bias tracking. It worked fine and robustly enough for many hours of flight tests in flying wings and 3D aerobatic planes. What happened is I continued to try new things and found something that is giving me better results, albeit my cuurent method is a royal pain in the arse in terms of calibration. Luckily, the calibrations don't shift by an appreciable amount over time once they are determined the first time.

25 deg/sec is rather huge over the temp range, and I assume you are talking about the upper limit of your system (flexipilot) being that which was stated in one of your spec sheets: +60 Centigrade. Yes, you can have the "Kalman Filter" use accel data and track bias, and I used to have my filter do this, however what do you do in the event of a sudden shift in the gyro bias? I used to see this, and of course it corrects out automatically but this can take time meanwhile the IMU solution can either diverge or be inaccurate. I discovered these large bias ranges and sometimes sudden jumps were more of a stress PCB layout issue. Small bias drifting is one thing, but with potential of 25 deg/sec change over your temp range is so large that I would be afraid of overloading the ability of the filter to track large temp changes all at once. Nowadays (after making countless experiments on how to best mount the gyros and PCB layout) I only see about a 2.5 deg change in bias over the entire temp sweep range of -40 C to +90C. I also discovered (then later realized it is a low-key parameter mentioned in the spec sheet) that the magnitude and orientation of G forces on the sensor affect the bias by non-trivial amounts (1 g can cause 0.25 deg/sec bias change, depending on the orientation of the gyro). So now with such a smaller 2.5 deg/sec change in bias over the -40 to +90 C range, it is rather easy to take 100 second sample averages at 14 temperature points across this range, then have a calibration table written in the autopilot for mere linear interpolation, and at any temperature already know the bias within approx +/-0.04 degrees/sec (that is a +/- 1 sigma around the mean).

It might sound ridiculous to have a hard-written calibration table for the gyros rather than automatically track bias in real time, but again I have done auto-tracking method in the past and for my needs judged it inferior to what I now do. With the hard-coded table of gyro bias versus temperature, there is ZERO wait time after powering up. There is no need to capture an initial bias and start tracking it. Quite simply, my IMU starts spiting out valid attitude data within a few milliseconds of being powered up. Another advantage is for the yaw gyro I DON'T have to rely at all on GPS heading info to track that bias. The GPS method is much less than satisfactory in windy situations. A magnetometer would be better, but I am trying to keep this initial 6 DOF IMU/AHRS with the most lenient export classification by purposefully excluding magnetometers and any ability for long duration dead reckoning navigation.

It would take pretty gross condensation of moisture to cause the digital electronics to fail, e.g. shorts of logic lines to source or drain. I am MUCH more worried about something I feel is 1000X more sensitive: faint traces of moisture on the analog pins of the gyros/accels/filter caps/ADC sample pins causing voltage level shifts. My IMU (the "Goedde Filter") is handling integers to 20 bit resolution on 5V gyros and 3.3V accels. I did this to ensure the math resolution is down in the noise of the sensors. There are tricks involved in my method that do real time estimation of a least squares linear fit on the incoming ADC samples as they are clocked in from the ADC. As I mentioned, I admit 20 bit integers were chosen to ensure the math resolution is well within the noise of the sensors so that I avoid stupid integer math errors; I need to keep the noise nice and white and Gaussian (it's a hopeful assumption, but it appears to hold true). If you look at what a 20 bit resolution is on 5 volts, it would be s step size of around 5 uV (that's micro Volts) and 3.3uV for the accels. It is worthwhile to do everything possible to keep it all bone dry. In a similar vein, the 2 channel OpAmp used in the FMA sensors (the AD8552) uses ~1000x voltage multiplication from the raw thermopile levels, and in the spec sheet Analog Devices mentions certain special PCB layout techniques and mentions it worthwhile to apply coatings to the PCB to prevent adventitious moisture from shifting voltage levels. If you have ever cracked open an FMA sensor head, you will notice they read the spec sheet of the OpAmp and used a silicone conformal lacquer.

Coatings can cause side effects in their own right. As a chemist experienced in air-free and moisture-free synthesis and having used special techniques to dry solvents down to the ppb level of moisture, I can tell you that there is at least ppm or ppt moisture levels in any liquid or solution you buy. So putting a conformal coating on electronics might prevent them from gross moisture, but will actually ADD traces of moisture. Coatings can also change the stress behavior of the circuit or analog component. So, I opted for no coatings, researched the best PCB layouts, and chose to hermetically seal the IMU.

No vacuum inside the package. I live in Arizona and most of the year the relative humidity is < 10%, with dew points below freezing. Even this is not good enough however because if the IMU were sealed with this atmosphere inside then condensation frost might happen at -30 or -40 C. So I do several things:

1) Fully test the assembled device (but not calibrate yet)
2) Anneal at 135 C to relieve solder stresses from the hand assembly portion
3) Clean the HELL out of it, then inspect
4) Bake at 100 C for extended time period (there is even moisture in the device packaging materials, and possibly within the PCB FR4 fiberglass layup as well, not to mention volatile solvents from the cleaning process)
5) Immediately after baking, solder on the hermetic seal.
6) Use alcohol to wipe off residue of flux from the outside where the last solder joints were made
7) Anneal at 135 C again due to the last solder joints.
8) Extensive calibration.

I considered adding some sort of moisture "getter" inside the sealed AHRS package, but don't think that is really required.

Overall, I took this crazy route based on data from a long development process. I also have heard from a military UAV maker that they are unhappy that the autopilots they have used in Afghanistan don't work if you let the UAV sit on the tarmac in full sun and the UAV temps up to 60+ C. They mentioned elaborate schemes of pumping air conditioning into the UAV avionics bay prior to launch. I also thought it kind of funny that IMUs use sensitive analog components and this would preclude, in a practical sense, usage below the dew point.... certainly not down to bottom of the mil spec range of -40 C. So why not kill the problems at their root cause, and allow operation over the entire range?

Regarding 200+ Hz IMU iteration and rejection of vibration comment - there is nothing of value in that statement. The high rate of the IMU loop is for the purpose of high-fidelity integration of the 3-axis gyros to propagate the model forward in time. This is why I went to the pain of carefully optimized code and fast integer math to make the code fast in a single 20 MIPS core, and the special 3D nature of the way gyro rates update the model in a method without singularities, and why I even break down certain self-referencing equations into quarter steps running at over 800 Hz.

The ADXRS610 gyros are specially designed to be essentially immune to vibration. They have a dual sensor structure per gyro. they have an internal impedence on the rate output of 180 k Ohms, and I use an external cap of 2.2 nF. Therefore the -3db bandwidth is 401 Hz. No problems there. Now to the Accels: internal impedence of 32 k Ohms and I chose external cap of 0.22uF. -3db bandwidth works out to 23 Hz. THIS is why my IMU has been proven in many flights to be essentially immune to vibration; the 23 Hz bandwidth is absorbing 100+ Hz harmonics of the motor and airframe. You just don't need fast bandwidth on the accels because the model is primarily driven by predicitions from the gyros, which are themselves pretty much immune to vibration.

Also, I chose accels with +/- 11g range. If I were to have chosen +/- 2g or +/- 3g accels like others, then there is the danger when near the limit of the signal (with +/- noise) being clipped on one end of the noise distribution. This would seriously screw up the IMU model in high G manuevers. I saw this in my early IMU work using +/- 3g accels with 100Hz data logging to SD card. Whenever any one of the accel axes saturated the IMU model solution "blew up". Using +/- 11g accels will allow sustained banking turns of well over 60 degrees, but ONLY IF the effect of these g forces on the gyros is accounted for.

This is SUCH a nifty and fun thing to have done for development. 2009 has been a strange year in part due to the IMU development. Part mystery novel, part horror story.

dmgoedde

Oct 03, 2009, 04:16 PM

I believe you are throwing all research in one direction, forgetting that 200Hz is inherently less resistant to vibration than lower sampling frequencies from the other autopilots. This is not the issue whether 10, 50 or 200Hz is better for calculation (200 is), the problem is that 200Hz lowpass filter has some sensitivity to 500Hz vibration as well, exactly where the things spin (30K RPM).This is the source of the misunderstanding....
1) I am not using any sort of Kalman Filter.
2) When I described 200Hz, I was not describing the bandpass of the accels. The 200Hz refers to the fact that my IMU code cycles through 200 times / sec.

My IMU is not inherently less vibration resistant than others. In fact I am quite certain it is more so by a fair margin based on close conversations with others that have used the main systems. Also, I have used the IMU in a grossly mis-balanced prop situation on a 20 ounce e-Foamy of Chris (airmcn_3) and we were not able to confude the IMU. With finger on the IMU and motor running, the buzzing was so strong so as to make your finger numb. Not only did it keep the attitude solution in flight like this, we did bizarre non-UAV things like 400' vertical climb with snap rolls, and recovery from inverted flight all without incident.

Chris - were we EVER able too confuse the IMU over those 5 weeks of testing? Oh yeah, it was 115 F then also.

dmgoedde

Oct 03, 2009, 04:38 PM

Nice work, and good to hear. I'm glad there are people like you helping the hobbyist community against these grubby corporations. :)I AM a grubby corporation. But this is to be expected. The amount of time and money I have blown on development is about 100X anything a part-time hobbysist would do. I have large debts to make up, otherwise all this was a giant waste of personal money. If I wanted to make a simple IMU that works "OK" under standard conditions, then I was 100% done 9 months ago. Back then my IMU was self-tracking of all gyro biases, and it all fit on a 1" x 1" single sided PCB and none of the gyros were mounted orthogonal to the main board. There were no factory calibrations, and no corrections applied for inter-axis misalignment between the sensors. It all would have been fine in high wing trainers and was even tested mostly in small flying wings.

BUT - my goal was to screw with the established autopilot companies, and even exceed them in respect of the torture-ability of the IMU. I wasn't trying to just introduce another IMU that passes the generic test of working near room temperature and calling +/- 5 to 10 degree attitude in flight as "OK" (Page 3 under "Attitude Estimation Error: Roll and Pitch" (http://www.williamsaerospace.com/Kestrel_2.2x.pdf)). In a sense, thermopiles spoiled me because they are immune to G forces and vibration, and have an inherent accuracy around 1-2 degrees. In most situations thermopile attitude sensing exceeds any IMU. So, here I am trying to make my initial 6 DOF IMU "perfect" and handling all effects and conditions.

Inter-axis misalignments:
Even if the sensor packages are mounted perfectly orthogonal, the internal sensing structures might be off a couple degrees. It's all described in the spec sheets of these sensors. This means in practice the sensing axes are NOT orthognal, and therefore rotation intended to be purely along one axis actually "maps" onto the other two axes by some small amount. Typically the effect is somewhere around +/-10 parts per thousand (example: 100 deg/sec in one axis causes an apparent rotation of 1 deg/sec on another axis). Same goes for the 3 accel axis. This is not something you have to track continually in flight, instead it can be measured and calibrated out at the factory.

As an example using gyros, consider that the yaw rate should be zero if only pitch or roll rate is present but no yawing is happening. In reality, any non-zero rate in another axis maps into yaw and causes the yaw sensor to respond. In careful tests of isolated movements, I measure what fraction of motion in each axis maps into the other two axes, then these corrections go into a table. In the IMU code the raw analog data of each gyro is bias corrected then scaled into an angular rate. Next, depending on the raw rates in the other two axes, we know how much should be mapping into this axis of interest, and corrections are applied. In practice this is NOT a giant complex problem requiring insane math skills to correct. It is SIMPLE: other axis' rates map into the other axes by a certian ratio. In reality the ratio has to do with sine of the angular dipping into one axis of another. 0 misalignment causes 0 mapping of one rate onto the other sensor. 0.5 degrees would cause 8.73 parts per thousand of one axis rotation being mapped into the other. Here is an example from a data table entry in the Atto IMU code, in part per thousand:

RollCorrect_Pitch = 18
RollCorrect_Yaw = -13
PitchCorrect_Roll = -31
PitchCorrect_Yaw = 21
YawCorrect_Roll = -14
YawCorrect_Pitch = -6

So there you have it: in one fell swoop all 3 gyros are corrected for inter-axis misalignment that comes from both sources of error: PCB and package misalignment, and internal sensor structure alignment.

dmgoedde

Oct 03, 2009, 05:15 PM

I AM a grubby corporation.Let me elaborate a bit:

$5000 for an IMU autopilot might seem like a lot, especially when you know the components only cost $300 to turn out a copy, and maybe another $500 in PCB assembly, workmanship and calibration. Also, $5000 is far above the average person's hobby budget. Also, there are things like the Ardu-IMU floating around for $100. All these things make average hobby UAV people get angry or just confused, and think the autopilot companies are raping people.

Consider this: there is insurance, huge development costs, business costs, taxes, and after all this a company needs to pay off debt and turn a profit. What the company gives in return is a professionally designed and developed product that has gaurantees to work, otherwise it is replaced or fixed. When someone pays $5000 for an autopilot you'd better be sure they aren't interested in coding or having to configure Linux on their machine to support it, load firmware, screw around with XML clode lines. No, they expect to install it, use a GUI or simple interface to get it customized for the airframe, and then they expect it to work.

Also consider, the calibrated Analog Devices ADIS 6 DOF sensor suite I alluded to earlier sells for $700. My AHRS meets and exceeds all of their specs, adds a slew of additional corrections, and includes a configurable setup and internal high powered 32 bit processor for a complete and very accurate attitude solution. It accepts speed data for full centrifugal corrections, therefore the attitude accuracy specs are the same in level flight or loiters... there is no difference. So based on simple logic, the unit I described would have to sell for > than the $700 price of the ADIS sensor. With configurable setup and full attitude solution it is in the performance ballpark of the $4000+ stand alone AHRS units already out there. Of course it won't retail for $4000, but also not anywhere near as low as $700.

kbosak

Oct 03, 2009, 07:02 PM

Small bias drifting is one thing, but with potential of 25 deg/sec change over your temp range is so large that I would be afraid of overloading the ability of the filter to track large temp changes all at once.

For me it works as designed.

So now with such a smaller 2.5 deg/sec change in bias over the -40 to +90 C range, it is rather easy to take 100 second sample averages at 14 temperature points across this range, then have a calibration table written in the autopilot for mere linear interpolation, and at any temperature already know the bias within approx +/-0.04 degrees/sec (that is a +/- 1 sigma around the mean).

Of course pre-adjusting the input this way is best. But a well adjusted Kalman is filtering it out event without temp compensation on very bad gyro.
So the temp based pre-adjustment is not absolutely necessary using classic IMU implementation and even current mass market gyros.

It would take pretty gross condensation of moisture to cause the digital electronics to fail, e.g. shorts of logic lines to source or drain. I am MUCH more worried about something I feel is 1000X more sensitive: faint traces of moisture on the analog pins of the gyros/accels/filter caps/ADC sample pins causing voltage level shifts. My IMU (the "Goedde Filter") is handling integers to 20 bit resolution on 5V gyros and 3.3V accels.

Analog signal conditioning in FLEXIPILOT handles this OK.
Analog filter design with proper choice of impedances is the key.

So why not kill the problems at their root cause, and allow operation over the entire range?

Because major operators operate in the desert...

spiggo89

Oct 03, 2009, 09:42 PM

So why not kill the problems at their root cause, and allow operation over the entire range?
Because major operators operate in the desert...

I'd put this down to a lack of understanding of the English language?

Mecha

Oct 03, 2009, 11:46 PM

will Atto3.xx have autonomous takeoff/landing option? or deep stall landing?

Paul_BB

Oct 04, 2009, 04:24 AM

For me it works as designed.

I agree, EKF is at least 10x more performant then any complementary filter (CF).
By the way, somebody I met compared the Extended KF with the Unscented KF and told me (To Be Confirmed...) that the UKF brings another order of magnitude in performance.
While I found that the computational load of the EKF is maybe 100x greater than the one of the CF (in case of a 7 states EKF), this guy told me that the computational load of the UKF is not so bigger than the EKF one (for the same number of states), about twice as big.
Can you describe your EKF (number of states, decoupling etc..) if this information is not secret ? :D

kbosak

Oct 04, 2009, 05:47 AM

Paul_BB

Oct 04, 2009, 07:34 AM

I am using EKF with a few states, but cannot tell details as it is going commercial.

Fair enough, I hope you and Dean will be successful. The more IMU the better.

CenTexFlyer

Oct 04, 2009, 11:24 AM

Anyway I hesitate to speak openly too much about HOW to make things.

Good thing to do......D

airmcn_3

Oct 04, 2009, 05:54 PM

There is more info here then needs to be......

airmcn_3

Oct 04, 2009, 08:16 PM

will Atto3.xx have autonomous takeoff/landing option? or deep stall landing?

Yes, but the landing option will require Ultrasonic range finder which we have already located for UAS use. Nice and small and very accurate.

Change from Laser range finder. Made a mistake.

jtprouty

Oct 04, 2009, 08:23 PM

Why not use ultrasonic? Sensors are under $70 and I've seen them used very successfully.

Jimmy

airmcn_3

Oct 04, 2009, 10:06 PM

Why not use ultrasonic? Sensors are under $70 and I've seen them used very successfully.

Jimmy

We have a very nice one to try and you are right for landing the ultrasonic will do fine. I misstated what I was saying. We are going to use the Laser for terrain following.....

Thanks for the reminder!

Chris

jtprouty

Oct 04, 2009, 10:15 PM

That ultrasonic sensor should be fairly easy to setup with Atto. I've used them with the MicroPilot and with an in-house helicopter autopilot project and they are very easy to work with. It would be nice if they were a little smaller.

Good idea on the laser range-finder for terrain following. Might also work for keeping a pan-tilt system pointed at a single point while the plane obits. :)

Jimmy

Mecha

Oct 04, 2009, 10:17 PM

Yes, but the landing option will require Ultrasonic range finder which we have already located for UAS use. Nice and small and very accurate.

Change from Laser range finder. Made a mistake.

Any of these part of the control board or add-ons to it/

airmcn_3

Oct 04, 2009, 10:19 PM

Any of these part of the control board or add-ons to it/

You could call it an add on but it will have a cable that runs from the sensor to the control board. You will have to buy it separately.

spiggo89

Oct 05, 2009, 06:37 AM

My IMU (the "Goedde Filter") is handling integers to 20 bit resolution on 5V gyros and 3.3V accels. I did this to ensure the math resolution is down in the noise of the sensors. There are tricks involved in my method that do real time estimation of a least squares linear fit on the incoming ADC samples as they are clocked in from the ADC. As I mentioned, I admit 20 bit integers were chosen to ensure the math resolution is well within the noise of the sensors so that I avoid stupid integer math errors; I need to keep the noise nice and white and Gaussian (it's a hopeful assumption, but it appears to hold true). If you look at what a 20 bit resolution is on 5 volts, it would be s step size of around 5 uV (that's micro Volts) and 3.3uV for the accels.

I've been meaning to ask you since you don't directly state it in this post, but what resolution are the ADC samples? If they are 20bit I would be interested in some of the pcb design tricks you have used to achieve this resolution.

I have heard from people who make digital scales (ADC experts) that more than 16bits is virtually unachievable since at this scale minute details such as the tolerance of components destroy the accuracy, and also that the ADCs themselves have up to 24bit resolution but they are only 16bit accurate, an important distinction.

kbosak

Oct 05, 2009, 12:28 PM

I've been meaning to ask you since you don't directly state it in this post, but what resolution are the ADC samples? If they are 20bit I would be interested in some of the pcb design tricks you have used to achieve this resolution.

I have heard from people who make digital scales (ADC experts) that more than 16bits is virtually unachievable since at this scale minute details such as the tolerance of components destroy the accuracy, and also that the ADCs themselves have up to 24bit resolution but they are only 16bit accurate, an important distinction.
Dean is only saying this because in absence of floating point in Propeller chip he is forced to use fixed point math everywhere.
Basically 20bit integer is like 6 decimal places floating point if you restrict float to live in the range of 0...1 values (no exponent), because 2^20 is 1048576. I bet he has 12bit ADC using MCP3208 or similar. Yet, it doesn't really matter who has 8 and who has 16 as a combination of ADC resolution + analog filtering frequency + digital sampling frequency is a design choice, not a feature.

Tom Harper

Oct 05, 2009, 01:53 PM

Gary Mortimer

Oct 05, 2009, 03:46 PM

You should only fondle exponents on the weekend Tom.

kbosak

Oct 05, 2009, 04:42 PM

kb,

What's your point (no pun)? Decimal FP? - what are you building, a calculator?

Integer is a special case of floating point - all values are normalized by design rather than constantly shifting values and fondling their exponents. Integer is much faster than FP and it is more accurate.
Definitely a feature.
ADC sampling precision of AttoPilot is not unusual among autopilots.
Neither is its IMU numerical precision.
My point is that 20bit decimal integer operations representing normalised values (i.e. accelerometer data between min and max represented as 0...1)
are not any more accurate than standard floating point.
There are no impressive precision behind 20bit integer math compared to any typical autopilot using standard floating point.
http://en.wikipedia.org/wiki/Single_precision
Standard float uses 23 fractional bits. If we fix exponent to any value (or use any arbitrary units of precision for fixed point math), it can be shown mathematically, that standard floating point used everywhere is as precise as 21bit integer math (small detail: float assumes exponent as power of 2 hence 2 bits less for comfort to say the universal truth).

20 bit in this case is just a solid design... Albeit costly one as anyone typing the code straight with float is not losing a single bit of precision.

Tom Harper

Oct 05, 2009, 07:03 PM

airmcn_3

Oct 05, 2009, 11:37 PM

dmgoedde

Oct 05, 2009, 11:49 PM

No not 24 it is 32bit!Let me explain Chris's words: He agrees with Tom that Atto's math is 100% top-end product. There was a conscious decision to use integer only math because at 32 bits the precision is there to do it accurately in only integers, and with the advantages of speed in keeping the math in integers only. then we have a winner.

Tom Harper

Oct 05, 2009, 11:54 PM

Amen

kbosak

Oct 06, 2009, 03:49 AM

I needed 48 bit integers for navigation on the simple system I built. I suspect Dean is running up there at times.

It is my understanding that AttoPilot uses 24 bit integer math. That is more accurate than standard floating point (per your #89) and definitely faster.

You are correct that integer math is a design choice and I believe it is the correct one.

So what's your point?
The point is you are posting again, without spending your time to learn (you could show some respect from time to time to an engineer, it's time to end f.. crisis), replacing mathematically false statements about implied engineering superiority of another product.
My claim was that given PROPERLY CHOSEN UNITS 21bit integer is not better than std float at any scenario.
Furthermore, near special exponent values and the choice of units, 23 bit integer is equivalent to std floating point.

It doesn't implies that 1280 bit integer would be any more precise than floating point. This is possible ONLY after re-normalizing and adjusting the units AFTER every rounding operation manually in order to extend 'dynamic range' of the values to the full representation of given integer.
In practice, when we use even 64bit carelessly for computations, it falls miserably against floating point (which is renormalized after every operation and ALWAYS uses 23 bit of its fractional part).

If in doubt, calculate how many bits in input you need for barometric formula in order to have output precision of say 23 bits, covering the altitude 0-8km.

dmgoedde

Oct 06, 2009, 02:43 PM

you could show some respect from time to time to an engineerMaybe you don't know who you are talking to with Tom. He is an engineer. Tom has lots of experience, and with experience comes prudence to know how to bake in the required precision in a system without arbitrary precision. There are always trade offs in the real world... I chose a balance between precision and computation speed. There is nothing careless in my 32 bit integer math equations. On the contrary I have developed and honed my skills to do anything required in 32 bit math despite a few required observations and practices when actually implementing equations in 32 bit integer math.

Rules:
1) scale decimal integers as powers of 10 to simulate decimals. Example in Atto is Lat is handled to the 5th decimal in degrees. This means latitude angles are 100,000X format. For example 34.12345 degrees is handled as the number 3,412,345. Baro altitude is handled as a 10X version in my code. Angles (pitch and roll) are handled as 100X.

2) The number of significant digits in a number need to extend to finer resolution than the signal... i.e. be within the noise floor. Example in my IMU code is 20 bit integers for the attitude solution of the XYZ components and body rates. 20 bits is approx 6 sig figures and well within the noise floor of my sensors. Also, the XYZ attitude state IS INDEED normalized to 1.00000 G at each iteration after the prediction and measurements are blended.

3) Balance the chosen precision in integer representations of dedimal numbers with not allowing overflow conditions to happen anywhere in the process space. In general I tend to use the max allowed precision that is just shy of overflow ever being a possibility for the allowed range of values of the parameter.

4) Make sure no overflows are possible inside any bracketed part of an equation. Overflows include being mindful that the most significant bit is the sign bit.

5) Design the equations so to make sure numerator is never less than the denominator, unless a banker's rounding is deemed OK.

dmgoedde

Oct 06, 2009, 03:20 PM

Dean is only saying this because in absence of floating point in Propeller chip he is forced to use fixed point math everywhere.
Basically 20bit integer is like 6 decimal places floating point if you restrict float to live in the range of 0...1 values (no exponent), because 2^20 is 1048576. I bet he has 12bit ADC using MCP3208 or similar. Yet, it doesn't really matter who has 8 and who has 16 as a combination of ADC resolution + analog filtering frequency + digital sampling frequency is a design choice, not a feature.Let me explain why my 20 bit is more than a design choice and is actually a feature:

1) First off, 20 bit representations are in the noise floor of my sensors, so it is adequate. Second integer math is very fast. So the fact of prop chip not having full native floating point engine in the silicon is a moot point. Besides, I can do long term integrations of rate to track an angle WITHOUT normalization, and the integrated drift is about 1 degree / minute. There is no monotonic drift; integer rounding is not happening because the white Gaussian noise of the sensor is a couple orders of magnitude larger than my 20 bit number base choice.

2) Yes, I am using the high-grade version of the MCP3208. It is the BI/SL version. It is a 12 bit ADC, 8 channels.

3) Why my 20 bit is a feature has to do with how I generate 20 bit estimates using a 12 bit ADC. First off, I am clocking out 12 bit samples from the ADC at about 35,000 / second. I accumulate (summate) 16 samples per channel. Of course I don't do all 16 on one channel then move on to the next channel. Instead I measure all 8 channels consecutively then repeat this 15 more times. This way the 16X oversample is still roughly time-paired data across the 8 channels. This entire process is happening at around 300 Hz. The result is 16 bit estimates of each channel updated at 300 Hz. Finally, I jack it up to a 20 bit estimate by a clever trick which takes the last 4 summations per channel and does a type of regression to more acurately estimate the current value without inducing delay. This regression creates another 16X per channel and looks like this:

S1 = most recent sample
S2 = 2nd oldest
S3 = 3rd oldest
S4 = 4th oldest

Estimate = 11*S1 + 7*S2 + S3 - 3*S4

Baked into this very simple regression equation is the slope between the samples as they project forward to the Y axis which is set at "now" time on the X axis of 0 seconds. The simple looking equation only assumes the samples are spaced evenly in time.

So you see, there are many examples in what I described how with AttoPilot I take lots of care to ensure the required precision is present balanced with simplified math for speed. I also normalize where required.

kbosak

Oct 06, 2009, 04:29 PM

Following oversampling theory sampling at 136Hz and 16bit is corresponding to sampling at 136*4^4=35KHz at 12 bit.
You have 16 significant bits at 136Hz plus 4 'marketing bits' that are pure artifact of smoothing.
Those remaining 4 bits contain useful data IF phase delay due to the polynomial smoothing you applied is so high that you limit signal bandwidth/frequency those bits can represent. In fact 136Hz/4^4 is 0.5Hz and this is the signal frequency you are able to represent at 20bit.

You could do exactly the same Xbit claim on any comparable autopilot.

Second point is that if you use 35KHz sampling, you are integrating a noise of the sensor, that is not guaranteed to be uniform thus killing the whole idea of oversampling by more than a few bits.

Noise of ADXL335 for example:
300micro_g/sqrt(Hz)

At 35000Hz it is 0.056124861g.
Given that this accelero is +/-3G range,
the noise occupies 0.056124861g/6g=0.0093541435 part of the range.
If the range is sampled by 12bit ADC at 35KHz (corresponding to 16 bit 136Hz), it is 4096*0.0093541435=38 ADC UNITS.
In fact whatever sensor you use, at this frequency you have around 38 units of noise from most MEMS accelerometers, which noise is not uniform.

Not to mention this frequency is a few times more than resonant frequency of those sensors - there is no hope they can behave uniformly transmitting any signal across ranges as 35KHz.

So basically you are integrating noise that is beyond your control. It is even out of control of the research dept that developed those sensors.

dmgoedde

Oct 06, 2009, 05:10 PM

I am using EKF with a few states, but cannot tell details as it is going commercial.
Sorry. Until I am sure I have something significantly better than any competing product, I am not announcing it. Anyway I hesitate to speak openly too much about HOW to make things. I am pointing the general directions that there are trade-offs and no single way to design. From the user point of view, this just.. works. It is off here or there when you shake it in random way, but it is not Ice Shaker IMU.I myself feel OK talking high-level technical details on RCGroups because:

1) It demonstrates that I know what I am talking about (I hope!) when people seem to have heartburn about why I made some certain choice in code or PCB layout or component choices

2) IMUs and autopilots are so vastly complex that the level of detail I give on here would help almost no one from exceeding some of the ideas that I am proud to have had and implemented.

My IMU is DESIGNED to handle baing shaked and rotated around randomly WITHOUT getting "off here or there" at all (well, attitude noise being constrained to fractions of a degree). I think the salt shaker is a good analogy. I have designed a salt shaker. Check out my Vimeos showing angular accuracy of better than 0.5 degrees after extended period of fast complex compounded motions and shaking. This is a quantitative horizon representation with angles displayed, not simply a no-detail 3D cube graphic on the PC. http://www.vimeo.com/6311096

Also - check out again my IMU flight video in Chris's 1.3m span flying wing. There is no slow pitch rocking like I have seen in some other people's IMU videos lately. There is no wing rocking, just a bit of airframe-induced yaw oscillation because the airframe designer/builder admits the two winglets are not square to each other. This level of performance in a flying wing is hard proof of the high performance level of my 6 DOF IMU. Not a high wing trainer or EasyStar type plane - this is a real-world can-always-fly despite wind airframe: a zero-hedral flying wing. http://www.vimeo.com/6494649

To extend the discussion on hard-core performance, consider these features I have added, all of them to eliminate B.S. things from ruining the end user's UAV experience under various conditions:

1) 50 Hz attitude controller is in its own core running at 20 MIPs on 32 bit integer math. No juggling of tasks allows tightly optimized method with no compromises. I simply can't make my 50 Hz attitude control any more detailed; nothing was left out.

2) Airspeed gain sheduling in the 50Hz attitude loop. Assumption is that control surface effectiveness scales as the square of airspeed. Therefore the gains are down-scaled as the recipricol of airspeed squared. I don't want to make assumption that most sUAS fly in a narrow speed range and thus pretend it is OK to use fixed gains. Also, in my gain scheduling a lower limit of 30 km/h is used to prevent the gains from scaling to infinity at 0 airspeed.

3) The I (of PID) in the 50Hz attitude controller serves with 0.5 second Ki reset time to track actual attitude versus target, and therefore self-trim pitch and roll. Because of this there is NO NEED to have the UAV trimmed in RC flight before passing control over to the autopilot. This system also absorbs issues like changing C.G. or a mis-balanced plane.

4) Pitot based airspeed control. With out this we are playing games in an autopilot. Pitot airspeed is safe and robust even in sUAS. With this we can employ a simple PID loop on throttle control so that no matter the climb or descent condition the airspeed is well above the stall speed. This is a safety measure in climbs and saves power in descent.

5) Exponential gains for pitch and roll. This is another layer of gain scheduling that takes care of a subtle problem I only discovered 6 months ago. Most UAVs have some dihedral effect, including flying wings with no real dihedral but having swept wings. What this means practically is in level flight the UAV is happier and semi-stable relative to higher attitudes. So in level flight the required PID gains are relatively mild. In high roll banks (30 to 45 degrees) the aircraft is more away from this stable zone and therefore typically requires a higher roll gain. If instead the autopilot is stuck with one gain for both level flight and high bank, then problems often happen. If the gain is just right for smooth level flight without oscillation, then when a 30 degree bank is attempeted the UAV will not have enough control authority to fully hit and hold the commanded bank angle. The gain is right for level flight but too wimpy for banking turn. If the gain is increased in order to allow proper banking turn, then the response is too hot for level flight and the UAV will display wing rocking in level flight. The answer is to schedule the PID gains for 50Hz roll control that are feed forward based on the actual roll angle. This allows THREE awesome results:

a) very smooth level flight
b) very smooth banking turns with actual roll right on roll target
c) the roll gain continues to scale to even higher values if the actual roll is pushed past the upper limit (e.g. 30 or 40 degree roll). If the actual roll is > the upper limit, then with the higher gain and fact that being > limit will cause the controller to push the system back in allowed range, we now have STRONG resistance to tip stalls. Written a different way, the system "knows" when an over-roll is happening and greatly increases the effort to push the system back into allowed safe range.

6) Integrated power sensing of 51.8 volts (12s LiPo) and 90 Amps. This allows a large variety of user-defined mAh based aborts. Team Melbourne UAV in the 2009 Outback had their 12' Telemaster powered by 12s LiPo pack and the Atto power sensor handled this just fine. The resistance of the sensor is only 500 micro-Ohms, which is on par with Hall sensors.

7) I have not yet announced or disclosed on this topic, but have recently greatly upgraded the vector-based navigation methods. I also completed an initial computational assessment of new methods and modelling. All of the math was modelled in the 32 bit Propeller chip that the AttoPilot uses, then imported into my PC so I can use Excell to build Macro commands for my old rusty copy of AutoCAD 2000 to generate graphics. What I am alluding to here I will discuss openly (rather than claim because my system is for sale, I can't disclose info yet). I have considered that the local curvature of the vector field is just as important as the target vectors represented in the field. The local curvature can be solved (approximated with sufficient practical accuracy) by numeric iterative methods in 32 bit integer math. Consider that if the UAV is already at the proper target heading er the vector field, this is NOT sufficient. The UAV must also take into account the curvature:

Curvature --> required turn radius --> required roll angle (with possible wind corrections)

The plots are over 2km x 2km grid and 400 meter radius loiter circle. The first plot shows just the target heading vectors, as I have shown on here before. The 2nd plot adds the 3rd dimension of curvature that has been massaged mathematically into required roll angle to keep the UAV on the local vector curvature. Blue zero curvature and red is max curvature. The 4th and 5th plots show what happens if there is wind. Sure, the target heading vectors are the same, but to give certain turn radii to follow the vectors requires taking into account the wind and UAV heading relative to the wind heading. You can see some pretty complex results in this 4th and 5th plots. This is a GREAT example of how small linear parts can combine together to generate a highly non-linear overall behavior or outcome. This is the essence of why numeric methods can be SO POWERFUL! All of these graphics are based on number generated on an AttoPilot processor cranking through an entire array of a process space. The 3rd plot has 17,777 elements (2x2km grid with 15m cell size) and was number crunched in the Atto processor in a little over 3 minutes.

Rather than just build some lookup table to control this, I opted to build and code a system to model it numerically in real time in the autopilot. This allows a general method to solve any number of odd situations that might happen in flight.

dmgoedde

Oct 06, 2009, 05:45 PM

If an IMU is only updating at 50Hz, then the response is no better than thermopiles. Themropiles have about 15-20 ms response time to slew over their range of response if you consider it as a RC time constant type of thing.

A 200 or 300 Hz IMU integration with matching bandwidth in the gyros is able to give 4-6x finer detail than thermopiles or IMUs running at 50Hz. This probably isn't required in semi-stable planes, but becomes increasingly required as the UAV shrinks to an 18" span plank with possibly very fast dynamics.

dmgoedde

Oct 06, 2009, 05:57 PM

Not to mention this frequency is a few times more than resonant frequency of those sensors - there is no hope they can behave uniformly transmitting any signal across ranges as 35KHz.
Why must I endure explaining away errors in your thinking and assumptions? If I have RC filter of -3db bandwidth on my accels of only 22 Hz, then PRIOR TO the ADC seeing the analog voltage from the accels, the high freq clock noise inside the accel is already absorbed in the RC filter.

Also, I made it really clear to be careful in how I explained my regression method. It does not induce delay the way a simple average would over the last N points. It instead is equivalent to taking the last 4 data points as a time trend then fitting a line through them and seeing where this line projects onto time "now". Not only is my method weighted towards the more recent points the result depends on the average slope of those 4 points against time, so it is a projection of the trend onto "now".

Also, the only sensor in my IMU with fast bandwidth are the gyros which are vibration immune and the main driving force to propagate the last state to current. I was really careful to highly RC dampen the accels to avoid vibration problems. These reasons are why I have a vibration-proof salt shaker IMU proven in small 3D foamies, and why airmcn_3 couldn't confuse my IMU in 3D foamy flight over 5 weeks of trying.

We can talk nuts and bolt and how people "think" I should be wrong, OR you can look at my videos and hear my description that I am able to integrate gyro rates for a full minute with only 1 degree of drift. My math is water tight and I am fully respecting the basic statistics within my sensors, ADC, and code filter.

Also, assumption of white Gaussian noise is pretty valid for the most part. It is more right than wrong. If I were short-sighted to use only +/-3g accels then there could be clipping of the accel distribution when it bumps near the sensor limit and consequent loss of Gaussian distribution. But I had the thought to use an +/- 11g accel to prevent this, and give possibility of using my IMU in 70 and 80 degree banking UAVs in the future (however this requires handling the G-induced shift in bias of the gyos, which isn't a small effect and not trivial to account for).