An Internship Full of Curiosity & Rocket Parts
NASA Jet Propulsion Laboratory — Flight Software Engineer Intern (June 2014 — Oct 2014)
NASA’s Jet Propulsion Laboratory’s mission is to explore the solar system. This summer, I had a chance to be part of that mission and the bold “Dare Mighty Things” motto, working with rocket scientists who built Curiosity, the most advanced, 2.5 billion-dollar Mars rover.
Curiosity — Paving the Path for Mankind
Curiosity is a state of the art rover; it carries an advanced suite of scientific instruments used to study the role of water and habitability factors on Mars surface. Launched in November 26th, 2011 from Cape Canaveral Air Force Station, Florida, Curiosity traveledexactly almost 350 millions miles until it landed on the surface of Mars in August 6th, 2012. Its mission was then extended indefinitely. Knowledge acquired from its mission will serve as a basis for Mars 2020 Project and future human-led missions.is
Mars’ atmosphere is a tricky one. It is 100 times thinner than that of Earth, making it extremely hard to decelerate. The “7 Minutes of Terror”, also known as “Entry, Descent, Landing” (EDL), refers to the period when the rover has entered Mars atmosphere until it has landed.
I was following the news on Curiosity 2 years ago when it was still cruising in space. When it landed in August 2012, I watched the live update from JPL and saved this very emotional video ever since. It was very surreal that I get to help continue the work of so many wonderful people here at JPL.
The Flight Software Core Team
Most of Curiosity’s activities are automated, putting a huge pressure on the software powerhouse — The Software Team. The software is a collection of components, which are each made of many modules. Each module corresponds to an executable task. Several sub-software teams, including the Flight Software Core Team, are responsible for these components.
Since the 1997 Pathfinder mission, the flight software architecture has been the same. Then, the rover of the mission, Sojourner, was as big as a 10-pound shopping cart. Curiosity, size of a MINI Cooper, still runs on the same architecture used for Sojourner. With an advanced suite of equipments, Curiosity and future missions will need a more robust, dynamic, and versatile software architecture. Enters The Flight Software Core Team. Flight Software Core is a collective effort to architect a new paradigm that will be versatile and reusable for future missions, expecting to be useful for the next 20 years, given current technological forecasts.
The software architecture consists of modules, which are specific behaviors of the rover. In the current architecture, modules are all over the place, entangled with each other. It is analogous to a bowl of spaghetti, where each meatball is a module. When you try to pick up a meatball, it is entangled in a lot of noodles, which represent the modules’ coupling. (Awesome analogy credited to my project lead Katie W.) We want to scrap this and re-architect the entire software suite by enforcing loose coupling, highly cohesive design principle.
In a high level overview, Flight Software Core is re-implementing a spacecraft operating system that could be the base for future missions. Think of the new architecture as the iOS platform for future space missions. Each mission is a task the end user wants to achieve using their iDevices. For example, the end user wants to find a place to eat. They would first open up the Yelp app to find a venue. Then they will use the Phone app to call their friends and use Apple Map to get to the restaurant. Finally, they will use Venmo to pay. The task of dining is like a mission, which requires a set of apps. Different missions will require different set of ‘apps’. Flight Software Core will re-architect its current operating system, allowing future developers to integrate their own applications, resulting in a fully functional software suite with less time and coding effort (and hence, government budget).
So… What do I do exactly?
Remember the new software architecture and its modules? It turns out each core module needs to communicate with each other by sending ‘messages’. This communication part is written in C, but the code is specific for each module. Although the code is similar for many modules, hand coding them will take developers tens of hours of work per project, not to mention the amount of unit tests and documentation they need to provide. And this is under the assumption that every developer can hand code these messaging modules flawlessly and consistently.
My role is to replace the hassle of hand coding the messaging function among modules by implementing an autocode tool that could parse inputs from XML files, process them, and spit out C code. This tool will be then integrated into the Make system to build the final software. It is estimated to save developers tens of hours per future project, not to mention its consistency and accuracy, removing the need for micro-unit-testings and dense documentation. That is a good amount of time (and money!) saved.
Around the Lab
What I Learned
The autocode tool allowed me to get very comfortable with the Python programming language. It had become one of my languages of choice. The beauty of learning Python was not mastering the syntax or knowing how to use a tuple or a dictionary, in my opinion. Once one learned the basic of programming, he/she could pick up the syntax of almost any language. What I really liked about learning Python was figuring out how to use the rich libraries available on the internet and integrate them to serve a purpose. Python is such a modern, useful scripting language that there is probably support for every technical need.
Developing in a Linux environment exposed me to many Linux utilities such as brew, pip, or even tkdiff. I also picked up a few VIM commands along the development process and got better at using SVN for backing up my work. These little pointers would definitely help me become a better developer. When I had free time to chat with my boss, a Carnegie Mellon alumni specialized in embedded systems and network protocols, I got a little sneak peek into several OS concepts such as asynchronous vs. synchronous processes, blocking vs. non-blocking threads, etc. I am sure these knowledge would come in handy when I take my first OS class this coming year.
While working at JPL, I also had a chance to learn about the (rocket) science behind the work that I was contributing to. For example, I learned a great deal about rocket propulsion and the engineering of the rover’s wheels. I was also informed of future Solar System explorations planned for years to come.
Lastly, I gained a tremendous amount of leadership lessons from my project manager and the division leader. Not only were they great leaders, they were also great people with big hearts who cared about the lowest level of the org chart (me!). They acknowledged the team’s opinions, but were also decisive enough to make executive decisions when necessary. I am very eager to try out these new lessons the next time I lead.
A government top-tier research facility that runs on tax dollars, JPL does not have the typical Silicon Valley’s free food and colorful offices perks. However, the Education Office has done their best to offer us interns very practical packages, which I am perfectly happy with!