Traffic Light Tracking
March '18
Traffic Light Tracking
March '18
Computer Vision
March 2018
Background
LiDAR- what it is, why it is relevant
Reference Velodyne LiDAR page
Remote Sensing- class at UMD, build our own LiDAR systems to map something on campus --> note less design, more build
Over Sand Vehicle
January - May 2015
Background
This was a semester long project I completed my freshman year at UMD.
I worked with an incredible group of engineering students to design, build, and test an Over Sand Vehicle from scratch.
It was designed to navigate around a sandbox and map the terrain. With several challenges, we focused on measuring the height of certain bricks at given locations.
[Side note: most of these pictures are before I got a fancy camera and light tent to take pictures, so I apologize for their poor quality]
Design Process
Constraints
Given that this was a first year project, we had quite a few rules to abide by.
First, our vehicle had to use an Arduino microcontroller to both sense and actuate. The Arduino as well as any other sensor, motor, etc. had to be powered by batteries.
Additionally, the vehicle could not weigh more than five pounds, could cost no more than $350, and could not exceed two feet in height or width.
Early Prototypes
We went through a very iterative and creative design process using a variety of concepts to accomplish the task.
Our team spent a substantial amount of time debating over the use of wheels or tracks. We even went as far as making models with wheels, but decided, in the end, to work with tracks [this was a decision we would later regret].
Furthermore, we took a variety of different approaches for measuring the brick including a distance sensor mounted on an angle.
Some of the renderings/drawings for these ideas are shown.
[Side note: this is only one of the prototypes we came up with. It was one of our better documented early concepts.]
Final Prototype
The final prototype was designed to use an ultrasonic "ping" sensor attached to a mast made of PVC. This sensor emits and receives ultrasonic waves off surfaces. With a quick calibration, the distance can be calculated.
The sensor hung over the side with the intention of gathering further information about the brick (e.g. area, volume) if needed. This would enhance our map. It also alleviated the need to figure out the geometry.
Furthermore, our team decided to use treads instead of wheels under the impression that wheels would slip in the sand and simply dig holes. The treads would be in tension along the drive gears and supports.
Motors
Distance sensor
PVC Mast
Treads
Batteries
Two motors were placed in the front of the vehicle and counter weighted with the batteries and Arduino.
To make the system as cheap as possible, we aimed to ignore aesthetics and use relatively cheap materials for the construction. As a result, the base and additional parts were to be made of wood.
It's worth noting that a substantial amount of calculation and research was performed before we purchased the motors, sensor, and batteries. Careful consideration was given for the power draw of both motors as well the as the battery life of the batteries.
For example, a motor characteristic was created for the motors we selected and extensive research was performed to determine the best type of batteries to use [we ended up using Nickel Hydride].
Build Process
The build process was split pretty evenly among the team members. While three group members were working on the code, the rest were constructing the hardware.
Hardware was further split between electrical and structural subsystems. Despite our limited experience, the initial construction of the vehicle went smoothly.
Later, several parts were 3D printed [my first time using a 3D printer] for various purposes including a general power switch holder and sensor mount.
Testing
#1 Treads
The first of many obstacles we faced along the way was with the functionality of the treads. Our initial design called for full tension in the treads, but we soon learned that the torque required to move the vehicle in sand could not be met by the motors.
Additionally, the treads consistently gathered sand between the joints making them stiff. This partially negated the purpose of easing the tension.
Solutions
In an effort to alleviate the first issue, we decided to move the tread supports closer together in an effort to relax the tension. This allowed the belt to move more effectively. This also explains why the built prototype doesn't exactly match the CAD design.
As a result, before each sequence of testing, we would wash the sand out of the treads and use compressed air to blow out the remaining particles. This was one of the biggest [and most annoying] issues with the propulsion system.
#2 Navigation
It became very clear to the coding sub-team that navigation would be our biggest challenge. The test area used computer vision through a webcam to identify a tracker [not set up by us].
The main computer then used a radio transmitter to communicate with the vehicle which had a radio receiver. Gathering and processing this information was crucial for knowing the orientation and location of the vehicle.
Solution
This became one of the problems that we faced quite frequently. Given the complexity of the issue, we looked to simplify other components.
For example, the mast was rotated 90-degrees to the front of the vehicle. Instead of driving along the side of the brick, it could simply drive up to the front face and measure the height. This required less turns and minimized the potential of navigation issues.
In addition, we moved the vehicle in 1.5 second bursts to allow the navigation system to "catch up" with the vehicles current location.
#3 Motor Controller Integration
Instead of building H-bridges to power the speed and direction of the motor controllers, we decided to use a motor controller. Given our lack of exposure to Arduino coding, the motor controller posed a serious challenge.
Problems During Testing
Overall, testing took on a trial and error approach with several iterations along the way. This explains why the final build didn't exactly match our final prototype design.
Solution
Luckily, through extensive trial and error combined with sample codes for reference, we were able to figure out the correct commands to power the motors.
Changed mast orientation
Side note: We noticed during testing that, for some reason, the vehicle ran better in reverse. I'm still not sure why this was the case, but it worked, so we didn't question it.
Final Result
The video and CAD drawings below are from the final test. We were able to successfully navigate to the brick and take an accurate height measurement.
Lessons Learned
This project was the first time I worked on a team with other engineering students. As the project manager, it was one of the most fun challenges I had faced. Our team had two mechanical, one electrical, one chemical, one fire-protection, and three bio-medical engineering students. This allowed for a huge diversity of thought, but also a tremendous opportunity to use everyone's diverse skillsets.
Given the changes we made, particularly from the first design to the last, this project taught me the importance of staying flexible throughout the design process.
It also helped me take on the mindset of failing early and failing often. We were the first team to put our vehicle in the sandbox to see how our idea would work. We wanted to make quick changes to constantly improve our design. This is how we discovered the tread problems among others.
Finally, this was one of my first true engineering courses where I had the chance to learn what engineering was all about. I learned how to use Computer Aided Design software, code in Arduino, and 3D print parts. It helped me develop a hacker mentality.