mirror of https://github.com/ArduPilot/ardupilot
231 lines
8.3 KiB
Plaintext
231 lines
8.3 KiB
Plaintext
2013-09-23
|
|
|
|
These notes describe the steps take to port ArduPilot to the Flymaple platform
|
|
http://www.open-drone.org/flymaple
|
|
|
|
Flymaple has an ARM based Cortex-3 STM32F103RE, 72MHz processor with 10DOF builtin sensors
|
|
|
|
|
|
Implementation
|
|
|
|
Unlike the Arduino versions of ArduPlane, the Flymaple port uses portions of
|
|
the libmaple library, including the stm32f1 core and some other libaries like
|
|
Wire, HardwareTimer, HArdwareSPI etc.
|
|
|
|
Most of the changes are confined to new directory libraries/AP_HAL_FLYMAPLE
|
|
which contains the Flymaple specific code. All the HAL modules have
|
|
been ported, sometimes based on HAL_AVR, sometimes HAL_PX4:
|
|
AnalogIn
|
|
AnalogSource
|
|
Console
|
|
GPIO
|
|
I2CDriver
|
|
RCInput
|
|
RCOoutput
|
|
Scheduler
|
|
Semaphores
|
|
SPIDriver
|
|
Storage
|
|
UARTDriver
|
|
Utility
|
|
|
|
The implementation of Storage uses EEPROM emulation code that uses 2 pages of
|
|
Flymaple FLASH ROM as EEPROM. It was copied from
|
|
AeroQuad_v3.2 to libraries/AP_HAL_FLYMAPLE/utility and slightly modified:
|
|
libraries/AP_HAL_FLYMAPLE/utility/EEPROM.*
|
|
libraries/AP_HAL_FLYMAPLE/utility/flash_stm32.*
|
|
|
|
Unlike other HAL ports, the namespace for Flymaple defined in
|
|
AP_HAL_FLYMAPLE_Namespace.h has a more extensive name: 'AP_HAL_FLYMAPLE_NS' else
|
|
get complaints from gcc 4.4.1 caused by collisions with other class names.
|
|
|
|
New board makefile mk/board/flymaple.mk, plus some other minor changes in
|
|
mk/*.mk
|
|
|
|
In other parts of the ArduPlane tree, the changes have been #ifdefed for
|
|
Flymaple except:
|
|
|
|
- ArduPlane/compat.pde
|
|
|
|
- libraries/AP_Compass/AP_Compass_HMC5843.cpp
|
|
- libraries/AP_Compass/Compass.h
|
|
- libraries/AP_Baro/AP_Baro_BMP085.cpp
|
|
Minor changes to raw data fetches to make them 32bit compatible. Should not
|
|
affect other platforms.
|
|
|
|
Some other minor edits to eliminate compiler warnings
|
|
|
|
These changes have now all been included in the ardupilot mainline code.
|
|
|
|
Resource usage
|
|
Resources on the Flymaple board have been allocated by the HAL:
|
|
|
|
Pins
|
|
0 AP GPS on Flymaple Serial2 Rx in. This is where you connect the
|
|
GPS. 3.3V only, NOT 5V tolerant
|
|
1 AP GPS on Flymaple Serial2 Tx out. This is where you connect the GPS.
|
|
3.3V
|
|
5 I2C SCL. Do not use for GPIO.
|
|
6 Receiver PPM in
|
|
7 Console and Mavlink on Flymaple Serial1 Rx in. Also on connector
|
|
"COM1". 5V tolerant.
|
|
8 Console and Mavlink on Flymaple Serial1 Tx out. Also on connector
|
|
"COM1". 3.3V
|
|
9 I2C SDA. Do not use for GPIO
|
|
15 3.3V board VCC analog in. Connect to 3.3V pin.
|
|
16 Airspeed analog in (if available). 3.3V, NOT 5V tolerant.
|
|
19 Battery current analog in (if available). 3.3V, NOT 5V tolerant.
|
|
20 Battery voltage analog in (on-board divider connected to board VIN)
|
|
29 Telemetry Tx to radio on Serial3 on connector labelled "GPS". 3.3V
|
|
30 Telemetry Rx from radio on Serial3 on connector labelled "GPS". 5V tolerant.
|
|
|
|
Timers
|
|
SysTick 1000Hz normal timers
|
|
1 CH1 RCInput
|
|
2 CH1 1000Hz Failsafe timer
|
|
3 CH1-4, 4 CH1-2 RCOut
|
|
8 not used by AP
|
|
|
|
AP I2CDriver on Flymaple uses the libmaple Wire library, configured to clock
|
|
at about 200kHz. The maximum possible Flymaple could support speed is limited
|
|
by the BMP085 barometer to 400kHz.
|
|
Current version of the Wire library is unfortunately
|
|
bit-banged. This may change in the future.
|
|
|
|
At 200kHz I2C speed, it takes 500us to read the 6 byte accelerometer
|
|
buffer, and 500us to read the 6 byte gyro buffer.
|
|
|
|
The SerialUSB (USB connection) to Flymaple is not used by AP. It can be used for
|
|
debugging inside AP_HAL_FLYMAPLE, using SerialUSB.println().
|
|
|
|
Sensor configuration
|
|
|
|
The sensors are configured so:
|
|
|
|
ADXL345 Accelerometer
|
|
8g full scale, full resolution mode, 800Hz bandwidth, read at 1kHz sample rate
|
|
per sec
|
|
|
|
ITG3205 Gyro
|
|
2000 degrees/sec, 256Hz LPF, 8kHz internal sample rate, read at 1kHz sample rate
|
|
|
|
Installation on Linux
|
|
|
|
Tested with:
|
|
libmaple https://github.com/leaflabs/libmaple http://leaflabs.com/docs/unix-toolchain.html
|
|
arm-none-eabi-g++ toolchain, version 4.4.1
|
|
on OpenSuSE 12.3
|
|
Mission Planner 1.2.78
|
|
|
|
You need a number of additional resources to build ArduPlane for Flymaple. I
|
|
have assumed that you will install them in your home directory, but they can really
|
|
go anywhere provided you make the appropriate changes
|
|
|
|
cd ~
|
|
git clone https://github.com/leaflabs/libmaple.git
|
|
cd libmaple
|
|
wget http://static.leaflabs.com/pub/codesourcery/gcc-arm-none-eabi-latest-linux32.tar.gz
|
|
tar xvzf gcc-arm-none-eabi-latest-linux32.tar.gz
|
|
export PATH=$PATH:~/libmaple/arm/bin
|
|
make
|
|
|
|
edit ArduPlane/config.mk to be something like:
|
|
#config.mk START
|
|
# Select maple_RET6 for Flymaple
|
|
BOARD = maple_RET6
|
|
# HAL_BOARD determines default HAL target.
|
|
HAL_BOARD ?= HAL_BOARD_FLYMAPLE
|
|
# The communication port used to communicate with the Flymaple
|
|
PORT = /dev/ttyACM0
|
|
# You must provide the path to the libmaple library directory:
|
|
LIBMAPLE_PATH = $(HOME)/libmaple
|
|
# Also, the ARM compiler tools MUST be in your current PATH like:
|
|
# export PATH=$PATH:~/libmaple/arm/bin
|
|
#config.mk END
|
|
|
|
Interrupt disabling on ARM
|
|
|
|
On AVR, ISRs run by default with the global interrupt enable flag disabled,
|
|
whereas mainline code runs by default with global interrupt enable flag
|
|
*enabled*. Which means that cli()/sei() in an ISR will have a different effect
|
|
to cli()sei() in mainline code. Thats why code that *might* run in an ISR must
|
|
use the special idiom: so that it restores the flag to the state it was before
|
|
the critical block
|
|
|
|
On ARM, the global interrupt disable flag PRIMASK is not altered behind your
|
|
back by hardware. By default its always clear (ie enabled) even in ISRs. A
|
|
different mechanism prevents ISRs from being reinterrupted. This means that
|
|
non-nested noInterrupts()/interrupts() will always leave the PRIMASK as it was
|
|
(interrupts enabled) when the critical block started, whether in ISRs or
|
|
mainline code.
|
|
|
|
Conclusion:
|
|
|
|
On AVR, cli()/sei() is dangerous both in ISRs *and* when nested.
|
|
|
|
On ARM, noInterrupts()/interrupts() is only dangerous when nested.
|
|
|
|
Sensor Orientation
|
|
|
|
The Flymaple board has no clear indication about which way is meant to be
|
|
'forward' or 'right', so we have adopted the following convention:
|
|
|
|
Aircraft 'Forward' is in the direction of the arrow marked 'Pitch' on the board, ie
|
|
towards pin 0.
|
|
|
|
Aircraft 'Right' is towards the bottom right corner of the board, towards pin 20 and
|
|
the 5V regulator
|
|
|
|
Aircraft 'Down' is away from the copper side of the board: 'right way up' is with
|
|
component side up.
|
|
|
|
Here in SE Queensland, in the southern hemisphere, the local mag field is
|
|
substantially vertical (down? is that correct?), and so the following simple
|
|
tests of the board should give the following results, using the mavproxy
|
|
graphing tools, and with a board orientation parameter of none:
|
|
|
|
The aircraft coordinate system of ardupilot is:
|
|
|
|
X +ve forward
|
|
Y +ve right
|
|
Z +ve down
|
|
|
|
Compass
|
|
Orientation Results
|
|
Level, right way up Z -ve
|
|
Left side down Y +ve
|
|
Nose up X +ve
|
|
(ie positive when that axis is pointing away from the earth, at least where I
|
|
am)
|
|
|
|
Accelerometer
|
|
Orientation Results
|
|
Level, right way up Z -ve
|
|
Left side down Y +ve
|
|
Nose up X +ve
|
|
(ie positive when that axis is pointing away from the earth, and consistent
|
|
with compass in southern hemisphere)
|
|
|
|
Gyro
|
|
Rotation Results
|
|
Yawing to right Z +ve
|
|
Rolling to right X +ve
|
|
Pitching up Y +ve
|
|
|
|
(ie right hand curl rule relative to the given axis)
|
|
|
|
Remaining issues:
|
|
|
|
1. For reasons I do not yet understand, the magnetic heading reported by
|
|
ArduPlance is 90 degrees away from what I think it should be.
|
|
The sensors on the Flymaple are all aligned with the nominal X, Y and Z axes
|
|
collinear. Pitch and roll axes point to the _corners_ of the board, not the
|
|
flat sides as might be considered normal for a sensor board.
|
|
Orientation is set to NONE, and yes, the reading of compass sensor registers
|
|
is in teh right order for the HMC5883.
|
|
|
|
2. Many alignment warnings emitted by the compiler from libraries/GCS_MAVLink
|
|
protocol.h eg:
|
|
mnt/disk2/src/ArduPlane-2.74b/libraries/GCS_MAVLink/include/mavlink/v1.0/ardupilotmega/../protocol.h: In function 'uint16_t _MAV_RETURN_uint16_t(const mavlink_message_t*, uint8_t)':
|
|
/mnt/disk2/src/ArduPlane-2.74b/libraries/GCS_MAVLink/include/mavlink/v1.0/ardupilotmega/../protocol.h:267: warning: cast from 'const char*' to 'const uint16_t*' increases required alignment of target type
|