Low Power Rangers

2D TOF RF tracking from a single sensor bar.

18-549 Capstone Project
Team 20: Clayton Ritcher, Nora Shoemaker, Shashwat Srivastava

We are three Electrical and Computer Engineering students at Carnegie Mellon University working on our senior capstone. This website is meant to track the progress of our project over the Spring 2016 semester.

Important Documents

Video

Pictures

Documentation

Concept

The goal of our project is to create a real time web API for relative angle and range information of a Tag from a measurement device.

To do this, we plan to use two fixed ultra wide band (UWB) radio transceivers (called Anchors) to collect Angle of Arrival (AoA) and Time of Flight (TOF) information of signals from a third, mobile UWB transceiver (called a Tag).

Motivation

Indoor position tracking applications are limitless -- from home automation, to security, or even finding your keys. Currently, indoor postion tracking systems are either too inaccurate for many of these applications, require extensive infrastructure, or are too expensive to achieve widespread adoption.

Our goal is to create an inexpensive plug-and-play device that precisely measures its range and angle from a Tag to support these types of applications.

Competitive Analysis

No current solutions exist that use UWB radios to measure range and angle to a device. Several systems exist that could be used for similar applications, though. For instance:

Wifi-based

Redpin is an open source indoor positioning system that was developed with the goal of providing at least room level accuracy. This technology can be used on any wifi-connected device. Its utilization of current WiFi infrastructure makes it easy to adopt, but its accuracy rules it out for some applications.

Bluetooth Low Energy (BLE) Beacons

Estimote is a company that creates small, wireless BLE radios that can be attached to any location or object in order to track surrounding smartphones. Estimote also has an SDK on top of which apps can be written in order to interact with their radios. Estimote boasts an average measurement error of 20-30% of actual distance. Estimote's SDK and battery operated beacons make installation easy, but because error grows with the distance from the beacons, high accuracy requires many beacons in the space.

Ultra Wide Band (UWB)

UWB radios use time of flight (TOF) analysis to gain distance readings with sub-meter accuracy. Because UWB radios are not yet ubiquitous (not in phones like BLE or WiFi), UWB tracking is often used in custom installations which are expensive. Additionally, the biggest player in the production of UWB transceivers, Decawave, is a closed source shop and charges large amounts to gain access to their development kits.

Use Cases

Because our final product is an API, our use cases can be thought of possible applications built on top of our API. Because our API is so general, there are many, many possible applications, so we will focus on one single example.

Indoor Localization Radar

We've all been there. Lost our phone somewhere in our house, but unable to find it (of course, it's placed on silent...sigh). Find my iPhone and other wifi-based localization apps will tell you your phone is in the building (great, you already knew that), but what you really want to know is where in the room it is.

With our indoor localization radar app, all you have to do is place a small tag on your phone, and we will be able to tell you not only which room it is in, but where inside the room it is.

The app idea is to make an Android mobile application which can use data it receives from the server to show the most recent position of the tag being tagged. To do this the Android app will connect to the website and pull information and update the locations of the tags on screen.

The main screen will have dots whcih move around representing different tags.

The dot representing the tag will move around as required. The position of the tag is fixed at the top of the screen and the user will have to orient himself that way as there is no way of knowing which direction the user is relative to the anchors.

It will allow the user to add new tags by entering their tag ID and a name for them.

This menu comes up when the user presses the plus button to add a new tag. The user can then enter a tag ID and the application will check to make sure it exists and if it does, add it to the main screen.

Other Possible Use Cases

  • Invisible fence
  • Proximity light activation
  • Tracking mobility over time

Requirements

Functional Requirements

  • Range and angle data shall be available through a web-accessible API.
  • Tag shall be portable (battery powered) as to allow tracking of mobile objects.

Quality Attributes

  • Range and angle data should be available through the API in under two seconds after the data is collected.
  • Range and angle data shall be collected at a rate of at least 1 Hz.
  • Tag shall be able to run at least two hours on a full battery.
  • Webserver shall be able to handle load of up to 100 requests per second.

Constraints

  • Budget of $700.
  • 10 week project timeline.
  • 3 team members.

Stretch Goals/Possible Extensions

  • A ‘radar’ app for finding your keys, phone, etc (anything with a Tag attached).
  • A client app that integrates the system with IFTTT, allowing actions such as turning on the TV when you sit on the couch.
  • Add a third Anchor, making an ‘L’ with the other two, in order to measure both the vertical and horizontal angle of arrival.
  • Ability to change the baseline distance between the measurement Anchors without manually changing the configuration parameters in the code.

Technical Specifications

Parts List

Raspberry Pi

The Raspberry Pi will do the math to determine angle of arrival and range and will also report new data to our webserver.

Decawave DWM1000 Module

The DWM1000 is the wireless radio tranceiver that allows the Tags and Anchors to talk to eachother in order to determine their distances from each other. Each Tag/Anchor will have one of these.

ATMega328

The ATMega328 microcontroller will boss around the DWM1000s and tell them what to do. Our homemade communication protocol will be implemented on these puppies. Each Tag/Anchor will have one of these.

FTDI Cable

An FTDI Cable will connect each of our Anchors to the Raspberry Pi. It's in charge of bringing power to the Anchors as well as allowing them to send their range calculations to the Raspberry Pi.

Protocols Used

SPI

We will use SPI protocol for communication between the microcontrollers and the DWM1000 modules.

Homemade Ranging Protocol

For communication between Tags and Anchors, we will define and implement our own communication protocol.

HTTP

We will use HTTP protocol for communication between the Raspberry Pi and the Webserver. Additionally, Clients will use HTTP to communicate with our web API.

UART/USB

The FTDI cable mentioned above will allow the Anchors to send their measurements to the Raspberry Pi. The Anchors will write these values out using UART serial and a chip in the cable will convert these signals into USB protocol for the Raspberry Pi.

Architecture

Below is a physical architectural diagram of our system including possible client applications. This diagram is meant to show the system structure and communication types. The blue boundary represents our system boundary. The purple boundary is meant to represent the physical and logical boundary of each Anchor/Tag.

UWB communication is used to obtain the range data between each of the Anchors and the Tag using TOF analysis. Microcontrollers on each Tag/Anchor talk to the DWM1000 chip through SPI. Once each of the Anchors know their distance from the Tag, this information will be sent to the Raspberry Pi, along with the Tag ID. The Raspberry Pi will then compute the angle of arrival based on the two range estimates and the known distance between the Anchors. Once the angle of arrival is calculated, the range between the Tag and the midpoint of the Anchors will be calculated and these two pieces of data will be sent to the web server, with the Tag and measurement device IDs, through an internal API call.

Interaction Diagrams

API-level Interaction

At a higher level, our project itself has very little user interaction (by design, for ease of use); the user simply needs to carry a Tag with them while in the presence of a measurement device to use the system itself. However, here is what we would expect user interaction with a client application to look like:

Internal Sysem Interaction

The goal of our system is to collect range and angle of arrival information about a single Tag, relative to a measurement device, over a period of time and create a web API from which applications can retrieve this information.

The diagram shows the interaction between various components going through the process of collecting range and angle of arrival information for a single point in time.

Steps:
  1. Poll - Tag polls both Anchors in a broadcasted message.
  2. ResponseA - Anchor A sends response to Tag.
  3. ResponseB - Anchor B sends response to Tag.
  4. Final - Tag broadcasts Final message to Anchors containing enough information for each Anchor to estimate range.
  5. Anchors tell Raspberry Pi their newly calculated range values.
  6. Raspberry Pi calculates angle of arrival and then makes API call to store new data on the Webserver.

Ranging Protocol

At an even lower level, we need to define a ranging protocol across DWM1000s.

For our protocol, we chose a variant of the Broadcast-Double-Sided Ranging (BDSR) protocol. This protocol has the Tag broadcast its messages, and lets all other devices respond in a staggered format.

Below is a diagram showing the BDSR protocol with three anchors where Tprop is the propagation time between the Tag and the corresponding Anchor.

We chose to implement a variant of BDSR with only two Anchors.

Message data sent throughout different steps of protocol:

Protocol Step Data Sent
Poll/td> Range Session ID, Tag Address
Response Range Session ID, Anchor ID
Final Range Session ID, Tag Address, Tround1A, Treply2A, Treply1B, Treply2B

One thing to note is that, at the end of our protocol, the information necessary to calculate propagation times is available on the Anchors but not the Tags. This is okay for our use case because (as you can see in the sytem interaction diagram) the Anchors are the ones who send the Raspi the range data, not the Tags.