robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.4.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version crystal-devel
Last Updated 2019-01-16
Dev Status DEVELOPED
Released UNRELEASED

Package Description

Provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Plugins

No plugins found.

Recent questions tagged robot_localization at answers.ros.org

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.4.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version bouncy-devel
Last Updated 2019-04-26
Dev Status DEVELOPED
Released UNRELEASED

Package Description

Provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

No launch files found

Messages

No message files found.

Plugins

No plugins found.

Recent questions tagged robot_localization at answers.ros.org

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.6.4
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version melodic-devel
Last Updated 2019-04-26
Dev Status DEVELOPED
Released RELEASED

Package Description

Provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://docs.ros.org/melodic/api/robot_localization/html/index.html

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

  • launch/dual_ekf_navsat_example.launch
    • This launch file provides an example of how to work with GPS data using robot_localization. It runs three nodes: (1) An EKF instance that fuses odometry and IMU data and outputs an odom-frame state estimate (2) A second EKF instance that fuses the same data, but also fuses the transformed GPS data from (3) (3) An instance of navsat_transform_node, which takes in GPS data and produces pose data that has been transformed into your robot's world frame (here, map). The node produces a map-frame state estimate. The first EKF instance produces the odom->base_link transform. The second EKF produces the map->odom transform, but requires the odom->base_link transform from the first instance in order to do so. See the params/dual_ekf_navsat_example.yaml file for parameter specification.
  • launch/ekf_nodelet_template.launch
    • This launch file provides an example of how to use ekf as nodelet or as node in one launch file. By providing arguments like "use_nodelets this launch file will start a nodelet instead of a node. This is very usefull in experimental setup to allow easy switch between nodelets and node. Also it allows you to specify the manager the nodelet should run in.
      • use_nodelets [default: ${optenv USE_NODELETS false)]
      • nodelet_manager [default: $optenv robot_localization_NODELET_MANAGER robot_localization_nodelet_manager)]
  • launch/ukf_template.launch
  • launch/navsat_transform_template.launch
    • 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 world 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 the template parameter file (params/navsat_transform_template.yaml). (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 the template parameter file. (3) The latitude, longitude, and altitude can be provided by: (a) a sensor_msgs/NavSatFix message (b) the "datum" service. See the template parameter file. (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. Optionally, the node can also produce a NavSatFix message corresponding to the filtered odometry, transformed back into lat/long coordinates. The node can also optionally publish the transform from the UTM frame the the world frame.
  • launch/ekf_template.launch

Messages

No message files found.

Plugins

Recent questions tagged robot_localization at answers.ros.org

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.5.6
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version lunar-devel
Last Updated 2019-02-15
Dev Status DEVELOPED
Released RELEASED

Package Description

Provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

  • launch/dual_ekf_navsat_example.launch
    • This launch file provides an example of how to work with GPS data using robot_localization. It runs three nodes: (1) An EKF instance that fuses odometry and IMU data and outputs an odom-frame state estimate (2) A second EKF instance that fuses the same data, but also fuses the transformed GPS data from (3) (3) An instance of navsat_transform_node, which takes in GPS data and produces pose data that has been transformed into your robot's world frame (here, map). The node produces a map-frame state estimate. The first EKF instance produces the odom->base_link transform. The second EKF produces the map->odom transform, but requires the odom->base_link transform from the first instance in order to do so. See the params/dual_ekf_navsat_example.yaml file for parameter specification.
  • launch/ekf_nodelet_template.launch
    • This launch file provides an example of how to use ekf as nodelet or as node in one launch file. By providing arguments like "use_nodelets this launch file will start a nodelet instead of a node. This is very usefull in experimental setup to allow easy switch between nodelets and node. Also it allows you to specify the manager the nodelet should run in.
      • use_nodelets [default: ${optenv USE_NODELETS false)]
      • nodelet_manager [default: $optenv robot_localization_NODELET_MANAGER robot_localization_nodelet_manager)]
  • launch/ukf_template.launch
  • launch/navsat_transform_template.launch
    • 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 world 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 the template parameter file (params/navsat_transform_template.yaml). (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 the template parameter file. (3) The latitude, longitude, and altitude can be provided by: (a) a sensor_msgs/NavSatFix message (b) the "datum" service. See the template parameter file. (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. Optionally, the node can also produce a NavSatFix message corresponding to the filtered odometry, transformed back into lat/long coordinates. The node can also optionally publish the transform from the UTM frame the the world frame.
  • launch/ekf_template.launch

Messages

No message files found.

Plugins

Recent questions tagged robot_localization at answers.ros.org

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.4.7
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version kinetic-devel
Last Updated 2019-02-15
Dev Status DEVELOPED
Released RELEASED

Package Description

Provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

  • launch/dual_ekf_navsat_example.launch
    • This launch file provides an example of how to work with GPS data using robot_localization. It runs three nodes: (1) An EKF instance that fuses odometry and IMU data and outputs an odom-frame state estimate (2) A second EKF instance that fuses the same data, but also fuses the transformed GPS data from (3) (3) An instance of navsat_transform_node, which takes in GPS data and produces pose data that has been transformed into your robot's world frame (here, map). The node produces a map-frame state estimate. The first EKF instance produces the odom->base_link transform. The second EKF produces the map->odom transform, but requires the odom->base_link transform from the first instance in order to do so. See the params/dual_ekf_navsat_example.yaml file for parameter specification.
  • launch/ukf_template.launch
  • launch/navsat_transform_template.launch
    • 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 world 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 the template parameter file (params/navsat_transform_template.yaml). (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 the template parameter file. (3) The latitude, longitude, and altitude can be provided by: (a) a sensor_msgs/NavSatFix message (b) the "datum" service. See the template parameter file. (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. Optionally, the node can also produce a NavSatFix message corresponding to the filtered odometry, transformed back into lat/long coordinates. The node can also optionally publish the transform from the UTM frame the the world frame.
  • launch/ekf_template.launch

Messages

No message files found.

Plugins

No plugins found.

Recent questions tagged robot_localization at answers.ros.org

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.3.4
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version indigo-devel
Last Updated 2018-12-19
Dev Status DEVELOPED
Released RELEASED

Package Description

Provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

  • launch/dual_ekf_navsat_example.launch
    • This launch file provides an example of how to work with GPS data using robot_localization. It runs three nodes: (1) An EKF instance that fuses odometry and IMU data and outputs an odom-frame state estimate (2) A second EKF instance that fuses the same data, but also fuses the transformed GPS data from (3) (3) An instance of navsat_transform_node, which takes in GPS data and produces pose data that has been transformed into your robot's world frame (here, map). The node produces a map-frame state estimate. The first EKF instance produces the odom->base_link transform. The second EKF produces the map->odom transform, but requires the odom->base_link transform from the first instance in order to do so. See the params/dual_ekf_navsat_example.yaml file for parameter specification.
  • launch/ukf_template.launch
  • launch/navsat_transform_template.launch
    • 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 world 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 the template parameter file (params/navsat_transform_template.yaml). (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 the template parameter file. (3) The latitude, longitude, and altitude can be provided by: (a) a sensor_msgs/NavSatFix message (b) the "datum" service. See the template parameter file. (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. Optionally, the node can also produce a NavSatFix message corresponding to the filtered odometry, transformed back into lat/long coordinates. The node can also optionally publish the transform from the UTM frame the the world frame.
  • launch/ekf_template.launch

Messages

No message files found.

Plugins

No plugins found.

Recent questions tagged robot_localization at answers.ros.org

No version for distro ardent. Known supported distros are highlighted in the buttons above.

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 2.3.1
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version jade-devel
Last Updated 2017-03-28
Dev Status DEVELOPED
Released RELEASED

Package Description

The robot_localization package provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

  • launch/dual_ekf_navsat_example.launch
    • This launch file provides an example of how to work with GPS data using robot_localization. It runs three nodes: (1) An EKF instance that fuses odometry and IMU data and outputs an odom-frame state estimate (2) A second EKF instance that fuses the same data, but also fuses the transformed GPS data from (3) (3) An instance of navsat_transform_node, which takes in GPS data and produces pose data that has been transformed into your robot's world frame (here, map). The node produces a map-frame state estimate. The first EKF instance produces the odom->base_link transform. The second EKF produces the map->odom transform, but requires the odom->base_link transform from the first instance in order to do so. See the params/dual_ekf_navsat_example.yaml file for parameter specification.
  • launch/ukf_template.launch
  • launch/navsat_transform_template.launch
    • 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 world 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 the template parameter file (params/navsat_transform_template.yaml). (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 the template parameter file. (3) The latitude, longitude, and altitude can be provided by: (a) a sensor_msgs/NavSatFix message (b) the "datum" service. See the template parameter file. (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. Optionally, the node can also produce a NavSatFix message corresponding to the filtered odometry, transformed back into lat/long coordinates. The node can also optionally publish the transform from the UTM frame the the world frame.
  • launch/ekf_template.launch

Messages

No message files found.

Plugins

No plugins found.

Recent questions tagged robot_localization at answers.ros.org

robot_localization package from robot_localization repo

robot_localization

Package Summary

Tags No category tags.
Version 1.2.2
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/cra-ros-pkg/robot_localization.git
VCS Type git
VCS Version hydro-devel
Last Updated 2015-05-27
Dev Status DEVELOPED
Released RELEASED

Package Description

The robot_localization package provides nonlinear state estimation through sensor fusion of an abritrary number of sensors.

Additional Links

Maintainers

  • Tom Moore

Authors

  • Tom Moore

robot_localization

robot_localization is a package of nonlinear state estimation nodes. The package was developed by Charles River Analytics, Inc.

Please see documentation here: http://wiki.ros.org/robot_localization

CHANGELOG

Could not convert RST to MD: No such file or directory - pandoc

Wiki Tutorials

See ROS Wiki Tutorials for more details.

Source Tutorials

Not currently indexed.

Launch files

Messages

No message files found.

Services

Plugins

No plugins found.

Recent questions tagged robot_localization at answers.ros.org