Student Projects
Contact Information:
Country: USA
Year Submitted: 2018
University: University of Texas at Austin
List of Team Members (with year of graduation): Will have a list of entire team soon.
Faculty Advisers: Dr. Christian Claudel
Main Contact Email Address: uthyperloopengineering@gmail.com
Project Information:
Title: UT Hyperloop Competition Entry - 2017 Innovation Award Winner
Description: With the help of a control systems designed around NI products, we have designed a Hyperloop Pod to travel at Transonic speeds with an air-bearing levitation system.
Products: myRIO, LabVIEW
Next iteration of design will use cRIO 9035, NI 9862, NI 9403, NI 9882, NI 9870, NI 9212, NI 9203
The Challenge:
How do we travel from one place to another in the most time, energy, and cost efficient way possible?
The Solution:
Texas Guadaloop is Texas’s premier Hyperloop student organization that houses a diverse group of multidisciplinary members ranging from PhD students to first-year engineers in fields such as Computer Science, Physics, and all flavors of engineering. In 2017, we competed in SpaceX’s Hyperloop Pod Competition II, where universities from all around the world send teams to test their designs for a nascent transonic vehicle concept that travels in a vacuum tube. Our Unique and competitive design earned us an innovation award, permantly putting University of Texas on the map for ground breaking Hypersonic Research. It is a revolutionary concept that has never been attempted before and will seek to bridge the gap between automobile travel and flight, shortening travel times between cities such as San Antonio and Houston where neither method of travel is ideal.
When designing a vehicle travelling past the speed of sound, having the right control system is crucial. In the previous iteration of our control system, we utilized two boards to control how the pod would work. The primary board was a Raspberry Pi 3 running Rasbian, which would handle communication, calculation, automation, and all the other high level tasks that we assigned it. Running at 1.2 GHz the Pi could handle all subsystems with ease, but by hardware design was mostly digital I/O pins and thus could not interface with enough of the analog sensors or outputs we required. As a result we made use of a second board, coming from TI’s TM4C family, which ran much slower (120 MHz) but could handle both digital and analog operations. The 40 digital pins on the Pi were connected to 40 digital pins on the TM4C to establish command-based communication protocol between the boards - in this manner, when the Pi updated a subsystem that required an analog read, it used this protocol to send a command and receive data. This communication protocol split the 40 bits into sections, some representing state bits, some representing 16-bit (half width) floats, some bits reserved for preventing race conditions while the Pi wants to read data. Essentially, the Pi used the TM4C as a blocking I/O device so that when a command was sent it could work on other subsystems - when the TM4C finished a command a state bit was flipped and the Pi resumed that specific subsystem. This protocol was tested on startup by simply sending over empty read and write commands with hardcoded outputs; as soon as the Pi verified these outputs matched, it could begin its flight code.
In our new design, the pod will be centrally controlled via a National Instruments CompactRIO microcontroller that will interface with an array of sensors and actuators to monitor and autonomously control of the pod during the test flight. We want to use the CompactRio because we want to convert some of the code to run on the FPGA so that we can have a better response time for specific critical systems, like height control and braking system. We also want to utilize the CRio’s CAN communication protocol so that we can integrate an electric motor to drive our pod. As for our sensors, we are keeping the current I2C system with some updated circuit design to improve signal integrity over long distances and interference from the electric motor. Sensor information will monitor system health like ammeter and voltmeter readings on all electrical systems, potentiometer readings on all electronic actuators, pressure at each air canister, air tank, and at imperative points throughout the pneumatic system, and drive motor RP, telemetry information includes speed, position along the track, ride height when levitating, and acceleration. All of these information will be relayed through the CRio so that the CRio can autonomously make all relevant decisions during the test flight and activate the necessary contingency measures in the case of a system failure. The information will also be relayed in real time, over UDP, to the control station running a Labview User interface.
Figure 1: Solution to improve I2C signal integrity over long distances
As stated earlier, the TM4C-Pi communication protocol was set up to allow the Pi to use the TM4C as an I/O device. Though this was an efficient system for this small use case, distributing blocking I/O requests across boards via a makeshift communication protocol is not scalable. For a single pod the bottleneck was communication between boards - shifting I/O off the board means the processor has to spend more cycles on waiting for a process to finish (analogous to accessing main memory instead of the L1 cache). For multiple pods this means more boards, more cycles, slower access times, and thus slower subsystem updates. Past the scalability there is also the issue of power consumption - while the Pi is overkill but lacks enough analog pins, the TM4C does not have enough processing power to handle the speed of updates required at high speeds. Lastly, two boards requires double the power supply and immediately reduces battery lifespan just to keep the control system alive, as there is no code or kernel shortcut to reduce voltage or current requirement. A careful balance between processing power, hardware features (power and analog/digital ability), and board cost has to be achieved for the optimal control system, thus it is safe to say this system is suboptimal, albeit sufficient.
As we kept running into issues with our embedded systems, we explored the National Instruments ecosystem to look for higher performance, reliable embedded devices. In the academic product line, the National Instruments myRIO provided us an ideal prototyping embedded system: a mixed array of I/O including analog & digital, a dual-core real-time processor, a Field Programmable Gate Array (FPGA), built-in network communications, flexible power options, and programmable with LabVIEW.
Fig. 2- Comparing new NI-based system to old system
Beyond the higher performance that the new NI-based system provided, moving to the NI myRIO fundamentally changed how simple our system was and therefore how quickly we could iterate on designs. We went from a system that used multiple embedded controllers and a mess of wires to a single embedded controller that had more processing power, I/O, and reliability. We went from three custom printed circuit boards (PCBs) to one. We went from spending 80% of our development time trying to resolve communications issues between systems to 100% of our development time focused on the new sensors, the architecture, and testing the system.
Prototyping with the NI myRIO moved quickly through multiple phases. First, we created simple logic interfacing with buttons and relays to create a control system for the levitation & braking pneumatics. Second, we began integrating analog sensors to monitor pneumatic pressure throughout the hyperloop pod. Third, we spent a few days creating an I2C sensor driver to read Time-of-Flight distance readings accurate to one millimeter. This allowed us to know precisely how high our 1,200 pound hyperloop pod was levitating once every ten milliseconds. When we stop to reflect on this, it is overwhelming to consider that we are engineering students using the speed of light to calculate a small levitation gap thousands of times a minute while building a next generation transportation technology. Fourth, we developed more I2C sensor drivers for Inertial Measurement Units (IMUs), environmental pressure sensors, thermopiles, and power monitoring sensors, all of which can be accessed on our open public github repository.
Figure 3 - The high level architecture of the embedded system, showing LabVIEW running on the laptop as well as on the NI myRIO on the hyperloop pod.
Finally, we needed to integrate all of these various embedded sensors into one system and add a remote laptop control user interface.
Figure 4 - An early version of the Control User Interface which controls the Guadaloop pod
Figure 5 - The power monitoring sensor was one of the first I2C sensors that was prototyped in the system using LabVIEW and the NI myRIO.
Figure 6 - The various I2C sensors for which Guadaloop developed LabVIEW drivers, available on the public Guadaloop repository
Figure 7 - UT pride shown while developing and testing the hyperloop pod embedded control system, based on the NI myRIO.
Figure 8 - Testing the electronics, including the NI myRIO, in a near vacuum. The whole system performed nominally for 30 minutes at 10% atmospheric pressure.
Figure 9 - Laser positioning system by detecting retroreflective tape with LabVIEW code that samples at 1 kHZ on the real-time processor or 10+ kHz if running on the FPGA
Figure 10 - The iPad app Data Dashboard controls the hyperloop pod. Using LabVIEW’s Network Shared Variables (NSVs), we were able to quickly implement dozens of channels of network communication which were hosted on the NI myRIO on the hyperloop pod and could be read and written from the host laptop or from an iPad, as shown above.
Figure 11 - Using Digilent’s OpenScope to troubleshoot I2C line signal integrity issues.
Because we were able to move faster using LabVIEW and the NI hardware ecosystem, we spent more time testing our system. Testing lead to discovering issues, driving improvements, and ultimately a more reliable overall system. At the 2017 SpaceX Hyperloop Competition in Hawthorne, CA, the Texas Guadaloop team flew through the battery of qualification tests while making no major code changes to the robust system. For the next competition, we expect to reuse a majority of this code and potentially upgrade to a CompactRIO, allowing us higher performance, more I/O, new capabilities, and to avoid developing a custom PCB.
Developing Hypersonic Control systems have more applications than just the Hyperloop Project. Being able to achieve such a high rate of performance and efficiency is relevant in all industries from Biomedical engineering to Aerospace/Defense technology. Currently, We are competing the SpaceX Hyperloop Pod Competition III and developing our Hypersonic research Lab at UT Austin, and using NI products to help pave the way!
