The goal of this lab was to begin creating autonomous wall following code, as well as ensuring the robot recognizes obstacles and stops before collision. In order to implement all the functionality for this week, the team broke the tasks into three scripts, which were worked on in teams of two. Here is a link to the github repository with the code for this lab. And here is a link to the Google Slides for this lab.

Chevy and Efe worked on a safety controller in charge of detecting obstacles directly in front of the robot (within a 60 degree cone) and stopping the racecar in response. The controller takes in data from the laser scanner attached to the racecar that is within the appropriate range (± 30 degrees) and filters it. The team decided on a distance at which an obstacle is considered too close and signals the robot to stop; that number was determined to be [1m] because it takes the robot some time to stop. If any reading indicates an obstacle within that distance, the robot is instructed to stop by sending a zero-speed command.

Raoul and Victor worked on a wall detector that provides information on where the wall is for the autonomous wall following code (see below). This detector also takes in information from the laser and returns the distance to the wall and angle from the wall. The detector takes all the measurements within the range ±30 to 135 degrees, determines the angle for each distance measurement, and uses RANSAC to create a linear model that represents the wall. Using that model, the detector can return a distance to the wall and angle from the wall.

Nick and Liza worked on a PD controller that took the angle and distance from wall-scanner and attempted to make the robot drive in a straight line parallel to the wall. The initial attempt at a controller, which was proportional to the error in distance and the derivative of the error, worked very well in simulation, but produced erratic behavior with the actual racecar. Raoul and Efe then created a PID controller which controlled the error in both distance and steering angle.

This week, the team did much better dividing up the tasks. The work for the week was divided into three scripts, each of which was worked on by a pair. This turned out to be a very successful model, since the pairs shared information and interfaced well, but there were never too many people working on the same thing. However, there is still room for improvement. While working this week, the team spent too much time in the planning phase and starting coding very late. This created something of a time crunch near the end of the week.

In the future, the team should make a timeline for the week and determine when actual coding will begin. Sharing information was also important this week, as each team member has a different technical background, and improved but there were moment where a team member realized during an explanation that either what they were explaining was incorrect or that they did not understand it themselves. This needs to be corrected so the team is not confused.