Discussion AttoPilot V3.0 6DOF IMU Q&A

[dmgoedde]

Originally Posted by ios

So given the AttoAHRS is a stand alone product, can it be interfaced with the existing Atto1.8 as an alternative to the thermopiles?

The 6 DOF AHRS cube interfaces with the outside world using logic, not analog. This is a 2-way communication as well; airspeed data is fed into the cube to properly handle centrifugal effects on the accels. There is no good way to interface this with the Atto V1.8 control board unless I did something like sacrifice the Pan and Tilt servo control pins to be that 2-way COM link. Right now Pan/Tilt aren't activated anyway so it could be done. Problem for export people is I cannot e-mail or otherwise send firmware updates without proper export licenses, so you would have to ship the V1.8 control board back to me in the US for the simple firmware update (BTW, I DON'T necessarily agree with or like the US Export laws).

When I wrote this would be a stand alone product, I mean more for persons that want to interface it with their own project just like the other AHRS units already on the market.

Zlite: will your ArduAHRS feed all 3 analog channels for complete 3-axis thermopile systems, per the equations I wrote out on your ardu AHRS thread? If it only emulates XY analog (2 channel) then it will be incomplete for use with an Atto V1.8, and won't work. Will it also be adjustable for use with 3.3V ADCs (like I showed equations for how to do) or be stuck emulating 5V ADC?

[bcuervo]

Chris(airmcn 3),
I think saabguyspg was referring to Chris Anderson's comment: not any comment you made.

[clolson]

Hi Dean,

Will your AHRS cube dump out raw sensor data in addition to your internally computed AHRS solution?

Thanks,

Curt.

[ios]

Given no one is using the pan/tilt servo pins, I'm sure it won't be missed, and I don't think people would mind send thier units back for an 'upgrade'. Plus, some people might want to upgrade if they don't need a second Attopilot. Just an Idea...

[zlite]

Originally Posted by saabguyspg

so chris are you saying we could use the adruAHS in place of our thermal piles on our atto 1.8?

Just to be clear, I'm talking about ArduAHRS, not AttoAHRS. We do intend to make it a plug replacement for the thermopiles for Atto1.8, but we haven't tested that yet, so no promises.

[CenTexFlyer]

Originally Posted by zlite

I don't want to hijack the thread, but we are developing a thermopile-relacement AHRS based on ArduIMU (which we should rename ArduAHRS!) over at DIY Drones.

Apples to oranges Anderson. A hijack it was........

[airmcn_3]

Originally Posted by ios

Given no one is using the pan/tilt servo pins, I'm sure it won't be missed, and I don't think people would mind or be suprised in needing to send thier units back for an 'upgrade' - as this is also an export condition as well. Plus, some people might want to upgrade if they don't need a second Attopilot.

Maybe a logical way to price an upgrade would be $Atto1.8+$AttoAHRS>$AttoIMU, this way the two products don't compete against each other, but still leaves an option to v1.8 users and accounts for development and upgrade costs.

I'm also unsure if using an arduAHRS would breach the export conditions, and in any case I don't intend to transition to Ardu any time soon - and will definitely purchase the AttoIMU.

Nick,

I will talk with Dean and the Directors. We have talked about this a lot and the conclusion is completely different products. We do not want to scrape something together.

The IMU is not the export item the control board is. I do not believe there will be any issues with arduAHRS and export as the individual will have already completed the export paperwork for the control board.

Chris

[dmgoedde]

The Atto IMU Cube wouldn't be an inexpensive upgrade to the V1.8. Analog Devices sells a similar 6 DOF sensor cube of nearly identical size. For $700 this 1" cube has +/- 300 deg sec gyros, +/- 10G accels, temp compensation for gyro bias (but not nearly as tight as my unit's specs) and corrections for inter axis mis alignment. It is only a sensor unit with some compensations, but no attitude solution, doesn't have centrifugal force corrections (a really good idea if you want an IMU to work in real aircraft versus a generic IMU YouTube demo playing to graphics on a display). It also doesn't have the Nth degree of other corrections I employ such as bias and scale factor corrections for the accels. Accel drift with temperature is not a giant effect, but is significant enough to worry about and more importantly is something that can be done and has a very positive affect on final results. Then there are minor wrinkles like compensation for clock crystal change with temperature. It's also not clear to me the Analog Devices 6 DOF cube would actually work at the bottom of temp spec where condensation might form on sensitive internal components.

Just like the V1.8, my aim is ALWAYS to make tons of useful sophistication that removes barriers in use. Every crazy correction in the IMU has a purpose born from very extensive testing. The kind of testing where I find the ultimate breakdown limits then plug the holes. This is why I appear to be slow releasing products, and not abuse customers by selling something that is still in a Beta state. Once I sell something you can be sure no gross issues remain to be found.

So, given that a huge company like Analog Devices (which is in the commodity business) sells a 6 DOF sensor cube with minimal corrections and no attitude solution for $700, and mine takes their type of design to the Nth degree higher, my AHRS price will be nowhere near $700. It will be more like 2-3X of their price in single unit Qty. My version of an IMU is brute force in every aspect (using large accel range, large gyro range, ultra fast computations with an overkill of computing power in a multi-core 32 bit processor, hermietic sealing, full mil spec temp range of use, etc...).

I am NOT worried at all about making an inexpensive entry level IMU autopilot. I never consider component costs or development costs restrictions. I also don't care one wit about having to use expensive and precise calibration jigs at "the factory" and calibrate each IMU individually with approx 24 hours of data collection time. My only aim is to make an IMU to work in real UAVs under the worst conditions of vibration, temperature, tolerance of complex flight maneuvers, and track attitude through fast manuevers. I also aim to do this at a price that beats the now current commercial autopilots, but not to the extent that I can't make back money spent on development.

My IMU is perhaps not the best choice for those wishing to get their feet wet for the first time. I am referring to weekend warriors in their repurposed RC toy aiplane made from foam and tons of airframe dynamic stability so a beginner can learn the basics on a rudder/elevator situation (EasyStar). My clients tend to already have extensive experience with the other well known IMU autopilots, and have given me strong feedback over the last 12+ months that they don't like X, Y, or Z about their current units. Cost is not always their main dislike of other systems. It is usually attitude accuracy in flight*, or vibration sensitivity, or finally they say "IMU autopilot brand X FREAKS OUT and loses it if attitude gets beyond level and dips partially into inverted flight for whatever reason". All of these issues have root causes, and I addressed and fixed those root causes. Cost of development or materials or using all flat sensors so the PCB is flat were never driving concerns of mine. My customers that do commercial UAV work also tend to understand that foamies and Telemasters are not the best choice (by and large) for serious work. We tend to agree strongly that a day with 30 knot winds should NOT ground small UAVs. This why I would marry a flying wing if it were legal in Arizona. I love them with all my heart.


*(thermopiles actually can usually beat the crap out of any IMU the way I implemented them in the V1.8 so some people have gotten spoiled if they tried a V1.8 and we got their UAV tuned up to max potential)

[zlite]

Originally Posted by CenTexFlyer

Apples to oranges Anderson.

Care to explain yourself? I was responding to a request with a solution. Since nobody outside our beta group has seen this product, I'm confused by why you think you're expert enough to comment on it.

[dmgoedde]

Originally Posted by clolson

Hi Dean,

Will your AHRS cube dump out raw sensor data in addition to your internally computed AHRS solution?

Thanks,

Curt.

Hi Curt. The AHRS cube sold as stand-alone will have copious user-configurability for data output rate, baud rate, data mode type, and types of data sent out. The same IMU cube sold with an Atto is really just identical, but the Atto control unit will expect only a certain standard setup with the IMU cube. The 'standard' AttoPilot setup will be something like airspeed and airspeed acceleration data is sent into the unit via serial UART at 115.2 kbauad, and it will spit out at 50 Hz in serial ASCII the following data: pitch and roll to the 2nd decimal, pitch roll and yaw rates to the 2nd decimal in deg/second, and finally Earth-centric dHeat/dt in deg/second to the 2nd decimal.

You will be able to configure it to get raw sensor data, however I don't plan to make available (but might) truely raw data as in gyro data without the inter-axis alignments applied, or Accel data without the temp-dependant scaling factor corrections. What you would get is 100% clean 'raw' data.

Consider this device as a clean base level to provide data for your own custom IMU filter, but mostly I see it as one of a few available AHRS with centrifugal corrections in a simple 6 DOF sensor suite that will simplify people making IMU autopilots with their own control boards when they don't want to wade through the mess of making their own IMU filter. It should be to IMU autopilots what the FMA sensors were to countless groups. I stress that this is intended for fixed wing aircraft because it handles centrifugal corrections. You simply have to feed it airspeed data. It would be great for static uses, but has the required complexity built in for real flying usage.

[saabguyspg]

Originally Posted by bcuervo

Chris(airmcn 3),
I think saabguyspg was referring to Chris Anderson's comment: not any comment you made.

this is correct my comment was directed at chris... I figure if he was posting here it would be because he had a solutinon to something ATTO related and it seems like he may have something in the future.

[carguy84]

Have you tried snap rolling with the IMU? I think that's about the most violent maneuver I can think of.

[mentari]

Originally Posted by airmcn_3

Nick,

I will talk with Dean and the Directors. We have talked about this a lot and the conclusion is completely different products. We do not want to scrape something together.

The IMU is not the export item the control board is. I do not believe there will be any issues with arduAHRS and export as the individual will have already completed the export paperwork for the control board.

Chris

Would you be allowed to export the IMU then to South Africa and no control board, SA don't have ITAR clearance for a full control board. If so can the Bill Permalani code be used with such an IMU, all vibration issues taken care off etc, yet needing significant integration for a final product.

[CenTexFlyer]

Originally Posted by zlite

I'm confused

Enlightenment sent via PM

[airmcn_3]

Originally Posted by mentari

Would you be allowed to export the IMU then to South Africa and no control board, SA don't have ITAR clearance for a full control board. If so can the Bill Permalani code be used with such an IMU, all vibration issues taken care off etc, yet needing significant integration for a final product.

I will check into it to be sure but I do believe the IMU cube is not export controlled.