2022-07-23 13:08:10 -0500 | marked best answer | Clock not publishing? I'm launching a bumblebee2 stereo camera to get my input images. When I check the /clock topic, I don't see any timestamps being published. Is this abnormal? |
2021-08-09 10:50:24 -0500 | received badge | ● Famous Question
(source)
|
2021-08-09 10:50:24 -0500 | received badge | ● Popular Question
(source)
|
2021-08-09 10:50:24 -0500 | received badge | ● Notable Question
(source)
|
2020-04-18 17:39:13 -0500 | marked best answer | How to get costmap_2d to build on top of cartographer's /map? I'd like to build a costmap on top of cartographer's map instead of say, gmaping, so I can run move_base on it for navigation. How do I go about doing this/ |
2019-08-19 14:54:36 -0500 | marked best answer | Could not get transform from odom to base_link I'm running rtabmap with an rgb-d sensor and get the following error: We received odometry message, but we cannot get the corresponding TF odom->base_link at data stamp 1533265358.770186s (odom msg stamp is 1533265358.757750s). Make sure TF of odometry is also published to get more accurate pose estimation. This warning is only printed once.
This is my launch file <launch>
<!-- Convenience launch file to launch odometry, rtabmap and rtabmapviz nodes at once -->
<!-- For stereo:=false
Your RGB-D sensor should be already started with "depth_registration:=true".
Examples:
$ roslaunch freenect_launch freenect.launch depth_registration:=true
$ roslaunch openni2_launch openni2.launch depth_registration:=true -->
<!-- For stereo:=true
Your camera should be calibrated and publishing rectified left and right
images + corresponding camera_info msgs. You can use stereo_image_proc for image rectification.
Example:
$ roslaunch rtabmap_ros bumblebee.launch -->
<!-- Choose between RGB-D and stereo -->
<arg name="stereo" default="false"/>
<!-- Choose visualization -->
<arg name="rtabmapviz" default="true" />
<arg name="rviz" default="false" />
<!-- Localization-only mode -->
<arg name="localization" default="false"/>
<!-- sim time for convenience, if playing a rosbag -->
<arg name="use_sim_time" default="false"/>
<param if="$(arg use_sim_time)" name="use_sim_time" value="true"/>
<!-- Corresponding config files -->
<arg name="cfg" default="" /> <!-- To change RTAB-Map's parameters, set the path of config file (*.ini) generated by the standalone app -->
<arg name="gui_cfg" default="~/.ros/rtabmap_gui.ini" />
<arg name="rviz_cfg" default="$(find rtabmap_ros)/launch/config/rgbd.rviz" />
<arg name="frame_id" default="base_link"/> <!-- Fixed frame id, you may set "base_link" or "base_footprint" if they are published -->
<arg name="odom_frame_id" default=""/> <!-- If set, TF is used to get odometry instead of the topic -->
<arg name="map_frame_id" default="map"/>
<arg name="ground_truth_frame_id" default=""/> <!-- e.g., "world" -->
<arg name="ground_truth_base_frame_id" default=""/> <!-- e.g., "tracker", a fake frame matching the frame "frame_id" (but on different TF tree) -->
<arg name="namespace" default="rtabmap"/>
<arg name="database_path" default="~/.ros/rtabmap.db"/>
<arg name="queue_size" default="10"/>
<arg name="wait_for_transform" default="0.2"/>
<arg name="args" default=""/> <!-- delete_db_on_start, udebug -->
<arg name="rtabmap_args" default="$(arg args)"/> <!-- deprecated, use "args" argument -->
<arg name="launch_prefix" default=""/> <!-- for debugging purpose, it fills launch-prefix tag of the nodes -->
<arg name="output" default="screen"/> <!-- Control node output (screen or log) -->
<!-- if timestamps of the input topics are synchronized using approximate or exact time policy-->
<arg if="$(arg stereo)" name="approx_sync" default="true"/>
<arg unless="$(arg stereo)" name="approx_sync" default="true"/>
<!-- RGB-D related topics -->
<arg name="rgb_topic" default="/camera/rgb/image_rect_color" />
<arg name="depth_topic" default="/camera/depth_registered/image_raw" />
<arg name="camera_info_topic" default="/camera/rgb/camera_info" />
<arg name="depth_camera_info_topic" default="$(arg camera_info_topic)" />
<!-- stereo related topics -->
<arg name="stereo_namespace" default="/camera"/>
<arg name="left_image_topic" default="$(arg stereo_namespace)/left/image_rect_color" />
<arg name="right_image_topic" default="$(arg stereo_namespace)/right/image_rect" /> <!-- using grayscale image for efficiency -->
<arg name="left_camera_info_topic" default="$(arg stereo_namespace)/left/camera_info" />
<arg name="right_camera_info_topic" default="$(arg stereo_namespace)/right/camera_info" />
<!-- Already synchronized RGB-D related topic, with rtabmap_ros/rgbd_sync nodelet -->
<arg name="rgbd_sync" default="false"/> <!-- pre-sync rgb_topic, depth_topic, camera_info_topic -->
<arg name="approx_rgbd_sync" default="true"/> <!-- false=exact synchronization -->
<arg name="subscribe_rgbd" default="$(arg rgbd_sync)"/>
<arg name="rgbd_topic" default="rgbd_image" />
<arg name="depth_scale" default="1.0" />
<arg ... (more) |
2019-07-22 15:37:20 -0500 | received badge | ● Famous Question
(source)
|
2019-05-13 08:22:39 -0500 | received badge | ● Famous Question
(source)
|
2019-05-08 04:42:29 -0500 | received badge | ● Famous Question
(source)
|
2019-05-01 09:41:09 -0500 | received badge | ● Famous Question
(source)
|
2019-03-27 09:30:06 -0500 | received badge | ● Notable Question
(source)
|
2019-03-27 09:30:06 -0500 | received badge | ● Popular Question
(source)
|
2019-03-22 02:44:16 -0500 | received badge | ● Famous Question
(source)
|
2019-03-01 16:34:51 -0500 | marked best answer | How to add automated kill switch to robot? My UGV sometimes behaves erratically when navigating autonomously with move_base. It will sometimes get caught in loops when performing turns to reach a nav goal, or it will completely lose it's pose and lose its pose wrt to the ground and think it's flipped in the air (as seen in rviz). When it is behaving erratically, it can even rush a wall and try to climb it until it tips over! I'd like to add a kill condition that will monitor its odometry, speed, and acceleration and send an interrupt to move_base to shut down when this happens. What's the best way of going about this? |
2019-03-01 16:33:15 -0500 | received badge | ● Famous Question
(source)
|
2019-03-01 16:32:17 -0500 | marked best answer | move_base navigating robot to close to costmap? I'm experiencing an issue where anytime move_base sets a trajectory for the robot to follow, it inevitably falls too close to an obstacle and ends up scraping against it, or gets stuck in an escape loop where it keeps backing out in order to avoid the obstacle but repeats the same trajectory instead of re-planning. How can I discourage this behaviour? move_base settings:
TrajectoryPlannerROS:
acc_lim_x: 2.0
acc_lim_theta: 1.0
max_vel_x: 0.18
min_vel_x: 0.05
max_vel_theta: 1.57
min_vel_theta: -1.57
min_in_place_vel_theta: 0.314
holonomic_robot: false
escape_vel: -0.20
yaw_goal_tolerance: 0.3
xy_goal_tolerance: 0.35
latch_xy_goal_tolerance: false
sim_time: 4.0
sim_granularity: 0.02
angular_sim_granularity: 0.03
vx_samples: 30
vtheta_samples: 30
controller_frequency: 20.0
meter_scoring: true
occdist_scale: 0.1
pdist_scale: 0.4
gdist_scale: 0.6
heading_lookahead: 1.0
heading_scoring: false
heading_scoring_timestep: 1.8
dwa: true
simple_attractor: false
publish_cost_grid_pc: true
oscillation_reset_dist: 0.4
escape_reset_dist: 0.0
escape_reset_theta: 0.4
map_type: costmap
origin_z: 0.0
z_resolution: 1
z_voxels: 2
obstacle_range: 5.5 #2.5
raytrace_range: 3.0
publish_voxel_map: false
transform_tolerance: 0.5
meter_scoring: false
footprint: [[-0.21, -0.165], [-0.21, 0.165], [0.21, 0.165], [0.21, -0.165]]
footprint_padding: 0.045
plugins:
- {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflater_layer, type: "costmap_2d::InflationLayer"}
obstacles_layer:
observation_sources: scan
scan: {sensor_frame: front_laser, data_type: LaserScan, topic: /scan, marking: true, clearing: true, min_obstacle_height: -2.0, max_obstacle_height: 2.0, obstacle_range: 2.5, raytrace_range: 3.0}
inflater_layer:
inflation_radius: 0.06
shutdown_costmaps: false
controller_frequency: 10.0
controller_patience: 5.0
planner_frequency: 20.0
planner_patience: 5.0
oscillation_timeout: 0.0
oscillation_distance: 0.5
recovery_behavior_enabled: true
clearing_rotation_allowed: true
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 10.0
publish_frequency: 5.0
width: 40.0
height: 40.0
resolution: 0.02
origin_x: 0.0
origin_y: 0.0
static_map: true
rolling_window: false
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflater_layer, type: "costmap_2d::InflationLayer"}
local_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 10.0
publish_frequency: 5.0
width: 10.0
height: 10.0
resolution: 0.02
static_map: false
rolling_window: true
|
2019-02-22 06:47:15 -0500 | received badge | ● Famous Question
(source)
|
2019-02-07 11:39:20 -0500 | received badge | ● Famous Question
(source)
|
2019-01-16 12:35:32 -0500 | received badge | ● Popular Question
(source)
|
2019-01-16 12:35:32 -0500 | received badge | ● Notable Question
(source)
|
2019-01-16 01:52:37 -0500 | received badge | ● Famous Question
(source)
|
2019-01-15 01:42:55 -0500 | received badge | ● Famous Question
(source)
|
2019-01-03 03:33:40 -0500 | received badge | ● Famous Question
(source)
|
2018-12-13 04:27:26 -0500 | received badge | ● Famous Question
(source)
|
2018-11-14 15:03:49 -0500 | received badge | ● Famous Question
(source)
|
2018-10-31 05:07:19 -0500 | received badge | ● Notable Question
(source)
|
2018-10-31 05:07:19 -0500 | received badge | ● Famous Question
(source)
|
2018-10-26 11:10:24 -0500 | received badge | ● Famous Question
(source)
|
2018-10-10 02:20:56 -0500 | received badge | ● Notable Question
(source)
|
2018-10-03 00:03:35 -0500 | received badge | ● Famous Question
(source)
|
2018-09-28 21:01:31 -0500 | received badge | ● Notable Question
(source)
|
2018-09-24 07:11:06 -0500 | received badge | ● Notable Question
(source)
|
2018-09-19 15:52:36 -0500 | received badge | ● Notable Question
(source)
|
2018-09-12 23:53:01 -0500 | received badge | ● Famous Question
(source)
|
2018-09-12 23:51:51 -0500 | received badge | ● Popular Question
(source)
|
2018-09-06 07:55:32 -0500 | received badge | ● Popular Question
(source)
|
2018-09-06 07:55:05 -0500 | received badge | ● Popular Question
(source)
|
2018-08-27 03:17:33 -0500 | marked best answer | TF Error: Lookup would requrie extrapolation into the future I'm running rtabmap on a jackal robot with bumblebee2 stereo camera on ros-kinetic. I get the following error when trying to view pointcloud2 topic in rviz: Transform [sender=unknown_publisher] For frame [front_camera_optical]: No transform to fixed frame [map]. TF error: [Lookup would require extrapolation into the future. Requested time 1533228746.513341601 but the latest data is at time 1533228664.878277882, when looking up transform from frame [front_camera_optical] to frame [map]]
When I view the tf tree link text I see that i'm getting -0.086 sec old from the map broadcast by rtabmap. |
2018-08-27 03:11:08 -0500 | marked best answer | RVIZ shows odom frame fixed to map frame when running rtabmap I've set the map frame as the fixed frame in RVIZ, and this is what it looks like when running rtabmap https://imgur.com/a/U5fJLLP . This is what my partial tf-tree looks like https://imgur.com/a/1s2PnV8 . This is my launch file for rtabmap: <launch> <!-- Choose visualization
--> <arg name="rviz" default="true" /> <arg name="rtabmapviz" default="false" /> <arg name="local_bundle" default="true" /> <arg name="stereo_sync" default="false" />
<param name="use_sim_time" type="bool" value="false"/> <!-- Visual SLAM: args: "delete_db_on_start" and "udebug" --> <node name="rtabmap" pkg="rtabmap_ros" type="rtabmap" output="screen" args="--delete_db_on_start">
<param name="frame_id" type="string" value="base_link"/>
<param unless="$(arg stereo_sync)" name="subscribe_stereo" type="bool" value="true"/>
<param name="subscribe_depth" type="bool" value="false"/>
<param name="subscribe_rgbd" type="bool" value="$(arg stereo_sync)"/>
<remap from="left/image_rect" to="/camera/left/image_rect_color"/>
<remap from="right/image_rect" to="/camera/right/image_rect"/>
<remap from="left/camera_info" to="/camera/left/camera_info"/>
<remap from="right/camera_info" to="/camera/right/camera_info"/>
<remap from="rgbd_image" to="/camera/rgbd_image"/>
<remap from="odom" to="/odometry/filtered"/>
<param name="queue_size" type="int" value="30"/>
<param name="map_negative_poses_ignored" type="bool" value="true"/>
<!-- RTAB-Map's parameters -->
<param name="Rtabmap/TimeThr" type="string" value="700"/>
<param name="Grid/DepthDecimation" type="string" value="4"/>
<param name="Grid/FlatObstacleDetected" type="string" value="true"/>
<param name="Kp/MaxDepth" type="string" value="0"/>
<param name="Kp/DetectorStrategy" type="string" value="6"/>
<param name="Vis/EstimationType" type="string" value="1"/> <!-- 0=3D->3D, 1=3D->2D (PnP) -->
<param name="Vis/MaxDepth" type="string" value="0"/>
<param name="RGBD/CreateOccupancyGrid" type="string" value="true"/>
<param name="approx_sync" type="bool" value="true"/> </node> </launch>
|
2018-08-25 03:20:54 -0500 | received badge | ● Famous Question
(source)
|
2018-08-21 05:31:50 -0500 | received badge | ● Notable Question
(source)
|
2018-08-21 03:01:33 -0500 | received badge | ● Notable Question
(source)
|
2018-08-20 11:54:54 -0500 | received badge | ● Popular Question
(source)
|
2018-08-17 19:18:21 -0500 | asked a question | move_base navigating robot to close to costmap? move_base navigating robot to close to costmap?
I'm experiencing an issue where anytime move_base sets a trajectory for |
2018-08-17 18:01:32 -0500 | asked a question | Robot gets 'stuck' in object's costmap? Robot gets 'stuck' in object's costmap?
I'm navigating a jackal robot with the move_base stack, and am experiencing an i |