AutoQuad ver 5

I know, the world probably has enough flying machine projects, but here is yet another one. AutoQuad's original design goal was high precision autonomous flight. It took five prototypes before I was happy with the hardware. The current prototype, AQv5, is showing very promising results. In fact, there is little left to do before this first goal can be checked off the list. Using this as a solid base, I intend to continue research, design and experimentation toward vision based navigation for indoor and outdoor use.

Hardware:

- 2" x 2" board with same mounting pattern as the MK FC

- Input voltage ~7.5v => 18v

- High efficiency DC/DC converters

- STM32F103 32bit Cortex M3 microcontroller @72 MHZ

- standard ARM 20 pin JTAG header for real-time debugging

- up to 8 PWM ESC motor control (prefer Turnigy ESC's with custom firmware)

- 2 powered payload servo controllers

- optional ultra sonic range finder

- Spektrum satellite (remote receiver) 2.4Ghz RC radio

- uSD card slot

- optional onboard uBlox LEA-XX module w/battery backup & timepulse capture

- optional female SMA connector for active GPS antenna

- optional external GPS via standard 6 pin connector (EM406, EM401, uBlox, MTK)

- optional onboard xBee module - up to 300mA (2.4Ghz, 900Mhz, bluetooth, etc.)

- optional external radio via standard 6 pin FTDI connector - up to 1A

- I2C bus connector for I2C ESC's

- modular sensor board (SBv5) - 100% analog sensors, EMI hardening:

+ 3 axis acc (ADXL335)

+ 3 axis mag (HMC6042 & HMC1041Z)

+ 3 axis gyro (IDG500 & ISZ500)

+ 2 temperature sensors

+ pressure sensor (MPXH6101A)

+ battery voltage

Software:

- Fully threaded RTOS design written in C - 60% idle

- All sensors read at 113KHz (~1.4M sps total)

- 450Hz motor update rate

- 200Hz attitude, 3D velocity / position solutions

- Full downlink telemetry

- Detailed system state dumps @200Hz => uSD card w/FAT32 FS

- Quaternion based attitude filter additionally producing rotation matrix and Euler angle outputs

- All math in single precision floating point

- Temperature compensated and calibrated sensor suite

- Custom ground station software w/bi-directional command and control API

- Cascading PID control system, velocity based for smooth transitions

- Auto land / takeoff

- Hover position / altitude hold

- Autonomous waypoint mission navigation

- Precise altitude hold indoors

Example of current capabilities:

Design philosophy:

- High performance

- Efficiency

- Ease of development

- Consistency / Repeatability

- Low cost

There is always room for improvement. For instance, I would like to see how much of a benefit using a SPKF (Sigma Point Kalman Filter) would be over my fixed gain navigation filter. Looking forward to the new Cortex M4 uC's with a hardware FPU so that any such math intensive solution can be more easily handled. As I mentioned above, there is a lot of room for work with vision navigation and SLAM. Also interested in propulsion efficiencies which with an eye toward higher endurance. Although the PID based control system works extremely well, I'm interested in exploring different types of MPC (model predictive control) to reduce control costs and increase precision.

I'm wondering if there is anyone interested in joining forces to work on some of the above mentioned or anything else along these lines that presents itself. This is only a hobby for me and I currently have no profit motive. This is definitely not a beginner's project as you can see by my sloppy SMD hand soldering job.

Comments?

Wow! This is truly impressive work! I'm often impressed with what people are able to achieve on their own, often outdoing what teams of lesser mortals (like myself) are able to do. I'm trying to work in your direction, but as a self taught programmer/engeneer/etc. I still have a long way to go. (My background in Psychology doesn't help with the math, physics, electronics, and software development stuff as much as I'd like)

In my playing with MK, ArduCopter, and KKMulticopter boards, and reading up on how they pretty much all use PID control, I couldn't help but think that there were better solutions, it looks like you're thinking of moving away from those, so I'm very interested in seeing how it goes. I like your integration of the various sensors and your methodical, mathmatical approach to design. I also intuitively feel that self tuning aircraft should be possible and would be a great improvement. It's really impressive work.

I don't think I'm quite to the point where I could be much help, but I'd love to help in any way possible. Next time you print up a batch of PCBs, maybe make some extras. I can handle assembly and programming. If you sell these, I'll buy one.

If you don't mind my asking, how did you come to develop your expertise in this area? Previous work or schooling, or are you self taught? Any resources for someone who's eager to follow?

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Michael Colton February 3, 2011 at 7:32am

Wow! This is truly impressive work! I'm often impressed with what people are able to achieve on their own, often outdoing what teams of lesser mortals (like myself) are able to do. I'm trying to work in your direction, but as a self taught programmer/engeneer/etc. I still have a long way to go. (My background in Psychology doesn't help with the math, physics, electronics, and software development stuff as much as I'd like)

In my playing with MK, ArduCopter, and KKMulticopter boards, and reading up on how they pretty much all use PID control, I couldn't help but think that there were better solutions, it looks like you're thinking of moving away from those, so I'm very interested in seeing how it goes. I like your integration of the various sensors and your methodical, mathmatical approach to design. I also intuitively feel that self tuning aircraft should be possible and would be a great improvement. It's really impressive work.

I don't think I'm quite to the point where I could be much help, but I'd love to help in any way possible. Next time you print up a batch of PCBs, maybe make some extras. I can handle assembly and programming. If you sell these, I'll buy one.

If you don't mind my asking, how did you come to develop your expertise in this area? Previous work or schooling, or are you self taught? Any resources for someone who's eager to follow?
Bill Nesbitt February 3, 2011 at 7:27am

Ruben:

Vdda is the analog voltage supply for the ADC on the uC. Look at the GPS's regulators datasheet to get exact power dissipation numbers, but it is not as high as you calculated. The current limiting resistors before noise sensitive power systems are used to increase the input capacitor's effectiveness (RC). The Xbee is a very noisy device constantly surging current as it switches on/off its transmitter and did not think it would be useful there.

As this is an experimental board, I went overboard on a lot of the design. If certain elements are determined to be superfluous, they can be omitted during build or removed from future designs. For example, I'm fairly sure not all of the power supply redundancies are not 100% needed. In the past, I've been trapped wishing I had given myself more options during initial design.
Bill Nesbitt February 3, 2011 at 7:10am

Jeroen: I've considered an external ADC, but there are drawbacks:

- Extra part (space / cost)

- Digital communications overhead - possibly higher than using uC ADC

- Lack of flexibility on sampling scheme and timing

I'm not sure if I can think of an pros I can list to offset the cons.
Bill Nesbitt February 3, 2011 at 7:04am

Flemming: Don't know. Possibly. Anyone who is interested enough to need a board to attempt a build should probably contact me.
Jordy February 3, 2011 at 1:22am

Thanks for posting the design, will be learning a lot from it! Using a "port" in the schematic is new for me, looks useful (and available in Eagle Cad). Of course some questions:

- What is +Vdda used for, or is it just a spare source?

- Is it true that (for example) the internal GPS VDO is still (when in full use) dissipating (6.5-3.3)*0.150=0.48W? Or is the resistor R23 somehow limiting this, also, why are you not using the same construction for Xbee regulator?

Sorry for such basic questions compared to the discussion about all the mathematics.
Jeroen van de Mortel February 3, 2011 at 12:32am

Thanks for the schematics. I do have a question you now sample at 113kHz and down scale it to 200Hz that is like 6bits extra ? wouldn't it be much better to get a higher resolution ADC like 22bits also with a high sample rate.
Flemming Frandsen February 3, 2011 at 12:14am

Cool with some hints about how it's done, jpegs aren't going to be very easy to build on, so will the actual source files that can be edited with a cad package be released?
Bill Nesbitt February 2, 2011 at 4:51pm

For anyone who's interested, schematics and BOM are available at:

http://code.google.com/p/autoquad/
eduardo February 2, 2011 at 2:11pm

this is a real super stable code.

the arducopter and some other based on the same code fly too poor ! toons of wooble.

i want one.
Bill Nesbitt February 2, 2011 at 7:46am

Roy: Not exactly. The simulation is a replica of the onboard code. Given sensor raw voltage readings recorded from an actual flight it computes the exact same estimates of states. Now if you change a runtime parameter (like the amount of GPS error to apply to the position state) the simulation will show what impact that has on the calculated solutions over the whole flight and can be scored. That simulation is wrapped in a parameter estimation filter (SRUKF) which simultaneously tries to find values for a few dozen such parameters which tend to make the solution "better." Turns out that half the battle is defining what "better" is as you don't actually know what the true states where at the time, but that's another conversation.

of 12

This reply was deleted.