ardupilot/libraries/AP_HAL_FLYMAPLE/FlymaplePortingNotes.txt

333 lines
12 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 ardupilot, the Flymaple port uses portions of a
custom version 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 ardupilot tree, the changes have been #ifdefed for
Flymaple:
- 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 input only, NOT 5V tolerant, use a voltage divider for 5V GPSs.
1 AP GPS on Flymaple Serial2 Tx out. This is where you connect the GPS.
3.3V output
5 I2C SCL. Do not use for GPIO.
6 Receiver PPM-SUM in.
7 Console and Mavlink on Flymaple Serial1 Rx in. Also on connector
"COM1". 5V input tolerant.
8 Console and Mavlink on Flymaple Serial1 Tx out. Also on connector
"COM1". 3.3V output.
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 output
30 Telemetry Rx from radio on Serial3 on connector labelled "GPS". 5V input 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
The I2CDriver on Flymaple uses the libmaple i2c low level hardware I2C
library, configuredfor high speed (400kHz).
As at 2013-10-03, there is a bug in the libmaple git master code, that causes
a crash in the I2C interrupt handler. Therfore it is necessary to use the
patched version of libmaple referred to below.
At 400kHz I2C speed, it takes 500us to read both the 6 byte accelerometer
buffer and the 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
ITG3205 Gyro
2000 degrees/sec, 256Hz LPF, 8kHz internal sample rate, read at 1kHz sample rate
The gyro and accelerometers are sampled at about 800Hz in
AP_InertialSensor_Flymaple.cpp, with the samples passed through a software
2-pole low pass filter, to produce filtered data for the main loop.
Installation on Linux
Tested with:
- libmaple patched library based on https://github.com/leaflabs/libmaple (see
below for more data)
- 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 ardupilot 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 to PATH and config.mk
cd ~
git clone https://github.com/mikemccauley/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
cp main.cpp.example main.cpp
make
(at this stage you can test your flymaple CPU and the upload process with
'make install', which will upload a simple LED blinking program to your
Flymaple)
Now download ardupilot:
cd ~
git clone https://github.com/ArduPilot/ardupilot.git
cd ardupilot
edit 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
cd ArduPlane
make flymaple
make upload
Libmaple fork
Correct compilation and operation of the Flymaple port depends on
using the fork of libmaple from https://github.com/mikemccauley/libmaple.git
The changes relative to the libmaple master are:
- Add LIBMAPLE_VERSION_MAJOR and LIBMAPLE_VERSION_MINOR for version detection
- Add TX ring buffer and interrupt handler to usart.c
- Fix a bug in I2C interrupt handler that would crash in master mode
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)
Alternative Orientations
Although the default board orientation is as described above, you can alter it
by changing the AHRS_ORIENTATION parameter.
For example, if you set AHRS_ORIENTATION to 1 (Yaw45), then the board will act
as if 'Forward' is towards the green row of pin headers (ie the row of digital
input pins marked 0 to 13, and 'Right' is towards the triple row of pins
marked PWM. This orientation is good for vehicles where the board must be
orthogonal to the direction of movement.
PPM-SUM receiver and transmitter channel assignments
Pin 6 of the Flymaple is used for the PPM-SUM receiver input
I used the DSM2 PPM+UART receiver product code LEM-CH6-PPM from www.lemon-rx.com:
http://www.lemon-rx.com/shop/index.php?route=product/product&path=70&product_id=66
(make sure you use one made after Oct 2013: earlier versions had a proprietary and
incompatible PPM output).
The raw channel numbers resulting from using this with my Spektrum DX6i 6
channel mode 2 transmitter are:
Channel Assignment
1 Throttle
2 Aileron/Roll
3 Elevator/Pitch
4 Rudder/Yaw
5 Gear/mode
6 Flap/learn
With the following channels configured for APMrover:
RCMAP_PITCH 1
RCMAP_ROLL 2
RCMAP_THROTTLE 3
RCMAP_YAW 4
MODE_CH 5
LEARN_CH 6
with the RC servo ouputs on Flymaple J5:
Transmitter channel 2 (steering) PWM/AIN/D27
Transmitter channel 3 (speed = motor ESC) PWM/AIN/D11
This permits a single joystick (the right stick in my case) to be used to control the rover:
elevator = speed control
aileron = steering
gear = mode
flap = learn
Notes:
You may (like me) need to reverse the Roll servo, using the Radio Calibration page
on Mission Planner, else the vehicle will steer in exactly the wrong direction
when on Auto, but will be OK on Manual.
GPS notes
I tested initially with an EM-405A GPS (This is a 5Hz, 5V GPS, and therefore I
also needed a voltage divider to make the received data compatible with the
Flymaple 3.3V GPS input on pin D0). This GPS was unsatisfactory due to long
time lags in changing ground track and speed, and also due to large random
ground speeds up to 1.0 m/s when stationary. I was able to get ok behaviour
with very large values for NAVL1_PERIOD of around 40. Don't use this GPS.
I also tested with a Eagle Tree GPS$v, which is a 10Hz, 3.3V GPS board
containing a GTPA010 GPS. This GPS worked much better with the suggested
tuning configuration from
http://rover.ardupilot.org/wiki/tuning-steering-and-navigation-for-a-rover/
For the record, the tuning I used with this was:
CRUISE_SPEED 3 m/s
CRUISE_THROTTLE 40 %
NAVL1_DAMPING 0.76
NAVL1_PERIOD 10
SPEED2THR_D 0.2
SPEED2THR_I 0.2
SPEED2THR_IMAX 4000
SPEED2THR_P 0.7
Remaining issues:
1. Many alignment warnings emitted by the compiler from libraries/GCS_MAVLink
protocol.h eg:
/mnt/disk2/src/ardupilot/libraries/GCS_MAVLink/include/mavlink/v1.0/ardupilotmega/../protocol.h: In function 'double _MAV_RETURN_double(const mavlink_message_t*, uint8_t)':
/mnt/disk2/src/ardupilot/libraries/GCS_MAVLink/include/mavlink/v1.0/ardupilotmega/../protocol.h:274: warning: cast from 'const char*' to 'const double*' increases required alignment of target type
2. Logging is not implemented.