TBM2 - “Welcoming Visitors”
Clarification of procedures and rules
- There will be no audio in-/output available from the ip camera at the entry door. The teams can use the camera to identify the visitor using vision only. But the robot can use a speech dialog (at the front door) to improve the recognition capability. The team will not get a penalty if it does not use the additional speech dialog.
- Naturally, the front will be closed. The robot can choose any way of opening the door, either using its manipulator or requesting a referee, team member or the visitor to open the door (e.g. using speech). There will be +no+ penalties applied in any case. The following picture shows the handle which will be mounted at the entrance door:
Post Man and Deli Man uniforms
Deli Man and Postman uniforms can be downloaded using "this link":http://rm.isr.ist.utl.pt/attachments/514/Uniforms_RoCKIn2014.zip .
Dr. Kimble face pictures
Moro photos of Dr. Kimble face pictures can be downloaded using "this link":http://www.rockinrobotchallenge.eu/dr_kimble.zip .
Detailed pictures of the parcel can be downloaded "here":http://rm.isr.ist.utl.pt/attachments/585/Parcel.zip . The dimensions are 9.5 inches / 24.13 cm (width) x 6.5 inches / 16.51 cm (length) x 1.75 inches / 4.45 cm (height).
IP Camera networked device (as replacement for the intercom device)
There will not be a full video/audio intercom device in this year competition. There will be only a standard ip camera mounted a the front door to retrieve images from the ringing visitors.
The camera mode is an Axis P1344. The camera can have its parameters (frame rate, resolution, color gains) changed over ethernet and it is not motor controlled (no pan-tilt). Documentation can be found in http://www.axis.com/products/cam_p1344/ .
The simplest way to access the camera is by receiving the MJPEG stream published by the camera, for example in @http://team_name:PASSWORD@@@10.0.0.2/mjpg/video.mjpg@ . During the setup days, the camera can be configured directly by each team to fit the needs (with admin but not root access). The organisation will save the configs and load them before each benchmark, for the correct team. Therefore, teams are welcome to use any protocol or configuration that the camera supports.
A ROS package that can be used to acquire images from the camera can be found here: "RoAH IPCam":https://github.com/joaocgreis/roah_ipcam . Note that this is ready to use, but no guarantees are given regarding its performance. Teams are welcome to develop better and more reliable ways to communicate with the camera.
List of variables to be logged
The robot is required to log any sensor data used to perform the benchmark (e.g., identified visitor, robot pose, sensorial data). The modalities for this are explained by "this document":http://rm.isr.ist.utl.pt/attachments/622/robot_data.txt. Only relevant data is expected to be logged (i.e., the pointcloud used to classify an object, more than one if an algorithm requiring multiple pointclouds is used). There are no restriction about the framerate: data can be saved, for the relevant parts of the benchmark, at the rate they are acquired or produced. The log may be a rosbag or the corresponding YAML representation, as specified in document:"RoCKIn YAML Data File Specification".
The following are expected ROS topic names and corresponding data types:
- command [@std_msgs/String@]: the event/command causing the activation of the robot
- pose2d [@geometry_msgs/Pose2D@]: 2D pose of the robot while moving in the environment, as perceived by the robot
- pose [@geometry_msgs/Pose@]: 3D pose of the robot while moving in the environment, as perceived by the robot (if available)
- image [@sensor_msgs/Image@]: sensorial data used to recognize the visitor
- pointcloud [@sensor_msgs/PointCloud2@]: sensorial data used to recognize the visitor
- visitor [@std_msgs/String@]: the result of any attempts by the robot to detect and classify a visitor
- audio [@audio_common_msgs/AudioData@]: the audio signals of the conversation with the visitors
- notification [@std_msgs/String@]: any notifications from the robot (e.g., alarm if a visitor shows anomalous behavior)
+Important!+ Calibration parameters for cameras must be saved. This must be done also for other sensors (e.g., Kinect) that require calibration, if a calibration procedure has been applied instead of using the default values (e.g., those provided by OpenNI).