No version for distro humble showing indigo. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.0.10
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/RobotnikAutomation/summit_xl_common.git
VCS Type git
VCS Version indigo-devel
Last Updated 2017-10-06
Dev Status MAINTAINED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The summit_xl_localization package

Additional Links

Maintainers

  • Elena Gambaro
  • Carlos Villar

Authors

No additional authors.
README
No README found. See repository README.
CHANGELOG

Changelog for package summit_xl_localization

1.0.10 (2016-09-01)

  • summit_xl_localization: commented robot_localization launch files
  • summit_xl_localization: updated robot_localization launch files
  • summit_xl_localization: added navsat_transform_new to CMakeLists.txt
  • 1.0.9
  • updated changelog
  • Contributors: Marc Bosch-Jorge, carlos3dx

1.0.9 (2016-08-24)

  • Adding install rules
  • Deleting unused files
  • Added rl_utils.launch
  • Contributors: Jorge Arino, summit

1.0.8 (2016-07-12)

1.0.7 (2016-07-12)

  • updated changelog
  • Contributors: carlos3dx

1.0.6 (2016-07-12)

1.0.5 (2016-07-05)

1.0.4 (2016-06-30)

  • added dependency
  • Contributors: carlos3dx

1.0.3 (2016-06-29)

1.0.2 (2016-06-28)

1.0.1 (2016-06-28)

  • indigo-1.0.0
  • added simple script to test magnetometer
  • Merge branch 'indigo-devel' of https://github.com/RobotnikAutomation/summit_xl_common into indigo-devel Conflicts: summit_xl_localization/launch/navsat_transform_node.launch
  • configuration tested in Lisbon uploaded
  • summit_xl_localization: added dependency to robotnik_msgs
  • Topic name change
  • Minor changes
  • Update launch files. Add robot_localization_utils
  • Update robot_localization_odom.launch
  • Frame name change
  • Add local_tf node
  • Static tf update
  • Add launch files and the new navsat_transform node
  • First commit summit_xl_localization
  • Contributors: Elena Gambaro, ElenaFG, Jorge Arino, mcantero, rguzman
  • added simple script to test magnetometer
  • Merge branch 'indigo-devel' of https://github.com/RobotnikAutomation/summit_xl_common into indigo-devel Conflicts: summit_xl_localization/launch/navsat_transform_node.launch
  • configuration tested in Lisbon uploaded
  • summit_xl_localization: added dependency to robotnik_msgs
  • Topic name change
  • Minor changes
  • Update launch files. Add robot_localization_utils
  • Update robot_localization_odom.launch
  • Frame name change
  • Add local_tf node
  • Static tf update
  • Add launch files and the new navsat_transform node
  • First commit summit_xl_localization
  • Contributors: Elena Gambaro, ElenaFG, Jorge Arino, rguzman

Launch files

  • launch/navsat_transform_node.launch
    • This comes from the navsat_transform_template.launch. Explains what this node does. This node needs to know the values of three variables in order to function: (1) A world-referenced heading (yaw). The node assumes an ENU standard for heading, with 0 facing east, though it can support any heading. (2) Odometry data that gives the robot's current pose in its own local coordinate frame (typically map or odom) (3) A latitude/longitude/altitude. These three items allow us to compute a transform from the global frame to your robot's local frame. There are several means of providing them, though keep in mind that these modes are typically mutually exclusive. (1) World-referenced yaw can be provided by: (a) an IMU in a sensor_msgs/Imu message (topic is /imu/data/) (b) the heading in the nav_msgs/Odometry message in (2) below can be used. To enable this behavior, set the use_odometry_yaw parameter to true, and set the delay parameter to some small value (~3 seconds). Be careful, though: this heading must still be globally referenced, so if your state estimation node always starts with a 0 heading, you CAN NOT use this option. (c) the "datum" service. See below. (2) The odometry data, which needs to have a valid frame_id, can be provided by: (a) a nav_msgs/Odometry message from your robot_localization state estimation node. (b) the "datum" service (all odometry variables are assumed to be 0 in this case). See below. (3) The latitude, longitude, and altitude can be provided by: (a) a sensor_msgs/NavSatFix message (b) the "datum" service (4) Alternatively, at any time, the user can send a robot_localization/SetDatum service message to the "datum" service. This will manually set the latitude, longitude, altitude, and world-referenced heading, and will assume an odometry message containing all zeros. This will effectively set the origin at the specified lat-long, with the X-axis aligned with east. The user can set this datum via the "datum" service, or via the launch file. If the wait_for_datum parameter is set to true, then the node will attempt to use the datum parameter. If the parameter is not set, it will wait until it receives a service call. The output of this node is an odometry message that contains the GPS data transformed into the robot's world coordinate frame (i.e., the frame specified by input (2)'s frame_id), or the coordinate frame defined by the message sent to the "datum" service.
      • wait_for_datum [default: false]
  • launch/rl_utils.launch
  • launch/robot_localization_complete.launch
      • debug [default: false]
      • gui [default: true]
      • wait_for_datum [default: false]
  • launch/robot_localization_odom.launch
  • launch/robot_localization_world.launch

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged summit_xl_localization at Robotics Stack Exchange