Fall 2015 RoSco Final Project Documentation
Our project, RoSco, has been a struggle throughout the semester. This document is a testament to our willpower and determination.
RoSco Fall 2015 Prototyping and Design
By Gary Fong (Project Manager/Manufacturing)
For our prototype, we put together some parts to simulate the lifting function because we did not have our 3D printed treads and wheels. Using moldable plastic, duct tape, tinker toys, and hard styrofoam, we put together a prototype. Here is a video of our rover prototype and here.
Fall 2015 RoSco: Schedule and WBS
By Will McKinney (Project Manager/Electronics and Controls)
Schedule and WBS
A significant tool that we used in our project was our Projectlibre schedule. This allowed us to list all of the tasks that we had to do on this project and plan deadlines. As the project went on we could see where we stood in terms of completion date. A copy of our schedule is seen below.
Above is the final schedule for the RoSco. The tasks that were of concern for us were the 3D printed parts and the PCB layout. We were able to send the 3D printed parts out fairly early but there were a lot of problems with the prints. It would have been beneficial to get our 3D printed parts early so that we could have a lot of time to catch some of our design flaws. However, that is not the way things go sometimes. There were a lot of problems with the 3D printers that we were using because they were printing bad parts. This ultimately had a big effect on our project because we got our parts too late to make changes to our rover. Another area of concern was our PCB. We cut it very close when we sent it out. Our PCB was sent out on the 20th of November and arrived two weeks later. When we soldered all the parts on the PCB everything worked but if it did not work, we would not have had time to fix the problem and get a new PCB. All in all, we moved things along very well in this project but got punished for our manufacturing mistakes.
Mid-way through the semester we had to change around our project positions which made our tasks a little bit unclear in terms of who does what. Below is a final work breakdown structure.
In the above diagram it shows our work breakdown structure. There was a change in the project manager position when Todd Cook moved to Electronics division while Gary Fong and Will McKinney decided to co-project manage. Todd’s was now in charge of the PCB wiring and layout. Youssef Al-shanti was in mission systems and test.
Youssef was in charge of most of the coding in this project which included the code for the servos, motors, control panel design, and the bluetooth.
Will McKinney started helping Gary with some solidworks design because with the switch, Will’s tasks went down and Gary’s increased. With Will helping Gary with some of the 3D design, it would even the load. Along with the 3D design, Will conducted multiple experiments, built parts for our prototype and worked on the schedule.
Gary Fong worked long hours on the 3D modeling of the wheels, brackets and tread. This was a new program for him to learn and he was able to pick it up very quickly. Gary also conducted a trade-off study along with tracking costs.
RoSco Fall 2015 Solidworks/3D Model Design
By Gary Fong (Project Manager/Manufacturing)
To begin with, it is important to understand the design process of our rover. The RoSco has four track assemblies that had to be constructed through Solidworks. This comes out to eight wheels, four tracks, 4 legs, pan and tilt, and one chassis that had to be designed. The tracks and wheels were designs that were obtained through Mike Pluma which I modified a bit to fit our requirement to overcome obstacles.
Fall 2015 RoSco: Verification and Validation
By Will McKinney (Project Manager/Electronics and Controls)
Verification and Validation
Above shows our verification table. This was used to determine how well our project was built. The verification table was to be done in a lab environment. This is an effort to focus on meeting the requirements without having the course conditions affect the the rover. The lab provided a controlled environment to observe the performance of our rover.
From this we can tell where we went wrong in this project and where we succeeded. The main problem that we ran into with this project was the design of our wheels and treads. The treads would fall off of the wheels after a few feet of movement. This hindered us from completing our verification test of overcoming tree roots. This was a design problem that we should have changed before sending the wheels and tread out. The tread was made at a different spacing then the wheels. Also, the wheels were wider than the tread which caused them to have room to move. Aside from this we had another problem with the pan and tilt. Our servo that pans the horizon would make erratic movements. This caused problems when testing for the field of vision of our rover. We did have a lot of success in this project as well. We were able to design a rover that met the height requirements, communicated through bluetooth, moved at a speed of .5ft/sec while the treads stayed on, and was able to traverse over a block the size of a sprinkler head. It is important to note that one design mistake affected a very large portion of our project which was the validation segment. The Validation table is shown below.
The goal of these validation tests were to see if the rover completes the mission of simulating a soldier crawling through that barbed wire course. In order to simulate a soldier on this course the rover would need to move at the speed of a soldier, operate under the height of barbed wire, maneuver over obstacles that a soldier would encounter, and last the entirety of the course. Each of these actions were to be tested on the course with multiple tests. For example, the speed would be tested using three different methods with varying difficulties. We would start testing the rovers speed on dirt, then move to testing the speed on leaves, and end with a speed test in rainy conditions.
The validation tests above were hindered by the fact that we could not keep our treads on, even in a lab environment. If the treads would not stay in tact in a lab environment, there would be no chance of completing the requirements on the course. The height requirement was able to be met but the other validation requirements needed the tracks to stay on the wheels.
Fall 2015 RoSco: Power Budget
By Will McKinney (Project Manager/Electronics and Control)
Power Budget
| Item | Model | Quantity | Minimum Current(mA) | Stall Current(mA) | Voltage(V) | Min Power(W) | Max Power(W) |
| Servo(Each Track Assembly) | HD 1501MG | 4 | 500 | 2500 | 6 | 3000 | 15000 |
| Motor(Each Track Assembly) | Pololu 120:1 | 4 | 70 | 800 | 6 | 420 | 4800 |
| Servo(Pan and Tilt) | Micro | 2 | 350 | 1500 | 6 | 2100 | 9000 |
| Bluetooth | HC-06 | 1 | 38 | 3.3 | 125.4 | ||
| Arduino | Uno | 1 | 250 | 3.3 | 825 | ||
| Total | Tested Running Current | MinCurrent | Max Current | Min Power | Max Power | ||
| ROSCO | 1A/2.5A | 3268 | 16200 | 18830 | 97200 |
Above is the final power budget. The majority of our power was used by the 6 different servos and the 4 different motors. It was essential to find out how much current our rover runs off us because we needed to know if the batteries we were given were sufficient. The batteries that were given to us were 700mAh capacity, 7.2V batteries that were used on past semester’s projects. The pololu motor’s specs say that the motors run at 70mA when free run. We tested this value and found that when they were free run, the Pololu motors ran at 72 mA.
Each servo drew about 500 mA when there was no load. When we built our first prototype we were able to see how much current our rover drew when everything was running. We found that it used 1A when the motors were running and 2.5 A when the servos were lifting the entire rover. This makes sense because the motors were running with friction being applied which means they drew more current. Each motor drew about 200mA when the motors were running. When the servos were lifting the chassis, 2.5A were being used. This means that the servos were barely under any stress. The servos are rated to have 17kg/cm of torque so when the four servos lifted the 3 pound chassis, they didn’t need to consume a lot of current.
In conclusion, our 700mAh battery is sufficient for this project because this will allow us to drive at best case run the rover for 40 minutes. At worst case, the rover would be able run at 2.5A for 16.8 minutes using the 700mAh battery. This would give us enough time to complete the course when traveling at .5-.75ft/sec.
Fall 2015 RoSco: Field of Vision Experiment
By Will McKinney (Project Manager/Electronics and Controls)
To fully simulate a soldier crawling through a barbed wire course we have to think about everything that a soldier might experience. We have to design a rover that will avoid obstacles, match the speed of a soldier, and even see what the soldier is seeing in a crawling position. We spent time researching the field of vision when a soldier is crawling and we didn’t find a lot of information on it. As a result of this we thought it would be a good idea to perform an experiment to see what our field of vision is when we are crawling.
To do this we needed to find the field of vision of a HTC Evo phone. This was done by measuring a distance away from a wall. Then marking all the edges of the frame on the wall with a marker. From this we can figure out the horizontal and vertical angles that this camera takes in a photo. We found this to be 28.5 degrees to the left of center and 28.5 degrees to the right of center. Also it had a vertical angle of 20 degrees above center and 20 degrees below center. Below is a table of the camera’s field of vision.
| Direction | Angles (In degrees) |
| Left | 28.5 |
| Right | 28.5 |
| Up | 20.2 |
| Down | 20.2 |
Figure 1: Field of Vision of a camera
Next we needed to find the field of vision of a human crawling. To do this we got into crawling position parallel to the wall. We measured the distance from our eye to the wall while looking forward and marked that position on the wall. Next we turned our head as far as it could go and focused on the farthest point we could see along the wall behind us. This gave us enough information to calculate the horizontal field of vision and found it to be 161 degrees left of center and 161 degrees right of center. Below is the horizontal angles that a person can see while crawling.
Horizontal eye angles (in crawling position)
| Direction | Angles (In degrees) |
| Left | 161.9 |
| Right | 161.9 |
We were able to do the same type of experiment for the vertical field of vision as well. In crawling position we looked ahead at the wall and measured the distance from our eye to the wall. Next we looked up along the wall and focused on the highest point we could see. This gave us enough information to calculate the highest angle we could look up and found it to be 76 degrees. Our field of visions were very similar. Below is a picture of the process we took to find the vertical field of vision.
Figure 1: Estimating the Highest point we could see in crawling position
Vertical eye angles (in crawling position) turning head
| Direction | Angles (In degrees) |
| Up | 75.74 |
| Down | 90 |
| Total | 165.74 |
Above is the vertical angles a human can see when crawling.
RoSco Fall 2015 Software Design
By Youssef Al-Shanti (Mission, Systems, and Tests)
Software Design:
The picture above is the block diagram for our software. you can see from the block diagram the big picture of how our software works. the blocks in red are the functions responsible for sending and receiving data to and from the Rosco.
RoSco Fall 2015 System Block Diagram
By Youssef Al-Shanti (Mission, Systems, and Tests)
This is our updated/ final Block diagram for Rosco. We updated it according to our final design. since we chose to go with designing our own PCB to replace the Adafruit motor shield and the bluetooth module. Also, originally we were going to go with the design of the Adafruit motor shield V2, but after research and deciding to design our own PCB we decided to go with the V1 Adafruit motor shield. This following blog post explains how we the change of motor shields affect the design. The blog can be found here.
Fall 2015 RoSco Waterproofing Servo Experiment
By: Will McKinney (Project Manager/Electronics and Control)
Experiment 1: Waterproofing Servos
The rover will be tested on December 16, 2015 in an outdoor environment. This year is an El Nino year which leaves us with a very high chance of rain on the day of test. There are three key components on our rover that need to be able to work in these conditions which are the motors, the PCB and the servos.