Hi @Ray_student,

Could you explain a little bit what are you trying to do and what are your problems, because after reading the post I noticed you did not mention any problem or asked any question.

Hi thanks for your comment. I met most problem is I don't know what is correct result. now I just get a topic /odom_filter but no any information.

When you use the efk or ufk nodes you should provide first a config file to stablish all necessary parameters. In this file you provide, apart from the frames, the set of odometry topics to extract the odom info in order to perform the fusion. Once you provide the proper topics the node will output a topic in wich you will find the odom fusion from all of your sources. The default topic name is odometry/filtered and you can remap it in the launch file.

Hence, the correct result depends on your sep up. As I see in your config file you are performing a fusion with odom and imu data, taking with odom only vx, vy, vz, and vyaw and with imu vyaw and ax. This means that, with your set up, you are only using velocity and acceleration to perform localization.

You will find more information about robot_localization package here.

I know more about this knowledge . Very thank you. but I notice that if I launch this

roslaunch turtlebot3_bringup turtlebot3_remote.launch

the topic : odometry/filtered will get information .

I don't understand the connection between this situation. Seems to be related to robot_state_publisher?

Mmm, the robot_state_publisher is a node that only generates the tf_tree with the robot_description (turtlebot in this case), the node itselft does not publish in any topic, only reads from /joint_states. You can execute rostopic info odometry/filtered to check what connections are using that topic. However, the topic is getting some information because the localization node is using the tf_tree generated to properly set up the odom and map frames. The param publish_tf is a flag to activate the publish transformations and map_frame, odom_frame, base_link_frame and world_frame specifies four principal coordinate frames for the robot. Generally, if you are using Gazebo, you already have the tf transform base_link-->base_footprint-->odom, thats is why I think you have information in that topic. However, ideally you may want to, not only base the localization in tf but input all your odometry topic to let the kalman filter do its job in the way it was designed.

Sorry for the late reply I am following this video now

https://www.youtube.com/watch?v=cmOplaq8cHc

about 22:18 he is finishing his launch file,I have some problems he is work on simulated environment and robot model not turtlebot3 , so I don’t know what he did first. I think this is necessary

roslaunch turtlebot3_bringup turtlebot3_robot.launch

And after referring to your statement ,robot_state_publisher is not necessary here?

I think your explanation is very clear, but I am still a little confused.

Hi @Ray_student,

So basically what he is doing is setting up the localization stack for the robot. He launches three instances of the robot_localization.

1. The first one is the efk_node used to filter encoders odometry with IMU data to obtain a more precisse odometry from the robot in the odom frame.
2. The second one is another efk_node used to filter encoders odometry, IMU and GPS data to obtain the localization of the robot in the map frame. The frame is important because the robot will be navigating in the map frame NOT in the odom frame.
3. The third one is the navstat_transform node, that he uses to convert fix GPS coordiantes (latitude/longitude/altitude) into UTM coordinates that can be used in the efk_filter in the map coordinate frame with the proper axis conventions stablished is ROS.

Hence, with this set up, you have first a good odometry from encoders and IMU and then a good localization in map with that odometry and the GPS data converted in UTM.

Thank you for your patience.

I understand what he is doing. now I want to solve my problem directly.

1.As far as I understand,I need to be prepared right topic for robot_localization(/odom , /imu) , And now I ’m using turtlebot3 ’s OPENCR to provide these information Through execution

rosrun rosserial_python serial_node.py _port:/dev/ttyACM0 _baud:=115200

2.So I don’t need to use robot_state_publisher at this point if I just want to fuse sensor data(and efk_node will set tf ?). Because in that video, I did not find any clue about robot_state_publisher.

Thanks again for your patience.

Or should I use the original turtlebot3_navigation for localizaion , And only fuse GPS data into odom?

Hi. To sum up: the first thing you need is the odom and imu topics. With this two topic you generate a odometry in the odom frame. Then, you need to convert you GPS data from lat/lon to UTM, and from UTM to local coordinates in your navigation frame (generally map frame). Finally you need to set up correctly your tf_frames with the robot_state_publisher and add to this tree the odom frame: base_link-->base_footprint-->odom. Then when you launch the ekf_node so it will build the transform between the odom and the map (navigation frame) thus localizing the robot within this frame.

About the fact that he is not using a robot_state_publisher you can check this line that is launching the RSP. It has no logic that you do not have a RSP because you need the full tf_tree of your robot in order to navigate properly.

About using the turtlebot3_navigation set up you can usie it but take into accout that it uses AMCL for localization not EFK. So you will need a LiDAR or a range sensor instead of a GPS. It depends on what you want to do becasuse if you plan in navigating outdoors maybe AMCL approach is not the most suitable for that set up, because likely you will not have good range data to compare with your map.

Oh! I noticed!

So if I now need run robot_state_publisher ,should I provide any document (.xml?)

No, for the RSP to work you only need the robot description to be launched. The robot_state_publisher will read from the /join_states topic and build the tf_tree from the robot_description parameter.