NASA - Local Positioning System

We are designing a local positioning system (LPS) to track individuals and equipment in an area where GPS is unavailable. This LPS would support safe and efficient space exploration, and could provide a flexible backup for satellite based navigation systems on Earth. Research to date on outdoor local positioning systems with multiple kilometer range has been limited, and this project is to become such a system. It will be relatively easy to deploy and functional even over areas with rugged terrain, such as on the surface of a planet like Mars. 
=Summary=
Global navigation satellite systems (GNSS) have proven reliable but are vulnerable to things like solar flares, jamming and spoofing, and may have limited accuracy in certain environments. A flexible system like the LPS could provide a temporary alternative in emergency situations or supplement GNSS when higher accuracy or greater security is desired. The LPS will be based on software defined radios (SDRs), so the hardware on every part of the total system can be the same. The software on each part will also be very similar, with all the position computation carried out on a central computer. The system will be easily adaptable to different frequencies, bandwidths, sample rates, etc. The signals will be based on the same codes streamed by GPS satellites and allow for ranging and positioning by a variety of methods, centered around correlation.
This team has laid much of the groundwork for this project, primarily through research. We demonstrated that software defined radios can be used to measure the distance to a tethered balloon. Error analysis shows that the final system will need to determine the positions of the balloons to within 10 cm to determine the position of a mobile unit to within 4 m. We have created a configurable positioning module which can be duplicated and used for further testing, both on balloons and on the ground. Our software provides a starting point for new designs, and our research, analysis and test flight better defines how the final system will need to perform.
=Problem Definition=
==Background==
Current Global Postitioning Systems(GPS) require the use of satellites in order to determine a location. On another planet like Mars they would be expensive to ship and difficult to repair or move to a different location. By using a series of balloons tethered around a specified point, it is possible to create a system that would function at a much cheaper cost and be easier to set-up and use than satellites. 
==Deliverables==
The Local Positioning System must act as an easy to set up replacement for GPS systems mounted on a series of tethered balloons. It must cost less than the price of shipping a satellite to Mars and update a users location in "real-time"
==Specifications==
===Functional Requirements===
 
*User Interface
**The system shall take no more than 3 hours for 3 people to set up and launch 
**All set up activity shall take place no more than 250 m from a defined central point.
*Postitioning Requirements
**Position information shall be displayed to a user at the defined central point or to a mobile user.
**The system shall determine the positions of one mobile unit relative to a defined central point.
**Positions shall be determined with an accuracy of +/- 4 m in any direction.
**shall be determined and displayed within 10s of a mobile unit occupying that position.
**Position measurements should be time stamped and recorded. 
**The system shall be capable of determining positions of mobile units anywhere within a 7 km radius of the reference point.
**The system shall operate continuously for at least 8 hours.
===Flight Requirements===
*Critical subsystems shall be designed to fly on moored (tethered) balloons.
*At least one balloon shall be launched as a critical part of a demonstration of the system.
===Environmental Requirements===
*The system is expected to have full operational capabilities in environments with ambient temperatures of -20°C to 40°C and winds of up to 9 m/s and no precipitation.
===Regulatory Requirements===
*FAA Requirements
** 14 CFR 101.13
** 14 CFR 101.15 
** 14 CFR 101.17 
** 14 CFR 101.19 
*FCC Requirements
**Communications devices must operate in amateur radio or unlicensed frequency bands, and comply with all regulations that apply to the selected bands. See FCC frequency allocations (3) and relevant regulations.
**All components must comply with FCC regulations at all times.
===Cost Requirements===
* Cost of a theoretical final product shall not exceed the cost of a GPS satellite launch.
* Cost to produce the prototype shall not exceed $10,000.
=Design Considerations=
The current plan is to use software-defined radio(SDR) to measure when a signal is sent and received. A SDR eliminates the need for traditional hardware components and circuits and instead implements them through the use of software running on a computer. Three balloons will be tethered 140m above the ground and mounted an SDR to receive radio signals. The receivers need to be located above the ground in order to have a clear line-of-sight to the transmitter since the radio waves will travel different speeds based on the medium they are traveling through. 
Fundamentally, the location of an object can be determined by measuring its distance or angles from three or more known references. The more references used in the calculation of the position will increase the accuracy of the calculation. By measuring the time it takes for a signal of an unknown origin to travel to a receiver with a known location, it is possible to determine how far a way the signal originated from. Using the distances from known references is called Multilateration. Our current design is to use three tethered balloons who's locations are known in order to provide the known references, and use the time it takes for a radio signal to reach each of the three balloons to find the location of a mobile object. 
=Project Learning=
==GNU Radio==
Gnu Radio is a free, open source software used to create software defined radios and simulations. The user pieces together either pre-defined blocks or creates their own custom blocks in python to create flowgraphs that perform a specific function. We have started off by creating a flowgraph to achieve basic communication between two antennae.
Example of a flowgraph used to modify an incoming signal source into something readable
GNU radio is able to run on linux and is light enough that it can be run on a small micro controller like a raspberry-pi.
==Multilateration==
In determining the position of an object based on the travel time of radio waves there are two main ways you can get a position: Time of Arrival and Time Difference of Arrival
Time of Arrival(ToA) calculations rely on having the exact time that the signal is sent and received to a reference point and subtracting them to get the time it takes for the signal to arrive. This system provides a 3D sphere around the reference point that can be compared with other spheres from different reference points to pinpoint a location. The point where each overlapping sphere meets is the location of the transmitter. 
The biggest problem with this system is that it requires us to have a way to ensure that the clocks on the transmitter and receivers are very closely synced, as even the smallest difference will have an effect on the final answer. For this system we would have one transmitter and multiple receivers with known locations that measure the time.
A way around this is a process called Two Way Time Transfer, where the time a signal takes to travel to a radio,re-transmitted, and sent back to where it originated is also measured. This only requires the first station to know the delay before the signal gets re-transmitted which does not require the clocks to be perfectly synced. This still gives spheres as the potential location of each point.
Instead of measuring how long the signal takes to reach a receiver, Time Difference of Arrival(TDoA) calculations measure the difference in when multiple signals reach a receiver. While ToA calculations require a high degree of coordination from each transmitter, the TDoA calculation does not require the time the signal was sent out. They only require that the signal was sent out at the same time from all receivers.
 
This works in our situation since we can have each balloon physically connected to the other to send a signal whereas it is much harder to sync two clocks that are 7 km apart. The result gives a hyperboloid of the location of the receiver for each transmitter as opposed to a sphere. Each hyperboloid can then be referenced to the others and where they all intersect is where the receiver is. This system would have multiple transmitters with known locations and one receiver that we are trying to locate.
==Pseudo-Random Sequence Correlation==
Pseudo-Random Sequence Correlation is a way satellites are used determine the arrival time of a signal to determine the distance away an object is. Each satellite plays a unique sequence of numbers that appear random however are predetermined by a known formula. Each receiver knows the code that each satellite is playing in advance. When a receiver wants to calculate the distance to a satellite, it starts playing the code at the same time as the satellite starts it. The difference in what the receiver is creating and what it is receiving from the satellite gives the distance away from the satellite.
This system can be adapted for use with balloons just above the earths surface as opposed to satellites orbiting the planet. The only limitation is it still requires a clear line of sight between the object and the transmitter as every object in the way will increase the time it takes for a signal to travel the distance. This system also inherently supports multiple users at the same time, especially if the positioning calculation is done at the receiver as opposed to a centralized location.
==Movement of Balloons==
Since we are using weather balloons we have to find a way to account for the movement of the balloon in each calculation. One option is to use the same system we have for each radio however we would add in a known base station on the ground. We would then be able to find the position of each balloon just before sending the signals, and assume that the balloon was not able to move that much during the time it takes to send and receive the signal. The downsides of this is that is might be difficult to perform this calculation in a small enough time to still hold the assumption that the balloons position would not change.
Another solution to this is to use an accelerometer and strain gauge attached to each balloon. The accelerometer would provide the angle the balloon is relative to the ground. The strain gauge would give us the strain in the rope from the balloon which would give us the elongation of the rope. These combined with knowing the initial length of the rope would give us a position of the balloon. This solution provides us with a set of much less computationally intensive equations. The problem encountered with this approach is that the rope will not be a straight line connecting the balloon to the tether. The curvature of the rope will also not be consistent enough at each position in order to predict what it would be without predetermining the positions of this experimentally, removing most of the benefits we would get from this system.
As an alternative, we are looking into an Impulse tracking system, which would keep track of the position of the balloon once the system is turned on. However, these systems run into problems without a way to calibrate them as they are running as the small errors in the calculation of the impulse compounds to eventually lose the true position of the balloon. If our only problem is computational time, we might be able to use the ground stations to calculate the position of the balloon and then use the system to keep track of the balloon for a short time while the radios calculate the position of the mobile unit.
==Uncertainty Analysis==
EES and MATLAB were used to solve a series of three equations that gives the intersection point of three spheres. This was used to determine how error in the calculated position of the balloon effects the calculation of the final position. The way we are currently calculating the position of the balloons means that we only calculate the position for a moment and assume that the balloon will not move significantly in that time. The less time that elapses before the distances are calculated means the more accurate the results will be.
The planned location for each each tether is not optimized for 3D positioning however it does give accurate results for 2D positioning which could be used in conjunction with a 3D topographical map or other system to get the height above the surface. The reason for this is because each base station is effectively in a straight line relative to where a position would be. This means each "Sphere" of possible locations are intersecting where they are changing vertically as opposed to intersecting perpendicularly where they are changing about the same in every direction. This can be mitigated by changing the altitudes of the balloons however for our testing purposes we are limited to 150 meters by the FAA.
==Rapid Deflation Device==
FAA requirements require the balloon to have an automatically triggered rapid deflation device that would activate should the balloon become tethered. Two systems were considered to be used, a tether and pin method and a hot wire. 
===Tether and Pin===
This type of system would use an extra tether that would be longer than the ones holding the payload. If the other tethers failed the balloon would rise tugging on this tether, pulling out a pin holding the balloon closed on the bottom and deflating everything. This type of system
===Hot Wire===
This would be a thin wire taped to the side of the balloon that when activated would heat up to melt a hole in the balloon causing it to deflate. This is a slightly more complex method however since the payload would already have some sort of micro controller inside of it this would be simple to integrate into our existing payload.
==Payload Detach Device==
The payload that is being sent off contains electronics that could be damaged if the balloon were to become detached or come crashing into the ground. In order to minimize the chance of damage occurring to the electronics, a parachute is going to be attached to the payload. The payload will also be detached from the balloon both to minimize the amount of weight being dragged down and to ensure that the parachute is able to deploy freely and that the rest of the balloon does not interfere with its deployment. This will be done with a linear actuator.
==Atmosphere on Mars==
On the surface of Mars the atmosphere is about .02 kg/m^3 as opposed to Earths 1.2 kg/m^3. Balloons generate lift equal to the weight of the air they displace, meaning that with a less dense atmosphere larger balloons will be required to lift the same amount. Helium still works as a lighter gas to fill the balloon with however lighter gasses like Hydrogen could potentially be used. Another problem is with balloons of that size a small difference in pressure between the inside of the balloon and outside causes large forces to be present in the balloon because of the large surface area. This could be problematic with the temperature variations of +/- 100 degrees Celsius in some places, having enough helium to keep the balloon up when it is warm out could pop the balloon when it gets cold out. Some solutions are being researched at NASA such as their Heavylift Super Pressure Balloon.
=Final Designs=
==The Circuit==
The entire system is powered by a 22.2V Lithium Polymer battery which feeds in a DC/DC converter that steps down the voltage to 12V to be able to power the UDOO X86 Advanced Plus which is a single board computer with Intel Quad Core processors and is Arduino 101 compatible. This single board computer powers the GPS Receiver, the software defined radio(USRP B205mini-i model) and the LoRaWAN Radio Transceiver. 
The GPS Receiver, Software defined radios and the LoRaWAN radio transceiver all required about 3.3v to be powered up and running so the UDOO X86 Advanced Plus is capable of accomplishing this.
The 22.2V Li-Po battery also feeds directly into Linear actuator which would need enough power to be triggered once a cut down process is required as earlier explained. Besides the 22.2V Li-Po battery, a 9V battery is also added to the system and is connected to a Nichrome wire which would have enough power to burst the Balloon when in flight and in need of a cutdown.
==The Payload==
USRP B205 mini-i SDRs SDRs were decided as the best choice for transmitting and receiving the positioning signals. The 902-928 MHz band was chosen because it would not require us to have a license and could easily travel over 7km while still being a high enough frequency for accurate detection. GNU Radio was used to interface with the USRPs. A two way time transfer system was used to find the distance between each radio. The system would measure how long it takes for a signal to travel to a radio and get sent back using pseudorandom code correlation, allowing us to avoid the problem of having to sync multiple clocks. 
The payload itself was made of Styrofoam that was glued and zip-tied together. Plywood supports were added into key areas to ensure any ropes or zip ties carrying weight wouldn't cut through the Styrofoam. The payload included a Battery, UDOO Computer/Arduino, USRP SDR, a GPS, a separate 9v battery, and a board with two switches to control the linear actuator and the hot wire. A cord connected to the top of the parachute was threaded through a ring attached to the balloon and back down to be attached to the linear actuator. The Hot-wire and 9v battery were their own circuit connected to everything else by a switch triggered by a GPS. The linear actuator was controlled by another switch. An Arduino was used to gather the data from the GPS and trigger the Hot-Wire and Linear Actuator if the GPS started showing positions outside of what we defined before the launch.
==Unresolved Issues==
In the payload there were a few features that we could not get fully working. We couldn't get high enough sample rate to get ranges more accurate than +/- 50 meters for the project, however we were able to get consistent correlation peaks with the balloon and a radio on the ground. 
The Arduino integrated with the UDOO board was a source of some problems as the UDOO would not register when the GPS was done sending data for each line and would cause the code to get stuck in an endless loop. The team was unable to resolve this issue and added in a standalone Arduino which didn’t have this problem. When it came to the GPS trigger only the Altitude was able to be used as a trigger. The GPS sends everything as an ASCII string that then gets converted to either a string or a float. The latitude and longitude would be given down to many decimal places however the conversion would only save two of them. Altitude was not affected by this problem as the GPS outputted it in meters as opposed to degrees, seconds, and minutes for latitude and longitude. We also had problems mounting the Hot-Wire to the balloon without tearing the wire out of its connections in the payload.
A secondary goal of the flight was to log GPS data to create better testing conditions for future project use. This was supposed to be done with the GPS and a script on the UDOO to read everything that was being transmitted on the serial port. For an unknown reason the data never got saved even though both systems were tested just before launch.
=Future Work=
The next step of this project is to greatly increase ranging accuracy to approximately plus or minus 10 cm. Then ranging can be extensively tested for maximum range, the effect of temperature on range, the effect of obstacles, the effect of interference and other issues. This could more than a year. Then code can be built up in GNU Radio to follow the process outlined in System Architecture. That would likely take about a month. Then the positioning of the system can be tested. If it does not work well (a likely problem is that positions are not found fast enough for the movement of the balloons to be negligible), several more months at least would be required. Porting the code from GNU Radio and Python to C++ would help, and there are other correlation based methods, such as using phase locked loops that could be tried. Carrier phase correlation might be needed and that would likely take several months as well. 
	To test the whole system in the field, software needs to be completed to communicate with the LoRa radios. That would likely take about two weeks. The issue with GPS logging on the Arduino and UDOO needs to be solved as well, which could take anywhere from a day to a month. Realistically, these steps will take at least two years of dedicated work by a few students. As senior design projects, they would most likely take longer since so much time may be spent getting familiar with the system and concepts.
	Very little extra hardware will be required. All of the electronics are purchased. Some extra wire, connectors and solder will be necessary. Boxes for the electronics will need to be built, but the team already has glue and styrofoam, though more may be necessary depending on the size of the boxes. Test launches will require approximately $300 of helium for each balloon, $150 for each balloon and $60 for every 500 feet of tethers. With one test launch, a cost estimate for finishing this project (demonstrating a proof of concept positioning system) is about $2,000. More test launches will probably be necessary, making a more realistic estimate about $4,700.
=Team Members=
thumb|left	Jonathan Preheim 
Major: Electrical Engineering
Hometown: Lancaster, PA 
Graduation Date:May 2019 
Future Goals: I want to devolp radio frequency technology that would be useful in space exploration
Email:preh7493@vandals.uidaho.edi
thumb|left	Paul Dania 
Major: Electrical Engineering
Hometown: Moscow, ID 
Graduation Date:May 2019 
Future Goals: I want to see the world and eventually work for NASA and deep space exploration
Email:dani2754@vandals.uidaho.edu
thumb|left	Andrew Petrehn 
Major: Mechanical Engineering
Hometown: Eagle, ID 
Graduation Date:May 2019 
Future Goals: I want to go into the US Air Force after I graduate and become a pilot,eventually hoping to get a masters in Aerospace Engineering and work on space craft.
Email:andrewpetrehn@gmail.com
=Additional Documentation=
*Project Schedule
*Project Value Proposition
*Snapshot 1
*Client Interview
*Budget
*Minutes
*Design Review
*Snapshot 2