Iris Rover
What if anyone could explore the Moon?
Carnegie Mellon University partnered with NASA and Astrobotics to design the first academic rover launch to the moon set for July 2021. A team of undergraduate and graduate students are currently collaborating on the design of the entire rover. The project attempts to break the current belief that space exploration can only be done with large, expensive, fancy rockets. Iris introduces the concept that anyone can explore the Moon.
I focused on the design of the software interface called Telemetry — a platform that enables mission control operators to monitor the rover’s health and identify critical errors to troubleshoot to ensure a successful mission.
Duration: September 2019 - Present
Team Members: Bin Li, Shan Wang
Role: Senior Interface Designer
Current design of the Iris Rover
Problem Space.
When the rover lands on the moon, it will be difficult to accurately predict how it will react to the environment. For this very reason, the team needs to closely monitor each sensor and component — ensuring it is functioning within its proper parameters. If an error occurs, it is imperative that operators quickly and accurately identify, track and troubleshoot during mission.
Driving the rover will require the collaboration of multiple mission control operation teams that rotate every 8 hours. During these shifts changes, all crucial information needs to be transferred from one team to another.
The Challenge.
The objective of the Telemetry interface is to offer mission control operators a holistic and efficient way to monitor the rover’s health. We knew this would be challenging due to the large amounts of data that needs to be organized and rendered. Nevertheless, we aspire to design an interface that enables operators to efficiently analyze rover data and troubleshoot critical errors.
Our goals:
01.
Clearly show an overview of all data for a holistic monitoring experience.
02.
Make it easy and quick for operators to detect errors.
03.
Provide robust features to help troubleshoot errors.
My Role.
As a Senior Interaction Designer, I lead a 3 person team of Interaction Designers tasked with building the interface from the ground up. I plan and schedule research and design tasks, ensuring the project stays on track. I also communicate with the Design Lead and share team progress to recalibrate priorities in accordance to the larger project’s timeline.
In addition, I ensure the team collaborates with different stakeholders such as developers, engineers and other designers.
The Process.
01. Discover
Stakeholder Interviews
02. Define
Data Architecture
Data Mapping
Feature Breakdown
03. Design
Sketching
Workflows
Feedback & Iteration Cycles
Wireframes
Hi-Fidelity Designs
01. Discover
Stakeholder Interviews.
Understanding a new space
Since we were starting from the ground up, we began with stakeholder interviews in order to get an initial sense of the project’s undertaking and its requirements. We conducted interviews with the Mechanics Lead, Flight Operator and Software Lead.
Interview with the Mechanics Lead.
Learnings from the Mechanics Lead:
Gained a better understanding of all sensors and components — what they measure and how they relate to each other.
“ ... the raw data can be helpful for post-mission analysis, but the team needs to monitor the inferred value during mission to ensure proper performance of all critical components. ” - Lou, Mechanics Lead
Learnings from the Flight Operator:
The goals of mission control operators, the team’s structure and what type of data each member will be monitoring.
The communication and transfer of data points — when, how frequently, and at what resolution the rover will be sending data points.
“ The main goal of the telemetry interface is to monitor the overall health of the rover, and warn the team if something goes wrong.” - Raewyn, Flight Operator
Learnings from the Software Lead:
The technology framework the interface will be built on — its possibilities and limitations.
“ ... a lot of times the failures require human analysis and cannot fully rely on auto-generated error messages.” - Connor, Software Lead
02. Define
Data Architecture.
Identifying flow and structure
Based on the stakeholder interviews and secondary research we conducted, we deconstructed and re-organized all data points within a framework that helped us understand the concepts better. This helped us understand how data was flowing from the rover into the Telemetry interface in a way that could be translated to helpful information to operators.
Data Mapping.
Tracking the transformation of data
Using the data architecture framework we created, we further identified the state of the data at each level. From this exercise, we were able to discern and design how each data point can transform into something informative to the user. In addition, this helped us understand each data category’s behavior in much more detail.
Feature Breakdown.
Establishing our design direction through objectives
Prior to designing, we wanted to delineate the goals for the interface and identify the features that would help us achieve those objectives. We got together to brainstorm the goals of the interface:
01.
Provide robust error handling.
To troubleshoot in a holistic manner — provide a history of errors along with accurate descriptions, and access to a snapshot of all rover data for a critical error.
02.
Prioritize the inferred value.
Ensure the interface clearly shows an accurate representation of the meaning of each data point, i.e. what is the data telling me?
03.
Customize error thresholds.
Enable customization of error parameters in order to accommodate the unpredictable reaction of the rover on the moon’s surface.
04.
Monitor with flexibility.
Provide a high-level view of all sensor data, but also allow operators to dive deeper to examine in more detail.
We then brainstormed each data category’s features by ensuring they met the goals we identified.
Feature breakdown exercise on the whiteboard.
Sketching.
Generating design ideas quickly
To begin the design of Telemetry, we got together to sketch the layout and workflows of the interface. Rough visualizations allowed us to quickly generate many ideas. In order to create multiple designs, we often did Crazy 8’s — a design exercise that asks participants to brainstorm 8 potential solutions in a short amount of time. We also did Parallel Design — each member brainstorms solutions to the same problem individually, followed by the merging of these designs into one solution.
Workflows.
Visualizing the task journey
Before generating detailed wireframes, we set out to understand the bigger picture of how operators would navigate the screens according to different tasks. This helped us visualize how each page was connected to another — helping us optimize task completion from a high-level perspective to identify gaps and efficiencies at each step.
Feedback & Iteration Cycles.
Informing our designs through feedback
Throughout the multiple rounds of sketches and updated workflows, we would get together with stakeholders and users to share ideas and gather feedback. From these sessions we identified misunderstandings or incorrect assumptions we’ve made during the design process — helping us make more informed iterations.
Wireframes.
Digitizing our designs
To transfer our sketches into a digital format, we created low-fidelity wireframes.
Challenges.
Due to the distance between the Earth and the Moon, there is a delay in the data’s transmission — there is no such thing as live data. In addition, there is limited bandwidth that needs to be shared across data points, resulting in lower resolutions all across and potentially rendering the monitoring experience useless.
There was a large technical component to this challenge, so we organized a collaborative design meeting with the Software Lead and Flight Operator.
Through this exercise we identified a way to address this issue:
Data resolution customization
To try to balance the need for higher data resolution with a limited bandwidth, we decided to allow operators to customize the resolution for each data category. Depending on what sensors they are specifically monitoring during the mission, operators can request higher resolution for the ones that are more important in the moment.
High-Fidelity Designs.
Iris has a design system, Cosmos, that determines the overall look and feel across all interfaces. Using the components, colors and styles set forth by the Cosmos team, we finally transformed our wireframes into high-fidelity designs.
Data Dashboard
Provides an overview of all data categories — mission control operators can get a holistic view to monitor the rover’s health.
Data Details
Each data category has a detailed view, where operators can manipulate and view data points at a more granular level.
Error Analysis
Provides a history of all errors and enables operators to view a snapshot of all sensor data when an error occurs. Images captured during an error can also be viewed. This ensures that during shift changes of engineers, operators have access to the same critical information.