Robot Setup Home

From RoCKIn Wiki
Revision as of 21:04, 11 April 2015 by Rockinadmin (Talk | contribs) (Created page with "== Setup for motion capture == During task benchmarks, the pose of the robot will be captured by a motion capture system. For this, a "Marker Set" (provided by RoCKIn) will b...")

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

Setup for motion capture

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

top view of the Marker Set

The base of the robot must be provided with a vertical-axis M4 nut (or threaded hole) 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.

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. 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
Y = dy
Z = dz

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. Important! Teams who do not comply with the axis convention used by ROS [1] 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 "this document":http://rm.isr.ist.utl.pt/attachments/622/robot_data.txt 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 "Files" section.

Passwords

A password will be given to each team before the competition. These can be used to:

  • Set up the private communication channel with the RSBB.
  • Access the camera.

Note that security is only designed to prevent unintentional honest mistakes from the teams, like accessing the camera the camera over wi-fi while another team is executing a benchmark. Any team caught trying to hack, circumvent or change the behaviour of any component described here for any purpose will be punished.


Home automation controller networked device

A picture of the network that will be used throughout the competition in presented bellow followed by a description of each block.

!>rockin_testbed_network__3.png!

  • *Server*: A computer used to manage the network. IP address 10.0.0.1
  • *Switch*: An ethernet switch used to connect all the devices.
  • *AP*: An Access Point where the robot is supposed to connect. This is the only connection between the robot and the network.
  • *Ethernet Camera*: Perspective camera facing the Outside Hallway. IP adress 10.0.0.2 More details regarding the camera are presented bellow.
  • *Devices*: Different devices may exist in the house. The devices in the environment will be: a motor to control the window blinds, 2 controlled power plugs, 1 light dimmer, and 1 door bell button.
  • *SMARTIF IO*: This module controls the different devices/sensors existing in the house. Can only be accessed from the server. Teams do not have to interact directly with it.
  • *SMARTIF Server*: Device responsible for the communication between the SMARTIF IO mentioned above and the network. Can only be accessed from the server. Teams do not have to interact directly with it. Technical details regarding SMARTIF products can be found at the official site.

The devices are located in the following positions:

  • 2 lights (on/off) on the bedroom
  • 1 motorized blind in the living room
  • 1 light dimmer in the living room
  • 1 door bell in the outside hallway

Network Layout

The network will be 10.0.0.0/16 (netmask 255.255.0.0). The refbox will have IP 10.0.0.1 and the camera will have IP 10.0.0.2.

A network of 256 IPs will be assigned for each team to use with static IPs as the team sees fit.


|_.Team |_.IPs | |b-it-bots@Home |=.10.0.21.* /16 | |BARC |=.10.0.22.* /16 | |Delft |=.10.0.23.* /16 | |Donaxi |=.10.0.24.* /16 | |homer |=.10.0.25.* /16 | |Pumas |=.10.0.26.* /16 | |Pumas |=.10.0.27.* /16 | |REEM |=.10.0.28.* /16 | |SocRob |=.10.0.29.* /16 | |Ursus |=.10.0.30.* /16 | |Watermelon |=.10.0.31.* /16 | |ART |=.10.0.32.* /16 | |Trinity |=.10.0.33.* /16 |


RoCKIn@Home Referee, Scoring and Benchmarking Box (R@H-­RSBB)

The full RSBB is not yet available, but fully functional client libraries are available and should be integrated in the teams software.

Note that this includes the protocol to access the home automation devices and the tablet application.

Tool to create rosbags [for teams not using ROS]

The converter is available at the "Github repository":https://github.com/joaocgreis/rockin_converter with instructions.

For more information about the YAML file format that can be converted to ROS bag files, check "yaml_file_spec.pdf":http://rm.isr.ist.utl.pt/documents/46 .


Safety check and robot inspection

During the set-up days, robots will be checked by TC/OC for compliance with Robot Constraint 3.2 of the rulebook: 'Safety and Security Aspects'. Teams will be asked to show the safety mechanisms of their robots and to demonstrate their use. A live demonstration is needed: for example, pushing an emergency stop button while the robot is moving and verifying that the robot immediately stops. If the robot has other mechanical devices (e.g., arms), their safety must also be demonstrated.

This inspection can be done at any time during the set-up days. When teams are ready to do it, they can call one of the TC/OC members. The inspection can be repeated at any time during the competition days, upon request of TC/OC. Referees, TC/OC members, team members and any user who is interacting with the robot are always allowed to use the safety mechanisms when there is a clear risk for the safety of any person or for the damage of any part of the environment.

  • Robots that are not considered safe by TC/OC will not be allowed to participate to the competition!*


Start/Restart/End procedures for the TBM tests

This section specifies the procedures that will be followed to start/restart/end each of the TBM tests.

Start procedure

The robots must be prepared outside the apartment, in particular in a preparation area outside one of the doors that has been designed to start the test. This preparation area is reserved for the next team in the schedule and can be accessed about 5 minutes before the start of the test. Any other preparation must be done at the team table or in any other location that does not interfere with the competition.

The referee will announce the team 2 minutes before the start of the test that the test will start in 2 minutes *sharp*. After 2 minutes, the referee will start the test, i.e. s/he starts the timer (no delays for any reason). From this moment the robot is allowed to enter the apartment. If the robot is not ready and team members are still working on it after the test is started there will be no penalty, but the time will run on. Whenever the robot enters the apartment, the team is not allowed to operate on the robot in any way (e.g., touching any device, using mouse, keyboard, touch screen, also remotely). Only the actions described in the test are allowed inside the apartment.

For each test, a desired location that the robot has to reach inside the apartment will be communicated to the teams during the set-up days. Entering the apartment must be done with a natural behavior (no joystick, keyboard, remote control, etc.). Autonomous navigation is the preferred solution. Following a person (e.g., a team member) is also fine. Using a nice easy-to-use interface may be considered a natural behavior by TC, however this must be approved by TC before the test. In case of non-fully autonomous behaviors, the teams *must* verify with the TC in advance that their solution is suitable.

If you think you are preparing a behavior that is not within this scope for some test, contact the TC by e-mail *now* or as soon as possible.


Restart procedure

Within the first 2 minutes after the robot enters the apartment and within the first 5 minutes from the start of the test, the team can call for a restart. In this case team members are allowed to enter the apartment, bring the robot outside it and do any operation on the robot. It is not allowed to fix the problem inside the apartment (even if it is a quick and simple operation). Whenever the robot is ready, it can re-enter the arena and restart the test. The restart can be done only once for each run of the test. No penalties will be given for a restart, but any score achieved before the restart will be canceled and the time will not be stopped during the restart procedure.


Exit procedure

After the end of the test, as communicated by the referee, the robots must quickly exit the apartment from the exit door designated for the test (which is usually different from the entrance door). Team members are allowed to manually drive, push or lift the robot. A penalty (in terms of an absolute negative score) will be given to the team if the robot is not outside the arena 2 minutes after the end of the test.