Conclusion

Results

Our project mostly met our criteria for success. We were able to reach a destination while avoiding obstacles.

The main issue we encountered was reliability and reproducibility of the results: minor fluctuations in starting location, etc. could product major variations in behavior. We saw everything from completely smooth path following to jerky motion to thrashing left and right until we shut it down, all with the same code running.

If we had the time to implement more reliable object tracking, perhaps this would be alleviated.

Difficulties

• Localization
  • Transform data from the GPS to the UKF node
  • GPS beacon placement
  • Rate of GPS data
• Obstacle detection
  • How can we reliably detect obstacles?
  • How do we limit the number of obstacles, for computational efficiency later on?
  • We can only see one (or two) sides of an obstacle
• Path generation/following
  • Optimization: originally written in MATLAB, converted to python
    • CVXOPT optimization is significantly slower (~5 times), but the Matlab/ROS interface made it impossible to run locally on the turtlebot (can't install Matlab on the Jetson since it doesn't support aarch64, Matlab node has to be run from Matlab itself and can't be linked to in a launch file, cannot easily handle custom message types). The decision was made to convert it to python, but to reduce the number of iterations done per time step in order to reduce the computation load
  • Avoiding jerky movement, especially with flickering obstacles

Flaws / Hacks / Possible Extensions

Obstacle detection

• Hack: Have to specify minimum object length in code. Ideally, would adapt based on object you hold up to calibrate, or at the minimum a config file. Also have to specify LIDAR valid-points range (up to 3.5m, but we usually used 2m) and resolution of LIDAR-to-image conversion (image is used both to visualize and detect obstacles) in code.
• Flaw: Obstacles flicker in and out of existence. We tried to combat this by holding onto some data from previous LIDAR scan frames, but that is by no means perfect. It would be good to improve the reliability of obstacle detection.
• Extension: Track and anticipate motion of moving obstacles. We could then plan our path such that it doesn't intersect with the path we anticipate the moving obstacle will take.

Localization / Sensor Fusion

• Hack: Have to consider which type of sensor want to use to obtain an optimal result. Ideally, UKF would adapt based on the sensors you specify but in the robot_location package we used, the types of sensor is very limited. In order to get around it and use our GPS beacons, we add a new message type and customized the GPS package file so that it sends the data we need for sensor fusion.
• Flaw: The UKF node highly depends on the GPS data so if the signal get worse, the filtered location data might have bias from the actual one. The precision of the filtered location is not perfect.
• Extension: Try to utilize the data from more types of sensors such as LIDAR and camera. In addition, tunning the UKF and specify the accurate covariance data of the sensors we used might improve its performance.

Path generation / following

• Flaw: when objects suddenly appear/disappear or move, the optimization often struggles and ends up creating paths with very jerky movements. For smooth performance, objects need to be detected about 1.5 meters ahead, have a static position in the world frame, and not be directly centered in front of the turtlebot, which are not realistic criteria
• Hack: objects were held for three time frames in order to attempt to smooth the movements. The path following was also constrained to not change velocities too drastically
• Extension: merge current with previously detected obstacles to avoid flickering obstacles. If the object still appears to be moving, account for its position at each time step to plan a path around it. Continue tuning cost for staying close to previous paths, so obstacles directly ahead does not cause the path to keep switching sides.