You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or API help for more information.
<?xml version="1.0"?>
    <allpages gapcontinue="Robot_Setup_Work" />
      <page pageid="8" ns="0" title="Robot Setup">
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">== Setup for motion capture ==

During task benchmarks, the pose of the robot will be captured by a motion capture system. For this, a &quot;Marker Set&quot; (provided by RoCKIn) will be fitted to the robot.

[[File:marker_set-perspective_view-lowres.bmp|left|Perspective view the Marker Set (red spheres are motion capture markers)]]

[[File:marker_set-top_with_quote-lowres.png|right|top view of the Marker Set]]

&lt;u&gt;The base of the robot must be provided with a vertical-axis M4 nut (or threaded hole)&lt;/u&gt; so that the Marker Set can be screwed onto it from above. For this, on the bottom of the Marker Set (the side facing the floor) there is a protruding M4 screw (visible in the first picture). The team can freely choose the location of the M4 nut (or threaded hole). High places and/or places without nearby objects that can hide the markers are preferred. M4 is a standard ISO metric thread with an outer diameter of 4 mm.

&lt;u&gt;Teams must provide the translation between the origin of the reference frame of the base of the robot and the center of the M4 nut.&lt;/u&gt; This translation is composed of the displacements along the X, Y and Z axes of such reference frame. Precisely, each team is required to provide a text file called '''displacement.txt''' containing four lines of text having the form

X = dx&lt;br /&gt;
Y = dy&lt;br /&gt;
Z = dz&lt;br /&gt;

where dx, dy and dz must be substituted with the numerical values of the displacements described above, expressed in meters. With this file, the team specifies that the center of the M4 nut is at coordinates (dx, dy, dz) according to the reference system of the base of the robot.
&lt;u&gt;Important!&lt;/u&gt; Teams who do not comply with the axis convention used by ROS [] for axes (i.e. X pointing forward, Y pointing left, Z pointing up) must add a second text file, called '''axes_orientation.txt''' where they describe clearly, in free text, how their axes are oriented.

Files displacement.txt and (if required) axes_orientation.txt must be written on the USB key provided by RoCKIn, in the same directory where the robot writes the data required by the benchmark: see &quot;this document&quot;: for details. Please note that the files must be saved on the USB key each time the robot executes a benchmark, even if they are unchanged wrt preceding benchmarks.

Mounting the Marker Set on the robot requires that there is a free volume of space (cylinder, diameter 180 mm) above the M4 nut. The Marker Set weighs 300g approximately. The protruding screw on the bottom of the Marker Set is 25mm long.
The robot must avoid collisions between the Marker Set and other objects (when assessing collisions for scoring, the Marker Set is considered as a part of the robot).

A CAD model of the Marker Set is available in the &quot;Files&quot; section.

== Setup for pose logging ==

During task benchmarks, robots are required to log pose data (see &quot;List of variables to be logged&quot; for each benchmark). &lt;u&gt;These data must be expressed in the reference frame of the testbed.&lt;/u&gt;

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.

Example of testbed reference frame for RoCKIn@Home. Z axis points towards the reader.

== Saving robot data ==

RoCKIn requires that robots '''save some data''' when executing the benchmarks. The modalities for this are explained by &quot;this document&quot;:

&lt;u&gt;Important!&lt;/u&gt; 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.</rev>
      <page pageid="9" ns="0" title="Robot Setup Home">
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">== Link to software packages ==
The following table summarizes the main software packages needed for the ERL-SR competition and their corresponding documentation. These can be used by the teams and/or organizers to install and test both the Refbox and the communication module for communicating with the Refbox.

{| class=&quot;wikitable&quot; style=&quot;font-size:80%; width:75%;&quot;
! scope=&quot;col&quot;| 
! scope=&quot;col&quot;| To be used by
! scope=&quot;col&quot;| Software/Repository
! scope=&quot;col&quot;| Document
! scope=&quot;row&quot;| RSBB refereeing module
| Organizers
| Explained inside the corresponding repository’s readme file, and in
! scope=&quot;row&quot;| RSBB Communication module
| Teams 
| Explained inside the corresponding repository’s readme file
! scope=&quot;row&quot;| RSBB Benchmarking module
| Organizers

* The optional packages are required for independent testing. They must be installed on a separate machine to simulate the Refbox/Robot behavior.

== 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 &quot;Marker Set&quot; (provided by RoCKIn). The instruction to do that are provided by the [[Marker Set]] page of this wiki.

== Communication Diagrams ==

With the goal of simplifying the implementation of the required communication with the Referee Box (RefBox), we have designed a diagram for each FBM/TBM, representing each specific case. These diagrams were created along the already existing guide, available at, which is the most complete source for the RefBox. They are intended to be a visual support for following the guide, and should not be viewed as its replacement.
There are eight diagrams, one for each FBM and TBM, and two additional ones that represent the communication segments that are present in (almost) all of the tasks. Due to this fact, these last two are color coded (as green and red) and are used in the other diagrams to condense the diagrams. In every diagram, the suspension dots mean the part of the task that does not require communication with the RefBox.
The table below gives a brief description of the communication processes represented in each diagram. By “intermediate communication”, we mean additional communication with the RefBox besides the “standard” start - perform task - end procedure.

Please click the images to view them in detail.

&lt;gallery mode=&quot;packed&quot; widths=150px heights=150px perrow=2&gt;

&lt;gallery mode=&quot;packed&quot; widths=150px heights=150px perrow=3&gt;

&lt;gallery mode=&quot;packed&quot; widths=150px heights=150px perrow=3&gt;

{| class=&quot;wikitable&quot;
|Required communication before any task is started.
|Required communication to end a task.
|No intermediate communication, but different ending procedure. The contents of the message used for the service should be consulted in the aforementioned guide. For each object to be evaluated, the robot should answer with the end command and wait for another start procedure from the RefBox side.
|If a timeout occurs it is seen from the teams side has a change in the topic /roah_rsbb/benchmark/state to BenchmarkState.PREPARE. The robot must physically and fully stop during the STOP_ROBOT phase. Teams must comply with this rule or they will be disqualified as explained in FBM2 section of this wiki.
|No RefBox communication required at all (not even the start and end procedures).
|No intermediate communication.
|Additional communication regarding the ringing of the doorbell. As per the rulebook, before the task is over, the doorbell will ring 4 times. As such the robot should only send the end command after completing the whole task and only once.
|Additional communication regarding the use of the tablet and the operation of the devices. There are many different services to operate on the devices. The aforementioned guide should be consulted to fully comprehend the communication with the devices.

== Home Automation Controller Networked Device ==
Main content moved to rulebook Section 2.4 (&quot;Networked Devices in the Environment&quot;)

The following networked devices will be located in the RoCKIn@Home environment:

* 2x light switches (on/off) in the bedroom
* 1x motorized blind in the living room
* 1x light dimmer in the living room
* 1x door bell at the main entrance

== Network Layout ==

The network will be (netmask 

Common IP addresses:
*  RSBB: 
*  Ethernet camera: 

Each team receives an own subnet (256 available IPs) to be used with static IPs:
{| class=&quot;wikitable&quot;
|10.0.21.* /16
|10.0.22.* /16
|10.0.23.* /16
|.10.0.24.* /16
|10.0.25.* /16
|10.0.26.* /16
|10.0.28.* /16
|10.0.29.* /16
|10.0.30.* /16
|10.0.31.* /16
|10.0.32.* /16
|10.0.33.* /16