Cave Exploration

The Cave Exploration ​scenario simulates a team of robots exploring a cave searching for trapped survivors of a recent accident. The user plays the roll of collaborative leader, directing the robots to both explore the cave and rescue survivors.

Quagents Implementation

Cave exploration is implemented using Quagents for both the explorers and trapped survivors, using the Java Quagents API?. The cave explorer Quagents ("Cave Explorers") are loaded with several intelligent behaviors, including exploring unknown territory, following specific entities, rendezvousing with other entities, and rescuing trapped survivors. The user is provided access to these behaviors, as well as a message log of in-game speech and the ability to see using the robot's camera. Using these tools, the user must lead the robots in a search and rescue mission to for the trapped miners.

Environment

This scenario is executed in a deterministic, partially observable environment. Throughout the environment at [TODO] random locations trapped survivors are located. These survivors yell (using a loud say command) for help periodically. This call for help may only be heard within an intermediate radius around the survivor, so explorers must be close to hear the message. The cave explorers must explore this unknown environment to find the survivors.

The environment may be extended to contain pitfalls for the explorers to navigate around, or time limits to rescue survivors by (implemented by reducing health using director commands time interval).

Screenshot of an example enviornment

User Notes

The user interacts with the scenario through the Cave Explorer GUI (shown below). The GUI has two sections - an explorer control panel and a message log. The control panel is composed of columns, one per explorer. Each column has a name, a "look" button, and a drop down menu of behaviors. The name is the cave explorer's name to which the column is referencing. All input from the column is focused on that explorer. The "look" button allows the user to see the exploration occur through the cave explorer's "eyes" (the real world analog to this could be an onboard camera, etc.). Each column also has a drop-down menu of all explorer behaviors. The user may select any behavior at any time. The behaviors are described in more detail in the following.

User Cave Exploration GUI

Behaviors

Explore: Cave explorer will use a value-iteration algorithm to explore the unknown environment. Priority is given to exploring the environment over rescuing survivors.

Follow: Cave explorer will follow specified entity.

Wait: Cave explorer will cancel all previous behaviors and wait for new orders.

Rendezvous: Cave explorer will attempt to rendezvous with specified explorer, or will tell all explorers to rendezvous.

Recsue: Cave explorer will actively search for trapped survivors. This includes attempting to make both visual and verbal contact.

Development Notes

Scenario

The Cave Exploration scenario is implemented as an extension of the base Scenario class. It does not modify the server in any way, so the configure file for the server is set to blank. The scenario simply instantiates a previously specified number of Cave Explorers and Trapped Survivors (see below) and sends them to the instantiation of the CaveExplorationGUI. All subsequent scenario functionality is handled by the GUI.

It is important to note that the scenario may be undertaken with a Random Map?, so additional instrumentation has been added to handle map generalization.

Cave Explorer

The Cave Explorer implements QuagentExecution? to enable blackbox Quagent method execution. The class contains two onboard sensors - a CartesianSensor2D? and a Facing? sensor. This allows the explorer to maintain data on its surrounds and keep its bearing. Each behavior has one or more related functions, all within the class. These are called by the CaveExplorationGUI, in response to user events.

To change or implement new behaviors, simply modify the nominally related function (e.g., "explore()" or "rescue()"). All behaviors must retain the initial line of code, however (unless the developer intends to completely rewrite the class). This is neccesary to maintain the asynchronous behavior functionality. The class also implements its own simple message parser/interpreter. Currently, it is limited to inter-explorer messages and explorer-rescuer messages, but it is entirely possible to extend it, perhaps even to parse and interpret user speech or text input.

Trapped Survivor