Bruin Formula Racing

Data Acquisition and Powertrain Lead, 2016-2017

Over 2016-2017, I undertook many different roles related to electronics. I started off the year in charge of our data acquisition team, but eventually took on overall electronics and powertrain responsibility for the team. This was my hardest year on the team, but I also felt an immense sense of pride knowing that I was instrumental in completing our car.

Data Acquisition

The data acquisition team aimed to outfit numerous sensors on the vehicle to start collecting data on the performance of our vehicle. This included the proposed implementation of accelerometers, wheel speed sensors, steering angle sensors, strain gauges, shock pots, engine data logging, brake pressure, pyrometer data, GPS, and more. In adding these sensors, the team aimed to learn more about our vehicle performance and handling, with an eye towards future vehicle designs. Starting in the summer, I consulted with leads to get their priority list of valuable data to them. From there, I generated a list of proposed sensors. Working with the mechanical design leads, I spent much of fall working on integration of these sensors into their designs. Much of this was modifying existing designs to work with my sensors. Below shows an integration for a shock pot which measures suspension travel: While many of the sensors got mechanically implemented, the electronics side was never completed, as the data acquisition team soon merged with the electronics and powertrain team to work on EFI.

Thoughts on Data Acquisition

I really liked this project as a cross-disciplinary project which combined electronics, mechanical design, and data processing. In the future, some key focus points would be to implement data acquisition more completely on a previous car– it is a lot harder to fully wire a new car with data acquisition when the primary focus of the car is getting it to run at that point. Data on the new car is very valuable, so if it is possible to implement new sensors and actually get them all to work that is a good priority, but from a logistics perspective, it doesn’t make sense for the data acquisition team to be working for 20 weeks on nothing while the car is being finished. This project in the future should be better mechanically integrated into designs as well as prioritized more during manufacturing and assembly. Leads often complain about having no data for their subsystems while also not prioritizing the physical implementation of these sensors. While data acquisition has the potential to be a cross-disciplinary team, my guess is that it will mainly be composed of electrical and computer science majors. Therefore, this gap must be made up on the mechanical subsystem side. Data acquisition is the next huge step of UCLA’s Formula team, and should be a primary focus for the immediate future.

EFI and Powertrain

I joined EFI and Powertrain in various capacities starting in approximately January 2017, continuing on to a full leadership role of Powertrain by late April. EFI and Powertrain were perhaps the longest and most stressful hours I’ve spent on the team. For many weeks, I spent 12+ hours each Thursday, Friday, Saturday working on the engine and related EFI. Many times we worked from 4pm to 4AM, and by 4AM we were cranky, exhausted, and still at a loss for what to do. We had the task of outfitting our new engine, a 2017 YZ-450FX with a 22mm restrictor (in comparison with the 40mm stock intake). We also swapped out every part of the fuel delivery system, as well as added a custom exhaust. All these changes meant that the existing stock setup had to be modified. We initially hoped to use the stock ECU and the corresponding Yamaha PowerCommander tuner. We had tried augmenting the PowerCommander with a sort of piggyback ECU in the form of an Arduino which would modify the existing map sensor and throttle position sensor outputs to artificially increase or decrease throttle, but these changes still didn’t help our engine run well enough. Below shows our vehicle undergoing dyno testing at Church Automotive: It eventually became clear that we weren’t given enough range with the PowerCommander. This makes sense, as the PowerCommander is designed for an amateur racer to adjust his completely stock bike. The PowerCommander could not give enough range for taking the intake and reducing the cross-sectional area by nearly 75%. This decision occurred right after Spring Break, in early April. We then had roughly 10 weeks to redo the EFI from the ground up with the Infinity 3 series ECU we had previously purchased. Thus began an urgent quest, in which we were temporarily behind but also hoping to surpass our existing stock setup. We eventually realized we had to replace our ignition coil, implement a fuel regulator, and other changes to the EFI which we had previously no idea about. We eventually had a lot of tuning help from Church Automotive Testing, who helped us pass a critical roadblock, when our O2 feedback sensor was displaying “lean” fuel conditions even though we were dumping fuel in large amounts. They helped us realize that the O2 sensor had some noise which was causing the error, and the fuel conditions were actually far too rich. We eventually were able to use their dyno, and their tuner Daniel helped us to get a viable fuel/ ignition map. Below shows a picture of the AEM Infinity ECU Software along with an fuel efficiency map:

On the mechanical side of things, I mainly focused on Powertrain subteam organization and parts management. The powertrain team up to that point was fairly large, but also fairly behind. I aimed to implement organization tools ( the return of the almighty spreadsheet!) to help make sure that every part was fabricated, welded, and assembled in a timely manner. I ended up conducting several engine rebuilds during my time on Powertrain. The most dramatic one followed the implosion of our intake. Several glass-filled nylon chunks had been sucked into our engine, and so a top-end rebuild was necessary. Following removal of these chips, the engine was reassembled, and yet the car still wouldn’t start. We soon realized that the cylinder was still not holding good compression. Having already swapped the head gasket, we got some advice that the piston rings likely weren’t sealing. Through 10th and finals week, we took apart the engine again, removed and cleaned the piston rings. We also noticed that the piston rings had likely gotten stuck and prevented from “springing out” possibly due to the intake debris or from poor engine break-in procedure. Having finally reassembled the engine, it was a joyous and exhilarating moment when the car first started again. This was Wednesday of finals week– it was a miracle that we had finished in time for competition. Below shows a render of our engine, derived from a 3D-scanned model:

One of the largest issues with the entire EFI and Powertrain debacle is that there were so many things that could (and often did) go wrong, combined with a severe lack of knowledge. There are so many reasons why an engine won’t run– bad spark, bad ignition signal, bad fuel injectors, bad ECU map– all were options and we didn’t really know how to diagnose each one. The other issue was that, while primarily getting the car to run is a software-based issue with the ECU map, real mechanical problems come into play very often, and the personnel for each were not both always present. This resulted in a lot of cross-disciplinary interaction in which the EE team would be forced to mess with the fuel injection system, and the MechE team would occasionally have to pull out InfinityTuner to make adjustments. Along the way, we also learned that fuel pumps are supposed to be used in conjunction with fuel regulators, and that using alligator clips as the basis of your EFI system is not a good idea.

Lessons Learned about Powertrain

This is really where I learned how to manage effectively. Everything I had learned from working on pneumatics and data acquisition was magnified. I knew nothing, and yet was expected to produce results in a very small amount of time. Tasked with a definitive and yet seeming impossible overall goal, we worked to break down the tasks into easier, more manageable chunks, broken down week by week. Facing a huge time crunch, I also learned how to prioritize, and learned when to take the time to do it right the first time and when to improvise to speed progress along. I also learned much more about people management, as this was by far the worst time crunch I’ve ever dealt with. This is where I felt a bit like Ender from Ender’s Game. I couldn’t let the best members I have burn out, but also had to lean on them hard to get the hardest work done. Weekly mandatory meetings helped keep everyone accountable, and documentation helped us remember what we had learned the night before. One of the key things which really helped– after every late night session we debriefed before we left. This helped immensely with making sure we knew what our plan of action was, while also documenting what we had tried so we wouldn’t try it again. This is also when I was definitely the most miserable on Formula. What kept me going was again the strong sense of duty to my team– I didn’t want to throw away an entire year’s worth of work because we couldn’t get the engine started. I will say, the immense amount of effort put in really gave me an equivalent amount of pride when the car ran.