ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2019-01-11 06:35:42 -0500 | received badge | ● Famous Question (source) |
2018-09-14 17:24:31 -0500 | marked best answer | How to incorporate moveable sensor (Lidar) into navigation stack I am building a robot which will move using ros navigation stack with move_base. I am using Lidar Lite 2 Laser Rangefinder to detect obstacles and for mapping as well. I have two questions regarding the use of this lidar.
|
2018-05-17 17:36:16 -0500 | received badge | ● Famous Question (source) |
2017-12-27 20:35:00 -0500 | received badge | ● Notable Question (source) |
2017-12-27 20:35:00 -0500 | received badge | ● Popular Question (source) |
2017-11-29 20:11:55 -0500 | received badge | ● Taxonomist |
2017-07-22 18:07:38 -0500 | received badge | ● Famous Question (source) |
2017-03-07 16:57:58 -0500 | received badge | ● Notable Question (source) |
2017-02-27 14:49:06 -0500 | received badge | ● Famous Question (source) |
2017-01-31 01:59:16 -0500 | received badge | ● Famous Question (source) |
2016-10-13 22:49:02 -0500 | received badge | ● Notable Question (source) |
2016-09-30 04:13:59 -0500 | received badge | ● Famous Question (source) |
2016-09-13 09:26:04 -0500 | received badge | ● Famous Question (source) |
2016-09-13 07:55:45 -0500 | received badge | ● Notable Question (source) |
2016-08-21 23:25:22 -0500 | received badge | ● Popular Question (source) |
2016-08-05 05:57:30 -0500 | received badge | ● Popular Question (source) |
2016-06-29 10:11:32 -0500 | asked a question | Problem with spinning lidar in gmapping I have set my lidar lite v2 spinning 360 degree on a stepper motor (since it is a range finder, not a wide angle scanner) and the transform base_link --> base_laser updates according to the motor position. So, when I run gmapping, I see my lidar rotating as I want it to be. But due to this, in Rviz, my robot keeps taking small jumps in the map due to which a proper map is not created (for example, a straight wall would become curved or bent). If I stop rotating my lidar (i.e. the transform base_link --> base_laser is constant), then the problem vanishes and the robot no more jumps around. I tried to resolve this problem by editing gmapping such that it always publishes map -- > odom transform as zero. By doing so, the robot does not jumps around anymore while lidar is rotating, but it leads to a new problem which I have asked in a new question in the following link. http://answers.ros.org/question/23842... Any ideas how can I resolve this problem of robot jumping around when lidar is rotating ? |
2016-06-29 10:09:40 -0500 | asked a question | Editing gmapping caused a problem I have edited my gmapping node to always publish zero transform from map to odom (reason being that map -- > odom keeps violently changing when I spin my lidar which causes the robot to jump around in rviz). Now when i start gmapping, everything works fine, but after some time, as I move my robot using teleop, I see the scan lines of lidar are displaced from the actual lidar frame as it shows in rviz. Means, the lidar frame and all other frames are in their proper place relative to base_link as appears in rviz, but the origin of scan lines (which make up the map) appear to be somewhere else, not on the lidar's frame. Any ideas on why the origin of scan lines is displaced from their actual origin ? Thanks |
2016-06-28 08:57:55 -0500 | received badge | ● Student (source) |
2016-06-11 10:40:04 -0500 | received badge | ● Popular Question (source) |
2016-05-17 03:09:19 -0500 | commented answer | Zeroing Out Orientation and Linear Acceleration of IMU If (imu_msg.angular_velocity.z <= 0.009) { imu_msg.angular_velocity.x = 0; imu_msg.angular_velocity.y = 0; imu_msg.angular_velocity.z = 0; imu_msg.linear_acceleration.x = 0; imu_msg.linear_acceleration.y = 0; imu_msg.linear_acceleration.z = 0; } |
2016-05-17 03:07:41 -0500 | commented answer | Zeroing Out Orientation and Linear Acceleration of IMU The link I provided contains the original code. I put an If condition inside the while loop just before the line imu_pub.publish(imu_msg). Following is the If condition. |
2016-05-16 02:35:09 -0500 | commented answer | Zeroing Out Orientation and Linear Acceleration of IMU I used rtimulib for my imu so I put this condition in the while loop which you can find at the end of this file https://github.com/romainreignier/rti... |
2016-05-16 02:34:31 -0500 | commented answer | Zeroing Out Orientation and Linear Acceleration of IMU Find out the part of your code where it is publishing the imu message, and put a condition there that if the x,y,z value is less than 'threshold', then put zero values in the imu message instead of the original values. |
2016-05-15 20:54:46 -0500 | received badge | ● Teacher (source) |
2016-05-14 13:26:42 -0500 | answered a question | lidar lite V 2 with HectorSlam I am also trying to use lidar lite v2 rotating 360 but with gmapping. Can you guide me how have you communicated the rotating behavior in your mapping node (i.e. hector_slam). |
2016-05-14 13:22:50 -0500 | received badge | ● Notable Question (source) |
2016-05-14 13:09:44 -0500 | answered a question | Zeroing Out Orientation and Linear Acceleration of IMU I also faced this problem as IMU always gives non-zero values for angular velocity (and hence orientation) and linear acceleration even when it is not moving. I didn't find any built-in filter inside ros which could do this task of zeroing out the values when it is stationary. So, I ended up building my own simple filter in which I zero-ed out the values based on a threshold value. This threshold value was found through manual observations on imu. |
2016-05-13 11:40:02 -0500 | asked a question | Moving laser frame causing problem I am using lidar lite v2 with gmapping. The lidar is rotated using a motor. To incorporate moving lidar, I have applied transform from lidar frame i.e base_laser to base_link is using a variable angle which is sent by the lidar motor. It works perfectly fine as I can see the lidar frame constantly rotating in Rviz. But, due to this, the transform from map to odom or base_link keeps changing constantly which causes the map frame to move constantly in Rviz while all other frames are stationary (except base_laser). When I use a non_varying/constant transform from base_laser to base_link (as if the lidar was stationary), then it works fine and the map frame does not float in Rviz (or in other words, transform from map to odom/base_link does'not change). Any ideas on how to resolve this? Thanks. |
2016-05-09 01:07:13 -0500 | received badge | ● Famous Question (source) |
2016-05-08 15:11:49 -0500 | answered a question | Problem with Autonomous robot motion: amcl I figured out the problem. The base_frame parameter in move_base node was set to base_link. I changed it to base_footprint. Now the robot follows its path properly and reaches its goal. Thanks everyone for help. |
2016-05-08 15:04:12 -0500 | received badge | ● Famous Question (source) |
2016-05-08 15:03:34 -0500 | commented answer | rostopic navigation_velocity_smoother/raw_cmd_vel Thanks for your response. I will look into this package. |
2016-05-08 15:00:49 -0500 | received badge | ● Popular Question (source) |
2016-05-05 10:24:26 -0500 | asked a question | Imu values not being filtered properly I am getting raw data values from imu. In the raw data, orientation always remains zero (x=0, y=0, z=0, w=0) whereas angular velocity and linear acceleration keep changing their values. I have applied the imu_complimentary_filter from imu_tools ros to filter the imu data and get proper orientation values. The output data provided by complimentary filter contains non-zero values for orientation (as it should be), but the problem is that the angular velocity and linear acceleration values are not being filtered properly. For example, even when the imu is stationary, it gives varying values (basically garbage values) for angular velocity and linear acceleration as they were in the raw data. Can anyone guide me as to what should I do to filter the values of angular velocity and linear acceleration (i.e. make them zero when the robot/imu is not moving). Thanks |
2016-05-04 03:44:35 -0500 | received badge | ● Famous Question (source) |
2016-04-29 03:06:36 -0500 | asked a question | rostopic navigation_velocity_smoother/raw_cmd_vel I am implementing navigation stack on my robot and using move_base to move the robot. The move base node is publishing Twist messages on rostopic navigation_velocity_smoother/raw_cmd_vel. Can anyone describe what this topic is for ? |
2016-04-28 11:00:31 -0500 | commented question | Problem with Autonomous robot motion: amcl I have added the configuration parameters for move_base and dwa_local planner in the original question. Please refer to them. |
2016-04-28 10:58:44 -0500 | received badge | ● Notable Question (source) |
2016-04-28 01:01:03 -0500 | received badge | ● Popular Question (source) |
2016-04-27 11:15:50 -0500 | asked a question | Problem with Autonomous robot motion: amcl My robot has been set up for autonomous motion using amcl & move_base from ROS navigation stack. The robot performs correctly using teleop; and the motors follow the velocity values published by move_base well enough. The problem is that, after defining the path between the robot and the goal position correctly, my robot fails to follow it (the defined path). I have uploaded a video of what the robot's simulation does in rviz here: https://youtu.be/cRTHVMGiG0I Also, The robot driver subscribes to the rostopic navigation_velocity_smoother/raw_cmd_vel to run the motors (since values are not being published on cmd_vel topic) Can anyone shed some light on why this is happening? (please watch the video in the provided url) Here are my move_base parameters:shutdown_costmaps: false controller_frequency: 5.0 controller_patience: 3.0 planner_frequency: 1.0 planner_patience: 5.0 oscillation_timeout: 10.0 oscillation_distance: 0.8 base_local_planner: "dwa_local_planner/DWAPlannerROS" base_global_planner: "navfn/NavfnROS" #alternatives:global_planner/GlobalPlanner And these are the dwa_planner params:max_vel_x: 0.5 max_vel_y: 0.0 min_vel_y: 0.0 max_trans_vel: 0.5
min_trans_vel: 0.1 max_rot_vel: 5.0 acc_lim_x: 0.5 acc_lim_theta: 2.0 acc_lim_y: 0.0 yaw_goal_tolerance: 0.3 sim_time: 1.0 path_distance_bias: 64.0
goal_distance_bias: 24.0
occdist_scale: 0.5 oscillation_reset_dist: 0.05 publish_traj_pc : true publish_cost_grid_pc: true global_frame_id: odom |
2016-04-22 03:00:07 -0500 | commented answer | Problem moving the robot using navigation stack Oh and I just found out that move_base is publishing messages on navigation_velocity_smoother/raw_cmd_vel but not on cmd_vel |
2016-04-22 02:48:53 -0500 | answered a question | Problem moving the robot using navigation stack Oh, and I just found out that data is being published on navigation_velocity_smoother/raw_cmd_vel but not on cmd_vel. |
2016-04-22 00:53:31 -0500 | received badge | ● Notable Question (source) |
2016-04-21 14:20:45 -0500 | commented answer | Problem moving the robot using navigation stack teleoperation node usually isn't running when i run move_base. It seems as if the robot is constantly stuck in obstacles, this is why recovery behaviors message is also displayed after 'got new plan'. But there are no obstacles in actual and the path shown in Rviz is also clear. |