Fall Semester Implementation Details
For our navigation subsystem, we are utilizing ROS’s move_base package to generate costmaps that can be used by our planner. The costmaps are generated using the LiDAR point cloud and our artificial center line point cloud. Given this costmap, our planner is able to plan global and local paths around these obstacles.
For the planning algorithm, we are using ROS’s default global planner (based on Disjksta’s shortest path algorithm), the Timed Elastic Band (TEB) local lanner. We chose this local planner because it constructs local paths that resemble the shape of an elastic band, which was desirable to us since we did not want our plans to use the differential-drive capabilities of our Husky platform. Given that our use case is a full-scale car, we want our planner to construct paths that would be feasible for Ackermann-drive vehicles. The TEB planner does a good job of this.
Below is an example of our full system demo, with planner functionality highlighted. On the central pane of the window, we can see the robot model moving through the environment and generating plans using the TEB pipeline. The green arrows are the waypoint goals, the black line from the robot is the global plan (naive shortest path to the goal), and the red line from the robot is the continuously optimized TEB local plan.
We spent a great deal of time and effort tuning all of the various parameters associated with the TEB local planner. This was essentially an ongoing, semester-long process of making small tweaks and changes. We were happy overall with the final behavior, but we are sure that there is still room for improvement if we were to spend more time working with the system and gaining more intuition on the effects each parameter has on the overall system behavior.
Overall, it was fairly difficult to tune the planner for the Husky, since most sets of planner parameters seemed to work well in the Gazebo simulation, but did not translate well to the physical platform. The main reason for these differences is that Gazebo most likely does not do a good job of simulating latency between messages being sent and trajectories being generated. Our early experience was that the incoming message frequency was too much for our laptops (we used our Lenovo Legion Y540s as onboard processors), so velocity commands were being sent before the system could give feedback about its current position. This behavior resulted in a lot of jerky movement. We ended up gradually mitigating this problem by eliminating all unnecessary computation being done by the planner by compiling only the pieces we absolutely needed for our system to run. By stripping down the computational load, we were able to get better response rates within the PID loop. Once that was mitigated, we tweaked the rotational/linear speed and velocity limits to ensure that the planner did not plan any paths that allowed the robot to accelerate too quickly or rotate in place. Our final speed and acceleration limits used in the Fall Validation Demo are listed below. We found these to be the best parameters to date, allowing the robot to make smooth, continuous turns with minimal in-place rotations.
-maximum forward velocity: 0.5 m/s
-maximum rotational velocity: 0.3 rad/s
-maximum forward acceleration: 0.1 m/$s^2$
-maximum rotational acceleration: 0.1 rad/$s^2$
——————————————————————————————————————–
Here are some of our preliminary videos from our first iteration of the planning subsystem. Look how far we’ve come!!