ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2023-03-13 07:22:46 -0500 | marked best answer | Yaw shifting on not moving outdoor robot with robot localization I am using robot_localization package for the localization of a robot placed outdoors and equipped with RTK GPS, wheel odometry and IMU.
When the robot is placed somewhere and is not moving, I can notice that there is a drift in the yaw output of the filtered odometry. Also, when the robot starts moving we notice in Rviz that the robot performs a full rotation around itself before moving forward, while the raw IMU measurements do not show any such rotation. Below is the configuration that I use with the robot_localization for odom->base link. For map->odom transformation, the configuration is below. (more) |
2022-10-19 08:05:50 -0500 | received badge | ● Critic (source) |
2022-09-27 08:59:10 -0500 | commented question | Zed ros wrapper [SEARCHING] stuck What do you mean by wrong values for position? Could you please post some sample messages? |
2022-09-21 03:49:11 -0500 | answered a question | publishers priority Twist mux (http://wiki.ros.org/twist_mux) is the package that implements exactly this functionality. |
2022-09-14 18:47:16 -0500 | received badge | ● Famous Question (source) |
2022-08-26 06:16:46 -0500 | edited question | Yaw shifting on not moving outdoor robot with robot localization Yaw shifting on not moving outdoor robot with robot localization I am using robot_localization package for the localizat |
2022-08-26 06:15:49 -0500 | commented question | Yaw shifting on not moving outdoor robot with robot localization By looking the raw IMU data from the robot, we notice that there is a small drift in the measuments, so you're right thi |
2022-08-26 05:18:35 -0500 | commented question | Yaw shifting on not moving outdoor robot with robot localization I added a sample message from each sensor input above. |
2022-08-26 05:18:27 -0500 | commented question | Yaw shifting on not moving outdoor robot with robot localization I added a sample messages from each sensor input above. |
2022-08-26 05:18:09 -0500 | edited question | Yaw shifting on not moving outdoor robot with robot localization Yaw shifting on not moving outdoor robot with robot localization I am using robot_localization package for the localizat |
2022-08-26 03:29:12 -0500 | received badge | ● Notable Question (source) |
2022-08-25 08:12:30 -0500 | received badge | ● Nice Question (source) |
2022-08-25 08:03:43 -0500 | received badge | ● Popular Question (source) |
2022-07-21 10:26:22 -0500 | asked a question | Yaw shifting on not moving outdoor robot with robot localization Yaw shifting on not moving outdoor robot with robot localization I am using robot_localization package for the localizat |
2021-10-18 04:00:03 -0500 | commented question | Ros Drivers/Libraries for FLIR VUE PRO thermal cam? Have you found a solution on this? |
2021-04-22 09:02:41 -0500 | answered a question | TopicDiagnostic: "Timestamps too far in future seen" but timestamps are correct. I had exactly the same issue and finally the problem was that the GPS antenna was not tightly mounted, even though the G |
2021-04-13 20:09:40 -0500 | received badge | ● Student (source) |
2021-04-03 08:06:22 -0500 | commented question | Prevent rosbridge buffering unsent messages Has any progress been made on this? |
2021-03-23 02:55:17 -0500 | received badge | ● Famous Question (source) |
2021-03-23 02:55:17 -0500 | received badge | ● Notable Question (source) |
2021-03-23 02:55:17 -0500 | received badge | ● Popular Question (source) |
2021-03-18 11:10:19 -0500 | received badge | ● Famous Question (source) |
2021-03-01 11:42:52 -0500 | commented question | Set offset to local costmap and rotate with robot Have you found any solution about the rotation of the costmap, so that it aligns with the robot orientation? |
2021-01-29 09:30:56 -0500 | received badge | ● Notable Question (source) |
2021-01-29 08:32:23 -0500 | commented answer | Robot_localization services /toLL and /fromLL respond with different result Alright, I will file an issue asap. Thanks a lot! |
2021-01-29 08:30:47 -0500 | marked best answer | Robot_localization services /toLL and /fromLL respond with different result I am using the robot_localization package and in the terminal, I run the services /fromLL and /toLL for the same position. But the results do not agree. Specifically, running: returns: And when I run: I get which is the same position as the first one. |
2021-01-29 08:09:27 -0500 | commented question | Robot_localization services /toLL and /fromLL respond with different result I am on ROS melodic and robot_localization has been installed using apt-get. Version 2.6.9 as mentioned in the package.x |
2021-01-25 13:33:38 -0500 | commented question | Robot_localization services /toLL and /fromLL respond with different result Yes, it was the current Lat/Long of the robot. If I'm not wrong there was a UTM->map transform at that time, using th |
2021-01-25 11:06:43 -0500 | received badge | ● Popular Question (source) |
2021-01-14 13:51:16 -0500 | commented question | Robot_localization services /toLL and /fromLL respond with different result I am running these services through the terminal, when running the node, so there is not a way to define in which frame |
2021-01-14 09:41:46 -0500 | asked a question | Robot_localization services /toLL and /fromLL respond with different result Robot_localization services /toLL and /fromLL respond with different result I am using the robot_localization package an |
2020-12-08 07:29:14 -0500 | received badge | ● Popular Question (source) |
2020-12-08 07:29:14 -0500 | received badge | ● Notable Question (source) |
2020-10-26 11:17:32 -0500 | received badge | ● Famous Question (source) |
2020-10-07 02:24:40 -0500 | received badge | ● Famous Question (source) |
2020-10-05 08:15:25 -0500 | received badge | ● Rapid Responder (source) |
2020-10-05 08:15:25 -0500 | answered a question | Navigation Stack Error - TF Exception that should never happen for sensor fram You are somewhere defining the frame as /frame_name. But, since ROS Melodic (probably, I'm not sure) you have to define |
2020-10-01 13:57:26 -0500 | received badge | ● Famous Question (source) |
2020-09-17 06:57:35 -0500 | received badge | ● Self-Learner (source) |
2020-09-16 08:40:20 -0500 | marked best answer | Change NDT matching TF transform frame in Autoware I am using Autoware 1.14 in ROS Melodic, installed from source and built with CUDA. Specifically, my system's TF tree is as follows: When I am using the NDT Matching algorithm, it provides a transform So, I thought to change the NDT algorithms's (matching and mapping) source code, so that they provide a transform from Does this sound correct? Or is there any other way to make this work? |
2020-09-16 08:40:16 -0500 | answered a question | Change NDT matching TF transform frame in Autoware In order to solve this problem, I made the lidar_localizer nodes totally independent from the rest of the Autoware packa |
2020-09-16 08:37:07 -0500 | received badge | ● Notable Question (source) |
2020-08-20 00:09:27 -0500 | received badge | ● Popular Question (source) |
2020-08-17 09:50:36 -0500 | asked a question | Change NDT matching TF transform frame in Autoware Change NDT matching TF transform frame in Autoware I am using Autoware 1.14 in ROS Melodic, installed from source and bu |
2020-08-10 01:40:46 -0500 | received badge | ● Nice Answer (source) |
2020-08-08 02:44:23 -0500 | received badge | ● Famous Question (source) |