...
Our user base comprises of three basic classes: (1) Researchers in Robotics, (2) Novice Users and (3) Visiting students to a Robotics lab.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:
- Robust Robotics Group at CSAIL
- Synchronized Position Hold Engage Reorient Experimental Satellites (SPHERES) project at SSL
- Robot Locomotion Group at CSAIL
Typical Characteristics of the classes are:
(1) Researchers in RoboticsNovice Users: Hobbyists and UROPs
- 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 mostly use Linux based systems and are familiar with medium to heavy command line use. They understand networking at a medium level i.e. know what an IP address is and are familiar with TCP, UDP, broadcast, etc
- Motivation: Motivated robotics researchers who are willing to dedicate large amounts of time to understanding robot dynamics, interactions, controls. They are experimentalists but 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
- 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 expectedApplication 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 and another user operates a very loud air compressorThe 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) Novice UsersIntermediate 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 LabAge : 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 (UROP age).
- 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: Ability to operate a phone app interface, to operate the robot's software and initiate experiments via the computer. No prior programming or networks experience is necessaryThis user experience varies from robotics software knowledge, Linux knowledge to none at all.
- Motivation: Motivated learners interested in learning about robotic system, controls and performanceTo learn about robotics systems.
- Domain Experience : No prior experience with LCM or communication tools requiredMay 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 under in collaboration with a supervisor who has significant experience in a robotics lab in terms of software and hardware. He/she would be working on a specific subsystem in the lab. 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) Students and Visiting students to a Robotics LabAdvanced 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 familiar with medium to heavy command line useusers. 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 but . 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 and , 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
- Robot is network enabled and set up
- Robot is on
- Mobile device is on
- Knowledge
- 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
- Robot is network enabled and set up
- Robot is on
- Mobile device is on
- Knowledge
- 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.)
- 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
- Robot is network enabled and set up
- Robot is on
- Mobile device is on
- Knowledge
- 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.
- Some robots are dangerous for the operator
- 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.
...