I have a mobile robot without wheel encoder. I have a 2D laser range finder. I want to run ROS navigation on this robot.
I notice that amcl can provide tf between `/map` and `/odom`. Because I have no wheel encoder, so that no `/odom` to `/base_link` tf can be provided.
Does ROS navigation stack need wheel encoder? How can I run the navigation stack on this robot?
↧
Does ROS navigation stack need wheel encoder?
↧
Error in amcl node while configuring navigation stack simulation
I have configured the navigation stack to a mobile robot model. When i tried to launch the below file got a following error. I am sure the error is with amcl node because i checked other nodes, launch file works fine without the amcl node.
↧
↧
Robot model orientation is improper with respect to map frame.
Robot model is not properly oriented (upside down) in rviz when "map" is selected as fixed frame. When the fixed frame is odom the robot model was perfectly aligned and oriented in rviz. How to bring the robot to same position as it was in odom frame.
Refer the result below
↧
Robot model not localizing in the map.
I have built a map of a world and launched my navigation launch file for self-navigation. My robot model cannot localize in the map and it keep on jumping inside the map with confusion.
I carried out test for laser and odometry, given in this tutorial and both are seems to be perfect. I can build a perfect map using slam_gmapping node but can't simulate the initial pose and goal in rviz, the model fails to localize.
How to tune the localization node for perfect results.
↧
Problem with navigation
Hello!
I am new to ROS, so please bear with me.
I am going through navigation tutorials of ROS listed [here](http://wiki.ros.org/husky_navigation/Tutorials/Husky%20AMCL%20Demo).
When I launch the amcl.demo file I get the following error continuously:
**[WARN] [1454762481.036046933, 3051.340000000]: Timed out waiting for transform from base_link to map to become available before running costmap, tf error: . canTransform returned after 0.1 timeout was 0.1.**
Due to this, the 2D pose Estimate and 2D nav goal don't work in Rviz. The Exploration, Static map, Global Costmap, Local Costmap show an error in Rviz.
Can anyone please help?
Thanks!
EDIT 1: Here is the summary of the terminal:
sri@Sri:~$ roslaunch husky_navigation amcl_demo.launch
... logging to /home/sri/.ros/log/99bc8912-cd81-11e5-9cc6-681729436688/roslaunch-Sri-16730.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://Sri:40227/
SUMMARY
========
PARAMETERS
* /amcl/gui_publish_rate: 10.0
* /amcl/kld_err: 0.05
* /amcl/kld_z: 0.99
* /amcl/laser_lambda_short: 0.1
* /amcl/laser_likelihood_max_dist: 2.0
* /amcl/laser_max_beams: 60
* /amcl/laser_max_range: 12.0
* /amcl/laser_model_type: likelihood_field
* /amcl/laser_sigma_hit: 0.2
* /amcl/laser_z_hit: 0.5
* /amcl/laser_z_max: 0.05
* /amcl/laser_z_rand: 0.5
* /amcl/laser_z_short: 0.05
* /amcl/max_particles: 2000
* /amcl/min_particles: 500
* /amcl/odom_alpha1: 0.2
* /amcl/odom_alpha2: 0.2
* /amcl/odom_alpha3: 0.2
* /amcl/odom_alpha4: 0.2
* /amcl/odom_alpha5: 0.1
* /amcl/odom_frame_id: odom
* /amcl/odom_model_type: diff
* /amcl/recovery_alpha_fast: 0.0
* /amcl/recovery_alpha_slow: 0.0
* /amcl/resample_interval: 1
* /amcl/transform_tolerance: 1.0
* /amcl/update_min_a: 0.2
* /amcl/update_min_d: 0.25
* /amcl/use_map_topic: True
* /move_base/DWAPlannerROS/acc_lim_th: 3.2
* /move_base/DWAPlannerROS/acc_lim_x: 2.5
* /move_base/DWAPlannerROS/acc_lim_y: 0
* /move_base/DWAPlannerROS/latch_xy_goal_tolerance: False
* /move_base/DWAPlannerROS/max_rot_vel: 1.0
* /move_base/DWAPlannerROS/max_trans_vel: 0.5
* /move_base/DWAPlannerROS/max_vel_x: 0.5
* /move_base/DWAPlannerROS/max_vel_y: 0
* /move_base/DWAPlannerROS/min_rot_vel: 0.2
* /move_base/DWAPlannerROS/min_trans_vel: 0.1
* /move_base/DWAPlannerROS/min_vel_x: 0.0
* /move_base/DWAPlannerROS/min_vel_y: 0
* /move_base/DWAPlannerROS/xy_goal_tolerance: 0.2
* /move_base/DWAPlannerROS/yaw_goal_tolerance: 0.1
* /move_base/NavfnROS/allow_unknown: True
* /move_base/NavfnROS/default_tolerance: 0.1
* /move_base/TrajectoryPlannerROS/acc_lim_theta: 3.2
* /move_base/TrajectoryPlannerROS/acc_lim_x: 2.5
* /move_base/TrajectoryPlannerROS/angular_sim_granularity: 0.02
* /move_base/TrajectoryPlannerROS/controller_frequency: 20.0
* /move_base/TrajectoryPlannerROS/dwa: True
* /move_base/TrajectoryPlannerROS/escape_reset_dist: 0.1
* /move_base/TrajectoryPlannerROS/escape_reset_theta: 0.1
* /move_base/TrajectoryPlannerROS/escape_vel: -0.1
* /move_base/TrajectoryPlannerROS/gdist_scale: 1.0
* /move_base/TrajectoryPlannerROS/heading_lookahead: 0.325
* /move_base/TrajectoryPlannerROS/heading_scoring: False
* /move_base/TrajectoryPlannerROS/heading_scoring_timestep: 0.8
* /move_base/TrajectoryPlannerROS/holonomic_robot: False
* /move_base/TrajectoryPlannerROS/latch_xy_goal_tolerance: False
* /move_base/TrajectoryPlannerROS/max_vel_theta: 1.0
* /move_base/TrajectoryPlannerROS/max_vel_x: 1.0
* /move_base/TrajectoryPlannerROS/meter_scoring: True
* /move_base/TrajectoryPlannerROS/min_in_place_vel_theta: 0.2
* /move_base/TrajectoryPlannerROS/min_vel_theta: -1.0
* /move_base/TrajectoryPlannerROS/min_vel_x: 0.0
* /move_base/TrajectoryPlannerROS/occdist_scale: 0.1
* /move_base/TrajectoryPlannerROS/oscillation_reset_dist: 0.25
* /move_base/TrajectoryPlannerROS/pdist_scale: 0.75
* /move_base/TrajectoryPlannerROS/publish_cost_grid_pc: True
* /move_base/TrajectoryPlannerROS/sim_granularity: 0.02
* /move_base/TrajectoryPlannerROS/sim_time: 2.0
* /move_base/TrajectoryPlannerROS/simple_attractor: False
* /move_base/TrajectoryPlannerROS/vtheta_samples: 20
* /move_base/TrajectoryPlannerROS/vx_samples: 6
* /move_base/TrajectoryPlannerROS/xy_goal_tolerance: 0.2
* /move_base/TrajectoryPlannerROS/yaw_goal_tolerance: 0.1
* /move_base/base_global_planner: navfn/NavfnROS
* /move_base/base_local_planner: dwa_local_planner...
* /move_base/controller_frequency: 5.0
* /move_base/global_costmap/footprint: [[-0.5, -0.33], [...
* /move_base/global_costmap/footprint_padding: 0.01
* /move_base/global_costmap/global_frame: map
* /move_base/global_costmap/inflation/inflation_radius: 1.0
* /move_base/global_costmap/obstacle_range: 5.5
* /move_base/global_costmap/obstacles_laser/laser/clearing: True
* /move_base/global_costmap/obstacles_laser/laser/data_type: LaserScan
* /move_base/global_costmap/obstacles_laser/laser/inf_is_valid: True
* /move_base/global_costmap/obstacles_laser/laser/marking: True
* /move_base/global_costmap/obstacles_laser/laser/topic: scan
* /move_base/global_costmap/obstacles_laser/observation_sources: laser
* /move_base/global_costmap/plugins: [{'type': 'costma...
* /move_base/global_costmap/publish_frequency: 3.0
* /move_base/global_costmap/raytrace_range: 6.0
* /move_base/global_costmap/resolution: 0.05
* /move_base/global_costmap/robot_base_frame: base_link
* /move_base/global_costmap/rolling_window: False
* /move_base/global_costmap/static/map_topic: /map
* /move_base/global_costmap/static/subscribe_to_updates: True
* /move_base/global_costmap/track_unknown_space: True
* /move_base/global_costmap/transform_tolerance: 0.5
* /move_base/global_costmap/update_frequency: 4.0
* /move_base/local_costmap/footprint: [[-0.5, -0.33], [...
* /move_base/local_costmap/footprint_padding: 0.01
* /move_base/local_costmap/global_frame: odom
* /move_base/local_costmap/height: 10.0
* /move_base/local_costmap/inflation/inflation_radius: 1.0
* /move_base/local_costmap/obstacle_range: 5.5
* /move_base/local_costmap/obstacles_laser/laser/clearing: True
* /move_base/local_costmap/obstacles_laser/laser/data_type: LaserScan
* /move_base/local_costmap/obstacles_laser/laser/inf_is_valid: True
* /move_base/local_costmap/obstacles_laser/laser/marking: True
* /move_base/local_costmap/obstacles_laser/laser/topic: scan
* /move_base/local_costmap/obstacles_laser/observation_sources: laser
* /move_base/local_costmap/plugins: [{'type': 'costma...
* /move_base/local_costmap/publish_frequency: 3.0
* /move_base/local_costmap/raytrace_range: 6.0
* /move_base/local_costmap/resolution: 0.05
* /move_base/local_costmap/robot_base_frame: base_link
* /move_base/local_costmap/rolling_window: True
* /move_base/local_costmap/static/map_topic: /map
* /move_base/local_costmap/static/subscribe_to_updates: True
* /move_base/local_costmap/transform_tolerance: 0.5
* /move_base/local_costmap/update_frequency: 4.0
* /move_base/local_costmap/width: 10.0
* /move_base/recovery_behaviour_enabled: True
* /rosdistro: indigo
* /rosversion: 1.11.16
NODES
/
amcl (amcl/amcl)
map_server (map_server/map_server)
move_base (move_base/move_base)
ROS_MASTER_URI=http://localhost:11311
core service [/rosout] found
process[map_server-1]: started with pid [16748]
process[amcl-2]: started with pid [16749]
process[move_base-3]: started with pid [16755]
[ WARN] [1454839265.612888152, 1338.590000000]: Timed out waiting for transform from base_link to map to become available before running costmap, tf error: . canTransform returned after 0.1 timeout was 0.1.
↧
↧
AMCL losting problem
hello... I work on AMCL. if I work in little area AMCL work very well. But if I work in corridor AMCL always is losting in the middle of corridor. My AMCL parameters are good so amcl pose estimation (pose arrays) doesnt spread. why it get lost always same area ??? problem is about **LIDAR MAX RANGE** or gound type ?
lidar hokuyo : 5.4 m max range
type of floor : tile
The length of the corridor :
[**VIDEO ABOUT PROBLEM :** ](https://www.youtube.com/watch?v=VFss-e_lgmQ&feature=youtu.be)
VIDEO INFO :
**video timing (03:08) : robot is actually in front of the first door, but amcl estimation is still in front of the first floor
video timing (04:07) : robot is actually in front of the third door, but amcl estimation is still in front of the second floor**
↧
Error in move_base while simulating navigation stack
When i launch the navigation launch file the robot fails to keep the plan and mess up in the middle, It throws the below warning and an error in Rviz (Ref image)> [ WARN] [1455133160.311617027, 27.096000000]: MessageFilter [target=map ]: Discarding message from [/move_base] due to empty frame_id. This message will only print once.>> [ WARN] [1455133160.311926656,> 27.096000000]: Invalid argument passed to canTransform argument source_frame> in tf2 frame_ids cannot be empty>> [ WARN] [1455133160.710917579,> 27.118000000]: Invalid argument passed to canTransform argument source_frame> in tf2 frame_ids cannot be empty
↧
Interface Pixhawk with hector_slam / AMCL
Hi everybody,
I am developing an autonomous indoor quadrotor. For the moment everything was simulated on Gazebo and worked well. Now I want to push everything on a real drone and make use of both a Pixhawk and the px4flow to get good low level control. These components were not included into the simulation.
My system relies on either hector_mapping or AMCL for the localization (depending on the situation I use on or the other...).
I am experimenting the connection between the px4 boards and ROS via Mavros. The topics are published but I don't really understand how to bridge mavros with my localization algorithms so that I can get an improved localization taking into account all the data available...
Here is my question! I guess I should use so Kalman filters to fuse all the information (optical flow from px4flow, IMU for Pixhawk, height for Pixhawk and 2D coordinates from localization - hector_slam or AMCL). Is there an available node for that? How do I need to use it?
Thanks for your help!
↧
amcl restore own position automatically
sometime AMCL can't localize itself in the given map while moving. such as in alike environments. In similar cases I use pose estimation button for real position of robot.
But is there a way to detect automatically that AMCL get lost real robot position ?
EXAMPLE: a node give me an error " ROBOT CAN'NOT LOCALIZE ITSELF" . after AMCL will try immediately localize right position. So, I dont use pose estimation button .
↧
↧
Robot doesn't Follow its path and particle cloud spreads out
Hi Everyone,
Has anyone had an experience with the robot following the path and going off it from time to time? It causes my robot to run into the walls and Im struggling with finding the solution to this problem. I should also mention that the robot doesn't see the obstacles and I don't know how to go out this.
Kind regards,
Maciej
With the reply to the comment I am posting all my config files below, if code is needed, this will be provided too.
Launch file:
↧
How do I get the pose estimated by AMCL at a fixed rate?
Hi everybody,
I'd like to know if there is a way to get the 2D pose estimates by AMCL at a fixed rate as is the case for the Hector SLAM in which the topic poseupdate provides the pose estimates at 40Hz with the Hokuyo UTM-30LX.
Thanks in advance!
↧
Wrong localization using AMCL and move_base
Hi all,
I am currently trying to set up the robot to navigate a known map using move_base. The global and local planners are set as follows:
↧
Nearest obstacle in Map
Let's say I have a robot in a Map. The robot it already knows the map and it knows its position (with amcl). Is there a way to extract from the information of the robot and the map the nearest obstacle in the map? To put it simple, let's see the figure below. The blue circle is the robot. I know all the map (black line). I want to know the distance and the angle of the orange dotted line that represents the closest obstacle. I should be able to know this information with the map and odometry topics. How can I do it?
Note: I'm pretty sure amcl guys did it somehow. But, it's there any simple way I can extract this info?
Note 2: I want to add multiple multiple objects in the scene and I would like to put some dynamics based on this distance. And of course this objects don't have lasers. As I said before, I should be able to do it only with the position of the object and the map.
↧
↧
AMCL parameters for localization
Hi all,
Please refer to my other question link:[here](http://answers.ros.org/question/227437/wrong-localization-using-amcl-and-move_base/)
What are the main parameters that should be adjusted to achieve better and consistent localization?
Thanks
↧
Costmap2DROS transform timeout
Hello ROS experts,
I am running a turtlebot with a Kobuki base and Asus Xtion Pro camera, without any dedicated laser range finder (on Ubuntu 14.04 using ROS Indigo).
When I run amcl everything runs fine and I am able to navigate using Rviz as well as my own code which uses move_base.
However, there is another node that runs, which subscribes to /camera/rgb/image_rect_color and uses the camera images to detect objects. As soon as this node starts running I start getting the below warning repeatedly:
> [ WARN] [1456505621.806228153]:> Costmap2DROS transform timeout.> Current time: 1456505621.8061,> global_pose stamp: 1456505620.1919,> tolerance: 0.5000 [ WARN]> [1456505621.806352967]: Could not get> robot pose, cancelling reconfiguration
After a couple of minutes, the robot is unable to navigate anywhere and all the move_base commands get aborted.
I checked the issue posted [here](http://answers.ros.org/question/215256/costmap2dros-transform-timeout/) and tried to increase the tolerance using
> rosparam set /amcl/transform_tolerance 5.0
The tolerance was set properly and I verified it using rosparam get.
. This helped for some time, but after that, the same problem reoccurred.
I checked the transform tree and saw that the frequency of map is 10000 Hz while frequency of base_link is around 5 Hz. This appears to be very strange, and it seems to me that this huge difference is somehow causing the transformation from map to base_link to fail.
Given below is a part of my tf transform tree (sorry I could not post an image since I do not have the required amount of points). The sequence is map->odom->base_footprint->base_link:
**map**
Broadcaster: /amcl
Average rate: 10000.000 Hz
Most recent transform: 1456505319.249 ( -0.752 sec old)
Buffer length: 0.000 sec
**odom**
Broadcaster: /mobile_base_nodelet_manager
Average rate: 50.556 Hz
Most recent transform: 1456505318.483 ( 0.014 sec old)
Buffer length: 4.905 sec
**base_footprint**
Broadcaster: /robot_state_publisher
Average rate: 5.208 Hz
Most recent transform: 1456505318.479 ( 0.018 sec old)
Buffer length: 4.800 sec
**base_link**
Broadcaster: /robot_state_publisher
Average rate: 5.208 Hz
Most recent transform: 1456505318.479 ( 0.018 sec old)
Buffer length: 4.800 sec
Any ideas or suggestions regarding possible solutions or pointers to what I may be doing wrong will be highly appreciated.
Best,
Sayantan
↧
Multiple robots simulation in Stage with amcl navigation
Hi,
I am trying to set two robots on the map and use amcl navigation for each of them. As a role model, I used [this question](http://answers.ros.org/question/41433/multiple-robots-simulation-and-navigation/) (it deals with the same situation in Gazebo).
After creating a .yaml and .world files with a map and two robots on it, I created a launch file that uses namespaces and tf_prefix.
The final list of topics is as expected.
The trouble is with frames: there is no /map frame, nor the link from it to robot_0/odom and robot_1/odom (the result of tf view_frames is [here](https://dl.dropboxusercontent.com/u/11955498/frames.pdf)). As far as I know, the responsibility for publishing that frame is on amcl but can't figure out why it fails to publish it.
(The warning received is: > Timed out waiting for transform from> robot_0/base_footprint to map to> become available before running> costmap, tf error: . canTransform> returned after 0.1 timeout was 0.1.
EDIT1: after adding fake_localization node, the map is connected, but it complains about robot_i/scan topic: when inspecting it with echo, there is nothing published there.
How could I fix it?
How to fix the situation without adding fake localization?
Please, help me with any hint on how frames actually work and why could it be that there is no /map frame and the connection to robot_i/odom.
The launch files are as below:
↧
Tuning AMCL's diff-corrected and omni-corrected odom models
I just read the discussion on `amcl`'s incorrect odometry models. See:
- [http://answers.ros.org/question/54467](http://answers.ros.org/question/54467/is-amcls-implementation-of-the-odometry-model-correct/)
- https://github.com/ros-planning/navigation/issues/20
I was wondering if anyone has figured out how to properly tune the parameters `odom_alpha1` through `odom_alpha5` (relative to the "incorrect" models). The consensus seems to be that the old defaults (`0.2`) don't work properly with the corrected models. I tried a few things, such as lowering them by an order of magnitude, but didn't get decent results.
PS. To be more specific, here's my experience with a made-up omni-drive robot in Stage (`drive "omni"`) and the `omni-corrected` odom model. If I tell the `DWAPlanner` to treat the robot as nonholonomic (`holonomic_robot: false`), then AMCL does OK. If I let it command lateral velocities (`holonomic_robot: true` and same `y` velocity params as `x` params), all hell breaks loose. Interestingly, it's mainly the position that's off, not the orientation.
Update #1: I found some numbers in this test config: https://github.com/ros-planning/navigation/blob/jade-devel/amcl/test/small_loop_crazy_driving_prg_corrected.xml If there's improvement, it's imperceptible to me.
↧
↧
How to set turtlebot to point to some orientation when it arrives?
**how to set the turtlebot point or not point to a specific orientation when it arrives the goal?**
I'm using rviz to set the goal for my mova_base for Turtlebot.
How to **configure the amcl files or something others** to make the turtlebot point or not point to the specific orientation when it arrives the goal.
Thanks!!
↧
A more risk taking move_base
I am using turtlebot gazebo simulation. I launched the turtlebot_world, demo_amcl and demo_gmapping launch files. I am sending goal positions to the turtlebot using a custom node that sends the turtlebot 1 metre forward. It is the most basic move_base client node that is found in tutorials available on the web.
The difficulty I find in using that is that less than 50 % of the time does it successfully send the turtlebot to the desired location. And it does that swirling on its axis trying to map its environment This happens whether I use the goal_position_node or the 2DNav Goal Tool in Rviz.
Is there a way to make the current move_base functionality better by a simple fine-tuning of parameters or there already exists a much more risk-taking alternative to move_base.
Otherwise would using a custom node which publishes to cmd_vel using laser_scan data be a better option.
↧
Integration of px4, px4flow with AMCL localization for quadrotor
Hi everybody,
Following previous questions ([1](http://answers.ros.org/question/226853/interface-pixhawk-with-hector_slam-amcl/?answer=226859#post-id-226859), [2](http://answers.ros.org/question/226878/mavros-publishes-odometry-without-gps/?comment=228524#post-id-228524)), I would like to ask you if this architecture looks smart and efficient. My goal is to perform autonomous indoor navigation for quadrotor based on AMCL localization. I have been facing some troubles to set up my tf tree and my different odometry and pose informations. The proposed solution is as follow:
**The TF tree:**
base_link -> base_stabilized: I use the IMU information returned by mavros in the [hector_imu_attitude_to_tf](https://github.com/tu-darmstadt-ros-pkg/hector_slam/tree/catkin/hector_imu_attitude_to_tf) node
base_stabilized -> base_footprint: I simply subscribe to the altitude topic of mavros and publish the z translation. I still have some reliability problems as the barometer is not really accurate. I might try to use the sonar height combined with the IMU information. To be continued
base_footprint -> odom: I use [robot_localization](http://wiki.ros.org/robot_localization). It is working in 2d mode. It combines the IMU and the optical flow. To use the [mavros_msgs/OpticalFlowRad](http://docs.ros.org/jade/api/mavros_msgs/html/msg/OpticalFlowRad.html) in robot_localization, I use make use of [optflow_odometry](https://github.com/lalten/tas/blob/master/tas_odometry/src/optflow_odometry.cpp). At the end of the day, robot_localization is also publishing my 2D odom.
odom -> map: I use another EKF, again [robot_localization](http://wiki.ros.org/robot_localization), to fuse my 2D odom with my SLAM position.
For the moment, everything looks good, except the base_stabilized -> base_footprint. This problem does not affect the system. Do you think my solution is a good one, compared to the use of a single mavros usage? Am I creating to much computing and processing requirements or maybe inducing errors?
↧