Flyport airborne data communications
The QuadForge Project is part of EGR 292, an engineering research and development class at Montgomery County Community College (http://mc3.edu). For the Spring 2013 semester there are seven students enrolled in the class.
The project aims to deliver a modular flight platform with numerous real-world applications. With Wifi and 3G connectivity, a first person view camera, water repellant nano technology, embedded electronics, and other possibilities, products delivered by the Quad Forge Project hope to serve many different uses.
Development covers a wide range of engineering disciplines from mechanical and electrical to software design. Additionally, the project is organized around delivering an actual product, meaning proper documentation must be produced and real-world reliability is a concern.
The open source nature of the project means that much of what we develop can be found on this website. For links to websites with related information and products, please look in the related links section below. For additional information, please send a request by email to email@example.com.
Environmental Surveying and Data Collection
In many parts of the world, the weather varies drastically from freezing winters to hot summers. During the seasons, mountainous regions endure treacherous snow storms, avalanches, and water-related landslides that cause substantial destruction.
Since there is no way of preventing these natural disasters, the best possibility of lessening the devastation these events cause would be to develop a way of forecasting when and where they may occur.
Most of the storms originate in these mountainous regions, making this a difficult mission to achieve. To accomplish this task, there will be, one day, a new generation of WiFi-based environmental stations located throughout these at risk regions that are outside the range of 2G, 3G, or 4G mobile data networks.
This project is a proof of concept for future WiFi-enabled environmental weather stations placed in remote mountainous regions susceptible to harsh weather. They will have the ability to communicate via FTP to send data files to a nearby flying Flyport. Each VTOL UAV quadrotor contains autonomous flight plans (GPS waypoints). When calm weather conditions are present, a quadrotor with an onboard Flyport flies to weather stations and captures their acquired data. The data saved in the Flyport is uploaded autonomously via FTP to a WiFi-enabled server when the Flyport returns to and detects the base station.
This document gives in-depth information on how to program a new Flyport out of the box for this type of communications and user interface capability. All source code is provided.
Flyport customized Webserver
To get started, you need a Windows PC or tablet with a USB port and Microsoft .NET Framework 4 is required to develop applications with the openPicus IDE.
Follow step by step the Getting_Started guide to install openPicus IDE and compiler
It's highly recommended to visit the [Reference_manuals] section and read the following documents:
- IDE 2.2 user manual
- Flyport Wi-Fi programmer’s guide
You are now ready to connect the miniUSB programmer to your PC or tablet, a serial bootloader is already on the module. Run the IDE and create a new project or open one.
Open the project
Double-click on “OpenPicus Flyport IDE 2.2” from the Windows start menu. Choose “OpenProject” above the Project Explorer window in the upper left hand corner of the screen.
The “Select project file” dialog box opens. Choose the “.conf” file. It is the one that contains project information.
The code for this project is found under the name “Scan example.conf” as shown below. (NOTE: We based our code on the original Scan example code provided by openPicus.)
The IDE will open with all relevant tabs in the main window pane. The project explorer is on the left-hand side of the IDE. The output dialog box is on the bottom. The output dialog box is where you will receive messages from the compiler.
TaskFlyport.c is the file where the main task taskFlyport.c() is located. The code that pertains to the user, starts in taskFlyport(). We do not recommend changing any other portions of the code as it could cause the Flyport to stop working.
Definition of terms
The “home base station” is where the main FTP server is located. It is where the quads return from a survey mission or a data collection mission.
The “field network station” is a remote WiFi-based weather/environmental station deployed in the field.
Choose the taskFlyport.c tab to show the taskFlyport() function. MAIN LOOP START. is a continuous loop that runs until the Flyport is turned off. Within this loop there are five separate processes (lines 143 to 217). Only one process will run each time through the loop. Which process will run is based on the many true or false variables in each if statement beginning each process. It is set up so that only one process will run each time the loop cycles. The exception to that is the delay process
- The delay process – This is a timer function that gets called every time the while(1) loop repeats. It is used primarily to delay the scan process.
- The scan process – This process calls the WFScan() function. Its recent scan results can be accessed with the WFScanList() function. It also sets ScanCompleted to TRUE when it is finished scanning.
- The data manipulation process – This process calls the DataManip() function.
- DataManip – SURVEY Mission - This mission is used only to find available field network stations. It collects scan data, essentially WiFi infrastructure information, and places this data in the array of NetNumber_tWFNetwork structures.
- DataManip – COLLECTION Mission - This mission is used to collect data from field network stations, and bring the data back to the home base station. The collection network is found by comparing the current scan results to a list. This list contains the field network stations added from the Web server page (see Collection Setup). When the current scan result reveals a network on the list, it collects the field network station’s data. DataManip() calls the readOrWriteToFTP() to do the collection.
- The dump memory process – This process calls to readOrWriteToFTP() function. It is used in a SURVEY mission to send the scans stored in memory to the home base station. When this function is called, each field network station it found and stored in memory gets uploaded one at a time to the specified home base station file. The home base station is automatically detected and the FTP upload starts autonomously.
- The write collected data process – This process calls to readOrWriteToFTP(). It is used in a COLLECTION mission to send data to the home base station when the quadrotor returns. Here again, the home base station is automatically detected. If no data was collected from the field network stations, it will write an error message to the file at the home base station
Compiling the project
In compiling the project, the Flyport IDE's compiler takes the .c source code files and converts them to object files (.o). It then links all of these together, and creates a .hex file.
The user should know that a .hex file is actually an ascii character file. It uses the characters “0” to “9” and “A” to “F” to represent machine code in a hexadecimal ascii character format. The hex file will then be used to make a machine object file that will be run on the Flyport itself.
There are many object files already compiled in the OpenPicus directory. This is where the OpenPicus was originally installed. Usually it is in your program files, for us it was the following directory:
C:\Program Files (x86)\OpenPicus Flyport IDE 2.2
These files are already compiled, and don't have to be recompiled again each time. The user only needs to deal with the code in his project directory. We started our project in the following directory:
Choose Compile Project on the Home tab ribbon as shown below. Then choose Compile. Occasionally, the user will notice errors from the Program Files directory. This is an indication that you need to choose Recompile All, instead of just Compile Project.
Look in the output window, you will see it listing the files as it compiles. If there are errors, as in this case, you will see them listed too.
You will also see below the error dialog box. Click OK and fix your errors.
When you have successfully compiled, it will list the amount of memory used. You may have to scroll the output window to see all of the output. The top number is flash memory used, the bottom number is RAM. You have 256K of flash, and 16K of RAM. If the bottom number is greater than 100 it will give you an error, and you will have to change your memory allocation. In the file MissionParameters.h line 43, you can change your MAXNETWORKS to a smaller or larger number if necessary.
You are now ready to download your project to the Flyport module.
Download the firmware
First download source code of this project.
You can download it here
Then open it by the openPicus IDE (the IDE takes the .hex file, parses it, and turns it into machine code that the Flyport can understand). It then downloads it to the Flyports flash memory (256K). It takes a few minutes for this to happen. Then the Flyport automatically executes the program.
Plug the Flyport into the development board, and connect the board to an open USB port on your computer or tablet. Choose the Download Firmware button on the top ribbon of the IDE as shown below.
This opens the Bootloader GUI screen:
Click refresh ports, and then choose an available COM port. Each board is assigned a different COM port, and this may involve downloading the correct Flyport driver. Click the Download button.
The user will see the progress bar move to all green as it is downloading as shown below.
When it is finished, it will say “Download completed successfully!”
You are now ready to open the Serial Monitor
Choose the view tab in the upper left corner of the IDE. This allows the user to select the Serial Monitor button
The serial monitor will open as shown below. If it closes automatically, place your mouse cursor over the Serial Monitor Tab on the screen's right side.
Notice at the top the three dialog boxes and the reset button. Below that are the Refresh, Connect and Clear buttons, as well as the Echo ON check box.
On the bottom of the screen, there is a box for entering input. Below that tells whether or not the Monitor is connected to the Flyport.
Click the Refresh button to refresh the COM ports available. Choose the one for your Flyport, and then choose 19200 and Append in the other dialog boxes. You can then choose Connect. Don't be worried about an Overrun message. This simply means that the Flyport was producing output before it was connected. Click the Reset button and you should see the initialize message from your Flyport. The Flyport will then begin executing code that was coded in taskFlyport() function. You are now ready to prepare the mission project.
A web page is used as the user interface for programming the onboard mission computer. All interaction with the mission computer is done through this web page. The page allows the user to set up a home network for the mission computer to connect to. It will also let a user set any field network stations where data will be collected from. Finally this Flyport internal website allows the user to control when to start the mission
The mission computer is programmed to set up an AdHoc network as its default behavior. For this reason the first time the mission computer is turned on the user must connect to the mission computer’s AdHoc network to interact with it. The default AdHoc network SSID name is “FlyportNet” with security set to open. The user can connect to this network just like any other WiFi network.
Once connected to “FlyportNet” the user can interact with the Flyport mission computer by using a web browser. The web page can be reached via browser at http://picus or by IP http://192.168.1.115.
After using the webpage to setup the home network station and after the mission computer successfully connects to the home network station, it will continue to use that network as its default and consequently the initial set up of connecting to the “FlyportNet” AdHoc network will not be needed. However if the mission computer fails for any reason to connect to the home network station it will default back to the “FlyportNet” AdHoc network and the initial use case will be needed again.
If the mission computer connected to its home network station during its last mission it will attempt to connect to that network again when it is powered on. The user will then have to connect to the same home network station and navigate to the mission computer's web page via a web browser. The web page can be reached at http://picus or by IP. The IP will be whatever the user set the home network IP to or be assigned by DHCP which may vary from connection to connection. Below is a picture of the webpage.
This page is where the user sets the information for the home base station FTP server. The home base station is the network that the mission computer will connect to after performing its mission, and default to when it powers on. The FTP server information is for the home base station’s FTP server where the mission computer will upload any data it collects. The file name is the name of the file that will contain the results of a survey mission.
Below contains example information for a home base station. The user must click Save Settings for this information to be saved to the mission computer (i.e., the Flyport PIC). All fields are required, and if any are not filled in an error message will be displayed.
In the example, the mission computer will connect to an infrastructure network using DHCP with and SSID of “homenet” using open security. It will use an FTP server with an IP of 192.168.1.2, port of 21, user name of “Flyport”, and password of “FlyportPass”. If sent on a survey mission the results will be uploaded on the FTP server to a file with the name of “scanResult.txt”.
This page is used to add field network stations that will be used during a collection mission. It requires all the same information as a home base station. The mission computer will attempt to connect to all networks added this way and download the file specified by the File Name field.
Below contains example information for a field network station. The user must click Add Station for this information to be saved to the mission computer. All fields are required, and if any are not filled in an error message will be displayed.
In the example, the mission computer will connect to a field infrastructure network using DHCP with and SSID of “fieldnet1” using open security. It will use an FTP server with an IP of 192.168.1.2, port of 21, user name of “Flyport”, and password of “FlyportPass”. If sent on a collection mission it will download “remoteData01.txt” from the “fieldnet1” field network station and upload that file on the home network station FTP server with the same file name.
Currently due to program constants there is a strict limit of three field network stations. Attempting to add any more than three will result in an error. If the user wishes to change one field network station they can delete a field network station from the Start Mission page, which will make room for an additional field network station.
Note: Currently any data collected from the given file is limited to 200 characters. It could be increased if the mission computer were equipped with external storage such as an SD card (which would require additional programming).
Starting a mission
Below shows an example Start Mission page with the home base station SSID set to “homenet” and three field network stations with their SSID's set to “fieldnet1, fieldnet2, and fieldnet3”.
The user can check that the settings for the home base station are correct by using the Check Network button. This will disconnect the mission computer from the current network and attempt to connect to the home base station.
If successful the mission computer will then be connected to the home base station, if not it will fall back to the default AdHoc network (see Initial Use).
Any field network station can be deleted by using the Delete Network button next to the field network station to be deleted. This is useful to make room for other networks, or to correct an error.
When the user is ready to start a mission they may select either survey or collection mission type and press the Start Mission button. The survey mission will not start unless the home base station is set up, and the collection mission will not start unless the home base station and at least one field network station are set up.
Flying a project on the onboard mission computer
After the Start Mission button is pressed the mission computer will begin performing its mission.
If survey mission was selected it will scan for WiFi networks and save the first 40 that it finds. After a set period of time it will start looking for its home base station SSID, and when it detects it will connect to it. If it successfully connects to the home base station, it will upload via FTP all network information that it found to the file name setup in Home Setup.
If collection mission was selected it will look for any of the specified field network station SSIDs. Once it finds one it will attempt to connect to that network and FTP server. If successful the mission computer will download the file that was set with file name on the Collection Setup page. It will do this for all field network station SSIDs that it finds. Again after a set period of time the mission computer will start to look for the home base station. When it detects the home base station it will attempt to connect to it and the home base station FTP server. If the connection is successful it will upload all files that it downloaded to the home base station FTP server.
Note: In the program it should be possible to change it from waiting a set period of time to waiting until at least one field network station is found, before looking for the home network station. This is currently not feasible because it is not possible to store all field network stations in RAM.
After either successful mission the mission computer will be able to be connected to again. Then the user may change settings and start another mission
The FileZilla FTP server
Setting up and testing the FileZilla FTP server
Setting up the FTP server is very similar to setting up the client, with the main difference being that the roles of active and passive mode are reversed.
A common mistake, especially by users with NAT routers, is in testing the server. If you are within your local network, you can only test using the local IP address of the server.
The server configuration is very similar to the client configuration for active mode. In passive mode, the server opens a socket and waits for the client to connect to it.
If you have a NAT router, you need to tell FileZilla Server your external IP address or passive mode connections will not work with clients outside your local network:
- If you have a fixed external IP address, you can enter it in the configuration dialog of FileZilla Server
- If you have a dynamic IP address, you can let FileZilla Server obtain your external IP address from a special website automatically. Except your version of FileZilla Server, no information will be submitted to that website.
If in doubt, use the second option.
Setting up FileZilla server with Windows Firewall
If you are having problems with setting up FileZilla Server to run behind Windows Firewall (specifically, it fails on "List" and the client receives a "Failed to receive directory listing" error), you must add the FileZilla Server application to Windows Firewall's Exceptions list. To do this, follow these steps:
- Open Windows Firewall under Control Panel.
- If using Windows 7, click “Allow a program or feature through Windows Firewall”.
- Click “Allow another program...”
- Do NOT select “FileZilla Server Interface” from the list, instead click on “Browse...”
- Locate the directory you installed FileZilla Server to (normally "C:\ProgramFiles\FileZilla Server\")
- Double click or select “FileZilla server.exe” and press open (Once again, NOT “FileZillaServer Interface.exe”).
- Select “FileZilla server.exe” from the list and click “OK”.
- Verify that “FileZilla server.exe” is added to the exceptions list and that it has a check mark in the box next to it.
- Press “OK” to close the window.
Passive mode should work now. If you are still having problems connecting (from another computer or outside the network), check your router settings or try to add the port number in the Windows Firewall settings.
FileZilla FTP Server
Since the Flyport speed limit is about 1 to 2Mbps, you can change the FileZilla Server speed limits from No Limit in both cases, to 10kps in both cases:
But changing it back to No Limit (the default) worked fine too:
NOTE: Using the Task Manager Services, it is possible to stop the FileZilla Server. However, when this is done, the FileZilla Server interface goes mad, see below:
For this reason it is better to keep the service running, you can turn the FileZilla Server on and off using the lightning bolt on the FileZilla user interface program:
ISSUE: When the FileZilla Server is simply left online, after a while, it seems that outside forces repeatedly attempt to log in on it:
It is possible that stopping the FileZilla Server service in the Task Manager, waiting a short while, then starting the service again appears to have stopped the above continual appearance of an outside force attempting to log in. Now things have been very quiet even though the server is online.
A major problem encountered related to the fact that winds that were quickly depleting the quadrotor LiPo battery as the autopilot was constantly adjusting its route. The constant changing of the speed of any of the 4 motors cut the projected flight time in half. A method will need to be developed to allow increasing the flight time.
The Montgomery County Community College students and faculty recognize and show appreciation to Ing. Claudio Carnevali and Ing. Gabriele Allegria from openPicus in Rome, Italy for our academic tie-up. Special thanks to Mr. Dan Graboi from FlyportAmerica, in California, USA for helping us in developing our airborne mission computer.
The EGR299-EGR292 class students:
- Aaron Wilz
- Brian Jerardi
- Daniel Rowe
- Jacob Simon
- Jason Cassel
- Kevin Healy
- Michael Marino
- Michelle Gavan
- Moon Kim
- Nathan Francis
- Regina Kuehrmann
- Scot Kantner
- William Fellmeth
- William Kerr
The engineering faculty:
- Andrew Ippolito
- Bill Brownlowe
- Jean-Jacques Reymond