Project Mini RoSco: Project Documentation

By: James Gilson (Project Manager)


Project RoSco:

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.

Dome for Pan and Tilt Vision System

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).

Our prototype custom PCB(Bluetooth module shown in lower right corner of the image)

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.

Our Custom PCB

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

Project Overview

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.

Burndown Report



The following are links to the indicated blog posts:

Project and System Level Requirements:

Objectives and Requirements

Project Budget:

Budget and Expenses

System Block Diagram and Interface Definitions: 

Block Diagram and Fritzing Diagram

Final Arduino Code

Resource Report:

Power Consumption Tests and Power Budget

Speed Requirement Trade-Off Study

Speed Requirement Trade-Off Study Update

Mass Budget Report

Top Level Schedule (changes have been made to percentage complete for certain tasks on the mpp file below):

Updated Project Schedule

Project Schedule Link (mpp file)

Trade-off Studies and Rapid Prototyping:

Speed Requirement Trade-Off Study

Speed Requirement Trade-Off Study Update

Electrical Motor Noise Reduction Techniques

Electrical Motor Noise Reduction Techniques Tests

Design Verification Testing:

Pan and Tilt Vision System

Pan and Tilt Vision System Test

Bluetooth Module Test

Project RoSco Presentations:

Project RoSco Preliminary Design Review

Project RoSco Critical Design Review

Arduino Code on Github:

Mini RoSco Code on Github


0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *