We will need more information in this case to narrow down the problem. Please show your navigation configuration (costmap params files.).
Especially check you costmap_common_params file and see which frame have you passed to your observation source (laser_scan_sensor) and which are your global and robot_base frames.

I am using libgazebo_ros_control.so plugin to control my robot, you can check the images in the links bellow to understand exactly what i am talking about. https://ibb.co/k5THXCK (This is the initial state) https://ibb.co/tLCwpGf (here you can see when the robot moves, the signals moves also, but in gazebo they are fixed)

note that the problem is not occuring when I use the plugin libgazebo_ros_diff_drive.so to control the robot,

Yes I understand that. We will need to see your navigation configuration files in order to debug the problem

Hi Pavel92, this is my costmap_common_params file:

obstacle_range: 8.0

raytrace_range: 10


footprint: [[-0.7874, -0.381], [-0.7874, 0.381], [0.8636, 0.381], [0.8636, -0.381]]


inflation_radius: 0.2

cost_scaling_factor: 0.5


map_type: costmap

transform_tolerance: 0.2

observation_sources: scan

scan: {data_type: LaserScan, topic: scan_multi, marking: true, clearing: true}

What do you think pavel ?

This is typically a transforms issue. Your laser data from the lidar iteself may be inverted. It is also possible that your localization stack is giving odometry / pose that does not follow ROS standard (ENU convention). Please check ROS REP 103 and ROS REP 105