ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

No, I don't think your setup will work, although I haven't thought through it in great depth. In any case, it's not the way it's intended to be used. The odometry input to navsat_transform_node can just be your ekf_localization_node output (it defaults to odometry/filtered). navsat_transform_node needs the third input (the odometry from your state estimate) because it converts the GPS data into the coordinate frame of that message. Also, if your robot starts out, for example, indoors, and then moves outdoors, you need to know its pose estimate at the moment it starts receiving GPS in order to make the transformed GPS data consistent with your current state estimate.

For you, as soon as your IMU data is fed to the filter, ekf_localization_node will produce a state estimate, at which point navsat_transform_node will have all the data it needs.

No, I don't think your setup will work, although I haven't thought through it in great depth. In any case, it's not the way it's intended to be used. The odometry input to navsat_transform_node can just be your ekf_localization_node output (it defaults to odometry/filtered). navsat_transform_node needs the third input (the odometry from your state estimate) because it converts the GPS data into the coordinate frame of that message. Also, if If your robot starts out, for example, indoors, and then moves outdoors, you need to know its pose estimate at the moment it starts receiving GPS in order to make the transformed GPS data consistent with your current state estimate.

For you, as soon as your IMU data is fed to the filter, ekf_localization_node will produce a state estimate, at which point navsat_transform_node will have all the data it needs.

No, I don't think your setup will work, although I haven't thought through it in great depth. In any case, it's not the way it's intended to be used. The odometry input to navsat_transform_node can just be your ekf_localization_node output (it defaults to odometry/filtered). navsat_transform_node needs the third input (the odometry from your state estimate) because it converts the GPS data into the coordinate frame of that message. If your robot starts out, for example, indoors, and then moves outdoors, you need to know its pose estimate at the moment it starts receiving GPS in order to make the transformed GPS data consistent with your current state estimate.

For you, as soon as your IMU data is fed to the filter, ekf_localization_node will produce a state estimate, at which point navsat_transform_node will have all the data it needs.

EDIT in response to question:

Your final setup will be this:

ekf_localization_node

  • Inputs

    • IMU
    • Transformed GPS data as an odometry message (navsat_transform_node output)
  • Outputs

    • Odometry message (this is what you want to use as your state estimate for your robot)

navsat_transform_node

  • Inputs

    • IMU
    • Raw GPS (NavSatFix)
    • Odometry (output of ekf_localization_node)
  • Outputs

    • Transformed GPS data as odometry message

The data path is circular, but it's necessary. Once navsat_transform_node gets the first odometry message input from ekf_localization_node, it drops its subscription.

No, I don't think your setup will work, although I haven't thought through it in great depth. In any case, it's not the way it's intended to be used. The odometry input to navsat_transform_node can just be your ekf_localization_node output (it defaults to odometry/filtered). navsat_transform_node needs the third input (the odometry from your state estimate) because it converts the GPS data into the coordinate frame of that message. If your robot starts out, for example, indoors, and then moves outdoors, you need to know its pose estimate at the moment it starts receiving GPS in order to make the transformed GPS data consistent with your current state estimate.

For you, as soon as your IMU data is fed to the filter, ekf_localization_node will produce a state estimate, at which point navsat_transform_node will have all the data it needs.

EDIT in response to question:

Your final setup will be this:

ekf_localization_node

  • Inputs

    • IMU
    • Transformed GPS data as an odometry message (navsat_transform_node output)
  • Outputs

    • Odometry message (this is what you want to use as your state estimate for your robot)

navsat_transform_node

  • Inputs

    • IMU
    • Raw GPS (NavSatFix)
    • Odometry (output of ekf_localization_node)
  • Outputs

    • Transformed GPS data as odometry message

The data path is circular, but it's necessary. Once navsat_transform_node gets the first odometry message input from ekf_localization_node, IMU message, it drops its the subscription.