Spring 2016: 3DoT Spider-Bot Preliminary Research Project.

 Introduction to the 3DoT Spider team:

Omar Mouline                                 (Project Manager)

Christopher Hirunthanakorn          (Missions, Systems and Test Engineer)

Kent Hayes                                    (Electronics and Control Engineer)

Andrew Saprid                               (Manufacturing and Design Engineer)

 

Project Manager Research

By Omar Mouline

Objective:

The customer wants a feasibility demonstration of a 3DoT Board, from ArxterraTM, for a low cost, DIY project. The idea behind the 3D of Things (3DoT) is for the DIY community to construct small-scale and quick-production robots. The project must be able to perform an interactive game with other projects. The overall result must be professionally presentable (as a promotional video) for The College of Electrical Engineering and ArxterraTM. 

Level 1 Requirement:

Project Requirement:

1. The project shall be Cam-based robot that demonstrates the capability of the new 3DoT micro-controller for DIY hobbyists.
2. The 3DoT Spider project shall be a low cost project with a budget that does not exceed $79.95, which include the cost for the 3DoT Micro-controller Board, 3D printing material, PCB, battery, and other components.
3. For a Quick Production, the project has been restricted to six hours of total printing time with a 2 hours limit for each single print.
4. The competing robots shall use an on-board optical transmitter and receiving system to simulate a game of tag.
5. The orientation of the transmitter and sensors shall be parallel to ground. Since both teams are still designing the robots, the height of the sensors and transmitters is temporary set to 3 inches above ground until both teams finalize this requirement .
6. The receiving transmitter shall disable the robot when tagged three times.

Missions, Systems and Test Research:

By Christopher Hirunthanakorn

The first step of any project is to begin researching information that is useful for your role. This can be done by looking at the work done in previous projects and using the internet to search for new information. I was able to understand my role as the Missions, Systems, and Test Division engineer and what the expectations are for this project. Listed below are the results of my research, which cover the most important tasks I will have to handle.

Source Materials:

1. μSpiderbot— Project Outline & Goals | Level 1 Requirements, 2/2/16 http://arxterra.com/%CE%BCspiderbot-project-outline-goals-level-1-requirements/
2. uSpiderbot Level 2 Requirements, 2/2/16   http://arxterra.com/uspiderbot-level-2-requirements/
3. Interface Definitions, Fritzing, Schematics, PCB Layout, 2/2/16   http://arxterra.com/interface-definitions-fritzing-schematics-pcb-layout/
4. uSpiderbot Resource Reports, 2/2/16  http://arxterra.com/uspiderbot-resource-reports/
5. μSpiderBot Final Document, System Block Diagram, 2/2/16  http://arxterra.com/%CE%BCspiderbot-final-document/
6. Preliminary Design Document and Project Plan, 2/2/16 http://arxterra.com/preliminary-design-document-4/
7. Using Data Structures and Lookup Tables for Servo Motion, 2/2/16  http://arxterra.com/using-data-structures-and-lookup-tables-for-servo-motion/
8. Battery Trade Off Study, 2/2/16  http://arxterra.com/battery-trade-off-study-2/
9. Fall 2015 Final Project Document: Boris the Spider-Bot, 2/2/16 http://arxterra.com/fall-2015-final-project-document-boris-the-spider-bot/

Review of Materials:

1. This blog post described the mission objective and the level 1 requirements for the uSpiderbot that was designed during the Spring 2015 semester. It helped by providing a sense of what to expect when scaling down a previously done project.
2. This blog post covered the level 2 systems level requirements for the uSpiderbot. All of the requirements meet the criteria but they could be rewritten in a clear and precise way. For example, the requirement regarding the servo specifications show the linkage with the level 1 requirement but does a poor job in describing the verification plan for that requirement. It also helps by providing a framework for our requirements, which will be different.
3. This blog post presents the interface definitions, fritzing diagram, schematics, and PCB layout for the uSpiderbot and was useful for describing what a fritzing diagram is.
4. This blog post described how mass management, power allocation, and task management was performed for the uSpiderbot. It was helpful in providing an example of how to report resource management and showed a way for tracking task progress that I would like to use for our project.
5. This document showed the system block diagram for the uSpiderbot, which provides an example of the components that need to be included for the block diagram. It is very clear how systems interact with each other but the system block diagram for Boris the Spiderbot is better.
6. This document is the preliminary design document and project plan for Boris the Spiderbot that was designed during the Fall 2015 semester. It includes the mission objectives, requirements, system block diagram, interface diagram, and much more. It provides a great example of comprehensive and well-made requirements that meet all of the criteria. The system block diagram shown here is much better than the system block diagram of the uSpiderbot because it clearly separates the various systems into their corresponding position within the overall system. It even includes things such as their work breakdown structure and task descriptions, which makes this document a valuable starting point for our project.
7. This blog post provides a possible solution for the issue of translating the control instructions that are sent from the control application to the microcontroller. It involves creating a lookup table for the microcontroller to access when it receives a command to move from the control application. This method could also be used for our project and is worth looking further into.
8. This blog post provides an example of how to do a bad trade off study. The evaluation of the three types of batteries was done qualitatively and did not list which requirements needed to be met for the best solution. It would have been better if the requirements were listed such as mAh needed, price range, size, or weight.
9. This document provides a very structured example of the final project document. It had a format that I would like to follow where each section is clearly defined and contains all the relevant information. The only flaws with this document are the use of section titles as links to previous blog posts instead of including that information in that section, mislabeling the work of the missions, systems, and tests engineer as “Software”, and use of only links for the bottom half of the document.

Analysis of Past Requirements

Requirement Evaluation Rubric:

1. Is the requirement, Quantitative, Verifiable, and Realizable?
2. Is the requirement located at the correct level (1 – Program/Project)
3. Is the requirement response to a higher level requirement or customer’s objective (Requirement Flow Down)? Is the linkage clearly defined?
4. Does requirement provide links to source material?
5. Does the requirement move the design process forward?
6. Are equations used to calculate a requirement provided and are answers correct?
7. The requirements that are missing are the hardest to discover and will be factored into your evaluation.
8. Is language in the form of a requirement?
9. Avoid multiple requirements within a paragraph. (i.e., breakup statements that contain multiple requirements)

uSpiderbot Level 2 Requirements	Requirement Evaluation Rubric Number
	1	2	3	4	5	6	7	8	9
In order to reach 0.067 m/s, one-third the speed of the spring 14’ spider-bot. In reference to level 1 requirement, the servos will need to have a 0.225 sec/60o servo rating which means the servos will need to move a distance covered by 60 degrees in 0.225 seconds.	Y	Y/N	Y	N	Y	Y	–	N	Y
In order for Spiderbot to receive commands from the Arxterra control panel, a bluetooth module will be connected to the Arduino Micro.	Y	Y	Y	N	Y	N	–	N	Y
The micro spider-bot must be constructed from materials that will prevent it from being hazard. Avoidance of such materials will help achieve this.	N	Y	Y	N	N	N	–	Y	Y
The microcontroller needs to provide enough servo connections to control 18 servo motors. Since the Arduino Micro does not have enough pins to provide for 18 servos, 2 PWM Drivers will be used to control the servos.	Y	Y/N	Y	N	Y	N	–	N	Y
The battery used needs to provide at least 540 mAH to provide power to the spiderbot’s legs. The 540 mAH number was acquired by calculating how much current the spiderbot would drain when walking. The walking gait uses only 6 servos and each servo requires atleast 90 mA.	Y	Y/N	Y	N	Y	Y	–	Y	Y

Detailed Review of Boris the Spiderbot Level 2 Requirements

The level 2 requirements for Boris the Spiderbot meet most of the criteria of the requirements evaluation rubric. They are all written in the form of a requirement, are specific and verifiable, and provide links to source materials. There are no calculations involved with these requirements but this is because most of the requirements do not require calculations. One requirement that could have been improved would have been the requirement stating the use of a single power source. Some calculations could have been performed to determine the capacity of the power source or even type of power source. Overall, these requirements clearly define the specifications of the system that the team is building.

Boris The Spiderbot Level 2 Requirements	Requirement Evaluation Rubric Number
	1	2	3	4	5	6	7	8	9
Spider-Bot shall be able to move at least as fast as the typical crawling military enlistee, or about .5 m/s.	Y	Y	Y	Y	Y	N	–	Y	Y
Spider-Bot shall be able to clear the height of the barbed wire according to standards given by customer, between 23 to 75 cm	Y	Y	Y	Y	Y	N	–	Y	Y
Spider-Bot shall be able to be operated by an android phone app as detailed by the customer.	Y	Y	Y	Y	N	N	–	Y	Y
Spider-Bot shall be able to have a prone human’s range of vision, 180 degree horizontal and 135 degree vertical.	Y	Y	Y	Y	Y	N	–	Y	Y
Spider-bot shall be run utilizing a single power source as defined here.	N	Y	Y	Y	N	N	–	Y	Y
Spider-Bot shall be able to operate in extreme historical weather conditions for the test date, including temperatures between 36 – 86 degrees fahrenheit and up to 0.34 inches of rain per day.	Y	Y	Y	Y	Y	N	–	Y	Y

Disclaimer: Because the level 1 requirements have not been finalized, the proposed level 2 requirements may be vague. They will be updated as soon as possible.

Proposed Level 2 Systems Requirements

• The Spiderbot shall utilize the Bluetooth module on the 3DoT board in order to receive commands from the Arxterra Control Panel (via the Android App).
• The Spiderbot shall use a battery that is able to power the robot for the desired operation time.
  • For example, the desired operation time could be from 10 to 20 minutes.
• The Spiderbot shall use two motors/micro servos to perform the head rotation and walking movements of the robot.
  • For example, the indoor game could require head rotation to be limited to 180 degrees and walking speed to be at least 0.067 m/s
• The Spiderbot shall use a set of sensors and components that are required to participate in the fun indoor game against another robot.
  • For example, if the indoor game was hide and seek, the set of sensors and components could include LEDs, light sensors, infrared emitters, infrared sensors, and laser pointers.
• The Spiderbot shall incorporate 3D printed parts for the legs, body, or head. This follows from the level 1 requirement dictating the limit on 3D printing times.

Proposed Level 2 Subsystems Requirements

• WThe Spiderbot shall use a battery with a capacity of at least X mAH in order to meet the desired operation time. This value was calculated using the following equation: total current used by components * desired operation time.
• The Spiderbot shall use motors/micro servos with a rated speed of X in order to meet the desired walking speed
• The Spiderbot shall use a set of sensors and components that match the following specifications: X, Y, and Z.
  • For example, if a laser pointer was required, the specifications would define the beam width, range, fixed or dynamic movement, etc. For sensors, the location and size would be defined.

Electronics and Control Research:

By Kent Hayes

Since I am in charge of batteries, sensors, and motors I found a couple helpful links that give a brief summary for understanding various data sheets I have encountered. In addition, I will be defining possible sub system requirements.

Source Materials

1. RobotShop Website, How Do I Interperet DC Motor Specifications – http://www.robotshop.com/blog/en/how-do-i-interpret-dc-motor-specifications-3657
2. PDF from MIT Website, A Guide To Underdstanding Battery Specifications  – http://web.mit.edu/evt/summary_battery_specifications.pdf
3. Arxterra Website, Preliminary Design Document and Project Plan – https://www.arxterra.com/preliminary-design-document-4

Review of Literature

1. This is a link to a site that contains information on how to interpret DC motor specifications that I will be reading when determining the proper motors and servos for our Spider-bot. On the 3DoT board document was a list of parts of which parts the 3DoT board is most compatible. On that list were micro and ultra micro servos. I conducted a trade off study that compares four different ultra-micro servos.
2. This PDF file has info on how to read the data sheets for different batteries and chargers. It goes over the discharging rate, the max and min input/output voltages and currents. I am having a bit more difficulty doing a trade-off study that meets the requirements for our 3DoT board. This is due to the many specifications to consider while looking at the data sheets.
3. This blog post described the preliminary design document for the Spider-bot team of fall 2015. Included in this post was the electronic subsystem design. They identified the items that were being interfaced together, and created a table of the possible pin out connections to be made. However, most of their information was “TBD”, thus making it too informative for the reader.

Note: The level 2 system requirements are being worked out between our team and the customer. We will update them as soon as possible.

Proposed level 2 Sub-system requirements 

• The spiderbot will use a 650mAh battery to power all components and give an on time long enough for users to play the desired game.
• The spider will use one servo to control the movement of the head, and one dc motor to control the motion of the camshaft.

Manufacturing and Design Research:

By Andrew Saprid

I did a thorough investigation for previous spider-bots made, beginning from the fall 2013 semester to familiarize myself with my job in the manufacturing and design division. I am going to use Solid-Works to build the design of the 3Dot Spider. Here is the research I did from the Arxterra community that will help my journey in making our 3DoT Spider.

Source material:

1. Spiderbot: Initial Design: https://www.arxterra.com/spiderbot-initial-design/
2. Design – First Iteration: https://www.arxterra.com/spiderbot-initial-design/
3. How to perform a stress test: https://www.arxterra.com/how-to-perform-a-stress-test/
4. Shattered Dreams: Switching to Nylon Femurs: https://www.arxterra.com/shattered-dreams-switching-to-nylon-femurs/
5. PCB Fabrication: https://www.arxterra.com/pcb-fabrication/

Review of literature:

1. This blog describes the implementation of 6 legs for the spider-bot, instead of 8 legs, which will be cost-efficient. Having 8 legs will be expensive requiring more materials and battery power. Since the leg design had only the femur and tibia, the manufacturing engineer decided to design the leg with 3 main parts that include: the coxa, femur, and tibia in order to save money. I will be using 3 main parts that include coxa, femur, and tibia.  I will use 6 six legs, instead of 8 legs to save money. Legs will be created in Solidworks.
2. This blog addresses the issue of their two-dimensional design. The initial design the manufacturing engineer created was not convincing to the president because of its flat nature. They modified the spider-bot to three-dimensional. I will focus more on three dimensional design for our 3Dot Spider.
3. This blog addresses how to perform a stress test for the leg designs. The test was design to determine the maximum stress level of their leg design. The use of Solidworks SimulationXpress Study is to check any design and material it can handle in terms of pressure. I will use this as reference to perform a stress test for our 3Dot leg designs and materials.
4. This blog post describes what went wrong with their femur designs by using acrylic material. As a result for not listening to the president, they had to spend more money on Nylon material for the femur designs, which is expensive. The pressure of the bolt against the acrylic caused it to shatter. Nylon was the alternative, which is more resilient material. Acrylic material is off the table for our 3Dot spider, based on its sensitive nature.
5. This blog post addresses the requirement of EE400D to create a PCB for their spider-bot. The manufacturing engineer lay down the steps to fabricate the PCB. Drilling the holes on the PCB and soldering components on to the PCB were addressed into this blog post. The PCB designed by the electronics engineer will be fabricated. I may use this as reference to fabricate the PCB.

Note: Level 2 system requirements are being worked on between our team and customer

Proposed Level 2 Sub-System Requirements

• The spider will have six legs to operate its course to battle robots.
• The Spider will be lightweight by using plastic material in order to save battery power.
• The length of the legs will not be higher than the height of the spider.