CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode...

61
CUAir Autopilot Documentation Documentation Release 1.0 Troy Joseph Brendan Quinn Jimmy Stoyell Blake Goodwyn Declan May 24, 2018

Transcript of CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode...

Page 1: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot DocumentationDocumentation

Release 10

Troy Joseph Brendan Quinn Jimmy Stoyell Blake Goodwyn Declan Sander Jesse Lupica Sitar Harel Yasmeen Mushtaq

May 24 2018

Contents

1 Welcome 111 How to edit this page 112 Support 213 License 2

2 Indices and tables 57

i

ii

CHAPTER 1

Welcome

Yay documentation

How to edit this page

Easy Mode

bull Click the ldquoEdit on GitHub button at the top of any pagerdquo

bull Edit the page

bull Click lsquoPreview changesrsquo before committing to make sure you havenrsquot made a mistake with markdown syntax

bull Add a change message and commit when you have finished your changes

bull In a few minutes readthedocs will be updated

Leet Mode

Installation

$ git clone httpsgithubcomCUAirAutopilot$ cd Autopilot$ virtualenv venv$ source venvbinactivate$ pip install -r requirementstxt$ cd docs$ make html

Use

bull To create a page make a new file called foobarrst

bull Add your page to the table of contents in the file indexrst under the api and groundstation pages

bull Edit your page using sphinx markup

bull To see what your page looks like compile it with make html

bull When you are happy with what the page looks like commit your changes with git (git add --all gitcommit -m change message git push)

bull The online documentation will update sometime in the next few minutes

1

CUAir Autopilot Documentation Documentation Release 10

To learn more about how to use sphinx see the following guides

httpwwwsphinx-docorgenstabletutorialhtml

httpwwwsphinx-docorgenstableresthtmlrst-primer

Support

If you are having issues please slack Troy

License

The project may or may not have a license

Contents

Autopilot API endpoints

2 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Autopilot API endpointsndash Status [status]

Attitude [statusattitude] Battery [statusbattery] Armed [statusarmed] Mav Info [statusmav_info] Mav Warning [statusmav_warning] Mav Error [statusmav_error] Safe [statussafe] Link [statuslink] GPS [statusgps] Mode [statusmode] Airspeed [statusairspeed] Wind [statuswind] Climb [statusclimb] Signal [statussignal] Flight Time [statusflight_time] GPS Status [statusgps_status] Throttle [statusthrottle] Waypoint Count [statuswp_count] Current Waypoint [statuscurrent_wp] Progress [statusprogress]

ndash Calibration [cali] Accelerometer Calibration [caliaccel] Gyroscope Calibration [caligyro] RC Calibration [calirc]

ndash Extras Cache Map [cachemaps] Get Locations [getlocations] Arming [arm] Set Flight Mode [set_mode] Get Flight Mode [flight_mode] Reboot [reboot]

ndash SDA [sda]ndash Geofences [geofence]ndash Waypoints [wp]ndash Interop [interop]

Server Control [groundapiv3interop] Obstacles [groundapiv3interopobstacles] Hz [groundapiv3interophz] Server Active [groundapiv3interopactive] Status [groundapiv3interopstatus]

The API for communicating between the autopilot and the ground station

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

13 License 3

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 2: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

Contents

1 Welcome 111 How to edit this page 112 Support 213 License 2

2 Indices and tables 57

i

ii

CHAPTER 1

Welcome

Yay documentation

How to edit this page

Easy Mode

bull Click the ldquoEdit on GitHub button at the top of any pagerdquo

bull Edit the page

bull Click lsquoPreview changesrsquo before committing to make sure you havenrsquot made a mistake with markdown syntax

bull Add a change message and commit when you have finished your changes

bull In a few minutes readthedocs will be updated

Leet Mode

Installation

$ git clone httpsgithubcomCUAirAutopilot$ cd Autopilot$ virtualenv venv$ source venvbinactivate$ pip install -r requirementstxt$ cd docs$ make html

Use

bull To create a page make a new file called foobarrst

bull Add your page to the table of contents in the file indexrst under the api and groundstation pages

bull Edit your page using sphinx markup

bull To see what your page looks like compile it with make html

bull When you are happy with what the page looks like commit your changes with git (git add --all gitcommit -m change message git push)

bull The online documentation will update sometime in the next few minutes

1

CUAir Autopilot Documentation Documentation Release 10

To learn more about how to use sphinx see the following guides

httpwwwsphinx-docorgenstabletutorialhtml

httpwwwsphinx-docorgenstableresthtmlrst-primer

Support

If you are having issues please slack Troy

License

The project may or may not have a license

Contents

Autopilot API endpoints

2 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Autopilot API endpointsndash Status [status]

Attitude [statusattitude] Battery [statusbattery] Armed [statusarmed] Mav Info [statusmav_info] Mav Warning [statusmav_warning] Mav Error [statusmav_error] Safe [statussafe] Link [statuslink] GPS [statusgps] Mode [statusmode] Airspeed [statusairspeed] Wind [statuswind] Climb [statusclimb] Signal [statussignal] Flight Time [statusflight_time] GPS Status [statusgps_status] Throttle [statusthrottle] Waypoint Count [statuswp_count] Current Waypoint [statuscurrent_wp] Progress [statusprogress]

ndash Calibration [cali] Accelerometer Calibration [caliaccel] Gyroscope Calibration [caligyro] RC Calibration [calirc]

ndash Extras Cache Map [cachemaps] Get Locations [getlocations] Arming [arm] Set Flight Mode [set_mode] Get Flight Mode [flight_mode] Reboot [reboot]

ndash SDA [sda]ndash Geofences [geofence]ndash Waypoints [wp]ndash Interop [interop]

Server Control [groundapiv3interop] Obstacles [groundapiv3interopobstacles] Hz [groundapiv3interophz] Server Active [groundapiv3interopactive] Status [groundapiv3interopstatus]

The API for communicating between the autopilot and the ground station

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

13 License 3

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 3: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

ii

CHAPTER 1

Welcome

Yay documentation

How to edit this page

Easy Mode

bull Click the ldquoEdit on GitHub button at the top of any pagerdquo

bull Edit the page

bull Click lsquoPreview changesrsquo before committing to make sure you havenrsquot made a mistake with markdown syntax

bull Add a change message and commit when you have finished your changes

bull In a few minutes readthedocs will be updated

Leet Mode

Installation

$ git clone httpsgithubcomCUAirAutopilot$ cd Autopilot$ virtualenv venv$ source venvbinactivate$ pip install -r requirementstxt$ cd docs$ make html

Use

bull To create a page make a new file called foobarrst

bull Add your page to the table of contents in the file indexrst under the api and groundstation pages

bull Edit your page using sphinx markup

bull To see what your page looks like compile it with make html

bull When you are happy with what the page looks like commit your changes with git (git add --all gitcommit -m change message git push)

bull The online documentation will update sometime in the next few minutes

1

CUAir Autopilot Documentation Documentation Release 10

To learn more about how to use sphinx see the following guides

httpwwwsphinx-docorgenstabletutorialhtml

httpwwwsphinx-docorgenstableresthtmlrst-primer

Support

If you are having issues please slack Troy

License

The project may or may not have a license

Contents

Autopilot API endpoints

2 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Autopilot API endpointsndash Status [status]

Attitude [statusattitude] Battery [statusbattery] Armed [statusarmed] Mav Info [statusmav_info] Mav Warning [statusmav_warning] Mav Error [statusmav_error] Safe [statussafe] Link [statuslink] GPS [statusgps] Mode [statusmode] Airspeed [statusairspeed] Wind [statuswind] Climb [statusclimb] Signal [statussignal] Flight Time [statusflight_time] GPS Status [statusgps_status] Throttle [statusthrottle] Waypoint Count [statuswp_count] Current Waypoint [statuscurrent_wp] Progress [statusprogress]

ndash Calibration [cali] Accelerometer Calibration [caliaccel] Gyroscope Calibration [caligyro] RC Calibration [calirc]

ndash Extras Cache Map [cachemaps] Get Locations [getlocations] Arming [arm] Set Flight Mode [set_mode] Get Flight Mode [flight_mode] Reboot [reboot]

ndash SDA [sda]ndash Geofences [geofence]ndash Waypoints [wp]ndash Interop [interop]

Server Control [groundapiv3interop] Obstacles [groundapiv3interopobstacles] Hz [groundapiv3interophz] Server Active [groundapiv3interopactive] Status [groundapiv3interopstatus]

The API for communicating between the autopilot and the ground station

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

13 License 3

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 4: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CHAPTER 1

Welcome

Yay documentation

How to edit this page

Easy Mode

bull Click the ldquoEdit on GitHub button at the top of any pagerdquo

bull Edit the page

bull Click lsquoPreview changesrsquo before committing to make sure you havenrsquot made a mistake with markdown syntax

bull Add a change message and commit when you have finished your changes

bull In a few minutes readthedocs will be updated

Leet Mode

Installation

$ git clone httpsgithubcomCUAirAutopilot$ cd Autopilot$ virtualenv venv$ source venvbinactivate$ pip install -r requirementstxt$ cd docs$ make html

Use

bull To create a page make a new file called foobarrst

bull Add your page to the table of contents in the file indexrst under the api and groundstation pages

bull Edit your page using sphinx markup

bull To see what your page looks like compile it with make html

bull When you are happy with what the page looks like commit your changes with git (git add --all gitcommit -m change message git push)

bull The online documentation will update sometime in the next few minutes

1

CUAir Autopilot Documentation Documentation Release 10

To learn more about how to use sphinx see the following guides

httpwwwsphinx-docorgenstabletutorialhtml

httpwwwsphinx-docorgenstableresthtmlrst-primer

Support

If you are having issues please slack Troy

License

The project may or may not have a license

Contents

Autopilot API endpoints

2 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Autopilot API endpointsndash Status [status]

Attitude [statusattitude] Battery [statusbattery] Armed [statusarmed] Mav Info [statusmav_info] Mav Warning [statusmav_warning] Mav Error [statusmav_error] Safe [statussafe] Link [statuslink] GPS [statusgps] Mode [statusmode] Airspeed [statusairspeed] Wind [statuswind] Climb [statusclimb] Signal [statussignal] Flight Time [statusflight_time] GPS Status [statusgps_status] Throttle [statusthrottle] Waypoint Count [statuswp_count] Current Waypoint [statuscurrent_wp] Progress [statusprogress]

ndash Calibration [cali] Accelerometer Calibration [caliaccel] Gyroscope Calibration [caligyro] RC Calibration [calirc]

ndash Extras Cache Map [cachemaps] Get Locations [getlocations] Arming [arm] Set Flight Mode [set_mode] Get Flight Mode [flight_mode] Reboot [reboot]

ndash SDA [sda]ndash Geofences [geofence]ndash Waypoints [wp]ndash Interop [interop]

Server Control [groundapiv3interop] Obstacles [groundapiv3interopobstacles] Hz [groundapiv3interophz] Server Active [groundapiv3interopactive] Status [groundapiv3interopstatus]

The API for communicating between the autopilot and the ground station

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

13 License 3

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 5: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

To learn more about how to use sphinx see the following guides

httpwwwsphinx-docorgenstabletutorialhtml

httpwwwsphinx-docorgenstableresthtmlrst-primer

Support

If you are having issues please slack Troy

License

The project may or may not have a license

Contents

Autopilot API endpoints

2 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Autopilot API endpointsndash Status [status]

Attitude [statusattitude] Battery [statusbattery] Armed [statusarmed] Mav Info [statusmav_info] Mav Warning [statusmav_warning] Mav Error [statusmav_error] Safe [statussafe] Link [statuslink] GPS [statusgps] Mode [statusmode] Airspeed [statusairspeed] Wind [statuswind] Climb [statusclimb] Signal [statussignal] Flight Time [statusflight_time] GPS Status [statusgps_status] Throttle [statusthrottle] Waypoint Count [statuswp_count] Current Waypoint [statuscurrent_wp] Progress [statusprogress]

ndash Calibration [cali] Accelerometer Calibration [caliaccel] Gyroscope Calibration [caligyro] RC Calibration [calirc]

ndash Extras Cache Map [cachemaps] Get Locations [getlocations] Arming [arm] Set Flight Mode [set_mode] Get Flight Mode [flight_mode] Reboot [reboot]

ndash SDA [sda]ndash Geofences [geofence]ndash Waypoints [wp]ndash Interop [interop]

Server Control [groundapiv3interop] Obstacles [groundapiv3interopobstacles] Hz [groundapiv3interophz] Server Active [groundapiv3interopactive] Status [groundapiv3interopstatus]

The API for communicating between the autopilot and the ground station

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

13 License 3

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 6: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Autopilot API endpointsndash Status [status]

Attitude [statusattitude] Battery [statusbattery] Armed [statusarmed] Mav Info [statusmav_info] Mav Warning [statusmav_warning] Mav Error [statusmav_error] Safe [statussafe] Link [statuslink] GPS [statusgps] Mode [statusmode] Airspeed [statusairspeed] Wind [statuswind] Climb [statusclimb] Signal [statussignal] Flight Time [statusflight_time] GPS Status [statusgps_status] Throttle [statusthrottle] Waypoint Count [statuswp_count] Current Waypoint [statuscurrent_wp] Progress [statusprogress]

ndash Calibration [cali] Accelerometer Calibration [caliaccel] Gyroscope Calibration [caligyro] RC Calibration [calirc]

ndash Extras Cache Map [cachemaps] Get Locations [getlocations] Arming [arm] Set Flight Mode [set_mode] Get Flight Mode [flight_mode] Reboot [reboot]

ndash SDA [sda]ndash Geofences [geofence]ndash Waypoints [wp]ndash Interop [interop]

Server Control [groundapiv3interop] Obstacles [groundapiv3interopobstacles] Hz [groundapiv3interophz] Server Active [groundapiv3interopactive] Status [groundapiv3interopstatus]

The API for communicating between the autopilot and the ground station

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

13 License 3

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 7: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Response 200 (applicationjson)

throttle 00battery time 00batterypct 00batteryvoltage 00batterycurrent 00

signal time 00signal_strength 0

safe trueairspeed time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

wp_count 0mav_warning current_wp 0attitude time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

mav_info EKF2 IMU1 is using GPSlink plane_link truelinks nullgps_link true

mode MANUALmav_error gps_status time 00satellite_number 0

armed truewind time 00windvx 00windvy 00windvz 00

gps time 00rel_alt 00asl_alt 00

4 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 8: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

time 00roll 00pitch 00yaw 00rollspeed 00pitchspeed 00yawspeed 00

Battery [statusbattery]

Returns the current state of the planersquos battery containing

bull batterypct [float]

bull batteryvoltage [float]

bull batterycurrent [float]

+ Response 200 (applicationjson)time 00batterypct 00batteryvoltage 00batterycurrent 00

Armed [statusarmed]

Returns whether or not the plane is armed

13 License 5

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 9: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

+ Response 200 (texthtml)true

Mav Info [statusmav_info]

Returns the most recent MAV info string

+ Response 200 (texthtml)EKF2 IMU1 is using GPS

Mav Warning [statusmav_warning]

Returns the most recent MAV warning string

+ Response 200 (texthtml)

Mav Error [statusmav_error]

Returns the most recent MAV error string

+ Response 200 (texthtml)Calibration FAILED

Safe [statussafe]

Returns whether or not the plane is safe

+ Response 200 (texthtml)true

Link [statuslink]

Returns the status of links containing

bull gps_link [boolean]

bull plane_link [boolean]

bull links [list]

+ Response 200 (applicationjson)plane_link truelinks [packet_loss 00alive truedevice_name WiFinum 0device tcp1270015760num_lost 0link_delay 00

6 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 10: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

]gps_link true

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull groundvx [float]

bull groundvy [float]

bull groundvz [float]

+ Response 200 (applicationjson)

time 00rel_alt 00asl_alt 00lat 00lon 00heading 00groundvx 00groundvy 00groundvz 00

Mode [statusmode]

Returns the current flying mode of the plane as a string eg ldquoAUTOrdquo ldquoMANUALrdquo ldquoFLY_BY_WIRE_Ardquo

bull str

Response 200 (texthtml)MANUAL

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

bull speed [float]

bull climb [float]

bull throttle [float]

bull airvx [float]

13 License 7

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 11: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

bull airvy [float]

bull airvz [float]

+ Response 200 (applicationjson)time 00airvx 00airvy 00airvz 00speed 00climb 00throttle 00

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

bull windvx [float]

bull windvy [float]

bull windvz [float]

Response 200 (applicationjson)time 00windvx 00windvy 00windvz 00

Climb [statusclimb]

Returns current climb angle

Response 200 (texthtml)00

Signal [statussignal]

Returns the time and the signal strength as an integer of the transmitter connection 0 0 100 100 255 in-validunknown See _RC_CHANNELS packet rssi field

bull signal_strength

+ Response 200 (applicationjson)time 00signal_strength 0

8 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 12: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]|[null]

bull if_flying [boolean]

+ Response 200 (applicationjson)time 00time_start nullis_flying true

GPS Status [statusgps_status]

Returns the gps connection represented by an integer number of satellites visible

bull satellite_number [int]

+ Response 200 (applicationjson)time 00satellite_number 0

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

Response 200 (texthtml)00

Waypoint Count [statuswp_count]

Returns an integer representing the current number of waypoints

+ Response 200 (texthtml)0

Current Waypoint [statuscurrent_wp]

Returns an integer representing the current waypoint

+ Response 200 (texthtml)0

Progress [statusprogress]

Gives information about the current mission progress

bull covered [int] (number of meters flown)

13 License 9

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 13: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

bull percentage [float] (percent of flight path coompleted)

bull remaining [int] (meters left to fly)

bull time_to_landing [int] (approximate seconds left in flight)

+ Response 200 (applicationjson)covered 0percentage 00remaining 0time_to_landing 0

Calibration [cali]

Accelerometer Calibration [caliaccel]

bull POST

Starts the accelerometer calibration process

Response 200 (texthtml)Started accelerometer calibration

bull PUT

Continues calibration process (mostly for accelerometer)

Response 200 (texthtml)Continuing

Gyroscope Calibration [caligyro]

bull POST

Starts the gyroscope calibration process

Response 200 (texthtml)True

RC Calibration [calirc]

bull POST

Starts the RC calibration process

Response 200 (texthtml)True

bull DELETE

Stops the RC calibration process

Response 200 (texthtml)True

10 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 14: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Extras

Cache Map [cachemaps]

bull POST

Tells the backend to cache a map location

HeadersContent-Type applicationjson

Requestsname ltstringgt [The location name]lat ltfloatgt [The locations latitude]lon ltfloatgt [The locations longitude]

Response 200 (applicationjson)

topLat 1bottomLat 0leftLon 0rightLon 1centerLat 05centerLon 05

Get Locations [getlocations]

bull GET

Retrieves the list of cached map locations

HeadersContent-Type applicationjson

Response 200 (applicationjson)

Cornell_Campus leftLon -764950662435imageURL imgsatellitesCornell_Campus_SatellitepngbottomLat 424384214463topLat 424586880256rightLon -764676004232

Game_Farm

leftLon -764650662435imageURL imgsatellitesGame_Farm_SatellitepngbottomLat 424333928552topLat 424536610611rightLon -764376004232

Arming [arm]

bull POST

13 License 11

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 15: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Arms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

bull DELETE

Disarms the plane

HeadersContent-Type applicationjsontoken ltsecret tokengtconfirm confirm

Response 200 (texthtml)True

Set Flight Mode [set_mode]

bull POST

Sets the plane mode

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestsmode ltstringgt [The name of the mode to switch into]

Response 200 (texthtml)Accepted Mode Change

Get Flight Mode [flight_mode]

bull GET

Gets the plane mode

Response 200 (texthtml)MANUAL

Reboot [reboot]

bull POST

Causes the plane to reboot

Headers Content-Type applicationjson token ltsecret tokengt confirm confirm

Response 200 (texthtml) ldquoTruerdquo

12 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 16: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

SDA [sda]

bull GET

Returns whether SDA is enabled

Response 200 (texthtml)true

bull POST

Activates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)true

bull DELETE

Deactivates SDA

HeadersContent-Type applicationjsontoken ltsecret tokengt

Response 200 (applicationjson)True

Geofences [geofence]

bull GET

Returns the geofence points

Response 200 (applicationjson)[lat 00 [degrees]lon 00 [degrees]

lat 00lon 00

]

bull POST

Sets the geofence points

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslist oflat ltfloatgt [The fence points latitude]lon ltfloatgt [The fence points longitude]

Response 200Added Fence

13 License 13

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 17: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Waypoints [wp]

bull GET

Returns a list of waypoints each containing altitude longitude latitude current waypoint waypoint type orMAV_CMD waypoint index

Response 200 (applicationjson)[

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

]

bull GET with arguments [GET wpwpnum]

The response field ldquotyperdquo in GET is the same as the ldquocommandrdquo field in POST and PUT The associated waypointtypes and numbers are listed under POST

Parameters wpnum - the index of the waypoint you wish to recieve

Response 200 (applicationjson)

command 0current 0param1 00param2 00param3 00param4 00lat 00lon 00alt 00index 0min_dist 00

bull DELETE Delete a specific waypoint

Parameters wpnum - The waypoints index

Response 200 (texthtml)True

bull POST

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]

14 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 18: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

bull PUT

PUT has the same parameters as POST but will update the values of the waypoint at the specifiedindex

HeadersContent-Type applicationjsontoken ltsecret tokengt

Requestslat ltfloatgt [The waypoints latitude]lon ltfloatgt [The waypoints longitude]alt ltfloatgt [The waypoints altitude]index ltintgt [The waypoints index]command ltintgt [The waypoints type or `MAV_CMD lthttpmavlinkorgmessagescommongt`]

Response 200 (texthtml)True

Interop [interop]

Server Control [groundapiv3interop]

bull POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a new instance of thebackend object then starts the backend on a separate thread and sets the server to active It will fail if the serveris either already started or if it has been less that a half second since the server was either started or stoppedlast Requires a valid JSON containing the server data (username password and url fields) Requires a validauth token to access

Response 200

bull DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets the Dataserver_activeglobal variable to false This is the loop condition on the backend so the server will stop as soon as it completesits current loop This will fail if the server is either already stopped or if it has been less that a half second sincethe server was either started or stopped last Requires a valid auth token to access

Response 200

bull GET

Returns a JSON string containing all available server info

ndash ldquoObstaclesrdquo Data structure containg obstacles (ldquomoving_obstaclesrdquo[]rdquostationary_obstaclesrdquo[])

ndash ldquoserver_workingrdquo Does the server believe it is functioning correctly (boolean)

ndash ldquohzrdquo Rolling frequency of interop telemetry posts (integer)

13 License 15

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 19: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

ndash ldquoactiverdquo Is the server active (boolean)

ndash ldquowp_distancesrdquo Closest point of approach to each waypoint (integer list)

ndash ldquoactive_missionrdquo JSON of active mission as described by the interop documentation

Response 200 (applicationjson)hz 00active_mission emergent_last_known_pos latitude 00longitude 00

fly_zones [boundary_pts [latitude 00order 0longitude 00

latitude 00order 0longitude 00

latitude 00order 0longitude 00

]altitude_msl_max 00altitude_msl_min 00

]mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]off_axis_odlc_pos latitude 00longitude 00

search_grid_points [latitude 00altitude_msl 00order 0longitude 00

]active trueid 0

16 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 20: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

home_pos latitude 00longitude 00

air_drop_pos latitude 00longitude 00

obstacles moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

]stationary_obstacles [latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

mission_waypoints [latitude 00altitude_msl 00order 0longitude 00

]server_working truemission_wp_dists [00

]active true

Obstacles [groundapiv3interopobstacles]

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if the server isactive and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returns it

Response 200 (applicationjson)

moving_obstacles [latitude 00sphere_radius 00altitude_msl 00longitude 00time 00

13 License 17

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 21: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

]stationary_obstacles [

latitude 00cylinder_height 00cylinder_radius 00longitude 00

]

Hz [groundapiv3interophz]

Returns a string containing the rolling average of the frequency that the interop server has been posting telemetry data

Response 20000

Server Active [groundapiv3interopactive]

Returns a boolean string telling whether the interop server is currently active or not

Response 200true

Status [groundapiv3interopstatus]

Returns a boolean string telling whether the interop server believes it is working as intended right now Automaticallytrue if the server is not active

Response 200true

Ground Station

18 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 22: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Contents

bull Ground Stationndash Overviewndash Installation for Developmentndash Installation for Test Flightndash Setup with planendash Setup with SITLndash Autopilot Server on the NUCndash WiFi Ground Station Linkndash How the front-end works

Setup Usage instructions The stack React Immutabe Redux Leafletjs Parameters Bootstrap Testing Communications

ndash Interoperability Setup Interoperability Use

middot General Test Flight Usemiddot MAVProxyGround Station usemiddot Judgersquos Server use

Interoperability Designmiddot System Designmiddot APImiddot MAVProxy Backendmiddot Competition rules

ndash Sense Detect and Avoid (SDA) Overview and Usage (New Mangual-Assisted SDA) Obstacle Prediction Implementation Plane Prediction implementation Overview (Old Automatic Versions) SDA Use How SDA Works

middot SDA Enginemiddot SDA RRTmiddot SDA Path

Bezier Curve Smoothing Conversion from Splines to Waypoints

middot Current Issuesmiddot Future Directions

SDA Version 1 Other Details

middot Implementationmiddot Future Directions for SDA

This section describes the use and design of the autopilot ground station

13 License 19

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 23: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Overview

We use a terminal-based ground station software called MAVProxy that receives data from and sends data to the planevia a radio and antenna connected to a computer via USB and the plane MAVProxy receives telemetry data andother data from the plane and is able to control the plane by setting up a mission changing parameters arming anddisarming the plane and more Wersquove customized it to do a few mission-specific things like interoperability SDAand more

Probably the biggest custom feature is the browser-based front end to MAVProxy for easy and intuitive control of theplane MAVProxy now provides a REST API that the front end queries to receive data and control the plane Thisfront end provides a GUI to perform the majority of tasks that MAVProxy can do and see the data from the plane in auser-friendly layout

Installation for Development

git clone httpsgithubcomCUAirMAVProxygitcd MAVProxygit submodule update --init --recursivevagrant up coolvagrant halt old version of guest additionsvagrant up finevagrant provision should be good nowvagrant provision sorryvagrant sshcd MAVProxyrunsh hey it worked

Installation for Test Flight

1 git clone httpsgithubcomCUAirMAVProxygit

2 On Linux

1 sh setupsh

2 pip install python-dev pymavlink tornado requests_futures requests flask sympy

2 On Mac

1 cd MAVProxyMAVProxy

2 virtualenv venv

3 source venvbinactive (try venvbinactivate if that doesnrsquot work)

4 pip install pyserial matplotlib Pillow numpy pyparsing python-dev pymavlink tornado requests_futures requestsflask sympy

5 Install OpenCV

To edit the front-end

1 Install NodeNPM httpsnodejsorgendownload

2 cd MAVProxy

3 npm install -g gulp

4 cd MAVProxymodulesserverstaticgcs2

5 npm install

20 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 24: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

6 gulp

Setup with plane

Linux

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyUSBltXgt --baudrate=57600

bull Run ls dev to see what X should be - also could by TTYACMltXgt

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Mac

1 Run the command

cd MAVProxyMAVProxy

2 Next run

python mavproxypy --master=devttyusblttab completegt --baudrate=57600

bull Run ls dev if tab completion doesnrsquot work

bull If you canrsquot find anything open mission planner and it should show the appropriate path in the upper right

bull If using MAVProxy through wired micro-USB rather than wireless baudrate should be 115200

Setup with SITL

The Software in the Loop is a simulation of ArduPilot with FlightGear This can be used as a virtual environment totest changes without needing a physical plane

Use

1 Connect to RedRover or EduRoam

bull There is a VPN to connect from elsewhere but itrsquos usually too slow to make work Ask if you want to set itup but at that point you may want to just install the SITL on your personal computer (Linux instructionsWindows Instructions)

2 ssh into the computer running the SITL The IP address may be out of date - see Troy for an updated version

ssh -Y cuair1014514217

3 Run

cd Userscuairsrc

4 Run lsquovagrant uprsquo to confirm that the virtualbox running the autopilot is active

vagrant up

13 License 21

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 25: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

5 Itrsquos likely that flightgear is already running on the server If these next steps fail then open a separate terminalwindow and run the following commands to start it

cd ardupilotToolsautotestsh sim_fg_hostsh

6 ssh into the virtual machine running the autopilot

vagrant ssh

7 Finally start the SITL

sim_FGsh

8 You should see two X11 windows pop up on your computer This may take up to a few minutes to happen

9 To run the ground station in a separate terminal window from the MAVProxyMAVProxy directory startMAVProxy

python mavproxypy --master=tcp10145142175555

Autopilot Server on the NUC

The autopilot server on the NUC provides an API for distributed to access autopilot data

------ --(telem2 fdti)--gt AutoPilot NUC server ----------gt distributedPlane |------ lt----(RFD900)----gt AutoPilot Ground Server lt------gt AutoPilot Ground Station

To install connect to the NUC and connect the NUC to the Internet Then

git clone httpsgithubcomCUAirMAVProxygit checkut airapicd MAVProxyMAVProxyvirtualenv venvsource venvbinactivatepip install -r requirementstxt

To start the server run

cd MAVProxyMAVProxysource venvbinactivatepython mavproxypy --master=devttyUSB0

NOTE The serial port is not bound to ttyUSB0 Sometimes you will have to try ttyUSB1 or ttyUSB2

WiFi Ground Station Link

The OBC can also be configured to forward its packets to the ground station on the ground This allows WiFi to actas a redundant (and superior) link just as the radios do When the WiFi link is established packets can be sent andreceived often much faster than with the radios alone and of course this acts as a secondary link in case either onefails

MAVProxy will consider the link passed on the command line as the ldquomasterrdquo link but both will send and receivepackets at the same time You will be alerted if either link goes down Type ldquolinkrdquo into the MAVProxy terminal toview the current links and there status (number of packets sent packet loss etc)

To use start up the ground station on the NUC with the following command

22 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 26: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

python mavproxypy --master=devttyUSB0 --out=udpGROUND_STATION_IP14551

Where GROUND_STATION_IP is the IP of the computer that will be running MAVProxy from the ground

Then start MAVProxy normally on the ground and run the command

link add 000014551

This will connect to the NUC if itrsquos available

How the front-end works

Setup

To use

Once MAVProxy is running go to httplocalhost8001staticgcs2indexhtml

The judgersquos view can be found at httplocalhost8001staticjudgesindexhtml

Usage instructions

The home screen has all of the flight information and flight controls used in normal operation of the ground stationThe map displays the waypoints shown below it and the map can be changed in the settings tab Additionally thesettings tab contains settings for the interop server authentication information geofences andthe reboot control (whichrequires double-confirmation) The parameters tab contains all of the parameter information Grey parameters indicatethat those parameters havenrsquot been received yet The calibration tab allows accelerometer gyroscope and pressure(airspeed) calibration Finally the Flight Notes tab can be used to store information The Flight notes store your noteslocally to your browser using localStorage (basically cookies) so they will not transfer between computers

13 License 23

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 27: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

The stack

Our stack consists of python (MAVProxy amp Flask) on the backend with React Immutable Redux Sass gulp and Jadebeing used on the front-end Additionally our backend can technically serve information over a rest API as well asover websockets however websockets tended to be pretty buggy so we decided to switch back to only using the RESTAPI

React

The front-end (gcs2) is built in React a javascript library from Facebook that makes the front-end faster by diff-ing thecurrent DOM with the new state to reduce the number of DOM operations (which are very expensive) and renderingchanges to the front-end in real-time See the documentation for the React here

Immutabe

The front-end (gcs2) is built in Immutable a javascript library from Facebook that has persistent data collections forJavascript which increase efficiency and simplicity Immutable data encourages pure functions (data-in data-out) andlends itself to much simpler application development and enabling techniques from functional programming such aslazy evaluation See the documentation for the React here

Redux

To power our react and Immutable system we used vanilla _lsquoRedux lthttpsreduxjsorggtlsquo_ which is poweredthrough a system called actions-store-reducers that makes all changes 1-way interactions (rather than Angularrsquos 2-way bindings) We broke the application down into essentially 8 sections Calibration Geofences InteroperabilityParameters SDA Settings Plane Status and Waypoints Each section has its own action creator and reducer Foran example of how to use immutable with Redux _lsquothis lthttpsreduxjsorgbasicsexample-todo-listgtlsquo_ example issimple and extremely useful You should either read it through in its entirety or try to make itmess with it to get fa-miliar Once you understand the general code structure it shouldnrsquot be hard to get the hang over making a simple appOne of the benefits of Redux over other javascript frameworks like Angular is that since everything is 1-way the stacktraces are very clear which assists in debugging One of the biggest advantages of using the Redux framework overthe Flux architecture like we previously had was that it got rid of the boilerplate codescaffolding It cuts down on theaction responding time and preserves all the benefits of Flux without introducing dispatchers and store registrationswhich has made redux much more efficient Redux uses one single store which in a sense is like one source of truththat has an immutable state Redux has a completely different approach to state management ndash it embraces the ideathat there is a global state and that inevitably if you wanted to make changes it should just happen there in a veryspecific way (how you handle what components have access to what state is up to you) Redux really changes howthe state tree is managed and give the stores different responsibilities and changes how state information is mappeddown to the components We may improve upon this by cleaning up some circular calls and with more understandingof Immutablejs

24 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 28: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Leafletjs

To handle our maps we use Leafletjs a leading mobile-compatible open source mapping library All of the mapfunctions get handled in MapUtilsjs and handles waypoints obstacles plane-tracking geofences and locations Theplane has an icon and there is a marker icon for each waypoint Additionally obstacles and geofences are treated asshapes and locations are set in settings

Parameters

To generate the parameters list we have a pythonbash script that pulls the parameters from the ardupilot website (inthe documentation folder) parses them from xml removes extraneous characters converts them to json and copiesthem to a javascript file (ParamDocumentationjs) so the object can be loaded in as json

Bootstrap

Additionally for our visual library we used Twitterrsquos Bootstrap because it is ubiquitous on the internet it has anenormous community and it is has a very appealing UI

Testing

The ground station has 2 primary tests front-end tests and backend tests The front-end uses selenium tests whichget run by going to MAVProxyMAVProxymodulesserverstaticgcs2test and running python testpy (run setupshthe first time before running testpy) which runs front-end selenium tests The backend tests are run by going toMAVProxyMAVProxymodulesserver and running python testspy which uses the requests module to test the RESTAPI We plan on adding these tests to our CI server next semsester once we get CI set up

13 License 25

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 29: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Communications

Our front-end system uses a simple polling system (in ReceiveApijs) We originally used socketio with websocketsbut it was way too slow (may be a result of synchronous socket emits not entirely sure) Basically we just takeadvantage of the REST API implemented in flask on the back-end We use postdeleteput requests to send informationto the server All non-GET requests are protected with a tokenpassword and all highly vulnerable actions (ie reboot)are protected with an extra layer of checks and a second confirm element in the request

Interoperability

Setup

See the Judgersquos server interoperability documentation here All of those setup instructions must be followed beforethe following instructions will work

Interoperability Use

General Test Flight Use

1 Make sure to bring a computer with the interop server installed on it If possible have a template mission readyto got

2 cd interop then run sudo serverrunsh

bull The server will run on localhost8000

3 To load the template mission

(a) sudo docker exec -it interop-server bash

(b) python managepy flush (This will flush the database - do not do this if you want to keep thecurrent database - see below for storing a dump)

(c) python managepy loaddata template_missionjson

(d) (Type exit to leave the docker bash shell)

4 Now the mission must be set up on the interop server to match the mission in Ardupilot

(a) Go to localhost8000admin

(b) Click ldquoMission configsrdquo

(c) Click the first mission

(d) In ldquoMission Waypointsrdquo hit the + button at the side to add a new waypoint

(e) Enter the proper order (1 indexed) then hit the spyglass then lsquoadd aerial positionrsquo

(f) Enter the proper altitude IN FEET

(g) Hit the spyglass then lsquoadd gps positionrsquo

(h) Enter the proper latitude and longitude

(i) Continue starting from set e until all waypoints are entered

5 Save the mission config

6 Go to localhost8000 and hit ldquoMission 1rdquo You should see a picture of your setup where blue spheresare the waypoints and the rest is not relevant to navigation Confirm that the blue spheres look like what yourwaypoint setup should be (If you donrsquot see the picture try Firefox instead of Chrome)

26 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 30: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

7 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

bull This will usually be lsquocuairsimrsquo and lsquoaeolusrsquo for the usernamepassword and ldquohttpltsome ipgt8000rdquo forthe url

8 Hit ldquoToggle interoprdquo Look at the Mission 1 again and confirm that a yellow box appears meaning that theinterop server is receiving data

9 Hit ldquoToggle interoprdquo again to turn off data sending until yoursquore ready to fly

10 When yoursquore ready to fly FIRST hit lsquotoggle interoprsquo on the front end to start sending data to the interop server

11 Then go to localhost8000admin then click ldquoTakeoff or landing eventsrdquo

12 Hit ldquoadd a takeoff or landing eventrdquo then select the appropriate user and ldquoUas in airrdquo Hit save

bull As of now the server is checking for data and recording data Make sure the plane has data link as muchas possible after this or the avg telemetry HZ will be low

13 Fly

14 Create a LANDING event for the appropriate user (same thing but leave ldquoUas in airrdquo unchecked)

15 Hit ldquoToggle interoprdquo to stop sending data to the interop server

16 Go to the mission page and mouse over ldquoSystemrdquo Right click ldquoEvaluate Teams (csv)rdquo and save it as a fileOpen that file in Excel or an equivalent to view the flight data (Donrsquot try to view it as plaintext itrsquos doable butannoying)

17 To create a database dump open the bash shell as if you were about to load a mission config (see beginning)but instead use python managepy dumpdata gt mydatadumpjson

MAVProxyGround Station use

1 Enter the correct username password and url (include the http and the port (usually 8000) in the settings tabof gcs2

2 Hit ldquoToggle Interoprdquo to activate server

bull You should see ldquointerop server startedrdquo printed on the MAVProxy console and get a green success status messageon the ground station

3 To stop hit ldquoToggle Interoprdquo again

bull You should see ldquointerop server stoppedrdquo printed on the MAVProxy console and get a green success statusmessage on the ground station

Judgersquos Server use

See the Judgersquos server interoperability documentation here

Interoperability Design

System Design The backend is designed with 3 main components - the API which provides a REST API for thefront end to control and query the backend the backend itself which sends information to and retrieves informationfrom the judgersquos server and the test suite which tests the functionality of the backend

13 License 27

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 31: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

API Location modulesserverviewsinterop_apipy

The program creates a flask server to serve data to the front end and other subteams It retrieves data related tointeroperability from the MAVProxymodulesserverdata file It also contains an endpoint to start and stop the backend

When multiple endpoints are listed both are valid - the second is the newest is is preferred Other endpoints not listedhere in code are deprecated

Endpoints

bull Server Control groundapiv3interop

ndash POST

Sending a POST request to this endpoint starts the interop backend To do this it creates a newinstance of the backend object then starts the backend on a separate thread and sets the server toactive It will fail if the server is either already started or if it has been less that a half second since theserver was either started or stopped last Requires a valid JSON containing the server data (usernamepassword and url fields) Requires a valid auth token to

ndash DELETE

Sending a DELETE request to this endpoint will stop the interop backend It simply sets theDataserver_active global variable to false This is the loop condition on the backend so the serverwill stop as soon as it completes its current loop This will fail if the server is either already stoppedor if it has been less that a half second since the server was either started or stopped last Requires avalid auth token to access

28 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 32: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

ndash GET

Returns a JSON string containing the obstacle data and server info

bull Obstacles groundapiv3interopobstacles

Returns a JSON object string that contains a list of both moving and stationary objects Checks to see if theserver is active and if so retrieves data from the MAVProxymodulesserverdata module jsonifies it and returnsit

MAVProxy Backend Location modulesserverinteroppy

This program is the script that does the work of sending telemetry data to the judgersquos interoperability server andretrieving data about the server and obstacles to store for other MAVProxy modules

Global Variables

bull TRIES_BEFORE_FAILURE

The number of consecutive telemetry failures the system will accept before warning the user the telemetryis down System will automatically warn the user every time a single telemetry request fails regardlessbut will not display as down until reaching this cap

bull RUN_TESTS

Uncomment this to run test cases This will cause the url to be overwritten with the url used to run testcases

bull FEET_TO_METERS_FACTOR

The factor to multiply a value in feet by to get a value in meters

Methods

bull __init__(self)

Establishes a connection with the interop server and starts a session by logging in with the specified credentialsThe server returns cookies after login which are stored in the selfsession variable and will be used every timea request is sent by this object

bull start(self)

Spawns two threads that send telemetry data and retrieve server and obstacle data After spawning it checksevery second to see if the server has stopped and if so prints that to the console then exits

bull get(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) then loops on the server_active condition It sleeps until it is time to send anew request sends that request then stores the response in Datapdata

bull post(self)

Will never be called on the main thread this method is called as its own thread by the start method It calculatesthe period (time between requests) giving it a fudge factor of 10 as it does to ensure that the average telemetrysend rate stays well above the required number It then sleeps until it is time to send a bit of data When it istime it grabs the necessary data from the Datapdata object then sends the http request to the interop server ona separate thread This is done asynchronously so we do not have to wait for a response and can continue at theproper speed even if the server is running slowly

bull send_telemetry(self telemetry_data)

Sends the telemetry data as an http request to the judgersquos server Afterwards it checks the status of the requestand increments the failures if necessary

13 License 29

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 33: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

bull initialize_history(self obstacles)

Initializes the recorded history of obstacle data for use by SDA

bull meters_to_feet(meters)

Converts a float from a value in meters to a value in feet

bull feet_to_meters(feet)

Converts a float from a value in feet to a value in meters

Competition rules Below are the rules that govern interoperability for the competition The interoperability systemis made to comply with these rules

531 As a flightmission demonstration requirement teams shall upload the UAS autopilot telemetry (TM) data(position altitude and related attributes) to support scoring using the interoperability system

5313 If the teamrsquos system cannot provide TM data to the judges using the interoperability system theywill not be allowed to fly just like if they had not displays to show the judgesrsquo the air vehicles position

532 The UAS shall upload this TM data at a target rate of 10Hz from the first takeoff until the last landing Ifthe average rate of upload across all flight periods is below 8 Hz the team will receive no points for the missiondemonstration The difference between 10 Hz and 8 Hz is intended to allow for short and temporary data link outages

533 Data dropouts which impact the ability for the judges to use the telemetry data to judge mission componentswill be counted against the team For example if data dropout makes it unclear whether waypoints were capturedwithin 50ft and in order it will be assumed the team did not do so If the data dropout occurs near a flight zoneboundary it will be assumed the team spent the entire time out of bounds If the data dropout occurs near obstaclesit will be assumed those obstacles were hit For data dropout evaluation it will be assumed the UAS traveled at themaximum allowed competition airspeed (100 KIAS)

534 The UAS may upload the position whenever the interoperability network is available and is not restricted toairborne flight periods Teams should also upload position whenever the UAS occupies the runway

535 Data uploaded shall be genuine autopilot flight telemetry data which is not interpolated extrapolated duplicatedsimulated or otherwise edited by teamrsquos codeoperators before being passed to the interoperability system The datamust be generated by the autopilot at 10Hz or greater and thus the UAS will need sensors and data links which cansupport sufficient data rates

796 Display Obstacles There are virtual obstacles for the Sense Detect and Avoid (SDA) task The positions andsizes of the obstacles are provided by the interoperability server This information shall be downloaded and displayedat the same UAS autopilot operator interface (eg the same laptop) used in the Ground Control Station Theseobstacles shall be displayed in a view that also shows the UAS position the mission boundaries the task positionsand the UASrsquo waypoints This view does not need to be the autopilot interface (eg the desktop application)

Sense Detect and Avoid (SDA)

Overview and Usage (New Mangual-Assisted SDA)

The new version of SDA hinges around features which enable the user to manually re-route paths on an SDA-groundstation This was chosen as opposed to previous automatic methods due to the necissity for predictability of pathrerouting to avoid interference with mission-critical systems such as airdrop and vision The SDA operator is able toavoid obstacles with the help of both plane-path predicions and obstacle path predictions which will be discussed ingreater detail in the following sections These preditions come in the form of a slider which can be enabled from thesettings tab Note this slider requires the user be in ldquoSDA-operator moderdquo as well The user can hit the ldquoresetrdquo buttonon the main ground station tab to trigger the computation of both obstacle and plane predictions at the same timeThese predictions apear as a purple plane and pink obstacles with blue splines tracing out the paths the coresponding

30 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 34: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

objects should follow Once the play-button by the slider is pressed the obstacles and plane will step-forward alongtheir paths roughly in real time The user can also manually move the slider to determine where obstacles or the planewill be in the future Most of the relevant files can be found in MAVProxymodulesmavproxy_plane_prediction andMAVProxymodulesmavproxy_obstacle_prediction

Obstacle Prediction Implementation

To predict obstacle positions interpolating splines are used in conjunction with a period-finding algorithm In otherwords a python library is used to calculate spline curves to interpolate all of the historical obstacle data (or a subsetof the data composed of only a certain amount of the most recent points) This spline then will approximate the entireperiod of an obstaclersquos motion given enough data points The period of the obstaclersquos motion is calculate by comparingthe first data point to all other datapoints and determining which point is closest This method is not flawless but workswell in practice Once an interpolating spline has been generated and the period has been calculated it is simply amatter of modding the time that the obstacles position is to be computed at by the period This method does have someshort-term weaknesses before the entire period is in the history and relies on periodicity of obstacle motion

Plane Prediction implementation

Plane prediction relies on the use of the Bezier Curves present in project atlas If project atlas is not being used planeprediction is simply done with interpolating lines In either case splines (or lines) are generated between all pairs ofwaypoints and the planes position is calculated by interpolating along these splines (or lines) and assuming constantspeed Due to its use of splines the method should work better when the plane is flying in spline-controller mode butseems to provide relatively accurate predictions over a relatively long time period (on the order of minutes) for bothcontrollers This method does not fully emulate the navigation algorithm as simulating L1 controll is both challengingand prohibitively computationally expensive

Overview (Old Automatic Versions)

SDA is an auxilary task for the competition wherein the interoperabilty server sends data to the groundstation aboutobstacles that the plane must avoid Obstacles come in two varieties moving and stationary Moving obstacles arespheres that travel along a predetermined path by the judges This path is not known to the competiting teams andthe only information that is given is the GPS coordinates of where itrsquos center currently is itrsquos radius and itrsquos altitudeAll other information must be calcuated by the team Stationary obstacles are cylinders of a given radius Similarlythe only information sent to the team are itrsquos GPS coordinates the height of the cylinder (obstacles extend from theground to this height) and itrsquos radius

SDA Use

SDA can be activated through the ground station It requires that the interoperability server is active and is sendingobstacle data When toggled on it will place and adjust auxilary waypoints to redirect the flight path away fromobstacles Obstacles are represented on the ground station as moving blue circles and stationary orange circles formoving and stationary obstacles respectively In the event that SDA is unneed or it creates a potentially hazardouswaypoint (eg miles away from the flight zone outside of the geofense too close to the plane and causes it to actirrationally) simply toggle off SDA through the groundstation button and it will delete all SDA waypoints Thegroundstation keeps track of which waypoints are SDA waypoints as opposed to user entered ones

How SDA Works

SDA Engine things and stuff

13 License 31

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 35: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

SDA RRT To compute Optimal paths that avoid obstacles we use what is know as an Rapidly Exploring RandomTree (RRT) RRTs are used as opposed to other pathfinding algorhythms such as A because they work on continuousspaces as opposed to discrete graphs The RRTs sacrfice optimatality for speed of computation an important factorwhen avoiding moving obstacles due to the potential necessity to re-compute the path multiple times In particularwe use a greedy biased ERRT A biased RRT is one which when selecting a random point has a probability (knownas the goal probablity) of selecting the goal as its random point to extend towards By biasing the RRT we can causethe RRT to tend towards exploring in the direction of the goal point while still allowing it explore a large spaceA greedy RRT is one which repeatedly extends in the direction of the random point it has selected until either anobstacle is reached or the biasing causes the goal point to be selected as the new point to extend towards ERRTs arean optimazation of RRTs for environments where the RRT could potentially need to be recomputed many times (suchas environments with moving obstacles that can move to invalidate previous paths) ERRTs do this by caching nodesfrom the previous RRT path and having some probabilty of selecting one of the nodes from the previous RRT insteadof the random point to extend towards This biasing towards previously used nodes can drastically increase the speedof re-computing RRTs as it avoids the necessity to completely recompute the RRT when a moving obstacle invalidatesits current path We then prune the optimal path using a greedy algorithm (presented in the paper above on RRTs) asopposed to Dijkstras algorithm due to its significantly faster computational speed

SDA Path

Bezier Curve Smoothing

Although RRTs can build paths rapidly ours teamrsquos current implementation does not account for non-holonomiccontraints of the plane That is to say the RRT can create a path that the plane will be unable to fly due to the turningradius of the plane To account for this we use G2 continuous cubic bezier curves to smooth sets of three waypointsG2 continuity is a property of functions that helps to ensure that the curves created are possible for the plane to flyThis approach to path smoothing enables us to compute the RRT without taking in to account the turning radius ofthe plane and then smooth and alter the optimal path to ensure fliability The smoothing algorithm is simplest ifperformed on a set of three waypoints in two-dimenstional space oriented such that the first waypoint is at the originand the second waypoint lies on the x-axis This is accomplished using a series of matrix transformations

Conversion from Splines to Waypoints

Our current autopilot is unable to fly spline waypoints so an algorhithm is required to convert the bezier curves pro-duced by the path smoothing algorithm into a fliable set of waypoints To accomplish this our team uses a modificationof the Segmented least Squares Algorithm (a dynamic programming algoiythm that allows for linear regression usingmultiple lines) To use the modification of the segmented least squares algorythm we first break the bezier curves(produced in the smoothing algorithm) into a series of points We then run the segmented least squares algorithm onthis set of points but instead of using simple linear regressions to determine the minimum error line that can be placedbetween a pair of points we combine two metrics of error First we account for the angular error of the line placedbetween the pair of points by calculating the angle between the derivative of the bezier curve at the second point andthe chord connecting the two points This angular error fucntion aims to prevent waypoints from being placed in sucha way that the plane is unable to fly the set of waypoints due to turning constraints The second error function accountsfor linear error and attempts to ensure that the plane flies as close as possible to the bezier curve The linear error isdefined as the maximum distance from the bezier curve between the points and the chord connecting the points Thisis aproximated using a form of binary search on the set of points sampled from the bezier curve The search terminateswhen the point on the bezier curve of maximum distance to the chord is found by weighting the two above errors withconstants and adjusting the constant that accounts for the cost of adding more lines we can tune out algorythm to fitcurves well in practice

Current Issues The current implemenation of SDA which uses curve smoothing to attempt to account for non-holonomic constraints of the plane runs into some serious issues implicit to the approach itself To begin with the act

32 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 36: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

of converting from a series of points to a series of bezier curves back into a series of points necissarily produces adegree of uncertainy as to the nature of the final path At each of these steps the path is necissarily altered in a waythat is not necissarily easy to predict This produces a degree of uncertainty that is not easy to quantify and thereforesomewhat dangerous The largest issue with the current implemenation of SDA though has to do with the turningradius of the plane Although path smoothing can help to reduce the sharpness of the turns the plane will make it cannot ensure fliability in all scenerios We believe these constraints are better imposed in the RRT itself a topic that willbe discusses in the following section

Future Directions For reasons enumerated in the above section out team believes it is best to impose curvatureconstraints within the RRTrsquos extension algorhithm itself This can be accomplished by constructing and applyingwhat is known as a Motion Primitive Set This set is a series of curves that are known to be fliable by the plane withrespect to its minimum turning radius Rather than simply extending the RRT towards the random point selected thefuture implemenation will the extend along the curve in the motion primitive set with endpoint closest to the randompoint The motion primitive set should only augment the extension algorhithm of our current RRT implemenation andwe plan to continue using a greedy biased ERRT (detailed under the RRT section) This should also remove the needfor path smoothing and spline to waypoint conversion

SDA Version 1

To complete this task the team developed a reactive algorithm to anticipate flight path and predict obstacle locationsThe algorithm creates a 3D geometric model with flight paths and moving obstacles as point entities on linear trajec-tories to the next waypoint in the flight plan and stationary obstacles as lines with lengths equal to their height Ouralgorithm identified potential obstacle collisions by calculating minimum distance between the linear entities usingthe linear closest point of approach (CPA) for moving obstacles and the closest point of two 3D line segments forstationary obstacles CPA assumes constant velocity vector u for the obstacle and constant velocity vector v for theplane and is defined as 119889(119905119862119875119860) = |w0 + 119905119862119875119860(uminus v)| where mathlsquomathbfw_0lsquo is the distance vector betweenthe initial positions of the plane and obstacle Time of CPA 119905119862119875119860 is calculated as follows

119905119862119875119860 =minusw0middot(uminus v)

|uminus v)|2

To detect collisions with stationary obstacles the ground station models the planersquos flight trajectory to the designatedwaypoint as a line segment r(119905) = 1198750+ 119905v and the center of the stationary obstacle as a line segment q(119904) = 1198760+ 119904uwhere 1198750 is the initial position of the plane 119904 and 119905 are length variables u and v are direction vectors and 1198760 is the

13 License 33

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 37: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

zero altitude location of the obstacle The distance equation is derived as follows

119889(rq) =|(Q0 minusP0)middot(utimes v)|

|utimes v)|

Distances less than the obstaclersquos radius for either equation are considered collisions

Once collisions are detected a line (A) between the flight trajectory and the projection of that line onto the center ofthe obstacle is calculated The algorithm iteratively calculates linear trajectories between the plane and points on Aas potential waypoints each further from the center of the obstacle than the last until the projection of the obstaclecenter onto the potential trajectory is greater than the obstaclersquos radius with a 10 meter buffer to ensure a collision-freeflight path Once an optimal waypoint is found to avoid collision with the obstacle on the original flight path thepotential waypoint is then run through a number of safety checks before being sent to the plane The ground stationfirst cycles through all the obstacles and checks that the waypoint is not being placed within any other obstacles Inthe case that the waypoint is placed within an obstacle the line A is recalculated such that the potential waypointsare being moved to the other side of the obstacle We then check to see that the waypoint is not placed outside of thegeofence If that does occur we recalculate in the same way trying to avoid the obstacle by diverting the trajectoryin the opposite direction Once the potential waypoint has passed all safety checks it is then sent to the groundcontrol station as an auxiliary waypoint This process runs every time the ground station receives new obstacle datafrom the interoperability server to adjust the flight path as the velocities of the plane and obstacles change When therecalculated path changes the ground station deletes the old auxiliary waypoint and replaces it with the new one

Other Details

Implementation SDA is mostly contained to modulesmavproxy_sdapy but it also uses the mod-ulessda_geometrypy module for geometry and unit conversions between longitudelatitude and an x-y-z co-ordinate system using meters Mavproxy runs SDA everytime the mavlink_package() method returns alsquoGLOBAL_POSITION_INTrsquo package and therefore runs every time new GPS location data from the plane is avail-able

Future Directions for SDANote This section is only being written to help plan for reimplementing SDA during the 20162017 year No criticalinformation for the function or editing of SDA is below

SDA currently has a relatively naive implementation seeing that planes donrsquot fly on linear trajectories and the math-ematical model we are using does not take into account flight dynamics in any way eg SDA does not know howquickly the plane can turn We are looking to solve that problem in the future by reimplementing SDA using 4Dsplines While it will provide many benefits this implementation will greatly increase the complexity of the problemin the following ways

34 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 38: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

1 Correctly implementing 4D splines as part of the mathematical model will require quite a bit of research into thebest types to use and how to properly model the planersquos movement along those spline paths taking into accountvelocity and acceleration While this is very doable it will be an undertaking Additionally writing code for 4Dsplines is just going to be more difficult that standard lines

2 Finding the CPA of a 4D spline and a line is much more difficult now that there is no constant time algorithmfor calculating such a point Thus it becomes an optimization problem We would have to create a 3D weightfunction and then perform gradient descent to find optimal waypoint placement

While these present significat challenges this new implementation would make flying with SDA a much safer experi-ence for the plane and will hopefully make it more accurate at avoiding obstacles

Ardupilot

Contents

bull Ardupilotndash Project Atlasndash Tuning

Rolling Takeoff Landing

ndash Failsafe Standard Failsafe

middot Throttle Failsafe Setupmiddot Standard Failsafe Configuration

Advanced Failsafemiddot Disabling the failsafemiddot Advanced Failsafe Configuration

This section documents any CUAir specific uses of or changes to Ardupilot

Project Atlas

For documentation see httpsdocsgooglecomdocumentd1yiXgehSbKX3eEdflroVd67lgQAZRXYEeqocb-Km1RCMeditusp=sharing

Tuning

Rolling Takeoff

Before attempting to set parameters determine landing gear style and stall speed of the aircraft For information onspecific takeoff and landing parameters see httpardupilotorgplanedocsflight-featureshtml For complete parame-ter list see httpardupilotorgplanedocsparametershtml

If plane is a taildragger (like Bixler)

TKOFF_TDRAG_ELEV 100TKOFF_TDRAG_SPD1 ltjust below TKOFF_ROTATE_SPDgtTKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 0TECS_PITCH_MAX 20GROUND_STEER_ALT 5

13 License 35

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 39: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

If plane has tricylce landing gear

TKOFF_TDRAG_ELEV 0TKOFF_TDRAG_SPD1 0TKOFF_ROTATE_SPD lt110-130 of stall speedgtTKOFF_THR_SLEW ltminimum of 20gtTKOFF_FLAP_PCNT 50TECS_PITCH_MAX 22GROUND_STEER_ALT 5

To tune ground steering test in mode FBWA

Landing

If plane is a taildragger (like Bixler)

LAND_FLARE_ALT 0LAND_FLARE_SEC 12LAND_PITCH_CD ltslightly above natural pitch of aircraft - 500 for BixgtTECS_LAND_ARSPD ltabove stall speed - 8 for BixgtTECS_LAND_SPDWGT 1

If plane has tricylce landing gear

LAND_FLARE_ALT 0LAND_FLARE_SEC 2LAND_PITCH_CD 500TECS_LAND_ARSPD ltabove stall speedgtTECS_LAND_SPDWGT 1

To ensure a smooth descent LAND_PF_ARSPD (a pre-flare descent parameter) must be set to a higher value thanTECS_LAND_ARSPD Additional note the parameter settings as they appear here were determined to be appropri-ate for a general airframe in these two landing gear types If setting parameters for non-standard airframe furtherconsideration is required

Failsafe

The competition rules specify the following rules for failsafe

bull After 30 seconds Return to Launch

bull After 3 minutes Terminate flight

These events are required to occur upon loss of the primary communications link which for CUAir 2015-16 is thetransmitter The first requirement is accomplished through the standard failsafe the second is accomplished throughthe advanced failsafe

Standard Failsafe

The competition rules require that the plane executes an RTL after 30 seconds of lost primary communications linkFor CUAir 2015-16 this is the transmitter The included parameters include an additional failsafe that cause the planeto CIRCLE after 2 seconds of lost transmitter signal ONLY if it was in a manual control mode when the transmitterloss ocurred then RTL in 30 seconds

36 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 40: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Throttle Failsafe Setup The standard failsafe uses the throttle input channel of the transmitter to determine if it haslost transmitter signal If the receiver loses connection to the transmitter it will begin outputting the lowest throttlestick value To make throttle failsafe work we need to ensure that what the receiver thinks that the lowest throttle stickvalue is is lower than the actual low throttle stick on the transmitter This way if the transmitter fails the receiver willoutput a value lower than it ever would if the transmitter was on and Ardupilot will take that as a signal to initiate thefailsafe

Read this document for more information and generic setup instructions

Setup instructions

1 Set the low point of the throttle on the transmitter (Should be Channel 3 but check on Mission Plannerrsquos RadioCalibration page) to extend below -100

bull If this is not possible set it to its lowest possible value

2 Bind the transmitter with the receiver

bull For the ezUHF receiver follow the instructions in the ldquobindingrdquo section here

3 Set the low point of the throttle back to its original value If you ever need to bind the transmitter again for anyreason you will need to repeat the setup process

bull If it was not possible to set the throttle beyond -100 then at this step set it to a higher value such as -90If this is necessary DO NOT turn on the planersquos throttle until you finish these instructions completely orthe throttle will activate while the stick is down

4 Do the radio calibration in mission planner to tell Ardupilot what the new range of the throttle is Once this isdone record the low point of the throttle stick while the transmitter is on Afterwards turn the transmitter offand ensure that that value drops

bull If it does not drop it is possible that the failsafe levels of the receiver need to be set Set the transmitterback to the low point then while the receiver is on and the throttle is down hold the button on the back ofthe transmitter Then repeat from step 3

5 Set the THR_FS_VALUE to a value between the throttle down point and the transmitter off point you recordedin step 4 A value somewhere in the middle is good - not too close to either endpoint to account for somevariation

6 Set THR_FAILSAFE to 1 to enable the failsafe

7 Ensure the other parameters are set as below

Standard Failsafe Configuration For the standard failsafe to function as described complete the above setup in-structions then set the parameters as shown below

THR_FS_VALUE ltSEE ABOVE - in range 925-1100gtTHR_FAILSAFE 1FS_SHORT_ACTN 0FS_SHORT_TIMEOUT 2FS_LONG_ACTN 1FS_LONG_TIMEOUT 30FS_BATT_VOLTAGE 0FS_BATT_MAH 0FS_GCS_ENABL 0

Advanced Failsafe

Disabling the failsafe To disable the failsafe set AFS_ENABLE to 0 This MUST before done within 3 minutes oftransmitter communications loss

13 License 37

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 41: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

AERODYNAMIC TERMINATION IS UNRECOVERABLE - ONCE TERMINATION BEGINS 3 MINUTESAFTER TRANSMITTER LOSS IT CANNOT BE ABORTED

Advanced Failsafe Configuration Important If these parameters are set as above the plane will terminate after3 minutes of lost transmitter signal Make absolutely sure you know what you are doing when use this failsafe systemAerodynamic termination WILL result in a crash and is UNRECOVERABLE once activated

This is the failsafe system that causes flight termination after 3 minutes of transmitter loss This system works throughthe throttle failsafe as shown above so the throttle failsafe needs to be set up correctly for this to work The AFSparameters should be set as follows to comply with competition rules

AFS_WP_COMMS 0AFS_WP_GPS_LOSS 0AFS_TERM_ACTION 42AFS_AMSL_ERR_GPS 100AFS_QNH_PRESSURE 0AFS_ENABLE 1AFS_MAX_GPS_LOSS 0AFS_MAX_COM_LOSS 0AFS_GEOFENCE 0AFS_RC 1AFS_RC_MAN_ONLY 0AFS_DUAL_LOSS 0AFS_RC_FAIL_TIME 180

The AFS_TERM_ACTION parameter is the final safeguard between terminating the plane and doing nothing whenthe flight termination condition is met It should never be 42 unless you are absolutely sure you want the plane toterminate when the transmitter link has been lost for 3 minutes For test flights it should always be at 0 - the only timeit should be 42 is during competition

See the AFS documentation and the AFS parameter list for more information

Catapult

Contents

bull Catapultndash Overviewndash Icarus Eos Interfacendash Odysseus Interface v10ndash Odysseus Interface v11ndash Bixler Interfacendash Control System

How to Flash the Arduino Description Software safety mechanisms

ndash Operation Instructions Setup Operation

Additional information including BOM and Design paper can be found at the catapult github repository httpsgithubcomCUAircatapult

38 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 42: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Overview

The catapult cart is the direct interface between the catapult and the aircraft Its design is critical for successful takeoff

The cart is composed mainly of aluminum sheet metal which has been water-jet cut to shape The geometry of thecart adds strength in the needed locations while keeping mass to a minimum Two identical side plates serve as theprimary mounting surfaces for the cartrsquos various interfaces as well as large stopping bloacks that contact the framedamper springs and distribute the loads present during deceleraion Four shafts contain a total of eight wheels thatride along the corners of the frame An additional piece known as the pin tension member spans the top two shafts Acarabiner connects this member to the cable at the front of the cart At the back of the pin tension member is a holethat interfaces with the safety pin

The cart frame experiences its highest loading upon impact with the spring stoppers It must decelerate from 15 ms torest in about 57 cm This is a deceleration of approximately 200 G Since all of the force of the deceleration is appliedto the stopping blocks they have to sustain an average force of approximately 1000 N (225 lb) each Thus ensuringthat the cartrsquos connections fully constrain the aircraft from undesired motion is a high priority in all present and futuredesign changes

Icarus Eos Interface

The original design of the cart was created for Eos Its interface comprises of four arms fit to the top two shafts in thecart The front two arms are connected to a ratcheting mechanism that constrain them in place until the cart reaches theend of its track restraining the plane in place as the throttle is applied At the end of the track the ratchet is releasedand the arms pivot about the cart shafts During launch they exert a force on the plane at their tips The momentcreated by the force of the plane is balanced with the use of four rubber bumpers mounted to the cart walls Uponimpacting the damping springs the arms rock forward and bounce off the bumpers allowing them to gently come torest

In its final iteration the cart was 10 kg and 125rdquo in length

13 License 39

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 43: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

The interface between the arms and the plane was designed to lock into the plane during acceleration and slide awayduring detachment All four arm tips fit into small holes cut into the bottom of the plane Icarus was designed witha Kevlar fuselage embedded with high-strength garolite plates laser-cut to conform with the arms of the cart Duringacceleration the plane has a tendency to pitch up since the horizontal forces are being applied below the center ofmass To prevent this pitching response the front two arms feature small hooks that grip the fuselage skin The backarms only require small nubs that interface with the fuselage holes since the pitching tendency acts to push them furtherinto the holes Upon detachment the arms pivot out of the holes and the plane continues in straight-line motion

Odysseus Interface v10

The interface designed for Odysseus required significant modification to the existing Eos cart design While existingmechanisms like the fitted launch arms and the pin tension member were retained new mechanisms such as the cradlewere introduced to the cart in this iteration

Foremost the cartrsquos side plates and the pin tension member were extended to 185rdquo in length Additional changesmade to the weight reduction design for three holes the back two 0375rdquo in diameter and the front 019rdquo in diameteron the top side of each side plate These holes were included to attach the cradle as well as facilitate future interfacedesigns as needed

The cradle provides a surface that is stable enough to constrain the aircraft during acceleration while smooth enoughto allow for clear removal from the cart It is comprised of two side plates three ribs and a polycarbonate cover Eachrib pieces into the side plates and is held in place by the side platersquos connection to the three mounting holes on the cartitself These plates are bolted through 4 18-8 machine screws in each of the back two holes and a 8-32 machine screwin each front hole The polycarbonate cover is attached to the upper surface of the finished cradle assembly via wetcement or gorilla glue

40 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 44: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Odysseus Interface v11

As of May 2016 significant modifications have been made to the Odysseus interface and base cart The thickness ofthe base cartrsquos side plating the pin member and the front cart arms have been increased from 316rdquo to 14rdquo Afterobservations of parallel plate motion in field testing six perpendicular rods have been incorporated into the cart into torestrict parallel plate motion The upper three of the rods have replaced the the machine screws which piece the cradleto the base cart The stopper pieces for the front cart arms and the launch armrsquos springs have been merged into onepiece called the stopper Testing of these cart modifications has yet to be conducted

13 License 41

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 45: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Bixler Interface

The interface developed for the Bixler 3 test plane consists of two sloped extended shafts that piece into a channelcut in the bottom of the Bixlerrsquos fuselage Initial development consisted of two wooden tabs cut to ~2rdquo and sloped ontheir upper edge These tabs are connected by means of an single 8-32 machine screw locknut and a mirrored washerarrangement threaded through the centered pin member of the cart

This assembly is functional in securing the Bixler to the catapult throughout launch however several improvements

42 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 46: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

are needed for further use Issues that have arisen in testing thus far include failure to constrain lateral motionexcessive tearing of the Bixlerrsquos fuselage and complete mechanical failure Foremost 3D printing of the functionalassembly into a single or two interlocking parts has been explored and should be fabricated for future use ConceptualCAD schematics for a new Bixler interface are pictured below and are available on the Mechanical Subteamrsquos CornellBox

Control System

The following describes the catapult control system The microprocessor used for control of the catapult is the AdafruitPro Trinket 5V16MHz The latest version of the control code can be found at httpsgithubcomCUAircatapultblobmastercatapultino

How to Flash the Arduino

Dependencies Arduino Liquid Crystal Library httpplaygroundarduinoccMainLiquidCrystal

1 Prepare your IDE to be compatible with the Adafruit trinket Follow these instructions httpslearnadafruitcomadafruit-arduino-ide-setupoverview

2 Clone the git repository and make any necessary edits using the Arduino IDE

3 Plug in FTDI cable to the pins on the front of the control box and to a USB port on your computer

4 Under the Tools menu set the Board to the Pro Trinket 5V16MHz (FTDI) and set the Programmer to USBtiny-ISP

5 Check that the IDE recognizes the Arduino COM port by the presence of a check next to the COM port in theToolsgtSerial Port menu

6 Compile the code by pressing the check-mark icon in the top left corner

7 Upload the code to the Arduino by pressing the arrow icon in the top left corner

Description

The control code is structured as a state machine - to allow for distinct states like pressurizing and primed and espe-cially for added safety Please refer to the source code for a detailed descriptions of each state See operation sectionfor operation instructions

13 License 43

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 47: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

The catapult control software has several functions It controls the behavior of the compressor and the launch valveit shows diagnostic information to the operator and it enacts several safety measures to prevent accidents Batteryvoltage and currenttarget pressure are displayed to the user User input determines what value to pressurize to whento pressurize and when to launch

The raw values of the pressure and battery voltage readings are mapped by constants that were measured by handThe battery voltage mapping is a direct scale factor of 0012289 in the code it is the constant lsquobattVoltageFactorrsquoThe pressure mapping is more complex The value displayed to the user is the direct reading from the transducer butan altered value is used to determine when to stop compressing because there are fluctuations in pressure readingswhile the compressor is on These fluctuations are larger at higher pressures so a jitter value is determined based on ascaling down of the target pressure The compressor stops when the pressure reading minus the jitter value is equal tothe target pressure This was thoroughly tested and shows excellent results The jitter value is a linear mapping of therange 0-150 (target pressure) to 3-10 If altering the code under no circumstances should the upper pressure threshold(read from the potentiometer) be raised above 150 Refer to source code for further comments

bull init - Initialize default state displays warning to user and initializes sensors

bull dSP - Pressure Set Display Displays the text template to for pressure to the screen and then sets state to SP

bull SP - Set Pressure Displays potentiometer data to the screen and saves value to pressure variable On press ofthe pressurize button sets state to dPress

bull dPress - Pressurize Display Displays template for pressure and battery diagnostics

bull Press - Pressurize Turns on pump displays current pressure goal pressure and battery voltage When currentpressure = goal pressure sets state to Primed

44 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 48: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

bull Primed - Primed Turns off pump displays pressure and battery stats and turns on launch LED On pressurizebutton push returns to dPress On launch switch sets state to Fire

bull Fire - Launch Catapult Opens servo waits launch duration closes servo (fires catapult) Turns off launchswitch LED and sets state to dSP

Software safety mechanisms

bull Device will never pressurize to values above 150 psi

bull Software makes sure that the launch valve is closed before comprpession begins

bull System cannot launch without primed LED (on the launch switch) being on

bull Debouncing disregards false launch and pressurize readings

bull Screen shows warning messages upon initialization

bull Battery voltage displays lsquoCRITICALrsquo when voltage is below 1145V

bull State machine design ensures that launch CANNOT occur if not in the primed state

Operation Instructions

Setup

1 Catapult should typically be set up to launch into the wind Catapult box must be set up next to the catapult andmust open towards it plan accordingly and place the box in the correct location

2 Remove two main parts of the catapult (large metal extrusions) Unsecrew the thumbscrews from the backportion and unwrap the cord from the front portion Unfold the legs of the front piece and insert the respectivepins

3 Slide the catapult cart onto the back piece in the correct orientation

4 Insert the back piece into the front piece and screw the thumb screws in Make sure they are screwed in tightand have someone double check that this is the case

5 Connect carabiner to catapult cart Insert safety pin into the back of the catapult

6 Connect the longest tube from the pressure tank to the front of the catapult Connect compressor tube to thecatapult box

7 Unspool ethernet cord connect one end to catapult box and the other end to the control box lay box far awaybehind and to the side of the catapult

8 Connect compressor power cable and connect 12V battery cable to catapult box

Operation

1 Turn the system on by turning the key to the on position

2 Read warning displayed on control box

3 Make sure that the safety pin is in place before proceeding

4 Turn pressure dial until the screen displays the desired target pressure

5 Announce that you are pressurizing the catapult and press the pressurize button

13 License 45

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 49: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

6 Once the compressor is finished pressurizing the LED on the launch switch will turn on This means that thecatapult is primed and ready to fire Do not lift the switch cap unless you are prepared to fire

7 Have someone else pull out safety pin

8 When everyone is ready lift switch cap and toggle the launch switch to fire

9 Once the plane has launched send two or three people to remove the catapult from the runway

10 To launch again return to step 3 otherwise turn the key to the off position and pack up the device

Test Flights

Contents

bull Test Flightsndash Overviewndash Preparation for a Test Flightndash Before the Test Flightndash At the Test Flight

Code to run at test flightsndash Hex Flying Procedure Without GCS

Overview

The autopilot sub-team has developed numerous resources and strategies to be most efficient and productive at testflights This page details these methods and consolidates links to essential resources

Preparation for a Test Flight

Please read the ArduPlane Documentation to familiarize yourself with tuning methodologies

Here you can also find a description of the meaning of different Pixhawk status LEDs

Before the Test Flight

Charging batteries ndash Batteries need to be changed before every flight This documentation describes how to do sosafety

Packing Checklist ndash Before leaving for a test flight test accordingly in the lab and ensure these items are packed

At the Test Flight

Roles ndash Assigning more limited roles at test flights ensures team members can work concurrently

Preflight Todo Checklist ndash Follow these steps carefully to avoid common issues with flight

Tuning guide ndash This manual details the steps needed to tunning ArduPlane Print the manual and follow along accord-ingly

Flight Cards ndash Fill out one of these at each test flight

46 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 50: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Code to run at test flights

bull APM Planner ndash as a backup APM should be installed on all computers

bull MAVProxy ndash Installation and instructions for using the ground station can be found here

bull Interoperability ndash Setup can use of the interoperability server can be found here

ndashlsquoAutopilot server ltgtlsquo_ ndash Setup and use of autopilot server for the NUC can be found here

Hex Flying Procedure Without GCS

Pre-flight checks

bull Make sure all the props are placed in the correct directions There are little red arrows on each motor for thedirection that it should spin

bull Check that all the motors do indeed spin in that direction If they spin the other way swap the red and blackplugs from the ESC

bull Double and triple check that all props are screwed down tightly

Now you can begin flight procedure

1 Turn on Taranis make sure you are on the model ldquohexrdquo

2 Plug in 6s battery

3 Wait until main light is flashing a single color (preferably green - maybe blue - not yellow)

4 Press and hold safety switch until the ESCs beep and the light on the safety switch becomes solid green Themotors may twitch a bit Atlas is now live

5 MAKE SURE EVERYONE IS FAR AWAY FROM THE HEX

6 Arm Atlas On the transmitter hold the left stick down and right until Pixhawk light becomes a solid color andprops start spinning slowly It is now armed

7 Fly Optionally set mode to lsquolandrsquo on ground station for auto landing if GCS is connected

8 To disarm the hex hold left stick down and left until props stop spinning and main pixhawk light starts flashing

9 Press and hold the safety switch until the ESCs beep and the safety switch begins flashing green

10 Unplug the battery

Autopilot Configuration and Setup

Contents

bull Autopilot Configuration and Setupndash Overviewndash Setting up RFD900sndash Using 3DR radios on Mac OSndash Binding Transmitter and Receiverndash Wiring guidendash Hexacopter Setupndash Telemetry to autopilot wire pin out

13 License 47

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 51: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Overview

This page documents remaining autopilot configuration procedures that do not relate to ardupilot software

Setting up RFD900s

We use RFD900+ radio modems Please read the data sheet before attempting to change the modem settings

1 Firmware can be installed on RFD900s with windows using the RFD900 configuration tool This can be foundhere

2 Settings should match below guide Make sure to use the same netid on both nodes of a piar and use differentnetids on different pairs If you have different settings than shown you may need update your firmware

Baudrate 115200Airspeed 250NetID xxTx Power 27NodeID 1 GROUNDBASE NODE SHOULD HAVE THESE REVERSEDNode Destination 0 GROUNDBASE NODE SHOULD HAVE THESE REVERSED

Min Freq 902000Max Freq 928000Number of Channels 50Duty Cycle 100Node Count 2

ECC (unchecked)Mavlink (checked)Sync any (unchecked)Op Resent (checked)RTCSTS (unchecked)

3 You can check that two RFD900s are paired and communicating with screen In terminal run the command

screen devttyusbltDEVICE_NAMEgt ltBAUDRATEgt

For example

screen debttyusbmodem1 115200

Using 3DR radios on Mac OS

Sorry this is kind of a pain

1 Confirm you are not using the Apple FDTI driver

cd SystemLibraryExtensionsIOUSBFamilykextContentsPlugInsls AppleUSBFTDIkext

If the kext is in this folder disable it with the following command

sudo mv AppleUSBFTDIkext AppleUSBFTDIdisabled

2 Download the latest FTDI driver from httpwwwftdichipcomDriversVCPhtm I used x64 (64-bit) for OSX109+

3 Find the name of the device in ldquoSystem Informationrdquo -gt USB -gt USB Device tree Mine was named ldquoCP2102USB to UART Bridge Controllerrdquo

48 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 52: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

4 Plug in the the radio and Run system_profiler -detailLevel full and grep for the name found instep 3 You will need to locate the information for ldquoidVendorrdquo ldquoidProductrdquo ldquobcdDevicerdquo My radio had thefollowing info

idProduct = 0xea60bcdDevice = 0x100idVendor = 0x10c4

5 Open SystemLibraryExtensionsFTDIUSBSerialDriverkextContentsInfoplist and add a new keydictionaryunder IOKitPersonalities and make sure above 3 values(idVendor idProduct bcdDevice) are there and correctYou can do this with applersquos plist editor or by opening the file and directly editing the XML All values must bedecimals (the values found in step 4 are in hex) I added the following to my XML

ltkeygtCP2102 USB to UART Bridge ControllerltkeygtltdictgtltkeygtCFBundleIdentifierltkeygtltstringgtcomFTDIdriverFTDIUSBSerialDriverltstringgtltkeygtIOClassltkeygtltstringgtFTDIUSBSerialDriverltstringgtltkeygtIOProviderClassltkeygtltstringgtIOUSBInterfaceltstringgtltkeygtbConfigurationValueltkeygtltintegergt1ltintegergtltkeygtbInterfaceNumberltkeygtltintegergt0ltintegergtltkeygtbcdDeviceltkeygtltintegergt256ltintegergtltkeygtidProductltkeygtltintegergt60000ltintegergtltkeygtidVendorltkeygtltintegergt4292ltintegergtltdictgt

6 Our driver will no longer match the systemrsquos signature so we will need disable System Integrity Protection toload the driver To do so first restart into recover mode by restarting your the computer and holding CMD+R assoon as you hear the boot noise until the apple logo appears on the screen Then run the command csrutildisable in the terminal

7 Restart your computer and load the new FTDI driver with the commands

sudo kextunload SystemLibraryExtensionsFTDIUSBSerialDriverkextsudo kextload SystemLibraryExtensionsFTDIUSBSerialDriverkext

8 You should now see the FTDI device with ls dev |grep usbserial

Note Permenatly disabling csrutil and can leave your computer vulnearble to some nasty hacks When you aredone using the radios rename csr by restarting into recovery mode and entering the command csrutil enable

Binding Transmitter and Receiver

We use an EzUHF 4 Channel Receiver and an EzUHF Transmitter JR Module on a Taranis Transmitter Refer to theirrespective documentation if there is any confusion about the following binding procedure

1 Download ImmersionRC update config tool software

2 Connect the transmitter to the computer with the config software

3 On the software set the transmitter to extreme hopping

4 Connect the receiver to the computer with the config software

13 License 49

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 53: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

5 On the receiver set the frequency band to match the transmitter frequency band

6 On the servo mapping tab set PPM slot and servo output as follows

PPM1 CH2PPM2 CH3PPM3 CH1PPM4 CH4PPM5 CH5PPM6 CH6PPM7 CH7PPM8 CH8

CH1 PPM MuxedCH2 -CH3 -CH4 -

7 Put the transmitter into bind mode by turning it off and then holding the bind button on the module on the backas it turns on It should start beeping slowly

8 Put the receiver into bind mode with the bind tab in the software

9 The software should tell you that you have successfully bound the receiver

Wiring guide

Output pin Mode Surface Inverted Transmitter8 19 Left Elevator Yes9 21 Rudder11 2 Left Flap5 4 Left Aileron Yes10 2 Right Flap12 4 Right Aileron Yes3 na Throttle7 19 Right Elevator Yes

Hexacopter Setup

Atlas is a portable lightweight test system to allow subteams to test without needing to do a full test flight It is able tocarry several pounds of payloads that can be mounted as necessary and is significantly easier to fly than a fixed wingaircraft

The base onboard electronics include

bull 1x Pixhawk autopilot with gps module running ArduCopter

bull 6x 30A ESCs

bull 1x RFD900 ndash setup is identical to the plane radios

ArduCopter setup is very similar to ArduPlane setup and is completely documented here The key difference is ESCcalibration which must be re-done after major system changes like receiver replacement or motor replacement

Atlas flight instructions can be found here

50 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 54: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Telemetry to autopilot wire pin out

Pictured here

RFD side (Left when flat side up) Autopilot side left1 white 62 black 13 black 54 red 25 black 36 black 4right white right

MAVProxy Playback

Contents

bull MAVProxy Playbackndash How to Set Up

Dumping the Database after the Testflight Loading the Dump File into the Playback Database Launching the Flask App

ndash API endpoints Status [status] Attitude [statusattitude] Airspeed [statusairspeed] Climb [statusclimb] Flight Time [statusflight_time] GPS [statusgps] Throttle [statusthrottle] Wind [statuswind]

The equivalent to the database and API endpoints for MAVProxy intended for use by the distibuted team to replaytestflights

How to Set Up

Dumping the Database after the Testflight

Once the flight is complete from MAVProxy dump the database into a file named mysqldumptxt

sudo mysqldump --result-file=mydumpsql -paeolus mavproxy

Loading the Dump File into the Playback Database

once the file is copied into the playback folder this will reload the data into this database

sudo mysql -paeolus mavproxy lt mydumpsql

if you get the canrsquot connect to mySQL server through socket erorr try

13 License 51

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 55: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

mysqld

if this is the first time you are running the database on your computer or you get the no database error try

setup_dbsh

Launching the Flask App

export FLASK_APP=playbackStatuspypython playbackStatuspy

API endpoints

Status [status]

Get the status of the plane A large json containing each piece of data as a namevalue pair A call can also be made tostatus to receive an individual bit of data (below)

+ Response 200 (applicationjson)

attitude pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

airspeed vx 00vy 00vz 00

climb 00

flight_time time 00time_start 00is_flying False

gps rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

throttle 0

52 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 56: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

wind vx 00vy 00vz 00

Attitude [statusattitude]

Returns the planersquos attitude containing

bull Pitch [float]

bull Yaw [float]

bull Roll [float]

bull Pitchspeed [float]

bull Yawspeed [float]

bull Rollspeed [float]

+ Response 200 (applicationjson)

pitch 00yaw 00roll 00pitchspeed 00yawspeed 00rollspeed 00

Airspeed [statusairspeed]

Returns vectors vx vy vz representing the airspeed velocity of the airplane as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

Climb [statusclimb]

Returns a float value representing the climb of the plane

+ Response 200 (applicationjson)

00

13 License 53

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 57: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Flight Time [statusflight_time]

Returns the information about the flight time conntaing

bull time_start [float]

bull if_flying [boolean]

+ Response 200 (applicationjson)

time 00time_start 00is_flying False

GPS [statusgps]

Returns various values from the planersquos onboard GPS containing

bull rel_alt [float]

bull asl_alt [float]

bull lat [float]

bull lon [float]

bull heading [float]

bull vx [float]

bull vy [float]

bull vz [float]

+ Response 200 (applicationjson)

rel_alt 00asl_alt 00lat 00lon 00heading 00vx 00vy 00vz 00

Throttle [statusthrottle]

An integer from 0 to 100 representing the current throttle level of the plane

+ Response 200 (applicationjson)

0

54 Chapter 1 Welcome

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 58: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

Wind [statuswind]

Returns vectors vx vy vz representing the wind velocity vector as floats

+ Response 200 (applicationjson)

vx 00vy 00vz 00

13 License 55

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 59: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CUAir Autopilot Documentation Documentation Release 10

56 Chapter 1 Welcome

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables
Page 60: CUAir Autopilot Documentation DocumentationYay, documentation! How to edit this page Easy Mode •Click the “Edit on GitHub button at the top of any page” •Edit the page •Click

CHAPTER 2

Indices and tables

bull genindex

bull modindex

bull search

57

  • Welcome
    • How to edit this page
    • Support
    • License
      • Indices and tables