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?
Comments
Brian: "I know exactly what you mean.", Morpheus :) I think the problem is that the velocity errors show up for more reasons than true acc bias. Other than GPS measurement noise, the largest is probably attitude estimation error.
Until one can estimate the attitude error (which if you could do that, you could simply correct the error) you have to lump all *apparent* biases into a single bucket. I chose to store them in the body frame as they most certainly are at least partially composed of true acc bias. But definitely do not try to use them as correction terms to acc inputs to your attitude filter - as you experienced.
The better solution is to have a filter which can separate the apparent bias into its true components and apply them appropriately - some of it will be body=>world rotation errors. I have had success in doing this offline in simulation with a SRCDKF (Square Root Central Difference Kalman Filter) as this is a non-linear problem. Of course the problem is that we cannot yet run a filter of this complexity onboard. Research is ongoing, but meanwhile we have a solution which works reasonably well.
Brian,
When you say "accelerometer bias", are you referring to a semi-constant bias (as might be found in the sensor's data sheet) or do you mean an offset of the sensor location from the c.g.? Or is it the "bias" of trying to compute the gravity vector itself (since the accel does not measure gravity)?
- Roy
Let me see if I understand you correctly. I think you're running a fixed gain "observer" on the quad. Your ground-based "simulation" is essentially the SRUKF which you are running with the data you collected in flight. But the KF is so computationally expensive that it takes a while to run, even on a PC. You are looking into using graphics chips and libraries to speed things up. I think these libraries have quaternion routines, right? In any case, the KF eventually converges, and you either take the converged gains (Ki?) or the converged parameters (xi?) and put those "constants" into your onboard observer. Is that basically correct?
- Roy
@Pete,
I think the following schemes for determining gains based on flight data look promising:
Fictitious Reference Iterative Tuning (FRIT)
Virtual Reference Feedback Tuning (VRFT)
Iterative feedback tuning (IFT)
Once I get my quad coded and built and flying, I would like to turn my attention to the auto-tuning problem. The other solution is on-line adaptive control, which I believe Bill's board has enough overhead to accomplish. My 8-bit AVR probably won't have the horsepower for that.
- Roy
Hey Bill,
Great stuff! I use a similar arrangement in my autopilot, but found that if I attribute the velocity errors to accelerometer bias and correct for it I get a low level oscillation whereby the velocity errors cause a change in accelerometer values which then cause an attitude estimation change because the accels (Gravity Vector) is used as a correction term for the gyro bias. This then causes a change in the velocity term etc...
I finally had to decouple them by keeping track of the velocity correction terms and applying them to the velocity estimation, but not apply them to the accels. I still assume the major velocity errors are caused by accel bias so I maintain these correction terms in body coordinates so they basically track with a given accelerometer.
It seems to be working OK, but boy I would sure like to apply the correction to the accels to improve their readings. The other assumption I'm making at the moment is that all the error is caused by offset error and not by a gain error.
Hope that makes sense.
Regards,
B
Hi Bill,
Your project looks amazing. I had one question about your inertial sensor. How do you calculate body velocity? Do you integrate accelerometer data, update coordinates and then correct with the GPS?
Also, sorry if this has been asked before, but for your runtime filters what flavour of KF do you use?
Cheers,
Nima
So it not for aliasing but more for better precision. Not possible with my current setup. I thought 16bits would be high enough.
I hope for some more detailed info on your IMU very interesting, and nice learning material.
so you sample the sensors at such a high rate to get rid of the aliasing and to get a mean of zero. That is understanable. But you have an analog filter of 20Hz if i'm correct so sampling at 200Hz would be enough according to nyquist.
My sensors work at a freqency of 1kHz with internal filters of 256Hz, my atitude and PID all work on +500Hz.
-
5
-
6
-
7
-
8
-
9
of 12 Next