|
Early in the course of this design project, it was realized that the greatest advances in user interfaces [UI] in the past ten years have been made in the realm of video games. Computer and console games alike must have clear interfaces which provide the player with both Controls and informational displays that allow for very fast response times to situations in a dynamic environment. These interfaces have developed at an incredibly rapid pace, with perhaps the pinnacle of UI design being that of so-called First-Person Shooter [FPS] games. FPS games are the most appropriate interface paradigm for a project such as USR, as they represent a three dimensional world with which the player can interact. Navigating a three-dimensional game world in search of computer-generated enemies is analogous to the task of finding injured and/or trapped victims in a USR scenario. Mapping that three-dimensional environment down to a two-dimensional computer display is simple enough using a live video feed, but making it intelligible, informative, and useful for the Robot operator is far more difficult.
Design
The most successful FPS games have very simple interfaces: the main portion of the interface is dedicated to a large viewing area that contains the game world. Small status areas around the perimeter are allocated for information regarding the player’s health and equipment. Most games also have a radar mini-map showing the direction to enemies or other players, as well as a separate screen containing a map of the current game level. The interface we ultimately used followed this format closely. However, the design of the interface module permits simple rearrangement of the visual items on the screen to enable testing different
interface configurations and looks.
Interface
The interface’s viewable layout and internal structure are defined by the relationships between a small set of configured objects, consisting of a view, viewports, visualizers, and widgets . The parameters for each type of object are specified in a configuration file, which allows the interface to be quickly reconfigured at run-time. The arrangement of these objects in the interface’s view tree determines how user interaction events and messages broadcast by one of the Robots are handled. This philosophy of highly generic code is maintained throughout the interface, which allows for operational flexibility as well as easy expansion of functionality in future updates to the interface’s capabilities.
The view defines the screen for the entire interface, as well as global parameters that apply to all viewports. The view contains some number of configured viewports and widgets, determined by the contents of the configuration file. The global view widgets are always active, and their scope is the entire interface. An example global view widget would be the keyboard shortcut for quitting the interface. No widgets are hard-coded, so even a widget as basic as quit must be specified in the configuration file.
A viewport is the display for a single visualizer, so each viewport provides some sort of information to the user. A given viewport has a defined position and dimension in the on-screen view, and each is associated with a single visualizer. A given viewport’s visibility can be toggled, so the information currently displayed in the view is contextual and dependent on the current state of the robot and/or the
interface. Each viewport contains a single visualizer for converting some information into a displayable format, as well as some number of widgets. These local viewport widgets are only active when the viewport is visible, and their scope is confined to the viewport.
A visualizer converts incoming data from a robot into a visual representation that is meaningful to the user, such as text output, an image, a status icon, or a graph. Each visualizer is associated with a message broadcast by a module on one of the configured robots. Multiple visualizers can process a given message, for example if the message contains different data types that need to be displayed separately. When a message is received, it is processed by all of the visualizers in visible viewports that are associated with the message’s originating module and robot.
A widget responds to an input event from the user, such as a mouse click, key-press, or joystick movement, and takes action based on that input. The action taken could be an internal status change, or a message that is generated and passed to a robot. Widgets that respond to a mouse click have a defined area within their parent view or viewport.
Configuration
Nearly every aspect of the interface is defined in a single XML configuration file. This includes the network connection information and metadata for each robot, the modules that should be started on each robot, the configurations for external USB controllers, such as joysticks or game-pads, as well as the layout of viewports within the view and the message and control bindings for
visualizers and widgets. While allowing all of these interface parameters to be configurable makes the configuration file large, it allows each user to have their own custom (and potentially completely
different) version of the interface. This is important from an HRI perspective, because different users may have different preferred interface layouts. Also, the interface can be quickly reconfigured to run on different computers with different available control peripherals. Since changing configurations is just a matter of restarting the interface with a different configuration file, it would be most efficient to
have several configurations available to swap in as needed. The XML format was selected because it is an open format that is easily human readable and familiar to many people due to its wide use and similarity to HTML. In addition, easily obtained open source XML parsing libraries made it easy to make the configuration process an important part of the interface. In fact, the parsing and setup code makes up over 20% of the entire code for the interface software.
Example Configuration
The example interface configurationwas used by an operator during the AAAI 2004 USR competition. It features a centered video feed, emphasizing the primary method by which most users receive their situational awareness. Superimposed on the camera image are the pan-tiltzoom indicators for the camera, which prevents the user from confusing straight ahead in the image with straight
ahead on the robot. The two displays in the lower right of the view are the range Sensors which show obstacles within a meter of the cylindrical robot that was used, and the map that is generated over the course of a run. The interface is run full-screen to avoid background clutter that might distract the operator. The green bars in the video display indicate half-meter distances on the ground place, with the first bar a meter away from the camera lens. These provide necessary scale information since the viewpoint of the robot is substantially different from that of an adult human. The user can switch between robots by using the space bar on a keyboard, which switches all of the visualizers.
Tech Materials (Free)
Human-Robot Interface Interface for managing the robot during the Urban Search and Rescue [USR] task
Calibration Techniques Set Up A Robot Cell With Work Objects
Calibration problems Things That Needs To Be Done Within Calibration
Direct Manipulation versus Interface Agents Extra Eyes or Extra Ears
Intelligent Interface Agents What is an Intelligent Interface Agent?
Interface Agents What can agents do for the user?
Robot System The Robot System
EPSON Micro PowerDrive EPSON PowerDrive Servo System ensures Maximum Robot Performance
HRP 2W Humanoid Can now serve tea and wash the cup
Robot Behaviors Exploring the T-Maze: Evolving Learning-Like Robot Behaviors using CTRNNs
More... Amazon Books
|
