Hi,
I have managed to use turtlebot3 (gazebo and Rviz) to create a map and use its data to implement an Astar algorithm(in python).The result is the series of (x,y) coordinates to which robot should move. But now i am confused which topic to publish into to tell robot to move to those places in that sequence.I know there is move_base package but it uses its own path planners,i have read that you can create your own plugin but i feel i might be overthinking and it might be some other way.So i have two questions:
1- Which topic or topics to use to publish these locations?
2-My results are in coordinates system,do i have to convert them back into world coordinates?
Thanks.
↧
Moving turtlebot with own implementation of Astar
↧
what are the important design pattern used in move_base package?
My task is to modify the move_base (especially local planner DWA algorithm) according to the need of mine application. I have studied the C++, OOPs concepts and UML diagram representation. Now I am studying design patterns, I found that there are various design patterns. It's very confusing and it takes a long time to study all design patterns. Could you tell me some of the important design patterns?
↧
↧
Morse + ROS - Robot not moving to the goal
Hi, I just picked up ROS and Morse and I'm trying to follow the Morse's tutorial on ROS Navigation. The tutorial can be found [here](http://www.openrobots.org/morse/doc/latest/user/advanced_tutorials/ros_nav_tutorial.html). At the end it should be moving to the goal, but for some unknown reason to me, it just won't. Any help? I'm using Ubuntu 16.04.3, Morse Simulator v 1.2, ROS Lunar.
My system:
No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.3 LTS Release: 16.04 Codename: xenial`morse check` gives the following output:
* Checking up your environment... * Running on Linux. Alright. * Found MORSE libraries on '/usr/lib/python3/dist-packages/morse/blender'. Alright. * Trying to figure out a prefix from the script location... * Default scene found. The prefix seems ok. Using it. * Setting $MORSE_ROOT environment variable to default prefix [/usr/] * Checking version of /usr/bin/blender... Found v.2.76.0 * Found Blender in your PATH (/usr/bin/blender, v.2.76.0). Alright, using it. * Checking version of the Python within Blender /usr/bin/blender... Found v.3.5.2 * Blender and Morse are using Python 3.5.2. Alright. * Your environment is correctly setup to run MORSEThe command `morse -v` gives:
morse UNKNOWN-dirty
↧
move_base/teb_local_planner requires a map during startup
Hi all,
I'm using the navigation stack with rplidar A2, hector slam and teb_local_planner in kinetic. The robot is self made and needs to stand up before starting the navigation. Afterwards, I turn on the lidar. Then, hector SLAM recognizes that there is a scan topic, kicks in and generates the map. Now I would expect the navigation stack to do the same, but unfortunately it does not recognize the new map but seems to be stuck when no map was present during startup, i.e. the global costmap is not being published.
If I start the lidar along with the navigation stack everything works fine.
My current solution is to start the lidar and kill the move_base node (with respawn=true in the launch file). Ugly, but works: after a few seconds the global costmap is generated and the navigation stack is working fine.
In the log file of move_base there is no error message, and I have no idea anymore where to look.
my parameters are:
* /hector_height_mapping/advertise_map_service: True
* /hector_height_mapping/base_frame: base_link
* /hector_height_mapping/laser_max_dist: 8.0
* /hector_height_mapping/laser_min_dist: 0.45
* /hector_height_mapping/map_pub_period: 0.5
* /hector_height_mapping/map_resolution: 0.05
* /hector_height_mapping/map_size: 512
* /hector_height_mapping/map_start_x: 0.5
* /hector_height_mapping/map_start_y: 0.5
* /hector_height_mapping/map_update_angle_thresh: 0.1
* /hector_height_mapping/map_update_distance_thresh: 0.05
* /hector_height_mapping/map_with_known_poses: False
* /hector_height_mapping/odom_frame: base_link
* /hector_height_mapping/output_timing: False
* /hector_height_mapping/pub_map_odom_transform: False
* /hector_height_mapping/scan_topic: scan
* /hector_height_mapping/update_factor_free: 0.45
* /hector_height_mapping/use_tf_pose_start_estimate: False
* /hector_height_mapping/use_tf_scan_transformation: True
* /move_base/TebLocalPlannerROS/acc_lim_theta: 0.06
* /move_base/TebLocalPlannerROS/acc_lim_x: 0.06
* /move_base/TebLocalPlannerROS/acc_lim_y: 0.06
* /move_base/TebLocalPlannerROS/allow_init_backward_motion: True
* /move_base/TebLocalPlannerROS/costmap_converter_plugin:
* /move_base/TebLocalPlannerROS/costmap_converter_rate: 5
* /move_base/TebLocalPlannerROS/costmap_converter_spin_thread: True
* /move_base/TebLocalPlannerROS/costmap_obstacles_behind_robot_dist: 0.5
* /move_base/TebLocalPlannerROS/enable_homotopy_class_planning: False
* /move_base/TebLocalPlannerROS/footprint_model/type: point
* /move_base/TebLocalPlannerROS/include_costmap_obstacles: True
* /move_base/TebLocalPlannerROS/inflation_dist: 0.8
* /move_base/TebLocalPlannerROS/map_frame: /map
* /move_base/TebLocalPlannerROS/max_global_plan_lookahead_dist: 1.5
* /move_base/TebLocalPlannerROS/max_vel_theta: 0.2
* /move_base/TebLocalPlannerROS/max_vel_x: 0.1
* /move_base/TebLocalPlannerROS/max_vel_x_backwards: 0.1
* /move_base/TebLocalPlannerROS/max_vel_y: 0.1
* /move_base/TebLocalPlannerROS/max_vel_y_backwards: 0.1
* /move_base/TebLocalPlannerROS/min_in_place_vel_theta: 0.0
* /move_base/TebLocalPlannerROS/min_obstacle_dist: 0.36
* /move_base/TebLocalPlannerROS/min_vel_theta: -0.2
* /move_base/TebLocalPlannerROS/obstacle_poses_affected: 30
* /move_base/TebLocalPlannerROS/odom_topic: /odom
* /move_base/TebLocalPlannerROS/optimization_activate: True
* /move_base/TebLocalPlannerROS/optimization_verbose: False
* /move_base/TebLocalPlannerROS/penalty_epsilon: 0.05
* /move_base/TebLocalPlannerROS/weight_kinematics_forward_drive: 0
* /move_base/TebLocalPlannerROS/weight_kinematics_nh: 0
* /move_base/TebLocalPlannerROS/weight_kinematics_turning_radius: 0
* /move_base/TebLocalPlannerROS/xy_goal_tolerance: 0.05
* /move_base/TebLocalPlannerROS/yaw_goal_tolerance: 0.05
* /move_base/TrajectoryPlannerROS/acc_lim_theta: 0.06
* /move_base/TrajectoryPlannerROS/acc_lim_x: 0.06
* /move_base/TrajectoryPlannerROS/acc_lim_y: 0.06
* /move_base/TrajectoryPlannerROS/escape_vel: -0.1
* /move_base/TrajectoryPlannerROS/holonomic_robot: True
* /move_base/TrajectoryPlannerROS/max_vel_theta: 0.2
* /move_base/TrajectoryPlannerROS/max_vel_x: 0.1
* /move_base/TrajectoryPlannerROS/max_vel_y: 0.1
* /move_base/TrajectoryPlannerROS/min_in_place_vel_theta: 0.0
* /move_base/TrajectoryPlannerROS/min_vel_theta: -0.2
* /move_base/TrajectoryPlannerROS/min_vel_x: -0.1
* /move_base/TrajectoryPlannerROS/min_vel_y: -0.1
* /move_base/TrajectoryPlannerROS/y_vels: -0.1, -0.08,-0.06...
* /move_base/base_local_planner: teb_local_planner...
* /move_base/controller_frequency: 7
* /move_base/global_costmap/always_send_full_costmap: False
* /move_base/global_costmap/global_frame: /map
* /move_base/global_costmap/inflation_layer/cost_scaling_factor: 5.0
* /move_base/global_costmap/inflation_layer/enabled: True
* /move_base/global_costmap/inflation_layer/inflation_radius: 1.0
* /move_base/global_costmap/map_type: costmap
* /move_base/global_costmap/obstacle_layer/combination_method: 1
* /move_base/global_costmap/obstacle_layer/enabled: True
* /move_base/global_costmap/obstacle_layer/laser_scan_sensor/clearing: True
* /move_base/global_costmap/obstacle_layer/laser_scan_sensor/data_type: LaserScan
* /move_base/global_costmap/obstacle_layer/laser_scan_sensor/marking: True
* /move_base/global_costmap/obstacle_layer/laser_scan_sensor/sensor_frame: base_link
* /move_base/global_costmap/obstacle_layer/laser_scan_sensor/topic: scan
* /move_base/global_costmap/obstacle_layer/observation_sources: laser_scan_sensor
* /move_base/global_costmap/obstacle_layer/obstacle_range: 2.5
* /move_base/global_costmap/obstacle_layer/raytrace_range: 4.0
* /move_base/global_costmap/obstacle_layer/track_unknown_space: False
* /move_base/global_costmap/publish_frequency: 1.0
* /move_base/global_costmap/robot_base_frame: base_link
* /move_base/global_costmap/robot_radius: 0.35
* /move_base/global_costmap/rolling_window: False
* /move_base/global_costmap/static_layer/enabled: True
* /move_base/global_costmap/static_layer/map_topic: /map
* /move_base/global_costmap/static_map: False
* /move_base/global_costmap/transform_tolerance: 0.3
* /move_base/global_costmap/update_frequency: 2.0
* /move_base/local_costmap/global_frame: /map
* /move_base/local_costmap/height: 2.0
* /move_base/local_costmap/inflation_layer/cost_scaling_factor: 5.0
* /move_base/local_costmap/inflation_layer/enabled: True
* /move_base/local_costmap/inflation_layer/inflation_radius: 1.0
* /move_base/local_costmap/map_type: costmap
* /move_base/local_costmap/obstacle_layer/combination_method: 1
* /move_base/local_costmap/obstacle_layer/enabled: True
* /move_base/local_costmap/obstacle_layer/laser_scan_sensor/clearing: True
* /move_base/local_costmap/obstacle_layer/laser_scan_sensor/data_type: LaserScan
* /move_base/local_costmap/obstacle_layer/laser_scan_sensor/marking: True
* /move_base/local_costmap/obstacle_layer/laser_scan_sensor/sensor_frame: base_link
* /move_base/local_costmap/obstacle_layer/laser_scan_sensor/topic: scan
* /move_base/local_costmap/obstacle_layer/observation_sources: laser_scan_sensor
* /move_base/local_costmap/obstacle_layer/obstacle_range: 2.5
* /move_base/local_costmap/obstacle_layer/raytrace_range: 4.0
* /move_base/local_costmap/obstacle_layer/track_unknown_space: False
* /move_base/local_costmap/publish_frequency: 1.0
* /move_base/local_costmap/resolution: 0.05
* /move_base/local_costmap/robot_base_frame: base_link
* /move_base/local_costmap/robot_radius: 0.35
* /move_base/local_costmap/rolling_window: False
* /move_base/local_costmap/static_layer/enabled: True
* /move_base/local_costmap/static_layer/map_topic: /map
* /move_base/local_costmap/static_map: True
* /move_base/local_costmap/transform_tolerance: 0.5
* /move_base/local_costmap/update_frequency: 2.0
* /move_base/local_costmap/width: 2.0
* /move_base/plugins: [{'type': 'costma...
* /pentapod_engine_node/cortex_i2c_address: 8
* /pentapod_engine_node/cortex_i2c_port: /dev/i2c-1
* /pentapod_engine_node/cortex_serial_baudrate: 230400
* /pentapod_engine_node/cortex_serial_port: /dev/ttyS1
* /pentapod_server_node/webserver_port: 8000
* /rosdistro: kinetic
* /rosversion: 1.12.7
* /rplidarNode/angle_compensate: True
* /rplidarNode/frame_id: laser
* /rplidarNode/inverted: False
* /rplidarNode/serial_baudrate: 115200
* /rplidarNode/serial_port: /dev/ttyUSB0
* /rplidarNode/start_motor: False
Any idea how to tackle that?
↧
Implement obstacle avoidance methods and local navigation (move_base)
Hello,
I would like to implement obstacle avoidance methods in Turtlebot2 (Velocity obstacles, VFH+. APF,...).
And I do not know if I have to use pluginlib and do as D. Lu did. That is, implement the interface named nav_core::BaseLocalPlanner and do planning in computeVelocityCommands method [1].
Or maybe, it requires to do something else such as modifying costmap_2d [2], add PoseStamped ?
So, does somebody may advise me on what should I do first, since I am a beginner using ROS ?
[1] https://github.com/DLu/simple_local_planner
[2] http://wiki.ros.org/costmap_2d
↧
↧
launch move_base : error loading tag
hi ,
i'm trying to launch move_base backage and i used this launch file :
i get this error :
*error loading tag:
file does not exist [/home/kesuke-pc/catkin_ws/src/flo_navigation_rviz/param/costmap_common_params.yaml]
XML is
↧
Roomba 400 navigation stack setup
Hello!
I'm using [create_autonomy](http://wiki.ros.org/create_autonomy) driver for my roomba 400 on kinetic, and I want to set up the navigation stack (especially move_base to send goals to the robot and navigate in rviz). The ca_driver running on Raspberry, the gmapping, map server on the PC.
I'm following the [navigation stack tutorial](http://wiki.ros.org/navigation/Tutorials/RobotSetup), and as described in it, first, I need to create a package with the following dependencies:
catkin_create_pkg my_robot_name_2dnav move_base my_tf_configuration_dep my_odom_configuration_dep my_sensor_configuration_dep
How should I need to fill up the dependencies on which device (RPI or PC) once the ca_driver itself publish a /tf and a /odom topic when I starting it with the following launch:
roslaunch ca_driver roomba_400.launch
Maybe if anyone successfully deployed the navigation stack, can send me a sample/example launch file or project?
↧
How to use move_base with a 3D map ?
Hey guys,
I am using move_base for path planning at the moment and I am wondering if it's possible to use move_base with just a 3D map or do I have to convert my 3D map (for localization) to a 2D map again?
Does anyone have experience with a 3D map for localization and a 2D map for planning? What is the best way to convert 3D to 2D and making sure that they will overlay correct (that my 3D localization pose and goal points in my 2D map will fit)?
Thank you guys in advance!
↧
Setting up move_base / Navigation Stack
Hi,
I was following the [tutorial](http://wiki.ros.org/navigation/Tutorials/RobotSetup) to set up the Nav Stack on a robot, but at the end I got pretty bad results in Rviz. Somehow I got the scans to be accumulated on the screen, and the particles were not moving good.
I just mapped on wall of the room for performance and speed purposes. The particles got initialized well, but the center of the robot didn't.
When I moved around the scans got accumulated, not like the turtlebot_navigation tutorial.
This is something I would expect to have
What I might be doing wrong?
↧
↧
Reverse recovery behavior for stuck non circular robots
Hello, I have a robot that is having issues getting stuck. In a lot of situations, a simple reverse operation would un stick it. Rotate recovery doesn't work well because my robot's turning center is offset from its body. Before I get to writing one from scratch, is there any reversing type recovery behavior i could get move_base to use?
Thanks!
↧
teb_local_planner: avoid constant path replanning
Hello,
We are working on a heavy omnidirectional platform using orientable wheels. We are using teb_local_planner for navigation. While the overall performance of the planner is good, we are facing serious issues in certain situations, particularly when there are close-by objects.
In these situations, teb planner is constantly re-planning the path, resulting in two different plans alternating quickly.
One of the main characteristics of the orientable wheels is that the platform has a pretty slow reaction to orientation changes (it has to reconfigure the wheel's orientation), so it is not able to react to the path change fast enough. The result is that the robot gets stuck in the position, with the wheels "dancing" between the two required configurations for the two different alternating paths.
Here are a coupe of sample videos ([one](https://youtu.be/zUkB8gfuFtE), [two](https://youtu.be/HgpyNAnvDok)) (rviz of the real robot) in which it can be appreciated. The plan is alternating between two apparently safe paths, but the robot is unable to configure wheels in time to follow a plan before it changes. So it gets stuck and doesn't move.
Here is [another video](https://youtu.be/yIB_y_ZXc6M ) of the robot stuck in a similar situation. However, this [other video](https://youtu.be/Qpq7MRYuxd8) shows how the robot is able to travel one path in one direction, but gets stuck in the same way in the opposite. As is seen in the video, the robot is actually capable of do it, but the planner is not able to create an adequate plan. When manually setting an additional "waypoint", the robot is able to get out. It can be seen, however, how the robot struggles with alternating re-plans several times.
We have tried to penalize angular acceleration to compensate for the slow reaction of the robot. However, it doesn't seem to have any effect on the creation of alternating plans (which is actually the source of the problem) and higher acceleration limits seems to perform better (lots of not feasible trajectories with very slow angular accelerations).
Setting `legacy_obstacle_association` to true alleviates greatly the problem. It seems that including all the obstacles in the planning makes the robot to pass further away from obstacles and makes paths more stable. However, the problem persists when the robot needs to pass close to obstacles.
So far we haven't found or guess any way or parameter to force that the planner only changes the current plan under more strict conditions to avoid it alternate between two. Is there such an option? What other parameters can we tune to alleviate this behavior?
Thank you and best regards.
Current planner configuration:
TebLocalPlannerROS:
odom_topic: odom
map_frame: map
# Trajectory
teb_autosize: true
dt_ref: 0.3
dt_hysteresis: 0.1
global_plan_overwrite_orientation: false
max_global_plan_lookahead_dist: 5.0
feasibility_check_no_poses: 30
allow_init_with_backwards_motion: true
# Robot
max_vel_x: 0.2
max_vel_x_backwards: 0.2
max_vel_y: 0.2
max_vel_theta: 0.5
acc_lim_x: 0.2
acc_lim_y: 0.2
acc_lim_theta: 0.5
min_turning_radius: 0.0
wheelbase: 0.0
cmd_angle_instead_rotvel: false
footprint_model: # types: "point", "circular", "two_circles", "line", "polygon"
type: "line"
line_start: [0.3, 0.0]
line_end: [-0.3, 0.0]
min_obstacle_dist: 0.45
inflation_dist: 0.75
# GoalTolerance
xy_goal_tolerance: 0.1
yaw_goal_tolerance: 0.2
free_goal_vel: false
# Obstacles
include_costmap_obstacles: true
costmap_obstacles_behind_robot_dist: 2.0
obstacle_poses_affected: 30
legacy_obstacle_association: true
# Optimization
no_inner_iterations: 5
no_outer_iterations: 4
optimization_activate: true
optimization_verbose: false
penalty_epsilon: 0.1
weight_max_vel_x: 2
weight_max_vel_y: 2
weight_max_vel_theta: 1
weight_acc_lim_x: 1
weight_acc_lim_y: 1
weight_acc_lim_theta: 1
weight_kinematics_nh: 1 # it is an holonomic robot, must be low
weight_kinematics_forward_drive: 0
weight_kinematics_turning_radius: 0
weight_optimaltime: 1
weight_obstacle: 50
weight_dynamic_obstacle: 10 # not in use yet20.0
selection_alternative_time_cost: false
# Homotopy Class Planner
enable_homotopy_class_planning: false
enable_multithreading: true
selection_cost_hysteresis: 1.0
selection_obst_cost_scale: 100.0
selection_prefer_initial_plan: 0.95
selection_viapoint_cost_scale: 1.0
simple_exploration: false
max_number_classes: 4
roadmap_graph_no_samples: 15
roadmap_graph_area_width: 5
h_signature_prescaler: 0.5
h_signature_threshold: 0.1
obstacle_keypoint_offset: 0.1
obstacle_heading_threshold: 0.45
visualize_hc_graph: false
# Global plan following
weight_viapoint: 10
global_plan_viapoint_sep: -1 # -1 to disable
↧
move_base and tf transforms
Hey, I'm fairly new with ROS and I'm having trouble understanding the TF reference frames. There's something wrong with our navigation code, but the person who originally wrote it is busy with other things and I'm not totally convinced he understood the TF transforms in the first place based on his explanations.
If some of my vocabulary is being used incorrectly, please correct me, as that might be indicative of my lack of understanding here.
The objective is to, upon boot-up, examine images from a camera to identify Aruco markers on a wall nearby, then travel to a point X meters perpendicular to that wall. The Aruco code is working and outputting the correct numbers, but not in the same coordinate system that `move_base` wants.
We change to the proper coordinate system and then enter a new coordinate frame into the TF tree for the wall, say `base_wall`. We'll also have a frame for the camera and a frame for the center of the robot.
If Aruco is telling me that the center of the wall is 2 meters away on the X axis and 1.5 meters away on the Y axis, and that the robot is rotated, say 0.8 radians, what should I be putting in the transform tree for the location of the wall? Where is (0, 0)? Is it the robot? Where is the goal? If the robot is (0, 0), then does the robot move until the location of the goal is also (0, 0)? What about the rotation? In the picture below, do we consider the robot to be rotated or the wall rotated?
edit: Theta is not the angle of a right triangle like it looks here; it's the angle of the robot relative to the wall.
↧
Problem when using move_base in my own robot model
Dear everyone,
I am trying to implement navigation after gmapping and after looking at the API and other models liky husky I am finding some problems.
i will write down a series of things that are happening in my simulation so that you can have a good idea and a fast recognition of the issue:
1. I am using my own multi robot model with its own urdf description. It has a diff drive odom controller and a modified hokuyo laser.
2. Gmapping worked perfectly and I have a map of the environment.
3. Once I launch everything now including the amcl and move base launch, I get a map with the robot on it, its pointcloud, and the laser readings correct.
4. When I try to set a goal in rviz for moving it, it is set properly (displaying the following message: etting goal: Frame:map, Position(0.189, 1.851, 0.000), Orientation(0.000, 0.000, 0.952, 0.306) = A). HOWEVER, in the amcl launch terminal it says :
[ WARN] [1523364828.094209076, 2369.900000000]: Control loop missed its desired rate of 5.0000Hz... the loop actually took 0.3890 seconds.
AND most importantly the robot does not move.
5. I checked all the topics of move_base and all of them are working but cost_cloud and trajectory_cloud.
6. This is my tf tree (I cannot attach yet an image):
[link text](https://github.com/Randulfe/Swarm_Robotics_Project/blob/master/frames.pdf)
7. Do you think it is a problem only with moving the base?
8. What should I put as the robot base frame and the global frame? Maybe that is the problem.
I will be very pleased if someone can help me with this as it is a work for my dissertation and I have been stuck for weeks (and I do not have that much of time left :( )
Thanks
↧
↧
Global plan does not update in move_base
**Environment:**
OS: ubuntu 16.04 (Xenial) on an x64
ROS: kinetic
Navigation stack: 1.14.3
**Config:**
base_global_planner: "navfn/NavfnROS"
base_local_planner: "base_local_planner/TrajectoryPlannerROS"
planner_frequency: 10
**Problem:**
I have setup move_base as per the tutorial, however, Global Plan does not seem to update at a specified **planner_frequency**. It updates when the local_base_planner's path touches an obstacle, however, I want global plan to be recomputed with each new robot position. One way I seek to do this is to update the global plan at some frequency. Navigation tutorials mention that **planner_frequency** is new to Navigation stack 1.16.0. How do I update my Navigation stack with Kinetic ROS distribution? Also, if there is a better solution to my problem?
Some easy way to constantly update global path as robot moves with my existing setup.
Than you.
↧
The simplest way to explore the environment to find a target and return to base
What is the simplest way to autonomously explore the environment in a room avoiding obstacles, find a target (based on vision) and return at the original starting position? Detecting the target using vision is not necessary part of the question but I included it to explain the overall scope of the project.
I have a working differential drive robot with a LIDAR sensor and a camera, so the question refers more to what is the best / simplest navigation stack I can use?
I am going thru Navigation Stack tutorials but there are many options and I was hoping to get some practical advice
Are there any good examples in python?
↧
Custom layer not showing on Costmap2D
Hi all,
I configured move_base to include an additional layer produced by a PointCloud2:
Observation Source:
yellow_tape_layer:
observation_sources: barrier_tape_detection_scan
barrier_tape_detection_scan:
#sensor_frame: camera_rgb_optical_frame
data_type: PointCloud2
topic: /barrier_tape_detection_scan
observation_persistence: 100.0
marking: true
clearing: false
min_obstacle_height: -2.0
max_obstacle_height: 2.0
The point cloud shows correctly in rviz, transformations etc. are fine.
Note that I tried to manually set the sensor_frame as well - every second point cloud is published in another frame, which is why I tried to avoid that option - but neither case works. I even increased the observation_persistence, hoping that it would just ignore observations happening too quickly.
In general, I copied the configuration from out laser scanners producing the obstacle_layer:
enabling the layer in global and local costmap:
plugins:
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: yellow_tape_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
...
yellow_tape_layer:
enabled: true
max_obstacle_height: 2.0
origin_z: 0.0
z_resolution: 2
z_voxels: 1
unknown_threshold: 15
mark_threshold: 0
combination_method: 1
track_unknown_space: true
obstacle_range: 2.5
raytrace_range: 3.0
publish_voxel_map: true
Which is why I assumed it to work - however, no matter the sensory input, nothing shows in the costmap visualized in rviz. (//edit: I also set combination_method for the laser to 1, of course.)
On startup, move_base happily greets me and says it's going to listen on "barrier_tape_detection_scan" - no leading slash - but it does the same for the lasers, also dropping the slash there. As I said, there are certainly points published and I can visualize them in rviz, yet they never appear in the costmap.
Anything else I can try? Should I post a rosbag/all config files?
ROS Indigo, Ubuntu 14.04 (old, but no time to upgrade...)
↧
What is the position topic I should give move base when amcl is not used
I am using move base without amcl since I cannot use a predetermined map. The issue I am having is providing move_base with a position topic since from what I can tell, AMCL provides the robots position. Instead I am using aprilTags position but I don't know what topic and message type to remap the aprilTag position message to so that move base can use it. I have transforms from map->odom->base_link->kinect2_link->kinect2_ir_optical_fram->camera_depth_frame set up already and can visualize that in rviz. (I set map odom and baselink to the same frame ie. the transform is 0,0,0,1) the kinect depth scan to laserscan is working nicely and the costmap is generating.
Any help would be appreciated!
I am running ros kinetic, ubuntu 16.04 on an Intel NUC
↧
↧
Global Costmap Updating Mysteriously
Hello everyone! I'm experiencing some weird behavior while using costmaps in `move_base` which I hope someone can shed some light on.
Thanks in advance to anyone who bothers with reading this wall of text and formulating a reply. Please let me know if I missed some important detail, and I'll be happy to add more information to this! :)
But first...
## What I'm Trying to Achieve
I want to access costmap data directly, i.e. read the values from the map while knowing how to related them to `\map` coordinates. This is not complicated, and I believe I've achieved it with `tf` (I might have to debug it a bit, but that's beside the point). Seeing as I'm using Python, using the [Costmap2D](http://docs.ros.org/indigo/api/costmap_2d/html/classcostmap__2d_1_1Costmap2D.html) API is out of the question.
As such, I developed...
## My Approach
Given that the costmap is only published once in `/move_base/global_costmap/costmap`, and then updated via `/move_base/global_costmap/costmap_updates`, I've written a small Python node that continuously listens to these, updates the main map and then serves them on a `GetMap` service.
This would allow me to have access to the latest costmap as an `OccupancyGrid` whenever I needed it, which is fine for my purposes. Furthermore, serving the map over a service only on-demand should be substantially easier on bandwidth than constantly publishing all updates.
While testing this with `rviz`, I stumbled upon...
## The Problem
**In short, it seems that the costmap that `rviz` shows is different than the one I'm getting on the `/move_base/global_costmap/costmap` topic.**
I have changed my code to act as a simple passthrough (receiving the costmap on the `/move_base/global_costmap/costmap` topic and publishing it elsewhere) and **restarting my node leads me to see, in `rviz`, an updated map without any messages being published in `/move_base/global_costmap/costmap`** (which is monitored with a `rostopic echo`.
In other words, if I move the robot's 2D pose estimate around, leading it to "pollute" the global costmap with whatever trash it's picking up on its sensors, and then restart my node, this new data will be on the costmap published by **my node**, which at this point accesses **only** the `/move_base/global_costmap/costmap` topic which, according to the `rostopic echo` I'm starting at the beginning of the session, has only a single message being published since the beginning of the session (sequence number `seq` is zero).
What I'm doing is basically:
```
self._global_costmap = rospy.wait_for_message("/move_base/global_costmap/costmap", OccupancyGrid)
```
to get the first costmap, and then
```
rospy.Subscriber("/move_base/global_costmap/costmap_updates", OccupancyGridUpdate, self.costmap_cb)
```
to integrate the updates. **For testing purposes, `self.costmap_cb` is limited to:**
```
self._costmap_pub.publish(self._global_costmap)
```
i.e. it publishes the "initial" map every time an update is received, without touching it at all.
## My Theory
I'm thinking that `rviz` uses the aforementioned Costmap2D API to get updated maps. This way, when I set up a new display pointing to `/move_base/global_costmap/costmap`, it "knows" it's a costmap, and accesses the API to get the latest version instead of the barebones version published in that topic. Somehow, in ways I couldn't figure out on my own, it "knows" which costmap the topic (with a completely different name) refers to, and is somehow messing with my custom node and topic.
## My Set-up:
* Xubuntu 14.04
* ROS Indigo
* Latest versions of packages from repos
↧
sending a sequence of goals to move_base
Hi all,
I have a mobile robot which is navigating around a room and it can go from start to goal without any issues. Now, I want to send a sequence of goals to [move_base](http://wiki.ros.org/move_base) so that once the robot reaches its first goal, it automatically starts moving to its second goal and so on. One way which I can think of is to send a second goal when the robot reaches its first goal but how can I know that the robot has reached its first goal automatically? Does it publish anything on any topic once it reaches the goal or is any flag set or changed? Does anyone have any idea about how can it be done or is there a better way to send a sequence of goals to move_base so that the robot just keeps on going from one goal to another?
Any help will be appreciated.
Thanks in advance.
Naman Kumar
↧
Teb_local_planner feasibility check always fails
I am using move_base with teb_local_planner but on every goal I get the same result first teb says the feasibilty check failed with the following message
[ WARN] [1525093179.924067116, 152.844000000]: TebLocalPlannerROS: trajectory is not feasible. Resetting planner...
This is repeated until recovery behaviours are attempted, these also fail with the following messages :
[ERROR] [1525093221.607037380, 168.074000000]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
So it seems the robot thinks it is on an obstacle while it's not, because this also happens when the map is empty.
↧