Arrivo

DON’T LET EARTH SUCK (ARRIVO’S MOTTO) Arrivo was a transportation start-up aimed at solving the problem of traffic. I worked as a test engineer helping design multiple test stands for new motor topologies.

Working at Arrivo was my first exposure to ‘High-speed’ engineering. It was sink or swim with a lot of new software & design practices. For example, the “Lev Rig” required me to learn LabVIEW from scratch. This wasn’t some simple code that could be copy pasted from demo project, but required custom closed loop control, high data acquisition rates, and multiple fault conditions. I spent multiple nights at the office, running trial and error testing on my code not only to get it to work, but also understand for myself the intricacies of LabVIEW.

Luckily I was able to see multiple projects from start to finish at Arrivo. This included test items and demo pieces like the LANDSPEEDER, which was demo’d at Jeff Bezos’s M.A.R.S. conference, and the Static Motor Rig V 2.0.

STATIC MOTOR RIG V2.0 This project is what I consider a true representation of where I am at as a Test/Mechanical Engineer. Everything I learned from the Lev Rig, the Landspeeder, and the other projects at Arrivo helped me turn the SMR V2.0 into a clean, optimized, and well-budgeted test fixture. I can proudly say I was the lead on this project and consistently delivered on deadlines to the point where my boss was completely hands off.

THE REQUIREMENTS: The SMR was a test bench I had to design to hold two new motor topologies envisioned by Arrivo’s power-train team. In a conceptual design review, i got a list of 1) What dials did the power-train team want to turn? 2) What values did they want to read? This gave me an idea of exactly how I needed to be able to control the SMR and what sensors I needed to place to survey the test. The SMR would not just be stationary, but was required to move the new motor in 3D space & record the forces of the motor in all phases against the wayside. The sensor suite required Hall effect sensors, air gap sensors, piezoelectric load cells (selected because of a trade study I conducted about stain vs piezo in magnetic fields), encoders, thermocouples, and accelerometers. All of this would be controlled by a National Instruments Compact-Rio & accompanying LabVIEW code. Along with the sensor data, I was required to communicate the motor driver/controller with commands & polling.

THE DESIGN (MECHANICAL): Mechanical design didn’t take too much time, the power-train team and I just needed to agree on a common mounting point, from there I was able to design around the motor and the wayside. The fixtures were going to take on very high loads in various axis. One of the major problems was finding not only a piezo load cell large enough for our system, but one that could take the amount of torque the motor was going to produce. Another challenge was designing the servo motors & their motion around the already tight space that the power-train motors were taking up.

A couple iterations later & the design was able to pass all the load cases with our selected factor of safety. Even better was that our modal analysis showed no need for redesign since the lowest mode was twice as high as the frequency we were going to operate the motor at!

With the design and analysis complete I presented to both R&D and Power-train teams, walking away with the O.K. to move forward with purchasing & building.

THE DESIGN (CONTROL): As parts and materials were being shipped in, I started on the LabVIEW code. One aspect that I wanted to make sure was that my code was “Crumpler proof”. Back when I was designing the Lev Rig, I had the code in a state that worked for me, but with a few misclicks here & there, my boss John Crumpler was able to bring my working Lev Rig to a complete standstill. I wanted to make the code for this coming SMR able to be operated by anyone in the office without prior instructions. I wanted a clean state machine with very linear operations.

One problem with the original SMR (built when I was still finishing up at Sacramento State) was the repetitiveness of the testing. If we wanted to run a test with a range of currents, we would have to manually put in the new current values every single test. With this new code, I created a iterative testing function which automatically ran the next test giving that all the proper safety conditions were met. That way if the Power-train team came up to me and asked, “Grady, can you test the ramp-up rate at different voltages on the new controller we designed?” It would be as easy as setting the lowest to the highest value, setting the intervals, and then hitting run!

Along with the LabVIEW I also created code in R to read and decipher all the .TDMS files that came from LabVIEW. Let me state for the record, I am a HUGE fan of R Studio and will take it with me for the rest of my career. The code would allow me to take the gigabytes of data (we were recording at 25 Ks/S!) and tweak filters values to automatically get graphs that were easy to digest and understand.

THE BUILD: As the parts came in I was working with the techs in the shop to help machine the custom parts, drill & tap all the connections, and grease the linear carriages. The biggest wait was getting the table welded and Blanchard ground. We needed these motors so precisely parallel to truly understand the physics behind the design. With a designated build space (something I didn’t really have for previous projects) I was able to do all the cable runs and wiring exactly how I wanted it. All power components were separate from all data connections to reduce noise. Every single wire was zip tied and strain relieved. I was quite happy there was no rats nest of wires.

Even though the Power-train team was never able to deliver a final product before the company shut down, I know I built a test fixture with solid design principles and the code to make testing run clean and smooth.