## 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 but if you don't want to read an essay skip to the last section "Questions I Want to Answer"
-----------
## 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 done 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.
To the best of my knowledge, these are the only parameters that have changed between the two graphs shown above.
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)
- **Example bagfile:** coming soon
## 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.
↧