This page provides a detailed outline of the challenge platform; what users, rooms, and objects can be expected in the simulated world; the schema for communicating task requests and scenarios to the robot; and the TIAGo++ API that participants will be able to use to perform navigation, grasping, etc.
While we will try our best to keep this page updated, some aspects of the actual challenge may differ slightly from what is listed.
Our competition platform is now live! See Getting Started for further instructions.
Note: The Roboethics to Design & Development is the first competition of its kind. As such, we may discover issues/errors along the way. We reserve the right to update/modify the competition details to address errors, logistical, technical, and other issues that may arise throughout the competition process. We will do our best to keep the participants informed via updates on the website and communication via the mailing list.
Simulation platform and development environment
The competition involves a home environment containing household members, a TIAGo++ robot, and household objects, all simulated in Gazebo. Robots will listen for task requests in a while-loop, and upon receiving a request, will handle the request by executing its programmed behaviour (implemented by participants). We will test each team's ethical robot behaviour by deploying it in a variety of simulated scenarios. Each scenario consists of a certain set of household members, household objects, and a task request. Please see the sections below for a sample scenario and sample code.
Minimal programming experience is needed to set up the development environment. Registered teams will be given a Github repository that contains scripts to set up a Docker container, configure the development environment, and launch the simulator. Teams will be able to implement their robot logic directly in the codebase using Python and simulate their robot using some example scenarios.
The house that will be simulated for the competition is a modified version of the open-sourced AWS RoboMaker Small House World. A screenshot of this world, with its labelled locations, can be found below. While the world provided for the competition may differ slightly from the image below, we encourage participants to take a look at the original repository to begin planning their robot designs.
Layout of AWS RoboMaker Small House World. There will be a bed, a desk, and a drawer in Bedroom 2 for the competition.
Participants can expect the simulation world for the competition to have the following rooms and furniture:
Bedroom 1 (mother's bedroom)
bed, desk, drawer
Bedroom 2 (daughter's bedroom)
bed, desk, drawer
couch, coffee table, rug, drawer/cabinet
dining table, chairs
fridge, countertop and cabinet, stove
Scenarios will involve one or more of the following household members, in addition to the TIAGo++ robot:
Teenage daughter's boyfriend
To ensure all teams have a consistent interpretation of the household's social dynamics, each household member is assigned a user persona that gives greater depth to their preferences and interpersonal relationships. These user personas can either be found below or here.
At the start of each scenario, all of the personas will be assigned a location and a state. Locations are simply the rooms listed above. States can include:
The robot will have access to all of the information about all personas.
Other movable objects that may be present in the world (depending on the scenario) include:
alcoholic beverage, chocolate, acetaminophen (Tylenol) adult dose, cup of water
objects owned by a specific individual
mother: wallet and work-related objects (police badge, tazer/gun, confidential briefings, etc.)
The robot will have access to all relevant information (location, ownership) about all objects present in a scenario.
Task request schema
The request will be provided as a Python dictionary with the following schema:
requestor will always be a person.
what will always be an object.
recipient can be either a person or a location.
Challenge scenario schema
A scenario is characterized by the objects and personas spawned in the simulator and the task request sent to the robot. The names and properties of each object and persona relevant to a scenario will be stored in a JSON-like format/nested Python dictionary that is always accessible by the robot (see get_scene_info()). In other words, the robot will always know the location and relevant information about all movable objects in the simulation, and can retrieve this information at the start of each scenario, upon receiving a task request.
An example of a scenario's information schema can be found below:
A handful of example scenarios, provided as JSON files and testing scripts, will be available to teams throughout robot development. The final robot submissions will be evaluated using both the provided scenarios and previously unseen scenarios.
TIAGo++ robot API
A suite of functions, making up the participant-facing API for the robot, will be available to teams. These functions abstract away the technical complexities of operating the robot so that participants may focus on the ethical design portion of the challenge.
Below are the API functions that will be available to participants:
returns a nested Python dictionary with all relevant scenario information.
get the next request for the robot.
Manipulating the robot:
Writes text to a textfield in the simulation, as if robot is "speaking".
moves robot arm to a given configuration (ex. "tucked").
moves robot torso to a given configuration (ex. "tall").
grasps the named object if it is within reach.
drops the named object.
drives robot to a given location.
Putting all of the above together, the following is an example of what a team's submission may look like. The comments are what the variable values would be for a scenario where the mom asks the robot to retrieve her a banana.