| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org |
 | 1 | initial version |
I'd have to see a sample odometry message, but just based on your description and launch file, my best guess is that you're having a transform issue. ekf_localization_node needs at least one message from one input source before it starts producing a state estimate. In your case, it will produce (a) an odometry message as /odometry/filtered, and (b) a transform from map->odom. Again, it will not produce either until it receives at least one message from one of its input sources. The problem is that your /odom message that you are using as input odom0 probably has a frame_id of odom. In order to use that message, the filter first needs to transform it into the world_frame specified in the launch file, which in this case is map. Since ekf_localization_node itself is responsible for producing that transform, and it hasn't produced a state estimate yet, the transform doesn't exist. It's a chicken-or-egg problem. The easiest way to get around it is to start producing messages for your other input source, /my_pose.
| | 2 | No.2 Revision |
I'd have to see a sample odometry message, but just based on your description and launch file, my best guess is that you're having a transform issue. ekf_localization_node needs at least one message from one input source before it starts producing a state estimate. In your case, it will produce (a) an odometry message as /odometry/filtered, and (b) a transform from map->odom. Again, it will not produce either until it receives at least one message from one of its input sources. The problem is that your /odom message that you are using as input odom0 probably has a frame_id of odom. In order to use that message, the filter first needs to transform it into the world_frame specified in the launch file, which in this case is map. Since ekf_localization_node itself is responsible for producing that the map->odom transform, and it hasn't produced a state estimate yet, the transform doesn't exist. It's a chicken-or-egg problem. The easiest way to get around it is to start producing messages for your other input source, /my_pose.
| | 3 | No.3 Revision |
I'd have to see a sample odometry message, but just based on your description and launch file, my best guess is that you're having a transform issue. ekf_localization_node needs at least one message from one input source before it starts producing a state estimate. In your case, it will produce (a) an odometry message as /odometry/filtered, and (b) a transform from map->odom. Again, it will not produce either until it receives at least one message from one of its input sources. The problem is that your /odom message that you are using as input odom0 probably has a frame_id of odom. In order to use that message, the filter first needs to transform it into the world_frame specified in the launch file, which in this case is map. Since ekf_localization_node itself is responsible for producing the map->odom transform, and it hasn't produced a state estimate yet, the transform doesn't exist. It's a chicken-or-egg problem. The easiest way to get around it is to start producing messages for your other input source, /my_pose.
EDIT: actually, after looking again at your odom0 configuration, it appears that you're only fusing velocity, which should work. Can you post a sample /odom message?
| | 4 | No.4 Revision |
I'd have to see a sample odometry message, but just based on your description and launch file, my best guess is that you're having a transform issue. ekf_localization_node needs at least one message from one input source before it starts producing a state estimate. In your case, it will produce (a) an odometry message as /odometry/filtered, and (b) a transform from map->odom. Again, it will not produce either until it receives at least one message from one of its input sources. The problem is that your /odom message that you are using as input odom0 probably has a frame_id of odom. In order to use that message, the filter first needs to transform it into the world_frame specified in the launch file, which in this case is map. Since ekf_localization_node itself is responsible for producing the map->odom transform, and it hasn't produced a state estimate yet, the transform doesn't exist. It's a chicken-or-egg problem. The easiest way to get around it is to start producing messages for your other input source, /my_pose.
EDIT: actually, after looking again at your odom0 configuration, it appears that you're only fusing velocity, which should work. Can you post a sample /odom message?
EDIT 2 in response to comment: If you are using amcl to do global localization, then what do you gain from running ekf_localization_node? Regardless, you can't have two nodes publishing the same transform, so you'll have to stop one of them from publishing it. If amcl supports turning off the map->odom transform, then you can do that, and instead feed its output to ekf_localization_node as an additional input. I've not tried this before, but as long as the message type is correct, it may work.
Also, your frame_ids in the message you posted start with a forward slash, e.g., "/odom" and "/base_link." You should remove the forward slashes.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
