Interface Specification

Gumbo User Interface

The UI will display:

• The map, which is fixed and known in advance
• The robot's current position
• The position of any hostages and active bombs seen by the robot
• History of dialogue (user commands and robot responses), ideally with some clever way to change/remove past standing orders
• The robot's current goal?
• Camera snapshot from last time one was requested?

LTLMoP Robot Control

LTLMoP controls the robot via a set of handlers (objects which handle data exchange and abstractions).

Pose handler

• The pose handler reports the robot's current position.
• Note: In terms of high-level control, this technically only needs to be as granular as the name of the current room, but a more accurate position is required for plotting on the map.

Sensor handler

• The sensor handler will read the state of robot sensors and perform any adjustments (abstractions) needed before reporting them as current state to the automaton. This includes persisting objects within a room even when the robot is not currently viewing them and filtering out any objects visible but not in the current region.

Motion handler

• LTLMoP tells the robot which room to go to. It will always instruct the robot to go to a room adjacent to the current one. As there is no guarantee that the path planner will take a path that does not pass through any region, we need to avoid any maps with multiple ways to go between regions.

• Note: Even without cycles, is this actually safe? You still have no guarantee of not spilling into a third region (i.e. neither initial-region nor target-region) during movement.

Map communication

• Q: How will we sync up the map between LTLMoP and the robot?
• A: Each will have a map file in its own format. The LTLMoP one will be auto-generated from Lowell's JSON one.