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

kosmastsk's profile - activity

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.
I am using one instance for odom->base_link transform, only with wheel odometry and IMU. The map-> base_link transform is using wheel odometry, IMU and the GPS. Why is this happening?

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.

frequency: 30
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.2
print_diagnostics: true
debug: false
publish_tf: true

map_frame: map
odom_frame: robot_odom
base_link_frame: robot_base_footprint
world_frame: robot_odom

# Wheel odometry:
odom0: wheel_odom
odom0_config: [false, false, false,
               false, false, false,
               true,  true,  false,
               false, false, false,
               false, false, false]
odom0_queue_size: 10
odom0_nodelay: false
odom0_differential: true
odom0_relative: false

# imu configure:
imu0: imu/data
imu0_config: [false, false, false,
          false,  false, true,
          false, false, false,
          false,  false,  true,
          false,  false,  false]
imu0_nodelay: true
imu0_differential: true
imu0_relative: false
imu0_queue_size: 10
imu0_remove_gravitational_acceleration: true
gravitational_acceleration: 9.7530

initial_estimate_covariance: [1.0,  0,    0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                          0,    1.0,  0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                          0,    0,    1e-9, 0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                          0,    0,    0,    1.0,  0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                          0,    0,    0,    0,    1.0,  0,    0,    0,    0,    0,     0,     0,     0,    0,    0,
                          0,    0,    0,    0,    0,    1e-9, 0,    0,    0,    0,     0,     0,     0,    0,    0,
                          0,    0,    0,    0,    0,    0,    1.0,  0,    0,    0,     0,     0,     0,    0,    0,
                          0,    0,    0,    0,    0,    0,    0,    1.0,  0,    0,     0,     0,     0,    0,    0,
                          0,    0,    0,    0,    0,    0,    0,    0,    1.0,  0,     0,     0,     0,    0,    0,
                          0,    0,    0,    0,    0,    0,    0,    0,    0,    1.0,   0,     0,     0,    0,    0,
                          0,    0,    0,    0,    0,    0,    0,    0,    0,    0,     1.0,   0,     0,    0,    0,
                          0,    0,    0,    0,    0,    0,    0,    0,    0,    0,     0,     1.0,   0,    0,    0,
                          0,    0,    0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     1.0,  0,    0,
                          0,    0,    0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    1.0,  0,
                          0,    0,    0,    0,    0,    0,    0,    0,    0,    0,     0,     0,     0,    0,    1.0]

For map->odom transformation, the configuration is below.

frequency: 20
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.2
print_diagnostics: true
debug: false
publish_tf: true

map_frame: map
odom_frame: robot_odom
base_link_frame: robot_base_footprint
world_frame: map

# Wheel odometry:
odom0: wheel_odom
odom0_config: [false, false, false,
               false, false, false,
               true,  true,  false ...
(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:

rosservice call /robot/fromLL "ll_point:
  latitude: 40.5665059791
  longitude: 22.9989873398
  altitude: 122.0"

returns:

map_point: 
  x: 140892.72962
  y: 5405179.36945
  z: 0.0

And when I run:

rosservice call /robot/toLL "map_point:
  x: 0.0
  y: 0.0
  z: 0.0"

I get

ll_point: 
  latitude: 40.5665059791
  longitude: 22.9989873398
  altitude: 122.375866815

which is the same position as the first one.
I believe that this is not normal, but why is this happening?

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.
I want to use the lidar localizer algorithms with my ROS system that contains another autonomous car package.

Specifically, my system's TF tree is as follows: map -> odom -> base_footprint -> base_link ->the rest of the TF frames.

When I am using the NDT Matching algorithm, it provides a transform map -> base_link and it changes completely my TF tree and several other functionalities.

So, I thought to change the NDT algorithms's (matching and mapping) source code, so that they provide a transform from map to odom instead of base_link.

Does this sound correct? Or is there any other way to make this work?
Thanks in advance.

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)