Only released in EOL distros:
Package Summary
Provides a library to STDR Simulator, to parse yaml and xml description files.
- Maintainer status: maintained
- Maintainer: Chris Zalidis <zalidis AT gmail DOT com>
- Author: Manos Tsardoulias, Chris Zalidis, Aris Thallas
- License: GPLv3
- External website: http://stdr-simulator-ros-pkg.github.io
- Bug / feature tracker: https://github.com/stdr-simulator-ros-pkg/stdr_simulator/issues
- Source: git https://github.com/stdr-simulator-ros-pkg/stdr_simulator.git (branch: hydro-devel)
Package Summary
Provides a library to STDR Simulator, to parse yaml and xml description files.
- Maintainer status: developed
- Maintainer: Chris Zalidis <zalidis AT gmail DOT com>
- Author: Manos Tsardoulias, Chris Zalidis, Aris Thallas
- License: GPLv3
- External website: http://stdr-simulator-ros-pkg.github.io
- Bug / feature tracker: https://github.com/stdr-simulator-ros-pkg/stdr_simulator/issues
- Source: git https://github.com/stdr-simulator-ros-pkg/stdr_simulator.git (branch: indigo-devel)
Package Summary
Provides a library to STDR Simulator, to parse yaml and xml description files.
- Maintainer status: developed
- Maintainer: Chris Zalidis <zalidis AT gmail DOT com>
- Author: Manos Tsardoulias, Chris Zalidis, Aris Thallas
- License: GPLv3
- External website: http://stdr-simulator-ros-pkg.github.io
- Bug / feature tracker: https://github.com/stdr-simulator-ros-pkg/stdr_simulator/issues
- Source: git https://github.com/stdr-simulator-ros-pkg/stdr_simulator.git (branch: indigo-devel)
Package Summary
Provides a library to STDR Simulator, to parse yaml and xml description files.
- Maintainer status: developed
- Maintainer: Chris Zalidis <zalidis AT gmail DOT com>
- Author: Manos Tsardoulias, Chris Zalidis, Aris Thallas
- License: GPLv3
- External website: http://stdr-simulator-ros-pkg.github.io
- Bug / feature tracker: https://github.com/stdr-simulator-ros-pkg/stdr_simulator/issues
- Source: git https://github.com/stdr-simulator-ros-pkg/stdr_simulator.git (branch: indigo-devel)
Contents
- 
Overview- How the stdr_parser works
- Using YAML files
- Using XML files
- 
stdr_specifications.xml- environment
- map
- map_specifications
- origin
- robot
- robot_specifications
- initial_pose
- pose
- footprint
- footprint_specifications
- points
- point
- laser
- laser_specifications
- noise
- noise_specifications
- sonar
- sonar_specifications
- rfid
- rfid_specifications
- kinematic
- kinematic_specifications
- rfid_tag
- x
- y
- theta
- max_angle
- min_angle
- max_range
- min_range
- num_rays
- frequency
- frame_id
- frequency
- noise_std
- noise_std
- cone_angle
 
 
Overview
stdr_parser is a Yaml/XML parser created for STDR Simulator. Its job is to parse resource files (robots and sensors) and create the according stdr_msgs. Also, provided a stdr_msgs message stdr_parser can save it to a Yaml or XML file. The parser structure is such that it can be "easily" extended with more file types (such as JSON f.e.) by changing only specific source files (the filetype parser and writer). A brief overview of the parsing steps follow.
How the stdr_parser works
Step 1 : Recursive file parsing
stdr_parser takes as input a Yaml or XML file and initially does a "blind" parsing of the file, meaning that no validation is performed. Of course if the file does not exist or is malformed, a ParserException is thrown. This initial parsing creates a tree consisting of stdr_parser::Node objects and represents the initial file. As the following sections describe, for convenience reasons you can have filename tags in your robot or sensor file, which are used for including other resources (for example in a robot you can include laser and sonar sensors without writing them from the scratch). During the parsing the specific filenames are parsed also recursively.
When a filename tag is found, during the parsing step, a stdr_parser::Node is created tagged as filename. For example a robot XML resource follows:
<robot>
  <robot_specifications>
    <footprint>
      <radius>0.3</radius>
    </footprint>
    <laser>
      <filename>hokuyo.xml</filename>
      <laser_specifications>
        <pose>
          <theta>1.57</theta>
        </pose>
      </laser_specifications>
    </laser>
  </robot_specifications>
<robot>where hokuyo.xml ,may contain the following (not fully functional, just to showcase):
<laser>
  <laser_specifications>
    <max_range>4</max_range>
    <pose>
      <x>0</x>
      <y>0</y>
      <theta>0</theta>
    </pose>
    <noise>
      <filename>gauss_small.xml</filename>
    </noise>
  </laser_specifications>
</laser>and the gauss_small.xml
<noise>
  <noise_specifications>
    <noise_mean>0</noise_mean>
    <noise_std>0.03</noise_std>
  </noise_specifications>
</noise>In addition, every stdr_parser::Node contains a level value that is increased when the recurrent file depth increases. After the first step, the tree will look like that (the levels in [ ]):
├ robot [0] │ ├ robot_specifications [0] │ │ ├ footprint [0] │ │ │ ├ radius [0] │ │ │ │ ├ 0.3 [0] │ │ ├ laser [0] │ │ │ ├ filename [0] │ │ │ │ ├ laser [1] │ │ │ │ │ ├ laser_specifications [1] │ │ │ │ │ │ ├ max_range [1] │ │ │ │ │ │ │ ├ 4 [1] │ │ │ │ │ │ ├ pose [1] │ │ │ │ │ │ │ ├ x [1] │ │ │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ │ │ ├ y [1] │ │ │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ │ │ ├ theta [1] │ │ │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ │ ├ noise [1] │ │ │ │ │ │ │ ├ filename [1] │ │ │ │ │ │ │ │ ├ noise [2] │ │ │ │ │ │ │ │ │ ├ noise_specifications [2] │ │ │ │ │ │ │ │ │ │ ├ noise_mean [2] │ │ │ │ │ │ │ │ │ │ │ ├ 0 [2] │ │ │ │ │ │ │ │ │ │ ├ noise_std [2] │ │ │ │ │ │ │ │ │ │ │ ├ 0.03 [2] │ │ │ ├ laser_specifications [0] │ │ │ │ ├ pose [0] │ │ │ │ │ ├ theta [0] │ │ │ │ │ │ ├ 1.57 [0]
Step 2 : 'filename' tag elimination
The second step is to eliminate the filename tags from the tree. To do so a sanity check is performed: the parent node and the child node of a filename node must be the same. If the above holds, the filename node is eliminated, as well as its child and the child's children are connected to filename's parent. The result follows:
├ robot [0] │ ├ robot_specifications [0] │ │ ├ footprint [0] │ │ │ ├ radius [0] │ │ │ │ ├ 0.3 [0] │ │ ├ laser [0] │ │ │ ├ laser_specifications [1] │ │ │ │ ├ max_range [1] │ │ │ │ │ ├ 4 [1] │ │ │ │ ├ pose [1] │ │ │ │ │ ├ x [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ ├ y [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ ├ theta [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ ├ noise [1] │ │ │ │ │ ├ noise_specifications [2] │ │ │ │ │ │ ├ noise_mean [2] │ │ │ │ │ │ │ ├ 0 [2] │ │ │ │ │ │ ├ noise_std [2] │ │ │ │ │ │ │ ├ 0.03 [2] │ │ │ ├ laser_specifications [0] │ │ │ │ ├ pose [0] │ │ │ │ │ ├ theta [0] │ │ │ │ │ │ ├ 1.57 [0]
Step 3 : Node merging
The third step is the recursive node merging. In this step the stdr_multiple_allowed.xml file under stdr_resources/resources/specifications is of crucial importance. There, the tags that can have multiple occurrences under a specific tag are placed. The current implementation allows multiple occurrences in these tags:
- robot
- laser
- sonar
All the other tags are recursively merged, if multiple occurrences exist under any other tag. The tree after this step follows:
├ robot [0] │ ├ robot_specifications [0] │ │ ├ footprint [0] │ │ │ ├ radius [0] │ │ │ │ ├ 0.3 [0] │ │ ├ laser [0] │ │ │ ├ laser_specifications [1] │ │ │ │ ├ max_range [1] │ │ │ │ │ ├ 4 [1] │ │ │ │ ├ pose [1] │ │ │ │ │ ├ x [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ ├ y [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ ├ theta [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ │ ├ 1.57 [0] │ │ │ │ ├ noise [1] │ │ │ │ │ ├ noise_specifications [2] │ │ │ │ │ │ ├ noise_mean [2] │ │ │ │ │ │ │ ├ 0 [2] │ │ │ │ │ │ ├ noise_std [2] │ │ │ │ │ │ │ ├ 0.03 [2]
Step 4 : Value merging
In this step we have supposedly merged all the possible tags and we are prepared to merge the value nodes. Here the level value plays its role, as during the value merging, the values with higher level are overridden by those with lower level. This helps to easily write resource files by changing only some aspects of the included files (in the specific example the robot has a laser but the scientist wants to change the laser's orientation). The final tree follows:
├ robot [0] │ ├ robot_specifications [0] │ │ ├ footprint [0] │ │ │ ├ radius [0] │ │ │ │ ├ 0.3 [0] │ │ ├ laser [0] │ │ │ ├ laser_specifications [1] │ │ │ │ ├ max_range [1] │ │ │ │ │ ├ 4 [1] │ │ │ │ ├ pose [1] │ │ │ │ │ ├ x [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ ├ y [1] │ │ │ │ │ │ ├ 0 [1] │ │ │ │ │ ├ theta [1] │ │ │ │ │ │ ├ 1.57 [0] │ │ │ │ ├ noise [1] │ │ │ │ │ ├ noise_specifications [2] │ │ │ │ │ │ ├ noise_mean [2] │ │ │ │ │ │ │ ├ 0 [2] │ │ │ │ │ │ ├ noise_std [2] │ │ │ │ │ │ │ ├ 0.03 [2]
Step 5 : Validation
This is the final parsing step where the validation is performed. Crucial role plays the stdr_specifications.xml file under stdr_resources/resources/specifications. There for every valid tag, the allowed and required children are specified. (Look at the end of the page for the file's contents). The validation step reads this file and performs allowed and required checks for all tree nodes.
Message creation / saving messages to files
After the tree is fully created, stdr_parser can create the according stdr_msgs. This is performed seamlessly by using templates. An example of creating a stdr_msgs::RobotMsg follows:
stdr_msgs::RobotMsg msg = stdr_parser::Parser::createMessage<stdr_msgs::RobotMsg>("simple_robot.yaml");In a similar way a stdr_msgs message can be saved to a Yaml or XML file:
stdr_msgs::RobotMsg msg = stdr_parser::Parser::createMessage<stdr_msgs::RobotMsg>("simple_robot.yaml");
stdr_parser::Parser::saveMessage(msg,"test.xml");
Exceptions
If anything goes wrong an ParserException is thrown. The way to use it in a source code file follows:
  try
  {
    stdr_parser::Parser::saveMessage(
      stdr_parser::Parser::createMessage
      <stdr_msgs::RobotMsg>      //!< Type
      ("pandora_robot.yaml"),    //!< Input file
      "test.xml"            //!< Output file
    );
  }
  catch(ParserException ex)
  {
    ROS_ERROR(" === STDR PARSER ERROR ===\n%s",ex.what());
  }The ParserException exceptions hold a trail of the error for better debugging. Example:
STDR parser : noidse_mean is not allowed in a noise_specifications tag Trail: [noidse_mean] Line 17 of file 'hokuyo_laser_4L.xml' [noise] Line 16 of file 'hokuyo_laser_4L.xml' [laser_specifications] Line 14 of file 'hokuyo_laser_4L.xml' [laser] Line 14 of file 'pandora_robot.xml' [robot_specifications] Line 52 of file 'pandora_robot.xml' [robot] Line 2 of file 'pandora_robot.xml' [STDR_Parser_Root_Node] Line 1 of file 'pandora_robot.xml'
Using YAML files
In this section typical (and fully functional) YAML file examples for the five basic message types will be provided.
Noise
noise:
  noise_specifications:
    mean: 0.5
    std: 0.200000002980232
Footprint
footprint:
  footprint_specifications:
    radius: 0.5
Laser
laser:
  laser_specifications:
    max_angle: 2.35619258880615
    min_angle: -2.35619258880615
    max_range: 4
    min_range: 0
    num_rays: 270
    noise:
      noise_specifications:
        mean: 0.5
        std: 0.200000002980232
    frequency: 10
    frame_id: laser_0
    pose:
      x: 0.100000001490116
      y: 0
      theta: 0
Sonar
sonar:
  sonar_specifications:
    max_range: 3
    min_range: 0.300000011920929
    cone_angle: 0.523598313331604
    noise:
      filename: noises/noise_gauss.yaml
    frequency: 10
    frame_id: sonar_0
    pose:
      x: 0.100000001490116
      y: 0
      theta: 0
Robot
robot:  
  robot_specifications:
    - footprint:
        footprint_specifications:
          radius: 0.15
    - initial_pose:
        theta: 0
        x: 0
        y: 0
    - laser:
        filename: laser_sensors/hokuyo_laser_4L.yaml
        laser_specifications: 
          max_range: 10
    - sonar:
        filename: range_sensors/standard_sonar.yaml
        sonar_specifications:
          frame_id: sonar_0
          pose:
            x: 0.100000001490116
            y: 0
            theta: 0
    - sonar:
        filename: range_sensors/standard_sonar.yaml
        sonar_specifications:
          frame_id: sonar_1
          pose:
            x: 0
            y: 0.100000001490116
            theta: 1.570795
    - sonar:
        filename: range_sensors/standard_sonar.yaml
        sonar_specifications:
          frame_id: sonar_2
          pose:
            x: 0
            y: -0.100000001490116
            theta: -1.570795
    - sonar:
        filename: range_sensors/standard_sonar.yaml
        sonar_specifications:
          frame_id: sonar_3
          pose:
            x: -0.100000001490116
            y: -0.100000001490116
            theta: 2.79252444444444
    - sonar:
        filename: range_sensors/standard_sonar.yaml
        sonar_specifications:
          frame_id: sonar_4
          pose:
            x: -0.100000001490116
            y: 0.100000001490116
            theta: 3.49065555555556
Using XML files
In this section typical (and fully functional) XML file examples for the five basic message types will be provided.
Noise
<noise>
  <noise_specifications>
    <noise_mean>0.1</noise_mean>
    <noise_std>0.01</noise_std>
  </noise_specifications>
</noise>
Footprint
<footprint>
  <footprint_specifications>
    <radius>0.5</radius>
  </footprint_specifications>
</footprint>
Laser
<laser>
  <laser_specifications>
    <max_angle>1.570795</max_angle>
    <min_angle>-1.570795</min_angle>
    <max_range>4.0</max_range>
    <min_range>0.1</min_range>
    <num_rays>270</num_rays>
    <frequency>10</frequency>
    <pose>
      <x>0</x>
      <y>0</y>
      <theta>0</theta>
    </pose>
    <noise>
      <filename>noises/noise_gauss.xml</filename>
      <noise_specifications>
        <noise_mean>0.5</noise_mean>
        <noise_std>0.05</noise_std>
      </noise_specifications>
    </noise>
  </laser_specifications>
</laser>
Sonar
<sonar>
  <sonar_specifications>
    <cone_angle>0.87</cone_angle>
    <max_range>3.0</max_range>
    <min_range>0.15</min_range>
    <frequency>10</frequency>
    <pose>
      <x>0.1</x>
      <y>0</y>
      <theta>0</theta>
    </pose>
    <noise>
      <filename>noises/noise_gauss.xml</filename>
    </noise>
  </sonar_specifications>
</sonar>
Robot
<robot>
  <robot_specifications>
    <footprint>
      <footprint_specifications>
        <radius>0.2</radius>
      </footprint_specifications>
    </footprint>
    <initial_pose>
      <x>0</x>
      <y>0</y>
      <theta>0</theta>
    </initial_pose>
    <laser>
      <filename>laser_sensors/hokuyo_laser_4L.xml</filename>
    </laser>
    <sonar>
      <filename>range_sensors/standard_sonar.xml</filename>
      <sonar_specifications>
        <pose>
          <x>0.1</x>
        </pose>
      </sonar_specifications>
    </sonar>
    <sonar>
      <filename>range_sensors/standard_sonar.xml</filename>
      <sonar_specifications>
        <pose>
          <y>0.1</y>
          <theta>1.570795</theta>
        </pose>
      </sonar_specifications>
    </sonar>
    <sonar>
      <filename>range_sensors/standard_sonar.xml</filename>
      <sonar_specifications>
        <pose>
          <y>-0.1</y>
          <theta>-1.570795</theta>
        </pose>
      </sonar_specifications>
    </sonar>
    <sonar>
      <filename>range_sensors/standard_sonar.xml</filename>
      <sonar_specifications>
        <pose>
          <x>-0.1</x>
          <y>-0.1</y>
          <theta>2.79252444444444</theta>
        </pose>
      </sonar_specifications>
    </sonar>
    <sonar>
      <filename>range_sensors/standard_sonar.xml</filename>
      <sonar_specifications>
        <pose>
          <x>-0.1</x>
          <y>0.1</y>
          <theta>3.49065555555556</theta>
        </pose>
      </sonar_specifications>
    </sonar>
  </robot_specifications>
</robot>
stdr_specifications.xml
- The contents of the stdr_specifications.xml file follow (not all tags are functional in the current STDR Simulator version): 
environment
- allowed - map,robot,rfid_tag
 
- required - map
 
map
- allowed - filename,map_specifications
 
- required - map_specifications
 
map_specifications
- allowed - image,resolution,origin,free_thresh,negate,occupied_thresh
 
- required - image,resolution
 
origin
- allowed - x,y,theta
 
- required - -
 
robot
- allowed - filename,robot_specifications
 
- required - robot_specifications
 
robot_specifications
- allowed - initial_pose,footprint,laser,sonar,rfid,kinematic
 
- required - -
 
initial_pose
- allowed - x,y,theta
 
- required - -
 
pose
- allowed - x,y,theta
 
- required - -
 
footprint
- allowed - filename,footprint_specifications
 
- required - footprint_specifications
 
footprint_specifications
- allowed - radius,points
 
- required - -
 
points
- allowed - point
 
- required - -
 
point
- allowed - x,y
 
- required - x,y
 
laser
- allowed - filename,laser_specifications
 
- required - laser_specifications
 
laser_specifications
- allowed - max_angle,min_angle,max_range,min_range,num_rays,frequency,frame_id,pose,noise
 
- required - -
 
noise
- allowed - filename,noise_specifications
 
- required - noise_specifications
 
noise_specifications
- allowed - noise_mean,noise_std
 
- required - -
 
sonar
- allowed - filename,sonar_specifications
 
- required - sonar_specifications
 
sonar_specifications
- allowed - cone_angle,max_range,min_range,frequency,frame_id,pose,noise
 
- required - -
 
rfid
- allowed - filename,rfid_specifications
 
- required - rfid_specifications
 
rfid_specifications
- allowed - angle_span,signal_cutoff,max_range,frequency,frame_id,pose
 
- required - -
 
kinematic
- allowed - filename,kinematic_specifications
 
- required - kinematic_specifications
 
kinematic_specifications
- allowed - type
 
- required - type
 
rfid_tag
- allowed - x,y,message
 
- required - x,y
 
x
- default - 0
 
y
- default - 0
 
theta
- default - 0
 
max_angle
- default - 1.57
 
min_angle
- default - -1.57
 
max_range
- default - 4
 
min_range
- default - 0
 
num_rays
- default - 180
 
frequency
- default - 10
 
frame_id
frequency
- default - 0
 
noise_std
- default - 0
 
noise_std
- default - 0.3
 
cone_angle
- default - 1.0
 








