Hi,
I'm currently using the teb local planner for a tricycle robot and it gives good results but I would like to i Increasing the max_vel_x parameter doesn't seem to change the speed and I am having a hard time with it with all the optimization parameters. Increasing the maximum x linear velocity doesn't change anything and cmd_vel remains around 0.25/0.3 m/s maximum.
I looked a bit at the the teb questions and it seems for example, that putting weight_acc_lim* to 0.0 or changing the footprint model would reduce computation time . When setting weight_acc_lim* to 0.0, the robot is not able to move anymore and the error " trajectory not feasible" appears on every goal I am trying to send.
Here is my current configuration for teb local planner :
**TebLocalPlannerROS:**
odom_topic: odom
map_frame: /odom
**# Trajectory**
teb_autosize: True
dt_ref: 0.3
dt_hysteresis: 0.1
global_plan_overwrite_orientation: True
allow_init_with_backwards_motion: False
max_global_plan_lookahead_dist: 1.5
feasibility_check_no_poses: 5
**# Robot**
max_vel_x: 0.8
max_vel_x_backwards: 0.2
max_vel_y: 0.0
max_vel_theta: 0.4
acc_lim_x: 0.15
acc_lim_y: 0.0
acc_lim_theta: 0.05
**# Carlike robot parameters**
min_turning_radius: 0.15 # Min turning radius of the carlike robot (compute value using a model or adjust with rqt_reconfigure manually)
wheelbase: 0.864 # Wheelbase of our robot
cmd_angle_instead_rotvel: True # stage simulator takes the angle instead of the rotvel as input (twist message)
**footprint_model:** # types: "point", "circular", "two_circles", "line", "polygon"
type: "polygon"
radius: 0.2 # for type "circular"
line_start: [0.0, 0.0] # for type "line"
line_end: [0.4, 0.0] # for type "line"
front_offset: 0.2 # for type "two_circles"
front_radius: 0.2 # for type "two_circles"
rear_offset: 0.2 # for type "two_circles"
rear_radius: 0.2 # for type "two_circles"
vertices: [[1.1,0.4],[-0.3,0.4],[-0.3,-0.4],[1.1,-0.4]]
**# GoalTolerance**
xy_goal_tolerance: 0.2
yaw_goal_tolerance: 0.2
free_goal_vel: False
**# Obstacles**
min_obstacle_dist: 0.5
include_costmap_obstacles: True
costmap_obstacles_behind_robot_dist: 1
obstacle_poses_affected: 30
costmap_converter_plugin: ""
costmap_converter_spin_thread: True
costmap_converter_rate: 5
**# Optimization**
no_inner_iterations: 5
no_outer_iterations: 4
optimization_activate: True
optimization_verbose: False
penalty_epsilon: 0.05
weight_max_vel_x: 590
weight_max_vel_theta: 120
weight_acc_lim_x: 370
weight_acc_lim_theta: 200
weight_kinematics_nh: 10000
weight_kinematics_forward_drive: 1000
weight_kinematics_turning_radius: 300
weight_optimaltime: 860
weight_obstacle: 50
weight_dynamic_obstacle: 10 # not in use yet
**# Homotopy Class Planner**
enable_homotopy_class_planning: True
enable_multithreading: True
simple_exploration: False
max_number_classes: 4
selection_cost_hysteresis: 1.0
selection_obst_cost_scale: 1.0
selection_alternative_time_cost: False
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
I tried lots of combinations with rqt_recofnigure and this one gives good results except that i seems to block the linear velocity to small values. I would like to rpevent the robot from going backwards and avoid obstacles coming on its way. Is there any parameters changes that could help keep this characteristics while increasing the velocity of the robot.
Thanks !
↧
Teb Local Planner : Increasing x linear velocity
↧
Why does the navfn plan a path through a wall
Hi,all, we are using [navfn in move_base](http://wiki.ros.org/navfn?distro=lunar) to plan a global path for a robot.
For now, the experiments are being done in a simulated environment by gazebo.
However, we found that if the robot is close to a wall, if a goal is on the another side of the wall, the generated path from navfn often goes through the wall. Please see the below two images.
The first image shows the generated path when the inflation layer is canceled. The second image shows the generated path with a running inflation layer. Both of these two path go through the wall.
I have read a similiar question [here](https://answers.ros.org/question/157296/navfn-planning-through-wall/). But the walls in the illustrated instance are intermittent(not constantly). On the contrary, as you can see from the below images, the walls are constantly(unintermittent).
Is this a bug of navfun?
Looking forwards to any advices to improve navfn! Thanks!
↧
↧
Navigation stack with hector mapping Issues - Lots of detail provided
Hi all,
I am currently trying to implement the navigation stack on a tank-steer robot (similar to differential drive but with 2 wheels on each side) and although the robot is able to navigate to navigation goals in fairly open areas, it seems to get "confused" by navigation goals around walls. All seems well at first and the robot begins to travel in the general direction of the path but then it begins to rotate in place. I am assuming that this is a recovery behavior but, even if a new goal is sent to the robot, it is unable to travel to the new goal. I have been playing with the parameters for several days now and I am still unable to fix this issue, or even isolate why it is happening!
It seems that when the robot gets "confused," the local_planer stops functioning properly (no path is generated) however, the global-planer seems to be working just fine.
Details:
I am using rplidar with hector mapping to produce a 2D map and give me my odometry. The topic that hector mapping uses to publish odometry only publishes the position and not the velocity of the robot (the velocity field in the odom msg is always 0 for all directions/rotations). I personally do not think this is the issue as the robot is still able to navigate to goals in open spaces.
I do notice error messages appear when running move_base (need to run robot the get exact errors):
- Extrapolation Error: Lookup would require extrapolation into the future. Requested time 1509126598.543527562 but the latest data is at time 1509126598.531893800 , when looking up transform from frame [scan_odom] to frame [map]
** I think this is caused by the scan_odom tf frame (generated by hector mapping) not being future dated like AMCL does but I thought this problem was supposed to be fixed when the tf.waitfortransform() was added to the navigation stack code back in 2014
- Global Frame: scan_odom Plan Frame size XX: map
** The number XX varies from 19 to 45 (in one test run)
I do also notice warn messages appear when running move_base:
- Could not transform the global plan to the frame of the controller
**I have no clue and to what is causing this warn messages.
Here are my launch and yaml files for the move_base/navigation stack:
move_base.launch:
<launch><node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
<!-- Added to remove Error regarding expected 20Hz -->
<param name="controller_frequency" value="5.0" />
<rosparam file="$(find motor_api)/costmap_common_params.yaml" command="load" ns="global_costmap" />
<rosparam file="$(find motor_api)/costmap_common_params.yaml" command="load" ns="local_costmap" />
<rosparam file="$(find motor_api)/local_costmap_params.yaml" command="load" />
<rosparam file="$(find motor_api)/global_costmap_params.yaml" command="load" />
<rosparam file="$(find motor_api)/base_local_planner_params.yaml" command="load" />
</node>
</launch>
costmap_common_params.yaml:
footprint: [[0.32, 0.31], [-0.32, 0.31], [-0.32, -0.31], [0.32, -0.31]]
transform_tolerance: 0.4
obstacle_range: 1.5
raytrace_range: 2.0
inflation_radius: 0.157 #6 Inches
observation_sources: laser_scan_sensor point_cloud_sensor
laser_scan_sensor: {
sensor_frame: laser,
data_type: LaserScan,
topic: scan,
marking: true,
clearing: true,
expected_update_rate: 0.2
}
point_cloud_sensor: {
sensor_frame: camera_link,
data_type: PointCloud2,
topic: voxel_cloud,
marking: true,
clearing: true,
expected_update_rate: 0.3,
min_obstacle_height: 0.0508 #2 Inch
}
global_costmap_params.yaml:
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 5.0
static_map: true
width: 20.0
height: 20.0
local_costmap_params.yaml:
local_costmap:
global_frame: scan_odom
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 2.0
static_map: false
rolling_window: true
width: 5.0
height: 5.0
resolution: 0.025
Any help would be appreciated! Please let me know if you would like more information.
↧
move_base functionality
where can I find a move_base functionality scheme?
↧
How can I use /bumper topic data in move_base ?
Hi there,
I am new to ROS and ROS navigation stack. Right now I am trying to use /bumper topic data ( msg->left.state and msg->right.state ) on roomba_500_series in move_base. The topic has been already published from /roomba560_node. I would like to know how to use(subscribe) it in move_base. Please let me know if you know any.
(What I would like to do is to use bumper's right state and its left state ( true or false ). For example, if right state is true, I let roomba turn left and go straight.)
↧
↧
API call for determine new map position
Hi,
Other than using standard trig - is there an API call that give the data below say will return the new position to pass to the navigation stack if I command the robot to move 0.5 meters backwards:
position:
x: 1.95812040039
y: 1.32759493657
z: 0.0
orientation:
x: 0.0
y: 0.0
z: 0.702802831861
w: 0.71138469166
Thanks
Mark
↧
How to use two different navigation stack packages?
Hey guys,
I'm pretty new to ros and i need to implement a new navigation stack for one robot. I have three robots running in a simulation and for one robot i need a customized navigation stack, but for the other two robots i need the normal navigation stack.
I tried to get the navigation stack from github and rename it, but i recognized that i have to change every namespace (packages, cmake and even node names in the source code). This is really frustrating.
Does anyone know a better, cleaner way to do so? Or even has a fully renamed navigation stack package? :)
↧
How to setParam of one of the move_base parameters if getParam function is working?
Hello everyone,
I am currently struggling with the next problem:
- I wrote a node in C++ that in its constructor I want to test if certain parameters of move_base exist and if they exist and have other values than I need for my application I want to change those values. My problem is that the test for the parameters is working, the getParam is working but when I try to set the parameters, with rqt_reconfigure and also in rviz i see that the param remains the same.
- the piece of relevant code that I wrote is the following:
float costmap_global_infl_infl_rad;
if (nh_param.getParam("/move_base/global_costmap/inflation_layer/inflation_radius", costmap_global_infl_infl_rad))
{
ROS_INFO("Got param: ../global_costmap/inflation_layer/inflation_radius");
if(costmap_global_infl_infl_rad < 0.15)
{
std::cout<
↧
Adding objects in MoveIt: fixed in the world while the mobile manipulator is moving: confusion with root_joint, planning_frame and srdf structure
Hi all,
Sorry if this question is answered somewhere else, but I didn't find a clear answer.
In the context of a mobile manipulator, we use move_base for base navigation and moveIt for arm planning.
We have an issue when adding parts and objects to the MoveIt planning scene: they are added "fixed" to the robot.
So when the robot moves, the parts move with it... :-( Not the expected behavior!
Another thing we'd like to do in the future but that our current issue will also not allow: having a rgbd sensor fixed to a wall and providing an octomap to MoveIt...
So, digging into it, I'm not sure if we have an issue with:
- our custom robot urdf/srdf structure (we do use a virtual joint between /map and /base_footprint in the SRDF)
- the overall concept of the Moving Planning scene, root_joint and planningFrame... and how they are linked to the gmapping's map.
So what we are expecting to do, is it even feasible?
should the root_joint of my custom robot be base_link? or the map/world_frame?
we can querry for the current PlanningFrame (getPlanningFrame() ), but there is no way to set it. So I guess it is generated at the construction of the PlanningScene... and thus will use the first frame of the URDF... which will never be the Map frame...
I think you got it: I'm missing a connection between all these concepts.
Can someone help?
Thanks
Damien
↧
↧
Obstacle Avoidance
Hi,
Im wroking on a Robot that do the mapping, I'm using UltraSonic Sensors, IMU and Hall Sensors From the BLDC Motor, Arduino Mega 2560 and ROS Kinetic.
The next step is the obstacle avoidance. So the question is:
**How can I do obstacle avoidance using Lasersan data ???**
↧
I wantna add sonar to move_base
I dont know how to add sonar data to move_base.
I have created map with lidar2D, but 2D Laser navigation is unsatisfactory, I think I should add sonar data to move_base.
but I dont know the best way to do that.
↧
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?
↧
navigation stack problem in real robot
Hello all
My team's project is a mobile robot with ROS ( using navigation stack)
----------------------------------------
we implement the hardware, test it and it works well.
----------
we test it with move_base we select a goal. getting a path but the movement of the motors was not stable. it doesn't move in the map and in the reality it tries to turn the motors left and right and the straight move is not continuous but like pulses. so we didn't get a movement on the path specified.
*the RQT_graph, frames and robot photos are attached*
thanks for help
----------
----------
↧
↧
Robot rotates around a point instead of navigating to Goal Position when working with amcl
Hello,
I have a custom robot with 2 wheels, a camera, and a laser rangefinder. I am trying to localize the robot using amcl.
I had everything set up. When rviz was launched I would define the initial 2D pose estimate and the used to define the 2d Nav Goal in RViz as well.
However, I implemented a basic node to publish to the topic so that I could have the robot move to the goal directly. When I run that node, RViz displays the correct path to the goal. But the robot starts moving forward and after a while (usually around the same spot) it starts to rotate around a single point for some reason.
I am not sure why that's the case. It works fine when I try to run it via RViz but not via the node. The code I am working with for the node -
#include
#include
#include
#include
typedef actionlib::SimpleActionClient MoveBaseClient;
int main(int argc, char** argv) {
ros::init(argc, argv, node_name);
// create the action client
// true causes the client to spin its own thread
MoveBaseClient ac("move_base", true);
// Wait 60 seconds for the action server to become available
ROS_INFO("Waiting for the move_base action server");
ac.waitForServer(ros::Duration(5));
ROS_INFO("Connected to move base server");
// Send a goal to move_base
move_base_msgs::MoveBaseGoal goal;
goal.target_pose.header.frame_id = "map";
goal.target_pose.header.stamp = ros::Time::now();
goal.target_pose.pose.position.x = 0.995;
goal.target_pose.pose.position.y = -2.996;
goal.target_pose.pose.orientation.w = 1;
ac.sendGoal(goal);
// Wait for the action to return
ac.waitForResult();
if (ac.getState() == actionlib::SimpleClientGoalState::SUCCEEDED)
ROS_INFO("You have reached the goal!");
else
ROS_INFO("The base failed for some reason");
return 0;
}
I run the above using `rosrun package_name node_name`
This is what it looks like right now. The robot started to rotate instead of following the green path.
↧
When working with amcl why does the robot try to move closer to the wall in an open area rather than navigating more towards the goal?
For example, the following
The robot is closer to the wall instead of following the path to the goal (green line).
I have noticed that happen all the time. Why is that so? Is there a particular parameter that influences this? As soon as the robot gets close to the wall it gets better at navigating straight to the goal I think. Or is it something related to amcl algorithm(s)?
Here is the robot shortly after reaching close to wall and then moving towards the goal again.
What causes such a pattern/behavior?
↧
Is there is trajectory planner for quadrotor / holonomic robot in ROS?
Hi All,
I wan to control a quadrotor with move_base package, this quadrotor is stable controlled by it's on-board processer, so I just need to move it.
But the problem is this quadrotor can not accept velocity_yaw command, or if I send rotation command it will become very unstable.
So, I want to know is there a path planner for only translation without rotation?
Thanks..
↧
Which function is the core of move_base ?
Hi there,
I am new to ROS navigation stack. I am confused that which function is the core of `move base`.
My understanding is that `MoveBase::executeCb`'s while statement is the core of the operation controller in move base.
Does anyone know it is correct or not ? Please let me know if you know any. Thank you.
↧
↧
[move_base] make_plan service crashes, transport error
Hey,
so I wrote a custom global planner plug-in and I have tested extensively, so I don't believe the error is there. can launch rviz with move_base, costmap and a robot description. The issue arises as I want to call the service make_plan() from the terminal. I am using the template completion provided by ROS.
The first time I call it, it gives me following error message but still compiles and publish the plan.
ERROR: transport error completing service call: unable to receive data from sender, unable to receive data from sender, check sender's logs for details
The second time I call the service move_base crashes and the following error message is displayed
[move_base-6] process has died [pid 10011, exit code -11, cmd /opt/ros/kinetic/lib/move_base/move_base __name:=move_base __log:=/home/rue011/.ros/log/06aca0b2-d577-11e7-bb08-d481d7bb040a/move_base-6.log]. log file: /home/rue011/.ros/log/06aca0b2-d577-11e7-bb08-d481d7bb040a/move_base-6*.log
Hope somebody can help, I have no Idea whats going wrong.
The log file ".../move_base-6*.log" is not not generated.
↧
Failed to create the global_planner/GlobalPlanner planner
Setup: ROS Kinetic, Ubuntu 16.04
on the TurtleBot platform, when launching the move_base node configured for the global_planner/GlobalPlanner, I receive the following error:
`Failed to create the global_planner/GlobalPlanner planner, are you sure it is properly registered and that the containing library is built? Exception: According to the loaded plugin descriptions the class global_planner/GlobalPlanner with base class type nav_core::BaseGlobalPlanner does not exist. Declared types are navfn/NavfnROS`
I load `move_base_params.yaml` within `move_base` as follows:
``
`
↧
clearing costmap using move_base/clearCostmap service
Hi all,
I have a layered [costmap](http://wiki.ros.org/costmap_2d) with `static_layer`, `obstacle_layer` (for Lidar and Kinect) and `inflation_layer` and there are situations when I need to clear out the `costmap` manually in the code. I am using `move_base/clearCostmapService` service to clear the costmap. Whenever I get a new goal, I call this service to clear the costmap and then the planner generates a new plan. AFAIK, when I call `move_base/clearCostmap` service, it clears the costmap and then fills it with `static_map` immediately meaning that obstacles which are not in the map are cleared. The problem I am having right now is that sometimes, planner generates a path through obstacles in the static_map (maybe because, costmap is cleared but has not been filled with `static_map` yet). I am calling the service when I receive a new goal and the planner plans a path after the service is called. Can someone suggest what can be the problem and how to fix it permanently? Code snippet from `move_base.cpp` ::
void MoveBase::executeCb(const move_base_msgs::MoveBaseGoalConstPtr& move_base_goal)
{
if(!isQuaternionValid(move_base_goal->target_pose.pose.orientation)){
as_->setAborted(move_base_msgs::MoveBaseResult(), "Aborting on goal because it was sent with an invalid quaternion");
return;
}
///// Added on 12/23/2015
boost::unique_lock lock1(planner_mutex_);
runPlanner_ = false;
std_srvs::Empty srv;
if(clear_costmaps_client.call(srv))
ROS_INFO("I got the goal and the costmap layers are reset!!!!!"); // It prints this and continues but the costmap is not reset properly, it takes some time after this for the costmap to properly reset
lock1.unlock();
/////
geometry_msgs::PoseStamped goal = goalToGlobalFrame(move_base_goal->target_pose);
//we have a goal so start the planner
boost::unique_lock lock(planner_mutex_);
planner_goal_ = goal;
runPlanner_ = true;
planner_cond_.notify_one();
lock.unlock();
current_goal_pub_.publish(goal);
std::vector global_plan;
**Update :**
It looks like the planner thread plans the path before the clearing (or resetting) Costmap thread is finished. Correct me if I am wrong. How can I make sure to run the planner thread only when the clearing Costmap thread is finished?
Any suggestions will be appreciated Let me know if you need more information from me.
Thanks in advance.
Naman Kumar
↧