By Kevin Vipavetz
When Tom Shull, my supervisor, told me the Virginia Space Grant Consortium (VSGC) might ask for project management and communications support for a university research balloon project, I thought about how I was already juggling four projects and didn’t have time to volunteer.
Photo Credit: NASA
I also realized I wouldn’t be here today without the help and mentorship of many others at Langley Research Center. When Anne Pierce, the Program and Development Specialist from VSGC, called and said, “I heard that you are an expert in best project management practices and can help us develop the communication system for the project, and that you are the best of the best. We really need your help,” she knew how to butter a person up. I heard myself say, “Sure, I’d be glad to help.”
Virginia Student Balloon Launch Program
The Virginia Student Balloon Launch Program focused on mentorship and providing “real-world” experience for students — an excellent idea. It involved a coalition of five Virginia universities and built on a prior balloon research project. As an atmospheric science experiment, it would measure products of combustion concentrations in the stratosphere (hydrocarbons and sulfur dioxide). The balloon would be launched from NASA Wallops Flight Facility between July and August, which, I learned later, was not the best choice when working with students near graduation.
Universities provide important basic research and innovative ideas that can be developed into cutting-edge technologies for NASA. They are also our main source for future scientists, engineers, technicians, and managers. So projects like this are important. You deal mostly with students who are book savvy but need project management skills and guidance. That’s what the projects are for — providing hands-on experience — but it can mean you need to fix things you had not originally anticipated. By realizing what experience the students needed and adjusting my expectations (these were not, after all, my seasoned Langley colleagues), I might have foreseen more of the unexpected challenges we faced during this project.
At the kickoff meeting, I learned that total funding for the project was $35,000, far too little to support the dozen or so NASA personnel who would be involved from Langley and Wallops and to procure hardware. I also learned that we needed to provide an additional mission control room for back-up telemetry to launch site operations (a decision that proved essential for gathering our data on launch day). The project Critical Design Review (CDR) was a month away, which seemed like good news. I thought I was coming in at the beginning of the project, but a successful CDR means that design drawings are near completion, interfaces are understood, much of the software code is done, and the project is ready to build and procure the hardware. During the meeting, I was asked to participate and help assess the CDR. Then I didn’t hear from anyone for a month.
The Critical Design Review
Of the 100 or so students who were involved in the project, six seniors had been assigned to me. I didn’t have any luck reaching them after the kickoff meeting and began to wonder if the CDR was still scheduled. A couple days prior to the CDR, I started receiving requests for help. Though the students had a camera and a data instrument, they did not know how to get the video and data sent from the balloon to the ground stations. I asked how we had already procured hardware when we hadn’t yet passed the CDR because these reviews are meant to help develop an end-to-end design for a compatibly integrated working system. What should have been — and I assumed had been — done up front was gather the stakeholders and put a complete concept together. I now push for this crucial step at the beginning of any project I am on.
Since the CDR was only a couple of days away, we didn’t have time to put a detailed design together. Instead, I recommended we look for off-the-shelf university equipment or compatible government hardware we could borrow. Because we didn’t have funding for a telemetry system, we would have to use one of Langley’s. I told the students to build and interface their hardware around this, then put together a CDR presentation showing how this would be integrated with the science instrument and ground operations. For a project of this size, we could get away with putting a working subsystem together without going through a full CDR process, but this would not produce detailed reports that could transfer the knowledge to the next balloon research team.
A couple of hundred people from the participating universities and members of the Aerospace Business Roundtable attended the CDR. The Roundtable provided further mentorship and assistance to the students and monitored the NASA�university collaboration. In addition, an Education Outreach Program was developing an interactive Web site to involve students from kindergarten to college across the globe in the program. Tom, my supervisor, accompanied me, and we sat next to a group of local newspaper reporters. I was starting to get a headache.
When my group presented, their chart showed a box diagram depicting a video camera, digital camera, controls, and global positioning system with a magical line connected to an unnamed box and then to a balloon antenna. On the ground, the chart showed a receiving antenna connected by more magical lines to two unnamed boxes connected to a monitor, network, and receiving computer. Well, I knew they were inexperienced. Afterward, my supervisor said to me, “Looks like you have a lot of work to do, but I’m sure that you can take care of it.”
Since everyone was there, I asked for a copy of the presentation and contact information for the faculty members in charge of the students, and I scheduled a meeting with the program manager. Then I asked for a copy of the system requirements. There were no requirement documents. I assigned one of the students to collect what he thought the requirements were and send them to me.
Getting It Done
When I got back to Langley, I immediately set up a schedule and several meetings. The next day I received a fax with a page of goals on the mission; these were the students’ requirements. I could see this was going to take some major work. I began putting together several requirement documents by using the students’ CDR presentation and contacting the university professors, who were very helpful, to develop the rationales and understand the objectives of the mission. This process played a big role in my seeing what needed to be done to achieve the project’s goals, and it set me on a path to understand industry best practices in this area.
The students did good work on a quick turnaround. They provided the hardware structure that held all the communication components for the gondola design, the electronics, command and control interfaces, cameras and video, global positioning system integration, and power distribution. They determined how the telemetry data would be acquired and transmitted and developed a simulation system to test the hardware and software. Once we had all the pieces, I wrote up a ground operations checklist and coordinated with our ground station at Wallops.
With a strong process in place, our team moved rapidly to meet our development goals. Over the next several months, the telemetry subsystem took shape and our spirits rose. By June the subsystem had completed its tests and was integrated with the rest of the payload. The payload passed environmental testing. We were ready to go. We were also ahead of schedule.
A Funny Thing About Seniors
For a month and a half we were on standby until the weather was right for the launch. About mid-August, we got the go ahead. Our team needed to be operating by 5:00 a.m. the next morning. I got in early and set up the ground telemetry with the Langley Mission Control Room operators. I could see from the Web site that we were getting visits from as far away as Australia; the project was generating a lot of interest. It was getting close to launch time, but none of the students had arrived. Time passed. Launch time was only a few minutes away. I called Wallops Mission Control and notified them that the students were not here. They asked if I could set up their computer at Langley, and it was then that I realized two things: one, I had incorrectly assumed that the students had procedures for operating the ground data processing computer (there were no computer procedures in the control room, and no one had the password to get computer access) and two, launching in the summer time may not have been a good idea. The seniors had graduated and moved on, and I had no way of getting data from the computer.
I sat quietly over the next several hours and watched the flight on the video screen. The balloon soared to around 90,000 feet. It followed a vertical circular pattern, first going over the Atlantic Ocean then coming back to Wallops. When the balloon was in the right flight position, the payload separated and parachuted down. I watched the payload descend until it went behind the horizon. Then I heard quite a bit of buzz on the intercom. A vehicle had hit the payload as it crossed over a road. Despite these difficulties, the instruments worked and the data was recovered.
This was not the easiest or most satisfying project I’ve ever worked on, but I think the students learned from their hands-on experience and gained some sense of what work like this requires. And I learned some important lessons: never assume; communicate early and often; and make sure your operation documents are complete so someone can fill in for an absent team member and you preserve project knowledge.
About the Author
 |
Kevin Vipavetz is a systems engineer and the Center Spectrum Manager at Langley Research Center. During the last twenty-three years, he has managed and provided engineering expertise for numerous instruments and subsystems in aeronautics, atmospheric science, the International Space Station, and the Space Shuttle. |
