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?

Lew: I've visited your page a few times in the past (great resource), but till just this moment realize that was you:) I have spent many months working with various flavors of SPKF. I've coded them in C, C++ and partially in assembly seeking stability and performance. I even had a small three state running onboard the ARM at a low frequency. There just is not enough cycles available to do anything useful.

Currently a parameter estimation SRSPKF is at the heart of my sensor calibration software, without which I would not be able to achieve current performance levels. I also use the same estimators to tune all flight parameters via offline simulations. I think the SPKF technology can help with a large number of problems, even if it cannot yet be used onboard. We owe Rudolph van der Merwe a debt of gratitude for all of his hard work.

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

Join diydrones

Comments

Rana January 31, 2011 at 8:35pm

It is very very difficult to beat your design ! Superb !

Present Arducopter and UAVX would take long to come at par with yours.
Bill Nesbitt January 31, 2011 at 4:13pm

Lew: I've visited your page a few times in the past (great resource), but till just this moment realize that was you:) I have spent many months working with various flavors of SPKF. I've coded them in C, C++ and partially in assembly seeking stability and performance. I even had a small three state running onboard the ARM at a low frequency. There just is not enough cycles available to do anything useful.

Currently a parameter estimation SRSPKF is at the heart of my sensor calibration software, without which I would not be able to achieve current performance levels. I also use the same estimators to tune all flight parameters via offline simulations. I think the SPKF technology can help with a large number of problems, even if it cannot yet be used onboard. We owe Rudolph van der Merwe a debt of gratitude for all of his hard work.
Moderator

Roberto Navoni January 31, 2011 at 4:03pm

@Lew I need some help on i2c bus on STM32 can you help us :)
Lew Payne January 31, 2011 at 3:47pm

Bill, some SPKF info can be had in this thread, where you'll also find some MatLab code for the Schmidt-orthogonal (soukf) implementation as well, and an soukf without Eigen lib dependency, and a cholesky decomposition substituted for the square-root one. In this thread, I'm blabbering about the SPKF. In this thread, I get tired of arguing theoreticals (hence, the MatLab code that came out in other threads).

Being primarily an STM32 and TI TMS320 (Delfino w/floating-point as well as Da-Vinci DM64 series) user, I'd be happy to "climb on-board" your development team, if you're looking for help.
Moderator

Roberto Navoni January 31, 2011 at 2:55pm

@Bill

this is my design that use same of your micro ... if you want i can share my opensource managment with you ... do you have an a price of your configuration ?

http://www.virtualrobotix.com/forum/topics/multipilot-20-ap32-building

This is the old one : http://code.google.com/p/lnmultipilot10/wiki/multiboard that had your same form factor .. mk like ..

Regards

Roberto
Aurelio R. Ramos January 31, 2011 at 1:59pm

@Ruben: It's common to fill the empty space of the board on either side and attach the fill to ground and positive (back and front) or sometimes just ground. This provides shielding and also a low resistance / inductance path to keep all components from interfering with each other via the power traces.

@Bill: This is one sexy design please do start a blog or page where you can fill in the details of this board and share your progress, I think that would be great.

I particularly like the insane update rates. What freq are the PIDs on arducopter running at?

-Aurelio

-Aurelio
Jordy January 31, 2011 at 12:25pm

I just 'discovered' switching regulators as a replacement for LDO's a few weeks ago, it's good to know that you can (and probably should?) use LDO's behind them. I like how small the Recom is compared to a switching regulator + inductor + capacitors + schottky diode. Like how stable it is flies!
Bill Nesbitt January 31, 2011 at 11:18am

Ruben: The 6.5v DC/DC is used for two reasons. One, the pressure sensor is a 5v part and part of the low noise voltage rail. Secondly, this gives me a lot of room to add serial resistance and capacitance before each LDO to further reduce power supply noise.
Bill Nesbitt January 31, 2011 at 11:03am

Brian: Yes, using the mag vector will not work directly, but not due so much to environmental concerns. On quads, the varying magnetic field set up by the motors twists the earth's apparent field into a very ugly shape. Fortunately, I have found that that shape is predictable and can be calibrated out. Offline I estimate a complete 3x3 rotation matrix and a 3 value offset vector from actual flight data. Multiplied by the current throttle setting and main battery voltage level, it is applied to the mag readings resulting in a clean readings suitable for inclusion in the attitude filter. Indoors, where there may be more fields to deal with but the accelerations will be low, less reliance on the mags and more on the accs can be ordered up by tuning parameters (although I have not yet had to do this.)
T3

Brian Wolfe January 31, 2011 at 10:34am

Thanks Bill. I'm familiar with using the mag vector for attitude estimation other than just yaw, I've just been leary to rely on it because of the fear of local magnetic varience as the airframe moves around (clumps of iron, ground deposits ect..). Carefull fusing with accel data would be needed, but even then??? I guess that sort of experimentation is why we do this.

of 12

This reply was deleted.