Actually having a local costmap helps a lot with path planning
In the standard ROS global/local path planning stack, you create a "costmap" by layering different types of information about things you want to avoid (or keep near), and these are used by a (1) global planner, which creates a full path to the eventual goal, and (2) a local planner, which keeps near the global plan, but additionally the robot's kinematic constraints. The global costmap is expected to be relatively static, while the local costmap will be smaller (in the video, it's a 4 meter square around the robot), but will update more frequently.
Poor path planning in the last video was probably largely the result of me having an empty local costmap! I had my topics misconfigured with settings from my old Kinect setup. A big issue was that, though I was using a fake LaserScan topic generated by depthimage_to_laserscan, I was trying to create a
costmap_2d::VoxelLayer from this, instead of a costmap_2d::ObstacleLayer. Since the RealSense is mounted not-quite-horizontally, the fake laser scan was tilted, and this resulted in weird behaviour where it would mark, but not clear, in the costmap (and do neither on the right side of the view if min_obstacle_height was set too high).
As you watch this, you can tell that remaining problems with path planning are likely just tuning issues--for instance, the oscillatory left-right steering trap that it falls into near 2:30 is due to the kinematic model believing that such small motions will actually accumulate a change in yaw, while, in reality, they are soaked up by the play in the drivetrain, and we don't go anywhere, like trying to swim by kicking in a viscous fluid.
And, other times (trying to do the turnaround at about 0:40 ), the planner will create trajectories that aren't feasible within the turning radius the car can actually achieve, and so will need to make frequent adjustments to the plan as we continuously fail to achieve it.
Having a more realistic kinematic model and more precise/achievable plans will all for less conservative cost-mapping, enabling for instance automatic passage through the kitchen at 6:28 without manual teleop. Really, the issue there is due to the towel on the stove being projected down into the costmap--it's clearly (to human eyes) not a true obstacle, but it's also unfortunately too low to be excluded with the max_obstacle_height parameter.
You can tell the parts where I drive manually, because no yellow/green planned paths appear in the map view, such as a few times between 4:30 and 5:39 where I manually drive around cleaning up the map.
Next video will show some (bad) semantic segmentation results and outdoor sidewalk driving (some autonomous). The eventual plan is to use this segmentation to create (at least part of) our local costmap.