I am currently using a VLP-16 device that produces Pointcloud data type messages. I have tried with no success to convert them to Laserscan for Autonomous Navigation (as that appears to be the popular choice) and would like to consider alternatives.
Where can I found existing robots with source code that navigate with simulation support and Pointcloud/Pointcloud2 data produced from LIDAR devices?
↧
Code examples of Pointcloud Autonomous Navigation?
↧
The robot does not follow path proper if goal in /map frame
Hello,
I'm running `ROS Kinetic` in `Ubuntu 16.04` on `Lattepanda`.
I want to send my robot to goal in `/map` frame. When I do this I have warning message:
Control loop missed its desired rate of 5.0000Hz... the loop actually took 0.9997 seconds
And my robot goes to goal not straight but like snake around path.
CPU not loaded.
Also when I change `global_frame` from `/map` to `/odom` in `global_costmap_params.yaml` everything was fine. Not warnings and robot follow path correctly, but my goal move with `/odom` frame. My localization node make transform `/map` to `/odom` and goal position depends on it. I want to fix my goal in `/map` frame.
I don't provide static map. I want to navigate my robot without map.
I use IMU with magnetometer, encoders, GPS. To get localization I use `robot_localization` and `navsat_transform` node for `base_footprint -> odom` and `odom -> map` transforms.
To simplify robot testing I generate empty laserscan data.
**move_base.launch**
↧
↧
Oscillation when using orientation field of move_base with teb_local_planner.
Hi everyone!
I am having an issue with the orientation fields of the move_base package and the teb_local_planner.
At first I would just set the orientation.w field to 1.0 and leave the xyz components set to 0. However, now I want to make the robot have a specific orientation when it reaches its goal location.
My train of thought was that if I wanted to rotate the robot around its base that I would have to rotate 0.5 * PI around its yaw axis. If I change the yaw component in my gazebo simulation then I can indeed rotate the robot around its y-axis.
I found [this tutorial](http://wiki.ros.org/tf2/Tutorials/Quaternions) on the ROS wiki which states that you can convert a roll, pitch, yaw rotation to a quaternion.
Suppose my RPY respectively are [0, 0, 0.5 * PI] then the Quaternion is (w,x,y,z) (0.707107, 0, 0, 0.707107) move_base s canaccepts this as a valid quaternion and thus the goal is active. However, the robot starts to oscillate due to its local planner. I added an image of the RVIZ view where I visualized both the local and global plan. The robot stays on the first pose in the red poseArray and moves back and forward.
Is my quaternion input incorrect or am I using the orientation field incorrectly?
My goal is to have the robot arrive at its goal location with a specific orientation.
Here is the output of my navigation nodes:
SUMMARY
========
PARAMETERS
* /move_base/base_local_planner: teb_local_planner...
* /move_base/global_costmap/footprint: [[0.25, 0.154], [...
* /move_base/global_costmap/global_frame: map
* /move_base/global_costmap/inflation_radius: 0.55
* /move_base/global_costmap/obstacle_range: 2.5
* /move_base/global_costmap/raytrace_range: 3.0
* /move_base/global_costmap/robot_base_frame: base_link
* /move_base/global_costmap/static_map: True
* /move_base/global_costmap/update_frequency: 5.0
* /move_base/local_costmap/footprint: [[0.25, 0.154], [...
* /move_base/local_costmap/global_frame: map
* /move_base/local_costmap/height: 10.0
* /move_base/local_costmap/inflation_radius: 0.55
* /move_base/local_costmap/obstacle_range: 2.5
* /move_base/local_costmap/publish_frequency: 40.0
* /move_base/local_costmap/raytrace_range: 3.0
* /move_base/local_costmap/resolution: 1
* /move_base/local_costmap/robot_base_frame: base_link
* /move_base/local_costmap/rolling_window: False
* /move_base/local_costmap/static_map: True
* /move_base/local_costmap/update_frequency: 60.0
* /move_base/local_costmap/width: 10.0
* /robot_pose_ekf/debug: True
* /robot_pose_ekf/freq: 50.0
* /robot_pose_ekf/imu_used: True
* /robot_pose_ekf/odom_used: True
* /robot_pose_ekf/output_frame: map
* /robot_pose_ekf/self_diagnose: False
* /robot_pose_ekf/sensor_timeout: 1.0
* /robot_pose_ekf/vo_used: False
* /rosdistro: kinetic
* /rosversion: 1.12.14
NODES
/
link1_broadcaster (tf2_ros/static_transform_publisher)
link2_broadcaster (tf2_ros/static_transform_publisher)
map_server (map_server/map_server)
move_base (move_base/move_base)
robot_pose_ekf (robot_pose_ekf/robot_pose_ekf)
ROS_MASTER_URI=http://localhost:11311
process[link1_broadcaster-1]: started with pid [19739]
process[link2_broadcaster-2]: started with pid [19740]
process[robot_pose_ekf-3]: started with pid [19758]
process[map_server-4]: started with pid [19776]
process[move_base-5]: started with pid [19841]
[ INFO] [1540834009.296069299, 13.907000000]: Loading from pre-hydro parameter style
[ INFO] [1540834009.310812145, 13.922000000]: Using plugin "static_layer"
[ INFO] [1540834009.317225170, 13.928000000]: Requesting the map...
[ INFO] [1540834009.520453286, 14.132000000]: Resizing costmap to 100 X 100 at 1.000000 m/pix
[ INFO] [1540834009.621709934, 14.232000000]: Received a 100 X 100 map at 1.000000 m/pix
[ INFO] [1540834009.626584742, 14.237000000]: Using plugin "obstacle_layer"
[ INFO] [1540834009.628411482, 14.239000000]: Subscribed to Topics:
[ INFO] [1540834009.638543716, 14.249000000]: Using plugin "inflation_layer"
[ INFO] [1540834009.685154386, 14.296000000]: Loading from pre-hydro parameter style
[ INFO] [1540834009.699557342, 14.311000000]: Using plugin "static_layer"
[ INFO] [1540834009.703080097, 14.314000000]: Requesting the map...
[ INFO] [1540834009.705428648, 14.317000000]: Resizing costmap to 100 X 100 at 1.000000 m/pix
[ INFO] [1540834009.806388473, 14.417000000]: Received a 100 X 100 map at 1.000000 m/pix
[ INFO] [1540834009.811111339, 14.422000000]: Using plugin "obstacle_layer"
[ INFO] [1540834009.814059193, 14.425000000]: Subscribed to Topics:
[ INFO] [1540834009.824545616, 14.435000000]: Using plugin "inflation_layer"
[ INFO] [1540834009.866551233, 14.477000000]: Created local_planner teb_local_planner/TebLocalPlannerROS
[ INFO] [1540834009.920261537, 14.531000000]: No robot footprint model specified for trajectory optimization. Using point-shaped model.
[ INFO] [1540834009.920337374, 14.531000000]: Parallel planning in distinctive topologies enabled.
[ INFO] [1540834009.920377444, 14.531000000]: No costmap conversion plugin specified. All occupied costmap cells are treaten as point obstacles.
[ INFO] [1540834010.103009231, 14.714000000]: Recovery behavior will clear layer obstacles
[ INFO] [1540834010.108103576, 14.719000000]: Recovery behavior will clear layer obstacles
[ INFO] [1540834010.143028158, 14.754000000]: odom received!
Sometimes (not always) these warnings are shown:
[ WARN] [1540833817.329080357, 41.430000000]: TebLocalPlannerROS: possible oscillation (of the robot or its local plan) detected. Activating recovery strategy (prefer current turning direction during optimization).
[ INFO] [1540833840.461887304, 64.530000000]: TebLocalPlannerROS: oscillation recovery disabled/expired.
[ WARN] [1540833864.453728681, 88.480000000]: TebLocalPlannerROS: possible oscillation (of the robot or its local plan) detected. Activating recovery strategy (prefer current turning direction during optimization).
Excuse me if the answer is very obvious. I looked through all the related questions and tutorials on the ROS wiki and this website but I could not find a solution for my problem.
Thanks in advance! I hope I did all the formatting correctly.
↧
teb_local_planner generates infeasible local plan, global plan is OK, for car-like robot
I have an Ackermann steering drive based robot or in other words ***car-like robot***. I am using `move_base` with `teb_local_planner` for path planning and control.
This is how my local and global plan look like:
You can see that the global plan (in green) is quite straightforward for the chosen goal and starting point. The local plan (in blue) is all over the place. And the robot ends up and gets stuck far away from the global plan. I suspect something is wrong with my parameter configuration, but I cannot figure out what.
Here are my params for the `TEBLocalPlanner`:
TebLocalPlannerROS:
odom_topic: /vesc/odom
map_frame: map
transform_tolerance: 0.3
# ******* Trajectory **********
teb_autosize: True
dt_ref: 0.4
dt_hysteresis: 0.1
global_plan_overwrite_orientation: True
allow_init_with_backwards_motion: True
max_global_plan_lookahead_dist: 3.0
feasibility_check_no_poses: 2
# ********** Robot **********
max_vel_x: 1.5
max_vel_x_backwards: 1.0
max_vel_y: 0.0
max_vel_theta: 2.5
acc_lim_x: 2.0
acc_lim_theta: 4.0
# ********************** Carlike robot parameters ********************
min_turning_radius: 0.82
wheelbase: 0.34
cmd_angle_instead_rotvel: False
footprint_model:
type: "line"
line_start: [0.0, 0.0]
line_end: [0.3, 0.0]
# ********** GoalTolerance **********
xy_goal_tolerance: 0.2
yaw_goal_tolerance: 3.0
free_goal_vel: False
# ********** Obstacles **********
min_obstacle_dist: 0.20
include_costmap_obstacles: True
costmap_obstacles_behind_robot_dist: 0.3
obstacle_poses_affected: 30
inflation_dist: 0.25
costmap_converter_plugin: ""
costmap_converter_spin_thread: True
costmap_converter_rate: 5
# ********** Optimization Parameters **********
weight_kinematics_forward_drive: 100.0
weight_kinematics_turning_radius: 500.0
weight_acc_lim_x: 0.0
# ********** Parallel Planning Parameters **********
enable_homotopy_class_planning: True
Most of the parameters are set to the default values. Some notable exceptions:
1. `min_turning_radius: 0.82`. I have a car like robot with max steering angle of 22 degrees and wheel base of 0.34 m.
2. `weight_kinematics_turning_radius: 500.0`. I increased it from 1 to 500 so that turning radius constraints
are enforced.
3. `weight_kinematics_forward_drive: 100.0`. I want the robot to favour forward motion.
↧
Bias costmap values to avoid zones
Hi,
I am using the navigation stack on ros kinetic (Ubuntu 16.04) and wanted to create regions of lower preference for the robot.
Basically what I am looking for, is having a path/zone, that remains accessible to the bot(holonomic), but is only chosen as a last resort for navigation...something like a very high cost path, that would only be better than a 'no path' scenario.
I have tried biasing the costs of the cells in the static costmap of this zone to different values (cost<=251) or (cost = 252).
When cost<=251 is set, the navigation stack returns returns a path around this 'zone' only if the path through is of comparable length. However, if the path around is way longer than the path through this zone, it still picks the through path. I understand that the cost through still turns out lower than along the much longer route.
When I set 252, in no case does it plan through the zone and shows failure if for example the goal lies within this zone.
Hence, neither of these cases meet my requirement of 'last resort path'.
Alternatively, I could mark these zones as 'prohibited zones' (cost > 251) and switch them off in a recovery behaviour (and toggle back on once planned through..). However, I was wondering if anyone could guide me to something less 'hacky' in this regard.
P.S.: Please let me know in case I am missing crucial specifics on the question.
↧
↧
Can I use the same map for multiple robots running move_base
For some experiments, I am trying to use two ground vehicles which would share the same map. Right now I am working on my configurations using gazebo. What I am trying to do is use the move_base package and launch a node for each vehicle. the issue I am running into is the mapping of topics and parameters. If I add a namespace to the launch file, then the map topic is also remapped. For example:
↧
Sending goals to navigation stack using code
Hi,
I think this question is not really related to rtabmap, but I'm hoping that you could point me to the right direction.
I am able to send goals to navigation stack following tutorials on this site http://wiki.ros.org/navigation/Tutorials/SendingSimpleGoals. My question is, how can I verify that the location of the goal pose itself is free of obstacles(a valid goal pose)? I'm trying to code up something that will generate valid goal poses by itself.
Thanks,
CJ
↧
robot doesn't stop when it reach to a goal
Hello,
my robot (diff_drive) is navigate quite well but when it reach to the goal it doesn't stop and keep turning.
I set xy_tolerance and yaw_tolerance to high values but there is no change.
the odometry is good and the rate of the all nodes are fine.
I am using RTABmap and encoders (not a visual odometry), move_base and depthimage_to_laserscen pkg. also, I am not use AMCL for localization.
Its velocity is slow for precision.
Do you have an idea for solving this problem?
Thanks
↧
RangeSensorLayer::updateBounds Segmentation fault.
Hi All,
I like to integrate ultrasonic sensors into costmap bu getting following error when I run the move_base.
Thread 11 "move_base" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffcb7fe700 (LWP 9665)] 0x00007fffe4069067 in range_sensor_layer::RangeSensorLayer::updateBounds(double,double, double, double*, double*, double*, double*) () from /opt/ros/kinetic/lib//librange_sensor_layer.so
local costmap:
local_costmap:
global_frame: /map
robot_base_frame: base_link
update_frequency: 2.0
publish_frequency: 1.0
static_map: false
rolling_window: true
width: 1.0
height: 1.0
resolution: 0.05
transform_tolerance: 0.5
plugins:
- {name: range_sensor_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
# - {name: inflation_layer, type: "costmap_2d::InflationLayer"}
global costmap:
global_costmap:
global_frame: /map
robot_base_frame: base_link
update_frequency: 2.0
publish_frequency: 1.0
rolling_window: false
static_map: true
width: 3
height: 3
transform_tolerance: 0.5
plugins:
#- {name: range_sensor_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
#- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
#- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
common costmap:
footprint: [ [-0.05,-0.05], [0.05,-0.05], [0.05,0.05], [-0.05,0.05] ]
transform_tolerance: 0.2
map_type: costmap
obstacle_layer:
enabled: true
obstacle_range: 3.0
raytrace_range: 3.5
inflation_radius: 0.1
track_unknown_space: false
combination_method: 1
observation_sources: laser_scan_sensor
laser_scan_sensor: {data_type: LaserScan, topic: scan, marking: true, clearing: true}
range_sensor_layer:
topics: ["/ultrasound", "/ultrasound1"]
no_readings_timeout: 0.0
clear_threshold: 0.46
mark_threshold: 0.98
static_layer:
enabled: true
map_topic: "/map"
inflation_layer:
enabled: true
cost_scaling_factor: 5.0 # exponential rate at which the obstacle cost drops off (default: 10)
inflation_radius: 0.1 # max. distance from an obstacle at which costs are incurred for planning paths.
reading from arduino:
#include
#include
#include
ros::NodeHandle nh;
sensor_msgs::Range range_msg;
sensor_msgs::Range range_msg1;
ros::Publisher pub_range( "/ultrasound", &range_msg);
ros::Publisher pub_range1("/ultrasound1", &range_msg1);
char frameid[] = "/ultrasound";
char frameid1[] = "/ultrasound1";
float getRange_Ultrasound(int pin_num){
int val = 0;
val=analogRead(pin_num);
float range = val;
return range/81; // (0.0124023437 /4) ; //cvt to meters
}
void setup()
{
nh.initNode();
nh.advertise(pub_range);
nh.advertise(pub_range1);
range_msg.radiation_type = sensor_msgs::Range::ULTRASOUND;
range_msg.header.frame_id = frameid;
range_msg.field_of_view = 0.1; // fake
range_msg.min_range = 0.0;
range_msg.max_range = 6.47;
range_msg1.radiation_type = sensor_msgs::Range::ULTRASOUND;
range_msg1.header.frame_id = frameid1;
range_msg1.field_of_view = 0.1; // fake
range_msg1.min_range = 0.0;
range_msg1.max_range = 6.47;
pinMode(8,OUTPUT);
digitalWrite(8, LOW);
}
long range_time;
void loop()
{
//publish the adc value every 50 milliseconds
//since it takes that long for the sensor to stablize
if ( millis() >= range_time ){
int r =0;
range_msg.range = getRange_Ultrasound(0);
range_msg.header.stamp = nh.now();
pub_range.publish(&range_msg);
range_msg1.range = getRange_Ultrasound(1);
range_msg1.header.stamp = nh.now();
pub_range1.publish(&range_msg1);
range_time = millis() + 50;
}
nh.spinOnce();
}
I could not found the reason for the problem. Is there anyone can suggest a solution to that problem?
Thanks
↧
↧
Is there an existing Dubins pathing package?
Hi everyone,
I have little experience with ROS and ROS open source packages, so bare with me. I am hoping if someone could inform me on a move_base like package that interfaces with gmapping using dubins pathing (circles)? The solution I am trying to implement is almost exactly like the husky demonstrations using move_base and gmapping however I am unable to pivot on the spot like husky is able to (I can but we are preferring not to for mechanical reasons). Would anyone happen to know of a dubins pathing-esque move_base package or whould I work on developing my own?
Thanks, Grant.
↧
robot_localization transform functions for move_base?
Hi,
I am curious as to the coordinate frames that my odometry data is in after using the robot_localization package ekf as a localisation estimator? I am using wheel odometry and an IMU in a continuous ekf and navsat (from a gps) (and the previous two sensors) in a discrete ekf.
ekf_cont:
frequency: 30
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.0
print_diagnostics: true
debug: false
map_frame: map
odom_frame: odom
base_link_frame: base_link
world_frame: odom
ekf_disc:
frequency: 30
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.0
print_diagnostics: true
debug: false
map_frame: map
odom_frame: odom
base_link_frame: base_link
world_frame: map
My solution needs to use this data in conjunction with move_base and gmapping. As I understand it I need to provide a transform for the discrete data. My IMU device is mounted in the exact center and my drive shaft is mounted at the exact centre (in one dimension at an equal distance from the centre in the other dimension, so the speed is measured from the centre in both dimensions).
As I understand, my continuous data has to be presented to move_base in the odometry frame and my discrete data has to be presented as a tf/tfMessage? [Clearpath Husky demo](https://roscon.ros.org/2015/presentations/robot_localization.pdf). If I understand correctly my continuous is in the odometry frame and my discrete is in the map frame but how do I produce this as a tf/tfMessage for my move_base node? Will
↧
Stop clearing recovery behaviour on some costmap layers
Hi,
I am using move_base with a gazebo simulation of a Turtlebot3 with Kinetic. I have a custom costmap layer which assigns a cost (arbitrary but let us say 50) based on the footprint of a robot (to avoid the robot going over ground it has already covered). The custom layer uses a costmap_2d::Layer class.
The global costmap uses: a "static layer" - created on-the-fly with gmapping, "obstacle layer" (using a 2D lidar), and an "inflation layer". The custom layer comes after these three in the plugins list, and all works as expected. (The local layer only uses an "obstacle layer" and "inflation layer").
Each are defined earlier in the param yaml file.
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
- {name: custom_layer, type: "custom_layer::CustomLayer"}
*The problem:*
When the costmap resizes (as the robot travels out of current bounds), the clearing recovery removes all non-lethal costs when it reverts back to the static layer map ([default behaviour](http://wiki.ros.org/clear_costmap_recovery)). This completely removes any costs associated with the custom layer (unwanted behaviour!).
*What I have tried - and did not work:*
1) For both the global costmap and the move_base params trying to turn off recovery behaviours using `recovery_behavior_enabled: false`
2) Setting above back to true, and defining the conservative and aggressive clear radius to large values in the global cost params
recovery_behaviors: [
{name: conservative_clear, type: clear_costmap_recovery/ClearCostmapRecovery},
{name: aggressive_clear, type: clear_costmap_recovery/ClearCostmapRecovery}
]
conservative_clear:
reset_distance: 10.00
aggressive_clear:
reset_distance: 10.00
3) Trying to specify which layers are effected by clearing behaviour
conservative_clear:
reset_distance: 10.00
layer_names: ["obstacle_layer"]
aggressive_clear:
reset_distance: 10.00
layer_names: ["obstacle_layer"]
*My question:*
Is there any way to stop the clearing behaviour from affecting a particular layer? I would still like to keep the clearing behaviours on in general (e.g. obstacle layer).
If this is not possible - Is there a method to store non-lethal costs on a global map in a permanent manner? For example, would building a map separately and passing it to move_base somehow work?
Best wishes,
Andy West
↧
How to use only the global planner without the other move_base components?
I am working on an autonomous robot. I have implemented my own local planner and controller. I would just like to use the `costmap_2d` and `global_planner` from the ROS navigation stack. How do I launch the global costmap and global planner just like `move_base` would?
↧
↧
unexpected robot behaviour with navigationstack
Hello everybody,
i have some problems again and hope someone can help me. Following scenario:
- I have a robot platform, diff-drive with laser scanner mounted pointing forward
- i have already recorded a map with slam (g-mapping i guess was the one i used in the end)
- i have set up the navigation-stack with move_base like described [here](http://wiki.ros.org/navigation/Tutorials/RobotSetup)
- i can see everything in rviz (map, cost map, base, laser scans)
- i can set a goal in rviz and (most of the time) get a nice looking path
I'm pretty sure the move_base package is quiet powerful, but now comes the weird thing: the robot doesn't follow the path at all. It seems like it is ignoring the path at all and trying to find a way to the goal of it's own with horrible results. Something like:
- turning 180deg and driving in the opposite direction. Or,
- instead of just passing straight through some obstacles in front of it, turn 270deg and than heading directly towards one of them. Or
- ignoring the curve in the plan at the very beginning and just drive the first 1.5meters straight, than make the 90deg turn that has summed up in order to follow the rest of the path
One idea i had is that this might be the escape sequences that the move_base-node provides. So i tried to switch them off. The base is still doing point turns and also driving backwards.
So, before i start programming my own node that takes the path (list of stamped points) and calculate the velocity commands for x/theta, is anybody here experienced enough for being able to make a guess based on the "files" above what might cause this behavior?
Thanks for everybody taking the time for reading this.
------------------------------------------------
Lets start with the shortened .launch file:
↧
Using AMCL for navigation with hector slam
Hi guys, I'm trying to navigate on a given map(built by hector slam), and the odometry is only supplied by Lidar by using hector mapping (didn't use any other extra sensors ), and I'm using raspberry pi 3B to publish the /scan data to my computer(RViz, navigation, mapping). Now, when I use AMCL for navigation, there're some problems showed up(the particle seems weird), I search a lot but still don't know where is the problem, is there any one can please help me to check the problems, thank you very much!! (here is the link of picture:[AMCL_problems](https://drive.google.com/drive/folders/1SsC70rpfHKU8OFpaCkfwMn_4ZpzqjdbK?usp=sharing) )
↧
Issue for Moving base with leg tracker msgs
I am trying to run my script to send pose to my move_base from msgs. But it runs the code and waits without throwing any error. My tracker is leg running is running and providing me a People_tracked msg of
PeopleArray(Person[] people)
Person (geometry_msgs/Pose pose uint32 id).
Can't figure out the problem as there is no error.
class move_base_goal:
def __init__(self):
self.goal_pose = PersonArray()
self.new_person = Person()
self.goal_pose.people.append(self.new_person)
if not self.goal_pose.people:
return move_base_goal()
rospy.init_node('movebase_goal_py')
rospy.Subscriber("people_tracked", PersonArray, self.callback )
def callback(self,msg):
self.goal_pose.people[0].pose.position.x = msg.people[0].pose.position.x
self.goal_pose.people[0].pose.position.y = msg.people[0].pose.position.y
def movebase_goal(msg):
move = actionlib.SimpleActionClient('move_base',MoveBaseAction)
move.wait_for_server()
goal = MoveBaseGoal()
goal.target_pose.header.frame_id = "base_link"
goal.target_pose.header.stamp = rospy.Time.now()
goal.target_pose.pose.position.x = self.goal_pose.people[0].pose.x
goal.target_pose.pose.position.y = self.goal_pose.people[0].pose.y
goal.target_pose.pose.orientation.w = 1.0
move.send_goal(goal)
if __name__ == '__main__':
x = move_base_goal()
rospy.spin()
↧
Strange behavior between move_base Navigation Stack and Rviz
This is my graduation project from college and I can't figure out the problem. I have an environment build specifically for this project and build a map of it with hector SLAM. The goal is for the Mobile robot moving around the static map for specific goal set by Rviz.
`UPDATE THE OLD 2 BEHAVIORS ARE NOT HAPPENING ANYMORE: I ADJUSTED LINOROBOT COSTMAPS TO WORK FOR ME AND IT FIXED THOSE 2 ERRORS. HOWEVER, THIS SOLUTION INTRODUCED:`
> DWA planner failed to produce path
> Off Map 1.098, -0.050
**Old behaviors:**
> Rviz behavior Video: [Google drive
> Rviz localization
> video](https://drive.google.com/file/d/1AKhtZoMIMrkTengJJV6RVGA-c4bFaosM/view?usp=sharing)
>> Rviz behavior when trying to estimate
> pose: [Google drive estimate pose
> behavior](https://drive.google.com/file/d/1Qr6w6JOIF65OAzy3w22B0fuvbzO3LuPg/view?usp=sharing)
> **NOTE: the robot was not in the designed environment when taking this video, this video is just for demonstration**
>
**The errors I'm getting:** `UPDATED`
> roswtf:
WARNING The following node subscriptions are unconnected:
* /amcl:
* /tf_static
* /rviz_1542954558890249147:
* /move_base/TrajectoryPlannerROS/global_plan
* /move_base/NavfnROS/plan
* /tf_static
* /map_updates
* /move_base/TrajectoryPlannerROS/local_plan
* /rqt_gui_py_node_27505:
* /statistics
* /move_base:
* /tf_static
* /move_base/cancel
WARNING Received out-of-date/future transforms:
* receiving transform from [/amcl] that differed from ROS time by 1.176933497s
Found 1 error(s).
ERROR The following nodes should be connected but aren't:
* /move_base->/move_base (/move_base/global_costmap/footprint)
* /move_base->/move_base (/move_base/local_costmap/footprint)
> AMCL warning: **[ WARN]
> [1542907954.448988739]: Frame_id of
> map received:'/odom' doesn't match
> global_frame_id:'map'. This could
> cause issues with reading published
> topics**
`FIXED BY MAKING MAP_SERVER FRAME ID TO BE MAP`
>Rviz Global option's fixed
> frame: **map**
`FIXED BY THE COSTMAP CONFIG`
> Blockquote
> TF configuration: **Tree --> odom -->> base_link --> laser --> map**
>> current `updated` TF configuration: map-->odom-->base_link-->laser
> rqt_graph: [rqt graph
> picture](https://drive.google.com/file/d/1Q5SWaZAXKYHpMi4VTCKD22pr-TfieJ_Q/view?usp=sharing)
**Packages used:**
- Rplidar (for the lidar I have)
- motor_hat (for the motor control)
- robot_setup_tf (for publishing the tf information)
- robot_drive (for publishing commands for the motor_hat)
- differential_drive (for publishing odom, twist commands and the PID controller)
- move_base (costmaps)
- amcl (for localization)
- map_server (to publish the map)
**robot launch file:**
6000 8.0 0.294 0.294 75 148 0 -255 255 30 4 5 75 148 0 -255 255 30 4 5
#include
int main(int argc, char** argv)
{
ros::init(argc, argv, "robot_tf_publisher");
ros::NodeHandle n;
ros::Rate r(100);
tf::TransformBroadcaster broadcaster;
while(n.ok()){
//broadcaster.sendTransform(
//tf::StampedTransform(
//tf::Transform(tf::Quaternion(0, 0, 0, 1), tf::Vector3(0.0, 0.0, 0.0)),
//ros::Time::now(), "map", "odom"));
broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(tf::Quaternion(0, 0, 0, 1), tf::Vector3(0.0, 0.0, 0.2)),
ros::Time::now(),"base_link", "laser"));
r.sleep();
}
}
**Costmaps:**
base_local_planner_params.yaml:
TrajectoryPlannerROS:
max_vel_x: 0.45
min_vel_x: 0.1
max_vel_theta: 1.0
min_vel_theta: -1.0
min_in_place_vel_theta: 0.4
escape_vel: -0.1
acc_lim_theta: 3.2
acc_lim_x: 2.5
acc_lim_y: 2.5
holonomic_robot: false
yaw_goal_tolerance: 0.05
xy_goal_tolerance: 0.10
latch_xy_goal_tolerance: false
sim_time: 2
sim_granularity: 0.10
angular_sim_granularity: 0.10
vx_samples: 3
vtheta_samples: 20
meter_scoring: true
pdist_scale: 0.6
gdist_scale: 1.0
occdist_scale: 0.1
heading_lookahead: 0.325
heading_scoring: false
dwa: true
global_frame_id: odom
oscillation_reset_dist: 0.30
prune_plan: true
costmap_common_params.yaml:
footprint: [[-0.15,-0.15],[-0.15,0.15], [0.15, 0.15], [0.15,-0.15]]
obstacle_range: 2.0
raytrace_range: 2.5
inflation_radius: 0.3
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
global_costmap_params.yaml:
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 5.0
static_map: true
transform_tolerance: 0.5
local_costmap_params.yaml:
local_costmap:
global_frame: odom
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 2.0
static_map: false
rolling_window: true
width: 2.0
height: 2.0
resolution: 0.05
transform_tolerance: 0.5
**amcl configuration launch file:**
↧
↧
Why is the laser scan used my most robotic even when the point cloud is present
Hi,
I have been seeing that all most all the robots use the laser scan for the navigation instead of the point cloud data, is there any specific reason for the same.
The navigation package does support the sensor_msgs/LaserScan and sensor_msgs/PointCloud as the sensor source but always laser scan is used.
↧
Robot thinks that there is a possible collision
Hi there,
I have recently added move base for the navigation and I have two sensors for navigation, 2D lidar and ultrasonic sensor.
Here is my `common_costmap_params`:
obstacle_range : 2.5
raytrace_range : 3.0
#robot_radius: 0.3
footprint: [[0.3, 0.15], [0.3,-0.15], [-0.3, -0.15], [-0.3, 0.15]]
footprint_padding: 0.1
inflation_radius: 1.0
cost_scaling_factor: 3.0
My `local_costmap_params`:
local_costmap:
global_frame: odom
robot_base_frame: base_link
update_frequency: 10.0
publish_frequency: 10.0
transform_tolerance: 0.5
static_map: false
rolling_window: true # Follow robot while navigating
width: 3.0
height: 3.0
resolution: 0.2
plugins:
- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
#Configuration for the sensors that the costmap will use to update a map
sonar_layer:
topics: ["/sonar"]
no_readings_timeout: 1.0
obstacle_layer:
observation_sources: base_scan
base_scan: {data_type: LaserScan, sensor_frame: laser_link, topic: /laser, expected_update_rate: 0.4,
observation_persistence: 0.0, marking: true, clearing: true}
My `global_costmap_params`:
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 10.0
publish_frequency: 10.0
transform_tolerance: 0.5
static_map: true
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
#Configuration for the sensors that the costmap will use to update a map
sonar_layer:
topics: ["/sonar"]
no_readings_timeout: 1.0
obstacle_layer:
observation_sources: base_scan
base_scan: {data_type: LaserScan, sensor_frame: laser_link, topic: /laser, expected_update_rate: 0.4,
observation_persistence: 0.0, marking: true, clearing: true}
My `move_base_params`:
shutdown_costmaps: false
controller_frequency: 10.0
planner_patience: 5.0
controller_patience: 15.0
conservative_reset_dist: 3.0
planner_frequency: 5.0
oscillation_timeout: 10.0
oscillation_distance: 0.2
And finally my `dwa_local_planner_params` :
DWAPlannerROS:
# Robot Configuration Parameters
max_vel_x: 0.26
min_vel_x: -0.26
max_vel_y: 0.0
min_vel_y: 0.0
# The velocity when robot is moving in a straight line
max_trans_vel: 0.26
min_trans_vel: 0.13
max_rot_vel: 1.82
min_rot_vel: 0.9
acc_lim_x: 2.5
acc_lim_y: 0.0
acc_lim_theta: 3.2
# Goal Tolerance Parametes
xy_goal_tolerance: 0.05
yaw_goal_tolerance: 0.17
latch_xy_goal_tolerance: false
# Forward Simulation Parameters
sim_time: 2.0
vx_samples: 20
vy_samples: 0
vtheta_samples: 40
controller_frequency: 10.0
# Trajectory Scoring Parameters
path_distance_bias: 32.0
goal_distance_bias: 20.0
occdist_scale: 0.02
forward_point_distance: 0.325
stop_time_buffer: 0.2
scaling_speed: 0.25
max_scaling_factor: 0.2
# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05
# Debugging
publish_traj_pc : true
publish_cost_grid_pc: true
However, when I run ros and try to use navigation I get this strange error:
[ WARN] [1543259912.224847610, 33.540000000]: Rotate recovery behavior started.
[ERROR] [1543259912.225066653, 33.540000000]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ WARN] [1543259917.436186721, 38.740000000]: Clearing costmap to unstuck robot (1.840000m).
What am I doing wrong here?
↧
Robot moves straight and then rotates and also doesn't move in the map when i give it a 2D goal in Rviz
my robot moves straight and then start rotating 360 after giving it a 2d goal in rviz and also it doesn't update its position in the map and doesn't move in the map after giving it a 2d goal in rviz ,i don't know what kind of error is doing this ,everything is working exactly fine in my move_base. Kindly help me pleaseeeeeee. The only warning that appears in my terminal is
[ WARN] [1460044692.767036876]: Clearing costmap to unstuck robot (3.000000m).
[ WARN] [1460044693.167373773]: Rotate recovery behavior started.
↧