Manually introducing noise in the simulated data did not help improve the tuning parameters. The poor localization accuracy stems from the fact that when we simulate our lidar/odometry data to test our SLAM algorithm, there is too little noise in the data to show problems with bad performance thus, it is difficult to tune the algorithm without directly running it on the robot. This makes it impossible to actually path plan. While the map that our SLAM algorithm builds is accurate, the localization accuracy is extremely poor. As of right now, SLAM is being integrated with path planning, but there are some critical problems we are facing. In essence, our work leading up to the demo and final report primarily revolves around integration and optimization, which we can do in parallel with our subsystem verification and system validation. Tomorrow, we are focusing on fine tuning the maximal rotational velocity and acceleration curves to ensure the map we generate of the environment is as accurate as possible. The translational acceleration is less of a problem, since the SLAM algorithm can keep up with it through a decent range of speeds. Moving SLAM to real time severely limits the computational resources for the rest of our algorithms (including path planning and our AruCo detection). This is not much of a problem in simulation since there were lots of CPU resources available since the SLAM is not running in real time. Unfortunately, autonomously moving involves large accelerations in both the translational and rotational senses. In particular, the SLAM algorithm matches the lidar point clouds very poorly during sudden large accelerations and fast speeds.

Although our path planning works correctly in simulation, there are integration challenges when moving from simulation to reality. There are some struggles still left, however. Throughout the week, we finished programming our DWA path planning algorithm.

Slamtec robotstudio plugin