Ironies of Automation - Ryan

Interesting things I didn't think about:

• Difficulty monitoring - it's boring to monitor something that doesn't change very often, which means that the monitor will be unprepared for emergency conditions - he's not paying enough attention
  • I don't think this will necessarily be a problem with our system, because the operator is still doing something.
  • However, We need to make sure that their attention can be drawn by abnormal conditions
• If you use alarms to alert to abnormal conditions, what is checking on abnormal conditions in the alarms?
  • This may be able to be solved by model checking - the alarm can keep track of itself
• Operator skill - if the operator is expected to take over during an emergency, if generally he just monitors the operation, how is he going to be skilled enough to take over?
• Human monitoring of automated systems - If we want the system to be simple enough for a human to monitor it, what's the point? In that case, a human could do the job

Solutions?

• Make sure that monitoring information for every part of the system, whether that's the part they're on or not, is visible in the display of every system.
  • Likely it will be better to keep that information constant on one part of the display, regardless of what system that are using
• Alarms to draw operator attention to abnormal conditions, whether or not they're paying attention to them before hand (likely they aren't)
• Simulation / external practice very important for operator so he can take over system when it fails.
  • Alternately, cheap enough systems you don't really care if you lose one. Unlikely.
• Easy way for operator takeover when system fails
• Stabilization / automated responses to abnormal conditions so the operator can assess before takeover
• Make sure displays work well together, not just alone, to facilitate switching between various systems.

HRI Survey - Ryan

Obviously, Human-machine interactions has been around as long as machines have.

I agree that HRI is a separate field, but one that requires expertise of many different kinds of people.

Interesting that peer relationships require more autonomy than having the robot just work alone. It makes sense, though, because not only does it need to be able to operate on its own, but it also needs to be able to react in human ways on its own as well, which is much harder.

Information exchange is an important problem with what we are dealing with. We need to make sure the information exchange between the robot and the operator is fast and as complete as possible, so that the operator can react appropriately.

• Consider using sound as well as visual for emergency situations

Our problem will require significant UAV automation as well as operator training.

This should have been more obvious to me, but there must be existing models we can use to supplement ours. For example, in terms of how and when to switch between automation and manual control, airplane operators are a good example where we can take information.

Computation Engineering - Ryan

21

Model checking is to verify finite-state model of reactive computing systems for proper behavior.

Computer systems should be reliable, and assurances should be the norm rather than the exception.

Model checking requires

• Create finite state model of system being verified
• expressing properties of system in temporal logic

Obviously, we are using a Reactive Computing System

Model checking best used in early conceptual design stages

Desired properties expressed using linear-time temporal logic or automata.

Model checking using over-approximation: assume testable state at all possible origin states

Safety Violations - something bad happens Liveness Violations - stuck in loop that doesn't include desired end state

Liveliness error for Three Philosophers: Why does Phil:1 starve? Doesn't Phil:5 release Fork:6? Page 395

22

Kripke Structures - used to model concurrent systems over time

• <S, s0, R, L>
  • S is finite set of states
  • s0 is an arbitrary start state
  • R contained in S x S is total relation known as Reachability Relation
    • The edges in a directed graph
  • L : S → 2^P
    • P is a set of atomic propositions
      • for example, boolean variables

Computational Tree Logic Syntax

• A - all paths
• G - every state along path
• E - there exists a path
• F - you can find along a path or future
• X - the next step along a path
• U - until - first holds until new requirement
• W - unless - first holds until new requirement, but new may never be reached

An LTL formula is true of a Kripke structure iff it is true of EVERY infinite path of the Kripke structure considered separately.

How exactly do you use the GFP or LFT algorithms for this? Page 413

Wilderness Research UAV - Ryan

Minimizing time to find person is a balance between quickly covering area and going slow enough that people watching camera feed can detect signs.

• Seems like at least some of this could be automated. For example, if the video were fed into a computer at the base, and it analyzed. Or, adding infrared capabilities into camera so it's easier to spot something unusual.

In rugged terrain, better to follow contours of terrain than probability

Mosaic camera views significantly better than just showing the camera feed.

Manager wanted to perform efficient search, which makes it incomplete, and the UAV was required to spend lots of time focusing on potential signs, making the search both inefficient and incomplete.

The (sensor) operator is required to direct the camera to make sure that adequate coverage occurs. Would it not be possible to automate the direction of the camera as well as the actual flight, to free the operator from that task?

We may need to have the models be flexible enough that they can change based on what search paradigm is being employed - sequential, remote-led, or base-led.