Welcome to our continuing series of Code Project interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Khaled S. Ali, a software engineer with the Mars Rover team at JPL.
Who are you?
My name is Khaled S. Ali, and I work for the Jet Propulsion Laboratory, which is part of both NASA and the California Institute of Technology.
My official job title is Robotics Software Engineer. I am the team lead for the Mars Exploration Rover (MER) Flight Software and Data Management Team, a Rover Planner for MER, and a programmer for the Axel robot project.
What do you do?
As the team lead for the MER Flight Software and Data Management team, I spend most of my time investigating potential problems and answering questions. These questions are of the sort, “What will happen if we do this?”, “What is the flight software going to do in this situation?”, “How does this algorithm really work?”, and “What strategy should we use to get our data down from the vehicle and deleted as soon as possible.”
I was in charge of the development and testing of the latest two versions of the MER flight software, which were uploaded to the rovers in 2006 and 2009.
As a Rover Planner, I drive the rover and operate the robotic arm. This involves writing sequences of spacecraft commands, which are just computer programs written in a domain-specific language, which will execute on the rover a few hours later.
For the Axel rover project, I am rewriting some of the CLARAty infrastructure software which is used on the project, particularly the mathematical libraries.
During the main flight software development phase of the MER project, I wrote software modules that interfaced with most of the sensor and propulsion hardware on the cruise and lander stages of the spacecraft. I also managed the development of and co-wrote the software that determines and propagates the rovers position and attitude knowledge, as well as the software that points the high-gain antenna at the Earth for communications.
Previously, I worked on a few NASA/JPL missions that had less success. I was on the robotic arm operations team for the Mars Polar Lander, which crashed on landing.
I also did some software integration for the 2001 Mars Lander, a project which was cancelled before launch.
Furthermore, I was the lead for the software for the Lunar Surface Operations Testbed, which was a testbed used to validate the robotic aspects of the Moonrise mission proposal in 2010–2011.
I have worked on several robotics research tasks including automated plant micro-propagation, health care robots, reconfigurable robots for all-terrain exploration, visual target tracking, and planetary surface science operations simulation.
What is your development environment?
For the MER flight software, we did the development on what would today be considered ancient Sun Ultra 10 (sparcv9 450 MHz) and Ultra 80 (with four sparcv9 450 MHz) systems, running SunOS 5.8. We still use these systems when we need to update the MER flight software, as we wish to change absolutely nothing which could introduce problems. The software itself runs on a RAD6000 processor (20 MHz) running VxWorks 5.3 onboard the Spirit (now defunct) and Opportunity rovers.
For the Axel project, I develop on a Intel Core 2 Duo @ 3.16 GHz running CentOS.
I use Vim to edit code, rather than any IDE, but I always keep cscope running nearby.
At the current time, the languages I use most are C, C++, and Python.
What is your coding pet peeve?
One pet peeve I have is comments that do not match the code. Often, code gets updated, but the comments are left unchanged. That is sloppy at best and confusing at worst.
How did you get started programming?
On either my eleventh or twelfth birthday (I cannot remember for sure), I convinced my father to buy me an Atari game machine. My mother, however, convinced me and my father that it would be better to get a computer for me to learn to use. We settled on the Atari 800.
After I had played all the games that we had to a point of boredom, I decided to experiment with the Basic language cartridge that it came with. After a little reading and experimentation, I was hooked. The games could not compare with actually writing software. Since we did not have the tape drive peripheral, which was the only form of NVM, nor a printer, I used to write my programs down on notebook paper once I was done writing and debugging them. That way, I could type them back in if I ever wanted to.
What advice would you offer to an up-and-coming programmer?
When learning to program or learning a new language, get a book on the language and write programs to do things that are not needed for your job. Do this even if you cannot think of a program you actually need. This allows you to experiment with all kinds of things that you might not be allowed to do in a program for your job.
Assume from the start that you will learn better ways to do things as you go along, and refactor. Use an internet search engine to find lots of examples of things described in your book. Fortunately, there are lots of people who thrive on giving examples and explaining why their style or technique is the best. Compare these different approaches.
