GR1 - Task analysis

User analysis

Our user base comprises of three basic classes: beginners, intermediate users and advanced users. For the purpose of User Analysis for each of these classes, we interviewed and have worked with the following robotics groups at MIT:

1. Robust Robotics Group at CSAIL
2. Synchronized Position Hold Engage Reorient Experimental Satellites (SPHERES) project at SSL
3. Robot Locomotion Group at CSAIL
   

Typical Characteristics of the classes are:

(1) Novice Users: Hobbyists and UROPs

• Age : Variable since the user could be novice to the robotic system at any age but a substantial chunk would be from late-teens or early 20s.
• Education : Most probably this user has finished high school and have some college, but they might as well be still in the high school.
• Computer experience: We assume they went through a tutorial of how to use a mobile device and/or the computer system or equivalent. No prior programming or networks experience is assumed.
• Motivation: Motivated learners interested in learning about robotic system, controls and performance.
• Domain Experience : No prior experience with LCM or communication tools is expected.
• Work Environment and Social Context: The work environment varies significantly depending on the type of robotics e.g. SPHERES works with experimental satellites on a laboratory glass table or in an epoxy floored clean room.
  

(2) Intermediate Users: Industry researchers and Visiting students to a Robotics Lab

• Age : Can vary from mid-20s to a variable age where-in the individual is a student in a Robotics Lab
• Education : Well-educated individuals with analytical skills and ability to comprehend mathematical charts. They would be highly motivated to learn about research tasks. Familiarity with the software and hardware is not expected.
• Physical Limitations : Our user audience is one that is capable of being mobile on the robotic arena to justify the need for a mobile interface.* Computer experience: This user experience varies from robotics software knowledge, Linux knowledge to none at all.
• Motivation: To learn about robotics systems.
• Domain Experience : May know comm tools like LCM is not expected to.
• Application Experience : Ability to use a phone app and read analytical charts.
• Work Environment and Social Context: This user with work in collaboration with a supervisor who has significant experience in a robotics lab in terms of software and hardware. They share interpretations of results with each other (i.e. among other researchers) and sharing tools. Environment noise level varies: one user operates a wind tunnel, another user operates a very loud air compressor and a third works in a clean room.
  

(3) Advanced users: Academia Researchers in Robotics

• Age : Can vary from mid-20s to a variable age where-in the individual is active in a Robotics Lab
• Education : Well-educated individuals with analytical skills and ability to comprehend mathematical charts. They would be highly motivated to perform research tasks and familiar with the specifics of their hardware and software
• Physical Limitations : Our user audience is one that is capable of being mobile on the robotic arena to justify the need for a mobile interface.
• Computer experience: Expert computer users who want to plot different parameters of the data transmitted against each other - a facility not supported by the current interface.  These users mostly use Linux-based systems and are medium to heavy command line users. They understand networking at a medium level i.e. know what an IP address is and are familiar with TCP, UDP, broadcast, etc. They understand the working model of the robotic model very well and are able to make decisions/judgments about the data received very quickly.
• Motivation: Motivated robotics researchers who are willing to dedicate large amounts of time to understanding robot dynamics, interactions, controls. They are experimentalists. They also do not have the time to invest to build a new, flexible and user-friendly interface and are too busy to dedicate large amounts of time to learning new interfaces unless its use is immediately obvious. Communication latency and delay are important considerations for the interface model they use.
• Domain Experience : Have used communication tools such as LCM before
• Application Experience : Have used desktop applications such as LCM-spy (previous desktop interface) whose output is an array of floats.
• Work Environment and Social Context: This user class works in 5-20 person labs. They are willing and able to ask for help and collaborate significantly with each other in terms of exchanging tools and debating results. Environment noise level varies: one user operates a wind tunnel, another user operates a very loud air compressor and a third works in a clean room.

Task analysis

Run Robot

Goal: Operate robot safely
Scenario: User wants to demo a robot to another researcher, outside sponsor, or friend. User wants to show data to his or her companion.

Preconditions

1. Robot is network enabled and set up
2. Robot is on
3. Mobile device is on
4. Knowledge
   1. Know the IP address of the robot (this knowledge depends on implementation details and might not be needed in some cases. Further study will allow us to determine its necessity.)

Subtasks

• Start application
• Identify system to connect to
• Run system
  • Choose data to view (ie position data)
  • Optional: interact with data (historical data, charts over time)
• Turn off system / robot
• End application

Debug unexpected behavior

Goal: Understand why system is producing an unexpected behavior (bug)
Scenario: Many users reported using existing LCM interfaces to help determine why their system was acting in an unexpected way.

Preconditions

1. Robot is network enabled and set up
2. Robot is on
3. Mobile device is on
4. Knowledge
   1. Know the IP address of the robot (this knowledge depends on implementation details and might not be needed in some cases. Further study will allow us to determine its necessity.)
   2. How to produce the unexpected behavior

Subtasks

• Start application
• Identify system to connect to
  • Examine data
  • Interact with robot to produce unexpected behavior (ie move robot)
  • Reexamine data (see what has changed)
  • Evaluate if system response was correct
  • Implement potential fix
  • Repeat until fixed
• End application

Tune control system

Goal: Hand-tune parameters for robot
Scenario: User has a new or modified system that requires hand-tuning for operation. Users report that when tuning a system, easily changing the parameters is a must.

Preconditions

1. Robot is network enabled and set up
2. Robot is on
3. Mobile device is on
4. Knowledge
   1. Know the IP address of the robot (this knowledge depends on implementation details and might not be needed in some cases. Further study will allow us to determine its necessity.)

Subtasks

• Start application
• Identify system to connect to
• Run system
  • Evaluate current parameters
  • Change parameters
  • Repeat
• Turn off system
• End application

Further thoughts on task analysis

• All of these tasks are performed in a lab, near robot
  • Not necessarily near main computer systems
  • Relatively clean, possibly noisy, not dangerous, but must be careful of significant amount of delicate and expensive equipment nearby

• Users reported using the systems on a range from a daily basis to monthly
• 1-2 hour sessions
• Task learning
  • Self-taught
  • Explained by other researcher in lab (ie to a UROP)

• Dangers
  • Some robots are dangerous for the operator
    • Propellers
    • High-speed / high torque motors
    • Heavy devices
  • Task can be very dangerous for the robot itself
  • One user was working on a dynamic control task which, if failed and the robot was not stopped, would damage the robot within 1/2 second
  • Another user's platform can be damaged by inattention for more than a few seconds when in an unstable state.

• Issues
• Failure to connect (wrong info, bad network connection, etc)
• Process not running
  • All users reported many components to their systems, any one of which could make the entire robot fail

Domain analysis

Comments:
Even though messages are created by a single process, they cannot identify the process.
However, we assume that the user has some implicit knowledge about which processes publish on which channels.

References

LCM project hosting

http://code.google.com/p/lcm/

LCM Overview

http://lcm.googlecode.com/files/2010-huang-olson-moore-lcm-iros.pdf