Rocket U UAS Competition Series: Team Aero-M
As a late entrant to the Rocket U Unmanned Aerial Systems (UAS) Competition, Marshall Space Flight Center’s “Aero-M” team brought a competitive edge with their hexacopter.
Never one to turn down an opportunity to work with bright, young engineers, Jim Snoddy, a Marshall Space Flight Center staff member in the propulsion systems engineering division, jumped at the chance to serve as Aero-M’s team mentor. As applications to participate streamed in from early-career employees across the center, Snoddy identified a team of young professionals who demonstrated a keen interest in learning, were at the right point in their careers, and had the right experiences to contribute to the competition. This is how Snoddy met Adam Kimberlin, a twenty-six-year-old propulsion engineer, who he tapped to be Aero-M’s project manager.
Kimberlin wasn’t the only one stepping into a new role. Other team members included Tiffany Russell (vehicle subsystems), Garrick Merrill (avionics), Chris Becker (ground station operator), Peter Ma (ground station operator and systems engineer), and Robert Parker (backup ground station operator who handled all of the check-out procedures during the day of the competition).
(Editor’s note: The following are excerpts from an interview conducted with a Marshall Space Flight Center team member and mentor. Some of the content has been edited for clarity and readability.)
APPEL News: Adam, prior to the Rocket U UAS Competition had you ever managed a project like this before?
Adam Kimberlin: Goodness, no. I’ve only been at Marshall for three years. I’m only 26 years old. I work in a research and development lab where we don’t really have many projects come through that require this type of organization and effort. We do a lot of small-scale subsystem testing, so this was definitely out of the norm compared to what I do for my day job.
APPEL News: What was the first thing you did in your role as project manager? Give Jim a call?
Kimberlin: Yes, definitely talking to Jim and going through his pointers and lessons learned.
Jim Snoddy: We probably spent the first week or two going through every project I’d ever managed. I told Adam what I thought we’d done well and what we’d done poorly. Stay away from this. Do this. Be ethical. Be legal. Work hard. We laid out some ground rules. When I started project management there was no such thing as 7120. We wrote those documents as we started—I came to NASA after Return to Flight on Challenger and we had to build everything back up from almost scratch. We learned a lot of the lessons and it’s neat to show Adam and the team what we’ve been doing going back through 25 years of history.
Kimberlin: In addition to going through Jim’s notes, one of the first things I did was go through some of the project management and systems engineering documentation that NASA has. I came to the quick realization that this is way too much for what we were trying to do. Figuring out how to scale it to where it was appropriate to our effort was probably the biggest thing that I wanted to accomplish right off the bat. I went to some of our systems engineering groups that we have here on post that do some smaller projects and kind of took their model. I was happy to find out that what we were doing was very similar to what they were advising, and it all just kind of fell into place from there.
APPEL News: Why did your team choose a hexacopter for your vehicle architecture?
Kimberlin: Before we jumped in and picked a vehicle, we did big systems studies to see which architecture would be appropriate for the RFP (request for proposal) that was given to us by the competition organizers. In a real-life scenario, it would probably make more sense to go with something like a plane, but given the constraints that we were provided by the competition organizers we decided to go with the “hex” for several reasons.
One was for the ease of being able to easily test it. We could fly it inside here at Marshall and get a lot of the bugs in the system worked out without having to risk an entire vehicle. It was really modular, so if we had any problems, it was easy to swap out parts. If things broke, we could fix them pretty easily—and we had a lot of stuff break. (We have a “bone yard” of parts that are no longer usable in the lab.)
Our decision really came down to a stable platform, really easy to test, and it was also cheap. We used a lot of off-the-shelf hardware and software that was readily available, which gave us a leg up so we didn’t have to write our own pilot software—although, we did tweak some of it to make it work for our applications. All of the image recognition was homegrown software here at Marshall.
Snoddy: The competition had what was called a request for proposals, which had a set of requirements in there. So you knew what you were going to be judged on before you ever created anything. That’s the good thing—ninety percent of your answer is done the first day you pick something. The day you pick it, all your solution sets go away. So if you don’t pick the right thing on day one, three years later you’re trying to make something work that you never really thought through.
The point of the APPEL-Rocket U UAS Competition was to teach project management and systems engineering. If you didn’t go through the mission concept review, you kind of skip the most important step. I thought the team did a very good job of going through and adjudicating the requirements and saying, hey this will do this, but it won’t do this, but it’ll give us the most points to win the competition. How you do your mission concept review, how you do your practice run before you go build the thing is critical. They did a fabulous job doing that.
Kimberlin: And just for the record, we were on the ragged edge between a plane and a hexacopter from day one. We had our big worksheets, essentially trying to take qualitative attributes for each vehicle type and try to quantify that so we could actually generate scoring criteria to help pick which vehicle we’d use.
Snoddy: That brings up another good point. They were kind of forced to write a project plan before they’d done the project. I know a lot of people get to a Preliminary Design Review (PDR) and they say, hey, we should write a project plan. The team had to write a project plan before they started, then go implement the plan. Obviously it’s going to change as you go, but they were very methodical about accepting a lot of the things people don’t do, which is do the hard work first and then start executing the plan.
Kimberlin: And one of the lessons learned that we generated and wanted to convey at the end of all this was something that Garrick kind of coined the phrase to, he said, “Plan now or fail later.” A lot of credit goes to Garrick and to Peter for getting all of the planning knocked out on the front end of it because it made it a lot easier on the tail end.
APPEL News: What was it like to interface with some of the other teams and hear about some of the experiences they went through?
Kimberlin: Some of their experiences really resonated with us. We experienced a lot of the same challenges in terms of some software glitch or something else that we all had to get through. Aside from listening to their presentations, we didn’t really have a chance to talk with too many other people. A lot of them were tied up with doing last-minute adjustments to their vehicles when we were down there and we didn’t want to get in their way. The few people that we did talk to, it was great listening to them, hearing about what they did for their vehicles to what they actually do during their day job. It was interesting seeing how diverse the backgrounds were on the projects.
APPEL News: Jim, why do you think programs and competitions like this are important to NASA?
Snoddy: For me, competition adds another dimension that people just do not realize. When you’re working against yourself it’s hard to go out and time a mile, and play a game. But when you’re playing with someone else, it adds a whole other dimension that you cannot comprehend what it does to teams who want to work and want to win.
I’ve been here for 25 years. Most people are put into project management jobs and they’ve never managed anything. I’ve never managed a $12,000 project, but I’ve managed a $20-million, $50-million, $100-million, and half-a-billion-dollar project. When you make a mistake on a $12,000 project, nobody really knows about it. When you make a billion dollar mistake, the whole world knows. I think you have to incrementally make little mistakes.
I’ve managed seven projects, and I’ve managed each one differently. I call it “lessons lived.” You can’t learn a lesson unless you live it. I’ve been on failure investigations many times. I’ve even been the result of a failure investigation, and I can tell you that if you haven’t lived it, you don’t really know what’s going to happen.
I didn’t think that these guys could learn the lessons that I’ve learned from a billion-dollar project on a twelve-thousand-dollar project. They actually went through it. How everything works and what organizations traditionally don’t support you relative to dealing with the Preliminary Design Reviews and Critical Design Reviews. I was amazed and shocked at the final outcome that they really learned that much with such a small investment.
APPEL News: Adam, going forward, what do you take from this?
Kimberlin: That’s a great question. There are definitely all the things I learned from this project as far as the project management and systems engineering are concerned. Then there’s who to work with, who to call about certain scenarios when you reach certain points. I guess one of the big things and one of the reasons why I started this project was to get to know people that were outside of my department, who I normally wouldn’t interface with.
I think one of the biggest things that I’ve learned is that if something like this ever dropped on my plate again or even on a much larger scale, I know exactly who I’m going to go to and ask for help. If you don’t have the right people involved from the very beginning, you’re destined for failure.
I’ve also learned how to be a little bit more patient. My day job is research and development, so a lot of what went on wasn’t exactly what I would be doing in my day job, but I hope to change that one day, and get more involved with the project management side of things.
APPEL News: What’s next for the team?
Kimberlin: Garrick, our avionics guy, picked up where we left off in the competition and submitted some proposals that were accepted and he’s now continuing the UAV work that we started. Another thing is that the local American Institute of Aeronautics and Astronautics chapter here in Huntsville is looking to sponsor a large unmanned aerial vehicle competition. They decided to do that independently of us, and I just happen to know a few people who are on that committee. Since we made that connection they’re involving us, asking for a lot of advice, and we’ve been able to offer some really valuable insight for them.
APPEL News: Jim, do you have final thoughts that you’d like to share?
Snoddy: I would never underestimate the value of training in a live situation. Even though some people may think $12,000 is not a lot, I would suggest doing activities like this where you put teams together and make them go through the whole process, cradle to grave.
You realize when you’re doing estimates up front and concept reviews, that you’ve got to test your system one day. You’ve got to fly it. You’ve got to design it, you’ve got to manufacture it, you’ve got to stand up before somebody and prove that it’s worthy to go fly. It makes you understand the importance of the paperwork and the systems engineering processes.
Kimberlin: I’d also add that one of the really big advantages that we had that you can’t necessarily capture with any spreadsheet or any number was how flexible our center was. Everything from center operations, our department heads, and even our center director had to get tied in at one point. Everyone was extremely supportive and extremely flexible and I feel like that was one of the things that was missing from some of the other centers that were competing. At some point, if you don’t have the manpower to address all of these logistical issues, then you kill your team’s ability to work on the things that are really significant.
I’d also like to mention how impressed we were with the other groups. They were really trying to go big on some of their projects and it was really interesting to see how they went about doing things. Major kudos to them because we thought they did an amazing job as well.
Systems Engineering and Integration (SE&I) lead and pilot Peter Ma, operates the MSFC development vehicle, Rogue, during early flight testing.
Featured Photo Credit: NASA Marshall Space Flight Center / Adam Kimberlin