It's been a while since I've posted an update on the progress of the AutoQuad flight controller.  The event that we've all been waiting for has arrived with ST Micro's announcement and subsequent release of their STM32F4 product line.  As expected, the micro-controller is pin for pin compatible with their STM32F2 series which the AQ v6.1 hardware was designed for.  This meant it was a drop-in replacement.  The most important new feature of the chip is the implementation of ARM's Cortex M4 core with a hardware FPU!  This means that we can now do floating point operations in a single clock cycle.  All forms of add / subtract / multiply / integer conversion, etc are single clock cycle instructions with the divide and square root instructions taking 14 cycles.  This is a significant step forward for math hungry applications like AutoQuad.

As soon as I could get my hands on one (around November I think) I had it on a board working to port my ground Unscented Kalman Filter code to fit into the 168MHz MCU.  With some optimizations, it ended up fitting with processing room to spare.  The current version leaves ~40% idle time during flight.  The filter is interesting because it brings all of the important estimated states and observations under a single mathematical model.  This means that each observation can influence any number of state estimates if there is determined to be co-variance between them.  The theoretical performance improvements over my old fixed gain techniques is high.  17 states and 16 process noise terms are estimated at 200Hz observed by 13 sensor measurements.

A benefit to using such a filter onboard is that it can adapt to changing variance of sensors and measurements on the fly.  This removes the need to do ground based flight calibration simulations which was a drawback to the original fixed gain methods.  Once you have a calibrated IMU, it can provide accurate state estimates "out of the box."  While this is nice, the biggest improvement is the accuracy of the state estimates it can produce.  States like 3D accelerometer bias and 3D rate gyro bias are critical to accurate attitude estimates which is the only way that you can propagate acceleration measurements through velocity and position estimates with any kind of accuracy.

Other than the upgrade of the MCU, the hardware is mostly unchanged from the original v6.1 layout.  However, there have been a lot of new features added to the firmware since last year.  What I call DVH (dynamic velocity hold) allows the pilot to control the craft's velocity in 3 dimensions while AQ handles everything else.  Let go of the sticks and the machine holds position.  AQ now speaks mavlink so it can be configured and controlled from any ground station that supports the protocol.  A comprehensive parameter set has been established that allows configuration of almost all aspects of operation.  Gimbal support and expanded mission capabilities have been added.  1-wire support for pre and post flight communications with ESC32.  Too many more to list here.

With the help of Max Levine I created this video to demonstrate the autonomous mission capabilities of the current firmware (version 6.6):

If you use the uBlox LEA-6T as the onboard GPS module, AQ can record raw satellite observations to its uSD card along with the normal flight log.  With this data and data from a local base station, you can use post RTK to get extremely accurate position and velocity estimates (~ centimeter accuracy.)  In fact, I use the RTK velocity estimates as an absolute data point in scoring the filter's performance in the ground simulations used to tune the variance and noise parameters used by the UKF.  Future work might include onboard RTK calculations using a linux based application processor mounted on a daughter board.  This would bring the system's performance to an entirely new level.

Here is what the actual flight path looked like of the flight shown in the above video using post processed RTK:

I need to thank the small group of people who have worked very hard to test, write utility software and interfaces, create documentation and generally improve the AQ  platform.  It is still very far from a finished, polished flight controller, but it has come a long way because of their help.

As with ESC32, I have decided to release the AutoQuad FC firmware under an open source license.  It can be found at:

http://code.google.com/p/autoquad/

I would also like to invite anyone interested to participate in a public beta test of the system.   Sensor calibration, setup and configuration is still a lengthy and sometimes tedious process so I would discourage anyone who thinks they can bolt the board to a frame and start flying as that is not at all what you should expect.  I have authorized manufacture and sale by ViaCopter and Flyduino who are taking orders in a few days.

I wanted to bring everyone up to date on where the ESC32 development is at this point.  After a lot of testing of the version 1 design, we found that operating under high current situations, current spikes caused by commutation were introducing a lot of noise on the digital side of things.  In the worse cases, this could lead to clocking issues causing the MCU to reset or worse, lock up.  Of course if that happens you will likely cook a motor.

So, back to the drawing board (CAD actually).  After a lot of trial and error, I came up with the version 2 design.  It manages to keep the high current paths much shorter and thicker as well as keeping the analog and digital ground planes completely separate.  This new approach is now working quite well with as much current as the FETs will handle.  I took this re-design opportunity to add CAN Bus support with an optional CAN transceiver chip onboard.  Additionally an external shunt resistor was added to improve the accuracy of current measurements over the original internal PCB trace shunt.  All of this without loosing any prior interfaces or functionality.

During the same time a lot of work went into improving the firmware's operation and adding new features.

The CLI has been expanded and gives you access to all tunable parameters via the UART port.  There is also a binary protocol for high speed machine to machine communications up to 921600 baud.  And now Dallas Semiconductor's 1-wire protocol is supported over the PWM IN port.  This means that the flight controller can bi-directionally communicate with the ESC over the existing PWM IN lines.  This can be useful for setting run modes and parameters pre-flight or downloading operational data post-flight.  Anytime the ESC is not in the run state, communications can take place.  There is a future opportunity to allow firmware updates over the 1-wire protocol as well.

Closed loop RPM mode has been implemented.  The idea is that the throttle maps to RPM directly in a linear fashion and the ESC works to achieve and maintain the requested RPM with a closed loop controller onboard running at 1KHz.  The ESC utilizes a feed forward augmented PI controller to get you to the requested set point as quickly as possible but still remaining within the set current limit.  There is also an experimental regenerative braking feature which takes excess motor speed and turns it into current flowing back into the battery.  Closed loop mode can be very useful when implementing advanced predictive attitude controllers on the FC which will require consistent, predictable performance from the motors.

Another interesting feature is what I call the virtual current limiter.  The problem with a lot of hobby ESCs is that they have to be careful of how much current they allow the motor to draw during acceleration events.  Most of them use some sort of throttle filtering or smoothing to limit the throttle increases allowed at each time step.  The amount of current drawn by the motor depends on the motor's size, RPM and prop load which is not known by the ESC and most do not have a current sensor.  Since there is no way to know how much is too much, they have to settle on a conservative approach to avoid frying motors or FETs.  This will ultimately limit the throttle response to something less than optimal and for multi-rotors, this is undesirable.

My solution to this problem was to give the user a way to profile the motor and prop being used on the bench.  This data can also be looked up from a database that is being compiled of known motor/prop configurations.  With this information, the onboard current limiter can pre-calculate how much current a given throttle (voltage) request will take at the current RPM, and if it would result in an over current situation, the implemented throttle request is trimmed to fit under the limit.  As the motor speeds up, the current demand drops even if the requested throttle has not changed so the limit is re-evaluated at 1KHz trying to give the maximum amount of acceleration possible with the given restrictions.  The results are the fastest throttle response possible while staying under the set current limit.  Finally, if the profiling parameters have not yet been set, a regular PI controller is used to limit current.  It is still better than throttle filtering methods, but not as good as the virtual current limiter as it is a reactionary strategy.

There are now also a lot of tunable parameters which allow the ESC to be used for non-standard applications.  For instance, if you are using PWM IN for control, you can design custom parameters for the pulse width and waveform period.  Current limits, start voltages, PWM output frequency many other settings can be made from the CLI, binary or 1-wire interfaces and stored in flash memory for future power ups.

I'm sure the first question will be how much current can they handle.  The truth is I don't really know.  According to their data sheet, the FETs are capable of 160A continuous.  As a practical matter, there is no way you could come close to dissipating the amount of heat that would be generated at those levels.  With large heat sinks you could probably run them over 50A continuous, but without any heat sinks the limit will be significantly less.  In the end, the limiting factor is simply cooling.  If you can get them into some prop wash or rig some sort of small heat sink your results will improve.  I've been flying them for for more than 6 months with no heat sink at all, but my machines typically weigh less than 3Kg.  As we get more test data in we will be better able to characterize the actual limits.

I'd like to thank all of the people who have helped test and even blown up motors to make this ESC possible.

ESC32 v2 specifications and features:

- STM32F103 72MHz 32bit ARM

- All N-FET design with gate drivers

- 2S through 5S battery voltage

- Option to power logic side via UART or PWM IN +5v

- CAN transceiver hardware support onboard

- Firmware written completely in C

- ARM Cortex SWD connector pads for real-time debugging

- Communications ports: PWM IN / UART / I2C / CAN Bus

- Communications protocols: PWM IN / CLI / binary / 1-wire / I2C** / CAN**

- 4KHz to 64KHz PWM out

- Current sensing / limiting with real shunt resistor

- Closed loop control modes

- Virtual current limiter

- Regenerative braking (experimental)

- Lot of available RAM / FLASH for experimentation and development

* rendering by Max Levine

** I2C and CAN drivers have not yet been written

Finally I have decided to release the source code under an open source license.  Hopefully talented individuals will be able to help design new features and functions that everyone can use:

http://code.google.com/p/esc32/

Recently the Chinese ESC design utilizing the ATMEGA which we have been flashing with Bernard Konze's firmware has been disappearing from the market.  This was the push I needed to finally decide to design and build a replacement.  Collaborating with a friend, we worked on it over the summer.  It is finished and I think it came out pretty well.  I call it ESC32:

Design goals:

- Extremely fast implementation of requested throttle setting

- Ability to take high rate input

- Multiple input protocols

- Ease of programming, real-time debugging

- Efficient

- Inexpensive

The final specifications read:

- STM32F103 72Mhz MCU - 32bit ARM

- Firmware written in straight C

- SWD connector for real-time debugging

- Input via PWM IN / UART / I2C

- 1KHz PWM update rate capable

- All N-FET design with gate drivers

- At least 40A continuous with proper cooling, maybe much more

- 2S => 5S battery

- Option to power logic side via UART or PWM IN +5v

- Command Line Interface for testing / parameter modification / back channel

- 8KHz => 64KHz PWM out

- Current sensing / limiting

- Regenerative braking capable

- Closed loop control mode - experimental

- Lots of RAM and CPU cycles available for advanced control techniques

- BOM cost < $20 at quantity

* image courtesy of TC Pictures, LLC.

It is a drop-in replacement for the ESC's that I have been running with AutoQuad and will take standard PWM input up to 450Hz.  I will eventually design new high rate PWM timing which will bring this rate up to 1KHz.  It is a definite improvement over the ATMEGA design.  Your flight controller can ask for large, quick changes in throttle and it is able to implement them very fast.  This allows PID output to be tuned to be more aggressive and results in much smoother control.

Start ups are very smooth and I have not yet found a motor it could not start.  It uses oversampling techniques which allow it to accurately control a BLDC motor down to 200RPM.  Early indications based on some initial head to head testing with other ESC's show the it is very power efficient.  This comes from the fast switching of the N-FETs due to the use of gate drivers.  Less time is spent in the on-off / off-on transitions, so less power is used, less heat generated.  No special heat sinks or cooling should be necessary for typical 10 to 20 amp usage.  This also means that you can use higher PWM output rates without too much of a hit to efficiency.

* image courtesy of TC Pictures, LLC.

As the ESC is an extremely important component of multi-rotor UAV's, it is critical that it keeps running, no matter what.  So you can imagine the amount of testing necessary before you can start to trust a new design with your expensive machine.  There are a handful of people flying the ESC32 now and I myself have perhaps 10 hours without incident so far.  There may still be problems, but I am fairly confident that it is trustworthy.  It's all I fly now.

For those following this saga, version 6.1 of the AutoQuad board is complete and has passed initial testing.  I have taken the 5.0 design and added features that should make it more flexible and expandable while increasing performance.  Here is a summary of specifications:

Hardware:

- 2" x 2.5" main board with MK mounting hole pattern

- Input voltage: 6.5v => 18v

- High efficiency DC/DC converters

- STM32F215 32bit Cortex M3 microcontroller @ 120Mhz (1MB flash)

- Standard Arm 10 pin 0.05" pitch SWD connector

- 14 general purpose PWM controllers / receivers (powered or un-powered)

- Dedicated Spektrum satellite (remote receiver) 2.4Ghz R/C radio connector

- uSD card slot driven by 4bit SDIO capable of 100Mb/s transfer (up to 32GB storage)

- optional onboard uBlox LEA-XX GPS module with battery backup and timepulse capture

- optional u.FL active GPS antenna connector

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

- optional external bi-directional telemetry radio via standard 6 pin FTDI connector - powered up to 1A

- I2C bus connector for I2C ESC's (or other I2C devices)

- onboard IMU options:

+ optional 9 DOF analog sensors (3x RATE, 3x ACC, 3x MAG) w/EMI hardening

+ optional VectorNav VN100

- daughter board options:

+ 9 DOF analog sensor board

+ VectorNav VN100

+ High performance SOM (Sytem on Module)

+ Any combination of the above

- Two barometric pressure sensors

- Battery voltage monitor

Software:

- Fully threaded RTOS design written in C -  75% idle in flight

- All (15) analog sensors read up to a rate of 276.8KHz (~4.2M sps total)

- 100Hz => 800Hz PWM motor update rate (requires custom ESC's at rates >450Hz)

- 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

- MavLink protocol support

- Cascading PID control system, velocity based for smooth transitions

- Auto land / takeoff

- Hover position / altitude hold

- Autonomous waypoint mission navigation

- Precise altitude hold indoors

What I call the general purpose PWM controllers are 14 connectors which can be used for PWM (or any other digital) signaling.  Each one can be optionally unpowered or powered with 5.0v or 6.5v (depending on the RECOM part used.)  Since each port is connected to a dedicated timer line on the uController they can be used for input or output. This means you can have any combination of motors / servos / acoustic range finders / LED's, etc. that you can image with power up to ~1.2A.  With the input capture capability, you could also use them to connect a traditional multi-channel R/C receiver.

I have included two pressure sensors (2nd one optional) so that fixed wing users can monitor airspeed.  Or, you could use one as a failover or combine the two to get smoother altitude measurements.

There is a lot of flexibility when it comes to the IMU.  First there is the option of using the onboard analog sensors:

+ 3 axis acc (ADXL335)

+ 3 axis mag (HMC6042 & HMC1041Z)

+ 3 axis gyro (IDG500 & ISZ500)

+ 3 temperature sensors

These must be calibrated by the user which can take a lot of time and aggravation. For the person who would rather pay someone to handle this calibration for them, a VectorNav VN100 can be soldered directly to the main board and used as an IMU.

With the 2x20 pin connectors a daughter board can be connected which can accommodate an analog or digital IMU as well.  In fact, you could have combinations of onboard and external IMUs used simultaneously for failover or co-witness configurations.  Since these connectors contain many analog and multiple high speed digital communications channels, a SoM can be connected such as a GumStix Overo with a 720Mhz Arm Coretex A8 processor with Vector Floating Point hardware running Linux with gobs of RAM and flash storage and optional bluetooth and WiFi radios.  This will allow easy experimentation with complex navigation filtering and the exploration of vision based navigation algorithms.

Here is a picture of an external VN100 attached as a second IMU:

I have received a lot of positive feedback on my past designs as well as a lot of requests for hardware that I could not fulfill so I have decided to try to find ways to make this board available to those who want to build a machine around it.  I can't say exactly when, but I hope to be able to announce hardware availability through various sources in the not too distant future.

The distributors finally got in some of the new ST Micro STM32F2 series uControllers and I grabbed a few.  I was able to "shoehorn" one into a ver5 board as the pinout is close to compatible with the performance STM32F1 series.  Spent a few days rewriting the device drivers and am very impressed with this controller's performance.

I was able to bump up the sample rate to around 276.8KHz for all 12 sensors for a total of ~3.32 million samples per second.  Despite this more than doubling of work load, I ended up with around 70% idle time, up from 60% of the STM32F1.  Keep in mind that at a 120MHz clock rate, this 70% free cycles represents more than twice as much free number crunching capability than the STM32F1 at 60% idle.  I also found that the DMA to be much better with full FIFO available on each DMA channel and an easier to use triple ADC.

The result is a much cleaner interpretation of the sensor data which translates to a smoother and more stable platform.

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?