Building and Testing the Prototype
After 3 or 4 months of redesign work, our final CAD draft to submit to SpaceX was just about finished. The pod that was to be entirely made out of
carbon fiber, moves and stabilizes on polyurethane-covered wheels, propels using a powerful electric motor, and brakes using magnetic (Halbach array) brakes that actuates using a simple pneumatic system.
Designs & Prototype Process
Compared to the last prototype pod, this pod is significantly lighter and more straightforward (although much denser): an estimated weight of 240 lbs compared to the previous design of 1100 lbs and 9 ft. in length compared to 14 ft. This design did not incorporate any sort of levitation, whereas the previous one did and it accounted for the majority of its weight. SpaceX made it clear that this competition, and from here onwards, the winner of the contest is solely determined by the fastest measured speed within the test track, so our design change accordingly– a lighter, high-torque, and simple pod.
Team Design Meetings
During the early stages of the redesign, our team had lengthy but collaborative, bi-weekly meetings to discuss and create prototype CAD models of each subsystem. Each subsystem and its members gathered to create, or re-create, their subsystem in one session. Although unnecessarily lengthy, these meetings allowed instant feedback on designs that ensured subsystems complied with SpaceX requirements and meshed well upon system integration. Here are a few examples of what came out of those meetings:
FEA of our Braking Subsystem, done by our Simulations Team Lead
The braking unit was a modified offshoot of our previous design. There were two key technologies our team was known for: air levitation and magnetic braking. Not many groups tried these technologies, so we kept our design. We were able to properly convince the advisors of our plan with these generated simulations. Unfortunately, I wasn’t heavily involved in this direct conversation with this so I cannot explain further.
FEA of our drive wheel, done by our Propulsion Team Lead
SpaceX’s test track is considerably short in length. It spans as long as the road SpaceX’s headquarters is: Rocket Road. With this much length of test track to “play” with and with the target speed we aimed to achieve, it was undoubtedly a fact that each pod wanting to reach 200+ mph will have to begin a considerable amount of torque. With this in mind, our drive wheel will need to sustain a substantial amount of stresses. Our propulsion team was assigned to design a wheel that can meet our torque requirements–the maximum torque an Emrax 228 can generate (if we can also produce the instantaneous power required to achieve this).
CFD analysis of our fairing traversing at our target speed in a low-pressure tube, done by our Pneumatics (and Fluidics) Team Lead
With this information, our team was able to make sure design modifications that would give our pod a competitive advantage. It also allowed us to provide our competition advisors the information they needed to verify our team was aiming to manufacture a prototype pod is feasible and compliant with the Hyperloop competition rules.
Determining structure thicknesses, i.e., figuring out the optimal number of carbon fiber sheets to use
Testing rig for our electronics and control software. This used a simple electric motor, pneumatics, friction brakes, and various light indicators.
Plenty of small prototypes were made of various subsystems were created to verify the design, e.g., structure thickness and control logic of our pod’s behavior. These prototypes gave our team confidence to create a fully-scaled design and allowed each subsystem to think about any boundary conditions and account for any design quirks that arose when data was obtained during testing.
Once our team got the “OK” from our advisors, accumulated the funding, and grew enough confidence on each subsystem, manufacturing of each system began.
Skip ahead about 1-2 month, and our team is buried in the manufacturing phase. There is a lot to be made: structure, containers, electronics, stabilization units, drive train, braking unit, pneumatics, and software.
The fairing and battery container (pressure vessel) were both made in-house with the help from our sponsors, and our structure was outsourced to our sponsor [CMI” src="http://www.carbonfiber.com). Because of our choice in carbon fiber everything a custom mold was required for nearly every component, each of which we had also created and cut ourselves.
After months of engineering design and verification, and back-and-forth with our advisors, our team, pivoted to, manufacturing organization. It was during this time when our team quickly grew in size–we needed all the labor help we could get.
We created a simple “to-do” list on the largest whiteboard in our lab, so when you walk in you know exactly what was to be done and lead by whom.
The Pressure Vessel
Gluing foam together for our battery container (pressure vessel)
Freshly cut foam via CNC for our battery container
A lot of time was spent gluing foam together, mainly for our fairing. We had to fix foam together to be as tall as our component and fit within the CNC machine we used. Our battery container was relatively simple since it was mainly a box. We made 2 halves of molds for the box.
Resin infusion of our pressure vessel
Why 2? Why not reuse 1? Well, because our initial method was to use resin-infusion to adhere carbon fiber layers together, and this method permanently destroys each mold–so we made one for the top and bottom halves of the box. However, after our failed initial attempt and limited resources, we switched over to the carbon fiber layup method (not pictured). We had connections to alumni to help guide us to layup the box in-house. We were also going to use the same approach to create our fairing anyways.
Our finished fairing, and a view of the giant foam mold we created for it on the right
Our fairing ended up being very different from our initially planned design. We needed to simplify the fairing because we found our initial design required multiple intricate mold cutouts, of which we did not have the resources to precisely cut at the time. So, we redesigned the shape. Since we were designing for travel in near-vacuum conditions, where aerodynamics doesn’t affect speed as much as other factors, we determined that changing the fairing shape wasn’t a risky decision.
The structure couldn’t have been made in-house because of its complexity and the tooling required to make it. We decided on a carbon-fiber “sandwich” structure, i.e., carbon fiber with a special foam in between. This choice was made to increase structural strength.
A view of our finished structure’s carbon fiber “sandwich”
The process and planning of our structure and collaboration with our sponsors took us longer than expected–it had to be correct on its first attempt due to our timeline. The process of making the mold, then laying up the carbon fiber and incorporating the foam was inherently long. We also needed to create the required holes and cutouts in the proper areas.
I knew this was going to be our team’s bottleneck within our plan because even if each subsystem completes their subsystem early, they won’t be able to verify or test without a structure to mount components on.
A view of our workspace outside where we buffed and polished our structure (shown on the left)
Although stressful, our team was able to follow the planned timeline thanks to our sponsor’s help and collaboration. We finished off the structure with some buffing and shining to maintain appearances for any passerby during competition and potential press.
A fully completed part of our stabilization unit, as well as its manufacturer in the background
I didn’t have too much involvement in the design and manufacturing of our stabilization subsystem, so I can’t say much. However, the information conveyed to me is that “it was way too difficult to create, but doable given the right tooling.” A lot of redesigning occurred throughout the manufacturing process because of the many intricate pieces. There were 4 of the shown pieces to be mounted on the pod, and this isn’t showing the many nuts, bolts, springs, and bushings required for the subsystem.
We learned from the last design that electronic and software debugging took a large chunk of our team’s timeline within each competition. Complications within this subsystem were always encountered during testing week, and having perf-boards and breadboards of our electronics were never a good idea to have in our final design.
So, I assigned the subsystem–including myself–to create a simple 2-layer PCB that consolidates all low-power electronics and sensors and distributes all of its I/O to the controller. With the help from our electronics subsystem’s sponsor, Altium, we were able to sketch multiple prototypes of the PCB board quickly, generate multiple BOMs to estimate cost, see the final design using 3D CAD, and create all the Gerber files our chosen manufacturer would need. This allowed us to make not 1, but 3 prototypes before our final design choice in 2-3 months–and this is including the time to manufacture the PCB.
Honestly, after using their PCB design technology, I find it really hard to adapt to their competitor’s technology. Our team, including myself, had little to no prior PCB design knowledge when tackling this task. Altium was really easy to learn due to its extensive documentation and countless youtube video tutorials created by other contributors.
I go in depth on this design in another project post you can find here
Drive Wheel (Propulsion System)
Our completed the propulsion system, e.g., drive wheel, being tested alongside our electronics
I’m going to skip ahead quite a bit, up to the point where our drive wheel subsystem, its holding fixture has already been built, and obtained our desired electric motor, inverter, and the batteries required to use it properly. This sounds like a lot, and it is, but most of these components are COTS. COTS makes a tad bit more comfortable to use since there are forums online to help us out, but it’s constrained. In this picture, you see our electronics, power, and propulsion subsystem all integrated and being set up to be tested. We needed to ensure to us and to our advisors that we can control our motor with specific behavior and provide data of our system’s maximum capability. Most of this is done during Testing Week, but verifying this beforehand makes Testing Week go much faster (and thus quicker to get into the test track).
Is it even engineering if you’re not testing?
Propulsion System (and Electronics)
Propulsion System testing
Test. Test. Test. And more testing. Our motor was being controlled with a COTS inverter by Emsio. This inverter, we found, is a highly respected company within the automotive industry–and will concur with the majority’s opinion. The inverter communicates on CanOPEN for digital control and provides data acquisition capabilities through its other serial ports like RS232/RS422. It also provides a (somewhat) detailed document explaining how to set up and tune the motor before its field use.
As a TL;DR of its documentation, setup is done via a CANopen debugger tool (CanOPEN to UART Serial USB) to setup PID parameters, CAN Bus clock speed, addresses, safety parameters, and then connecting few potentiometers to its 15+ pin connector to begin verification. What you see in the video is one of our Electronic and Control’s engineers and I testing analog control of the motor via a potentiometer. It’s failing to turn direction because of the low overcurrent limit we had placed, and the required torque needed to rotate the other direction required a more considerable amount of current.
After we got the hang of adequately controlling the motor, we went ahead and started tuning the PID parameters needed. We used the Ziegler-Nichols method to start looking for good values and wasn’t too bad after a few tweaks. Below are a few charts we had obtained during testing of proper PID parameters:
Cyclic Cycle Testing for Viewing Torque Control
Target Velocity Testing for Viewing Velocity Control
We never tuned for target position, because we didn’t need to. What we were aiming for were proper PID parameters for target torque for fast rise times and minimal error, since our pod needed to deliver nearly high and instantaneous torque at starting position.
Our Power Systems Lead and Lab Manager setup a rig for battery testing
For a while, I was honestly wondering, how on earth to we test our Hi-C batteries? To which, our lead essentially answered: “just use a bunch of power resistors in parallel.” He was right. Simple, easy, cost-effective. We needed to get data that tells us how well our batteries performed: heat generation per constant amperage, how quickly each pack dissipated its charge, recharge time, and what voltage did each battery level off at its percentage charge. Our team did so many tests, but sadly I currently do not have the records to show them all.
But was it all safe? Yes, but the way we did it was–to me–no so much. More precautions could have been taken, but we weren’t all that “unsafe.” We never did testing with just batteries and power resistors. We were well aware of the dangers of working with Li-Po batteries, i.e., uneven discharging/charging, keeping cells at a low charge for an extended time, and load balancing.
We always used a battery management system–there was no way on Earth we would have tested without one. On top of that, we always carried a Class D fire extinguishers ready for use in case of any chemical fires.
On top of battery testing, we also needed to see how long each our inverter will discharge (from 450 V). The inverter uses very large capacitors to hold the charge, and its data sheet mentioned it takes nearly 30 minutes to discharge them to near 0V (which our advisors needed to ask for). Needless to say, the datasheet was correct.
IMU integration stationary drift
For navigation, we relied on our IMU and integration methods to determine the distance traveled and speed met. Because of our choice, our navigation would experience drift–motion when there is no motion present. This is a well-known problem. Typically one obtains a high precision IMU, use other control-navigation methods like Kalman filters, or use different means of measurements to “double-check” speed and distance like encoders on wheels. We had a high precision IMU, so the drift encountered was reasonably insignificant for the estimated time of our full run.
This piece took longer than expected. I want to keep each piece under a 15-minute read so I will end this one here. Thank you for following along! I’ll be writing about our final assembly process, verification methods, the actual competition and where HyperXite is at currently in the next post.
Also, here a few early sketches of what the pod would have looked like. 😄