Revision history [back]

Ok, so here's your setup as I see it:

ekf_localization_node instance 1:

• Inputs: wheel odometry and IMU
• Relevant parameters: world_frame is set to odom
• Outputs: local_odometry and odom->base_link transform

ekf_localization_node instance 2:

• Inputs: wheel odometry, IMU, and transformed GPS data from navsat_transform_node
• Relevant parameters: world_frame is set to map
• Outputs: odometry/filtered and map->odom transform

navsat_transform_node:

• Inputs: local_odometry, IMU, and raw GPS data
• Outputs: odometry/gps

Additionally, you are using the second instance of ekf_localization_node because you want GPS-integrated data to be available at a faster rate.

Answers and comments:

1. Both odom and map are "world frames." When your robot starts, they have the same origin. They will diverge as you move, however.
2. As I recall, move_base will let you issue a goal in any frame, but will transform it into a target frame before executing the motion commands. Someone please correct me if this is wrong. If you want to issue goals in UTM coordinates, you're in luck: there's a parameter for navsat_transform_node named broadcast_utm_transform. Set it to true. (I just realized that this wasn't documented properly on the wiki. Sorry about that.) Now you should be able to issue goals in the utm frame.
3. It's a minor point, but your odometry input to navsat_transform_node should be your odometry/filtered data from the second instance of ekf_localization_node.
4. No, you don't need gps_common per se, but the package should be installed, as I'm using a header file from it.
5. You should have no need to use set_pose. The output of navsat_transform_node is in a world-fixed frame that is aligned with your vehicle's start position and orientation. In other words, if your robot is at (4, 2) in the odom frame (ekf_localization_node instance 1), then its position, in a perfect world, would be (4, 2) in the map frame (ekf_localization_node instance 2).
6. Make sure your IMU reports in the ENU frame, and that you know what it reads when it points to magnetic north, and then make sure you set the parameters to navsat_transform_node accordingly.

Hope this helps! Let me know how it goes.

Ok, so here's your setup as I see it:

ekf_localization_node instance 1:

• Inputs: wheel odometry and IMU
• Relevant parameters: world_frame is set to odom
• Outputs: local_odometry and odom->base_link transform

ekf_localization_node instance 2:

• Inputs: wheel odometry, IMU, and transformed GPS data from navsat_transform_node
• Relevant parameters: world_frame is set to map
• Outputs: odometry/filtered and map->odom transform

navsat_transform_node:

• Inputs: local_odometry (incorrect, see below), IMU, and raw GPS data
• Outputs: odometry/gps

Additionally, you are using the second instance of ekf_localization_node because you want GPS-integrated data to be available at a faster rate.

Answers and comments:

1. Both odom and map are "world frames." When your robot starts, they have the same origin. They will diverge as you move, however.
2. As I recall, move_base will let you issue a goal in any frame, but will transform it into a target frame before executing the motion commands. Someone please correct me if this is wrong. If you want to issue goals in UTM coordinates, you're in luck: there's a parameter for navsat_transform_node named broadcast_utm_transform. Set it to true. (I just realized that this wasn't documented properly on the wiki. Sorry about that.) Now you should be able to issue goals in the utm frame.
3. It's a minor point, but your odometry input to navsat_transform_node should be your odometry/filtered data from the second instance of ekf_localization_node.
4. No, you don't need gps_common per se, but the package should be installed, as I'm using a header file from it.
5. You should have no need to use set_pose. The output of navsat_transform_node is in a world-fixed frame that is aligned with your vehicle's start position and orientation. In other words, if your robot is at (4, 2) in the odom frame (ekf_localization_node instance 1), then its position, in a perfect world, would be (4, 2) in the map frame (ekf_localization_node instance 2).
6. Make sure your IMU reports in the ENU frame, and that you know what it reads when it points to magnetic north, and then make sure you set the parameters to navsat_transform_node accordingly.

Hope this helps! Let me know how it goes.

Ok, so here's your setup as I see it:

ekf_localization_node instance 1:

• Inputs: wheel odometry and IMU
• Relevant parameters: world_frame is set to odom
• Outputs: local_odometry and odom->base_link transform

ekf_localization_node instance 2:

• Inputs: wheel odometry, IMU, and transformed GPS data from navsat_transform_node
• Relevant parameters: world_frame is set to map
• Outputs: odometry/filtered and map->odom transform

navsat_transform_node:

• Inputs: local_odometry (incorrect, see below), IMU, and raw GPS data
• Outputs: odometry/gps

Additionally, you are using the second instance of ekf_localization_node because you want GPS-integrated data to be available at a faster rate.

Answers and comments:

1. Both odom and map are "world frames." When your robot starts, they have the same origin. They will diverge as you move, however.
2. As I recall, move_base will let you issue a goal in any frame, but will transform it into a target frame before executing the motion commands. Someone please correct me if this is wrong. If you want to issue goals in UTM coordinates, you're in luck: there's a parameter for navsat_transform_node named broadcast_utm_transform. Set it to true. (I just realized that this wasn't documented properly on the wiki. Sorry about that.) Now you should be able to issue goals in the utm frame.
3. It's a minor point, but your odometry input to navsat_transform_node should be your odometry/filtered data from the second instance of ekf_localization_node.
4. No, you don't need gps_common per se, but the package should be installed, as I'm using a header file from it.
5. You should have no need to use set_pose. The output of navsat_transform_node is in a world-fixed frame that is aligned with your vehicle's start position and orientation. In other words, if your robot is at (4, 2) in the odom frame (ekf_localization_node instance 1), then its position, in a perfect world, would be (4, 2) in the map frame (ekf_localization_node instance 2).
6. Make sure your IMU reports in the ENU frame, and that you know what it reads when it points to magnetic north, and then make sure you set the parameters to navsat_transform_node accordingly.

Hope this helps! Let me know how it goes.

  <!--My IMU doesn't have compas-->

Ok, so here's your setup as I see it:

ekf_localization_node instance 1:

• Inputs: wheel odometry and IMU
• Relevant parameters: world_frame is set to odom
• Outputs: local_odometry and odom->base_link transform

ekf_localization_node instance 2:

• Inputs: wheel odometry, IMU, and transformed GPS data from navsat_transform_node
• Relevant parameters: world_frame is set to map
• Outputs: odometry/filtered and map->odom transform

navsat_transform_node:

• Inputs: local_odometry (incorrect, see below), IMU, and raw GPS data
• Outputs: odometry/gps

Additionally, you are using the second instance of ekf_localization_node because you want GPS-integrated data to be available at a faster rate.

Answers and comments:

1. Both odom and map are "world frames." When your robot starts, they have the same origin. They will diverge as you move, however.
2. As I recall, move_base will let you issue a goal in any frame, but will transform it into a target frame before executing the motion commands. Someone please correct me if this is wrong. If you want to issue goals in UTM coordinates, you're in luck: there's a parameter for navsat_transform_node named broadcast_utm_transform. Set it to true. (I just realized that this wasn't documented properly on the wiki. Sorry about that.) Now you should be able to issue goals in the utm frame.
3. It's a minor point, but your odometry input to navsat_transform_node should be your odometry/filtered data from the second instance of ekf_localization_node.
4. No, you don't need gps_common per se, but the package should be installed, as I'm using a header file from it.
5. You should have no need to use set_pose. The output of navsat_transform_node is in a world-fixed frame that is aligned with your vehicle's start position and orientation. In other words, if your robot is at (4, 2) in the odom frame (ekf_localization_node instance 1), then its position, in a perfect world, would be (4, 2) in the map frame (ekf_localization_node instance 2).
6. Make sure your IMU reports in the ENU frame, and that you know what it reads when it points to magnetic north, and then make sure you set the parameters to navsat_transform_node accordingly.

Hope this helps! Let me know how it goes.

EDIT 1: 1: Quick question: I noticed that in your launch file, you have this:

  <!--My IMU doesn't have compas-->

Is that still true? If so, that's going to be a problem. You need an IMU that has some knowledge of its orientation relative to north (east, really, but knowing one gives the other).

Ok, so here's your setup as I see it:

ekf_localization_node instance 1:

• Inputs: wheel odometry and IMU
• Relevant parameters: world_frame is set to odom
• Outputs: local_odometry and odom->base_link transform

ekf_localization_node instance 2:

• Inputs: wheel odometry, IMU, and transformed GPS data from navsat_transform_node
• Relevant parameters: world_frame is set to map
• Outputs: odometry/filtered and map->odom transform

navsat_transform_node:

• Inputs: local_odometry (incorrect, see below), IMU, and raw GPS data
• Outputs: odometry/gps

Additionally, you are using the second instance of ekf_localization_node because you want GPS-integrated data to be available at a faster rate.

Answers and comments:

1. Both odom and map are "world frames." When your robot starts, they have the same origin. They will diverge as you move, however.
2. As I recall, move_base will let you issue a goal in any frame, but will transform it into a target frame before executing the motion commands. Someone please correct me if this is wrong. If you want to issue goals in UTM coordinates, you're in luck: there's a parameter for navsat_transform_node named broadcast_utm_transform. Set it to true. (I just realized that this wasn't documented properly on the wiki. Sorry about that.) Now you should be able to issue goals in the utm frame.
3. It's a minor point, but your odometry input to navsat_transform_node should be your odometry/filtered data from the second instance of ekf_localization_node.
4. No, you don't need gps_common per se, but the package should be installed, as I'm using a header file from it.
5. You should have no need to use set_pose. The output of navsat_transform_node is in a world-fixed frame that is aligned with your vehicle's start position and orientation. In other words, if your robot is at (4, 2) in the odom frame (ekf_localization_node instance 1), then its position, in a perfect world, would be (4, 2) in the map frame (ekf_localization_node instance 2).
6. Make sure your IMU reports in the ENU frame, and that you know what it reads when it points to magnetic north, and then make sure you set the parameters to navsat_transform_node accordingly.

Hope this helps! Let me know how it goes.

EDIT 1: Quick question: I noticed that in your launch file, you have this:

  <!--My IMU doesn't have compas-->

Is that still true? If so, that's going to be a problem. You need an IMU that has some knowledge of its orientation relative to north (east, really, but knowing one gives the other).

EDIT in response to update 2: I'm afraid it's been some time since I used move_base. There may be someone else who's integrated it. My guess is that you want to give it your non-GPS-enabled instance (instance 1) of ekf_localization_node. Assuming move_base requires your current location and a goal location, then I would hope/think it's transforming the current location and goal location into whatever frame it wants to use. However, I think you'll want the position estimate that you give to move_base to be continuous, and your GPS position is subject to discrete jumps. If you used instance 2, then as you got nearer to the goal, your robot might suddenly change course as your GPS jumps around.

Re: the reason for needing a compass, see this page. navsat_transform_node first transforms GPS data into the UTM coordinate frame. The UTM coordinate frame has its X axis facing east and its Y axis facing north. East and north are, of course, fixed to earth. Now, when your robot starts out, it may be facing, say, northeast (+45 degrees above the east/X axis), and at UTM coordinate (1000, 1000). Let's say you drive forward 10 meters. You would be at UTM position (1007.07, 1007.07) in the UTM coordinates, but in your map (and odom or map ) frame, you should be at (10, 0). The purpose of navsat_transform_node is to output a nav_msgs/Odometry message that has converted your raw GPS location into a position that is consistent with your robot's start position and orientation. In order to do that transform, I need your current heading (+45 degrees above east). The only way to get that heading is through an earth-fixed heading reference, such as from a compass/magnetometer. Otherwise, you won't know which way you're facing with respect to the UTM grid.