The HyperXite III Team

# HyperXite 2018 | Prototype Hyperloop Pod (1/3)

Looking for HyperXite? Find them here!

I owe a lot to this team for many of the things I know about engineering. It’s been a few months since I’ve been active with UCI’s Hyperloop Team, so before I forget the details of my experiences, I figured I’d write about it. I was initially going to write this as a project piece but felt I can better detail the “Hyperloop experience” in blog-like posts.

I split this piece into 3 posts. The goal of each piece is to give insight to those unaware of Hyperloop, and it’s current status, the SpaceX Hyperloop Competition, and my experience being involved with UC Irvine’s Hyperloop team for nearly 2 years.

## The Hyperloop

To those living under a rock and don’t know what Hyperloop is, in a nutshell, it’s a sort of fusion of high-speed rail and aerospace technology–the proposed 5th mode of transportation–where a pod carries passengers through a vacuum tube at speeds higher than the speed of sound (a feat even commercial airplanes have difficulty achieving).

How? Well, a considerable factor preventing planes and trains going 700+ mph is air. Nearing the speed a sound wind starts to behave like a brick wall. So, eliminate that from the equations, and you can necessarily “break” the sound barrier easier than a high-speed train could.

The Hyperloop is said to be able to travel to-and-from LA and San-Francisco in 1 hour ( 30 minutes 1 way) and would cost less than a plane ticket, but more than a train. Crazy, right? Of course, I’m grossly simplifying, but this is the gist of it. If you want to really know more have a look at the official Hyperloop Alpha Whitepapers.

## The Hyperloop Competition

### The First Competition

The Hyperloop Alpha whitepapers gave the public a sort of a baseline design of what this new form of transportation can be. Many people, more specifically universities, took notice. Soon after SpaceX hosts a sort of competition amongst Universities around the world to see who can propose a feasible and scalable Hyperloop design. This competition was considered the 1st competition.

The competition was purely pen-and-paper: no actual manufacturing of a pod was required. Hundreds applied, only a few followed through. UC Irvine competed and won 5th place out of more than 100 teams around the world.

The competition became so popular SpaceX decided to push this further and hold another competition. This time, however, manufacturing of the pod is required. The rules? Hardly any. Find your own funding, own team, own resources, and design your own pod for SpaceX’s (almost) mile-long vacuum-tube test track.

### The “Actual” Competition

I know I mentioned there were hardly any rules, but let me point a few obvious ones:

• The pod must survive in low-pressure environments
• The pod must able to safely start and stop within the length of the test track
• The pod must be safe to handle
• The pod must be able to communicate with a base station
• The pod must aim to be fast
• The pod must be safe to handle

There are more, of course, but due to an NDA I have with SpaceX, and The Boring Company, the disclosure of specific technical competition rules, pod-design criteria, and details of SpaceX’s vacuum tube is prohibited.

## HyperXite II: The UCI Hyperloop Team and The Controls Subsystem

I joined the team late in the Spring quarter of 2017 as a Controls subsystem member. The team was in the process of changing the pod’s design and was looking for members to help redesign their controls and electronics system.

The team obtained a PLC and, though it met their initial requirements, they underestimated the amount of effort it would take to utilize it’s potential entirely. It was a fantastic controller, don’t get me wrong, but even I didn’t anticipate the significant issues they could possibly encounter during the testing and verification phases, e.g.:

1. The controller wasn’t vacuum-compatible, so a large pressure-vessel was made to contain it
2. The controller added a lot of unnecessary weight
3. The programming wasn’t intuitive (and still isn’t)
4. Wasn’t easy to change the code for quick prototyping and testing

The lead of the Controls subsystem was looking for people that had background working with a PLC or embedded systems that used Arduino/Raspberry Pi/Linux, general software development, sensors, and autonomy (state-machine).

I wasn’t too familiar with PLC but was familiar with the latter. A friend of mine had joined the team before I did, and through him, I made my way in by recommending me to help migrate away from PLC.

I can go in depth about this team, but to keep this post within the scope of 2018, I’ll generalize the 2017 HyperXite year:

• Began searching for MCUs to replace the PLC
• Found and worked with the BeagleBone Black
• Lead to the team to implement a robust state-machine using the CompactRIO using LabVIEW
• Ensured vacuum compatibility
• Redesigned the electrical system
• Successfully proved our state-machine at SpaceX
• The team got 3rd place at the 2nd SpaceX Hyperloop Pod Competition 🎉

The use of a CompactRIO made it easy to test quickly, measure, and prototype electronics and software. Another member proposed its use because he had some experience with it in high-school robotics. We looked into it and met all of our requirements. Most importantly, it survived near-vacuum conditions (after testing it), and we didn’t have to worry about building a detailed GUI since we just needed quick prototyping.

Much like the PLC, programming was done through “block-diagram” programming with LabVIEW and the LabVIEW Real-Time. Though it didn’t support version control, the language was simple, and the CompactRIO provided all the interfaces we needed. I’d like to thank National Instruments for their help.

Below is footage of our open-air run inside the test track! The loud hissing noise is the pod levitating on a thin layer of air (air-bearings), and at the end, you can hear us cheering in excitement when our controls operator confirmed that the pod has successfully stopped on its own command.

View the official SpaceX Hyperloop Recap of this Competition here.

### New Role

Traditionally, in HyperXite, there has always been a Team Captain.

The Team Captain had the following duties:

1. Communication with SpaceX advisors as the main point of contact
2. Relaying new competition information to the team from Hyperloop competition officials
3. Ensuring pod meets competition design specifications by Testing Week
4. Facilitating general and lead weekly meetings
5. Communication with business sponsors to obtain funding and resources for the team

Other duties include:

1. Ensuring the pod design and HyperXite members achieve the MAE Senior Design milestones
2. Attending MAE Senior Design meetings
3. Communication with University faculty members and advisors
4. Attending and facilitating interviews with potential new members

Given my reputation of successfully leading the Controls & Electronics subsystem, I was asked to spearhead UC Irvine’s 2nd prototype Hyperloop pod for SpaceX’s 2018 Hyperloop Pod Competition as its Team Captain. So, as of the summer of 2017, Team Captain duties became my duties. 😅

An important thing to note: if you know me, I graduated UCI with a degree in Electrical Engineering. This major falls under the EECS department at UCI, and what I failed to realize before taking the position is the entire HyperXite project falls under the MAE department. This quickly became an issue, because each department has it’s own respective “senior design project” and the EECS department required its majors to follow their separate curriculum.

Because of this, I decided to share these duties with a fellow colleague as Head Engineer, and their’s: project manager, since I would mostly be doing 2 senior projects. Was this a smart idea? In retrospect, sort of. ¯\_(ツ)_/¯ I didn’t have as many responsibilities, but it got confusing when it came to final decision-making.

## HyperXite II

At UCI, HyperXite is known as one of the larger Senior Design Project teams. It’s on par with UCI Rocket Lab, UCI Design-Build-Fly, and UCI Anteater Racing in terms of team size. The 2018 HyperXite team had over 50+ undergraduate members by the end of the academic school year, 1 graduate advisor, 1 faculty advisor, and more than over 30+ alumni connections. We were the 3rd iteration of UC Irvine’s Hyperloop team (though we know this is the team’s 2nd major design iteration), so we felt best to call the team HyperXite III.

Our team’s mantra was the following:

Design, manufacture, test, and validate a prototype Hyperloop pod that will show the efficiency and power of electric motor propulsion, magnetic braking, autonomy, and to help showcase a new method of transportation–Hyperloop.

We organized ourselves to have the following departments: Management/Steering, Mechanics, Electronics, Structures, and Operations. Each department had its respective pod subsystem that aimed to meet each Hyperloop subsystem design criteria. Also, we felt it necessary to have Simulations, Documentation, and Outreach teams to verify engineering design and support the 40+ member team.

Team Description
Management Manages logistics of the entire team including documentation, finances, outreach and fellow team members
Outreach Uses networking, sponsorship management, event organization, marketing and advertisement as well as community outreach to promote and sustain the HyperXite team and pod
Operations Responsible for the team’s operations which include processing, manufacturing and special projects.
Mechanics The mechanics subsystem ensures and maximizes the safety and speed of the pod by integrating a high-end electric motor with proper liquid cooling systems, and creating a high velocity braking mechanisms.
Structures The structures team is responsible for designing a modular structure, improving the pusher interface, and designing new stabilizer wheels for the HyperXite pod
Simulations The simulations team uses different softwares to simulate the behavior of the HyperXite pod to ensure safety and success
Electronics In charge of controlling the pod’s autonomy, sensors, Controls and Power Systems
Documentation We plan and direct the preparation of project documentation such as engineering drawings, experiments and tests, design packages, and bill of materials. We work closely with the project manager and system engineers to monitor and ensure the progress of the project.

## Planning and Funding

Prototypes shouldn’t be expensive, but if you’re trying to compete with teams from around the world who also have university and industry backing it can easily be. From last competition, prototype Hyperloop pods were nearly complete products. It was both intimidating and inspiring.

The competition process is nearly 9 months long–well under 1 year. Within this time-frame teams are expected to obtain their own funding for internal prototyping and testing, material, access to machines or labs, and transportation. I let rest of the steering team handle the financing of these, while I and another dealt with the budget for the pod itself.

Learning from last year’s competition, we asked each subsystem lead to coordinate with their team and search for parts and services they would think they would need. I then came up with the following initial budget estimate:

Subsystem Cost Estimate
Braking $4,7920.40 Controls & Telemetry$14,347.53
Cooling & Pneumatics $2,103.00 Power Systems$14,168.84
Propulsion $20,084.00 Stabilization$32,046.90
Chassis & Fairing $38,700.00 Pod$126,242.67

Our Braking and Pneumatics subsystem estimated they would cost the least because we would be reusing many of the components from the last competition’s pod design.

In previous competitions, the team did not have a Propulsion subsystem. The reason being: SpaceX provided an optional “pusher” vehicle to propel the pod up to speed, i.e., the pod did not have to drive itself. Because of this, the initial pod design levitated on air-bearings and had the pusher put it up to speed. In this competition, SpaceX took this option away and thus required teams to develop their own method of propulsion.

The other subsystems were estimated based on what each team anticipated spending to get the parts and services they needed if paid in full. Like most teams, we didn’t need to buy everything. We approached companies to help sponsor our team with either cash, products, or services–or any combination of the three. Without their help, UCI HyperXite would have never achieved its current status. So, if you’re a previous (or current) sponsor reading this. Thank you. Truly.

Controls subsystem had an initial design during this phase. Learning from last competition, I instructed our controls lead to obtaining a rough initial design of how the software and sensors should be laid out. Looking at the state diagram, you will notice that there is no “coasting” phase between “push” and “brake,” meaning that at no point our pod will ever cruise. If we allowed cruising, then we would limit our pod’s full acceleration potential. In a competition about speed, this decision is a no brainer. I’m sure other teams thought of this as well.

## Communication and Software Tools

Our primary form of communication was through Slack and Google Drive. There we would have channels for each subsystem to discuss and share small files. On Google Drive, we would put our essential data, like CAD files, source code, documents, and presentations. And thanks to TeamGantt © and Teamline © (was BusyBot) we were able to integrate project management into our workflow seamlessly.

I’d like to end this piece here. I will describe the full engineering process in the next post, from initial design to prototyping, all the way through manufacturing and verification at the SpaceX competition. 🙌

For the curious and impatient, take a look at the following attachments showing what Pod III ended up becoming 🚀 and some snapshots of the HyperXite II team.