This one is a little longer and less picture oriented than usual but it outlines the project as a whole and sets up what we did.
Comet ISON was discovered by Russian astronomers in September, 2012 and named after the network it was discovered with. In November, Balloon Rapid Response for Comet ISON (BRRISON) was born to take advantage of this rare opportunity to observe a comet from the Oort Cloud. Because Comet ISON might not survive its trip around the sun and with its perihelion happening on November 28th, 2013, time has been short since the start. Programmatically BRRISON is overseen by NASA’s Glenn Research Center and all the engineering is being done by The John Hopkins Applied Physics Laboratory (APL) and Southwest Research Institute (SwRI). SwRI’s contribution to BRRISON is the UVVis Instrument composed of two detectors, two mechanisms (a retractable fold mirror and filter wheel), a fast steering mirror, and the flight electronics and software to operate it all. In addition to observing ISON and other objects in the solar system, BRRISON is being used to demonstrate advanced image stabilization on a balloon platform. BRRISON lifts off from Fort Sumner, NM in late September, early October – just some 11 months after its conception.
Before BRRISON could get off the ground, APL and SwRI teams had to pass a Critical Design Review (CDR) with NASA to prove it was a feasible endeavor. This is normally a process that takes a year or so but for BRRISON, CDR level analysis had to be done in two weeks. It meant a lot of sleepless nights and immense effort on everyone’s behalf. After the project was approved, again because of the short time scale, getting the funding to keep up with the project’s pace was a struggle. To simplify and speed up the funding flow, SwRI was made a subcontractor to APL for the UVVis instrument (despite the proposal for this mission being largely developed by SwRI). With the funding flow and some bureaucratic struggles and road blocks getting the DayStar crew hired, it was not until March that we were really able to get started.
Before the scale of our involvement was finally revealed to us, we thought we would be doing almost all software work similar to what we had launched last fall on DayStar. We thought we would be writing the flight software system for collecting health and status data, taking and storing images, and communicating with the ground. In January we heard rumors that there might be some additional mechanisms involved, possibly a second camera, and even a fast steering mirror. Come February in some of the first meetings here at SwRI, we were rudely awakened with what had actually been put on our plates. Rather than just the flight software we were suddenly responsible for:
1. Figuring out how to operate two high performance cameras. (They included SDK’s but were both primarily designed to run on Windows (and our flight OS was certainly not going to be Windows) in a lab setting, not at 120,000 ft on a balloon.)
2. Interfacing with, operating, defining the behavior of, and monitoring two mechanisms. (Thankfully that number was cut down from four, two linear focusing stages were left out.)
3. Interfacing with and controlling a heating system to keep the optics bench and electronics within certain temperature ranges. (Hardware can fail or act strangely if it gets too hot or cold.)
4. Creating a power system to power the entire instrument off a single raw battery voltage. (Capable of powering the flight computer system, power hungry cameras, mechanisms, heaters, etc. All of it drawing more than 300 Watts if it was all operating at once.)
5. Developing a control system using image analysis to determine how a high performance steering mirror should be moved to stabilize the images taken. (This included nontrivial interfacing with and characterizing of the fast steering mirror.)
For reference, the mechanical design of the instrument (mounting to the telescope, the optical elements and optics bench, the mechanisms, and the pressure vessels were done by 7 mechanical engineers and optics specialists spread between SwRI, CASA, and High Precision Devices (HPD). At least in the case of the optics, they also started earlier than March (like December, a lot of the design had to be done for CDR). Engineering efforts are often split into thirds between mechanical, electrical, and software engineering. By this measure the DayStar team was tasked with 2/3 of the UVVis Instrument effort.
So rather than the four of us teaming up to work together on the flight software we really had to break up and specialize to absorb all the other parts of this instrument. Doing basically all of the flight software was dropped into Kevin’s lap as he had done nearly all the flight software for DayStar. Getting the cameras and mechanisms working was given to Zach since he had been one of us to build the DayStar camera. He also tag teamed a lot of the software with Kevin. Nick was suddenly responsible for designing and building the power system to power every part of the instrument. This was similar to what he did on DayStar but orders of magnitude more complex. Jed got the rather mysterious control system design since in parallel to BRRISON, he was working on the SwRI Solar Instrument Pointing Platform which also includes a fast steering mirror control system.
After drawing up the first system block diagram with all these parts included, we stepped back and Steve Osterman (optics specialist and systems engineer for the UVVis Instrument) noted pretty overwhelmed expressions on our faces. We thought we were signing up for part time work, maybe 20 hours a week if it really got rough. It started to sink in that it was going to be more like 20 hours a day and that we were going to have quite an indoorsy Spring and Summer. It was daunting but we faced up to the challenge and haven’t had time to look back since.