AutoQuad Flight Control Firmware
This is a fork/continuation of Bill Nesbitt's AutoQuad firmware for multicopter flight control.
- AutoQuad Project Site
- AutoQuad Documetation
- AutoQuad Forums
- AutoQuad Downloads Page
- AutoQuad Public FTP: ftp://ftp.autoquad.org/3/334693_22529/
USE AT YOUR OWN RISK!!! ABSOLUTELY NO RESPONSOBILITY IS ASSUMED BY THE AUTHORS OR PUBLISHERS OF THIS FIRMWARE. SEE LICENSE FILE FOR FULL TERMS.
masterbranch is current stable version.
nextbranch is to integrate all proposed changes for holistic testing before being committed to
- Numbered branches (eg.
6.8) are for older versions.
- All other branches are "feature" branches used for testing individual changes before integration into
Pull requests should typically be submitted against the
next branch, unless it is an important fix for something which affects
master as well, or some other similarly good reason.
Pre-compiled firmware versions can be found at the AutoQuad public FTP site: ftp://ftp.autoquad.org/3/334693_22529/aq-firmware/forks/mpaperno/aq_flight_control/. The structure is organized by repository branch and then hardware version.
Getting The Source Code
If you already have a Git client installed (or are willing to learn), the easiest method is to clone this repository to your local machine. If you do not want to deal with Git, you may also download zip archives of the necessary projects.
Repository Checkout & Submodule Init/Update
This repository contains Git submodules (for MAVLink headers) which must be initialized and updated. This is a simple process but you will get compile errors if you don't do it.
If you use a GUI Git client (TortoiseGit, SourceTree, etc) then look for options such as recursive during cloning and commands like "Update Submodules". This is usually an option when (or after) you do a clone/checkout command. Refer to the program's help if necessary. After checking out the code, make sure the
lib/mavlink/include folder exists.
It is also very easy to use the command line for clone, update, and checkout.
Here's a complete example starting with fresh copy of the repo, then checking out the
next branch, and the submodule init:
git clone https://github.com/mpaperno/aq_flight_control.git cd aq_flight_control git checkout next git submodule update --init
If you already have a clone of the repo and you only want to do a pull of the latest changes, run something like this (example uses the
master branch and assumes "origin" for the remote name of this GitHub repo, which is a typical default):
git checkout master git pull --recurse-submodules origin master git submodule update --init
As you may have gathered by now, the point is to run
git submodule update after cloning or updating the code from this repository. The
--init option is only necessary the first time, but it doesn't hurt to include it.
Download Code as Zip Archives
Unfortunately GitHub makes this a bit more complicated than it should be. To download a snapshot of the current code on any branch:
- In the default GitHub Code tab view, find the Branch menu and select the branch you want to download.
- To the right of the Branch menu, click the Download ZIP link and save the file (it will be named something like "aq_flight_control_master.zip")
- While still in the Code view, click on the
- To the right of the
mavlinkfolder there is an ID like "67a140b" or similar (7 hex digits). Click on that. It will take you to a different code repository (AutoQuad/mavlink_headers) and to a specific commit in a specific branch (this is important).
- Now click the Download Zip link on this new page. Save the file (it will be named "mavlink_headers-" with a long string of numbers at the end).
- Unzip the "aq_flight_control_master.zip" file into wherever you want to keep the firmware source code (preferably a directory path w/out spaces).
- Unzip the "mavlink_headers-xxxxx.zip" file into the
lib/mavlinkfolder of the firmware source code tree. So the final result should be a
lib/mavlink/includefolder with 2 subfolders and some .h files inside.
Compiling The Firmware
Building with CrossWorks for ARM:
Note: If you already own a full (not eval) license for CrossWorks for ARM, simply install version 2.3.5 from their archives page, open the autoquad.hzp file, and build one of the Release types. Otherwise, proceed as below.
- Install, start, and license (eval is OK) latest version of CrossWorks for ARM.
- You may also need to install the
STM32 CPU Support Package"legacy" version 2.28 (use the
Package Managerfound in
Toolsmenu). You can always install it later if the build doesn't work w/out it (we're not actually using anything from this package but CW may complain w/out it).
- Download and unpack/install CrossWorks for ARM 2.3.5 from http://www.rowley.co.uk/arm/releases.htm . (You do not need to run or activate this version, we only need the libraries from here.)
- Copy the
libfolder from CW 2.3.5 install/unpack folder to the installation folder of the latest CW version you installed in step 1. To avoid conflict with the existing
libfolder, rename the copied one to
lib-2.3. If you are not going to use CW for anything else, you can just replace the existing
libfolder and skip step 5, below. You can now completely remove the CW 2.3.5 installation/files.
- Open autoquad.hzp file in CrossWorks (the one from step 1).
- (Skip this step if you replaced the
libfolder in step 3.)
- In the Project Explorer window, expand the
Project 'autoquad'and then the
- Double-click the
Additional Input Filesline.
- Replace each occurrence of
$(StudioDir)/libwith the folder where you copied the CW 2.3.5 libraries to. For example:
- Click OK and you're done.
- In Project Explorer window, select the build type from the dropdown menu at the top left. The build type should match your AQ hardware (version, IMU type, etc). Be sure to select a "Release" type build (not "Debug").
Build Solutionfrom the main
Buildmenu, or press
SHIFT-F7. If all goes well, there should be a compiled firmware binary in a subfolder of the
Building with Makefile:
- Download and unpack/install CrossWorks for ARM 2.3.5 from http://www.rowley.co.uk/arm/releases.htm . It is best to install it to a directory path with no spaces in the names at all. You do not need to run this version, we just need the build toolchain (compiler and libraries).
- In a plain-text editor, create a new file in the root of this project named
Makefile.user(it goes next to the existing
- Enter the following on a line of the new file:
CC_PATH ?= [path to CW]where "[path to CW]" is the root of your CrossWorks 2.3 installation folder (at minimum, the following folders are expected to be inside the CW install folder:
/gcc/arm-unknown-eabi/bin, lib, include). Eg.
CC_PATH ?= /usr/share/crossworks_for_armor
CC_PATH ?= c:/devel/crossworks_for_arm. On Windows always use forward slashes in directory paths (see Notes for Windows users, below).
- Windows only: in
Makefile.user, also specify a path to the
mkdirutility, like this:
EXE_MKDIR = c:/GnuWin/bin/mkdirwhere the "c:/GnuWin/bin/" part would be wherever you have installed GNU tools (see Notes for Windows users, below). You can avoid this step if your GNU tools are on the
PATHbefore the Windows system folders (see example batch file, below).
- Open a terminal/command prompt and navigate (
cd) to the root of the project (where the Makefile lives).
- Type the command
make alland see what happens. With no other arguments, this should build a default firmware version for AQ6 revision 1 with DIMU. The binary should appear in a new
- To change the AQ hardware version, pass
make BOARD_VER=8 BOARD_REV=6to build for M4 rev 6 (M4 v2). Read the
Makefilefor full list of versions and revisions available.
Tips for using Makefile
- Read the Makefile comments for more options, full list of build targets, and other information.
-jXfor faster (parallel) compilation, where "X" equals the number of CPUs/cores/threads on your computer. If you have
makeversion 4+, also add the
-Ooption for better progress output during compilation. Eg.
make -j8 -Ofor a quad-core CPU.
Makefile.userfile is the right place to specify build options you typically want, then you can avoid entering them on the command-line each time, or editing the main
Makefile. You can also set any variable in the environment and
makewill use it instead of the default in the
Makefile. Command-line options always override all other variables.
- All directory paths are relative to the location of the
Makefile. You can use relative or absolute paths for most options.
- You can easily set up a local environment and specify build options using a batch or shell file. This is especially useful for Windows so you can specify a local
PATHvariable w/out having to change the system-wide
PATH(and need to restart Windows). The order of the
PATHentries also affects how Windows searches for commands (making it easy to, for example, override Windows'
mkidirwith GNU tools
mkdir). Here is a basic example batch file to initiate a build (this also shows using environment variables to set all the build options):
@echo off set PATH=c:\devel\GnuWin\bin;C:\Windows\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem set CC_PATH=c:/devel/crossworks_for_arm_2.3 set BUILD_TYPE=Release-M4.r6 set BOARD_VER=8 set BOARD_REV=6 make bin
Notes for Windows Users:
You will need some GNU (Unix/Linux) tools installed and in your
PATH. Make sure to install them on a path with no spaces (eg.
c:/GnuWin/) There are several good sources for these, including GnuWin32 CoreUtils and ezwinports. The following utilities are required:
sh, make, gawk, mv, echo, rm, mkdir, expr, zip.
Most distributions include an older version of 'make' (3.x). Version 4.x offers some improvements for parallel builds. Windows versions are available from ezwinports (get a "w/out guile" version) or Equation Solution (64 or 32 bit version, depending on your Windows type).
Note that all directory paths used by
make should have forward slashes (
/) instead of typical Windows backslashes (