We are Team2
Our project's main objective is to detect and remove obstacles utilizing an ultrasonic sensor and swinger arm respectively. There are certain environments that are filled with garbage or obstacles. It may be of importance to have the debris cleared before other vehicles or people come in to complete a certain task. In an attempt to create a project that would eventually detect debris on the road and dispose of it properly we began by implementing an ultrasonic sensor and sweeper arm. In future iterations of the project, other sensors or arm actuation can be implemented to further the capabilities of the robot.
The base circuitry for the car before adding any additional components.
The circuit including the additional components. For the ultrasonic sensor, a 1 kilo-ohm and 2 kilo-ohm resistor were used in series.
The training model for an autonomous vehicle requires image data as an input. To gather this data the vehicle requires a camera we designed a camera mount to vary the angle of the image. We created 3D models using SolidWorks and exported an STL file to 3D print the camera mounts. We also designed a chassis and attached it to the main body of the RC car to mount the rest of the electronics. Additionally, we 3D printed a case for the Raspberry Pi 3 B+ 
For the base plate, we designed it in SolidWorks and cut it out of 1/4" acrylic. To allow for cable management, we left a center slot that would allow for wires to pass through from the chassis to the electrical components. To help with the alignment of the base plate with the stand-offs, we used a slotted hole at the back of the plate, which allowed for vertical adjustment. We could not easily or accurately measure the length from the back stand-offs to the front due to the limited range of the calipers in the lab; therefore, having slotted holes prevented misalignment issues. Apart from the camera mount, we used Velcro to secure the electrical components to the base plate.
The camera mount was a combination of of 3D printed parts and laser cut acrylic. The camera mount was designed to allow for quick adjustment of the height and angle of view, in order to optimize the camera position before starting to train. For the through bolts that connected the acrylic arm to the two 3D printed parts, two nuts were used as a substitute for a nylock nut, which was required to prevent the bolt from loosening under vibrations. While this camera mount allowed for easy adjustment of the camera position initially, it also was detrimental to consistent results when collecting data. When running the car in autonomous mode for the first time, the car crashed into one of the lockers and the camera angled down slightly. This change in view angle ruined the previous models that were trained--therefore requiring us to restart data collection. To mitigate the risk of this happening further in the project, we used superglue to adhere the acrylic arm into a fixed angle.
In the last week of the project, our camera mount was snapped while it was left in the storage locker. It is unknown the circumstances under which this happened; however, it could have been avoided by using a more robust mounting arm. While the 1/4" acrylic was suitable for normal operation of the car, it was too weak to withstand the abuse of multiple groups sharing a locker. Within the original design, there is a stress riser occurring between the transitions from 3D printed material to acrylic due to the sharp corner. For a redesigned mount, reducing this stress riser would result in a more robust design.
Ultrasonic Sensor and Sweeper Actuator
Team2 was able to collect data and train a model that successfully completed 5 indoor autonomous laps.
Using the same model, the robocar was able to complete 3 fully autonomous outdoor laps. The model was robust enough to detect the outer edges of the track despite the lighting differences in the training data. The model was able to detect the edges of the track and correctively steer in order to remain within the outdoor test track.
In order to add the feature of obstacle detection, the team decided to implement an ultrasonic sensor. We believed it would be simpler to implement than running a second camera and using computer vision on a second Raspberry Pi. We were able to implement an inexpensive HC-SR04 Ultrasonic Sensor Module  to the front of our vehicle and wire it directly to the Raspberry Pi that we were already using to run the DonkeyCar framework. It was simple to connect the sensor to the pi as per our circuit diagram in the corresponding section. Implementing code to start collecting data from the ultrasonic sensor was a simple process. 
However, as we tested with a moving obstacle the data was noisy and had high variance. This led to erroneous data that triggered the actuation of the additional servo motor at incorrect instances. To fix this issue we implemented a moving average filter that took the running average of the last three sampled data points. We did not want to use more data points because we were worried that the inherent delay caused by this filter would be too large that the car would crash into the obstacle without actuating the sweeper's arm.
This short python script controls the servo to do a quick 180-degree sweep . A full 180-degree sweep was enough to keep the arm out of the car's self-driving camera while the arm was in its resting position and to move an object completely out of the car's way.
We then combined the ultrasonic distance measurement script mentioned earlier with the sweeping script. This next script continuously takes averaged measurements and sweeps once if an object is less than 5cm from the sensor .
Our original plan was to have the sweeping mechanism work while the car was driving autonomously. We wanted the car to stop when an object was detected in its path, sweep the object away, and then continue driving. However, a number of issues prevented our car from functioning. Our camera mount snapped in the storage locker requiring us to retrain the PI. Then our PS3 controller stopped connecting with the car which halted development on this feature. Reflashing the PI at this time would risk the sweeping script from functioning correctly. We decided to continue development on the sweeping feature itself instead of the auto drive portion.