The meeting notes will follow the structure
<DD-Mon-YYYY> (use heading 4 for readability)
and be on this page in plain text (with some formatting):
20-Feb-2011
Sreeja @ Task Analysis: SPHERES-wise, the goal is to be able to track the state of the robot graphically on a mobile device instead of from a stationary point. It allows for user mobility.
Preconditions - establish comm between robot and mobile device. info known has to be which satellite he is interacting with, which frequency he's on, what data he is viewing, which expt/test he's on.
where is the task performed: on the flat floor or lab table for 3DOF testing and on the ISS for 6DOF microgravity testing
environment on the ISS is very cluttered on the edge of the arena, flat floor is relatively flexible. but we have to always take care to not stand in between the bot and the global metrology system (which is 6 beacons around the floor)
Time required - couple of hours of testing, about once in a month per researcher.
Task is learned by trying it, watching others, reading the manual
Sreeja @ Domain Analysis: I like Dimitar's chart and would not change much. Could you be a little clearer on what the numbers mean though? X[Y-Z] -> what does X,Y,Z mean in the context of the relationship?
Sreeja @ User Analysis: Any age group that does experiments with robots, educated, no physical capabilities required except that we're designing for a set of mobile users,
persona : geeky computer scientists who prefer graphical visualizations with as much content as possible. Interviewed with personnel from the 1,2,3 labs and the results show (your inputs). We are at an advantage because we represent 3 classes of users however the system we want to design is generic enough to be expanded to other classes.
19-Feb-2011
Dimitar: I disagree that this is the only class of users: -- both good points, I agree (--Andy)
another class - novice users / UROPs
* no previous LCM experience assumed
* working on a specific subsistem.
* mid-to-low programming skills
etc...
another class - visiting student
* some robotics experience but no previous LCM experience.
* needs to quickly understand how a specific project is working by looking at the LCM info
As a general rule I think we should try to assume as little as possible about the user's abilities (even for grad students :) )
17-Feb-2011
feedback from users for GR1
User Analysis
Andy:
I think we have a single user class -- researchers in robotcs
Characteristics of user class:
- Mid-20s
- Well educated
- Highly motivated for research tasks
- Familiar with the specifics of their hardware and software
- Expert computer users
- Linux based systems (most users)
- Medium to heavy command line use
- Understand networking at a medium level
- Know what an IP address is
- May or may not know the difference between TCP, UDP, broadcast, etc
- Linux based systems (most users)
- Willing to dedicate large amounts of time to understanding robot dynamics, interactions, controls
- Too busy to dedicate large amounts of time to learning new interfaces unless use is immediately obvious
- Care a lot about delay on their systems
- Have used LCM before, likely have used lcm-spy (previous desktop interface)
- Work in 5-20 person labs
- Willing and able to ask for help
- Environment noise level varies
- One user operates a wind tunnel
- Another user operates a very loud air compressor
Task Analysis
Andy:
Run system: Goal operate robot
Preconditions
Set up LCM on robot
Connect all features of robot to LCM
Turn on LCM system for robot
Turn on phone
Knowledge:
Know the IP address of the robot? (depends on LCM configuration)
Subtasks:
Start application
Identify system to connect to
Confirm that system is online
Run system
Interact with system (ie demo)
Kill system
End application
Debug code: Goal understand if new feature is working or why it is not
Preconditions
Set up LCM on robot
Connect all features of robot to LCM
Turn on LCM system for robot
Turn on phone
Knowledge:
Know the IP address of the robot? (depends on LCM configuration)
what data to look at
Subtasks:
Start application
Identify system to connect to
Loop
Examine data
Interact with robot (ie move robot)
Reexamine data (see what has changed)
Evaluate if system response was correct
End loop
End application
Modify parameters: Hand-tune parameters for robot (ie stability gain parameters)
Preconditions
Set up LCM on robot
Connect all features of robot to LCM
Turn on LCM system for robot
Turn on phone
Knowledge:
Know the IP address of the robot? (depends on LCM configuration)
Subtasks:
Start application
Identify system to connect to
Confirm that system is online
Run system
Evaluate current parameters
Change parameters (ie more P gain)
Repeat
Kill system
End application
Where is the task performed?
In lab, near robot
not necessarily near main computer systems
What is the environment like?
Lab, relatively clean, possibly noisy, not dangerous, but must be careful of significant amount of delicate and expensive equipment nearby
How often is the task performed
daily
Time constraints
1-2 hour sessions
How is the task learned
self-taught
explained by other researcher in lab
What can go wrong
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
that user also relied on a dangerous propeller for propulsion
another user's platform can be damaged by inattention for more than a few seconds when in an unstable state.
failure to connect (wrong info, bad network connection, etc)
Who else is involved
- not sure here... need to think on this more.
Dimitar:
Domain Analysis
Andy:
Sreeja:
Dimitar: