I am sorry for my poor English.
I am a beginner at ROS and ROS navigation stack. I would like to know what `double MoveBase::distance(const geometry_msgs::PoseStamped& p1, const geometry_msgs::PoseStamped& p2)` means , which is a function in move_base.cpp. Does it mean the distance from a present point to a goal point?
In addition, I would also like to know the meaning of `geometry_msgs::PoseStamped`. Is it a self position?
I would appreciate it if you could answer my question.
Thank you.
↧
What is the meaning of MoveBase::distance ?
↧
The simplest way to explore the environment to find a target and return to base
What is the simplest way to autonomously explore the environment in a room avoiding obstacles, find a target (based on vision) and return at the original starting position? Detecting the target using vision is not necessary part of the question but I included it to explain the overall scope of the project.
I have a working differential drive robot with a LIDAR sensor and a camera, so the question refers more to what is the best / simplest navigation stack I can use?
I am going thru Navigation Stack tutorials but there are many options and I was hoping to get some practical advice
Are there any good examples in python?
↧
↧
how to subscribe bumper data on move_base?
I am a beginner at ROS and ROS navigation stack.
I have been using `roomba_500_series` and navigation stack (including `move_base` module). I would like to subscribe `/bumper` topic in move_base. The topic type of /bumper is `roomba_500_series/Bumper`. I can already use bumper data by using `kobuki_bumper2pc`. However I want to use the data in `move_base` one way or another.
First of all, I would like to try to turn rommba left when the right bumper is true after publishing /cmd_vel. I modified `move_base.cpp` like below.
`move_base.cpp` (line: 902~) [link text](https://github.com/ros-planning/navigation/blob/e538b4f4624c7f757d4868e5200ba8f8904a0d94/move_base/src/move_base.cpp#L902)
//make sure that we send the velocity command to the base
vel_pub_.publish(cmd_vel);
//***modified part
bump_sensor_sub_ = nh.subscribe("/bumper", 1000, &MoveBase::BumperSensorCB, this);
if (right_bumper==1){
publishZeroVelocity();
while(right_bumper==1){
cmd_vel.linear.x = 0.0;
cmd_vel.linear.y = 0.0;
cmd_vel.angular.z = 0.78;
vel_pub_.publish(cmd_vel);
bump_sensor_sub_ = nh.subscribe("/bumper", 1000, &MoveBase::BumperSensorCB, this);
}
} //***
function `MoveBase::BumperSensorCB` which I made
void MoveBase::BumperSensorCB(const roomba_500_series::Bumper::ConstPtr& msg)
{
left_bumper = msg->left.state;
right_bumper = msg->right.state;
}
`right_bumper` & `left_bumper` are boolean data type
bool right_bumper, left_bumper;
I modified move_base.cpp as noted above. However roomba doesn't work as I thought. It seems like `MoveBase` can't subscribe `/bumper` topic now. Although, the cause might be `CMakeLists.txt` , I have no idea how to modify it to use `/bumper` topic from `roomba_500_series`.
Sorry that was such a long post and my poor English.
I would appreciate it if you could answer my question.
Thank you.
↧
local path wont follow global path ROS
Hello everyone,
last week i managed to localize my robot in my self created map.
After localization im trying to use move base and the navigation stack.
At the moment my robot can compute a global map path but the local path
is very noisy and is not following the global path.
My setup:
4 Wheel drive robot
Im publishing /map with mapserver
im using laser_scan_matcher and amcl for map->odom->base_footprint->baselink->laser (rplidar)
In addition im trying to use an Imu. My Arduino programm publishes Imu/data_raw & with imu filter Imu/data
I took the Pose information from /amcl/pose topic and the linear_acceleration.x/y and angular.z from Imu and
publish them together to /odom topic.
So my /odom takes information from:
pose = amcl/pose
twist = Imu/data
With my described setup my local path is appearing and dissapearing over time and it isnt following my global path which is pretty fine.
Thank you!
↧
Local Costmap of move_base Package Does not Refresh when the Robot is Stationary.
Hi,
I am encountering the issue that my local cost map does not refresh when the robot is stationary. This would create significant problems when there are moving obstacles around the robot. You can observe the behaviour here at 0:22
[Local_costmap_issue](https://youtu.be/sHPK6NG8IzQ)
Here is how I launch my move_base node in my robot launch file:
↧
↧
moveIt! for differential drive mobile robots
Hi everyone!
I'm currently looking for a motion planner for implementing 2D and 3D navigation for a differential drive mobile robot.
As far as I read from this forum, the `moveIt!` google group and internet in general, it should be possible to implement navigation with `moveIt!`.
The task for the robot is navigation in a 2D or 3D indoor environment (probably with ramps, slopes, etc...) with only few obstacles. There could be also some moving obstacles (e.g. people). In particular, the robot should follow a bustrophedic path.
My questions are:
- Did someone succed in setting up moveit for a differential drive robot?
- Is there a clear example, excluding the standard `moveit_setup_assistant` example and other tutorials on the `moveIt!` website, which are clearly for manipulators, for a differential drive robot setup in `moveIt!`?
- Is there any advantage in using `moveIt!` instead of the good-old `move_base` for this task?
↧
Possible to have local costmap aligned with base link?
I am wondering if there is an option to have the local costmap aligned with your robot?
My point is that if you have a car-like robot which moves mostly forward and cant turn in place, most of the space in a local costmap is useless.
So I would reduce the length of the costmap behind the robot and also the width but would increase the length in front of the robot.
Is there already such an option from which I am not aware?
↧
Navigation Stack without SLAM or AMCL
Hello,
is it possible to use the ROS Navigation Stack without SLAM and AMCL. These are probabilistic localization methods but we use a motion capture system which provides us with a very accurate pose via /tf. Robot has no sensors at all (e.g. Laserscanner). I supply a static map of the environment. The global planner works without a problem. But the local planner (robot) never stays on path or reach its goal, no matter if I use base_local_planner, dwa_local_planner or teb_local_planner. Also I am not sure if nav_msgs/Odometry is necessary at all or if move_base can collect the pose from /tf. Motion Capture System only provides pose no speed data. Is it necessary to provide although actual position is always updated and exact.
Maybe someone has a suggestion how to setup correct or what's missing for the local planners.
↧
move_base problem: i ran move_base node to accept the /scan topic from rplidar node, but the move_base node wants the /CloudPoint type rather than /LaserScan type.
the error info is shown below:
Client [/move_base] wants topic /scan to have datatype/md5sum [sensor_msgs/PointCloud/...], but our version has [sensor_msgs/LaserScan/...].Dropping Connection.
I think i have configured the observation_source in the costmap_common_params.yaml file as below, but it still shows that move_base node wants the PointCloud type of topic /scan. The topic /scan is published as LaserScan type.
Does anyone have ideas on this problem? with great thanks.
obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[-0.16,0],[0,0.16],[0.16,0]]
robot_radius:ir_of_robot
inflation_radius: 0.55
observation_sources: scan
scan: {datatype: LaserScan, topic: /scan, marking: true, clearing: true, expected_update_rate: 0}
and the other config file for move_base is shown as below:
global_costmap_params.yaml
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 5.0
static_map: false
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: 6.0
width: 6.0
resolution: 0.05
base_local_planner_params.yaml
TrajectoryPlannerROS:
max_vel_x: 0.45
min_vel_x: 0.1
max_vel_theta: 1.0
min_in_place_vel_theta: 0.4
acc_lim_theta: 3.2
acc_lim_x: 2.5
acc_lim_y: 2.5
holonomic_robot: false
↧
↧
Move_base: replanning issue
Hello:
I'm trying to configure move_base with my mobile robot platform and i am facing a serious issue. I am using ROS Hydro and navigation stack 1.11.15
I have configured the navigation package to follow the generated path as close as possible and when an unexpected obstacle appears in the path from outside the local window, the navfn and global_path is replanned and everything works OK. But if the obstacle appear near the robot (where the global path is already planned) it is not able to replan and approaches the obstacle until the robot stop.
If I configure the global planner to replan at a certain ratio, it is able to replan avoiding the obstacle, but this is not the behaviour (periodic planning) we want in the real application, only replanning when the path is blocked.
My configuration files are as following:
Base local planner params:
base_global_planner: navfn/NavfnROS
base_local_planner: base_local_planner/TrajectoryPlannerROS
recovery_behaviors: [{name: conservative_reset, type: clear_costmap_recovery/ClearCostmapRecovery}, {name: rotate_recovery, type: rotate_recovery/RotateRecovery}, {name: aggressive_reset, type: clear_costmap_recovery/ClearCostmapRecovery}]
controller_frequency: 10.0
planner_patience: 3.0
controller_patience: 5.0
conservative_reset_dist: 3.0
recovery_behavior_enabled: true
clearing_rotation_allowed: true
shutdown_costmaps: false
oscillation_timeout: 0.0
oscillation_distance: 0.5
planner_frequency: 0.0
global_frame_id: map_navigation
TrajectoryPlannerROS:
acc_lim_x: 0.4
acc_lim_y: 0.4
acc_lim_theta: 0.8
max_vel_x: 0.2
min_vel_x: 0.1
max_trans_vel: 0.2
min_trans_vel: 0.1
max_rotational_vel: 0.6
max_vel_theta: 0.6
min_vel_theta: -0.6
min_in_place_vel_theta: 0.3
escape_vel: 0.0
holonomic_robot: false
y_vels: []
xy_goal_tolerance: 0.5
yaw_goal_tolerance: 0.3
latch_xy_goal_tolerance: true
sim_time: 1.0
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 3
vtheta_samples: 20
controller_frequency: 10
public_cost_grid_pc: true
meter_scoring: true
#DWA
heading_scoring: false
dwa: false
forward_point_distance: 0.325
path_distance_bias: 32
goal_distance_bias: 24
#TRAJECTORY PLANNER
pdist_scale: 0.9
gdist_scale: 0.8
occdist_scale: 0.01
heading_lookahead: 0.325
publish_cost_grid_pc: false
global_frame_id: map_navigation
oscillation_reset_dist: 0.05
prune_plan: true
NavfnROS:
allow_unknown: false
planner_window_x: 0.0
planner_window_y: 0.0
default_tolerance: 0.0
visualize_potential: false
Local costmap params:
local_costmap:
# Coordinate frame and TF parameters
global_frame: map_navigation
robot_base_frame: base_link
transform_tolerance: 1.0
# Rate parameters
update_frequency: 2.0
publish_frequency: 2.0
#Map management parameters
rolling_window: true
width: 8.0
height: 8.0
resolution: 0.05
origin_x: 0.0
origin_y: 0.0
static_map: false
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: hokuyo/scan, marking: true, clearing: true, observation_persistence: 0.0, expected_update_rate: 0.0, max_obstacle_height: 2.0, min_obstacle_height: -2.0, obstacle_range: 4.0, raytrace_range: 5.0, inf_is_valid: false}
max_obstacle_height: 2.0
obstacle_range: 4.0
raytrace_range: 5.0
track_unknown_space: false
inflation_layer:
inflation_radius: 5.52
cost_scaling_factor: 2.0
plugins:
-
name: obstacle_layer
type: "costmap_2d::ObstacleLayer"
-
name: inflation_layer
type: "costmap_2d::InflationLayer"
Global costmap params:
global_costmap:
# Coordinate frame and TF parameters
global_frame: map_navigation
robot_base_frame: base_link
transform_tolerance: 1.0
# Rate parameters
update_frequency: 5.0
publish_frequency: 2.0
#Map management parameters
rolling_window: false
resolution: 0.05
static_map: true
#Static Layer
static_layer:
unknown_cost_value: -1
lethal_cost_threshold: 100
map_topic: map_navigation
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: hokuyo/scan, marking: true, clearing: true, observation_persistence: 0.0, expected_update_rate: 0.0, max_obstacle_height: 2.0, min_obstacle_height: -2.0, obstacle_range: 4.0, raytrace_range: 5.0, inf_is_valid: false}
max_obstacle_height: 2.0
obstacle_range: 4.0
raytrace_range: 5.0
track_unknown_space: false
inflation_layer:
inflation_radius: 5.52
cost_scaling_factor: 2.0
plugins:
- name: static_layer
type: "costmap_2d::StaticLayer"
-
name: obstacle_layer
type: "costmap_2d::ObstacleLayer"
-
name: inflation_layer
type: "costmap_2d::InflationLayer"
Thank you in advance for any idea about how to solve it.
↧
Navigation using move_base with RGBDSLAMv2 instead of a known map
Hey, everyone,
I met some trouble while trying to use **move_base** package to control my car. But the tutorials of the **move_base** package is using a known map. I think the **move_base** package can work using rgbdslamv2 instead of a known map. But I don't know how to do to connect them together. Since the source from google is mostly on laser scan, so i hope i can get some help from you. Thank you very much!
Here is my config files:
base_local_planner_params.yaml
enter cTrajectoryPlannerROS:
max_vel_x: 0.45
min_vel_x: 0.1
max_vel_theta: 1.0
min_in_place_vel_theta: 0.4
acc_lim_theta: 3.2
acc_lim_x: 2.5
acc_lim_y: 2.5
holonomic_robot: true
costmap_common_params.yaml
obstacle_range: 2.0
raytrace_range: 3.0
#footprint: [[0, 0]]
robot_radius: 0.09
inflation_radius: 0.20
observation_sources: point_cloud_sensor
point_cloud_sensor: {sensor_frame: base_camera, data_type: PointCloud, topic: camera/depth_registered/points, marking: true, clearing: true}
global_costmap_params.yaml
global_costmap:
global_frame: /map
robot_base_frame: /base_link
update_frequency: 5.0
publish_frequency: 5.0
static_map: false
rolling_window: true
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: 3.0
height: 3.0
resolution: 0.02
move_base.launch
↧
What does a padded footprint mean in navigation package?
Hi, all. I am learning and modifying the navigation package to make it suit our need.
I found many method functions in costmap_2d are about padded footprint. For example, [padFootprint()](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/src/footprint.cpp#L138),Costmap2DROS::[setUnpaddedRobotFootprint()](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/src/costmap_2d_ros.cpp#L337)
I wonder what "pad/padded/padding" mean in navigation, and what the hell the comment of padFootprint() "Adds the specified amount of padding to the footprint (in place)" means.
The body of padFootprint is displayed as follows:
void padFootprint(std::vector& footprint, double padding)
{
// pad footprint in place
for (unsigned int i = 0; i < footprint.size(); i++)
{
geometry_msgs::Point& pt = footprint[ i ];
pt.x += sign0(pt.x) * padding;
pt.y += sign0(pt.y) * padding;
}
}
/** @brief Same as sign(x) but returns 0 if x is 0. */
inline double sign0(double x)
{
return x < 0.0 ? -1.0 : (x > 0.0 ? 1.0 : 0.0);
}
Hopefully anyone give me any guidance. Thank you!
**EDIT:**
Thank you very much for your explanation! @ahendrix
However, I compare the output of
[Costmap2DROS::getRobotFootprint()](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/include/costmap_2d/costmap_2d_ros.h#L169) which returns padded_footprint_ with the output of [LayeredCostmap::getFootprint()](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/include/costmap_2d/layered_costmap.h#L141) which returns footprint_. They have same values. Why?
Why and when does it need to provide some extra distance between the robot and obstacles duriing navigation?
Thank you!
↧
Plugging in a mobile platform to higher level navigation nodes
I've created a simple two-wheeled mobile platform with a Raspberry Pi running ROS Kinetic, and an Arduino that controls motors and relays sensor data via a rosserial node. I can reliably read sensor data via rostopic and move the platform by manually publishing a standard Twist message. I also have Tf running, which takes odometry data published by the Arduino, and updates the world position.
I'm now trying to plug this into the higher-level navigation nodes, with my ultimate goal being to using SLAM to dynamically map a room and navigate within it. What should be my general strategy be to accomplish this?
I've been trying to go through the [navigation stack](http://wiki.ros.org/navigation) docs, but it's a pretty large project and a little overwhelming. Should I start with [move_base](http://wiki.ros.org/move_base) or would this ultimately not be useful for SLAM or be superseded by something else? What interface does my "base controller" need to provide? Just a subscriber to a Twist message, or something else?
I'm having trouble conceptualizing, or even testing, just with the Twist message. I want to be able to instruct my robot to "move forward 1 meter", but Twist only represents velocity, not distance. I want to create my own motion message/action that extends Twist to also include distance or time, but I feel like I'd probably be reinventing the wheel. Are there any message or action types like that?
↧
↧
How to set via-points through code?
The TEB local planner has a tutorial (http://wiki.ros.org/teb_local_planner/Tutorials/Following%20the%20Global%20Plan%20%28Via-Points%29) on setting via-points in Rviz, but it does not explain how to set them in code. Anyone know how I can do this?
↧
How can I reduce drift in my robot's trajectory?
## The Problem (TL;DR) ##
My robot used to travel in straight lines between point A and point B. Now it doesn’t. I want to figure out why and how I can make it do that again by forcing the local path planner to follow the global path as closely as possible. I've done my best to summarize the problem here, but if you don't want to read an essay skip to the solution to this ROS question where I've re-stated the problem more clearly, and the work-around.
-----------
## The Problem (full explanation) ##
If a robot travels directly between two points and there are no obstacles in the way, then its trajectory between those points should be a perfectly straight line (in theory). My robot used to behave like this, as shown below:
And now it doesn't, it consistently follows a bowed/curved trajectory every time. The radius of the curve changes but otherwise the trajectory is identical. The final stretch back to the starting point also has a funny kink it. Example:
Now before I go any further, I do understand that this problem is largely aesthetic and doesn't matter. And I know that I could work around this by adding more goal points and breaking the longer lines down into a series of shorter ones. However the fact remains that I can't currently explain this behaviour and I'd like to solve the problem if only for my own education.
So I would like to correct this behaviour and answer a few questions
Here is all the relevant system information:
## System Information ##
- **OS:** Ubuntu 14.04 (laptop), ROS Indigo Igloo (robot)
- **Robot:** Clearpath Robotics Jackal UGV (real, not simulated)
- **Sensors:** IMU, wheel encoders, high accuracy RTK GPS
- **Localization:** package used is [robot_localization](http://wiki.ros.org/robot_localization). There are two instances of ekf_localization_node (local and global). IMU and encoder data is fused in the (local) /odom frame. IMU, encoder and GPS data is fused in the (global) /map frame - this is the frame /move_base uses for navigation. I can provide the specific launch files if requested.
The output from the global EKF is always accurate and doesn't drift. The local output accumulates error over time and tends to drift quite badly by the end of a run.
- **Navigation:** I use the [jackal_navigation](http://wiki.ros.org/jackal_navigation) package (version 2.2.2) to set up my navigation stack. I use the [odom_navigation_demo.launch](https://github.com/jackal/jackal/blob/indigo-devel/jackal_navigation/launch/odom_navigation_demo.launch) with the following parameter changes to [local_base_planner](http://wiki.ros.org/base_local_planner) and [costmap_2d](http://wiki.ros.org/costmap_2d):
1. xy_goal_tolerance increased to 0.35 m
2. heading_scoring = true (false by default)
3. Costmap size increased to 120x120 m
4. All instances of any "global_frame" parameter have been changed to /map.
5. All map (local and global) "update_frequency" parameters reduced from 20 Hz to 10 Hz
6. Reduced "controller_frequency" and "planner_frequency" parameters from 20 HZ to 10 Hz
To the best of my knowledge, these are the only parameters that have changed between the two graphs shown above.
The full navigation parameter files are [here](https://drive.google.com/open?id=0B1KZT92BcdVNZ2xVdXN6QlBycFk)
Currently, in all cases the global path is perfectly straight, but the robot never seems to follow it directly. I've tried tweaking the various trajectory scoring parameters in the [local_base_planner](http://wiki.ros.org/base_local_planner) config files but I haven't found any combination that provides a better outcome than the default values, possibly because I don't fully understand what each scoring parameter is changing.
- **Frame tree:** [tree](https://drive.google.com/open?id=0B1KZT92BcdVNYlZTT1JUc0VBYW8)
- **Node graph:** [node_graph](https://drive.google.com/open?id=0B1KZT92BcdVNSy1sNm4ybmNTWnc)
- **Localization launch file:** [localization.launch](https://drive.google.com/open?id=0B1KZT92BcdVNX29lbHY1V3dQVVU)
- **Example bagfile:** [Bagfile for 2nd graph](https://drive.google.com/open?id=0B1KZT92BcdVNOVhqWDhhcldPWFU)
## Possible Causes ##
I have several working theories on the cause of this problem:
1. **The wheels on one side of my robot slip.** If the wheels on one side weren't engaging properly this could explain why the robot leans to one side. However if this were the cause I would expect the robot to consistently pull to one side and one side only, which is not the case. In addition, when I manually drive the robot in straight lines it doesn't noticeably drift. The reason I'm considering this is because I have already had an issue with a wheel slipping on one axle, which has been replaced.
2. **The navigation parameters for local_base_planner are not tuned.** Which could cause the local base planner to not follow the global path properly. See the next section for questions I'd like to answer that may help with this.
3. **Trajectories are being calculated in the /odom frame.** I'm sure [base_local_planner](http://wiki.ros.org/base_local_planner) does this by default. If this were the case, and the /odom frame had drifted relative to /map, then a straight trajectory in the /odom frame would translate to an angled path in the /map frame. This could explain the drift I'm seeing. I've done my best to replace every mention of "/odom" in the config files with "/map" to try and force /move_base to do everything in the /map frame but it hasn't improved the trajectory.
Over the coming days I'll be trying a few other things like fusing GPS data in the /odom frame and periodically re-zeroing to match the /map frame. But I'm not sure they'll fix the problem I wasn't doing them previously when the trajectory was straighter.
## Questions I Want to Answer ##
1. In the trajectory scoring parameters for [base_local_planner](http://wiki.ros.org/base_local_planner) the explanation for *pdist_scale* says "The weighting for how much the controller should stay close to the path it was given" Does this refer to the global path or some other path?
2. What parameter dictates which reference frame local_base_planner calculates trajectories in? I'm pretty sure it's *global_frame_id* but I've set this to /map and it didn't improve the trajectory at all.
3. In general, what parameter changing/tuning advice do people have to make the local path adhere more closely to the global path?
Thank you in advance to anyone who can help answer these questions. I apologize profusely for the lengthy essay, but there's just no short way to convey this kind of problem *and* the context needed to solve it.
## Updates to the Problem ##
**UPDATE 1:** I'll post all new information in its own section for clarity. I have tried two solutions, both have offered only marginal improvements to the trajectory of the robot. However I have also discovered another possible cause.
First, I tried to periodically re-set the odometry in the /odom frame to match the odometry in the /map frame. I didn't complete a full run before the localization completely bugged out and started its "I'm hopelessly lost so I'll rotate on the spot endlessly" behaviour. Here is the trajectory for comparison: [Actual Trajectory (odom resetting) ](https://drive.google.com/open?id=0B1KZT92BcdVNa2Z5RVFsV1VBQkk) and here is what all the local/global/gps odometry streams look like relative to their internal reference frame (i.e. in X and Y terms, not UTM Northing/Easting): [Internal Odometry (odom resetting)](https://drive.google.com/open?id=0B1KZT92BcdVNd0FoR1pNOXNQXzQ)
Second, I tried to fuse GPS data in the /odom frame to (in theory) make it identical to the /map frame odometry and therefore just as accurate. It did offer slight improvement: [Actual Trajectory (gps fused in odom)](https://drive.google.com/open?id=0B1KZT92BcdVNZExwVzduU1NYOGM). What is worrying though is that the local data in the /odom frame and the global data in the /map frame were still different: [Internal Odometry (gps fused in odom)](https://drive.google.com/open?id=0B1KZT92BcdVNd0Y1QTR1MjlnX3c). I'm still investigating this.
In addition, I discovered that the data coming from the wheel encoders (in the topic /jackal_velocity_controller/odom) is at a very large angle to all the other data:
This data is fused in both my local (/odom) and global (/map) EKFs. Based on my experience with fusing GPS data in the global reference frame, if you fuse two data streams that are at angles to one another, you are going to have serious problems. Both the local and global EKFs are fusing the X and Y velocities from this data, and because these velocities will be at an angle to all the other sensor data this is quite likely to be what is pulling the local EKF off course. Unfortunately, it looks like this was also happening when the data for the very first graph (the one with nice straight lines) was recorded. Yet it obviously didn't affect the trajectory in that case, which is confusing.
The topic with this data in it - /jackal_velocity_controller/odom is set up by Clearpath and is published by a ROS node that runs by default on the UGV. However, as I said I have replaced one axle on the robot so it's possible that there was a encoder calibration process that I messed with when I replaced it. Or perhaps this is normal and the ekf_localization node accounts for this angular difference at some point, I don't know enough about how the source code works to say. I'm continuing to look into all this, but any advice or explanation on this particular issue would be very welcome.
**UPDATE 2:** I ran a rough test to confirm the behaviour of the odometry in /jackal_velocity_controller/odom. I started the UGV at a central point and then drove it in a (roughly) straight line in each of the cardinal directions as show below (re-booting the UGV between each run to reset the encoder odometry.
As you can see, with one exception the encoder odometry reports odometry starting in the positive 'X' direction. So even if the robot is travelling in a different direction (say, positive 'Y' direction), the encoder velcities I'm fusing will be showing it moving in a positive 'X' direction. But this doesn't seem to be having a significant effect on the local EKF which still confuses me. Obviously there is something critical that I'm missing about the way the EKF handles the data.
**UPDATE 3:** In response to @ahendrix and @MarkyMark2012 comments:
@MarkyMark2012: to the best of my knowledge, the only thing I have changed (in the localization/navigation packages) is the parameter changes I've listed in section "System Information > Navigation" above.
@ahendrix. It sounds like the EFK isn't handling the odometry data quite the way I think it does. To clarify, this is the relevant code in my launch file for both the local and global EKFs:
[false, false, false,
false, false, false,
true, true, true,
false, false, true,
false, false, false]
And the resulting trajectory (for a single pass, this one is straighter than most) looks like this:
I'm fusing the X/Y velocities, and my understanding is that in this case the encoder data is indicating that the X velocity is large and positive (moving to the right) while the Y velocity is small and positive. All other data indicates that the robot is moving up which contrasts with the direction the encoder velocity is implying. So in theory, this will encourage the EKF to propagate the position estimate to the right, following the encoder data. This doesn't seem to be consistent though, and like I said elsewhere, the encoder data has been doing this for as long as I've been recording bagfiles, but didn't affect it previously.
Regarding tuning the PID controller, that's a really good suggestion, but there doesn't seem to be any explicit PID parameters defined for the [/move_base](http://wiki.ros.org/move_base?distro=kinetic) or [/local_base_planner](http://wiki.ros.org/base_local_planner) packages. The closet equivalent seems to be the *pdist_scale*, *gdist_scale* and *occdist_scale* parameters in the /local_base_planner package, is that what you're referring to?
I'm running some more tests today to further investigate the issue so I'll try to update this again soon.
**UPDATE 4:** I tried increasing *pdist_scale* in the [/local_base_planner](http://wiki.ros.org/base_local_planner) package to 1000, which according to the [navigation tuning guide](http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide) should force the local plan to follow the global plan more closely. As you can see it didn't help, if anything making the trajectory worse: [odometry_with_pdist=1000](https://drive.google.com/open?id=0B1KZT92BcdVNLXVaS2REWTIwTjg)
Looking at the simulated data in RViz I did notice that the local path seems to stick a little closer to the global path, and the global path still points straight at the end goal point. But the robot still seems to drift. Other than the wheel encoders messing with the EKF I'm running out of leads to chase.
**UPDATE 5:** Just realized I had also altered the various map/controller/planner refresh frequencies from 20 Hz to 10 Hz. I did that many months ago to reduce warning messages about the controller/planner not meeting its refresh rate target. I'm not sure how this could affect the performance of the robot's trajectory but I'm not taking any chances so I'm looking into it now.
**UPDATE 6:** Based on [this](http://answers.ros.org/question/209287/base_local_planner-does-not-follow-the-global-plan-accurately/) ROS question I've slowly reverted some of my navigation parameter changes to try and make things run a bit more smoothly. I've changed the format of my charts to make them a bit more readable and added a "desired" trajectory to better show the drift.The changes (accumulative and in order) were:
1. Reduced the map size (120x120 -> 80x80). [Result](https://drive.google.com/open?id=0B1KZT92BcdVNRkh5ckxtcUtjTlU). No significant improvement.
2. Increase all map/controller/planner frequencies (10Hz -> 20Hz). [Result](https://drive.google.com/open?id=0B1KZT92BcdVNcHhsTGRxc1RLWVE). No significant improvement.
3. Reduced speed (1m/s -> 0.5m/s) and increased EKF freq (20Hz -> 30Hz). [Result](https://drive.google.com/open?id=0B1KZT92BcdVNTUkwMkJ6R3dHUG8). Biggest improvement is from reducing the max speed but waiting for a slow robot gets annoying quickly.
Many of the frequency changes were to get rid of warning messages about the map missing its update rate (because of my massively increased map size). Either way it doesn't seem to be the silver bullet I (briefly) hoped it might be.
**UPDATE 7:** I couldn't find information coming from the encoders directly (I think that Clearpath software handles it and gives the result to ROS) but I have been looking at the command signal coming from the [/move_base](http://wiki.ros.org/move_base?distro=kinetic) node, which is published to the /cmd_vel topic:
The top graph shows the actual vs desired trajectory of the robot, the key part here is obviously the blue line curving when it should follow the red (Sorry about the poor presentation). The bottom graph shows the content of /cmd_vel during this part of the trajectory. They key part here is the angular component - a positive value commands the robot to turn *left* and a negative value commands it to turn *right*. The large spike is where the robot is turning the first 90 degree corner.
Honestly this doesn't feel that helpful, because it looks like the robot is largely following the commands it is send. i.e. sharp left turn, straight, then slow left turn. I'm not sure if this means that the problem is happening downstream of the [/move_base](http://wiki.ros.org/move_base?distro=kinetic) node or not.
↧
move_base/status
I have imported a map and has run the Move_base package and all the necessary packages. I have however when I issue a coromandel to move the base using the set 2 d position in rviz I did no get the vehicle to move, no cmd_vel published.
I have check the rostopic but could not find move_base/status message.
Can I find out what are the causes the move_status not publishing.
Thank you
↧
Remapping move_base Twist publisher topic.
Hi all,
I'm working with a Clearpath Husky on ROS Indigo, Ubuntu 14.04. I'm trying to remap the topic that `move_base` publishes its Twist messages on to (`'cmd_vel'`) to another name that I can use with a `topic_tools` mux. I was able to do so by changing the `move_base.launch` file in the `jackal_navigation` package, however, I want to know if there's a way to do so without changing the source of the original package.
I created my own launch file that launches the `jackal_navigation amcl_navigation.launch` file and tried to remap the `move_base` publishing topic using `
↧
↧
base_global_planner doesn't update in planner_frequency.
## environment
- OS: ubuntu 14.04 on an x64, with kernel 4.2.0-42-generic
- ROS: indigo
- package: ros-indigo-navigation:amd64/trusty 1.12.14-0trusty-20180110-202207-0800
### config
- base_global_planner: "navfn/NavfnROS"
- base_local_planner: "base_local_planner/TrajectoryPlannerROS"
- planner_frequency: 0.5
## Problem
When navigation package is upgraded to 1.12.14 from 1.12.13, global planner doesn't update in planner_frequency.
It seems that the package is well-working at 1.12.13 in the same configuration. Is it problem of 1.12.14?
↧
Move Base Publishing Y velocities
Hi,
I've run into this strange behavior while trying to get my robot stack to run in gazebo. I've configured a turtlebot URDF with some 3D sensors and launching my pretty-generic ROS navigation stack configs. All of the sudden, move base is publishing only Y and theta velocities, no X.
I figure it must have to do with the URDF configs I changed or TF from the diff drive gazebo plugins, because I have not changed move_base in this development effort.
Any thoughts? I've become stumped here.
Example messages below: (I can never figure out how to get the markdown to work in ros answers :( )
linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.714091062546
linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.0
linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.401096045971
linear:
x: 0.0
y: 0.000136807560921
z: 0.0
angular:
x: 0.0
y: 0.0
z: -0.800002932549
↧
move_base and arduino synchronisation
move_base work well when i move the robot manually .
but when i subscribed to /cmd_vel by arduino it move well until it reached the goal it displayed that it reached the goal but my robot didn't stop and when i use keyboard it stop .
it's a synchronisation issue or in params ??
↧