Crossing Boundaries: My Experience of Working in a Multidisciplinary Team and the Lessons Learned

One thing that I have been told many times throughout my academic career is that the real world is nothing like the classroom. At first, I always thought this just meant the mannerisms or environments would differ. It never occurred to me that the work that I was doing every year for the past four years was ultimately an unrealistic image of the work required by the real world. It never occurred to me just how sheltered and bubbled my work experience in academia was compared to the real world. It never occurred to me until I had to participate in the Shiley School of Engineering Capstone Project. For my capstone project I joined the NASA Lunabotics multidisciplinary competition team. For the first time ever, I have had to work with people in different fields. I had to face a multitude of new problems and I had to think very differently if I wanted to be successful. For this talent competency paper, I will first describe the NASA Lunabotics competition and summarize what is expected of the competitors. I will then discuss the challenges I faced while participating in this competition as well as my personal experience with the construction process.

NASA Lunabotics is an annual competition sponsored by NASA to help future prospective engineers learn about the entirety of the engineering process and the difficulties and expectations that exist within our fields. To teach these engineers, NASA Lunabotics requires us to build a lunar rover that is capable of navigating and mining on a lunar based simulated environment. In this competition, we must create a rover that is able to successfully drive in a lunar environment, it must be able to dig and collect materials in this environment, and the rover must follow other constraints such as size and weight limits. In addition to creating the rover, teams must also write and submit design reports and even hold a presentation updating NASA officials about their progress. The competition itself grades the competitors on factors such as how much material was collected during mining, how much automation does the rover have, how well were the design reports written, along with other factors that encompass our rover’s ability perform. My team consists of four mechanical engineers and two computer scientists. In this project I had to help with the electrical engineering and the mechanical engineering processes. In this competition I could not afford to stick to my own field; I had to venture into other disciplines. I had to help create the circuitry for the rover and I had to work with the mechanical engineers on their designs to ensure that I could program what they wanted correctly. This competition has put my team through the entire engineering process that is expected of actual engineers working at NASA. This capstone project provided me with my first opportunity to work with others from a different discipline let alone my first time working on such a large and complex project. This process, beneficial as it is, has made me face brand new challenges and has tested my limits as an engineer.

A multidisciplinary project that makes students go through the entire engineering process of a NASA engineer forced me to face new problems and experiences that I have never faced before in my entire academic career. One of the first new experiences that I faced was how rigorous the design process is. Before, in academia, I never had to write multiple reports and create such large plan layouts for any project that I participated in. For the competition, my team had to write reports detailing the design process, the risk analysis, scheduling charts, and other important information. Even though this work was grueling, it was an eye opener for me. Because we wrote all these reports, because we planned for all these scenarios and tests, my team was able to build our rover in a timely manner without running into major issues. This long design process forced us to find all the potential errors with our design, it forced us to think more about the future and how we would progress, and it made my team much more successful than we would have been without this process. Another challenge I faced in this competition was that it presented me with the first time I have ever had to really work with other disciplines. While programming in my academic career, I would always assume the mechanical side would work perfectly and the only thing I cared about was the software. However, in this competition I could not be ignorant of other factors, I had to pay attention to the mechanical details, and I had to constantly account for new factors. One good example of these challenges was my inability to program for a large majority of time while the rover was being built. It was impossible to write and test the code because once finished, the mechanical systems could completely change the way the rover worked. This conundrum was a brand-new experience for me because I’ve never started a project being unable to do my part for such a long period of time. To get past this challenge, I had to step outside my comfort zone, and I had to help the mechanical engineers with their design and creation process. I had to design and create circuity for the rover, something I have never done before. Even after the mechanical engineers finished the major systems, I was still facing new challenges. For example, I would code software that would theoretically work perfectly, however external forces such as friction, weight, and small mechanical errors would render my code useless in certain situations. I had to consider all these possibilities, like accounting for friction and margin of errors with motor articulation, and program my solutions around these possibilities. These solutions weren’t all software either, for example, I helped develop a solution using encoders to track our wheel’s current angle. By using this mechanical and electrical feature, we were able to help prevent a major issue with the wheels splaying as the encoders would let the rover know when to fix its wheels’ positions. This experience expanded the way that I think, and it made me consider new approaches to different problems.

While building this lunar rover, I was able to experience firsthand the construction process for a project as ambitious as this one. The construction process being simply the set of steps needed to slowly construct our entire project. My experience as a computer scientist with this process was very different from the mechanical engineers on our team. This was because I couldn’t do my job until they finished their job. The mechanical engineers had to design each part, they had to go to the machine shop to make a prototype, then had to test the prototype, make any necessary changes, manufacture the needed parts, and then finally install the parts into the rover. This was a long process, and my job was very dependent on how the rover would function once the parts were installed. Instead of waiting months for the rover to be put together, the computer scientists on our team were able to create our own miniature rover prototype that could be used for software testing purposes. This rover, named CHARLIE, was just a simple small rover with a resin base that was meant to fundamentally mimic the main rover. With CHARLIE created, I was able to start programming code and testing it on this miniature rover. CHARLIE allowed me to gain a better understanding of the challenges, and ultimately the solutions to these challenges, of programming the main rover. The idea that I would have to make a brand-new rover just to program and test my code was unbelievable to me. Out of everything, this experience shocked me the most because it taught me that creating something like a rover requires you to create many other tools that can then be used to finally make the rover. Instead of seeing the project as one big system, I started to see it as a collection of hundreds of mini systems. Reflecting on my experiences, it felt as if I spent very little time programming the main rover but instead, I spent more time constructing and programming tools that would help with programming the main rover. The idea that more time is spent on building these tools rather than building the main rover was mind blowing to me, but it also made a lot of sense. It was like we had to build a rover out of Lego blocks, except we couldn’t buy Lego blocks. Instead, we had to design a mold and create our own Lego blocks. Once created, we could finally put everything together. It makes sense that designing and creating the blocks would take more time and effort than simply connecting these blocks together. I think this idea that the product is simply the accumulation of a bunch of tools is one of the more important lessons I learned from this experience because it taught me the value of making these tools and how finishing a giant project isn’t just one or two large steps, but rather the accumulation of a bunch of tiny steps.

My grand challenge is “Engineering the Tools of Scientific Discovery” and participating in this NASA Lunabotics competition was quite literally the best way I could have learned more about what it means to engineer these tools. This entire competition was for my team to engineer a tool, like a lunar rover, that could then be used to further scientific discovery. Because I had the opportunity to participate in this project, I was able to further my understanding as an engineer. Being part of a multidisciplinary team forced me to face unique adversities and challenges. It taught me how to think differently and how to come up with unique and creative solutions. To participate in this competition, I had to learn new skills like wiring circuitry, I had to learn more about the mechanical aspects such as finite element analysis and factors of safety, and I learned the importance of making new tools to help further your progression. I can say without any doubt in my mind that participating in this competition has led me to become a better engineer. Working with others from a different field, working with new ideas and processes, has made me grow more as an engineer and as a person than any other academic experience I’ve had in the past four years.