User:Earthpatrol

From PaparazziUAV
Revision as of 13:59, 9 August 2017 by Earthpatrol (talk | contribs) (→‎915 Mhz SiK/HopeRF)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

Developing autonomous capabilities for HooperFly using the Lisa MX and Elle0 autopilots from 1BitSquared in tandem with PaparazziUAV.

Frames & Components

The collection of HooperFly frames configured to fly with Paparazzi.

HooperFly RacerPEX Quad : Azul

HooperFly RacerPEX Quad : Verde

HooperFly RacerPEX Quad : Neon

HooperFly RacerPEX Hexa : Neon

HooperFly TeensyFly Quad Lisa

HooperFly TeensyFly Quad Elle

HooperFly TeensyFly Hexa

Frame/Component Test Bench : MultiWii FC & DSM2 Receiver

Each frame and associated components(motors/escs/wiring harness) are tested for functionality using a MultiWii FC and DSM2 receiver prior to the Lisa/MX autopilot integration.

Multiwii dsm2 testfc.JPG

Flight Preparation

Airframes: HooperFly TeensyFly and RacerPEX

Attempting to use PaparazziUAV to fly four HooperFly frames in a synchronized autonomous fashion.

Hooperfly racerpex azulverde.jpg

Hooperfly teensyflyquadhexa lisamx.jpg

HooperFly RacerPEX LisaMX.jpg

Hooperfly RacerPEX Hexa LisaMX.jpg

Airframe Configuration

Motor Layout Diagrams: Quad, Hexa, Octo

Motor position and rotation diagrams for "x" and "+" configurations of HooperFly quads, hexa, and octocopters. The top row consists of the "x" configuration frames and the bottom row contains the "+" configurations. Odd numbered motors(1, 3, 5, 7), blue in color, rotate clockwise. Even numbered motors(2, 4, 6, 8), green in color, rotate counter-clockwise.

Motor layout diagrams.png

All HooperFly airframe configuration files are located in the directory: 

$PAPARAZZI_HOME/conf/airframes/HooperFly
Table of Airframe Config Files
Airframe File
TeensyFly Quad teensyfly_quad_lisa_mx_20.xml
TeensyFly Hexa teensyfly_hexa_lisa_mx_20.xml
RacerPEX Quad racerpex_quad_lisa_mx_20.xml
RacerPEX Hexa racerpex_hexa_lisa_mx_20.xml
RacerPEX Octo racerpex_octo_lisa_mx_20.xml

JSBSim Aircraft Configuration

Jsbsim coordinates.gif

JSBSim defines a "BODY" frame with the following cartesian coordinate system to quantify propulsion forces:

  • Top Left Quadrant (e.g.: NW, FL) -, -
  • Top Right Quadrant (e.g.: NE, FR) -, +
  • Bottom Right Quadrant (e.g.: SE, BR) +, +
  • Bottom Left Quadrant (e.g.: SW, BL) +, -

Reference the JSBSim Documentation for a discussion about the STRUCTURAL vs. BODY frame as well as details related to each section of a jsbsim configuration file.

All HooperFly JSBSim aircraft configuration files are located in the directory: 

$PAPARAZZI_HOME/conf/simulator/jsbsim/aircraft/HooperFly
Table of JSBSim Aircraft Config Files
Airframe File
TeensyFly Quad teensyfly_quad.xml
TeensyFly Hexa teensyfly_hexa.xml
RacerPEX Quad racerpex_quad.xml
RacerPEX Hexa racerpex_hexa.xml
RacerPEX Octo racerpex_octo.xml

AHRS/Stabilization Settings

This is a placeholder for rotorcraft flight research as it relates to Stablization/AHRS pairs.

Reference Pages:

Stabilization
AHRS int_quat float_quat int_euler float_euler
int_cmpl_quat yaw wobble
float_cmpl
int_cmpl_euler
float_mlkf

Power System

Wiring Harness

  • If possible, braid esc-to-battery connection wiring, or at a minimum, twist them as a group to minimize magnetic interference.

ESC Wiring/Layout

  • If possible, braid motor-to-esc wiring, or at a minimum, twist them as a group to minimize magnetic interference.

TeensyFly Supported ESC's

ESC to Motor Wiring and Rotation

  • RCTimer Mini OPTO ESC: A-A, B-B, C-C --> Clockwise Rotation
  • KISS ESC: A-A, B-B, C-C --> Clockwise Rotation

Autopilot UBEC

The UBEC DC/DC Step-Down (Buck) Converter - 5V @ 3A output from Adafruit is recommended for supplying power to the 1bitsquared autopilots; these include the Lisa/MX and the Elle0.

Elle0 Voltage Divider Circuit

If you plan to monitor the battery voltage, the Elle0 requires the addition of a voltage divider to the power circuit: 

 +12v -- 10K ohm Resistor -- V. Batt. -- 2.2k ohm Resistor -- gnd

Electromagnetic Interference Considerations

Mount2 wire tfhexa.jpg

  • Address issues related to reducing electromagnetic interference

Telemetry Radios

2.4Ghz Xbee

Radio Setup

Links

Recovering a Bricked Xbee

There are some signal/power dynamics associated with Xbee radios that can sometimes result in a non-operational radio. The following links are useful when looking to un-brick an Xbee radio:

915 Mhz SiK/HopeRF

Firmware Link: Firmware Github

Multipoint SiK Firmware Link: Multipoint SiK Firmware Github

Authentic 3DR Telemetry

Authentic 3DR Telemetry modules use the FTDI chip.

Links

Cloned 3DR Telemetry

3DR telemetry clones available on Ebay use the SiLabs chip.

Links

Air/Ground Pairs in Support of Multiple Aircraft

Based on some simple initial testing, it looks like each aircraft will need an air/ground telemetry radio pair(i.e. point-to-point connection). Each air/ground pair should be assigned their own unique NET_ID. Programming the air radio requires the use of an FTDI-to-USB board for changing the NET_ID. The ground radio has a built-in USB connection and does not require an adapter for programming. The telemetry radios are shipped with a default NET_ID = 25. Picking a NET_ID other than 25 is advised to reduce the chance of NET_ID collision due to other aircraft using default radio settings( valid NET_ID values: 0-499).

The ground station antennas should be vertically spaced a minimum of two wavelengths from each other to reduce interference related issues. Applicable wavelengths for commonly used telemetry radio frequencies:

  • 400 mhz =75 cm
  • 900 mhz = 33.3 cm
  • 2.4 ghz = 12.5 cm

Recommended ground station antenna spacing:

  • 400 mhz : 75 cm * 2 = 150 cm (59 inches)
  • 900 mhz : 33.3 cm * 2 = 66.6 cm (27 inches)
  • 2.4 ghz : 12.5 cm * 2 = 25 cm (10 inches)

Transmitter - 2.4Ghz DSM2/DSMX Compatible

Spektrum DX6i

Using the Spektrum DX6i transmitter as an RC link.

Airframe Radio Section

Define the roles of the "flap" and "gear" switch for the transmitter. In this example, the "flap" toggle is used for the radio mode and the "gear" toggle as the kill switch. 

    <subsystem name="radio_control" type="spektrum">
      <define name="RADIO_MODE" value="RADIO_FLAP"/>
      <define name="RADIO_KILL_SWITCH" value="RADIO_GEAR"/>
       <configure name="USE_SECONDARY_SPEKTRUM_RECEIVER" value="1"/>
    </subsystem>

Deriving 3-State Behavior with Two Toggle Switches

The Spektrum DX6i does not have a 3-state toggle switch. A little bit of "mixing magic" between two toggle switches is needed to express 3-state toggle switch behavior. Use the following setup for "Mix 1" to emulate a 3-state toggle switch using ELEV D/R & FLAP switches. 

FLAP-> FLAP ACT
RATE D -100% U  0%
SW ELE D/R TRIM INH

DX6i Toggle Switch Flight Mode Verification

Given the following autopilot flight mode settings:

File: conf/airframes/HooperFly/teensyfly_hexa_lisa_mx_20.xml 
 <section name="AUTOPILOT">
    <define name="MODE_STARTUP" value="AP_MODE_NAV"/>
    <define name="MODE_MANUAL"  value="AP_MODE_ATTITUDE_DIRECT"/>
    <define name="MODE_AUTO1"   value="AP_MODE_HOVER_Z_HOLD"/>
    <define name="MODE_AUTO2"   value="AP_MODE_NAV"/>
 </section>
  1. Power up the autopilot outfitted with a GPS module as well as a working telemetry connection.
  2. Turn on your TX configured to the aircraft under test.
  3. Start Paparazzi and open the appropriate session for your given telemetry link along with the GCS.
  4. Wait for the GPS to get lock and verify the TX is connected as well.

Now that you have your GPS enabled autopilot connect to the GCS, verify the following toggle switch/autopilot states:

Autopilot Flight Mode Toggle Switch States
ELEV D/R FLAPS MODE VALUE
0 1 MODE_MANUAL ATT -- AP_MODE_ATTITUDE_DIRECT
1 1 MODE_AUTO1 H_ZH -- AP_MODE_HOVER_Z_HOLD
1 0 MODE_AUTO2 NAV -- AP_MODE_NAV

Channel Mapping for Spektrum Revised

As of November 2015, the channel assignments for Spektrum radios were modified to reflect a Paparazzi centric view of channel assignments. There are two options for dealing with the change. One is to reverse the appropriate channels on a previously programmed spektrum transmitter; the other is to compile the airborne code with RADIO_CONTROL_SPEKTRUM_OLD_SIGNS defined.

Name/Channel Assignments
Configuration Throttle/0 Aileron/1 Elevator/2 Rudder/3 Gear/4 Flap-Aux1/5 Aux2/6 Aux3/7 Aux4/8 Aux5/9 Aux6/10 Aux7/11
Spektrum Factory 1 -1 -1 -1 1 -1 1 1 1 1 1 1
PPRZ Convention 1 1 1 1 1 1 1 1 1 1 1 1

Given the above mapping, it is expected that the Aileron/1, Elevator/2, Rudder/3, and Flap-Aux1/5 channels would need to be reversed.

2015-11-30: Verified that the Aileron - ch 1, Elevator - ch 2, Rudder - ch 3, and the Flap-Aux1 - ch 5 need to be set to reverse (i.e. R). All other channels are still set to neutral (i.e. N).

See spektrum_arch.h and spektrum_arch.c for details.

Devo 10

Using the Walkera Devo 10 transmitter running Deviation firmwareas an RC link.

Updating Firmware

  1. Download the Deviation 4.0.1 release as well as the Walkera provided DFU USB Tool
  2. Install the downloaded DFU USB tool
  3. Connect the Devo 10 via USB to your computer
  4. Using the DFU USB tool, install the 4.0.1 firmware

Modifying Files

  1. Connect the Devo 10 via USB to your computer
  2. Open the file browser and navigate to the Devo 10 device that should now be present
  3. Reference the Devo 10 documentation for details about the file structure

Channel Mapping for Devo 10

Name/Channel Assignments
Configuration Throttle/0 Aileron/1 Elevator/2 Rudder/3 Gear/4 Flap-Aux1/5 Aux2/6 Aux3/7 Aux4/8 Aux5/9 Aux6/10 Aux7/11
Deviation Defaults 1 -1 -1 -1 1 1 1 1 1 1 1 1
PPRZ Convention 1 1 1 1 1 1 1 1 1 1 1 1

Given the above mapping, the Aileron/1, Elevator/2, and Rudder/3 need to be reversed.

Receiver - 2.4Ghz DSM2/DSMX Satellite

Wiring/Binding

Flash the firmware with the latest Paparazzi that includes patch related to binding DSM2 receivers with LisaMX in spektrum_arch.c: 

#define MASTER_RECEIVER_PULSES 4

The transmitter must bind using the DSM2 protocol only. Note: The DSMX protocol is not currently support in Paparazzi.

Links

Verify TX/RX Connection

  • Lisa MX led 4 light on: red
  • Select the PPM settings and display the TX/RX related messages using the message tool.

Autopilot - Lisa/MX

Lisa MX Mounting Orientation

The default "front" of the Lisa MX controller is dependent on the placement of the IMU on the autopilot pcb board. This can differ between revisions of the autopilot. The PHI/THETA/PSI parameters, in the IMU section of the airframe definition file, are used to normalize the body to IMU placement.


File: conf/airframes/HooperFly/teensyfly_quad_lisa_mx_20.xml 
 <section name="IMU" prefix="IMU_">
    ...
    <define name="BODY_TO_IMU_PHI"   value="0." unit="deg"/>
    <define name="BODY_TO_IMU_THETA" value="0." unit="deg"/>
    <define name="BODY_TO_IMU_PSI"   value="0." unit="deg"/>
    ...
  </section>

Black Magic Probe(BMP)

The BMP is used to load the appropriate firmware for a given aircraft.

Command Line Loader Using the BMP

The following command will upload firmware to the autopilot using the JTAG connected Black Magic Probe: 

 Syntax:
 make AIRCRAFT=<aircraft_name> ap.upload BMP_PORT=<bmp_device_id>

 Examples:
 make AIRCRAFT=Teensy_Fly_Quad ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1
 make AIRCRAFT=Teensy_Fly_Hexa ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1

Add the clean_ac target prior to the ap.upload target to force a clean build and load: 

 Syntax:
 make AIRCRAFT=<aircraft_name> clean_ac  ap.upload BMP_PORT=<bmp_device_id>

 Examples:
 make AIRCRAFT=Teensy_Fly_Quad clean_ac ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1
 make AIRCRAFT=Teensy_Fly_Hexa clean_ac ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1

Paparazzi Center Upload Using the BMP

Bmp upload target.png

The appropriate device id for the BMP needs to be set in each airframe file for the upload feature to work correctly. In the firmware section of the airframe file, under the target named ap, add a <configure name="BMP_PORT" value="/dev/id_of_bmp_device"/> line. See the example below:


File: conf/airframes/HooperFly/teensyfly_quad_lisa_mx_20.xml 
  <firmware name="rotorcraft">
    <target name="ap" board="lisa_mx_2.0">
       <configure name="BMP_PORT" value="/dev/cu.usbmodemE2B9BDC1"/>
    </target>
  </firmware>

Update BMP Firmware for MacOS X

Install pyUSB Updates 

brew install libyaml
brew install libusb
sudo easy_install pyusb
sudo easy_install pyyaml</nowiki>

Install BMP Updates
 <nowiki>
git clone https://github.com/blacksphere/blackmagic
cd blackmagic
git submodule init
git submodule update
make
cd src
make

Now unplug the Black Magic Probe, then HOLD THE BUTTON DOWN WHILE PLUGGING IT AGAIN. 

../scripts/stm32_mem.py blackmagic.bin

Now unplug the Black Magic Probe, then replug it WITHOUT holding the button down.

Update BMP Firmware for Ubuntu Linux

Install pyUSB Updates 

sudo apt-get install python-yaml python-usb

Install BMP Updates 

git clone https://github.com/blacksphere/blackmagic
cd blackmagic
git submodule init
git submodule update
make

Now unplug the Black Magic Probe, then HOLD THE BUTTON DOWN WHILE PLUGGING IT AGAIN. 

sudo scripts/stm32_mem.py src/blackmagic.bin

TeensyFly Hexa - Mounting Strategies

Simple Double Sided Tape Mount

Mount1 tfhexa.jpg

  • Display Vibration Data with/without Props

Vibration Isolator Mount

Mount2 tfhexa.jpg

  • For comparison purposes, do not alter frame dynamics. The current vibration profile/dynamics are used as baseline to evaluate various autopilot vibration damping techniques.
  • Develop a vibration testing process to measure the permutations/combinations of various vibration damping techniques.
    • Use new tool: report_imu_scaled.py (need to integrate tool into github)
  • Capture and display test results

First flights using the vibration isolator mount resulted in a considerable reduction in the X and Y accelerometer data. The Z-axis was reduced to about 0.4g or 3.9m/s^2.

Vibe isolator data.png

RacerPEX Quad - Mounting Strategies

Vibration Isolator Mount

Using the same vibration isolator that is used on the TeensyFly Hexa aircraft. Initial inflight vibration measurements exceeded acceptable levels. Observed that props were way out of balance at near hover harmonics. Captured baseline motor vibrations without props, balanced the props and captured new inflight vibration data. Balanced props reduced the vibration levels to acceptable levels.

Vibe Isolator RacerPEX.png

RacerPEX Hexa - Mounting Strategies

Vibration Isolator Mount

Balanced propellers and profiled sensors for vibration related characteristics. 

$ ./sw/tools/calibration/report_imu_scaled.py -p ./var/logs/15_08_14__17_15_15.data

ACCEL : Time Range(84.253 : 418.182)
         ax      ay      az
Min   [-10.022  -9.322 -41.947] m/s2
Max   [  7.730   7.728  19.852] m/s2
Mean  [ -0.137  -0.165  -9.662] m/s2
StDev [  2.575   2.273   8.418] m/s2

GYRO : Time Range(84.253 : 418.182)
         gp      gq      gr
Min   [-180.909 -198.646 -50.302] deg/s
Max   [174.069 279.009  57.981] deg/s
Mean  [  1.762  -0.095   0.256] deg/s
StDev [ 40.902  38.000  13.893] deg/s

MAG : Time Range(84.261 : 418.182)
         mx      my      mz
Min   [ -0.302  -0.540   0.707] unit
Max   [  0.873   0.568   1.090] unit
Mean  [  0.269  -0.174   0.916] unit
StDev [  0.193   0.247   0.054] unit

TeensyFly Quad - Mounting Strategies

Simple Double Sided Tape Mount

Balanced propellers and profiled sensors for vibration related characteristics. 

$  ./sw/tools/calibration/report_imu_scaled.py -p -s 50 -e 225 ./var/logs/15_08_19__16_37_42.data

ACCEL : Time Range(50.165 : 225.853)
         ax      ay      az
Min   [-19.483 -21.083 -29.329] m/s2
Max   [ 19.075  22.015   7.724] m/s2
Mean  [ -0.162   0.428  -9.790] m/s2
StDev [  6.747   8.123   5.874] m/s2

GYRO : Time Range(50.165 : 225.896)
         gp      gq      gr
Min   [-58.037 -43.839 -28.592] deg/s
Max   [ 52.680  67.129  33.474] deg/s
Mean  [  0.033   0.943  -0.311] deg/s
StDev [ 11.733   8.796   9.428] deg/s

MAG : Time Range(50.165 : 225.853)
         mx      my      mz
Min   [ -0.354  -1.221  -0.235] unit
Max   [  0.313  -0.178   0.678] unit
Mean  [ -0.007  -0.772   0.346] unit
StDev [  0.123   0.142   0.121] unit

Vibration Isolator Mount

The addition of a vibration isolator mount greatly improved stability of the aircraft when in H_ZH and NAV mode. Here are the vibration results: 

$ python ./sw/tools/calibration/report_imu_scaled.py -p -s 43 -e 113 ./var/logs/15_08_28__15_39_51.data

ACCEL : Time Range(43.075 : 113.813)
         ax      ay      az
Min   [ -1.971  -1.079 -15.983] m/s2
Max   [  1.733   2.068  -3.909] m/s2
Mean  [ -0.023   0.381  -9.747] m/s2
StDev [  0.680   0.602   2.657] m/s2

GYRO : Time Range(43.075 : 113.876)
         gp      gq      gr
Min   [-17.793 -14.869  -9.806] deg/s
Max   [ 15.779  15.597   8.281] deg/s
Mean  [ -0.624   0.822  -0.051] deg/s
StDev [  4.919   5.428   2.774] deg/s

MAG : Time Range(43.075 : 113.876)
         mx      my      mz
Min   [ -0.128  -0.487   0.758] unit
Max   [  0.390  -0.271   0.983] unit
Mean  [  0.278  -0.386   0.866] unit
StDev [  0.046   0.034   0.043] unit

Vibe Isolator TeensyFlyQuad.png

Autopilot - Elle0

Elle0 Mounting Orientation

Using the 1bitsquared recommended mounting orientation for the Elle0( servo pins facing the back of the aircraft and the power/rx ports facing the front of the aircraft.)

Flashing with USB

Install DFU-UTIL

The dfu-util tool, version 0.8 or newer, is required for flashing the Elle0.

For Mac OS X, install it with brew: 

brew install dfu-util

For Ubuntu Linux, install the Vivid version. Click the link to get the package: DFU-UTIL AMD64 Link

Once installed, verify the version: 

$ dfu-util -V
dfu-util 0.8

Using Paparazzi Center

Build the ap target and upload using the USB DFU-UTIL flash mode option.

Flash with dfuutil.jpg

Using the Command Line

Build the ap target and upload using the DFU-UTIL flash mode option.

make AIRCRAFT=Teensy_Fly_Quad_Elle0 clean_ac FLASH_MODE=DFU-UTIL  ap.upload

TeensyFly Quad - Mounting Strategies

Based on previous testing with the Lisa/MX, it was decided to use the vibration isolator mount on this frame in tandem with the Elle0.

Vibration Isolator Mount

Elle0 vibe isolator.jpg

Binding Spektrum RX

A step-by-step for binding Spektrum receivers to the ELLE0:

  1. Unpower and switch off the TX
  2. Hold down the bind button on ELLE0
  3. Plug in the power using the battery or BEC to ELLE0 (do not use USB cable) as a result, the Spektrum satellite RX(s) should be blinking rapidly
  4. Turn on the TX in bind mode and hold until the RX lights go solid
  5. Turn off/unplug the battery to the ELLE0

The RX(s) are now bound to your TX.

Calibration

The processes used to calibrate the actuators and sensors for the Elle0 are nearly identical to the those used for the Lisa/MX.

Actuators

Reference the Lisa/MX ESC Actuator Setup section. Note that the setup_elle0 firmware is used for Elle0 actuator calibration.

Accelerometer

Reference the Accelerometer Setup section.

Magnetometer

Reference the Magnetometer Setup section.

Current

Reference the Current Calibration Setup section.

Vibration Profiles

NOTE ==>> ANTI-VIBRATION PLATE USES CHEAPER WHITE BUSHINGS, ALSO PRE-PROP BALANCE

$ python ./sw/tools/calibration/report_imu_scaled.py -p -s 51 -e 195 ./var/logs/15_09_04__21_25_14.data

ACCEL : Time Range(51.126 : 195.951)
         ax      ay      az
Min   [ -4.210  -3.255 -20.111] m/s2
Max   [  5.402   2.655  -0.023] m/s2
Mean  [  0.389  -0.097  -9.748] m/s2
StDev [  1.438   1.054   3.482] m/s2

GYRO : Time Range(51.126 : 195.914)
         gp      gq      gr
Min   [-33.809 -66.948 -23.836] deg/s
Max   [ 29.053  66.276  13.988] deg/s
Mean  [ -0.065   0.015  -0.276] deg/s
StDev [  6.215  23.490   3.939] deg/s

MAG : Time Range(51.126 : 195.933)
         mx      my      mz
Min   [ -0.254  -0.518   0.824] unit
Max   [  0.174  -0.266   0.992] unit
Mean  [ -0.023  -0.400   0.915] unit
StDev [  0.085   0.034   0.022] unit

GPS - UBLOX LEA-6H

Links

Verify GPS Connection

  • Lisa MX led 3 light on: green
  • GPS unit leds active

Touch Device Applications

PPRZONDROID

Wiki Page: PPRZonDroid
Repository: PPRZonDroid Github

Flight Testing

RC Transmitter Verification

With the propellers removed from the multirotor, verify throttle, roll, pitch and yaw functionality prior to initial flight tests as well as expected motor spin directions. The autopilot should be in manual flight mode during this verification process.

TX/Motor Verification
Airframe Throttle Yaw Pitch Roll M1 M2 M3 M4 M5 M6
TeensyFly Quad + + + + CW CCW CW CCW
TeensyFly Hexa + + + + CW CCW CW CCW CW CCW

IMU Calibration

It is best to have a fully populated airframe with a working telemetry radio running on battery power for IMU calibration purposes. Be sure to remove the propellers from the motors before proceeding with IMU calibration. For a general overview reference: ImuCalibration.

Accelerometer

  1. Power up the flight controller/IMU circuitry on your aircraft with a functioning telemetry radio
  2. Start paparazzi
  3. Run the session that connects the ground station telemetry to the aircraft
  4. In the "Settings" tab for the aircraft select the "raw sensors" and commit
  5. Viewing sensor data in real-time (optional step)
    1. Open the "Messages" tool and select the "IMU_ACCEL_RAW"
    2. Open the "Real-Time Plotter" tool and reduce the "Update time" slider to the far left (smaller the value, the faster the update)
    3. Drag and drop the IMU_ACCEL_RAW fields "ax", "ay", and "az", from the Message window to the Real-Time Plotter window
  6. Stop the "server" process and restart to begin the capture of calibration related information
  7. Begin aircraft manipulations - "Flat/Flip/Edge Stepping Rotation"
    1. Place on a flat surface in the "normal" position, wait 10 seconds
    2. Flip aircraft top down on the flat surface, wait 10 seconds
    3. Hold aircraft on edge, perpendicular to the flat surface, wait 10 seconds
    4. Rotate craft 90 degrees on edge, still perpendicular to the flat surface, wait 10 seconds
    5. Rotate craft another 90 degrees on edge, still perpendicular to the flat surface, wait 10 seconds
    6. Rotate craft the final 90 degrees on edge, still perpendicular to the flat surface, wait 10 seconds
  8. Stop the "server" process to finish the data capture

From the command line, run the "calibrate.py" tool over the collected accelerometer sensor data 

python ./sw/tools/calibration/calibrate.py -s ACCEL -p ./var/logs/15_02_18__18_19_04.data

Copy and paste the resulting displayed ACCEL values into the IMU section of the aircraft configuration file

File: conf/airframes/HooperFly/teensyfly_hexa_lisa_mx_20.xml 
  <section name="IMU" prefix="IMU_">
    ...
    <define name="ACCEL_X_NEUTRAL" value="36"/>
    <define name="ACCEL_Y_NEUTRAL" value="15"/>
    <define name="ACCEL_Z_NEUTRAL" value="-108"/>
    <define name="ACCEL_X_SENS" value="4.86727226621" integer="16"/>
    <define name="ACCEL_Y_SENS" value="4.87315360311" integer="16"/>
    <define name="ACCEL_Z_SENS" value="4.85264051322" integer="16"/>
    ...
  </section>

Save the aircraft configuration file and upload the new firmware 

make AIRCRAFT=Teensy_Fly_Quad clean_ac ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1

Magnetometer

  1. Power up the flight controller/IMU circuitry on your aircraft with a functioning telemetry radio
  2. Start paparazzi
  3. Run the session that connects the ground station telemetry to the aircraft
  4. In the "Settings" tab for the aircraft select the "raw sensors" and commit
  5. Viewing sensor data in real-time (optional step)
    1. Open the "Messages" tool and select the "IMU_MAG_RAW"
    2. Open the "Real-Time Plotter" tool and reduce the "Update time" slider to the far left (smaller the value, the faster the update)
    3. Drag and drop the IMU_MAG_RAW fields "mx", "my", and "mz", from the Message window to the Real-Time Plotter window
  6. Stop the "server" process and restart to begin the capture of calibration related information
  7. Begin aircraft manipulation "Global Bee Dance"
    1. Hold craft out from body and rotate frame about axis parallel to the ground while rotating your body slower than the craft is spinning
    2. Continue this motion until your body has completed 360 degrees of rotation
    3. Turn the craft 90 degrees on edge and repeat the process
    4. Hold craft out from body and rotate frame about axis parallel to the ground while rotating your body slower than the craft is spinning
    5. Continue this motion until your body has completed 360 degrees of rotation
  8. Stop the "server" process to finish the data capture

From the command line, run the "calibrate.py" tool over the collected magnetometer sensor data 

python ./sw/tools/calibration/calibrate.py -s MAG -p ./var/logs/15_02_18__18_26_49.data

Copy and paste the resulting displayed MAG values into the IMU section of the aircraft configuration file

File: conf/airframes/HooperFly/teensyfly_hexa_lisa_mx_20.xml 
  <section name="IMU" prefix="IMU_">
    ...
    <define name="MAG_X_NEUTRAL" value="262"/>
    <define name="MAG_Y_NEUTRAL" value="-108"/>
    <define name="MAG_Z_NEUTRAL" value="43"/>
    <define name="MAG_X_SENS" value="3.26330433172" integer="16"/>
    <define name="MAG_Y_SENS" value="3.22600231318" integer="16"/>
    <define name="MAG_Z_SENS" value="3.76287398848" integer="16"/>
    ...
  </section>

Save the aircraft configuration file and upload the new firmware 

make AIRCRAFT=Teensy_Fly_Quad ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1

Notes

Calibrating the magnetometer of a RacerPEX Hexa class aircraft is difficult based on it's size. Rotating an aircraft of that size is awkward and, depending on your arm length, very challenging.

Current Calibration

IMPORTANT: Mounted propellers are needed when performing current calibration. The aircraft needs to be safely secured and stable to allow the propellers/motors to reach maximum throttle for this test. Strong straps, zip ties, etc... are useful for securing the copter to a flat, stable surface for testing.

References

Add send_imu_mag_current module to airframe file:

File: conf/airframes/HooperFly/teensyfly_hexa_lisa_mx_20.xml 
  <modules>
    <load name="send_imu_mag_current.xml"/>
    ...
  </modules>

Add MILLIAMP_AT_IDLE_THROTTLE and MILLIAMP_AT_FULL_THROTTLE to battery section in airframe file. As an initial approximation, multiplied the MILLIAMP_AT_FULL_THROTTLE by 0.10 to derive the MILLIAMP_AT_IDLE_VALUE. The message tool along with the mag_calibration setting could also be used to measure this value:

File: conf/airframes/HooperFly/teensyfly_hexa_lisa_mx_20.xml 
  <section name="BAT">
     <define name="MILLIAMP_AT_IDLE_THROTTLE" value="5880" />
     <define name="MILLIAMP_AT_FULL_THROTTLE" value="58800"/>
    ...
  </section>

Process

  • Startup the paparazzi control center
  • Start a session for the aircraft under test with propellers. Be sure that the craft is secured and safe to operate under full throttle.
  • On the Modules tab in Settings, select 'Start' button for the send_imu_mag line and commit

Mag current calib module.png

  • On the TX, enable motors and slowly sweep the throttle up to maximum.
  • On the Modules tab in Settings, select 'Stop' button for the IMU_MAG_CURRENT_CALIBRATION messages and commit
  • Kill the motors

Contents of the IMU_MAG_CURRENT_CALIBRATION message as displayed in the Messages tool: Mag current calib messages.png

From the command line, run the "calibrate_mag_current.py" tool over the collected magnetometer sensor data 

$ python ./sw/tools/calibration/calibrate_mag_current.py var/logs/mag_current_tune_15_03_11__16_50_58.data

<define name= "MAG_X_CURRENT_COEF" value="-0.0140313409241"/>
<define name= "MAG_Y_CURRENT_COEF" value="-0.00949491888244"/>
<define name= "MAG_Z_CURRENT_COEF" value="-0.0151296129399"/>

Copy and paste the resulting displayed MAG_*_CURRENT_COEF values into the IMU section of the aircraft configuration file

File: conf/airframes/HooperFly/teensyfly_hexa_lisa_mx_20.xml 
 <section name="IMU" prefix="IMU_">
    ...
    <define name= "MAG_X_CURRENT_COEF" value="-0.0140313409241"/>
    <define name= "MAG_Y_CURRENT_COEF" value="-0.00949491888244"/>
    <define name= "MAG_Z_CURRENT_COEF" value="-0.0151296129399"/>
    ...
  </section>

Save the aircraft configuration file and upload the new firmware 

make AIRCRAFT=Teensy_Fly_Hexa clean_ac ap.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1

Hover - In Flight Tuning

Reference

ESC/Actuator Setup

IMPORTANT: Remove propellers before proceeding with ESC/Actuator setup. Once the actuators are calibrated, re-flash the autopilot with the appropriate firmware prior to mounting the propellers. Do some live testing of the motors with the newly calibrated actuators in combination with your transmitter before you add propellers.

Flash Lisa/MX with Setup Firmware

  • Start the Paparazzi Center and choose "setup_lisamx_20" as the aircraft
  • Compile the "setup_actuators" target
  • Connect the BMP including the serial line to UART2
  • On the command line, flash the firmware using the following command:
make AIRCRAFT=setup_lisamx_20 setup_actuators.upload BMP_PORT=/dev/cu.usbmodemE2B9BDC1

Setup - Unified Power System

For autopilots and ESCs that are powered from a unified/single connection use the following steps:

In the Paparazzi Center, execute the "Messages and Settings" session

  1. Unplug power
  2. Plug in power (the pwm outputs are not active until you commit a setting through the settings app)
  3. Set the first actuator output to 2000
  4. Submit with green check mark (you should hear all the esc beep)
  5. Set the first actuator output to 1000
  6. Submit with the green check mark (you will hear the first esc beep)
  7. Return to step 1 and repeat this procedure for each of the remaining actuators

Setup - Dual Power System

For autopilots and ESCs that are powered from separate connections use the following steps:

In the Paparazzi Center, execute the "Messages and Settings" session

  1. Unplug all power
  2. Plugin autopilot power
  3. Set all actuators in the settings app to 2000
  4. Submit all actuators settings using the green check mark
  5. Plugin ESC power (all esc should beep)
  6. Set all actuators in the settings app to 1000
  7. Submit all actuators settings using the green check mark (for each submitted value the corresponding esc should beep)
  8. Setup of the actuators is complete

PWM Parameters in Airframe File

After doing this the 0 value for the esc is 1000 and max is 2000. The motor should not turn on before you give it less than 1065 making the 1100 setting in the airframe file is a good value to use for neutral (motors running at idle), 1000 for minimum (motors off) and 1900 for maximum throttle.


File: conf/airframes/HooperFly/teensyfly_quad_lisa_mx_20.xml 
 <servos driver="Pwm">
    <servo name="FRONT_LEFT"  no="0" min="1000" neutral="1100" max="1900"/>
    <servo name="FRONT_RIGHT" no="1" min="1000" neutral="1100" max="1900"/>
    <servo name="BACK_RIGHT"  no="2" min="1000" neutral="1100" max="1900"/>
    <servo name="BACK_LEFT"   no="3" min="1000" neutral="1100" max="1900"/>
 </servos>

IMPORTANT: Once the actuators are calibrated, re-flash the autopilot with the appropriate firmware prior to mounting the propellers. Do some live testing of the motors with the newly calibrated actuators in combination with your transmitter before you add propellers.

Flashing SimonK ESC's with BLHeli

When using the following SimonK flashed ESC: Rctimer Mini ESC16A OPTO SimonK Firmware, reference the BLHeli Programming Adapters document for flashing instructions.

PID Tuning

Attitude Control Section

Real-Time Tuning with Attitude Stabilization Sliders

Teensyfly quad pid.png

Update and Save Changes to Airframe File

File: conf/airframes/HooperFly/teensyfly_quad_lisa_mx_20.xml 
  <section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_">
    <!-- setpoints -->
    <define name="SP_MAX_PHI"     value="45." unit="deg"/>
    <define name="SP_MAX_THETA"   value="45." unit="deg"/>
    <define name="SP_MAX_R"       value="90." unit="deg/s"/>
    <define name="DEADBAND_A"     value="0"/>
    <define name="DEADBAND_E"     value="0"/>
    <define name="DEADBAND_R"     value="250"/>

    <!-- reference -->
    <define name="REF_OMEGA_P"  value="400" unit="deg/s"/>
    <define name="REF_ZETA_P"   value="0.85"/>
    <define name="REF_MAX_P"    value="400." unit="deg/s"/>
    <define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/>

    <define name="REF_OMEGA_Q"  value="400" unit="deg/s"/>
    <define name="REF_ZETA_Q"   value="0.85"/>
    <define name="REF_MAX_Q"    value="400." unit="deg/s"/>
    <define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/>

    <define name="REF_OMEGA_R"  value="250" unit="deg/s"/>
    <define name="REF_ZETA_R"   value="0.85"/>
    <define name="REF_MAX_R"    value="180." unit="deg/s"/>
    <define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/>

    <!-- feedback -->
    <define name="PHI_PGAIN"  value="500"/>
    <define name="PHI_DGAIN"  value="200"/>
    <define name="PHI_IGAIN"  value="200"/>

    <define name="THETA_PGAIN"  value="500"/>
    <define name="THETA_DGAIN"  value="200"/>
    <define name="THETA_IGAIN"  value="200"/>

    <define name="PSI_PGAIN"  value="1350"/>
    <define name="PSI_DGAIN"  value="500"/>
    <define name="PSI_IGAIN"  value="10"/>

    <!-- feedforward -->
    <define name="PHI_DDGAIN"   value="300"/>
    <define name="THETA_DDGAIN" value="300"/>
    <define name="PSI_DDGAIN"   value="300"/>
  </section>

NOTE: Compile and re-flash firmware to persist PID modifications

Sensor Analysis: Accel/Gyro/Mag

  • Collect/capture scaled IMU messages during flight testing
  • Use the "report_imu_scaled" tool to quickly analyze and generate metrics related to the captured flight data
./sw/tools/calibration/report_imu_scaled.py -p -s 100 -e 220 ../../paparazzi/var/logs/15_04_04__16_50_40.data

Accel (vibration)

ACCEL : Time Range(100.006 : 220.982)
         ax      ay      az
Min   [ -2.413  -2.507 -24.158] m/s2
Max   [  2.170   2.066   7.477] m/s2
Mean  [ -0.019  -0.580  -9.549] m/s2
StDev [  0.731   0.758   5.936] m/s2

150404 165049 accel.png

Gyro

GYRO : Time Range(100.342 : 220.998)
         gp      gq      gr
Min   [-50.358 -47.924 -38.048] deg/s
Max   [ 51.574  47.000  25.668] deg/s
Mean  [  0.661   0.019  -0.849] deg/s
StDev [ 17.431  15.366   5.136] deg/s

150404 165040 gyro.png

Mag (EMI)

MAG : Time Range(100.022 : 220.934)
         mx      my      mz
Min   [ -0.534  -0.594   0.953] unit
Max   [  0.089   0.000   1.079] unit
Mean  [ -0.201  -0.405   1.019] unit
StDev [  0.163   0.083   0.019] unit

150404 165040 mag.png

Manual Flight (ATT)

First flights are conducted using RC control only. Any issues related to normal/manual flight should be addressed before attempting more autonomous forms of flight.

  • Program Lisa MX manual flight mode: ATT -- AP_MODE_ATTITUDE_DIRECT
  • GPS and Xbee Telemetry not required but are useful if mounted for monitoring flight characteristics with Paparazzi
    • Note telemetry and GPS data while running manual test flights as a correlation exercise with respect to expected vs. observed data
  • Verify all flight systems are stable, reliable and behaving as expected before attempting more advanced flight modes

Test Plan

  • Prior to flight:
    • Verify TX correctly enters ATT flight mode when the FLAP switch is toggled from 0 --> 1 and the ELEV D/R switch is 0
  • Verify the idle arming of the motors using the throttle/yaw stick
  • Verify the KILL mode assigned to the GEAR toggle switch. Toggling the GEAR switch from 1 (live) --> 0 (kill)
  • Verify responsive throttle, pitch, roll and yaw behavior

Flight Log

  • Saturday, 2015-02-21 : (Sunny/Calm) Flew both the LisaMX TeensyFly Quad and Hexa at the test field. Both aircraft are stable and responsive in manual flight mode.
  • Monday, 2015-02-23 : (Sunny/Calm) Flew both the LisaMX TeensyFly Quad and Hexa at the test field. Once again, both aircraft flew stable and responsive in manual flight mode.

Hybrid Flight (HOVER)

  • Program Lisa MX auto1 flight mode: H_ZH -- AP_MODE_HOVER_Z_HOLD
  • Mount GPS and Xbee Telemetry for monitoring flight characteristics with Paparazzi
  • Verify all flight systems are stable, reliable and behaving as expected before attempting fully autonomous flight modes

Test Plan

Reference Rotorcraft Control Loops

  • Prior to flight:
    • Verify TX correctly enters ATT flight mode when the FLAP switch is toggled from 0 --> 1 and the ELEV D/R switch is 0
    • Verify TX correctly enters H_ZH flight mode when the FLAP switch is 1 and the ELEV D/R switch is toggled from 0 --> 1
  • Wait for GEO_INIT to complete
  • Switch to ATT mode, take off
  • Establish a hover position about 5 meters above deck
  • Switch from ATT mode to H_ZH mode (hover)
  • Move throttle to 100% while in H_ZH mode
  • Aircraft should now be in a 3D locked hover
  • Verify flight characteristics based on the hover mode. Evaluate roll, yaw and pitch RC inputs.

Flight Log

  • Saturday, 2015-02-28 : (Sunny/Wind 10mph) Flew the LisaMX TeensyFly Hexa at the test field and tried the above test plan. Test went as planned but the H_ZH behavior was not as expected. When switching from ATT to H_ZH, I had the throttle set to approx. 60%. The craft would stay stable for about 2-3 seconds and then deviate off axis and begin to accelerate in the direction of deviation. I could quickly recover the craft by switching back to ATT mode and to a more predictable response from the craft.
    • Log/Data File: $PAPARAZZI_HOME/var/logs/zhz_t1_15_02_28__17_02_29
    • Cover barometer sensor with foam/tape being sure not to plug either of the two holes
    • Review flight log files (See Log Replay tool)
    • Verify the hover throttle level and update the vertical guidance value in the airframe to reflect that value in decimal form. (i.e. 50% throttle = .5)
      • NOTE: The CLIMB rate specified in the flight plan should also be reviewed to verify an appropriate throttle level
    • Move HOME point more north in the field to allow for more flight buffer along the south side of the flight perimeter
    • Move waypoints: CAM and 2 a little closer to HOME
    • Re-flash LisaMX with updates
  • Sunday, 2015-03-01 : (Sunny-Overcast/Calm) Flew the LisaMX TeensyFly Hexa at the test field. Successfully managed to fly in 3D Hover(H_ZH) for an extended period of time. Flew three batteries for an average of about 7 minutes each for a total in air time of about 21 minutes. Also attempted to switch into NAV mode from H_ZH to see how the aircraft would react. It looks like the vertical guidance parameter related to throttle still needs to be increased a bit. New target is .61 = 61% throttle for a nominal hover value; today's mission was at .58 = 58% throttle. The xbee telemetry module on the aircraft stopped functioning after the third flight putting an end to the days flight tests.
    • Log/Data File: $PAPARAZZI_HOME/var/logs/zhz_t2_15_03_01__15_57_36
    • Review flight log files (See Log Replay tool)
    • Update nominal throttle value from .58 to .61 in the airframe file.
    • Check xbee telemetry radio on the aircraft to understand why it is non-functioning.
    • Elevate the GPS RX off of the aircraft deck to see if that improves the 3D lock characteristics of the flights.
    • Review the vertical and horizontal guidance loops and the various inputs/behaviors.
      • Investigate using real-time loop tuning of the vertical and horizontal guidance values from the Settings tool
    • Re-flash LisaMX with updates
  • Tuesday, 2015-03-03 : (Sunny/Calm) Measured IMU data for the purposes of vibration analysis. Monitor scaled_sensors using the Settings tool.
    • Flight 1:
      • Procedure: TeensyFly Hexa in ATT and H_ZH
      • Log/Data File: $PAPARAZZI_HOME/var/logs/vibe_t1__15_03_03__13_13_42
    • Flight 2:
      • Procedure: Removed propellers from TeensyFly Hexa and suspended it in a stable string harness.
      • Log/Data File: $PAPARAZZI_HOME/var/logs/vibe_t2_15_03_03__15_39_00
    • Profile frame vibrations using the IMU scaled_sensor parameters in the log and real-time plotter tools: plot & plotter
      • Look at the full spectrum of flight modes: takeoff, hover, climb, descend, pitch variants, roll variants, yaw variants
      • Anything greater than 9.9m/s on the accelerometer is over the limit
    • Balance props
    • Re-flash LisaMX with updates
  • Wed/Thur, 2015-03-04/05 : (Sunny/Calm) Two days devoted to understanding how the aircraft/TX/GCS interact when transitioning from Z_HZ to NAV mode.
    • Observe how the aircraft behaves during the start engine/takeoff/standby NAV sequence
    • Attempt multiple NAV takeoffs to become familiar with TX/GCS interaction
    • Need to increase the climb rate on takeoff in NAV mode( change from .65 to .75). A little too slow/minimal based on observations.
    • Increase the initial ground_alt from 45m to 46m
    • Compile and Re-flash LisaMX with updates
    • Work on fine tuning the hover in Z_HZ by capturing the tune_hover telemetry during the next set of flights
  • Saturday, 2015-03-07 : (Sunny/Calm) Two flights to capture tune_hover telemetry. First flight in ATT and the second in H_ZH.
    • Analyzed data based on pitch, yaw and roll for the respective RC/Command/Body parameters
    • As expected, the H_ZH mode is less stable and requires more RC stick to maintain hover.
      • Log/Data File: $PAPARAZZI_HOME/var/logs/hover_tune_15_03_07__10_55_42
      • Plot: Hover Tune Data 2015-03-07 at 1.07.32 PM
  • Sunday, 2015-03-08 : (Sunny/Calm) One flight with Piotr to get his thoughts on how well the craft is flying in ATT and H_ZH mode.
    • In H_ZH, the copter is "toilet bowling" a bit probably due to magnetometer interference related to DC currents/motors on craft.
      • Profile current using the mag_current_calibration process. Update the firmware and see if it performs better.
  • Tuesday, 2015-03-10 : (Sunny/Calm) Successfully achieved an autonomous hover in H_ZH mode. Three flights, averaging about 7 minutes in stable H_ZH mode.
  • Monday, 2015-03-16 : (Sunny/Calm) Attempted a take-off in NAV mode. The aircraft did not rise up with any authority and seemed to "wallow" around. Decided to try and fly a hover flight to make sure that aircraft was stable. Experienced drift in the hover flights and, ultimately, had to stop testing due to an Xbee telemetry module bricking.
    • Recovered the bricked Xbee at home
    • Considering developing improved vibration damping autopilot mounts
    • Considering better/improve wiring/electronics placement to reduce magnetic interference
    • Investigate vibration and electromagnetic interference mitigation strategies/solutions
    • Rebuild the TeensyFly Hexa using vibration/electromagnetic mitigation techniques and repeat all the necessary calibration and test completed up to this point.
      • NOTE: Archive the existing airframe configuration and assign it a revision number (i.e. teensyfly_hexa_lisa_mx_20.xml --> teensyfly_hexa_lisa_mx_20_v001.xml)
  • Wednesday, 2015-04-15 : (Sunny/Calm) Autonomous hover in H_ZH mode is now reliable. Two flights, at about 8 minutes each in stable H_ZH mode. Time to move on to NAV testing.

Autonomous Flight (NAV)

  • Define a thoughtful flight plan with the appropriate safety features for limiting flyaway risk
  • Identify and take GPS measurements of the area to be used for testing. Also see Maps
  • Incorporate GPS measurements/data into a flight plan and simulate until satisfied with behaviors
  • Program Lisa MX to include a full navigation flight mode: AP_MODE_NAV (a.k.a. NAV)
  • TBD: Establish a set of pre-flight system checks

Test Plan

  • Prior to flight:
    • Verify TX correctly enters ATT flight mode when the FLAP switch is toggled from 0 --> 1 and the ELEV D/R switch is 0
    • Verify TX correctly enters H_ZH flight mode when the FLAP switch is 1 and the ELEV D/R switch is toggled from 0 --> 1
    • Verify TX correctly enters NAV flight mode when the FLAP switch is toggled from 1 --> 0 and the ELEV D/R switch is 1
  • Take off in ATT mode and fly to STDBY waypoint altitude and GPS coordinate
  • Switch from ATT mode to H_ZH mode (hover). Verify that aircraft is maintaining the STDBY position.
  • Switch to NAV (position hold). Verify that the aircraft is maintaining the STDBY position.
  • In GCS, select Stay_s1 (stay and hold position at point S1). Verify that aircraft is holding at waypoint s1.
  • Fly a line S1 -> S2 -> S1 and hold
  • Switch over to ATT mode again and land

The flight plan only needs to have the geo init part, hold position S1 and the line blocks for this test.

Once comfortable, expand this test to include autonomous takeoff and landing and start to improve the flight plan.

Flight Log

  • Thursday, 2015-04-16 : (Sunny/Winds: 6 mph) Flew a successful NAV flight that included an autonomous take-off as well. Full NAV take-off, STDBY, Hold S1, Line S1->S2->. Switched to ATT mode and landed. Flight was flow in a small area approximately 40' in diameter. Next step is to repeat this flight at the flying field and begin exploring other waypoint sets.
  • Friday, 2015-04-17 : (Sunny/Winds: 15 mph) Successful NAV flight start-to-finish: take-off, stay at STDBY for 2 minutes, land at TD waypoint. Flight went really well.
  • Monday, 2015-04-20 : (Sunny/Calm) Worked with Piotr to put TeensyFly through the complete set of flight blocks contained in the sample flight plan. Flew multiple flights. Discovered that the GPS unit has a tendency to wonder at times and took a "long time" to converge to an acceptable resolution <10m. Also added 10m of elevation to the waypoints to avoid any "Z drift" related GPS inaccuracies. Another anomaly related to initiating the circle CAM action was observed. It successfully completed the CAM nav block but upon entry the craft became unstable and seemed to be seeking to catchup with the carrot. The craft did recover on its own and complete the CAM nav action. See graph of carrot_psi vs. psi.
    • Review of the flight replay is consistent with observed behavior as well as why it occurred; reference logged data for flight 15_04_20__16_23_52.
    • Investigate GPS performance issues including checking the software init/config of the device as well as ground plane shielding.

TF CAMnav carrot observation.png

  • Friday, 2015-04-24 : (Overcast/Showers) Flew two separate flights exercising all the NAV blocks. Worked perfect.
  • Monday, 2015-04-27 : (Sunny/Calm) Flew three separate flights exercising all the NAV blocks. Worked as expected. Grey and Esme were in attendance.
  • Wednesday, 2015-04-29 : (Sunny/Calm) Testing survey_rectangle NAV blocks. Flew four flights: first flight had issues related to GPS wandering, remaining three flights worked well. The aircraft successfully navigated both survey_rectangle NS and LO blocks.

Survey rectangle NS 201504029.png

  • May, 2015: Averaged about 20 flights a week during May. Focused on testing and refining flight plans as they relate to NAV flight. Tested survey and poly-survey as well as experiment with NIR aerial photography. The main focus was on refining the TeensyFly Hexa flights and behavior.
  • Saturday, 2015-05-30 : (Sunny/Calm) Built up a new RacerPEX Quad for LisaMX testing and started the tuning process. Based on inflight early sensor analysis, vibration is an issue at this point with respect to flying reliably in NAV.
./report_imu_scaled.py -p -s 390 -e 580 ../../paparazzi/var/logs/15_05_30__20_39_39.data

ACCEL : Time Range(390.069 : 580.945)
         ax      ay      az
Min   [-28.800 -19.145 -114.258] m/s2
Max   [ 27.211  15.464  71.604] m/s2
Mean  [ -0.008   0.187  -9.315] m/s2
StDev [  9.117   4.667  32.285] m/s2

GYRO : Time Range(390.021 : 580.977)
         gp      gq      gr
Min   [-233.827 -204.256 -78.656] deg/s
Max   [261.635 187.917  79.621] deg/s
Mean  [  0.405   0.885   1.340] deg/s
StDev [ 79.282  57.455  27.960] deg/s

MAG : Time Range(390.037 : 580.976)
         mx      my      mz
Min   [ -0.001  -0.504  -0.593] unit
Max   [  0.717   0.250   0.676] unit
Mean  [  0.306  -0.150   0.207] unit
StDev [  0.073   0.094   0.156] unit
  • Sunday, 2015-05-31 : (Sunny/Calm) Removed props from motors on the RacerPEX to capture baseline vibration numbers. Based on the numbers it looks like unbalance props may be a large contributor to the vibration. Balanced the props and did a quick test flight. The aircraft is much more stable. Next up, a magnetic current calibration and collection of inflight vibration data post prop balancing. Completed current calibration and collected new inflight vibration data.
./report_imu_scaled.py -p -s 300 -e 570 ../../paparazzi/var/logs/15_05_31__19_59_59.data

ACCEL : Time Range(300.055 : 570.945)
         ax      ay      az
Min   [-12.620  -6.953 -50.022] m/s2
Max   [  9.855   7.456  30.894] m/s2
Mean  [ -0.108   0.315  -9.835] m/s2
StDev [  2.890   1.880  10.825] m/s2

GYRO : Time Range(300.007 : 570.961)
         gp      gq      gr
Min   [-155.661 -117.739 -40.482] deg/s
Max   [140.973 104.506  45.238] deg/s
Mean  [ -0.621   1.782   0.382] deg/s
StDev [ 34.829  32.607  15.166] deg/s

MAG : Time Range(300.039 : 570.961)
         mx      my      mz
Min   [  0.000  -0.705   0.250] unit
Max   [  0.313  -0.042   0.982] unit
Mean  [  0.165  -0.362   0.713] unit
StDev [  0.036   0.063   0.085] unit
  • Sunday, 2015-07-05 : (Sunny/Calm) SiK radios testing for multiple aircraft flights. Initial tests with only two aircraft, TeensyFly Hexa and a RacerPEX Quad. Verify ground station interaction as well as simple arm/disarm capabilities. Currently both aircraft are bound to a single TX for non-flight testing that includes motors on/off. Interaction with the aircraft was non-deterministic and the radio configuration is probably the issue. Used two air telemetry radios and one ground telemetry radio all set to the same NET_ID. Guessing that the frequency hopping features were in contention between the two air radios as the ground radio tried to match. Plan of action is to create air/ground telemetry pairs, where each radio pair shares a unique NET_ID.
  • Thursday, 2015-07-09 : (Sunny/Calm) Flashed latest SiK firmware (v1.9) to two of the telemetry radios. Set the NET_ID's for each air/ground telemetry pair to a unique IDs. Tested two air/ground pairs with respect to arming/disarming motors. All tests successful.
  • Saturday, 2015-07-11 : (Cloudy/2-3mph winds) Reprogrammed and flew Neon RacerPEX Quad in the cul-de-sac in full NAV. Surprisingly good flight. Clean take-off, exercised waypoints and pano blocks, smooth landing. The best autonomous flight of the Neon RacerPEX Quad to date. Latest releases of PaparazziUAV seem to be more stable with respect to yaw behavior.
  • Sunday, 2015-07-12 : (Partly Cloud/4-5mph winds) Successfully flew a single autonomous NAV mission with two aircraft: the Neon RacerPEX Quad and TeensyFly Hexa. Take-off, waypoint goals and landing all in NAV mode for both aircraft. Telemetry radios worked well and the aircraft were stable.
  • Thursday, 2015-07-16 : (Sunny/4-5mph winds) Loaded the latest paparazzi/master firmware to test HooperFly branch integrations. Flew a TeensyFly Hexa and the Neon RacerPEX in ATT, HZ_H, and NAV. All systems are go.
  • Thursday, 2015-07-19 : (Sunny/Calm) Flew RP-Quad and TF-Hexa combined NAV missions using the latest paparazzi/master firmware. All aircraft performed exceptionally well. Shot some video of the flights and hope to edit for display at OSCON 2015.
  • Monday, 2015-09-07 : (Sunny/Calm) Flew TF-Quad and TF-Quad Elle in NAV, each on their own. Followed up with a tandem flight with both of them. Noticed a few GPS glitches in the flights. Based on these flights, it's a go to fly four aircraft.
  • Tuesday, 2015-09-08 : (Sunny/Calm) Flew TF-Quad, TF-Quad Elle, TF-Hexa, and RP-Quad in NAV. Simple take-off, hover, land sequences. Flew four repetitions of the sequence on a single battery per aircraft. A few GPS issues occurred during the flights but nothing catastrophic where the mission had to be aborted. Simply switched to H_ZH mode for all craft and back to NAV to complete the sequence.
  • Tuesday, 2015-09-09 : (Sunny/Calm) Spent some 1-on-1 time with the TF-Quad Elle. Initial NAV flight takeoff resulted in a hard enough impact to decouple the flight controller. That set the tone for the rest of the session. The aircraft was not consistent in it's flight. Decided to take it back to the shop and recalibrate all the sensors. Subsequent flight after calibration was much improved and the aircraft is very stable once again.
  • Tuesday, 2015-09-10 : (Sunny/Calm) Two flight sessions at the test field. First session was focused on NAV flight of each aircraft that included TF-Quad, TF-Quad Elle, TF-Hexa, and RP-Quad. Noticed the TF-Quads losing altitude between set points. Need to up the vertical gains possibly. The second session was focused on a pair flight with TF-Quad Elle and TF-Hexa as well as testing vertical guidance changes for RP-Quad. Both flights went really well and managed to complete their missions without any major anomalies. The TF-Quad Elle needs to have it's vertical gains increased to reduce the sag between set points.

Mode Flight Rating

This is a simple rating system for the various HooperFly aircraft based on actual flights in ATT, H_ZH, and NAV mode. The goal is to develop a method for evaluating and minimizing risk when flying each aircraft in a multi-aircraft scenario. A grade is given to each flight mode for each aircraft based on observed flight and the ability to complete a set of flight blocks as defined in conf/flight_plans/HooperFly/rotorcraft_multiflight.xml

Mode Flight Ratings
Frame ATT H_ZH NAV
TeensyFly Quad A A A-
TeensyFly Quad Elle A A A-
TeensyFly Hexa A A A-
RacerPEX Quad A- A- B+
RacerPEX Hexa A C ?

Notes

  • 2015-08-25: Based on multiple flight tests and trying different AHRS settings, I've decide to use a vibration mount on the TeensyFly Quad as well as redesign the center plate for the RacerPEX Hexa. With respect to the TeensyFly Quad, the vibration mount should result in A grade flight ratings across all flight modes. The RacerPEX Hexa design is fine for ATT flying, it's actually quite a good flyer in that mode. The real issue is related to lower frequencies not dampening enough to allow the AHRS to work effectively. The gravity heuristic set to 0 improved it's stability but not enough to pursue NAV flight.
  • 2015-08-26: Went to the field to fly the TeensyFly Quad to verify flight characteristics prior to the overhaul to add a vibration plate. Completed the tear-down and rebuild with the new vibration plate. Initial test flight in ATT and H_ZH look very promising(no GPS installed). Still need to run through the re-calibration of the acc, mag, and mag current. The expectation is that the aircraft will be much more stable in H_ZH and NAV modes.
  • 2015-08-27: Flew the rebuilt TeensyFly Quad in ATT and H_ZH modes with the GPS installed. Very stable and predictable even before recalibration of the acc, mag, and mag current. Need to run through calibration and repeat field testing. Began the teardown of the RacerPEX Hexa in prep for center plate/mass redesign. Promote the ATT and H_ZH grades to A and A- respectively.
  • 2015-08-28: Calibrated acc, mag and mag current for new TeensyFly Quad vibration mount rebuild. Really stable. Promoted H_ZH mode grade from A- to A. Still need to test the NAV functionality at the field. Expect it to perform at least as good as the TeensyFly Hexa.

Goals

  • Autonomous hover (First Success: 2015-03-01, Stable/repeatable behavior: 2015-04-15)
  • Autonomous takeoff (First Success: 2015-04-16, Stable/repeatable behavior: 2015-04-20)
  • Autonomous landing (First Success: 2015-04-17, Stable/repeatable behavior: 2015-04-20)
  • Fully autonomous execution and verification of the rotorcraft_basic flight plan (First Success: 2015-04-20)
    • Includes routes, CAM nav, take-off, landing
  • Survey flights (First Success: 2015-04-29)
    • Integrated a nav_survey_rectangle_rotorcraft module supplied by Eduardo.(2015-04-28)
    • Successfully simulated the module behaviors (2015-04-28)
    • Flew both NS and LO patterns over 3 different flights (2015-04-29)
  • Multiple aircraft flights
    • Flew a two aircraft(Neon RacerPEX Quad/TeensyFly Hexa), fully autonomous mission (2015-07-12)
    • Flew four aircraft(TF Elle, Quad, Hexa, RP Hexa), fully autonomous mission(2015-09-07)
    • MultiUAV
  • Formation/follower flights

Technical Explorations

  • BBB Paparazzi Ground Station
  • BBB OpenCV + Lisa/MX
  • Potential Blender/Bullet Integrations

Paparazzi UAV Project Development and Compilation

Project Related

Environment

OPAM

$ opam list
Installed packages for 4.01.0:
base-bigarray    base  Bigarray library distributed with the OCaml compiler
base-threads     base  Threads library distributed with the OCaml compiler
base-unix        base  Unix library distributed with the OCaml compiler
camlp4         4.01.0  Camlp4 is a system for writing extensible parsers for programming language
ivy             1.2.2  This OCaml-library interfaces the Ivy software bus C-library.
lablgtk        2.18.2  OCaml interface to GTK+
ocamlfind       1.5.3  A library manager for OCaml
ocamlnet        3.7.6  Internet protocols (http, cgi, email etc.) and helper data structures (mai
xml-light         2.4  Xml-Light is a minimal XML parser & printer for OCaml 

$ opam switch
system  I system  System compiler (4.02.0)
4.02.0  I 4.02.0  Official 4.02.0 release
4.01.0  C 4.01.0  Official 4.01.0 release
--     -- 3.11.2  Official 3.11.2 release
--     -- 3.12.1  Official 3.12.1 release
--     -- 4.00.0  Official 4.00.0 release
--     -- 4.00.1  Official 4.00.1 release

$ opam switch 4.01.0
# To complete the configuration of OPAM, you need to run:
eval `opam config env`

$ eval `opam config env`


Command Line Tools

Ivyprobe

With the command line tool ivyprobe, you can see what is being sent over the IVY bus. 

$ ivyprobe -help
ivyprobe: illegal option -- h
usage: ivyprobe [options] [regexps]
	-b bus	defines the Ivy bus to which to connect to, defaults to 127:2010
	-t	triggers the timer test
	-n name	changes the name of the agent, defaults to IVYPROBE
	-v	prints the ivy relase number

regexp is a Perl5 compatible regular expression (see ivyprobe(1) and pcrepattern(3) for more info
use .help within ivyprobe
	-s bindcall	active the interception of regexp's subscribing or unscribing
	-f regexfile	read list of regexp's from file one by line
	-c msg1,msg2,msg3,...	filter the regexp's not beginning with words

The following command will display all packages with all their content: 

ivyprobe "(.*)"

You can constrain what ivyprobe displays by extending the regular expression for example, the following command will display raw accelerometer data that is being sent over the IVY bus 

ivyprobe “[\d]+ IMU_ACCEL_RAW (.*)”

ivyprobe takes that regular expression and prints the match inside the (), by default it is only showing telemetry:*

Note: The packages/class names returned by ivyprobe can be used as input to the messages tool.

Messages

$ ./messages -help
Usage: 
  -b <ivy bus> Default is 224.255.255.255:2010
  -c class name
  -help  Display this list of options
  --help  Display this list of options

GCS

$ ./gcs -help
Usage: 
  -auto_ortho IGN tiles path
  -b <ivy bus> Default is 224.255.255.255:2010
  -center Initial map center (e.g. 'WGS84 43.605 1.443')
  -center_ac Centers the map on any new A/C
  -edit Flight plan editor
  -fullscreen Fullscreen window
  -maps_fill Automatically start loading background maps
  -maps_zoom Background maps zoomlevel (default: 20, min: 18, max: 22)
  -ign IGN tiles path
  -lambertIIe Switch to LambertIIe projection
  -layout <XML layout specification> GUI layout. Default: horizontal.xml
  -m Map XML description file
  -maximize Maximize window
  -mercator Switch to Mercator projection, default
  -mplayer Launch mplayer with the given argument as X plugin
  -no_alarm Disables alarm page
  -maps_no_http Switch off downloading of maps, always use cached maps
  -ortho IGN tiles path
  -osm Use OpenStreetMap database (default is Google)
  -ms Use Microsoft maps database (default is Google)
  -particules Display particules
  -plugin External X application (launched with the id of the plugin window as argument)
  -ref Geographic ref (e.g. 'WGS84 43.605 1.443')
  -speech Enable vocal messages
  -srtm Enable SRTM elevation display
  -track_size Default track length (500)
  -utm Switch to UTM local projection
  -wid <window id> Id of an existing window to be attached to
  -zoom Initial zoom
  -auto_hide_fp Automatically hide flight plans of unselected aircraft
  -help  Display this list of options
  --help  Display this list of options

Link

$ ./sw/ground_segment/tmtc/link --help
Usage: 
Usage: 
  -b <ivy bus> Default is 224.255.255.255:2010
  -d <port> Default is /dev/ttyUSB0
  -fg Enable trafic statistics on standard output
  -noac_info Disables AC traffic info (uplink).
  -nouplink Disables the uplink (from the ground to the aircraft).
  -s <baudrate>  Default is 9600
  -hfc Enable UART hardware flow control (CTS/RTS)
  -local_timestamp Add local timestamp to messages sent over ivy
  -transport <transport> Available protocols are modem,pprz,pprz2 and xbee. Default is pprz
  -udp Listen a UDP connection on <udp_port>
  -udp_port <UDP port> Default is 4242
  -udp_uplink_port <UDP uplink port> Default is 4243
  -udp_broadcast Broadcast on <udp_broadcast_addr>, e.g. for multiple simulated aircrafts
  -udp_broadcast_addr <addr> Broadcast address. Default is 224.255.255.255
  -uplink Deprecated (now default)
  -xbee_addr <my_addr> (256)
  -xbee_retries <nb retries> (10)
  -xbee_868 Enables the 868 protocol
  -redlink Sets whether the link is a redundant link. Set this flag and the id flag to use multiple links
  -id <id> Sets the link id. If multiple links are used, each must have a unique id. Default is -1
  -status_period <period> Sets the period (in ms) of the LINK_REPORT status message. Default is 1000
  -ping_period <period> Sets the period (in ms) of the PING message sent to aircrafs. Default is 5000
  -ac_timeout <time> Sets the time (in ms) after which an aircraft is regarded as dead/off if no messages are received. Default is 5000ms, set to zero to disable.
  -help  Display this list of options
  --help  Display this list of options

Server

$ ./server --help
Usage: 
  -b Bus	Default is 224.255.255.255:2010
  -hostname <hostname> Set the address for the http server
  -http Send http: URLs (default is file:)
  -kml Enable KML file updating
  -kml_no_http KML without web server (local files only)
  -kml_port Port for KML files (default is 8889)
  -n Disable log
  -no_md5_check Disable safety matching of live and current configurations
  -replay_old_log Enable aircraft registering on PPRZ_MODE messages
  -help  Display this list of options
  --help  Display this list of options

Settings

$ ./settings --help
Usage: 
  -b <ivy bus> Default is 224.255.255.255:2010
  -ac A/C name
  -help  Display this list of options
  --help  Display this list of options

Calibrate

$ python ./sw/tools/calibration/calibrate.py -help
Usage: calibrate.py [options] log_filename.data
Run calibrate.py --help to list the options.

Options:
  -h, --help            show this help message and exit
  -i AC_ID, --id=AC_ID  aircraft id to use
  -s SENSOR, --sensor=SENSOR
                        sensor to calibrate (ACCEL, MAG)
  -p, --plot            Show resulting plots
  -a, --auto_threshold  Try to automatically determine noise threshold
  -v, --verbose

Magnetometer Current Calibration

$ python ./sw/tools/calibration/calibrate_mag_current.py -help
Usage: calibrate_mag_current.py [options] log_filename.data
Run calibrate_mag_current.py --help to list the options.

Options:
  -h, --help            show this help message and exit
  -i AC_ID, --id=AC_ID  aircraft id to use
  -p, --plot            Show resulting plots
  -v, --verbose

Play

$ python ./sw/logalizer/play -help
Usage: 
  -b <ivy bus> Default is 224.255.255.255:2010
  -d <port> Default is /dev/ttyUSB0
  -o Output binary messages on serial port
  -s <baudrate>  Default is 9600
  -shfc Enable UART hardware flow control (CTS/RTS)
  -help  Display this list of options
  --help  Display this list of options

Plot/Logplotter

$ ./sw/logalizer/plot -help
Usage: plot <log files>
  -export_csv Export in CSV in batch mode according to saved preferences (conf/%gconf.xml)
  -v Verbose
  -help  Display this list of options
  --help  Display this list of options

$ ./sw/logalizer/logplotter  -help
Usage: logplotter <log files>
  -export_csv Export in CSV in batch mode according to saved preferences (conf/%gconf.xml)
  -v Verbose
  -help  Display this list of options
  --help  Display this list of options

Plotter

$ ./sw/logalizer/plotter -help
Usage: 
  -b <ivy bus> Default is 224.255.255.255:2010
  -c <curve>  Add a curve (e.g. '*:telemetry:BAT:voltage'). The curve is inserted into the last open window (cf -n option)
  -t <title>  Set the last opened window title (cf -n option)
  -g <geometry>  Set the last opened window geometry ( '500x500+100+100' )
  -n Open another window for the next curves
  -m <size>  Memory size (default 500)
  -u <time>  Update time in s (default 0.50)
  -help  Display this list of options
  --help  Display this list of options

Report IMU Scaled

$ ./sw/tools/calibration/report_imu_scaled.py -h
Usage: report_imu_scaled.py [options] log_filename.data
Run report_imu_scaled.py --help to list the options.

Options:
  -h, --help            show this help message and exit
  -i AC_ID, --id=AC_ID  aircraft id to use
  -p, --plot            Show resulting plots
  -s START, --start=START
                        start time in seconds
  -e END, --end=END     end time in seconds
  -v, --verbose

Flying Robot Commander

The flying robot commander is a collection of RESTful web based applications for managing robotic flight using PaparazziUAV. It's currently in alpha development that includes real world flight testing.

Source Code

Currently the code base relies on the python RESTful framework Flask as well as the nginx web server. All source code is managed using the following github repository:

Flying Robot Commander Github Repository

Here's a directory listing for the current set of files that constitute the FRC: 

├── frc.py
├── img
│   ├── aircraft-landing.png
│   ├── aircraft-take-off.png
│   ├── arrow-with-circle-down.png
│   ├── arrow-with-circle-left.png
│   ├── arrow-with-circle-right.png
│   ├── arrow-with-circle-up.png
│   ├── arrows-rotate-clockwise.png
│   ├── arrows-rotate-counterclockwise.png
│   └── propeller.png
├── index.html
├── index_flightblock.html
├── index_guided.html
├── index_waypoint.html
├── url_test.sh

Architecture Overview

The current implementation is highly decoupled to facilitate research and rapid prototyping. As a common set of use cases/models/scenarios are identified, the ability to optimize/collapse behavior is easily achieved. The Flying Robot Commander(FRC) leverages a RESTful web based architecture along with a simple message passing protocol. One of the benefits of using a web based architecture is the ability to deliver the UI to any device that runs a modern browser.

The current UI consists of a set of html files: index.html, index_flightblock.html, index_guided.html, and index_waypoint.html along with image icons(contained in the img folder). The current implementation leverages javascript that submits http get requests to our flying robot commander request server.

Each http request is serviced by the request server: frc.py, currently implemented using a python Flask framework. Subsequently, the server constructs an `IvyMessagesInterface` compliant message and publishes it to the ivy bus for consumption by PaparazziUAV aircraft and ground systems. Also included in the file system is a test file: url_test.sh that interacts directly with the http request server via curl commands for testing purposes.

Videos

Here are a few links to videos showing the flight block and guidance mode interfaces:

Screen Shots

Frc flightblock screen.png Frc guidance screen.png Frc waypoint screen.png

Retrieved from "http://wiki.paparazziuav.org/w/index.php?title=User:Earthpatrol&oldid=23814"