RFGeolocation

From eLinux.org
Revision as of 06:28, 19 September 2014 by Cattnb (talk | contribs)
Jump to: navigation, search

Testbed for RF Geolocation by Nathan Catt, Andrew Belk, Jaci Dalton, and Joel Stiffler

RHLogo.jpg

The goal of this project, Testbed Development for Geolocation of RF Emitters, was to improve upon the testbed used in conjunction with the Air Force Research Laboratory (AFRL) geolocation algorithm. The military has many applications where locating radio signals are important. Locating downed pilots or pinpointing communication signals of the enemy are just a couple of examples. Rose-Hulman Institute of Technology is currently working on compressive sensing algorithms to help locate the source of radio frequency (RF) signals. These algorithms will be implemented on a ground based mobile platform as part of this project development. The mobile platform will be controlled by a user. A system must first be designed that includes reconfigurable sensors with at least one transmitter and two receivers. The mobile testbeds will need to demonstrate the ability to receive signals and locate the transmitter. A final demonstration will be completed at the AFRL. This testbed could be made autonomous or implemented on an aerial platform in future development. The main goal of this project was to create a system that had individual sensors that can navigate through a predefined grid and use the received signal strength taken at different points and angles to locate the emitting signal. Our team used a mobile platform that has a programmable motor controller, a Software Defined Radio (SDR), a microprocessor, and various sensors. Our team was able to implement an Xbox 360 remote as a user control for movement and access to sensor data. The initial plan was to have an autonomously controlled system, but the accuracy of the off-the-shelf GPS was not sufficient. Our team suggests using a more accurate GPS sensor in order to implement a waypoint navigation algorithm.

Transmitting Rover

Project Overview

For this project, our team has been working for the United States Air Force Research Lab (AFRL). The United States Air Force (USAF) has the desire to be able to locate emitters at different frequencies for a number of different reasons, including locating enemy communication signals. The goal of our team’s project was to create a testbed that would collect the required data to run a compressive sensing algorithm that is currently being developed by the Rose-Hulman Institute of Technology Department of Mathematics. Our project was intended to be a fundamental stepping block for much more complicated data collection, but more importantly, to collect data to test the effectiveness of the geolocation algorithms. The main deliverables for this project include the testing hardware developed by our team and a detailed testing plan. Our team was able to achieve creating reconfigurable sensors that are mobile and able to collect data when requested by the user.

Logical Architecture
Domain Model

Hardware

Microprocessor

We chose to use the BeagleBone Black for our microprocessor. This enabled us to have plenty of room for additional sensor expansion. It takes 210-460mA at 5V and has I2C, Serial, UART, GPIO, and Analog Input along its pin headers. Additionally, it has an HDMI, USB, Ethernet, microSD card, and microUSB inputs. A BeagleBone Proto Cape was used to get rid of wire clutter.

We chose the Alfa Wi-Fi USB Adapter as a reliable/powerful Wifi adapter. The Wifi adapter must be plugged into the USB port upon start up in order for the connection to work.

GPS

The Adafruit Ultimate GPS Module was used as our GPS sensor. This was the best COTS GPS device on the market at the time. Details of the pins of the GPS sensor can be found here. We also used the External GPS Antenna to increase the gain of the GPS. Take note that this antenna is magnetic, although we do not utilize this on the rovers. Feeding this antenna through the top of the rovers' cover is extremely tedious, but was done to remove the magnetic antenna away from other hardware such as the SDR.

Compass

The compass is located on the outside of the rover and is wired through the cover down to the expansion cape. The compass specs can be found here. The compass uses I2C to communicate to the BeagleBone. Before testing can be done, a calibration of the compass must be performed. This includes turning the compass 720 degrees in 2 - 30 seconds.

Software Defined Radio

The Software Defined Radio (SDR) is the most complicated piece of hardware on board. It has much more power than the BeagleBone, although not as much input/output. Still, this piece of hardware has huge potential into further research and development. The SDR used in our project was the Ettus Research E100. The SDR communicates directly with the BeagleBone over an Ethernet connection. The USRP E100 is a top-of-the-line embedded SDR. A complex communication system can be programmed using python or GNU Radio (or its graphical version, GNU Radio Companion). After talking to an Ettus Reserach representative and determining the metal cover has no effect on performance, we chose to remove the casing to conserve space within the rover. It is imperative that care be given to these devices as they are fragile and extremely costly. Attached to the SDR is the Daughterboard and the Antenna. One SDR was programmed as a transmitter using an omni-directional antenna, while the other two rovers were programmed as receivers with directed antennas.

Since the start of the project, new SDRs have come on the market. NI's version of the Ettus Research USRP is widely used in the classroom and is easily programmed with LabView. Cost is a limiter on this product. A second, much less costly product of interest is the Hack RF. This could be helpful in simple RF protocol research.

Daughterboard

The daughterboard is connected on the top of the SDR. We chose the RFX900 due to its operating frequency range in the IMS band. Make sure the board is properly attached to the SDR for accurate results.

Antennas

Antennas chose for this project were the log periodic directional antenna LP0965 as the receiving antenna and the omni-directional VERT900 as the transmitting antenna. These should be wired directly to the SDR using SMA connectors.

Payload Housing

Mobile Platform

Wild Thumper

T'Rex Motor Controller

Power System

User Control

Software

Our code can be cloned from GitHub.

Software Flow Diagram
Alt text
Control Flow Diagram

Client

The Client code is ran on the BeagleBone. This code integrates all of the sensors and communicates information back to the host computer. The current BeagleBones are the Rev B version running Angstrom with the September 4th, 2013 image. The Client runs two primary programs. The first (Client.c) interfaces with the Central Processing Node, while the second (SDRdata.py) interfaces with the SDR. These two programs interface through a UNIX socket.

Wifi

Getting the BeagleBone (aka Client) to connect to the Wifi was a challenge. First, make sure the Router is maintained with a ESSID of "beagle" and the password is set to "beagle10". This can be done by pointing a browser at the IP address of the router when connected to its Wifi. Direct instructions on how to set up the Wifi with BeagleBone Black Rev B (the version we are currently using) can be found here. I've found better instructions for Rev C provided on Adafruit's website. These instructions seem to provide a much more stable connection. I skipped the disabling of the HDMI port and it still maintains a consistent connection.

Server

Software Defined Radio

Testing

Subsystem Testing

Full System Testing

For correct operation, the following boot sequence must be followed:

  1. Power on the Wi-Fi router
  2. Connect the central processing node to the router
  3. Power the Beaglebone; wait for it to connect to the network
  4. Power the motor controller and the SDR


Location of Measurements

Alt text
Location of Measurements

Simulation of Position Points

Simulation.gif

Future Developments

MATLAB

Integrating MATLAB to view data in real-time is a potential addition to this project. This would enable users to understand and view solutions to the algorithm in real-time while controlling the rovers. In order to do this, a UNIX socket could be set up between the Server code and the MATLAB code so that once the Server code receives data, it is then relayed to MATLAB. Once MATLAB receives the code, it could add it to the table of previous data points and recalculate the position of the sensor using the algorithm.

Wild Thumper Controls

The controls to the Wild Thumper seem to be incorrect. Videos online seen here, show the Wild Thumper moving seamlessly through rough terrain. Our Wild Thumpers have a difficult time navigating even on pavement. This could possibly be due to its' heavy payload. Having two battery packs on board does not help.