Robot Setup Work

From RoCKIn Wiki
Revision as of 18:18, 19 November 2015 by BRSU (Talk | contribs) (Synchronization with the benchmarking system)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Functionality Benchmarks

All functionality benchmarks of @Work will take place in a designated area of the @Work testbed. There will be no podium as in the last year. The FBM will be performed on the ground floor and the objects (e.g. for FBM1 and FBM2) will be placed on a workstation.

Setup for motion capture

During the benchmarks, the pose of the robot will be captured by a motion capture system. To enable this, it is mandatory for each participating robot to be fitted with a "Marker Set" (provided by RoCKIn). The instruction to do that are provided by the Marker Set page of this wiki. For FBM3, a different marker set, suitable for gripping with the end effector of the robot, will be provided.

Setup for pose logging

Example of testbed reference frame for RoCKIn@Work. Z axis points towards the reader. NOTE: the official testbed reference frame is labeled in the testbed itself. You can find it on the center of the arena (i.e. on the walls of the squared box).

During task benchmarks, robots are required to log pose data (see "List of variables to be logged" for each benchmark). These data must be expressed in the reference frame of the testbed.

The reference frame will be clearly marked on the testbed. It will be possible for teams to define such frame in their robot before the start of the competition. The following picture shows a possible testbed reference frame.

Saving robot data

RoCKIn requires that robots save some data when executing the benchmarks. The modalities for this are explained by "this document".

Important! While the content of the data files saved by the robot is not used for scoring, the existence of such files and their compliance to the specifications does influence the score of the robot. Teams have the responsibility of ensuring that the required data files are saved, and of delivering them to the referee at the end of the benchmark. These aspects will be noted on the score sheet and considered for team ranking.

Network Infrastructure

The @Work central factory hub and the robots will be connected through WLAN with each other. In order to do not stress the bandwidth of this network the access to this wireless network will be limited (MAC filter), i.e. each robot of a team and @Work central factory hub get access. Additionally, we allow at most one client from each team, e.g. a PC which the team uses to connect to and work with the robot. Please do not stream any pointclouds, images or any other large data for a long time over the wireless network.


  • SSID: RoCKIn-AtWork
  • Security: WPA/WPA2 Personal
  • Key: will be provided on site

IP Addresses

Within the WLAN a dhcp server assigns the ip address to the clients. Each client will always get the same ip address: The teams should use the 'Benchmarking Box & NTP Server' address to synchronize the clocks of their robots.

Name IP address MAC address
Central Factory Hub (CFH)
Benchmarking Box & NTP Server (Clock)

Synchronization with the benchmarking system

In order to benchmark the performance of the robots these should be time-synchronized with the benchmarking system. To achieve this, Network Time Protocol (NTP) synchronization and Chrony are required.

With Chrony installed, modify the following file /etc/chrony/chrony.conf to look like this:

server minpoll 2 maxpoll 4
initstepslew 2
keyfile /etc/chrony/chrony.keys
commandkey 1
driftfile /var/lib/chrony/chrony.drift
maxupdateskew 5
dumpdir /var/lib/chrony
pidfile /var/run/
logchange 0.5
rtcfile /etc/chrony.rtc
rtcdevice /dev/rtc 
sched_priority 1   
local stratum 10
# log measurements statistics tracking rtc
# logdir /var/log/chrony

Once setup, you should check the synchronization is working appropriately with the following command:

watch chronyc tracking

It is highly recommended to do this validation every time before a benchmark. A quick way to determine if this is working appropriately is to check that system time has at least four leading zeros after the decimal point (e.g. 0,00007755).

RoCKIn@Work Central Factory Hub

The @Work Central Factory Hub or CFH is is an adaption of the "RoboCup Logistics League Sponsored by Festo (LLSF) referee box", and can be download on RoCKIn's Github repository here. Please make sure that you checkout the "rockin" branch of the repository to have the correct version. After cloning the repository to your local machine, please follow the instructions in the "README file" to install the prerequisites and to get the Central Factory Hub compiled successfully. In case of any error during the installation or compilation process, please write an email with a short description together with the complete error message(s) to the "RoCKIn@Work OC/TC mailing list".

Central Factory Hub-Communication

The communication of the Central Factory Hub is based on "boost asio" and "protocol buffer messages". An example on how to use boost asio and protobuf messages to communicate with the Central Factory Hub can be found "here"

General Remark:

  1. The robot team communicates only with the Central Factory Hub.
  2. Command messages for controlling the networked devices (DrillingMachineCommand, ConveyorBeltCommand, CameraCommand) are sent to the RoCKIn@Work Central Factory Hub which will be forwarded by the Central Factory Hub to the designated device(s). The team robot will know that the command has been executed by the status messages (DrillingMachineStatus, ConveyorBeltStatus, CameraStatus)
  3. Every part in the factory has a unique identifier as described in Section "Objects" above.
  4. Every important locations (workstation, shelves) in the factory has a unique identifier as described in Section "Locations" above.

Central Factory Hub-Messages

All messages to communicate with the Central Factory Hub (CFH) can be found in the "official repository of the RoCKIn@Work Central Factory Hub". But not all message are required yet. The following list summarizes the messages to be used by the teams within the different task and functionality benchmarks:

Msg Name Filename Direction Interval Short Description
BeaconSignal BeaconSignal.proto robot -> CFH 1 sec this message is send as a kind of "alive signal".
BenchmarkState BenchmarkState.proto CFH -> robots 1 sec A status message which describe the state of the benchmark/test. This includes information of the state (INIT, RUNNING, PAUSED, FINISHED), time, phase (NONE, TBM, FBM), available teams, connected teams and the mode of the CFH (STANDALONE, MASTER, SLAVE).
CameraCommand Camera.proto robot -> CFH once The command message for the quality control camera in order to request an image.
ConveyorBeltStatus ConveyerBelt.proto CFH -> robots 0.1 sec The status message of the conveyor belt. There are two possible status of the conveyor belt (STOP, START)
ConveyorBeltCommand ConveyerBelt.proto robot -> CFH once The command message for the conveyor belt. There are two available commands for the operating the the conveyor belt (STOP, START)
DrillingMachineStatus DrillingMachine.proto CFH -> robots 0.1 sec The status message of the drilling machine. There are five possible states of the drilling machine (AT_TOP, AT_BOTTOM, MOVING_UP, MOVING_DOWN, UNKNOWN)
DrillingMachineCommand DrillingMachine.proto robot -> CFH once The command message for operating the drilling machine. There are two available commands for controlling the drilling machine (MOVE_DOWN and MOVE_UP)
Image Image.proto CFH -> robot once The data message containing the captured image by the quality control camera.
Inventory Inventory.proto CFH -> robots 1 sec The information message which provide a list of of parts (message Item) in the factory and its location
Order Order.proto CFH -> robots 1 sec The information message containing the description of one order. This include the status (OFFERED, TIMEOUT, IN_PROGRESS, PAUSED, ABORTED, FINISHED), its identification number, identification for the object (message ObjectIdentifier), identification of the container where the object is being placed (message ObjectIdentifier), the quantity of the object which are currently already delivered and the quantity of the object requested in the order originally, the designated delivery destination (message LocationIdentifier) and the original placement of the object before delivery (message LocationIdentifier)

Tool to create rosbags

You need to use at least ROS Hydro (for the audio messages):

sudo apt-get install ros-${ROS_DISTRO}-audio-common-msgs libyaml-dev

To download the converter, follow "this link" [GitHub repository] and compile as a normal ROS package. To run, use the following command:

rosrun rockin_converter rockin_converter FILE1.yaml FILE2.yaml ...

There are two utils to check that base 64 conversion is being done correctly:

rosrun rockin_converter base64_encode < INPUT_BINARY_FILE > OUTPUT_BASE64_FILE
rosrun rockin_converter base64_decode < INPUT_BASE64_FILE > OUTPUT_BINARY_FILE

For more information about the YAML file format that can be converted to ROS bag files, follow "this link".