I was looking through some of the launch and node files and wasn't sure where to begin with adjusting turtlebots speed when executing a goal in amcl? I want the robot to move faster to Deliver samples from point to point. Also like to include that I am using hydro on 12.04. I am assuming the gmapping works differently than the teleop. Am I wrong? Any advice appreciated.
I have changing parameter values in base_local_planner_params.yaml and dwa_local_planner_params.yaml but i see nothing.
Thanks in Advances
↧
How to adjust speed of turtlebot in Gmapping autonomous navigation?
↧
Unable to launch [laser_filter-1]
i launch Laser_amcl_demo.launch and i get
----------
core service [/rosout] found
Unable to launch [laser_filter-1].
If it is a script, you may be missing a '#!' declaration at the top.
[laser_filter-1] killing on exit
sr1@sr1-ThinkPad-T430:~$
i Have look in the cpp and launch but still cannot solve.
Thanks in Advances
↧
↧
amcl first map only
I saw on the amcl wiki page a new param, first_map_only param was added. I'm unsure how to use it exactly.
It appears like amcl can take in a new map on run time and use it. However, I'm not able to find another package that allows me to do that. It would be nice if my robot would be roaming around in the first map, and as it drives around, it can receive a new map(which has been updated), and continue to move around.
So here is what I'm curious about.
1. What is the param, first_map_only, intended to be used for?
2. If it is designed to be used as I described, is there any existing packages that allow me to do that? Or what should I modify to do what I'm looking for?
Note: I have looked into using gmapping to do dynamic mapping, but think I don't think I'd be able to use the actionlib to move the robot around because the initial position change every time gmapping starts.
↧
How can I set up properly the navigation?
I have set up a simulation in gazebo:
1. I have designed a dae model created by google ScetchUp.
2. I have created map files (png, yaml) according to dae model.
3. A gazebo model is made base on dae model and a new word file.
4. I have modified the original launch file of turtlebot_gazebo.
During the simulation I have used the official turtlebot parameters.
Error symptom:
When I set a new navigation goal, the robot moving the correct direction but the arrows of the Particle Cloud (amcl) are spread out. They are divided into two main group. After some time the robot is positioned in the left side (wrong position) and right inside the wall.
In the console of amcl the next message can be read:
[ WARN] [1406140201.717257002, 385.382000000]: Clearing costmap to unstuck robot.
[ WARN] [1406140203.342920266, 386.387000000]: Rotate recovery behavior started.
[ WARN] [1406140205.090192188, 387.380000000]: Clearing costmap to unstuck robot.
[ WARN] [1406140206.671660821, 388.381000000]: Rotate recovery behavior started.
[ERROR] [1406140209.937260911, 390.285000000]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ WARN] [1406140210.081675518, 390.375000000]: The origin for the sensor at (3.39, -0.17, 0.30) is out of map bounds. So, the costmap cannot raytrace for it.
[ERROR] [1406140211.601161068, 391.287000000]: Aborting because a valid plan could not be found. Even after executing all recovery behaviors
***********************************************************************************************************************************
**The youtube video of the trial can be found here:**
youtu.be/Nhq9Bs-Jv0c
I have read that the cause of wrong navigation is the wrong odometry but in this case it is a simulated.
**How can I debug the details of navigation?
What is the problem?**
Important parameters (turtlebot defaults):
amcl: {base_frame_id: base_footprint, first_map_only: false, global_frame_id: map,
gui_publish_rate: 10.0, initial_cov_aa: 0.034312367268577004, initial_cov_xx: 0.1517505191628672,
initial_cov_yy: 0.5215769607475513, initial_pose_a: 3.0335755590078475, initial_pose_x: 2.808151913939129,
initial_pose_y: 2.8708867799177478, kld_err: 0.05, kld_z: 0.99, laser_lambda_short: 0.1,
laser_likelihood_max_dist: 2.0, laser_max_beams: 60, laser_max_range: 12.0, laser_min_range: -1.0,
laser_model_type: likelihood_field, laser_sigma_hit: 0.2, laser_z_hit: 0.5, laser_z_max: 0.05,
laser_z_rand: 0.5, laser_z_short: 0.05, max_particles: 2000, min_particles: 500,
odom_alpha1: 0.2, odom_alpha2: 0.2, odom_alpha3: 0.2, odom_alpha4: 0.2, odom_alpha5: 0.1,
odom_frame_id: odom, odom_model_type: diff, recovery_alpha_fast: 0.0, recovery_alpha_slow: 0.0,
resample_interval: 1, restore_defaults: false, save_pose_rate: 0.5, tf_broadcast: true,
transform_tolerance: 1.0, update_min_a: 0.2, update_min_d: 0.25, use_map_topic: false}
bumper2pointcloud: {pointcloud_radius: 0.24}
camera:
imager_rate: 2.0
rgb:
image_raw:
compressed: {format: jpeg, jpeg_quality: 80, png_level: 9}
compressedDepth: {depth_max: 10.0, depth_quantization: 100.0, png_level: 9}
theora: {keyframe_frequency: 64, optimize_for: 1, quality: 31, target_bitrate: 800000}
cmd_vel_mux: {yaml_cfg_file: /opt/ros/hydro/share/turtlebot_bringup/param/mux.yaml}
depthimage_to_laserscan: {output_frame_id: /camera_depth_frame, range_max: 10.0, range_min: 0.45,
scan_height: 10, scan_time: 0.033}
gazebo: {auto_disable_bodies: false, cfm: 0.0, contact_max_correcting_vel: 100.0,
contact_surface_layer: 0.001, erp: 0.2, gravity_x: 0.0, gravity_y: 0.0, gravity_z: -9.8,
max_contacts: 20, max_update_rate: 1000.0, sor_pgs_iters: 50, sor_pgs_precon_iters: 0,
sor_pgs_rms_error_tol: 0.0, sor_pgs_w: 1.3, time_step: 0.001}
move_base:
TrajectoryPlannerROS: {acc_lim_theta: 1.0, acc_lim_x: 0.5, acc_lim_y: 0.0, angular_sim_granularity: 0.025,
dwa: true, escape_reset_dist: 0.1, escape_reset_theta: 1.57079632679, escape_vel: -0.1,
gdist_scale: 0.8, heading_lookahead: 0.325, heading_scoring: false, heading_scoring_timestep: 0.1,
holonomic_robot: false, max_vel_theta: 1.0, max_vel_x: 0.3, max_vel_y: 0.0, meter_scoring: true,
min_in_place_vel_theta: 0.6, min_vel_theta: -1.0, min_vel_x: 0.1, min_vel_y: 0.0,
occdist_scale: 0.01, oscillation_reset_dist: 0.05, pdist_scale: 0.6, restore_defaults: false,
sim_granularity: 0.025, sim_time: 3.0, simple_attractor: false, vtheta_samples: 20,
vx_samples: 6, vy_samples: 0, xy_goal_tolerance: 0.15, y_vels: '-0.3,-0.1,0.1,-0.3',
yaw_goal_tolerance: 0.3}
aggressive_reset: {reset_distance: 1.84}
base_global_planner: navfn/NavfnROS
base_local_planner: base_local_planner/TrajectoryPlannerROS
clearing_rotation_allowed: true
conservative_reset: {reset_distance: 3.0}
conservative_reset_dist: 3.0
controller_frequency: 5.0
controller_patience: 3.0
global_costmap:
footprint: '[]'
footprint_padding: 0.01
global_frame: /map
height: 10
inflation_layer: {cost_scaling_factor: 10.0, enabled: true, inflation_radius: 0.5}
map_type: voxel
obstacle_layer:
bump: {clearing: false, data_type: PointCloud2, marking: true, max_obstacle_height: 0.15,
min_obstacle_height: 0.0, topic: mobile_base/sensors/bumper_pointcloud}
combination_method: 1
enabled: true
mark_threshold: 0
max_obstacle_height: 0.6
observation_sources: scan bump
obstacle_range: 2.5
origin_z: 0.0
publish_voxel_map: false
raytrace_range: 3.0
scan: {clearing: true, data_type: LaserScan, marking: true, max_obstacle_height: 0.35,
min_obstacle_height: 0.25, topic: scan}
unknown_threshold: 15
z_resolution: 0.2
z_voxels: 2
obstacle_layer_footprint: {enabled: true}
origin_x: 0.0
origin_y: 0.0
plugins:
- {name: static_layer, type: 'costmap_2d::StaticLayer'}
- {name: obstacle_layer, type: 'costmap_2d::VoxelLayer'}
- {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
publish_frequency: 0.5
resolution: 0.05
robot_base_frame: /base_footprint
robot_radius: 0.18
static_layer: {enabled: true}
static_map: true
transform_tolerance: 0.5
update_frequency: 1.0
width: 10
local_costmap:
footprint: '[]'
footprint_padding: 0.01
global_frame: /map
height: 4
inflation_layer: {cost_scaling_factor: 10.0, enabled: true, inflation_radius: 0.5}
map_type: voxel
obstacle_layer:
bump: {clearing: false, data_type: PointCloud2, marking: true, max_obstacle_height: 0.15,
min_obstacle_height: 0.0, topic: mobile_base/sensors/bumper_pointcloud}
combination_method: 1
enabled: true
mark_threshold: 0
max_obstacle_height: 0.6
observation_sources: scan bump
obstacle_range: 2.5
origin_z: 0.0
publish_voxel_map: false
raytrace_range: 3.0
scan: {clearing: true, data_type: LaserScan, marking: true, max_obstacle_height: 0.35,
min_obstacle_height: 0.25, topic: scan}
unknown_threshold: 15
z_resolution: 0.2
z_voxels: 2
obstacle_layer_footprint: {enabled: true}
origin_x: 0.0
origin_y: 0.0
plugins:
- {name: obstacle_layer, type: 'costmap_2d::VoxelLayer'}
- {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
publish_frequency: 2.0
resolution: 0.05
robot_base_frame: /base_footprint
robot_radius: 0.18
rolling_window: true
static_map: false
transform_tolerance: 0.5
update_frequency: 5.0
width: 4
oscillation_distance: 0.2
oscillation_timeout: 10.0
planner_frequency: 1.0
planner_patience: 5.0
recovery_behavior_enabled: true
restore_defaults: false
shutdown_costmaps: false
navigation_velocity_smoother: {accel_lim_v: 0.6, accel_lim_w: 5.4, decel_factor: 1.0,
frequency: 20.0, robot_feedback: 2, speed_lim_v: 0.8, speed_lim_w: 5.4}
↧
problem publishing tf map->base_link
Hi
I wrote my own localization and I figured out hat amcl is publishing map->odom and not map->base_link.
Which is strange but on the end I had to do the same by computing first the difference to publish map->odom->base_link.
Can anyone help my out to clarify this situation.
Thanks
↧
↧
cannot launch node in hydro
When i launch move_base.launch, I got this :
ERROR: cannot launch node of type [tf/static_transform_publisher]: can't locate node [static_transform_publisher] in package [tf]
ERROR: cannot launch node of type [amcl/amcl]: can't locate node [amcl] in package [amcl]
However I already have done : `sudo apt-get install ros-hydro-amcl` and `sudo apt-get install ros-hydro-tf`
↧
Improve gmapping results
Hey everyone
I am working with the ROS Navigation stack using a simulated environment in Stage. Initially I would have created a topic criticizing the precision of the AMCL localization stack, but after deeper research I found the error to occur from the map I have created with the GMapping.
The following image shows the comparison between the ideal image (blue) and the resulting map from GMapping (red). Interesting enough the data fed into the GMapping process are all ideal, no error in either the odometry or the laser scans.
Besides setting the number of particles to 150 I use the standard settings when executing the GMapping process. Actually I have tried to reduce the update frequency in the translation and angular rotation, but it did not change alot.  I have also tried to visualize quite primitively how I have traveled through the area. The black dot is the start and the numbers shows the order in which the different areas have been explored.  Does anyone have any idea to how to improve the result of the GMapping process? So far it does not seem that impressive.
Regards
Sebastian Aslund
P.s my laser scanner is modeled to a SICK LMS200 with a range at 8m.
P.p.s Maybe it was an idea to show the results between a higher update frequency. The red figure shows the map with the standard update intervals. In the blue map the linear update is set to 0.2 and the angular update is set to 0.1. 
The following image shows the comparison between the ideal image (blue) and the resulting map from GMapping (red). Interesting enough the data fed into the GMapping process are all ideal, no error in either the odometry or the laser scans.
Besides setting the number of particles to 150 I use the standard settings when executing the GMapping process. Actually I have tried to reduce the update frequency in the translation and angular rotation, but it did not change alot.  I have also tried to visualize quite primitively how I have traveled through the area. The black dot is the start and the numbers shows the order in which the different areas have been explored.  Does anyone have any idea to how to improve the result of the GMapping process? So far it does not seem that impressive.
Regards
Sebastian Aslund
P.s my laser scanner is modeled to a SICK LMS200 with a range at 8m.
P.p.s Maybe it was an idea to show the results between a higher update frequency. The red figure shows the map with the standard update intervals. In the blue map the linear update is set to 0.2 and the angular update is set to 0.1. 
↧
dual laser source for navigation
hi, All,
I am using an LMS100 for localization and one hokuyo URG laser for local path planing.
question is, how do I specify which one goes where?
I am using Navigational Stack and in the costmap_common_params.yaml, following parameters are set
observation_sources: laser_scan_sensor point_cloud_sensor
laser_scan_sensor: {sensor_frame: base_laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
point_cloud_sensor: {sensor_frame: base_laser, data_type: PointCloud, topic: point_cloud, marking: true, clearing: true}
how do I specify which one is for AMCL which one is for local path plan?
regards
Ray
↧
Depth image on amcl_demo
Hi!
I'm having some trouble while trying to access the kinect depth image using amcl_demo.
When i run `roslaunch openni_launch openni.launch` it works well, and i can access/see topic `/camera/depth/image`.
The problem is when i run `roslaunch turtlebot_navigation amcl_demo map_file:=/..`. It starts all the nodes from the camera (the topic is there as well) but i can't see the depth image from the same topic before. I think i need to enable something but don't know what to do.
Hope you can help.
Thank you!
↧
↧
Navigation Stack, AMCL or EKF
According to ROS wiki:
"[amcl](http://wiki.ros.org/amcl?distro=indigo) takes in a laser-based map, laser scans, and transform messages, and outputs pose estimates."
"[The Robot Pose EKF](http://wiki.ros.org/robot_pose_ekf?distro=indigo) package is used to estimate the 3D pose of a robot, based on (partial) pose measurements coming from different sources. It uses an extended Kalman filter with a 6D model (3D position and 3D orientation) to combine measurements from wheel odometry, IMU sensor and visual odometry."
What I understand from the descriptions of these two localization algorithms is that amcl only works with laser data and ekf works only with odometry sources (wheel encoder, IMU, visual odometry). Is this a correct interpretation?
and how can I switch between amcl and ekf in the navigation stack?
Thanks
↧
Global Costmap only publishing once to a subscriber?
Hello.
I'm using the amcl_demo.launch file to localize to a static map, and gather costmap data of the environment. When I try to subscribe to the global_costmap/costmap topic, it only publishes once, and will not update the value. The same effect is seen when using rostopic echo. Rviz can update the global costmap display, so I don't know what the issue is. Thanks.
↧
amcl publish frequency map-> odom
Hello! in my tf tree I have that between /map and /odom there's amcl that publish at 20Hz. How to increase this speed rate?
↧
State Estimation and Localization in Robot Navigation
Hello,
I would like to ask the difference between a state estimator like `robot_localization`, or `robot_pose_ekf` and a localization package like `amcl`.
Can we say, a state estimator estimating (x, y, z, roll, pitch, yaw, and their respective velocities) is more general
than a localization module which only estimates (x, y, z, roll, pitch, yaw)
Other than the fact that, `robot_localization`, or `robot_pose_ekf` are fusing odometry data from different sensors and amcl is using this data plus laser/camera data to localize the robot, and (x, y, z) in state estimators are relative to the initial position and global (relative to the map) in `amcl`
Thanks
↧
↧
amcl odom dynamic obstacles
Hello everybody! I have a problem: I'm running amcl and navigation stack on husky in a empty room. If I add some obstacles in the room the global costmap will update but unfortunately the odom frame will have a wrong position. Can somebody help me please? I'm using hydro on ubuntu 12.04lts
↧
Extrapolation Error and AMCL
Its my first time trying to get the navigation stack up and running. After fiddling with the .yaml files, I've gotten it to move with RVIZ. There are some issues I'm running into.
The robot is having issues localizing. My set up follows the http://wiki.ros.org/navigation/Tutorials/RobotSetup tutorials, but only have a laser scanner as an input.
Here's the error generated by move_base.launch.
[ERROR] [1385945596.417775629]: Extrapolation Error: Lookup would require extrapolation into the future. Requested time 1385945596.400712013 but the latest data is at time 1385945596.309387000, when looking up transform from frame [odom] to frame [map]
[ERROR] [1385945596.417830096]: Global Frame: odom Plan Frame size 305: map
[ WARN] [1385945596.417853423]: Could not transform the global plan to the frame of the controller
After reading up on some other posts on answers.ros, to see what could be the problem, I took a look at my transforms, and I don't think thats it.
Here is the tf_monitor report.
RESULTS: for all Frames
Frames:
Frame: /base published by /base_ctrl_odom Average Delay: 0.000454951 Max Delay: 0.000718333
Frame: body published by /robot_state_publisher Average Delay: -0.499598 Max Delay: 0
Frame: bracket published by /robot_state_publisher Average Delay: 0.000529436 Max Delay: 0.000995636
Frame: bracket_90 published by /robot_state_publisher Average Delay: -0.499596 Max Delay: 0
Frame: hokuyo published by /robot_state_publisher Average Delay: -0.499597 Max Delay: 0
Frame: hokuyo_90 published by /robot_state_publisher Average Delay: -0.499597 Max Delay: 0
Frame: left_wheel published by /robot_state_publisher Average Delay: 0.000526063 Max Delay: 0.000993213
Frame: odom published by /amcl Average Delay: 0.0103003 Max Delay: 0.0867516
Frame: right_wheel published by /robot_state_publisher Average Delay: 0.000528483 Max Delay: 0.000995021
Frame: servo published by /robot_state_publisher Average Delay: -0.4996 Max Delay: 0
All Broadcasters:
Node: /amcl 41.432 Hz, Average Delay: 0.0103003 Max Delay: 0.0867516
Node: /base_ctrl_odom 5.82941 Hz, Average Delay: 0.000454951 Max Delay: 0.000718333
Node: /robot_state_publisher 60.1176 Hz, Average Delay: -0.420926 Max Delay: 0.000994623
I also ran
>rosrun tf tf_echo odom map
But there wasn't anything that threw a red flag at me.
There were three of those errors thrown when I was running the navigation stack. The room I'm using was fairly large. I used rviz to set an initialpose. After I did that, sending a it a goal didn't go too well. It moved a lot farther than it was suppose to, and I had to shut it off before it had a chance to try to complete the path. It also did a lot of extra rotating even though it was sent a straight path.
What additional information would be helpful to debug this issue? I'm not too sure where to look myself.
Thank you!
_______________________________________________________________________________________
Edit:
After reducing the size of the local cost map back down to the original size of 6x6 @ 0.5 resolution, the extrapolatoin error went away.
There weren't any grid cells with obstacles/inflated obstacles, but I took a look at the local cost map.
http://i.imgur.com/2chPFoC.png
It looks like that is the issue and it encloses itself off in a circle. So it tries to inch forward a little, but mostly spins in a circle.
I'm unsure if it's the laser scanner. It's frame_id is correctly on the urdf and is linked to the base of the robot.
_______________________________________________________________________________________
Edit2:
One of the problems was with the AMCL/odometry.
The 'anti-clockwise' really threw me off. I had to adjust the dead reckoning formula a bit. So now with a remote control, AMCL localizes for me very well! I have about a 2-5 degree error with the odometry, but it was all corrected
Although, running the navigation stack still have issues. Instead of the image above, the local costmap creates something more like a sharp wall.
↧
AMCL odometry and drift question
I'm using AMCL and it does a good job of estimating my position and accounting for drift, looking at the particles cloud. The odometry is periodically updated from AMCL but then reverts back to the drifted solution. Am I supposed to subscribe to amcl_pose and update my odometry node? or something else?
↧
nav2d autonomous multi robot exploration
Hi everyone,
I started using the [nav2d](http://wiki.ros.org/nav2d) package and did the four [tutorials](http://wiki.ros.org/nav2d/Tutorials) with success.
In the [3rd tutorial](http://wiki.ros.org/nav2d/Tutorials/MultiMapper) you can make a robot autonomously explore an unknown map.
In the [4th](http://wiki.ros.org/nav2d/Tutorials/DistributedMapping), you can move two robots via joystick, exploring a map and have one robot localize itself via [amcl](http://wiki.ros.org/amcl).
What I'm trying to achieve is a sort of "mix" between the two tutorials, that is having **two robots autonomously exploring and building** the map while having **one of them localizing itself**.
I'm struggling on the rqt_graph and launch files, trying to understand how to make stuff work, but without results until now (I'm pretty new to ROS and don't know how the nav2d package elements work in detail). Can someone help figure out how to achieve this goal?
Thank you very much for your kind help,
Regards.
↧
↧
Navigation, AMCL, amcl_pose
Hello,
I'm debugging the navigation stack set up on my robot. My question is about `amcl_pose`. This topic is published by `amcl` (or `fake_localization`), and in my robot `amcl_pose` is being published to by the localization module too, but no topic is subscribed to `amcl_pose`.
As I understand, local planner should use `amcl_pose` and I'm using [DWAPlannerROS](http://wiki.ros.org/dwa_local_planner#DWAPlannerROS) in the navigation stack, and `DWAPlannerROS` is only subscribed to `odom`.
So, the question is which component is using the result of the localization module.
**UPDATE 1:** Another suspicious thing with `amcl` (or `fake_localization`) is, although it is publishing to `/particlecloud`, but I can not visualize the particles in `Rviz` using `/particlecloud` topic. Nothing appears in `Rviz`.
Thanks
↧
AMCL error: Couldn't determine robot's pose associated with laser scan
Hi all,
I'm having a problem with AMCL in groovy, giving constantily the error "Couldn't determine robot's pose associated with laser scan".
It also is giving repeatedly a warning:
[ WARN] [1411296723.445692688]: Failed to compute odom pose, skipping scan (Unable to lookup transform, cache is empty, when looking up transform from frame [/base_footprint] to frame [/odom])
and I get this warning when using topic `/initpose`:
[ WARN] [1411296739.805780034]: Failed to transform initial pose in time (Lookup would require extrapolation into the future. Requested time 1411296739.805698007 but the latest data is at time 1411296739.737616394, when looking up transform from frame [/map] to frame [/base_footprint])
[ INFO] [1411296739.805813654]: Setting pose (1411296739.805799): -0.032 0.007 0.052
AMCL is feed with the laser scans from two different sources, that are merged in a single topic using the *relay* from topic_tools. When fusing topics, their frame_id is not changed. Laser scan topics come from a first computer, while navigation stack runs in a diferent computer, but both are time synchronised with chrony.
The point is, even if I'm constantly getting the error message, the localization seems to be working pretty good.
The TF tree seems good (I would attach the output from `rosrun tf view_frames` but I can't yet attach files) and laser scans are visualized correctly in rviz in all fixed frames (map, odom, base_link...). However, after a second watch I see that odom tf is published at only 10Hz, while the lasers are published at a rate of 25Hz (possible cause?)
Altough localization seems to work, getting the error means that there is something around there that is not working properly, but I'm unable to identify the source of the error. I'm afraid also that it can be the source of other apparently unrelated problems (i.e. the second warning shown, that causes that when setting /initpose, sometimes AMCL is not getting the sent position correctly).
Any ideas of what can be causing this AMCL error?
Thank you and best regards,
Ivan.
**Edit 1:** Added some warnings that I'm also getting. Plus something I noticed about the publication frecuency of the different TFs.
↧
amcl not publishing map -> odom
After trying to simulate turtlebot navigation on STDR instead of Stage, I always run into missing transforms problems and navigation cant start. I ran view_frames and put a link to the resulting pdf.
[pdf file of TF tree](http://www.pdf-archive.com/2014/09/25/frames/)
The particularity of STDR is that it is publishing its own map and doesnt need map_server (from what I could understand). I also had to manually add some transforms to avoid a lot of remapping,
> odom -> base_footprint which is just a> copy of map_static -> robot0
and
> base_link -> base_laser_link which is> a copy of robot0 -> robot0_laser_0
When I run everything, I get the following error:
> Waiting on transform from> base_footprint to map to become> available before running costmap, tf> error: Could not find a connection> between 'map' and 'base_footprint'> because they are not part of the same> tree.Tf has two or more unconnected> trees.
As you can see in the pdf map is also supposed to be connected to odom, which is actually the task of AMCL. But in my case it is not. And i couldnt find out the source of the problem.
I would be very thankful for your help.
↧