Goliath Fall 2016
Preliminary Design Document
Kristen Oduca (Project Manager)
Diana Nguyen (Missions, Systems, and Test Engineer)
Sou Thao (Electronics and Control Engineer)
Dylan Hong (Design and Manufacturing Engineer)
Table of Contents
Program Objectives/Mission Profile
By Kristen Oduca (Project Manager)
Objective
The Goliath will follow the biped autonomously throughout an unknown course with obstacles, such as walls and “hills” with a six and a half degree incline. Throughout the biped’s journey, the Goliath will remain behind the biped at a fixed distance. Through an Android phone, the Goliath will provide live video feed for the biped in the Arxterra application. This was based on the game plan created by the game committee the customer’s request.
Requirements
Spring 2016 Level 1 Requirements Analysis
By Kristen Oduca (Project Manager)
The chart above analyzes if the Level 1 requirements fit the rubric of the requirements checklist. For all but one requirement, the language they used was not in the correct format. Words such as shall, will, or should can be used in order to make it in the appropriate language. They did not mention the time this project needed to be completed by.
Less than 6 hours of printing time. The previous Goliath did not mention anything about how the tracks and wheels were used in order to compensate for the amount of time the body took to print, which is a missing requirement.
Piloted via live cam on an Android phone. In the level 2 requirements they mention how they are controlling the Goliath robot via Bluetooth using an android device. They break up this requirement into two parts. This creates no real linkage. Since there is no linkage, it does not really move the design process forward. It does mention the camera, however it does not mention how this camera will be used for the laser tag game. This requirement could have been combined with the level 2 requirement in order to produce one statement.
Controlled by the 3DOT board. The previous semester conducted a test to show how the Arxterra application connected to the Bluetooth using the 3Dot board. In order to demonstrate how the 3Dot board was truly the micro-controller, they created a chart that stated whether or not the robot was functioning as it should. However, this verification is not a valid test. No numbers or equations or pictures were provided to show the Goliath was working.
Looks cool and inspired by the Goliath. Looking cool cannot be quantitative and verifiable. They tried to prove it by saying it would be compact, but this does not provide a legitimate equation to how it could look cool. In the requirements, the dimensions of the Goliath were not mentioned. However, they said that their Goliath was inspired by the original Goliath because it is scaled in a similiar ratio. They said they followed a ratio in the validation, but it was not a requirement.
Periscope on an Android phone degree with the x-axis. This does not branch down to level 2 requirements. There were no equations to prove that this was correct. Missing from this requirement is how the phone shall be placed in order to use the periscope.
Fall 2016 Level 1 Requirements
By Kristen Oduca (Project Manager)
Based on the previous semester, one of the changes that should be made is the budget. Their goal was to not exceed the price of $80, but they spent $111.78 without the 3Dot board. After roughly researching the prices of the items that would be needed to make a Goliath autonomous would be $125. This leaves wiggle room for other necessities. However, this still needs to be approved by the customer. Some potential requirements that are based off our new objective are
- The budget should not exceed $125. (Based on previous semesters budgets this still needs to be approved)
- The Goliath robot should be completed by Thursday, December 15.
- All aspects of the Goliath robot should be printed under six hours. (Based on the customer’s request and Spring 2016 Goliath)
- Goliath should be able to travel around all areas of the course. (Based on the game objective)
- The Goliath shall follow the Biped autonomously. (Based on the game objective)
- The Goliath should look like the Goliath 302. (Based on the customer’s request)
- The Goliath shall use a Galaxy s6 to produce a live video feed for the Biped that shall be viewed in the Arxterra Control Panel on cp.arxterra.com. (Based on the game objective)
- All electrical components within the Goliath shall be connected to the 3Dot board. (Based on the game objective)
- The Goliath shall be able to fit in Professor Hill’s cabinet. (Based on the customer’s request)
Source Material
- https://www.google.com/search?q=distance+sensors&oq=distance+sensors&aqs=chrome..69i57j69i60l2j69i65j69i59l2.2143j0j4&sourceid=chrome&ie=UTF-8
- http://arxterra.com/spring-2016-3dot-goliath-final-project-document/
- https://docs.google.com/document/d/1LqDI9S5xJGxpAQUizGwnSxbU4afXyOJFsW7KdwqQuAA/edit?usp=sharing
Spring 2016 Level 2 Requirements Analysis
By Diana Nguyen (Missions, Systems, and Test Engineer)
- The rover will be controlled by two individual DC motors (3-5V). There is no linkage to a level one requirement for this requirement. This requirement would have been better suited as a subsystem requirement instead of a level 2.
- Battery duration should last to the whole period of the battle 15 minutes. This requirement lacks a link that states or references the game rules and duration of the game. In addition there should have been some calculation to how much voltage the battery should have or an estimation.
- Print parts of rover individually. It does not state how many parts can be printed individually therefore it is not quantitative. This can be fixed by stating an estimate of the number of parts will be 3D printed.
Fall 2016 Level 2 Requirements
By Diana Nguyen (Missions, Systems, and Test Engineer)
After analyzing last semester’s Goliath we need to make sure that there are links and references to where we are getting our requirement information from. In addition, we made sure to write some subsystem requirements for electronic and manufacturing divisions. Based off of that we came up with potential level 2 requirements for this years Goliath.
- Each component being 3D printed should be less than two hours each. (Based off Customer Request and Spring 2016 Goliath)
- The Goliath should be able to go up a 6.5 degree incline. (Based on the game objective)
- The Goliath shall be at most ½ meter away from the biped. (Is dependent on the biped’s need for the field of vision) (Based on the game objective)
- The Goliath should have an approximate ratio of 1 : 0.566 : 0.373 (Length: Width: Height) (Based on the Goliath 302)
- The Goliath shall have the biped in it’s the field of vision (Based on the game objective)
- The Galaxy s6 shall connect to the Bluetooth module on the 3Dot Board (Based on Customer Request)
- A battery shall be used to operate the 3Dot Board (Based on the schematics of a 3Dot Board)
- All components including the smartphone, motors, PCB board, and 3DOT board shall be tightly fitted and housed in the body of the Goliath. (Based on customer’s request)
- All components need to be accessible and functional. (Based on the previous semester)
- The two motors shall be controlled by 3DoT board via the TB6612FNG Dual Motor Drive. (Based on the schematics of a 3Dot Board)
- The sensors and PCB shall be interfaced with the ATmega32U4 through the I2C of the 3DoT board. (Based on the schematics of a 3Dot Board)
Spring 2016 Level 2 Electronic Sub-Requirements Analysis
By Sou Thao (Electronics and Control Engineer)
- For the previous semester’s electronic and control level 2 subsystem requirements, they wanted a single charge of a battery to power the two DC motors, the camera, and the laser and sensors. This requirement fell under the level 2 requirement of having to make the battery last the whole game play, which was 15 minutes. However, the word “must” should be replaced with “shall” to form a requirement. There was no indication of why a laser was included in the requirement, and the system block diagram excluded the laser. Also, there was no mention about the piezo speaker used for the design, and the speaker was included in the final system block diagram.
- While going through the PDD from the previous semester’s Goliath project, it was noted that there was a size requirement (≤1”) for a design. However, this requirement could not be traced back to any of the level 1 and 2 requirements and there are no answers as to what this design was.
Source Material
Fall 2016 Level 2 Electronic Sub-Requirements
By Sou Thao (Electronics and Control Engineer)
Based on the previous semester, the laser tag game failed because the sensors and speaker operated on 3.3V, not 5V from the VCC source coming through the I2C. This semester, a boost converter should be taken into consideration if the sensors require 5V. Also, because the mission objective has changed from the previous semester, a new set of electronic and control level 2 subsystem requirements should be implemented which includes:
- The Goliath shall use two DC motors to control the wheels (Based on the simple robot)
- The motor shall not consume more than 500mA and 5V (Based on customer’s request)
- The Goliath should use tracking sensors (Based on the game objective)
- The Goliath should go the same speed as the biped (Based on the game objective)
- The battery duration shall last up to 30 minutes (Based on the game objective)
- The battery in the 3DoT board shall be rechargeable (Based on the schematics of a 3Dot Board)
Spring 2016 Level 2 Manufacturing Sub-Requirements Analysis
By Dylan Hong (Manufacturing and Design Engineer)
The requirement of having the 3Dot Goliath to mimic the actual German Goliath tank is verifiable and realizable but not quantitative. It is not quantitative because the requirement is too broad and needs to be more specific to be on a subsystem level. It is verifiable because it relates to a level 1 project requirement, but not a level 2 system requirements. The team did not provide source material on how to mimic the German Goliath and why it does not need to pan-tilt.
The placement of the periscope does not link to any level 1 or 2 requirements, which leads to no progress. Also, the use of language does not meet the requirement material.
The skeletonize of the body of Goliath for reducing the weight had great potential for being a subsystem requirement, but the language form was incorrect.
Fall 2016 Level 2 Manufacturing Sub-Requirements
By Dylan Hong (Manufacturing and Design Engineer)
According to previous semester’s Goliath project, the group was unable to make their Goliath look similar to an actual Goliath. Now for our project, the customer emphasized on changing the design of the Goliath to be more compact and to look more like the actual Goliath. To achieve this goal, the potential subsystem for design is listed below:
- The Goliath should have all the grooves and contours of the actual Goliath 302 tank. This includes doors and hinges. (Based on customer’s request and the Goliath 302 tank )
- The Goliath should have no openings on the bottom, side, and top surfaces of the body besides the doors. (Based on customer’s request and the the Goliath 302 tank)
- The whole Goliath should have a total of two gears on the front, two driving wheels in the rear side, and fourteen wheels in the center. (Based on customer’s request and the Goliath 302 tank)
- The phone shall be laid flat down with the camera facing upwards and horizontally in parallel with the top part of the body. (Based on customer’s request and previous semester)
- The smartphone’s camera will incorporate a universal periscope with the dimensions of 2 x 1.6 x 1.2. The mirror of periscope should have a 90 degree turning lens. (Based on customer’s request and previous semester)
- The Goliath will incorporate a hinge between the top and bottom portion of the body. This will allow easier access to the components in regards to potential modifications, installations and troubleshooting of the components. (Based on customer’s request and previous semester)
- Not a requirement but a statement: The Goliath should sport a similar tread design for the tracks to the actual Goliath. (Based on customer’s request)
Design Innovation
Creative Solutions
By Kristen Oduca (Project Manager)
In the Spring 2016 Goliath, their robot took too long to print and did not really look similiar to the Goliath tank. Brainstorming, attribute listing, and forced noun generator helped us solve that problem [2]. After doing some creative exercises, we came to the conclusion that 3D printing the tracks or buying them would be the best options in order to make it look very similiar to the Goliath 302. There is a possibility of 3D printing the body also, but a simulation has to be done to see if it fits within the time frame of printing under 6 hours. The Goliath also needed to be as compact as possible. In the noun generator, the idea of having Goliath like a townhouse helped us solve that task. We can create a two leveled interior in order to have one place for the custom I2C shield and the 3Dot board.
Another issue we had was discovering a task for Goliath’s I2C shield. Using the Dunker Diagram and brain writing [2], we thought of the idea of making Goliath autonomous and changing the game. After talking to other project mangers involved in the game, the game was changed thus Goliath’s objective was changed. This problem was resolved.
Systems/Subsystem Deisgn
Project Breakdown Structure
By Diana Nguyen (Missions, Systems, and Test Engineer)
Product Breakdown Structure (PBS) is an outline of the product broken down into different systems. The systems can be hardware, software, or informational items. The Goliath is broken down into battery, camera, mobility, and the 3Dot board. The battery will provide power for all of the systems. The camera system will encompass a Galaxy S6 with a periscope attached. The components that contribute to the movement of Goliath are its motors, gears, and tracks. Lastly, the 3Dot microcontroller will be reading the inputs of the follower sensors and providing a Bluetooth transceiver to connect to Arxterra.
Electronic System Design
System Block Diagrams
By Diana Nguyen (Missions, Systems, and Test Engineer)
The system block diagram illustrate how the components of the Goliath communicate and interlink with each other. The new 3Dot board has a built in Bluetooth transceiver which eliminates the need to have a Bluetooth module. Using the Bluetooth transceiver we connect the Galaxy S6 to the 3Dot board which will allow us to provide a live feed while the phone is on Goliath. Also built into the 3Dot micro-controller is a rechargeable battery which powers to the board and all the components connected to it.
Interface Definition
By Diana Nguyen (Missions, Systems, and Test Engineer)
The interface matrix shows how each subsystem will be connected to the ATmeg 32u4 which is located on the 3Dot board.
Mechanical Design
By Dylan Hong (Design and Manufacturing Engineer)
According to the customer, the 3Dot Goliath tank must replicate the actual 302 German Goliath Tracked Mine as much as possible in terms of mechanical design. This preliminary 3D model of Goliath was created with Solidworks. By researching the 302 Goliath tank, I was able to create four individual parts: the top, bottom, and the two sides to assemble it in a way that replicated the actual product. The inside of the body is hollow and is made to fit the smartphone, motors, PCB board, 3Dot board, and the battery. [1]
As for the dimensions of the Goliath, the previous semester modeled the body with dimensions of 7.375 x 5.125 x 3.44 inches, which was disproportionate to the actual Goliath. Upon research, we found that the actual specification for the dimensions of the actual Goliath came out to be a ratio of 1: 0.566: 0.373. Our Goliath is currently modeled at 7.33 x 5.13 x 2.5, which is approximately closer to the actual ratio than the previous model. The only outlier from our dimensions was that the width has a difference of about an inch from the actual model because we have to compromise the width of the Galaxy S6 smartphone, which has dimensions of 5.65 x 2.78 x 0.27 inches.[3]
Design and Unique Task Descriptions
Spring 2016 Goliath Motor Trade Off Study Analysis
By Sou Thao (Electronics and Control Engineer)
A motor trade off study was conducted to compare the specifications of a GM9 or a DG01D DC motor. From the results, the DG01D motor was more suitable for the 800 gram Goliath tank, and required less power to run. However, there is no indication as to which motor was selected, and how they narrowed down their search to these two motors. In contrary to the trade off study, the motor used does not look like the GM9 nor the DG01D. Through observation, the motor used on the final Goliath seemed to be a Tamiya Twin-Motor Gearbox RB-Tam-01. Also, by manually testing the speed of the Goliath, it was able to pass 4 feet in 38 seconds. Thus, the speed was calculated to be 1.26in/sec or 3.2cm/sec. As a result, by analyzing the speed of the Goliath and this trade off study, a new study should be performed to fully understand the specifications of a DC motor, and how to choose the correct motor.
Fall 2016 Goliath Tasks Electronics
By Sou Thao (Electronics and Control Engineer)
- Perform trade off study on follower sensors: find the pros and cons of each sensor
- Select the best sensor based on trade off study
- Perform test on breadboard to verify sensors are working correctly
- Perform trade off study on choosing the right DC motor for Goliath
- Choose a DC motor based on analysis of speed, torque, current, and voltage levels
- Perform control tests on DC motor through Arduino IDE
- Integrate sensors and DC motor onto breadboard for test and validation
- Create Fritzing diagram required for PCB
- Program 3DoT Board to control motors based on feedback of sensors to automate Goliath’s movement
- Assist Systems engineer with interfacing the phone’s camera on the bluetooth module to provide live video feed
Fall 2016 Goliath Tasks Manufacturing
By Dylan Hong (Manufacturing and Design Engineer)
According to their Preliminary Design Documentation blog post, the previous semester initially sketched a design on Solidworks and showcased the body of the Goliath with closed surfaces. The group decided to remove the box panel that would be connected to the side panel to decrease volume.
Furthermore, in the Body Redesign blog post, the team gradually updated their strawman sketch to a design that would meet requirements that included a 3D print time under six hours, a scaled model of the Goliath tank, and the fitting of all components within the Goliath. As for the materials used, 3D printing was the only medium considered in designing the Goliath, which resulted in the requirement of printing a total maximum time of six hours, with each part printing at a maximum of two hours. The requirement of a print time less than six hours greatly limited their ability to make their goliath a complete replication of the actual demolition vehicle. Their overall chassis design resulted in changing the desired closed surface of the body to an open surface with trusses on all faces of the body. Also, they opted for prefabricated wheels and tracks to further reduce their use of 3D printing. The design change with the 3D print setting of 25% density allowed them to reach their requirement at 5 hours and 57 minutes.
Overall, the team was able to meet two out of the three requirements with a print time of five hours and 57 minutes while fitting all the components in the body, but failed to have a scaled model of the Goliath tank.
With the failure of the scaled model requirement, the team’s total dimensions came out to be about 7.38 x 5.13 x 3.44 inches and weighed 437 grams. In comparison, the actual Goliath model had dimensions of 1.5 x 0.85 x 0.56 meters (59.06 x 33.46 x 22.05 inches) and weighed 370 kg. To determine if their Goliath met the requirement, we calculated the ratio of the actual dimensions:
In conclusion, the ratio calculations allowed us to confirm that the actual spring 2016 Goliath model did not reach the ideal scaling of 7.38 x 4.13 x 2.73 inches and had a difference of 0 x 1.17 x 0.71 inches with a percent error of 0 x 24.21 x 26 %. The smartphone, Samsung Galaxy S4 (5.38 x 2.75 x 0.31 in.) played a factor in off scaling the dimensions because it had to be incorporated within the Goliath’s body design to produce a live video feed. In conjunction, the overall dimensions were able to house the components of the phone, 3DOT board, PCB board, battery and the motors.
Spring 2016 Goliath 3D Printing Simulation Analysis
By Dylan Hong (Manufacturing and Design Engineer)
- Continue to add other important parts such as the wheels, gears, tracks, and doors to the assembly of the 3D model in Solidworks
- Perform a tradeoff study between 3D printing, laser cutting, and vacuum forming to find out which material is best to work with. For instance, if we plan on 3D printing would we be able meet our print time requirement of six hours?
- Perform a tradeoff study between different periscopes
- Measure the overall weight of Goliath and inspect that the potential material is good enough withstand it while in motion.
- Cooperate with the Electronics Engineer and discuss PCB layout and assembly