Astrobotic’s MoonRanger is the first autonomous rover to look for ice at the Moon’s south pole. I led design for the faults & errors feature within the Mission Control Software. This feature aids Mission Operators in correcting errors and faults with the rover that could jeopardize the success of this lunar mission. In addition to my studies at CMU, I participated in the development team on this R&D project, in association with NASA and Masten Space Systems.
🌝 MoonRanger Mission Control
Clients:
Astrobotic Technology x MoonRanger
Timespan:
May 2022 - June 2022
Role:
Product Designer - Faults & Errors Lead
How can Mission Control Software aid Mission Operators in solving unexpected circumstances that jeopardize the success of the MoonRanger mission?
Problem:
Because Mission Operators are working under tight timelines and stressful situations, reducing cognitive load was an important priority. This is done through developing information salience and using existing design patterns to prioritize primary information and actions.
Solution:
Error Resolution assists Mission Operators in identifying, prioritizing, and troubleshooting faults through directing focus and information saliency.
The MoonRanger rover is going to the moon to search for water ice on the lunar south pole. The rover could encounter faults and errors along the way e.g. electrical problems with the rover system, mechanical malfunctions, and unfavorable environmental conditions. Mission operators must troubleshoot these problems within a limited communication window, or risk mission failure.
I rapidly iterated on the engineering flows to understand process behind operator & robot interaction for error resolution.
I devised a ‘spotlighting’ ui pattern, which highlights current screen focus for operators.
What is a MoonRanger, anyway?
MoonRanger is an autonomous lunar rover looking for water on the moon.
A collaborative effort between CMU, NASA, and Masten, MoonRanger is slated to arrive on the moon at the end of 2023. This project features several important innovations in the area of lunar exploration: MoonRanger is the first truly autonomous lunar rover to search the Lunar South Pole for water ice. The rover is being built and will be operated by a team of engineers and researchers from Carnegie Mellon university.
Image from CMU Astrobotic MoonRanger
Team organization & structure for MoonRanger
Fault Resolution: Diagnose, Debug, Deploy
My role on MoonRanger led advancement of a software feature to help mission control operators handle faults and exceptions that may jeopardize the success of the mission.
Many faults are identified by the engineers through the design and testing of the systems. Historically, these faults were planned for and documented by space exploration teams through a Fault Tree Resolution (paper) manual, but the MoonRanger team sought to incorporate this into their Mission Control software.
System faults with the rover could range from electrical issues with the rover’s power management system to environmental hazards like damage from rocks. The aim was to provide a way for the software system to aid operators in troubleshooting these issues in what could be a high-pressure scenario.
Design Process: My approach
The short-timeline and complex problem space dictated my approach to design.
Design as research. Learning things by making and testing. Using a bias for action, and putting pen to paper.
Abductive reasoning. Useful for ‘taking your best swing’ with the info available. and knowing while the current iteration may not be perfect, it
Testing and iterating, many times.
02 Inspiration ↔ Ideation
Using secondary research to ask better questions and inform rapid assumptions testing with SMEs
One of the most significant challenges I faced in designing this error handling feature was the complexity of the engineering systems involved. I was able to get up to speed quickly with desk research, but still needed to distill the ambiguity of the problem.
To learn more about the systems as well as look for design opportunities, I created a high-level flow to both visualize and communicate my ongoing thinking and get feedback from the Systems Engineering Lead, one of the longest-running team members with significant understanding of the project and systems.
Identifying the most challenging & riskiest parts of the flow pointed me towards looking for a way to simplify & frame the problem in a more manageable way.
Error Resolution Flow, first iteration with questions
Developing principles for a design direction
Feedback from this test of assumptions additionally helped me create priorities for qualities of the design solution.
01 Performance: Task Completion
Due to the critical nature of the task, users need to complete efficiently and accurately.
02 Reduce Cognitive Load for Operators
In a complex mission situation with multiple operators and dashboards, reducing the mental work operators must do to complete a task is essential
03 Prioritize Efficiency Over Learnability
The system need not prioritize walk-up-and-use users. The operators will be highly trained, technical users.
Framing the problem through scenario selection and test design
Working closely with the Research Lead, I translated the engineering requirements for the initial boot up scenario to a testing flow for the project’s ‘Paper Mission’ testing.
This was necessary to simplify the kind of faults the rover might face in the scenario and narrow down the problem scope to something that could be handled on an interface.
The type of faults I decided to test were: rover-detected, critical risk (as determined by a likelihood x severity matrix), and had a well-defined resolution by the engineering team.
Engineering flow and scenario selection
Fault selected for scenario testing. This fault was selected for the following reasons:
Critical Risk: high severity x uncommon likelihood (worth testing)
Rover-system detected (not a human error)
Well-defined resolution methods (is well understood by the engineering team)
Defining UI requirements through process flow mapping and iteration
Flow showing operator interaction for fault detection and resolution.
I further mapped this fault scenario into task-oriented user steps to define the necessary screens and primary actions that could help the user complete their task.
These flows were iterated on multiple times to look at the synchronicity of the multiple operators involved in resolving this fault, getting feedback often with SMEs and the engineering leads.
Defining necessary screens & operator actions
Granular action flow for interface
03 Solution
Requirements to high-fidelity wireframe sketching using design systems
Two of the screen sketches at a high fidelity using design system pieces.
Based on the requirements outlined with flow mapping, I sketched several solutions using my design principles as a guide.
I explored several layouts and ways of organizing fault detail and troubleshooting flows.
Building final screens for the paper mission
Two of the screen sketches at a high fidelity using design system pieces.
With feedback from the engineering team, I pushed the designs to higher fidelity and strengthened the hierarchy of primary actions and interaction feedback for the user.
This led to a design pattern, ‘Spotlighting,’ where the user’s attention is drawn to a selected widget or sub-component within a widget to minimize information overload and guide the user through the troubleshooting process.
