We first approached the design phase by brainstorming primary features and functions.  We individually brainstormed features, and then as a group and created an affinity diagram.  The items from the affinity diagram were categorized into the following interface areas. 

Interface Features

Commanding
Ideas for the commanding area consisted of the need for multiple modes, including an advanced mode for troubleshooting and viewing of low level data and controls as well as a novice mode.  One of the research papers recommended the ability to access all levels of control so that an operator could drop down to low-level control during unusual or anomaly situations.  The idea of commanding the robot to traverse to waypoints originated from the NASA seminar.  In addition, the need for an emergency stop was supported by multiple robotic teams.   

Scientific Data / Situational Awareness
Scientific data was defined as the data collected by the robot during the mission.  This data would include the pictures taken by the onboard camera as well as maps generated by the onboard pictures and orbiter pictures.  Along the lines of scientific data, the interface needs to communicate situational awareness as well.  Situational awareness is of utmost importance because it helps the operator visualize the location and environment of the rover.  To ensure sufficient awareness, the interface needs to communicate a correct description of the robot’s environment.  Needed details of the robot’s environment include:  temperature, amount of visible light, terrain description, time of day, distance to targets, and description of current weather. 

The interface would ensure that the data being given to the user is accurate.  Because of a reorted difference between what the robot’s and orbiter’s perception, it was suggested that the interface be able to calculate and display this difference in perception to ensure optimal operator performance.  In Robo-Soccer, an overlay camera image was paired with the robot’s computer generated ‘world view,’ this ensured that there was consistency. 

Scientific data would also include awareness data, such as information displaying what tasks the robot is currently performing.  Other important information that the operator needs to know include connection status and battery and equipment status.  In respect to the given task, the operator in the game situation will need to know point values and game score.

Errors/Warnings
It is essential that the interface display errors and warnings.  A warning could be given when the battery is running low or equipment isn’t properly working.  A warning could also be given when the robot is about to run into an obstacle.  Data supporting the display of errors and warnings included contextual inquiry data from Robo-Soccer, interview data from the NASA seminar, and background papers.  In the Robo-Soccer contextual inquiry, the operator made sure an error didn’t occur by ensuring that the robot didn’t run off the course and into an obstacle.  Evidence also came from the NASA seminar.  The Mars rover driver described problems when the onboard AutoNav (auto-navigation) unexpectedly caused the robot to drive randomly in circles.  In addition, the paper “Improved Interfaces for Human-Robot Interaction in Urban Search and Rescue” shed light on the importance of enhanced awareness of the robot.

Navigation/Orientation
In order to navigate, the controller needs to know the layout of the robot’s environment.  In addition, in order to correctly formulate commands, the user must be aware of the orientation of the robot.  The pre-defined task allows for two different views:  the orbiter’s view and the robot’s view.  It was suggested that a map of the environment be shown at all time. 

Robot Capabilities
In order to effectively control a robot, the operator must know what the robot can and cannot do.  In the case of the Mars rovers, the rovers run off of solar energy.  The drivers are keenly aware of this, and so always know that the robot must stop at locations that will allow it to get enough sunlight.  Even when scientists want to stop the rover to do observations, the scientists will override the scientists’ requests to ensure the robot will have enough battery power.

Not only is knowing a robot’s capabilities important when deciding what commands to send, it is also important when deciding how the robot will execute commands. Robot command execution can happen two different ways.  One, the execution is continuous, meaning that if new commands are sent while the robot is performing a task, the robot will automatically do those commands and then go back to the original plan.  The second way is to tell the robot to stop after execution and wait for more commands at the next communication uplink.  This ensures that the operator can determine where the robot is located.  The mode of operation chosen generally depends on the robot’s level of precision when executing commands.  Since the Lego Mindstorm responds to commands with low precision, it has been decided that the robot will stop after execution and wait for more commands.

Scheduling
In order to re-task the robot, the interface has to support scheduling of activities.  In the brainstorming session, ideas for the scheduling aspect of the interface included

• ability to rank each task
• graphical manipulation of activities in a queue
• automatic optimization of the plan based on priorities
• pre-planning of different options
• graphical manipulation of activities in a graph
• gaant chart view of plan
• spatial visualization of the plan overlaying a map

Based on evidence, we also wanted our interface to be able to show an activity log of past events.  We found that history and documentation would be important features based on the contextual inquiry with Robo-Soccer.  During the contextual inquiry, the robot operator needed to know who made a particular change to the code, and when.  Other supporting evidence came from the NASA seminar, in which the rover driver stated that events that happened in the past affect the current plan.  The knowledge of past events helped the NASA planning team create the schedule.  For instance, when one of the rovers got stuck in the sand, the rover planners new to stay away from certain areas in the future.  Along the lines of providing history and documentation, it was decided that the interface should have an archive of photos taken which could be searched by the operator. 

Simulation / Estimation / Suggestion
We discovered that simulation of the activity was important because it allowed robot operators to visualize the activity and to foresee if any problems might occur.  The Robo-Soccer team, the NASA Mars Rover planners, and Red Team all referred to a simulation of the task when planning.  Simulations of both the current plan and the different plan options would be valuable when the operator had to choose between options.  We decided that the interface would also have an estimation ability, which would include an estimation of the amount of time needed to complete each task, and the amount of time needed to finish the plan.  Further supporting the operator would be a suggestion area that would allow other scientists and the backend AI to make suggestions for the plan. 

Basic Design Requirements
The underlying focus of the interface design is to follow basic usability design specifications.  These specifications include the integration of shortcut keys to create, edit, and delete items.  To facilitate the commanding of the robot, we chose to design for the use of macros.  Macros would allow the user to input a high-level command that the backend software would break down into robot-recognizable commands.  We also decided to implement customizable placement of pallets and windows.

• Shortcuts
• Macros
• Customizable pallets/windows

“I want an interface so anybody can use it… I don’t want to have to rely on the one person staying in the desert for months at a time to be the only person who can operate it.” 

Mike Wagner, Life in the Atacama