All Rovers – Page 10

Spring 2016 3-DoT Goliath Research and Intro

February 10, 2016/in 3DoT Goliath, All Rovers, Goliath Generation #1, Members and Communities/by refaas0a

Ayman Aljohani (Project Manager)

Tae Lee (Mission Systems & Test)

Kevin Moran (Electronics & Controls)

Rickeisha Brown (Manufacturing Division)

Jerry Lui (Manufacturing Division)

By: Ayman Aljohani (Project Manager):

The 3-Dot Goliath is a new project that will be working with a new board referred to as the 3- Dot board.

As a project manager, I will be responsible of my team’s final product, and making sure it meets the customer’s requirements (level 1 requirements) which are:

low-cost ( $ 90 total)
less 3D- printing time ( 6 hr maximum),small size Goliath look.
successfully compete in a laser-tag (optical transmission device)battle with 3-DOT Spider project.
sensor placed horizontally on the rover with zero degree along x-axis,located at a height of 3 inches above the ground.
When getting tagged three times, the rover should be disabled.
the rover should be piloted via a live camera view only.
looks of the RoSco has to be cool

From researching past projects, we have our preliminary budget as follows:

Tracks and wheels – $17.33

Motors – $11.50

Chassis- $5.07

ABS plastic- $ 18 (1 Kg)

PCB -$10

3DOT board-$30

Periscope- $6.89

Total cost: $ 98.79

I also conduct weekly meetings to followup on weekly actions.

Documentation is very important part of my assignment as PM.

2-minutes video for our project as a marketing tool, is also required from a project manager.

In order to meet those requirements, I have developed a work breakdown structure (WBS) where the the work is broken down into tasks assigned to each division with a deadline.

A prototype version of the project is schedule to be tested on week 5 of the semester.

A research on sensors in terms of (field of view, cost, safety, and interference from outside source) will be assigned to Systems engineer .Based on the research results, the type of sensor will be determined to be one of the following:

IR – LED – Laser – Ultrasonic

The research should focus on four main aspects:

cost
field of view
safety
interference from another external source i.e lights of the room, distance

The research will be joined efforts with our opponent robot team (3DOT Spider).

One important decision should be made as soon as possible is the type of communication devise used in laser-tag battle.

Source materials:

By: Tae Lee (Mission Systems & Test) :

Source Material:

Battery Comparison,NiCd vs NiMH vs. LiPo Battery Packs, 12-04-13,https://www.arxterra.com/battery-comparisons/
System and Subsystem Requirements, Level 2 and Level 3 Requirements, 10-31-2013 https://www.arxterra.com/system-and-subsystem-requirements/
I.Y. Laser Tag Electronics, Head, 2003, Sensors, http://www.lasertagparts.com/mtsensors.htm
Project Summary, Major Project Features, 12-20-2013, https://www.arxterra.com/project-summary/
Robot Block Diagram, http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/04%20Robot%20Block%20Diagram.pdf
How to Make a Fritzing Diagram, 12-28-2014, http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/08%20How%20To%20Make%20Fritzing%20Diagram.pdf
What is Arduino?, Fall 2015, http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/02%20Intro%20to%20Arduino.pdf

Introduction

The 3D Dot Rosco is a new project that will require a little bit of research. We will be working with a new board referred to as the 3D Dot board.

Some of my responsibilities are performing

Verification and validation
Creating level 1 requirements
Creating the product breakdown structure.
Able to integrate everything together to create a product that meets the customer’s expectations.
Power Distribution
Testing of servos, motors, and sensors

From researching past projects I have noticed they used the Arduino board, Arduino motor shield, and a Bluetooth module that will be used to program a rover to do various tasks [7]. However, the new 3D dot board now incorporates all the hardware into a single board that will be used to control and perform various tasks on the rover. The 3D dot has dimensions 1.38 x 1.73 inches making it portable and convenient when printing 3D parts for the RoSco. Using the Arduino programming language (C++) we will then code and test the servo, motor, control panel, and the Bluetooth module[7].

Review of Literature:

Trade Off Studies of Batteries Review:

The blog post provided information on the research to determine which types of batteries will be suitable for the rover.

Notes for Requirements:

The research that was conducted on the type of batteries seemed unnecessary. This section should be replaced with a tradeoff study on the uses of different batteries. The group provided with informative information on the characteristics of the battery. However, it is more important to provide calculations to determine which battery will last longer for the rover. This requirement of comparing batteries does not contribute with moving the design forward. It would be better to narrow down a few batteries and documenting the amount of current that can be produced by the battery. Next step will to determine the milliampere-hour by adding up all the currents drained from each device to determine the total current. By doing this we can than calculate an approximate value of how long the rover will last by multiplying the total current with the desired operation time [1].

Level 2 and Level Requirements Review:

The rover team provided a good understanding of the level 2 requirements before building the product. They performed research on the terrain for obstacles and the distance that is needed to travel to fulfill the requirement. This included simple calculations to approximate the distance that was needed to travel. In addition, provided information and calculation of determining the required speed of .05 m/s. The next requirement was to determine a battery that will be used on the rover to last 20 minutes. Performing a simple calculation, they were able to determine the type of battery needed (890mAh) [2].

Note on Level 2 Requirements:

A recommendation to improving the blog is to combine the level 2 and level 3 requirements. An example of this is when they discussed the Power and the Power Storage. These sections are closely related and should be combined to make it clear to the reader of choosing the battery that will be used on the rover [2].

I agree with most of the level 2 requirements; however, the power storage will be modified because of the various components that will be used on the rover. The rover will be using a Bluetooth module, 3D Dot Board, laser, laser sensor, and two motors. This will require different type of battery that will power these components. In addition, the speed requirement will be changed by the customer needs.

Laser Communication Device:

We need to implement a sensor that is able to receive a certain wavelength from a laser. Once the laser hits the sensor it will send a signal to an LED or a buzzer to indicate we got hit by the enemy. The laser and the sensor will be connected to the 3D dot board and controlled by a wireless controller. This field will be further researched to be implemented on our rover [3].

New Requirements:

Battle with spider bot
Control methods (ex. Bluetooth, Axterra, or Both)
Sound indicator (ex. Detect when hit or firing)
Have fun

System Block Diagram:

The systems engineer provided a satisfying block diagram that shows the electrical interface of the rover. This includes the connections for the motor, illuminator, pan & tilt motor, and other components powered by the battery. We will be able to apply a similar block diagram with a few changes to help us create the new rover [4]. These changes include the laser, laser sensor, and the 3D Dot board.

By : Kevin Moran (Electronics & Controls):

Sources material :

Double Gearbox Motor

https://www.tamiyausa.com/items/geniuseries-educational-kits-50/educational-construction-38000/double-gearbox-70168

For more info on batteries

http://batteryuniversity.com/learn/article/understanding_lithium_ion

Level 2 Requirements: (Based on requirement to make a “low budget” and “cool” rover)

Motor selection

In this year’s project we will be using the 3DoT board which comes with a motor shield and a voltage booster from 3.5V to 5V to control the motor speed. I will be testing the board to ensure it meets the requirements to power the rover. The motors should not exceed a combined force of 5V since that is the board’s limitations

Battery Life

In order to meet the level one requirements for a game of laser tag, the length of the game must be decided in order to ensure the batteries chosen for the task of powering the rover last until the end of the game. The selection of the batteries will depend on their mAh, their discharge rate, and size. Since our rover is the next generation and because of level 1 requirements, we must ensure it fits in the overall design of rover.

Laser Tag Game

Level 1 requires that a game of laser tag be played between the Rosco team and the Spider bot. The length of the match is still to be determined. Lasers will not be allowed in this laser tag game. An LED will be used in its place. In order to be able to hit a target, the LED must be focused on the objective.

Rover from previous generations:

In order to build a next generation rover, I read the documentation on previous projects, trying to learn from their successes but also their mistakes. To demonstrate the effectiveness of the 3DoT board, our rover must exceed previous expectations and results. Below are a few of the experiments done by previous groups.

Waterproofing Servo Experiment

In order to ensure the survival of the rover through its respective test course, the team needed to waterproof their servos to ensure full functionality in wet conditions, and completion of the required task. They enclosed the PCB in waterproof box. They had to spray the servos with plastic dip and submerged them under water for thirty seconds in order to prove they were safe to work in wet conditions. The only problem I see with this way of waterproofing is in the long run of the project. For our specific project we will not be able to waterproof this way, for we are not using servos. However, since we are using a prototype 3DoT board we need to be extra careful to protect from any outside interference, such as a single drop of water. All of our circuitry must be inside the rover and protected by our 3D printed rover.

Field of Vision Experiment

In order to fully simulate a soldier crawling through a barbed wire course, the designed their rover to avoid obstacles, to match the speed of a soldier, and visualize what a soldier sees in the crawling position. They tried to find the information on the internet but were not successful, so they decided to perform an experiment on field of vision. They needed the field of vision of a HTC Evo phone.

Power Budget:

The majority of the power was used by 6 different servos and 4 different motors. They needed to know the current the rover uses in order to figure out if their batteries were enough to complete the task. They were given batteries with 700mAH capacity, 7.2V batteries were used on previous semesters. By building their prototype, they were able to determine the exact current their rover would use when it was operational. They discovered that their batteries allowed them to run their rover for 40 minutes. For our project I need to determine how much power the laser will use, and for how long our game of laser tag will last. I need to ensure sufficient battery life for the motors and the laser circuitry. Since it is our first time using the 3DoT board, I will also need to run experiments and seeing how it functions and if it uses up much battery life to function since it’s such a compact design

New Ideas to meet level 1 requirements

Since the rover has been done by previous teams before using the Arduino plus a motor shield along with other components, in order to make our project a new generation we must improve on previous models. However, we must be realistic, we will not be reinventing the motor or the batteries used for the rover. Our focus will be to improve on previously known data. We will choose a similar motor and batteries but according to our 3DoT board, to ensure full cooperation amongst the subsystems. Below are some ideas to meet the level 1 requirements

Motor
We will research if 2 separate motors, or a single double-gearbox motor with individual control for the sides works best with the 3DoT board. The location of where the motor is placed will also play an important role, as it will allow for maximum torque and efficiency
Battery Life
Since the 3DoT board has a place for a lithium battery, we will research and see if a battery that can fit there can meet all of our requirements. Such as the voltage, the amperage needed during a certain amount of time, and the discharge and charging rates. Since our goal is to reduce costs by reducing the size, it would be ideal to just have 1 set of batteries. We must also figure out a way to charge the battery once it is already in place. I have thought of creating a USB adaptor and placing it on the side of the rover to recharge the batteries as needed. We must also be able to determine the charge of the battery at any given moment.
Laser Tag Game
In order to ensure a successful game of laser tag, I have suggested adding the “laser” to the pen tilt that will be holding the phone and the periscope. The point of any game is to try and have a good time (usually by winning). If we are able to have the laser point in the direction of the center of the periscope, we can potentially be able to target the other team by moving the pen tilt until their sensors are in our sights. This will meet the level 1 requirements by reducing the amount of single moving parts, and allowing our team a successful game of laser tag.
Crazy Idea
Since our point is to demonstrate the ability of the 3DoT board to power a rover by itself, I have suggested trying to take that a step further. If we were to be able to have two android devices control the rover simultaneously, our rover will be very successful. Person 1 would control the movements of the rover and speed, while person 2 will be control the pen tilt and trying to hit the laser sensors. Both persons would have access to the camera on their devices.

By: Rickeisha Brown (Manufacturing Division):

Source Material :

Rosco Fall 2015 Custom PCB Manufacturing, Pg. 1, December 19, 2015, https://www.arxterra.com/rosco-custom-pcb-manufacturing/
RoSco Budget, Pg. 1, October 11, 2015, https://www.arxterra.com/rosco-budget/
Micro Rover Design Manufacturing, Pg. 1, May 12, 2015, https://www.arxterra.com/micro-rover-design-manufacturing/
Micro Rover Final Design and Dimensions, Pg.1, May 12, 2015, https://www.arxterra.com/micro-rover-final-design-and-dimensions/
Micro Rover Final Eagle Schematic, Pg. 1, May 4, 2015, https://www.arxterra.com/micro-rover-final-eagle-schematic/
MyBot, Pg. 11-13, http://web.csulb.edu/~hill/ee400d/Project%20Folder/Robots%20and%20Drones/Track%20Rover/Track%20Robot%20S’12/Tracked%20Robot%20PDR.pdf

Manufacturing our rover incorporates the actual publishing and printing of the PCB board, soldering IC components and other necessary components to the IC board, along with designing 3D structure components. We will use Eagle Cad to draft our design of circuit boards, create a Gerber file and place an order with a PCB manufacturing company of the Manufacturing Division Manager’s choice. It is vital that we confirm with systems and controls a final PCB board design before moving forward with Eagle Cad and Gerber files prior to printing. It is our goal to utilize production time effectively for adequate testing time.

As stated, we are responsible for the 3D design of rover components on a computer software that allows us to do so. For the sake of time ease and access, our manufacturing team will use SolidWorks. SolidWorks will allow us to draft all parts required to manufacture our rover including: the chassis, gears, battery holder and shell.

The customer requests that our manufacturing team design a rover which mimics the German Rover Goliath. The German Rover Goliath has a distinct height and length ratio, such as 1:3. However, the most recent rover designs are replicas of Mars Rover and/or NASA’s Curiosity Rover, which have a height/length ratio of 3:1. Goliaths requirements:

Lower Cost (comparison to recent RoSco specs)
Minimizing use of 3D-printing
Smaller/Compact design
Smaller PCB
3D Printing Time: 6 hrs.
- Chassis
  - Dimensions: 7.69×4.69×3.19
- Miscellaneous bolts (prints provided by Division Manager: Kevin L.)
Goliath Replica
- Tracks & wheel design
- Chassis-body structure includes phone, PCB & 3 Dot wiring components
- One level structure: no neck attached to pen tilt
- Pen Tilt replaced Periscope
- Range of view: Dependent on periscope specs-90 degree angle turns

Estimated total weight of Goliath Rover: 1.88-2.00 lbs

The manufacturing division will be responsible for the generation of an Eagle Cad design of the PCB Board, a 3D model of our Rover design using SolidWorks, & the calculation of material and supply needed to build the desired design.

By: Jerry Lui (Manufacturing Division):

Sources materials:

http://www.toybuilderlabs.com/blogs/news/13053117-filament-volume-and-length

http://www.amazon.com/gp/product/B001VZJDY2?refRID=BT3DN2GHRMF7CEJ988CY&ref_=pd_ybh_a_4

Level 2 subsystem requirement

Chassis material has to be light weight (at least under 1.63lbs)

Based on the previous Rosco project, the prime material to use for 3D printing would be ABS.
The overall weight must at least be less than the previous teams Rosco chassis weight of 1.63lbs.

The overall cost has to be low (<$80)

As per customer suggestions 3D printing should be used. This will cut down on costs.
ABS is priced, on average, $20 per kg or $9.07 per pound which can significantly reduce weight compared to PLA.

A game has to be implemented in conjunction with the 3Dot Spider-bot team

A led has been suggested to replace the original laser tag system as per customer request.

The Rover must be similar to the german Goliath ROV

A prefabricated, commercial track has been proposed to meet the customer objective of having a wheel-tracked system.

Suggestions

The body of the old Rosco was fairly bulky which accounted for the majority of the 3.25lbs. A more skeletonized body was proposed to help minimize the weight, speed up printing time, reduce costs, and to make it look aesthetically pleasing as per customer objectives.
The reduced weight of the body will also minimize the strain on the motor(s), and tracks thus increasing product longevity.

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

February 10, 2016/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #6/by Omar mouline

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)

Table of Contents

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:

Program requirement:

As a senior design project for Spring 2016, the project shall be completed by May 13th, 2016 Monday, May 9, 2016 2:45PM – 4:45PM (Final day) on the linoleum floor of ECS315 at CSULB.http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html
As a senior design project for Spring 2016, Documentation of the 3Dot Spider-bot shall be completed by the 25th of April http://web.csulb.edu/~hill/ee400d/Syllabus.pdf

Project Requirement:

The project shall be Cam-based robot that demonstrates the capability of the new 3DoT micro-controller for DIY hobbyists.
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.
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.
The competing robots shall use an on-board optical transmitter and receiving system to simulate a game of tag.
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 .
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:

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

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

Is the requirement, Quantitative, Verifiable, and Realizable?
Is the requirement located at the correct level (1 – Program/Project)
Is the requirement response to a higher level requirement or customer’s objective (Requirement Flow Down)? Is the linkage clearly defined?
Does requirement provide links to source material?
Does the requirement move the design process forward?
Are equations used to calculate a requirement provided and are answers correct?
The requirements that are missing are the hardest to discover and will be factored into your evaluation.
Is language in the form of a requirement?
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

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

Review of Literature

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

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

Review of literature:

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

Final Project Document

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
Matthew Clegg – Computer & Control Systems
Simon Abatay – 3D Modeling & Manufacturing

Before signing off with the final document for Spiderbot, we would like to thank various members of the Robot Company in aiding with the completion of Spiderbot:

First off, we would like to thank David Gonzalez of last semester’s Hexapod project for his loan of Chop Suey for preliminary code practice.

We would like to thank Ali Etezadkhah of 3D Bioprinter and division manager of manufacturing, for allowing us use of his 3D printer for the class and for printing Spiderbot’s pieces in a timely fashion.

We would also like to thank Tommy Sanches of MC3 for his immense help in getting Spiderbot connected to Arxterra.

We would like to thank Elaine Doan of Biped for helping run tests and for guiding Spiderbot in the writing of requirements.

Finally, we would like to thank Vice President (Dr.) Larry Harmon for all of his hard work in posting countless blogs and grading presentations, despite his busy schedule.

THANKS!

A pdf file of the final document of Spiderbot can be downloaded here:

https://dl.dropboxusercontent.com/u/184627659/EE%20400D_Spiderbot_CDD.pdf

This is Project Spiderbot signing out.

Live Long and Prosper!

Spiderbot: Struggles Remembered and Suggestions

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
Matthew Clegg – Computer & Control Systems
Simon Abatay – 3D Printing & Manufacturing

Following the mass lay-off of all members of the Robot Company for Spring 2014, we remember the numerous struggles faced by Spiderbot with the following video:

http://youtu.be/1e-2mCIpM-Y

Many improvements can be done to make future Spiderbots better machines.

For one thing, connection of Spiderbot to the Arxterra Android App can definitely be helped by possibly finding a forest-like route in a different location on campus. Many issues occurred on demonstration day during the race against Rover and Hexapod. Connection was constantly dropped when multiple projects were connected to the app in the particular race course area and perhaps a location with better wifi connection might remedy that issue.

A route with a more even terrain might be helpful in preventing damage to the gears of the servo motors, as was done with one of the servos from a rear leg of Spiderbot.

A convenient trick we learned from Tien Dang, Communications member of Hexapod, was that if, when taken apart, the servo motor shows gear damage, then the motor can easily be fixed by replacing the gear, which can most likely be purchased online. This is much cheaper than purchasing a whole new servo motor.

The damage was most likely done when testing Spiderbot in the race location prior to the race, when it encountered the various branches of the course.

As for manufacturing, the individual pieces can be improved to help Spiderbot’s overall performance. For one thing, the tibia side portions of Spiderbot’s tibia pieces can be shaved down. The pieces were extended mostly for aesthetics, so if they were shaved down to the same width as the servo motors in their particular orientation, then they should function just the same and be lighter in weight in the long run.

The base of Spiderbot was ultimately very dense, causing the stance of Spiderbot to be higher than it should have been in order to support the entire piece. A wider base most likely would have allowed for a lower position and therefore, a faster sweep of the legs. Research regarding a possible ratio between the base width and leg length should be done to achieve a faster speed.

In regards to the connections of the bracket pieces, the tibia pieces were molded in a manner that made it difficult for the screws to easily tread and lock into them. Because of this, epoxy was initially used, but after testing in the grass, it proved to be too weak of an adhesive. Loctite is recommended as a better adhesive alternative to insure secure connection. That, and testing in terrains aside from grass, since the grass most likely caused some wear and tear in the servo motors from the legs getting stuck.

Purchasing stronger servos would be a good alternative to increase the speed as well, but will ultimately rack up the cost of the final project. Another thing to keep in mind in regards to cost is that creating a mold to cast 3D pieces will require a lot of material, so the initial starting price for this project is already projected to be a couple hundred dollars, so mold and cast wisely.

Good luck to all future Robot Company Projects!

Spiderbot: The Final Video

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager

With the demonstration of all projects having wrapped up, the final video for Spiderbot, created by yours truly, has dropped! The video can be viewed after clicking the following link:

http://youtu.be/5wJuN8XxtVk

Enjoy!

Project Burndown and Overview

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager

The following image displays the final overview of Spiderbot:

Due to the incomplete state of some of the tasks originally assigned, Spiderbot is only 83% complete. The slack comes from the planning and programming portions of the progress of Spiderbot. Manufacturing is labeled at 100%, since, though not done in the timely fashion that was hoped for, Spiderbot’s design came out, for the most part, as planned.

The burndown of the project can be seen in the charts below:

I did not account for many of the issues causing delays that were encountered throughout the progress of this project, so the work and task burndown plots are steeper than they should have been.

A Day at the Races

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Matthew Clegg – Computer & Control Systems

It all began earlier in the day. Group members Kristine Abatay, Simon Abatay and Matthew Clegg met early in a classroom, for a last second check to ensure everything on Spiderbot was working properly. A couple of screws were tightened and the Android phone was connected properly to the Arxterra website. The group had lunch to prepare for the race. At around 2 o’clock, Spiderbot, Hexapod, and Rover met on the predetermined course.

There was a bit of nervousness coming from all the groups. Who would come out on top? Who would be showered with glory and accolades as the victor or who would crash and burn in failure and leave bitter and dejected? Negotiations quickly took place to shorten the course with less obstacles but this did not go through because the original course was outlined in the requirements and had to be the one all of the projects would race on.

Both Spiderbot and Hexapod were fairly large, so having them all line up and race at the same time would have proven difficult. It was decided that each project would go individually and a time would be kept as it traversed the track. All of the groups had difficulty at first establishing a connection due to Wi-Fi issues but it was all eventually settled by having only one project at a time connected to the Arxterra control panel.

We (Spiderbot) got everything up and running and decided to go first. The first two steps started off well, but after that things quickly deteriorated. The pathway was on uneven ground, so with each step, Spiderbot slowly drifted to the left. Attempts to correct this did not fare well either. As it was turning, it lost footing, which caused it to collapse. It was picked up and set on course again. The next problem to arise was the servos. The rear right servo that causes the spider to lift its leg started making a horrible grinding noise with each lift. The weight of Spiderbot might have been too great for the servos to sustain for an extended period of time. At this point, it was decided to shut everything down to prevent further damage. Simon opened up the servo and found the gears inside to be busted.

The total distance traveled was roughly 6 feet at a time of around 3 minutes. Hexapod and Rover reached a further distance but did not have their share of issues. No project completed the full course. Spiderbot was defeated that day, but it was not a total loss. The knowledge learned from the track can be used by future projects for better planning and design. From the ashes, Spiderbot shall rise again like the phoenix.

Here’s a link to a video of the exciting race day!:

http://youtu.be/XNUIfEWJOmY

Weight Resource Report

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
& Simon Abatay – 3D Modeling & Manufacturing

The following tables are the weight resource reports for Spiderbot.

This first table shows the various masses that we initially predicted. The masses for the parts that were 3D printed (Chassis, Femur, Tibia, Pan & Tilt) were taken from estimates provided by SolidWorks with the properly chosen materials.

This second table is the final weigh in of all of Spiderbot’s parts, with a slight estimate on the ‘Wire Mesh, Screws, etc.’ row.

Ultimately, a majority of the parts weighed much less than what was predicted. The value that did increase was the femur portion, but that is understandable seeing as to how that particular piece was designed to hold two servo motors, so more weight is welcomed in that area.

Level 2 Requirements – Final Iteration

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
& Elaine Doan – Robot Company Systems Engineer

The following three requirements are the initial level 2 requirements that were introduced during the Spiderbot PDR:

1. In order to match the speed of the rover project while on a flat surface, the servo motors will need to move a distance covered by 60 degrees in 0.13 seconds and utilize a tripod gait – the walking style that will allow Spiderbot to move quickest, which will be implemented in the coding of Spiderbot.

This value was obtained using the following calculations done by our controls systems member, Matthew Clegg.

To try to estimate a possible speed for Spiderbot, he first calculated a velocity based on the speed of the servo motors. A servo’s rated speed is how fast, in seconds, the arm can move 60 degrees. To apply this to Spiderbot, he took into account the motion of the bot in a tripod gait. The gait is the specific sequence of leg movements executed when Spiderbot is in motion. An analysis of the different possible walking styles that Spiderbot is capable of can be found in the following blog post link from last semester’s Hexapod project: https://www.arxterra.com/hexapod-gait-description/. The study will show that the most efficient possible walking style that Spiderbot can use is the tripod gait.

These calculations can be found at the following link to a previous post, which lays out the calculations used to determine these values:

https://www.arxterra.com/speed-calculations-component-modification/

Test: Since this time value is so quick, measurement of this speed will require implementation of a video recording device and slow motion playback in a video editor. Code will be run through a breakout board and Arduino to a servo that will be placed on top of a protractor, which will be marked off to accurately measure 60 degrees. A digital stopwatch will be placed near the servo and will increment its time while the servo motor operates. A video of the motor will be captured and opened within a video editing program which will modify the video to play in slow motion. This way, the milliseconds portion of the watch will be easier to read and the time for the servo motion can be recorded.

2. In order to meet the safety requirement outlined by the level 1 requirements, Spiderbot will need to be constructed from materials that will prevent it from being labeled as a hazard. Avoidance of materials such as LiPO batteries in the Spiderbot design will help achieve this.

Test: According to the Injury and Illness Prevention Program for CSULB (found here: http://daf.csulb.edu/offices/ppfm/ehs/programs/iipp/#policy1), “All…hazard class scenarios shall also be immediately reported to SRMIS and each will be addressed on a case by case basis with the individual college or department manager”. If the final construction of Spiderbot does not garner the attention of SRMIS by falling under the category of one of its four hazard classifications, then Spiderbot will have met the safety requirement.

3. To meet the clearance specifications of 4 inches in height and 2.5 inches in width, Spiderbot’s 3D design will need to be at least 5 inches in height and 3 inches in width. The following design considerations were developed by Simon Abatay from manufacturing, to determine these value choices.

The femur length is chosen based off of reasonable servo specifications. Standard servo speeds from 0 to 60 degrees vary from 0.08 to 0.2 seconds. The femur length and servo speeds are critical for the spider to reach the speed requirement of 0.2003m/s. Based off of calculations, if the femur length is chosen to be 5 inches, the servo must rotate from 0 to 60 degrees along its z-axis within 0.12 seconds. If the femur length is chosen to be 3.5 inches, the servo must rotate at a speed of 0.09 seconds. This relationship shows that the longer the femur, the greater the distance traveled, thus the slower the servo has to move. Realistically, it would be ideal to choose a femur length that is longer than 3.5 inches. This is because finding a servo that moves at a speed of at least 1.2 seconds under load is more realistic than finding a servo that moves at 0.09 seconds under the same load.

Test: These clearances will be checked within the SolidWorks. Once a complete leg and chassis design are made, the pieces can be connected in the program, and if the measurements done allow for the obstacle clearances, then this requirement will have been met.

This next list of additional level 2 requirements was written with minimal guidance from Robot Company’s Systems Engineer, Elaine Doan, who wrote the requirements for this semester’s Hexapod project, alongside Hexapod’s Computer Systems and Software member, Chau To:

4. In order for Spiderbot to receive commands from the Arxterra Android App, via the Arxterra Control Panel, the microcontroller used must have a USB host interface.

For this reason, an Arduino Uno – R3 will be used, which will allow for communication, but will not accommodate all of the servos that will be used for Spiderbot.

Test: Send a command to the Android smart phone being used by Spiderbot, using the Arxterra control panel, and if the command executed matches the command that was sent, then this requirement will have been verified.

5. The microcontroller used must also provide connections to accommodate pins to control 20 servo motors.

Since the Arduino Uno – R3 does not directly accommodate all 20 servo motors, two Adafruit 16-ch 12-bit servo drivers will be used to provide power to them.

Test: Connect the servo driver used, along with a servo motor, to the microcontroller chosen and run a basic Arduino command. If the command sent to the servo motor matches the action executed by the servo motor, then this requirement will have been verified.

6. In order for motion of Spiderbot to occur, its battery will need to supply at least 10800 mAH.

This value is an estimate that accounts for the 18 servos that will be used to control the legs of Spiderbot, which is where a majority of the current will be allocated. The value was obtained from testing of the Power HD servo motors, whose results can be found here:

https://www.arxterra.com/current-test-of-the-power-hd-high-torque-servo-1501-mg/

The maximum current that was drawn from the servo motors, using a supply of 6V, was 0.6A. Multiplying this value by 18 yields the 10800 mAh stated above. Of course, this value overshoots the true amount of current that will be used by Spiderbot, considering the fact that all of the servo motors will not be drawing their maximum current simultaneously.

Test: Connect Spiderbot to power and let it run. If it lasts for at least 1 hour, then this requirement will have been verified.

Molding Parts

May 21, 2014/in Communites, Hexapod, Hexapod Generation #2, Members and Communities/by arxterra

By Vinh Kim, 3D Modeling and Manufacturing

Introduction:

Here I will show you the process of molding and casting the Hexapod parts with pictures.

Tool & Supplies:

Sliding Compound Miter Saw
Hardwood Flooring
Mold Max 40 or OOMOO 30
3D- printed parts
Glue gun & hot glue
Ease Release 200
Vinyl gloves only (Latex gloves will inhibit the cure of the rubber)
Drill
Screws
Digital Scale
Measuring Tape
Disposable plastic cups
Safety Glasses
Utility knife
Clamp
Disposable Wooden Chopstick

Making the Mold Box

Figure 1: Thank you to Ali the manufacturing manager for printing the Hexapod parts. Here I have the Hexapod 3D printed parts ready.

Figure 2: Here I measured (minimum of ½” of space on all sides of model see Figure 5) and cut the hardwood flooring using a sliding compound miter saw.

Figure 3: Using the two free 12 in. Ratchet Bar Clamp I got from Harbor Freight by using a coupon to clamp the wood that I cut together, so I can drill the holes and put the screws in. Here I am using a M3-0.50 x 12 mm screws, than I used a drill bit size 2.50 mm to punch the holes.

Figure 4: Next I used a 1.60 mm drill bit to drill the holes in the 3D printed parts and screwing the model down with a M2-0.45 x 12mm screw to prevent the 3D parts from moving. Also to prevent rubber from leaking out of the mold box, I used hot glue to stick it around the interior edges.

Figure 5a: Mold box done. Figure 5b

Pouring Mold Rubber

Figure 6: Once again, thanks to Ramon Luquin (Fall 2013 Hexapod Project Manager) for donating some mold and casting material to the Hexapod team.

Figure 7: Here I’m using rice to estimate amount of rubber or you can go online at http://www.smooth-on.com/tools.php to use a Material Calculators “How much liquid rubber do I need?”

Figure 8: Using Mold Max 40. It will be mixed in a 10:1 ratio. I am using 8 oz for Part A, 0.8 oz for Part B than mixing it together. Vacuuming is required to remove all the air bubbles. When mixing, just make sure to keep mixture stick on the bottom of the container and scrape the sides of the container. Than keep on swirling in circle until you get a solid green color.

As for OOMOO 30, I need mix a 1:1 ratio than I would use 4.4 oz for Part A and 4.4 oz for Part. However for this particular kind, it’s not required to vacuum this product since it has a low mixed viscosity.

Figure 9: Spray a light-mist coating inside the molding box, so when you remove the rubber it does not stick to the model.

Figure 10: To prevent air bubbles. Pour the rubber into a corner of the mold box and allow the rubber to flow evenly throughout the model. Let it cure and rest for 24 hours. OOMOO 30 only required 6 hours to form.

Figure 11: Finally, after rubber has cured, remove the retaining walls away from the cured mold.

Figure 12: Molding done.

Project Manager Research

Missions, Systems and Test Research:

Electronics and Control Research:

Manufacturing and Design Research:

Like Us!