Authentic 3DR Telemetry

Cloned 3DR Telemetry

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:

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.

Power up the autopilot outfitted with a GPS module as well as a working telemetry connection.

Turn on your TX configured to the aircraft under test.

Start Paparazzi and open the appropriate session for your given telemetry link along with the GCS.

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).

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.

Paparazzi Center Upload Using the BMP

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:

Update BMP Firmware for Ubuntu Linux

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

Display Vibration Data with/without Props

Vibration Isolator Mount

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.

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.

GPS - UBLOX LEA-6H

Links

Verify GPS Connection

Touch Device Applications

PPRZONDROID

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

Power up the flight controller/IMU circuitry on your aircraft with a functioning telemetry radio

Start paparazzi

Run the session that connects the ground station telemetry to the aircraft

In the "Settings" tab for the aircraft select the "raw sensors" and commit

Viewing sensor data in real-time (optional step)

Open the "Messages" tool and select the "IMU_ACCEL_RAW"

Open the "Real-Time Plotter" tool and reduce the "Update time" slider to the far left (smaller the value, the faster the update)

Drag and drop the IMU_ACCEL_RAW fields "ax", "ay", and "az", from the Message window to the Real-Time Plotter window

Stop the "server" process and restart to begin the capture of calibration related information

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.

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:

Hover - In Flight Tuning

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

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

Unplug power

Plug in power (the pwm outputs are not active until you commit a setting through the settings app)

Set the first actuator output to 2000

Submit with green check mark (you should hear all the esc beep)

Set the first actuator output to 1000

Submit with the green check mark (you will hear the first esc beep)

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

Unplug all power

Plugin autopilot power

Set all actuators in the settings app to 2000

Submit all actuators settings using the green check mark

Plugin ESC power (all esc should beep)

Set all actuators in the settings app to 1000

Submit all actuators settings using the green check mark (for each submitted value the corresponding esc should beep)

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.

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.

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

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.

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.

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.

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.

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.

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.

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-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.

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.

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

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:

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 spawns a related process: flightblock.py, guidance.py, or waypoint.py that publishes the appropriate message/messages 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: