For a high level description of the IFL and its capabilities, see the IFL website "About the IFL" page.

What tools the IFL provides:

• A 55 camera Vicon system distributed across two rooms that can be used separately or combined.

• Two GTAE-IT managed Windows 10 PCs (one in each IFL room) equipped with high end network cards for interfacing with the Vicon hardware, and installed with Vicon Tracker.

• A TP Link WiFi router connected to the IFL1 PC for connecting remote devices to the IFL network.

• A Github repo containing multiple options for connecting to the IFL network and getting Vicon data onboard your vehicle.

What the IFL does not provide:

• Vicon markers (these can be bought at B&L Engineering)

• Any robots (ground or aerial) or associated hardware

• Any hardware or software for implementing specific functionality (such as radio links, microcontrollers, or robot command/control software)

What tools the IFL will be adding in the future:

• A multi-purpose parameter identification rig for measuring a robot's mass, 3D center of mass, and mass moment of inertia [in progress].

• A 3DOF dynamic gimbal rig for restrained flight, enabling safe initial gain tuning [in progress].

• A static thrust/torque rig for characterizing the mechanical and electrical performance of an individual motor/prop or an entire airframe up to a certain size.

• Additional software capabilities

As of 6/28/21:

• For general use of the space not needing Vicon, only IFL1 is available to schedule.

• IFL2 is temporarily being used to host surplus equipment for the next couple of weeks.

• For Vicon use, only IFL1 can currently be used. IFL2 PC is ready to go but needs an ethernet cable running securely to the switch box.

IFL planned future works:

• Installation of server racks for the network switches and Lock

• Running of ethernet cable from network switch to IFL2 PC

• Improved power switching

• Cable re-positioning to allow the IFL1 screen to fully drop

• Installation of permanent calibration markers

• Installation of TV screen on bracket by IFL1 control booth

• Floor markings denoting geometric center and grid or similar

• Height markings

• Successful calibration of IFL1+IFL2 combined calibration

• Review and potential upgrade of WiFi router

In many cases, IFL users will need to use Vicon data in real time (such as in real-time onboard/offboard control, synchronizing data, or ground control visualization). To facilitate this, Vicon Tracker continuously outputs onto the local network over a UDP stream, which can be accessed by the user directly or by using Vicon's DataStream SDK.

Over time the IFL team and its users have developed, and will continue to develop, code that covers many of the functionalities future users may wish to perform. This code can be found in the IFL repo and described in the IFL Codebase section of this Gitbook.

Direct UDP Access

Since the Vicon data stream is being output over the well-defined UDP IP protocol, this stream can be directly accessed, parsed, and used by any device/application with the ability to connect to the network. Many great off-the-shelf libraries exist to facilitate this, such as:

• Python: "import socket"

• C/C++: "include <sys/socket.h>"

• MATLAB: udpport()

• Simulink: "UDP Receive" block in the Instrument Control Toolbox

See the Shared Code section of this Gitbook and the IFL repo for existing direct UDP implementations.

DataStream SDK

Vicon's DataStream SDK provides a library of tools that simplifies the process of accessing the UDP stream and offers enhanced functionality (such as the ability to interrogate Tracker for information regarding the system's health and performance). Note that DataStream SDK requires an operating system (Windows 32/64-bit, Linux, or Mac), it is not for embedded applications. Once downloaded you will be able to develop applications in C, C++, .NET, Python, or MATLAB. Vicon provide examples for each of these options in the download.

You can install DataStream SDK on your own machine from the Vicon website, where you can also find the online documentation. DataStream SDK isn't currently installed on the IFL machines but reach out to Lee Whitcher if you would like to have that functionality.

ROS

As of April 2021 there is only one viable ROS package named "Vicon Bridge" developed by ETH Zurich, that is unfortunately only included in EOL distros (the latest being Jade). This package is in fact an interface to the DataStream SDK, so developing a version in-house shouldn't be too difficult for those with good knowledge of ROS.

Using IFL1 (MK103)

• Plug in the surge protector strip by the freight elevator (Vicon camera PoE switches)

• Plug in the orange extension cord by the control booth entrance (Vicon lock box and another switch)

• If you are performing a high-precision task, wait approximately 1 hour for cameras to reach thermal equilibrium

• Log in to the PC and open Vicon Tracker. If it throws a license issue or doesn't properly load, someone else is likely logged on with Tracker open, locking out the license. In this case you will need to restart the PC if you can't track down the previous user to get them to log off their profile.

• In Vicon Tracker go to "System">"Local Vicon System">"Show Advanced" and set the following:

  • Requested Frame Rate = whatever you need up to a maximum possible 330Hz, but keep this as low as you can for your project to make the Vicon network run as smoothly as possible

  • UDP Object Stream settings, if you wish for Tracker to broadcast data for single object tracking:

    • Tick "Enabled"

    • Data block size = 256

    • IP Address = "localhost" if using local code on the IFL PC, "192.168.10.2" if broadcasting externally

    • Port = 51001 (other options are possible but unlikely to be needed, see for more information

• Set up camera masks

  • Remove everything from the capture space, including yourself, the calibration wand, and your tracking objects (anything reflecting IR will be masked out by the cameras and thus will create dead spots)

  • In Vicon Tracker go to "Calibrate">"Create Camera Masks">"Start"

  • Watch the camera overview panes gradually mask any IR-reflecting pixels from green to blue. Stop once finished.

• Calibrate the space (do this every session once the cameras have reached thermal equilibrium)

  • In Vicon Tracker go to "Calibrate">"Calibrate Cameras">"Show Advanced" and set the following:

    • Wand: 5-Marker Wand and L-Frame

    • Calibration type: Full Calibration on All Cameras

    • Refinement frames: At least 2000, the more the better!

    • Tick "Auto-Stop"

    • Click "Start"

  • Do the "Vicon wand dance" being sure to maximize the simultaneous visibility of all cameras

  • Once the calibration is completed check the "Camera Calibration Feedback" and repeat calibration if necessary. It is totally feasible to have less than 1mm World Error from all cameras

• "Set Volume Origin" by placing the wand at the desired position and axis orientation and clicking "Start"

You are now ready to commence a tracking task!

At the end of your session be sure to:

• Shut down Vicon Tracker as you will block the license for the next user if not

• Unplug the orange extension cable

• Switch off the surge protector strip

• Report any issues to Lee Whitcher

• Remove all trash and all of your equipment

Vicon Tracker is the software system installed on IFL PCs to generate usable position and orientation data of objects being tracked. This is a required piece of software and in some cases is all that is needed by an IFL user (such as logging tracking information for use in post-processing, or any other non-real-time application).

Vicon Tracker 3.7 is currently installed on the IFL1 PC. Online documentation can be found but the PDF below is in many cases much easier to read. This documentation is the gold standard for learning how to use Vicon and all of its features so be sure to read it fully in addition to getting your IFL initiation.

Vicon Tracker 3.7 is not the latest version (which is 3.9) but is the one widely used by researchers currently, so we are keeping it this way until the need arises to upgrade. One such reason to upgrade is the introduction of an official Python API in Tracker 3.8 which will be attractive to many users. As such, we have installed Tracker 3.9 on the IFL2 PC for "beta" testing once that PC is fully online. Please contact Lee Whitcher if you would like to use this functionality as its implementation can be expedited if needed.

Purchases required

At the bare minimum you will need to purchase your own Vicon markers since these are not provided by the IFL. The best way to get markers is to use Workday to "Request Non-Catalog Items", selecting Vicon as the vendor and listing your required supplies from the . Where possible use pearl markers of at least 14mm diameter to get the best reflections for the Vicon system.

If you are planning to use ROS or any other software that requires computational hardware/IT infrastructure, you will also need to purchase that. The only IT provided by the IFL is a Windows 10 PC and a router configured as a wireless access point.

Setting up Tracker

to make sure the graphics card settings you need are set up properly on your user profile. Make sure you do this for the actual executable, not the shortcut.

TBD - this section will describe everything we go through in IFL initiation

Setting up your object

TBD

Pre-initiation

If you are using the IFL space only (no Vicon), you only need to familiarize yourself with the space by looking thoroughly over the IFL website (especially the "About the IFL" page).

If you are planning to use Vicon, you should complete the following training tasks (ordered by level of detail in each resource):

1. Thoroughly look over the IFL website (especially the "About the IFL" page).

2. Thoroughly look through this IFL Gitbook Wiki and Github repo. Note that the Wiki is intended to supplement the Vicon Tracker User Guide, not replace it, and to provide space-specific information.

3. Watch the official Vicon Tracker 3 tutorial videos. Note that, of the 14 videos on this playlist, only the following videos are absolutely necessary to watch: 1,2,7,10,11,12,13,14. But there is no downside to watching the entire playlist.

4. Thoroughly read the Vicon Tracker 3.7 user guide. You can access it online here (expand the "Vicon Tracker User Guide" drop down on the left hand side of the page) but it's clumsy to navigate so I recommend you download the PDF version here.

5. If you are planning on using any software on your own device (laptop/embedded/vehicle) to interface with Vicon, the in-person initiation is a good time to configure and test it (time-depending). Make sure anything you would like to test is installed and bring your equipment with you.

Note that the IFL doesn't provide Vicon markers so you may want to initiate the purchase now to minimize down time. See the Setting up Vicon Tracker and your object page for more details on this.

In-person initiation

If you are using the IFL space only (no Vicon) the initiation will be scheduled for 30 minutes and will cover the following topics:

• General overview of the space(s) and capabilities

• Review of Shared Space User Agreement and shared space philosophy

• Instructions on use of the external doors

• Safety discussion (emphasis on Li-Po procedure)

• Review of the research project including technical advice/support (time-permitting)

If you are also receiving an initiation on the use of Vicon, the above topics will be covered in addition to:

• Overview of Vicon hardware, network layout, and power instructions

• Overview of Vicon Tracker software

• Walk-through of the Quick Start Guide using the wand as a surrogate tracked object

• Review of the IFL Codebase capabilities

• Overview of IFL network architecture, including configuration of external device (time-permitting)

The goal of the IFL Codebase is to enable current and future researchers to minimize their research setup time by sharing any software functionality developed by past researchers. Over time the codebase will hopefully expand and improve.

The IFL repo can be found here. GT credentials are required for access. You are more than welcome to freely use and modify any of the code in the codebase, but we ask that you do so with these comments in mind:

• There is no guarantee that the code will immediately work for you, or that it will provide robust and reliable results in your application. As such, don't blindly trust the code and rigorously test it (especially before flying).

• Since the code is provided voluntarily as a courtesy, often times by fellow students/researchers who have little bandwidth at the best of times, please be respectful of the code authors' time and do not bombard them with questions. Make sure you explore all debugging avenues and have specific questions before reaching out.

• Please endeavor to appropriately credit/cite/reference/acknowledge any code authors whose code you used, along with the IFL.

• If you find any bugs, please report on Github and, where reasonable, propose a fix via a merge request

• Where reasonable/permissible please pay forward the benefit you received in using the IFL and IFL Codebase with any code (or general info/tips) that you developed that may have benefit to others in the future

Code author: Original author unknown but this version was developed by Lee Whitcher.

Direct repo link: https://github.gatech.edu/GT-AE-Indoor-Flight-Laboratory/Python-Vicon-Local-File-Write

Access the Vicon output stream on a local machine (or any other Windows machine on the IFL network) and save to a file.

This code, of unknown origin, uses a Python wrapper to use a C library written for what is believed to be the Vicon DataStream SDK. This is a really useful tool for running on the IFL PC to shorten the workflow of logging a tracking mission offboard and saving it directly to the format you want. Otherwise, you would have to log a mission in Tracker, load it, then export to CSV.

Download all files locally to the machine where you want to make a log file. You will need to edit ViconFileWrite.py to contain the name of the Vicon object you care about, spelled as it is in Vicon Tracker (case sensitive). You will also need to make sure the connection settings are correct for the Tracker settings.

As long as Tracker is Live and your object is being actively tracked, running ViconFileWrite.py from the command line will log the stream into the file, f. This code uses a unique time string as a filename that is a useful technique for keeping track of which file was logged when. To stop logging, ctrl-C out of the terminal.

The IFL's network is, in essence, one big IP network where all the Vicon cameras, the PC, router, and any devices a user connects to it (such as a laptop, aircraft) are hosts ("nodes") on that network. This network is a local area network (LAN) configured by the IFL team that is totally distinct from any of GT's networks such as eduroam.

Networking 101

Data Transmission Protocols

Data is/can be sent around the network using any one of multiple "Internet Protocol (IP protocol)" options in the form of "packets" of a certain size. The most common IP protocol in general use is TCP (transmission control protocol) which is, amongst many other things, used widely for internet applications such as browsing, streaming, etc. TCP focuses on accuracy of data transmission and guarantees its delivery in the order it was sent... packets are not just sent and forgotten; the receiving host verifies that the content was sent correctly and requests re-transmission of any that were corrupted during transmission. All this happens behind the scenes. Because of its focus on guaranteed accurate delivery of packets, TCP is not the fastest way to send data over a network and latency can be added. Enter UDP (user datagram protocol)... UDP is similar to TCP but doesn't have these accuracy-guaranteeing functions. Instead, data is sent out and immediately forgotten about; it's on the user of the data to ensure it is accurate enough to use. In practice, provided you have an orthodox setup with good quality of connection and hardware, you will lose little to no packets using UDP. The major upside of using UDP is its speed; in a real-time decision making application (i.e. flight control) any late or disordered packets once fixed are too late to do anything with anyway so we prioritize speed (low latency) and focus on transmission quality a priori. This is why Vicon Tracker is set up to use UDP and any time-critical communications you wish to perform over the network using your own code should use UDP, not TCP. A more thorough breakdown of the differences between TCP and IP can be found here.

Addressing

Much like your physical home address that sets it apart from everyone else in the street/city/county/country, any IP network and its hosts need an address; an "IP address". There are multiple ways to define an IP address but the IFL uses a "Class C IPv4" system as shown below (original credit) and described in more detail here:

Note that this address system defines the local "private" IP address only. Since the IFL PC is connected to the internet it also has a "public" IP address for the outside world (eduroam).

IP addresses can be automatically assigned, for example by your home router, or configured to be static, which is what the IFL does (so that our code can thus also be static). The network ID and subnet mask were chosen, fairly arbitrarily, by Vicon and GTAE-IT when the IFL network was installed, and are configured as follows:

• Network ID: 192.168.10.xx

• Subnet mask: 255.255.255.0

The host ID is to be selected by the user with any number up to 255 allowed (since the host ID is 8 bits), with exceptions as follows (full IP address shown):

• 192.168.10.1 - IFL1 PC Vicon Ethernet Card Physical Port 1 (for connection to the cameras)

• 192.168.10.2 - IFL1 PC Vicon Ethernet Card Physical Port 2 (for connection to the WiFi router)

• 192.168.10.3 - TP Link WiFi Router (configured as a Wireless Access Point)

It is advisable to select your host ID as something somewhat unique/personal to avoid the (admittedly unlikely) event that someone else has picked the same number and happens to be within range of the WiFi router when you are also connected. For example, if everyone picked the next available host ID, #4 (192.168.10.4) and one of Professor Rogers students was benching above the IFL in MK207, there would quite likely be an IP address conflict on the network resulting in a conflict and potentially severe consequences.

Ports

Since many different applications/services can be sharing data over an IP connection it is not enough to define the IP address, a unique ID is required to define that specific service (for us, the Vicon service). This ID is called the port number and can take any value between 0 and 65535. You often define the port via concatenation on the end of the IP address, for example 192.168.10.2:51001.

Many port numbers are actually globally standardized to avoid different applications having to be configured on every network, so these should not be selected for use in your application. A list of these reserved ports can be found here but as a rule of thumb you can safely select anything above 49152 since these ports cannot be reserved (see: ephemeral ports).

When Vicon Tracker is on and tracking, it will always be outputting data on port 801 regardless of what settings you pick. However, you can also configure a UDP stream for yourself by going to System > Local Vicon System > Show Advanced and scrolling down to the "UDP Object Stream" section shown in the image below. Here you will choose the desired settings as follows:

• Enabled: YES

• Data Block Size: 256 in most cases (larger blocks bog down the network unnecessarily but may be required when tracking many objects)

• Object Per Port:

  • If you are tracking a single object, NO.

  • If you are tracking multiple objects AND want to have a dedicated port for each object, YES. In this case each object will be on a port numbered sequentially beginning at the number specified below.

• IP Address:

  • If you are accessing the UDP stream on the IFL PC you will select localhost. This is a special IP address used to denote "this machine", thus eliminating the need to transmit over hardware.

  • If you are accessing the UDP stream on a remote device you will select 192.168.10.2. This is the address for the physical RJ45 port on the Vicon network card on the back of the IFL PC, through which the Tracker UDP stream will be transmitted to other hosts on the network.

Making a Wired Connection

The fastest and most reliable connection to the IFL network is via a wired connection. This is useful for many things including if you want to connect your own laptop/PC running custom code such as a ground control station, setting up a Linux machine for running ROS, using a static piece of equipment such as an antenna tracker, or if you have a ground robot that doesn't need a wireless connection.

To implement a wired connection you have three options:

1. Directly connect your device to the second ethernet port on the back of the IFL PC using an ethernet cable (one is already present, usually plugged into the TP Link router but this can be unplugged for your own use).

2. Connect the second ethernet port on the back of the IFL PC using an ethernet cable to the blue INTERNET port on the back of the TP Link router and then connect any of the yellow ethernet ports to your device using another ethernet cable. This approach is useful if you want to have both wired and wireless connections.

3. Bring your own network switch and connect it to the second ethernet port on the back of the IFL PC using an ethernet cable, then connect your device(s) to that switch using additional ethernet cables. This approach is useful if you have multiple wired devices and want to use a switch of higher quality than the TP Link wired ports.

In any of the above cases you will need to then configure your device with a static IP. This is operating system dependent (or in the case of embedded applications, language/library dependent), but the Windows 10 instructions are as follows:

1. Make the physical ethernet cable connection

2. Go to Control Panel > Network and Internet > Network Connections (or type View Network Connections in the Windows search bar)

3. Right click on the ethernet connection and hit Properties

4. Select the "Internet Protocol version 4" in the scroll window and hit Properties

5. Select "Use the following address" and enter your IP address as 192.168.10.xxx, where xxx is your desired host ID subject to the addressing constraints outlined above. Enter 255.255.255.0 as the subnet mask.

6. Default gateway and DNS server settings can be left alone since they are not used in our network

7. Hit OK and your connection should be ready to go. You can check you are successfully connected by opening a command prompt (type cmd in the Windows search bar) and typing 'ping 192.168.10.2'. If you have a successful connection you will see reply readouts from the Vicon ethernet card with performance statistics.

Making a Wireless Connection

Many applications, most notably aerial robots requiring real time access to the Vicon data stream, will require a wireless connection to the IFL network. To facilitate this, the IFL provides a standard TP Link WiFi "router". This "router" is actually not a router since it is configured in its firmware as a Wireless Access Point (WAP). In short, this means it doesn't perform any internet connectivity, firewalling, or IP address assignment, it merely serves as a portal for wireless connections to the network.

To configure your wireless connection follow these steps:

1. Connect the second ethernet port on the back of the IFL PC using an ethernet cable to the blue INTERNET port on the back of the TP Link router, if it isn't already connected.

2. On your remote device set up a WiFi connection with the TP Link router using the default SSID and password printed on its label.

3. Set up your remote device using a static IP address as described in the previous section

Code author: of Professor Panagiotis Tsiotras's .

Direct repo link:

Python code for accessing and parsing the UDP stream output by Vicon Tracker.

Vicon Tracker outputs a generic UDP stream that can be accessed without using the Vicon DataStream SDK. In embedded applications or where use of this SDK is not possible or undesired, it is possible to simply parse this UDP stream and extract the relevant Vicon data. DataBlock.h, in the Vicon Tracker installation folder (specifically C:\Program Files\Vicon\Tracker3.7\Simulink\UDP in the IFL PCs) describes the format of these UDP messages.

This repo contains 2 simple scripts for accessing and parsing these UDP messages:

1. SimpleSingleObjectUDP.py accesses the UDP stream, parses it to extract an object's 6 position and orientation values, then prints to the terminal.

2. MultithreadAsynchronousUDP.py extends functionality by implementing multi-threading and the ability to handle asynchronous UDP and program execution rates.

Code authors: (an undergrad researcher from ECE) and .

Overview

Many applications require the use of Vicon position and orientation information in real time onboard the remote vehicle, such as trajectory control and synchronized logging. With the need to be onboard a flying vehicle, the requirement to be lightweight and low profile in doing this is critical. Furthermore, many aircraft do not provide a feasible/convenient means of injecting Vicon position information into their flight control system, which is particularly the case for proprietary aircraft like those made by DJI. This project was created to address both of these tasks, and achieves these goals using two repos as follows:

1. Photon Vicon Raw Data - A WiFi-enabled microcontroller is used to connect to the IFL network, access the Vicon UDP stream, and directly parse it into {x,y,z} position and {roll,pitch,yaw} orientation values. Since the Photon weighs only 5g, operates on 3.6-5.5V @ 100mA, and has an external antenna interface for enabling the best WiFi coverage, it is perfect for this application.

   • Direct repo link

2. Photon Vicon GPS Spoofer - this repo is an extension of the former whereby the raw data stream (a flat earth reference frame) is mapped onto a latitude/longitude/altitude (geodetic) reference frame centered on the IFL's real life position on Earth. It is then encoded in either NMEA or UBX format (user-selectable) and sent out over a serial port configured as per almost all off-the-shelf GPS (strictly-speaking, "GNSS") receivers. This has the effect of creating a device that tricks an existing flight control systems into thinking it is communicating with a standard GPS receiver. This is an extremely powerful tool; it enables indoor flight where a solid GPS signal cannot be obtained, it eliminates the need to modify source code which can be extremely inconvenient or indeed impossible in the case of proprietary systems, and it facilitates quick configuration changes in a vehicle that sometimes flies outdoors and sometimes flies in the IFL. One simply needs to unplug the GPS receiver and plug in the Photon in its place. The repo also includes the ability to vary position update rate, accuracy, and variance, for testing aircraft control robustness in outdoor flight conditions.

   • Direct repo link

Photon Vicon Raw Data

The VICON cameras transmit (x, y, z) location information as well as rotation information about each of those axis. If you would like this information instead of the GPS formatted information, you can use the code at IFL Codebase Github repo.

The information is sent out over the Serial (USB) and Serial1 port on the photon (which can be found ) at 9600 and 115200 baud respectively. The baud rate is only adjustable by changing the source code.

The data is printed in the following format.

x, y, and z are all in meters. The rotation angles are in radians. The last number gives the number of UDP packets processed per second. If the loop rate of the code is set to 100 Hz then the updPerSec field should be ~100.

The loop rate is adjustable in the source code with the variable dt

Photon Vicon GPS Spoofer

The GPS Emulator is designed to provide you with real-time data in a GPS friendly format. The photon has been programmed to have the following functions:

• Send UBX formatted messages

• Send NMEA formatted messages

• Change configuration parameters in real time over a USB serial connection

• Add normally distributed noise, with adjustable variance, to the VICON data

The photon does not respond to messages. If you plug the photon into a flight controller running Ardupilot, it will recognize the photon as a GPS properly.

UBX Messages

NAV-PVT Messages

The NAV-PVT messages provide position and velocity information.

Time

The time provided in this message is not guaranteed to be accurate. The time provided in the PVT messages is guaranteed to not be accurate to precision beyond the second. The photon does not provide absolute time queries that are more precise than a second. The time messages do report out to the microsecond, and relative to the other messages this will be accurate, but the absolute time is not accurate down to the microsecond. Taking difference measurements down to the microsecond is ok with these messages, but not syncing with external objects. Also, without connecting the photon to the cloud, which cannot happen while receiving VICON data, the day, month, and year are not accurate. The photon normally gets its time stamp from the cloud, but on the local network in the IFL it cannot connect to the cloud.

Flags and Fix Type

The photon will always report a 3D-fix.

The fix status flags will always be gnssFixOk.

The number of satellites is a configurable property. The default number of satellites is 6.

Position Measurements

The height above the ellipsoid was measured on campus at Georgia Tech with a GPS then that number was used as the 0 height in the IFL. Thus all measurements in the z direction are added to that to get the UAV's height above the ellipsoid. The same procedure was used to get the height above mean sea level.

The horizonal and vertical accuracy estimates are reported to be 2x the the square root of the add noise variance. Thus if you change the noise variance, the vertical and horizontal accuracies should adjust.

Calculated Values

The velocities in the North, East, and Down directions are calculated as a simple numerical derivative: the difference in position measurements divided by the change in time. A positive down velocity means the vehicle is going down.

The ground speed is calculated by taking the vehicle's total change in distance in the x-y plane and dividing that by the change in time.

The heading of motion gives the angle at which the UAV is traveling by using

Dilution Of Precision (DOP)

The position DOP (pDOP) is a configurable value. The default is 1.0. Changing the pDOP has no effect on any other calculations.

NAV-DOP

The NAV-DOP message contains the following DOP information:

• Geometric

• Position

• Time

• Vertical

• Horizontal

• Northing

• Easting

The pDOP, vDOP, gDOP, nDOP, and eDOP can all be adjusted through the serial interface. They can only ever be set to the same value unless the code is manually modified. Changing the DOP values has no effect on the rest of the code.

NMEA Messages

While using the NMEA messages, the following messages are sent:

• GNGGA

• GNRMC

These messages were picked because of the information they send and that they constitute enough information for Ardupilot to recognize the GPS.

GNGGA

Time

Once again, due to the same limitations as above, the time presented here is not guaranteed to be accurate.

Position

The position is calculated the same for the NAV-PVT and the GNGGA message. Please see above.

Flags and Other Information

The number of satellites is a configurable number. The default is 6.

The age of differential corrections and the station providing those corrections are not used and thus left blank.

GNRMC

Time

See above. Time is not guaranteed to be accurate.

Position

The same position is reported in the GNRMC message as is the GNGGA message.

Calculated Values

The ground speed uses the same ground speed calculation as the UBX messages.

The course over ground uses the same calculations as does the heading of motion for the UBX messages.

Magnetic Values

The magnetic values (variation and E/W indicator) are not used and thus left blank.

Additional Noise

The VICON cameras provide very accurate measurements. If you would prefer for your GPS measurements to be more noisy, then you can add "fake" noise to your data by using the MCv command shown below. The default variance is 0. This noise will be added to every time step and is approximately normal.

Changing Parameters

You can write a message over USB serial to change the device properties. All messages start with "MC" meaning "Make Change" then a lower case letter to signify what to change followed by the number.

• MCv1.23456 Will Make a Change to the Variance of the artificial noise added to the data. The new variance will be 1.23456.

• MCd1.23456 Will Make a Change to the dt of the loop. In this example, the new dt would be 1.23456 seconds.

• MCp440 Will Make a Change to the dilution of Precision. Changes the pDOP, hDOP, vDOP, gDOP, nDOP, and eDOP to all be the same thing. Changing the dilution of precision has no effect on the any other calculations in the code. Should be expressed as 1e2. In this example, the new DOP would be 4.40.

• MCs12 Will Make a Change to the number of Satellites.

• MCu Will toggle the message type being sent. If NMEA is currently being sent then UBX will instead be sent. Make sure your flight controller is ready to accept that message type. When working with Arudpilot, the GPS type may need to be manually set.

The vertical and horizontal accuracy will always be reported as 2x the standard deviation of the noise variance described above.

Important Note: The photon stores this information in volatile memory, thus when the photon loses power you will need to re-configure parameters. The easiest way to configure parameters is to power the photon through the autopilot (by plugging in the battery normally) then connect the USB to your computer and type in the serial commands. This way the photon will never lose power.

Configuring The Photon

We need to "claim" the photon before we can use it at all. Although in the future we will not need to have the photon connected to the internet, for the claiming step, we need internet connection.

1. Plug your photon into your computer over USB. (right now we only need power, so if you have a different way of supplying power, you can use that. USB is suggested).

2. 1. Select any network that allows you to reach the internet. Getting onto eduroam is not suggested, as the credentials to login are not trivial to overcome. For this, I would suggest using a hotspot or home network.

   2. We only need this connection to claim the photon, we will configure the WiFi credentials for the lab later

Setting Up a Local Development Environment

We need to be able to flash the correct code and re-configure the WiFi credentials, so here we will set up your local machine for this. You need the Command Line Interface (CLI) for future commands. If you prefer to use a graphical interface then you can download the Particle Workbench.

Download the Command Line Interface (CLI)

1. 1. This is required to be able to run the command line commands below.

Download the Particle Workbench

1. To use the Particle Workbench you will need Visual Studio Code (which can be downloaded on Linux, Mac, and Windows). Please download Visual Studio Code

2. Now go to the extensions search (normally located on the left of the screen) and search for Particle Workbench Core or Photon. Install the Workbench core extension.

3. Now we can compile and flash code locally!

Connect the Photon to the IFL Network

The commands here have only been tested on an Ubuntu machine.

1. Make sure the photon is plugged in over USB to your computer.

2. Go to your terminal and type particle usb list You should see your device listed. If it is not listed make sure your USB connection is secure and the installation of the CLI is correct. Also check that the light on the photon is flashing any color (to show it has power).

3. Now we need to put the photon into listening mode. Type particle usb listen and you should see the LED on the photon change to flashing blue.

4. Let’s configure the WiFi settings now. Type particle serial wifi into the CLI and you should be prompted with a list of networks, select the SSID shown on the IFL router and use the associated password.

5. The light should blink a fast green then eventually a slow green to show that it is connected to the network, but not the WiFi.

6. Now the photon is connected to the IFL network.

Flash the Code to the Photon

Before we can gather data we need to flash the correct code onto the photon. The photon will run the most recent code that has been flashed on boot.

Using the Particle Workbench

1. Get the code locally on your computer and put it into a photon project in the workbench.

2. To check if it compiles, start by pressing the “check” button in the top right of the screen (the button is only located there while you have the .ino or .cpp file selected).

3. Now to flash the application, press the “lighting bolt” button in the top right. It should put the device into DFU (device firmware update) mode before it flashes. If that fails then in the CLI you can type particle usb dfu which should put the device into DFU mode manually. Then you can re-try the flash button.

Using the CLI

1. Navigate to the folder that holds the src folder then run the following commands

2. particle compile p --saveTo test.bin

3. particle usb dfuThis line is needed to but the photon into DFU mode so it can be flashed

4. particle flash --usb test.bin

Configuring UDP

• IP address (IPAddress myAddress) = 192.168.10.xxx where xxx is the user-selected Host ID that needs to conform to the constraints laid out in the networking instructions

• Subnet mask (IPAddress netmask) = 255.255.255.0

• Default gateway (IPAddress gateway) = 0.0.0.0

• Router IP (IPAddress router) = 192.168.10.3

• UDP port (Udp.begin.port()) = Whatever is configured in the Vicon Tracker UDP Object Stream setting (or 801 if the DataStream default is sufficient)

• UDP Packet Size (int packet_size) = Whatever is configured in the Vicon Tracker UDP Object Stream setting

Troubleshooting

This section holds miscellaneous tips for troubleshooting.

• If the autopilot software claims to be waiting on a GPS config message, you can change the autopilot to skip GPS configuration by changing GPS_AUTO_CONFIG to 0.

• If the photon is having a hard time connecting to the network, you can try runningparticle device doctor which should update the device. After running this command you may need to repeat the network connection steps and re-flash the code.

Recommended parts suppliers

There are many great places to acquire off-the-shelf components for building UAVs, but these are Lee's recommended ones. Please feel free to contact me with other options not covered here and I'll ad to the list for future users.

Retailers for all components

Online

For purchasing pretty much all components needed to build UAVs, the following are great online retailers:

• HobbyKing

• GetFPV

• RaceDayQuads

The following options are ones I recommend on the huge caveat that you proceed with caution as quality, assured supply, and consistency cannot be guaranteed. Alas, they do occasionally throw up some great options if you're willing to spend the time/money risking it:

• Amazon

• eBay

• AliExpress

• Banggood

Local

There are also brick-and-mortar options in the Atlanta area that have a good stock of components that you can go to in-person without waiting for shipping:

• Grayson Hobby

• Hobbytown (Kennesaw branch in particular)

• Atlanta Hobby

Propulsion System Combos (Motor+ESC+Propeller)

For high-quality, reliable, and super-efficient propulsion systems I highly recommend using propulsion system combos from either T-Motor or KDE Direct. These two manufacturers are of particularly high standard and produce a wide range of sizes. KDE Direct should be the go-to choice for projects requiring 100% USA manufacturers since T-Motor are Chinese.

The primary reason for recommending these two manufacturers is that they publish *actual* data for their recommended combinations, taking much of the guesswork out of sizing an aircraft. To find recommended combos, go to the product page for one of the motors and click on Specifications (T-Motor) or Performance Data/Compatible Configurations (KDE Direct). Furthermore, T-Motor offers some "Combo Packs" and KDE Direct has a "Build Your System" tool.

Individual motors, ESCs, and propellers, from T-Motor and KDE Direct are also a good way to go, in case you wanted to mix and match with other options.

Motors

For high-end options, pick T-Motor or KDE Direct. For less expensive options check what's in stock at any of the online or local retailers listed above, being sure to check for good reviews.

ESCs

There are a couple of particularly high-end options for ESCs: Castle Creations, and Advanced Power Drives. Both of these manufacturers offer highly-engineered ESCs that also include telemetry (RPM, voltage, current, temperature, and more) for you to interface with flight control, ground test rigs, or just for logging. For other high-end options, pick T-Motor or KDE Direct. For less expensive options check what's in stock at any of the online or local retailers listed above, being sure to check for good reviews.

Propellers

For high-end options, pick T-Motor or KDE Direct. For less expensive options check what's in stock at any of the online or local retailers listed above, being sure to check for good reviews.

In my view the gold standard of affordable propellers (as opposed to the high-end props of T-Motor/KDE Direct which are awesome but expensive) is APC Propellers. Not only do APC stock a huge range of inexpensive props that are customized for different applications (gasser, multi-rotor, etc.), but they publish data on the performance of all their props in their Performance Data section in the form of .dat files. These .dat files, believed to be analytically determined as opposed to directly measured, give you thrust and torque/power data as function of both rotor RPM and advance ratio (forward speed for fixed wing flight). This enables you to size props for multi-rotor drones particularly easily.

Batteries

There are two candidate battery chemistries for use in VTOL flight: lithium-polymer (Li-po) and lithium-ion (Li-on). Both are feasible, however Li-po batteries are typically selected based on them being readily available off-the-shelf for UAV usage. Li-on packs should be considered, however, since they offer a considerable amount to the more advanced user. The four main discussion points for deciding between the two are as follows:

• Energy density (mass per unit of stored energy): Li-on has up to around 20% higher energy density than Li-po, which directly relates to flight time i.e. 20% longer flight for no weight increase.

• Power density (mass per unit of discharged energy): Li-po has significantly higher power density, meaning it can tolerate higher rates of discharge than a Li-on of equivalent mass. This difference is significant enough that many VTOL aircraft cannot even get off the ground using Li-on. However, Li-ions are seeing increasing use in super-lightweight applications such as this one, and this one.

• Off-the-shelf availability: Since Li-on cells are prolifically used, they are widely available in standard cell shapes such as 18650 (18mm diameter, 65mm tall) and 21700 (21mm diameter, 70mm tall), however they are not commonly found as packs of cells ready for use in UAVs. Conversely, Li-po battery packs are widely found ready to be used in UAVs but are rarely found as single cells.

• Ability to optimize integration through shape and size: Following on from the previous note, the ability to source single Li-on cells in many different sizes gives us the opportunity to architect battery packs in shape and capacity with significant fidelity compared to Li-po. However, in order to do this it is necessary to spend a non-trivial amount of NRE (non-recurring engineering) time designing the packs and setting up the ability to configure them electrically. Furthermore, it is necessary to purchase a spot welder. All of this is feasible, but not for the scope of this project given Li-Pos are readily available off-the-shelf.

Lithium Polymer

Arguably the best Li-po supplier is GensAce/Tattu, with batteries ranging from the smallest you can buy up to the biggest. In fact, they are the only supplier of high-capacity, high-voltage, "smart" batteries, without needing to gang smaller cells. For example, this 12S 22000mAh 25C battery that has CAN bus and onboard memory for storing performance data.

You can also find Li-pos at any of the online or local retailers listed above, but be sure to check for good reviews.

Lithium Ion

Flight-ready Li-on pack are not currently sold, to my knowledge. Instead, you will need to find individual cell suppliers. My favorite is IMR Batteries. Since battery technology is constantly evolving, you should always check the stocked cells for those with the best performance at the time of buying. It's typically a good trick to sort all cells by price and start at the most expensive, checking the rated capacity and discharge rating for all cells. Reputable manufacturers such as Samsung and Sony should be prioritized since, despite being more expensive, they typically publish accurate specs. You will also need to decide which cell geometry to buy, with 18650 and 21700 being the most popular currently. If I were building a Li-ion pack today (6/29/21) I would almost certainly use this Sony VTC6A cell with a whopping 40A discharge rating and a 4100mAh capacity.

If you decide to also integrate a battery management system (BMS) to provide health monitoring, balance charging, current limiting, etc. (highly recommended), there are two recommendations worth considering: this one and this one. I haven't personally used these, but I trust the recommendation.

For a good high level guide on how to build Li-on packs, see this YouTube video.

Airframes (out-sourced)

TBD in detail but check out the online and local retailers listed above. Tarot in particular makes some good frames.

If you wish to have custom carbon fiber frames made, Plastic Spider has provided multiple projects in GT-AE with great quality parts in quick turnarounds. You will just need to produce DXF files of your design and send to them for quote.

Flight Control

TBD in detail but I thoroughly recommend Pixhawk Cube-based systems. Check out IR Lock (Georgia supplier) and Spektreworks.

Wiring and connectors

TBD in detail but for wiring you should always use highly flexible silicon cable of sufficient thickness (low AWG number) to carry the current of your application without introducing too much resistance into the circuit. Amazon stocks good quality wire selection kits of various diameters, such as this one, but you should try and order good quality wire from your motor/ESC supplier.

You will likely need various connectors over time, such as XT60, XT90, EC5, AC150, Deans, generic bullets, Anderson PowerPole, since different motor/ESC/battery suppliers use so many different types. In all cases you should always strive to buy genuine connectors (not cheap copies) from the motor/ESC/battery supplier or the original manufacturer although I have bought lots of good quality connectors from the above online and local retailers.

Miscellaneous materials, hardware, and fasteners

TBD in detail but you will need at some points to buy miscellaneous materials, hardware, and fasteners. Good local resources for this are Home Depot, Lowes, McMaster-Carr (online order but local pickup within an hour is possible), and Metro Bolt & Supply Co. This is in addition to the above-mentioned online and local retailers.

Building airframes in-house

TBD in detail but it is also very much possible to make airframes in-house. Depending on the scale of your build you will use some combination of the following parts/techniques:

• Tubes (carbon fiber or aluminum)

  • Cut to length using a miter saw with appropriate blade or on the Do-All in the GT-AE machine shop (or mill if you need particularly well-machined ends)

  • Circular or square/rectangular profiles can be used

• Plate (carbon fiber, aluminum, polycarbonate, acrylic, garolite, plywood)

  • Hand-cut if it's simple geometry - just print your design 1:1 on paper and glue it to your plate then cut with whatever tool makes sense (bandsaw, drill press, hole saw, Dremel, etc.).

  • Laser cut in the GT-AE Yang Aero MakerSpace if it's a laser-able material (acrylic, plywood, some other plastics)

  • Waterjet cut in the GT-AE Machine Shop

  • Outsource to Plastic Spider

• 3D-printed brackets, arm clamps, etc.

  • Design your part and then print from the most appropriate material one of GT-AE Yang Aero MakerSpace's many 3D printers

• Aluminum tube clamps

  • Servo City has a large range of tube clamps, including side-tapped clamping mounts which can be used to connect round tubes to flat plate and thus make significantly large airframes really easily

Some good resources for purchasing raw materials to perform in-house builds, in addition to the risky online retailers listed above, are:

• Carbon fiber plate and tube

  • Rockwest Composites

  • Clearwater Composites

  • DragonPlate

  • McMaster-Carr

• Aluminum plate and tube

  • McMaster-Carr

  • Metal Supermarkets (they have a local store on the north-side)

  • Lowes and Home Depot (in particular architectural aluminum square tube which is extremely capable and cost-effective for drone arms)