Robo-Monitor - Designs

Scenario

John is a Ph.D. student in a robotics lab at the University of Michigan. Last year he was on-track to finish his thesis in two years, but this year he feels like he's still got two years left. John's project involves cooperative maneuvers on autonomous quadrocopters and he's hoping to show that his systems can build complex structures autonomously (like in the video below). He implemented his communication system via LCM channels on a wireless network and so far has been relatively happy with it.

One of John's collaborators, Craig "the theory guy" Stevenson, is in town, so John fires up his base-station computer to run a short demo. He was up late last night getting the code ready, and managed to get his new cooperative block-lifting algorithm to work. As the computer comes up, John hooks in the quads' batteries and confirms their normal startup beeps and bloops.

Once the ground-station is online, John walks into the shared motion-capture studio and places his two vehicles on their starting positions. He taps the "Robo-Monitor" app and takes a quick glance to make sure everything is online. All looks good so he hits go.

The quads jump to life and Craig unconsciously steps back. John smilies as he sees his friend watch their work in action. The test goes well until the third task when one of the helicopters refuses to move. It slowly lowers itself to the ground and remains there, idling. John glances at Craig who seems surprised but doesn't know what is wrong. John looks at his phone and sees that data is still moving on all of the channels. He takes a closer look at the "QUAD2_COMMAND" channel, but valid commands are clearly being sent.

A few weeks ago, John had some integration trouble, so he created a "debug" mode for the system. Might as well try it, he says to himself and a few taps later he is on the command channel of the Robo-Monitor app. A quick tap sends the "debug" command, and the other quad lands. A flood of new data appears on the screen and John drills down into the QUAD2 subsystems. On-board sensing seems good... battery voltage is nominal... internal temperatures are valid... embedded processors are running... plenty of free RAM... wait... looks like position isn't correct. John picks up his ailing craft and notices that velocities remain zero.

"Stupid Vicon always breaks," John tells Craig who laughs and says something derogatory about real hardware. Why would it only be one quad? John thinks and looks at the quad. "It was working last night!"

As John is thinking, Craig starts pacing and steps on a small silver ball. He asks John, "what's this," showing John the ball. "That's a Vicon marker... where did you find it?"

"On the floor over here, " Craig replies. "Could it be the problem?"

"Well, only if it came off of this one. Let's check."

"Hey, looks like it must have gotten bumped off when it picked up that last block. That would definitely do it."

Ten minutes of marker-repair later, John switches back to his app. He punches "normal operation" command to move out of debug mode and the quads jump back to life. "It's always something," says Craig. "That's why I work in simulation."

Designs

Key Aspects

We present the the criteria to which the users will hold the robo-monitor. The ordering is important - it means that if the more important aspects are not present, then the less important aspects do not matter.

Reliability

This has more to do with implementation, than with design. However, a roboticist need to be able to trust the tools that he/she is using. That means that they also need to understand conceptually how the program is working.

Visibility

A researcher needs to be able to see all the relevant information in a system monitor. Otherwise they won't be able to monitor the robot.

Efficiency

It is important for a researcher not to spend too much time adjusting the monitor - they have other more important task at hand and this is managing/debugging the robot. A good monitor will be efficient but will also allow the users to use their own speedup tricks and maybe even provide a way to script some parts.

Design Elements (for the first two designs)

Number of layouts

The first two designs use the notion of layouts. A layout is a configuration of visualisations present. A layout is created by the user, and saved as a file. The designs vary in the number of layouts that the user has available. In a multi-layout design it is easy for the user to switch between several already selected layouts.
In a single layout the user is only concentrated on one layout and swapping layouts is done less efficiently - by navigating through the whole list of layouts. Layouts are similar to tabs in functionality. Multi-layout design allows the user to organize and group visualisaitions based on common factors. A layout can be also used as a category to contain related visualisations.

Layout presentation

We consider two different ways to present the visualisations within a layout: as a list or as a 2d plane of rectangles. In the first two designs we also explore these two possible ways to present the layout. We chose to combine multi-layout with rectangular presentation and single-layout with list presentation but the other two combinations are also possible.

Rectangular Presentation of a Layout

Each visualization is contained in a rectangle (hence Rectangular) the user can move visualizations around by dragging them and change their properties by tapping on them. The screen slides to the right where the user can specify the parameters of the visualisation.

List Presentation of a Layout

All visualisations are of the same width, and are put in order. That simplifies navigation among the visualisations because the user now only needs to scroll up and down.

Multi-Layout Rectangular Design Analysis

• Visibility
  • A user opening a layout by name wouldn't know what is present on the layout. This could eventually be improved by providing a thumbnail version of what the layout may look like.
  • It may not be visible that the user can drag visualizations around by holding a tap.
• Efficiency
  • Saving and opening a layout can save time for the user who regularly uses the same setup or who needs to switch between several different setups.
  • Also, we plan to make the layout description standartized (XML or YAML) in order to allow users to create layouts automatically.
• Error prevention
  • Errors are typically accidental deletions of layouts or visualisations. To prevent layout deletion a confirmation dialogue may be shown to the user (since deleting a layout will be reasonably rare operation). Deleting a visualization will not be specifically prevented - instead it will be really easy to recover from it - just add the deleted visualization again. We might also include an undo-delete option in the menu.
• Learnability
  • The 2D shape of the layout will help users distinguish between layouts easier - without the need of reading all the labels

Single-Layout List Design Analysis

• Visibility
  • Like in the multi-layout design a user opening a layout by name wouldn't know what is present on the layout.
  • It may not be visible that the user can drag visualisations up and down by holding a tap.
• Efficiency
  • Saving and opening a layout can save time for the user who regularly uses the same setup or who needs to switch between several different setups.
  • Also, we plan to make the layout description standartized (XML or YAML) in order to allow users to create layouts automatically
• Error prevention
  • Costly errors are typically accidental deletions of layouts or visualisations. To prevent layout deletion a confirmation dialogue may be shown to the user (since deleting a layout will be reasonably rare operation). Deleting a visualization will not be specificially prevented - instead it will be really easy to recover from it - just add the deleted visualisation again. We might also include an undo-delete option in the menu.
• Learnability
  • The list layout has pretty simple structure which should allow the user to quickly understand the metaphor.

Show-All List-Based Design

This design is fundamentally different from the previous two designs - it assumes a fixed layout which always shows all the available channels in a list. In other words we can also say that this design is layout-free. It also presents visualizations differently - in the so-called graph screen which gives a visualization the full screen. Finally it introduces the ability to control a system through the Robo-monitor by sending specific messages to it. This last feature can possibly be used in the previous two designs as well.

Main Screen

The main screen shows a list of available channels and color codes them based on recent activity. Tapping a channel selects its detailed view (bottom right) which displays live graphs of any numeric quantities. Tapping a graph or number in a channel brings up the graph interface (below).

Graph screen

Graph interface fills the screen. Interaction is similar to a photograph which users are familiar with. Pinch or double-tap to zoom, drag to pan. A single tap anywhere freezes/unfreezes the graph (ie stops or starts live data being added.)

More traces can be added to the plot by pressing Menu and then selecting Add Trace. The Add Trace window appears (lower right) which allows the user to browse through available channels and variables in those channels. More than one new variable can be selected.

When graphing text, we display small colored bars at the bottom of the screen that change color when the text changes. While this does not convey what the text is, it conveys that it has changed, which may still be useful. We use a hashing strategy to display colors, so that the same text will always have the same color.

Control mode

A control mode, accessible from the Menu button on the main screen allows the user to change parameters. Options are presented as spinners which update in real-time (send data on finger-up). An interface for selecting the resolution of the spinner is shown in the lower right.

Analysis

• Visibility
  • Some options like the command menu are accessible only from the Menu option, which might cause visibility issues. This issue arises for some of the graphing screen's more advanced features as well.
  • Most data is displayed early and quickly, so data visibility is high.
• Efficiency
  • The drill-down aspect of the interface may not be the most efficient, but we expect that it is worth the organizational and learnability benefits.
• Error Prevention
  • The only serious errors that can occur with the application is in the command screen. As the interface stands, commands are sent on finger-up, but if testing reveals that this is an issue, we will likely add a Confirm button.
• Learnability
  • Most things are clickable in this interface, so learnability should be relatively easy. The graph mode has a few features that novice users are not likely to know about, but that is more a visibility issue.