NASA/JPL Rover Sketch

Making it easier to drive on Mars

In 2015, there were two NASA rovers exploring the surface of Mars. These two incredibly delicate, billion-dollar machines are driven by approximately a dozen engineers based at the NASA Jet Propulsion Lab. The interfaces they use to send the robot directions are extremely precise and give them the ability to make hundreds of small tweaks to its behavior. But while their interfaces are powerful and precise, they are not great for exploration or comparison of multiple paths.

We worked with the Rover team to develop a working prototype of a complimentary piece of software, what we first termed “Google Maps for Mars” and the RSketch. RSketch enables rover drivers to quickly sketch new potential paths, drag waypoints around the terrain to see how the changes impacts the quality of the path, and share these insights with team scientists and managers.

Contextual InquiryA Mars rover driver walks us through his daily interactions with the system.
Contextual Inquiry

Talking to the “rover drivers,” we found that they had a specific idea of what they wanted out of a tool. Their current toolset was unwieldly and overly precise. They needed the final simulators for checking their final commands, but it was too difficult to use for sketching out multiple paths and getting feedback from team scientists. As we discussed their problems we continually referred to the concept of “Google Maps for Mars.” They needed something as easy to use as Google Maps but with the customized information that no one on Earth would ever need.

Contextual InquiryTimeline of rover drivers daily schedule highlighting the flurry of activity in the morning.
Contextual InquiryA sample of initial sketches used to validate our findings with the rover drivers.

From these interviews, we developed a series of sketches of a potential interface as well as a timeline of the rover drivers day that illustrated where we felt the drivers needed the most assistance. These documents were used to validate our direction with the drivers and proceed confidently.

PrototypesPaper prototype the rover drivers could interact with. While initially incredulous, the rover drivers found the activity clarified their own thinking.

What does a rover driver need to know as they plot out multiple routes for the Mars rover. It was unclear to us what was essential and what could be done by other systems. In order to better understand the thought process of the drivers, we gave them a paper prototype where they could create their ideal map.

Some of the facets of path-planning that were elicited: The importance of toggling overlays on and off, the importance of annotating specific points on the map, and the importance of comparing length and ground-type of alternative drives.

PrototypesSoftware prototype exploring the behaviors surrounding toggling on and off different terrain layers.

At the end of one session, one engineer mentioned that while he at first through this exercise would be a waste of time, in the end it helped not only the designers gain clarity, but it helped him think through the unconscious decisions he makes as he plans his driving routes.

Final Interface DesignA selection of mock-ups for the final interface.
Final Interface Design

We developed a final visual language for the development team to find inspiration from. We delivered representative screens, image assets they would need to build the final application, and color and positioning information so they could precisely build the tool we designed.

Final PrototypeScreenshot of the prototype used by the rover drivers.
Final Prototype

As you can guess, the computer systems that connect to the Rover are tightly controlled. We worked with the engineers to find a way to just a browser running in a Java virtual machine to read the files the rover drivers needed. The final prototype had real data, and it gave the drivers a sense of the capabilities of our system if they chose to develop it further.