By: James Gilson (Project Manager)
James Gilson (Project Manager)
Alexander Montoya (Systems and Test Engineer)
Anthony Haas (Sensors, Actuators, and Powertrain)
Jonathan Gong (3D Printing and SolidWorks)
Project Mini RoSco was a success. Working off of the documentation of previous RoSco models, and with the help of Professor Gary Hill, our team made a miniature version of RoSco that had different capabilities and different project requirements than the previous RoSco model.
Our RoSco was designed around a simple objective; build a robot with performance parameters equivalent to a member of the U.S. military crawling around the test course. The budget for the robot could not exceed $150 to produce, and had to be delivered by December 10th, 2014. The project also had to have all parts 3D printed, a custom printed circuit board, control of the robot provided by Arxterra (using an Android phone camera), a pan and tilt vision system, single power supply, and Bluetooth communication.
The major change to the previous RoSco model was the pan and tilt vision system. As shown on the previous RoSco model, the pan and tilt vision system worked using two servos that made a cell phone pan and tilt. This caused servos to burn out prematurely because some cell phones are much larger than others. Also, since the cell phone is crucial to controlling the robot, if the vision is lost (the cell phone was damaged) then the robot would be helpless. And since our robot was designed to replace a soldier who may or may not be exposed to dangerous elements, our vision system had to be secured and protected. Our pan and tilt vision system was designed and refined by several people. A pan and tilt vision sub-group was formed to assist all projects utilizing the new design. This sub-group was crucial in getting our design working.
Bluetooth communication was used for signals to be sent from the Android phone to the Arduino Microcontroller. On previous models, a cable was plugged into the Android phone on one end, and the Arduino on the other end. Not having to use this cable allowed us to make one less hole in our chassis, thus making our design more dust proof. This new addition also allowed our pan and tilt vision system to rotate freely with no hanging wires (except for the servo wires which were not a problem).
The other major change to the previous RoSco model was the chassis. The previous RoSco had a chassis that was full of gaps and thus exposed all of the electronics. This design served a valuable purpose however; it allowed the user to quickly make fixes to internal components and easily allowed new technology to be added to the robot. Our RoSco however, had to have a sealed chassis with all internal electronics. Again, this was due to the nature of our objective, specifically, a robot that was built to crawl around in the dirt had to be resistant to dirt and dust. Our chassis also had to make it possible for our robot to be less than 16 inches in height (see Project Requirements).
This semester all groups were given the requirement to design a custom PCB. Our robot’s custom PCB was relatively simple, and with the help of the PCB czars Ahmed Arbi and Steve Weiss, we were able to design and purchase our custom PCB. Having a custom PCB allowed us to reduce the size of the internal components and gave us more room inside our chassis. The Adafruit Motor Shield was used on the previous RoSco model. This motor shield worked very well, but designing and ordering our own custom PCB allowed us to learn how to use the Eagle Software, and allowed us to only pay for the components that we needed.
At the time of this writing, our Mini RoSco is being further refined. The picture of RoSco above provides a good idea of what our final robot will look like, but don’t forget to check out our final design in our Mini RoSco movie.
Percentage of Work Completed and Overdue Tasks
The above image is an up-to-date project overview that provides the percentage of work completed, as well as overdue tasks. Project Mini RoSco was very successful. The overdo tasks are not all necessarily overdue. When making the project schedule, we decided to be ambitious and try to finish early. We wanted to finish early to have plenty of time to work on our final video, as well as make any improvements and or trouble shoot or robot. During the semester we found someone with experience in editing movies. He agreed to make our final video for us, which is currently in progress. This final video is not due until 12/19/2014 at 7:00 PM. Therefore, this task is not overdue by the companies deadline; it is only overdue by our teams deadline.
Also, at the time of this writing, our custom PCB is being soldered and assembled. After we ordered our custom PCB, we realized that we had ordered it too late. It took much longer to deliver then we expected it to, and it would have caused us to go over budget if we expedited shipping. Our team soldered our own custom PCB for testing, and this PCB was used in our robot on the day we presented. Our Professor knew that our PCB was in the mail, and was kind enough to give us an extension. We will be presenting our final robot on 12/16/2014 at 1:00 PM.
The only task that is truly overdue is the testing of the chassis. The idea was to test how dustproof our prototype chassis was. However, as the semester progressed, and other problems were encountered, this task was pushed aside for more important items. Part of the problem was the 3D printer that we were using. The printer failed the majority of its prints, so we were using our prototype chassis to test our robot until about a week before our final presentation. As project manager, I should have been more on top of when and where our final chassis would be provided so that I could perform the chassis test. Although we were not able to test our chassis, I am confident that our design will provide protection from the dust and elements on the test course.
The following are links to the indicated blog posts:
Project and System Level Requirements:
System Block Diagram and Interface Definitions:
Top Level Schedule (changes have been made to percentage complete for certain tasks on the mpp file below):
Trade-off Studies and Rapid Prototyping:
Design Verification Testing:
Project RoSco Presentations:
Arduino Code on Github: