Fall 2016 Velociraptor (W) Preliminary Project Plan

September 29, 2016/in Velociraptor (W), Velociraptor Generation #2/by LamNguyen

By: Lam Nguyen (Project Manager)

Hal Vongsahom (System Engineer)

Table of Contents

Work Breakdown Structure (WBS)

By: Lam Nguyen (Project Manager)

The Work Breakdown Structure in Figure 1 organize specific tasks to three section for the Velociraptor project. These three sections are assigned to division members in Mission, System, and Test, Electronics and Control, and Manufacturer. The overall diagrgam is overseen by the Velociraptor’s Project Manager to delegate these task to each division member. Each branch lists the responsiblity of the division member to meet the overall objective in completing the project.

Figure 1

Project Schedule

By: Lam Nguyen (Project Manager)

In order to meet deadlines for the Velociraptor Project, a project schedule was made to keep track of completed tasks. This schedule will not only benefit both the project manager and the division members but will also help move the project forward to build the robot.

Top Level Schedule

Top Level Schedule was created to keep track of tasks the project manager assigns each team member in Figure 2. Each task has a projected deadline assigned to each division member. Each deadline that is completed will help guide the team to focus on tasks unattended. The overview timeline of project in Figure 3 shows

Figure 2

Figure 3

System/Subsystem Level Tasks

The System/Subsystem Level Tasks outlines the tasks for each division member and provides a projected time for each division members.

Figure 3

Figure 4

Burn Down and Project Percent Completion

(TBA)

System Resource Reports

By: Hal Vongsahom (System Engineer)

Power Report

Figure 5

The power report is an overview of the initial power draw of the system. However, an important note is that the manufacture website or data sheet only listed power draw in current for all the components. Therefore, the power draw was calculated using Ohm’s law. The power report has a minimum and maximum power draw. A minimum power draw is when the velociraptor is not walking. A maximum power draw is when the velociraptor is walking. The measured power column is left blank at this moment. The group have not obtained any of the hardware to physical measure the current draw. However, the expected margin can give a rough estimate of the actually current.

The servos power draw was collected from the manufacture web site [1]. A total of three servos will be used. One servo to control the head, the second to control the tail, and the third is to control the threaded rod that will shift the center of mass accordingly. The total power draw for the three servos use the most power of the entire system.

The two DC motor comes second in drawing the most power for the system. The data was collected from the hardware website [2]. One DC motor will use for the right leg, and the other DC motor for the left leg.

The I2C and the MPU-6050 data was collected from the manufacture data sheet [3, 4]. The power draw for the I2C and MPU-6050 are not significant.

The 3Dot board data was collected from last semester Spider bot [5]. The Spider bot also use a 3Dot board last semester and measured actually values to verify that the ranges are correct. As a result, the velociraptor may use Spider bot data to factor into our initial power estimate.

Overall, the power is sufficient to operate the system. In addition, a 3,387 mW contingency is available for the system for other uncertainty.

Mass Report

Figure 6

The goal of this semester velociraptor is to weigh less than 900 grams. The mass of the MPU-6050 was gathered from the manufactured data sheet [3]. The mass of the MPU-6050 is very small and does not factor heavily in the project. The mass of the I2C is collected from the website [4]. The mass of the I2C also plays a small part. The mass of the 3Dot board was collected from the Spider bot last semester. Again, they were able to accurately measure the mass of the 3Dot board which justify it in this report.

The mass of the servo is collected from the manufactured website [1]. Since the quantity is in three, and it is acting as the velociraptor muscle. This add a decent amount of weight to the project. The DC motor mass was also collected from the website [2]. The quantity of the DC motor is two and adds 36 grams to the project. The battery mass of the battery is found online data sheet [6]. There will be two battery use in this project which ass 63.5 grams which is the second highest mass in the project.

The largest mass comes from the frame of the velociraptor. The frame of the mass was calculated using the total mass of the previous semester project minus the components mass of this semester [7]. The justification for using last semester mass is because their project was successful, therefore, this semester can factor that into this mass report for a good estimation.

Project Cost Estimate

By: Hal Vongsahom (System Engineer)

Figure 7

The total project budget for this velociraptor project is 400 dollars. The PCB, Frame, and prototype cost for this semester velociraptor cost report was borrowed from last semester velociraptor [7]. Last semester project actually spent the funds approved by the customer. Therefore, a good estimation can be calculated in this cost report. Also to note, these parts are the most expensive resources of the project.

The MPU-6050, I2C, Battery, servo, threaded rod, and DC motor cost was collected from the retailer’s website [3,4,6,2,3,1]. The DC motor and servo are the second most expensive component for this project. The data for the system resource reports link mass and cost together. The more mass the component has, the more cost that component shall have as well.

Last note, the 3Dot board is provided by the customer, therefore, it is not factor in the cost.

Overall the initial cost is well within the project budget with enough budget to cover addition cost for uncertainty.

Resources

[1] Addicore SG90 9g Mini Servo. (n.d.). Retrieved September 28, 2016, from http://www.addicore.com/Addicore-SG90-Mini-Servo-p/113.htm

[2] https://www.pololu.com/product/182/specs

[3] https://www.cdiweb.com/datasheets/invensense/PS-MPU-6000A.pdf

[4] https://cdn-shop.adafruit.com/datasheets/PCA9685.pdf

[5] https://www.arxterra.com/spring-2016-3dot-spider-bot-preliminary-design-document/

[6] https://www.bhphotovideo.com/bnh/controller/home?O=&sku=1018868&gclid=Cj0KEQjw1K2_BRC0s6jtgJzB-aMBEiQA-WzDMZ4G93fpLNmiUX-CGjONHm0czidWkbbSiUMk3B_luoAaAqM68P8HAQ&Q=&ap=y&m=Y&c3api=1876%2C92051678402%2C&is=REG&A=details

[7] https://www.arxterra.com/spring-2016-velociraptor-project-summary/#Size_Weight

[8] https://www.grainger.com/category/threaded-rods/bolts/fasteners/ecatalog/N-8k5

Fall 2016 Pathfinder (Solar Panels): Preliminary Project Plan

September 29, 2016/in Pathfinder Solar Panel/by Inna Echual

By:

Inna Echual (Project Manager)

Stephan Khamis (Mission, Systems, and Test)

Jose Rodriguez (Electronics and Control)

Ridwan Maassarani (Design and Manufacturing)

Table of Contents

Work Breakdown Structure (WBS)

By Inna Echual (Project Manager)

Figure 1: Work Breakdown Structure

The Work Breakdown Structure shown in Figure 1 demonstrates the work needed to complete the solar panel component of the Pathfinder project. The work branches into the four divisions (including project management) and the work/unique tasks underneath associated with each division.

Project Schedule

By Inna Echual (Project Manager)

Top Level Schedule

Figure 2: Top-Level Schedule

The top-level schedule shown in Figure 2 follows the blocks shown in the work breakdown structure. The major project deadlines are shown under the tasks of the project manager while each division’s individual tasks are nested under their respective division.

Currently, the tasks related to completing the folding mechanism (research, trade-off studies, 3D-Modeling, component specification and ordering, etc.) has the longest completion date and is our current critical path. We don’t have a solid choice for the folding mechanism yet so we still have to do further research and more studies to establish a design in order for our design to move forward.

System/Subsystem Level Tasks

Figure 3: System Tasks

Figure 4: Subsystem (Electronics & Controls) Tasks

Figure 5: Subsystem (Manufacturing) Tasks

Burn Down and Project Percent Completion

Figure 6: Burndown Chart

The project Burn Down Chart in Figure 6 demonstrates the work completed so far compared to the total amount of tasks expected to complete the project. The group has completed approximately 30 of the total tasks scheduled for the project. Currently, we are still trying to solidify a design for the folding mechanism so we may fall behind in the upcoming weeks due to research and trade-off studies.

System Resource Allocation Reports

By Stephan Khamis (Mission, Systems, and Testing)

Cost Allocation

Figure 7: Cost Allocation

Our budget that we have set for ourselves is to keep the project under 500 dollars. All of the expected prices listed in Figure 7 are rough approximations or the average price for that type of component as, for instance, we have yet to define the specifications of the stepper motor will be using so its cost is yet to be defined but we have an approximation of its price. We are reusing some of the parts that were on the previous pathfinder, such as the battery and the charging circuit for the battery. Our total expected cost is $383.81 and we have a contingency of $184.66 dollars. We have allowed ourselves a margin of about $70.

Power Allocation

Figure 8: Power Allocation

The expected power allocations are based on the components we expect to be using. We have not specified our motors yet but we have a range of the current draw based on the models we are leaning towards. Battery specifications were to be provided by the chassis group but they have yet to provide us with their experimental data.

Mass Allocation

Figure 9: Mass Allocation

The mass report in Figure 9 are rough approximations of the mass of each component we expect to be using. We have yet to define specifically the DC motors and stepper motors we will be using so their mass is yet to be determined but we have a general idea. The aluminum sheets will have a honeycomb cutout structure to reduce its mass.

Project Cost Estimate

By Inna Echual (Project Manager)

Figure 10: Project Cost Estimate

From the Cost Allocation Report in Figure 7, the overall projected costs are currently estimated to be $383.81. This price will be subjected to change as the project continues and is by no means a representation of a final product. However, we have already selected the type of solar cells we will be using—which are monocrystalline solar cells that already come with the tabbing connectors, ultimately reducing the cost of the overall project. However, the motors and springs have yet to be defined, which I expect will affect our total cost significantly.

2016 Fall Velociraptor: Preliminary Project Plan

September 29, 2016/in Velociraptor (Th), Velociraptor Generation #3/by Paul Ahumada

Paul Ahumada – Project Manager

Robert Licari – Systems Engineer

Kevin Armentrout – Electronics and Control Engineer

Victoria Osaji – Manufacturing Engineer

Table of Contents

Work Breakdown Structure

By Paul Ahumada

The WBS represents the job description tasks that members must fulfill. The three engineers are separated into their own divisions and handle their task for the Velociraptor. The tasks throughout the semester are specifically shown in the calendar view in the Top Level Schedule section.

Project Schedule

Top Level Schedule

By Paul Ahumada

The schedule is spread out for the semester with start and due dates for each task. These dates refer to a schedule provided by the customer. The Velociraptor project should follow the schedule to remain on track. Experiments and tests may be added as they are discovered and increase the task load.

The calendar provides a visual with names associated with each task. The person assigned to that task is responsible for its completion.

Calendar View Of Schedule

System/Subsystem Level Tasks

By Paul Ahumada

These tasks are shown in the Top Level Schedule. On the calendar layout, names are associated with each task. These tasks must be fulfilled by their associated team members. If there are no members listed, then the team as a whole must complete the task.

Burn Down and Project Percent Completion

By Paul Ahumada

The Project Burn Down shows how many tasks are left that the Velociraptor group must complete by the last day of the semester. The tasks we compare to are the remaining tasks in the Top Level Schedule. These tasks may increase as new experiments and tests are discovered. The Percent Completion is on a scale of 0-50 so it can be included on the same graph of tasks remaining.

System Resource Reports

By: Robert Licari

Mass Report

The mass needs to be as close to 657g as possible to meet initial torque calculations (done by E&C). Currently the estimated mass is at 706g with a contingency of 21.6. Assets that were used in this calculation come from the previous semester as well as the initial torque calculations. From the previous semester, we have our mass allotment of 657g as well as an overall frame mass of 154g. For our purposes, the frame mass shall be the total mass of the mechanical structure of the velociraptor without anything listed under the “Systems” category. Systems includes anything that will contain our control modules, battery packs, and any cables outside of the 3DoT board and the PCB motor controller. The battery mass was taken from last semester as a placeholder. We should expect the battery to be of equivalent or less mass than last semester. An allotment of 60g divided between the cables and the Motor Controller PCB have also been given as placeholders and will most likely alter based upon final design choices. Due to the nature of the design changes, this is only a preliminary mass resource report and is subject to change.

Power Report

The power resource comes from four basic factors that draw current from our supply source. Supply source will be defined as the battery on the 3DoT board as well as an external battery source. The 3DoT board will consist of the Atmega32U4 microcontroller, the HC-10 Bluetooth module, as well as the boost converter and was estimated at 110mA average by spiderbot. The motors will be separated into the server motors and the DC motors. Current draw from the servos was taken from the “Actual Current” measurement from last semester, and the draw of the DC Motors was taken from the average current draw from the initial torque calculations. The PCB design has changed, so the current draw is minimal due to last-minute design changes. Due to the nature of the design changes, this is only a preliminary power resource report and is subject to change.

Project Cost Estimate

By Paul Ahumada

The Cost Report provides an estimate to what the expected costs will be. The previous semester had there project cost $257.48. There project had $443.76 allocated for the frame and had an actual cost of $5.00. There reports show that the robot was not made 100% of aluminum and used a combination of aluminum and PLA to reduce costs described by their mass reports. The cost report shown for 3rd generation shows an expected cost of $273.55 and is increased because of the margin. Previous semesters requested $400.00 and our increased margin brings us to $387.05. Numerous components were looked at and are included in the citations.

Citations:

http://web.csulb.edu/~hill/ee400d/Lectures/Week%2005%20Project%20Plans%20and%20Reports/c_Generic%20Schedule.pdf
https://www.servocity.com/hs-5065mg
https://www.servocity.com/hs-65hb-servo
https://www.servocity.com/hs-65mg-servo
http://www.ebay.com/itm/Torque-Digital-Metal-Gear-Servo-Motor-for-RC-Robot-Helicopter-Airplane-Car-Boat-/222246871400?var=&hash=item33bef22168:m:mq1v5yVeOUDRTVVJUVjh70A
http://www.ebay.com/itm/AE-Team-Associated-1-10-ProSC-ProLite-4×4-XP-DIGITAL-DS1903MG-STEERING-SERVO-/400948939305?hash=item5d5a6b4a29:g:j1MAAOSw0UdXqeLU
http://www.robotshop.com/en/hitec-hs422-servo-motor.html
https://www.arxterra.com/fall-2016-velociraptor-th-preliminary-design-document/
https://www.google.com/search?q=pla+material&ie=utf-8&oe=utf-8#q=pla+material&tbm=shop&spd=8876641036563277883
https://www.google.com/search?q=pla+material&ie=utf-8&oe=utf-8#q=pla+material&tbm=shop&spd=8876641036563277883
http://www.homedepot.com/p/MD-Building-Products-24-in-x-36-in-Plain-Aluminum-Sheet-in-Silver-57794/202091743
https://www.servocity.com/81-rpm-mini-econ-gear-motor
https://www.servocity.com/90-rpm-micro-gear-motor-w-encoder
https://www.servocity.com/90-rpm-micro-gear-motor
http://www.batteryspace.com/A123-System-Nanophosphate-LiFePO4-18650-Rechargeable-Cell-3.2V-1100mAh.aspx
http://www.batteryspace.com/smart-charger-3-0a-for-3-2v-lifepo4-battery-pack.aspx
http://www.all-battery.com/TenergyLiFePO4BatteryCharger-01369.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdffi=fb520bc42d4e46cbab702234d35f7d38&gdfms=58521D8DE97640DEAF38BED2760D36D6&gclid=CjwKEAjwjqO_BRDribyJpc_mzHgSJABdnsFW5P8tGT10YF5GFBHJeBKOgnXMOOc1RIUaGDwV8nozwhoCQvjw_wcB

Preliminary Project Plan – Prosthetic Arm (Fall 2016)

September 29, 2016/in Prosthetic Arm/by Carolina Barrera

WORKDOWN BREAKDOWN STRUCTURE

The following Work-down Structure is the second iteration we got after we organize the potential schedule for the semester.

Figure 1 – WBS 2nd iteration

PROJECT SCHEDULE

The project schedule was done to give a basic idea to the group on the timing framework, and to work as a reference to know if the tasks are being done in a timely manner.

From the schedule we conclude that regardless of the video-taking that we are going to be doing to provide documentation about the project, we will spend major part of the project performing experiments on the arm system, and making sure it works as a whole.

The schedule for the project of the Prosthetic Arm is provided in HERE

SYSTEM RESOURCE REPORTS

Mass Report

For this initial mass resource report for the Prosthetic Arm project, the total expected weight of internal components (inclusive of an estimated 5 lbs from the Prosthetic Hand and 21 fl. oz. drink combined, per our L2-3 requirement) totals to 6.23 lbs, with a margin of 0.26 lbs. Given a required capacity to lift up to 6.83 lbs, the current report meets the requirement with a contingency of 0.34 lbs. The measured weight of the majority of our components is to be resolved, as we have not yet received many of the parts and validated their actual weights on a scale, however given margins and uncertainty, the actual weights are predicted to be lower than the expected weights.

Figure 2 – Mass Report

Power Report

In this initial iteration of the power resource report for the Prosthetic Arm project, the total expected current totals to 3242 A, inclusive of supplying the Prosthetic Hand with an estimate of 2A on 12V and 1A on 5V. The total margin for the current sums up to 0.840 A, with a remaining contingency of 0.418 A.

Figure 3 – Power Report

Cost Report

This first iteration of the cost resource report for the Prosthetic Arm project shows an expected project cost of $286.48, with a margin of $63.87 for the electronic components of the project. With respect to these estimates, the contingency amounts to $149.65, which will be allocated to the manufacturing components specified in the overall Project Cost Estimate.

Figure 4 – Cost Report

Cost

CA Tax Rate – Long Beach, CA

Myoware EMG Sensor (Cost)

Mass/ Power

Buck Converter LT3971A (10-Lead MSOP Packaging Weight)

LDO

14.8V Li-Po Battery

Teensy 3.2

Stepper Motor (PHI – 3321)

Myoware EMG Sensor (Weight)

Stepper Driver

Wire

PROJECT COST ESTIMATE

The project estimate is based on the budget and materials that we have purchased and looked at. It provides margin and it confirms our estimate provided previously in the Preliminary Design Document.

Figure 6 – Project Cost Estimated

Fall 2016 BiPed : Preliminary Project Plan

September 28, 2016/in 3DoT Biped, Biped, Biped Generation #3/by Gifty Sackey

Gifty Sackey (Project Manager)

Brandon Perez (Systems Engineer)

Ryan Daly (Electronics and Controls Engineer)

Ijya Karki (Manufacturing Engineer)

Table of Contents

Work Breakdown Structure

Gifty Sackey (Project Manager)

The Work Breakdown Structure (WBS) diagram, shows the responsibilities of each BiPed group member. A top level view of the job requirements can able to found in the product breakdown structure provided below. In each division of the product, readers are provided with a detailed explanation of what each team member will be responsible for their part.

Figure 1 : Work Breakdown Structure

Product Breakdown Structure

The Product Breakdown Structure (PBS) outlines what products are required to be designed by each group over the course of the semester. The PBS is broken down into a consecutive algorithm in order to ensure a successful completion of the product. Note that the blocks, containing what is produced, are not limited to intervention by other team members. The block labeling allows for a broad overview of what each members responsibilities are without going into details of each product.

Figure 2 : Product Breakdown Structure

Project Schedule

The project schedule details the necessary work that needs to done to implement the BiPed. In addition to the schedule, a projected timeline of deadlines and dates can also be found. In the link provided, readers can find a visual presentation of what the proposed schedule for implementing the BiPed. ProjectLibre was the tool used to implement the schedule. By manipulating the dates provided, if we are able to refine and solidify our requirements early, it gives us more flexibility with our days for coding; validation tests and also unforeseen events.

https://drive.google.com/file/d/0BzIcuzRpcmk4T3ZYX20wUmlPUmM/view?usp=sharing

Burn down and Project Percent Completion

The project percent completion and burn down chart provides a visual representation of the tasks that needs to be completed for the BiPed. It also allows the team to know how much of the current work load has been done.

Figure 3 : Breakdown Chart

Project Cost Estimate

The Cost Report summarizes how much each physical part of our product will cost. Details about shipping are not included in each resource since they can be bundled in the same order when ordering multiple parts from the same vendor. Amazon has no shipping charges if the parts are picked up at our Amazon pickup location at our University. The Project Allocation was determined based off what Rofi, the previous BiPed cost to be initially built.

Figure 4 : Cost Estimates

System Resource Reports

Brandon Perez (Systems Engineer)

Mass Report

The mass report summarizes an expected mass of our individual physical products of the BiPed. Most of the items were easy to determine since details about most electronic components contain a mass value on their spec sheets or on their vendor’s website. The PLA Platsic mass was determined based off what the previous BiPed weight. All “Actual Mass” values will be determined when obtaining the physical parts. Project Allocation value is an idealistic estimate of what we think the BiPed’s mass should be limited to.

Figure 5: Mass Report

Power Report

The power report summarizes how much power each electronic component will be consuming. No values shall be needed for the mechanical hardware since power consumption due to kinetic energy will only reflect in the power consumed by our electromechanical devices such as our dc motors and servos. Project Allocation value was determined based off how much constant power our two batteries would supply over the course of an hour.

Figure 6 : Power Report

Fall 2016, Preliminary Design Documentation

September 22, 2016/in Pathfinder Chassis, Pathfinder Generation #3/by sabinasubedi

Sabina Subedi – Project Manager

Adan Rodriguez – Mission, Systems and Test

Jose Alcantar – Electronics and Controls

Nicholas Lukin – Design and Manufacturing

Table of Contents

Review of Literature

By Sabina Subedi, Project Manager

Level 1 requirements for the Pathfinder from Spring 2016 were reviewed and analyzed per the requirement evaluation rubric provided below.

Requirement Evaluation Rubric:

Is the requirement, Quantitative, Verifiable, and Realizable?
Is the requirement located at the correct level (1 – Program/Project, 2 – System/Subsystem)
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?
Is language in the form of a requirement?

Figure 1: Review of requirements from Spring 2016

Program Objectives / Mission Profile

By Sabina Subedi, Project Manager

Program Objective Statement

The Pathfinder is an autonomous rover that is self-sufficient using solar panels. The design of the Pathfinder is inspired by the twin Mars rovers “Spirit and Opportunity.” The Pathfinder will utilize navigation waypoints on Arxterra control panel to traverse through the defined course, articulating ultrasonic range finders and LiDar sensor for obstacle avoidance. Digital slip differential will be implemented for unmanned turning of the rover during it’s course. In order to save battery, the Pathfinder will have sensors that will send signals to the motors to stop the wheels from spinning under no load conditions.

Mission Profile

The mission for the Pathfinder is to complete the same course defined for Spring 2016 AdBot. “The mission profile will be a test course consisting of the 9 steps in front of the USU building, then the concrete path clockwise leading down some inclines back to the bottom of the stairs.” (Spring 2016, AdBot Blogpost) The Pathfinder shall complete its mission in one evening. The pathfinder shall conduct its mission at night for better operation of the LiDar sensor.

Requirements

Program/Project (Level 1)

By Sabina Subedi, Project Manager

The pathfinder shall be autonomous, demonstrating GPS navigation mode on Arxterra
The pathfinder shall avoid obstacles articulating Ping Ultrasonic Range Finder and a LiDAR sensor
The pathfinder shall implement digital slip differential for turning, i.e., inside wheels turn at a different speed than the outside wheels while turning
The six wheels shall be on a rocker bogie suspension system to allow the Pathfinder to traverse through rough terrain and enable mobility
Each wheel shall have its own motor in order to be able to be controlled independently
Wheels under no load condition shall stop spinning in order to conserve power
The physical design of the Pathfinder shall mimic the Spirit and Opportunity rovers.
The pan and tilt system shall be modified to support an Android phone
The pan and tilt system shall be sealed in order to protect it from weather conditions in December
The Pathfinder shall explore the course defined by the AdBot rover. The mission shall be completed in 4 hours in the evening.
The Pathfinder shall be completed by the last day of 400D course, December 15^4h, 2016

System/Subsystem (Level 2)

By Jose Alcantar, Electronics and Controls Engineer

The Pathfinder shall use an Arduino Leonardo implementing the latest version of the 3DoT library. Due to customer request, the current Arduino Mega will be replaced with the Arduino Leonardo. The Leonardo will be programmed using the 3DoT library.
The Pathfinder shall use GPS coordinates from its sensors to communicate position with the Arxterra app. This will allow GPS navigation and the use of waypoint navigation.
For obstacle avoidance, a LIDAR sensor and two SeedStudio ultrasonic range finders (SEN136B5B) shall be implemented onto the design of the Pathfinder. The ultrasonic range finder will be able to detect the range of obstacles in front of the pathfinder from 3cm to 400 cm. The LiDAR sensor will be able to detect the obstacle itself, allowing the rover to maneuver around that obstacle. A trade off study was done prior to choosing this specific model of ultrasonic range finder.
The design of the pathfinder shall resemble the Spirit and Opportunity rovers. The Spirit and Opportunity rovers are each 1.5 meters high, 2.3 meters wide and 1.6 meters long, and weigh about 400 lbs.
Due to the removal of the Google Tango, the pan, and tilt platform shall be redone to accommodate solely an Android phone, specifically a Samsung Galaxy S7 Edge. The dimensions of the phone to be used are 9 x 72.6 x 7.7 mm (5.94 x 2.86 x 0.30 in). The phone weighs 157.6 g.
The encasement for the Android phone shall be sealed to protect the device from outdoor conditions.
This requirement will vary depending on the weather conditions on the day of the final demonstration in December. The forecasted load for the day of the final, December 15^th, 2016, is partially cloudy with a high of 65 degrees Fahrenheit and a low of 47 degrees Fahrenheit. No rain is forecasted for that week. Historical average for the day is 67 °/47 °.
In order for the Pathfinder to implement electronic slip differential 6-wheel drive, three separate VNH 5019 motor shields shall be used to allow the control of each independent DC motor. Testing will be done to find a suitable voltage ratio between the wheels to ensure slip differential turning.
The ACS712 (SEN-08883) current sensor shall be implemented to get feedback on the amount of current passing through the load. This current sensor will allows us to measure load up to 5A of AC or DC current.

Source Material

The links below consist of sources that were used in developing the Level 2 requirements.

PINGER and Arduino:

https://www.arduino.cc/en/Tutorial/Ping

Ultrasonic range finder (SEN135B5B) Fritzing diagram:

http://fritzing.org/media/fritzing-repo/projects/3/3pi-robot-atmega-328p-and-ultra-sonic-range-measur/other_files/ULTRASONIC%20SEN136B5B.pdf

SeedStudio UltraSonic range finder and Arduino interface:

https://www.youtube.com/watch?v=y8ox5NPvcPc

SeedStudio Ultra-sonic range finder:

http://www.eio.com/p-40804-seeedstudio-sen136b5b-ultra-sonic-range-measurement-module.aspx

Ultrasonic Field of View test, Fall 2015 Pathfinder:

http://arxterra.com/pathfinder-ultrasonic-field-of-view-test/

Specifications of the Spirit and Opportunity:

http://hobbiton.thisside.net/rovermanual/

Waypoint navigation on Arxterra:

https://www.arxterra.com/arxterra-now-supports-waypoint-navigation/

Performance of Arduino Leonardo:

https://www.arduino.cc/en/Main/ArduinoBoardLeonardo

Performance of LiDar Lite V2:

https://www.sparkfun.com/products/retired/13680

Weather Forecast for December 2016:

http://www.accuweather.com/en/us/los-angeles-ca/90012/daily-weather-forecast/347625?day=86

Spring 2016 AdBot Preliminary Design Documentation:

http://arxterra.com/preliminary-2/

Low Current Sensor:

https://www.sparkfun.com/products/8883

Preliminary Budget

The preliminary budget was created based on the new upgrades required to the existing rover in order to meet the new Level 1 and Level 2 requirements for this semester, Fall 2016. This budget will be verified by our customer before any parts are purchased. Therefore, the total estimated cost is subject to change.

Figure 2: Preliminary Budget for the Pathfinder, Fall 2016

Design Innovation

By Sabina Subedi, Project Manager

A brainstorming exercise was performed in order to come up with creative solutions to the problems found in the existing Pathfinder. Some of the problems with the existing Pathfinder were:

It cannot climb up the stairs. This problem occured because the weight on the existing rover is not distributed properly. It could be fixed by lowering the center of gravity. Possible ways of lowering the center of gravity include but are not limited to redistributing the weight on top of the chassis, or lowering the entire platform and pushing the wheels further back.
The rover draws excess current merely due to its weight. The weight could be reduced by milling excess metal off or by using lighter components. This could potentially increase the battery life.
The existing pan and tilt system is designed for a Google Tango and is controlled by two servo motors. The existing encasement a bulky design made out of plastic. The bulkiness of the design limits the Pathfinder in its range of movement and makes it harder to navigate. Possible solution to this problem is to design a new pan and tilt system to hold an Android phone and utilize stepper motors instead of servos to reduce bulkiness as well as increase functionality.

Systems/Subsystem Design

By Jose Alcantar, Mission Systems and Test Engineer

Product Breakdown Structure

Figure 3: Product Breakdown Structure

The product breakdown structure demonstrates the hierarchical breakdown of the products that will be used in the overall design of the Pathfinder chassis subsystem. At the highest level, the Pathfinder chassis subsystem splits into two separate main subcategories, the hardware and software aspect. The hardware consists of three subcategory items, the chassis, pan and tilt platform, and the Arduino microcontroller. The chassis subcategory was organized by first starting at the bottommost level, where the manufacturing engineer is responsible. This consists of the six wheels and six DC motors that will be installed onto the rocker bogie suspension system and ultimately onto the chassis. The pan and tilt platform is the responsibility of the manufacturing and electronics engineer. At the lowest level, the category consists of the Android device, motors for pan and tilt, and the two sensors. These bottom level components will be installed onto the manufactured pan and tilt platform allowing obstacle detection and platform control. The Arduino subcategory is the physical microcontroller used on the pathfinder. This category is further split into two categories, the motor shield, and Bluetooth module. The electronics engineer is responsible for these components. The use of the motor shields allow for DC motor control and the Bluetooth module allows for communication between Arduino and Android.

The other main subcategory is the software block. This block is then further split into other functions needed for the control of the pathfinder. The first sub component is the software-implemented control of the pan and tilt motors. The second component is the software controlled DC motors used for the wheels of the pathfinder. Third is the control of the LIDAR and Pinger sensors used for obstacle avoidance. The fourth component is the software integration for communication between Android and the Bluetooth.

Electronic System Design

By Adan Rodriguez and Jose Alcantar

System Block Diagram

By Adan Rodriguez, Mission, Systems and Test Engineer

Figure 4: System Block Diagram

Interface Definitions

By: Jose Alcantar, Electronics and Controls Engineer

Figure 5: Interface Matrix

The interface matrix for the Pathfinder chassis subsystem tabularizes the pin connection layout of the electronic system. The embedded system is comprised of the ATMEGA32U4, Arduino Leonardo board, Motor Shield and finally sensors and actuators on the rover. The Arduino and motor shield use up some pins from the ATMEGA and in exchange get an extension in capabilities for the components used on the rover.

Fritzing Diagram

By: Jose Alcantar, Electronics and Controls Engineer

Figure 6: Fritzing Diagram

Source Material

The following sources were used in developing the interface definition.

https://cdn.sparkfun.com/datasheets/Sensors/Proximity/lidarlite2DS.pdf

https://www.arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf

https://www.arduino.cc/en/Main/ArduinoBoardLeonardo

https://www.adafruit.com/product/1438

https://cdn-shop.adafruit.com/datasheets/TB6612FNG_datasheet_en_20121101.pdf

Mechanical Design

By Nicholas Lukin, Design and Manufacturing Engineer

Overall Design

Figure 7 : Overall design of the new chassis

Figure 8: Exploded view of the new chassis

The above pictures are models of what the Pathfinder should look like in order to satisfy the level 1 and 2 requirements. In order to satisfy the mission objective of traversing the same course/path that was outlined for the “Spring 2016 Adbot” the Pathfinder will utilize a rocker bogie suspension system that is very similar to the design used on the Spirit mars rover. This suspension system gives the Pathfinder a wide and long stance allowing it to climb up and around obstacles such as rocks and stairs. The length from the front to the back wheel will need to be longer than the length of the base platform in order to produce a wide stance. This wide stance will prevent the Pathfinder from tipping backwards when going up steep surfaces. Many components will be mounted to the base platform such as the pan/tilt mobile case, solar panels, electronics box, battery and sensors. These components will be mounted in a way that will create even weight distribution on the base platform. This even weight distribution will also help the Pathfinder remain upright when going up steep surfaces. Using a rocker bogie suspension system and having even weight distribution will help achieve the goal of traversing the course.

Chassis Lightening

Figure 9: Rocker-Bogie Suspension system

In order to conserve battery life and limit the stress put on the driver motors the chassis will be made as light as possible. The suspension components of the current Pathfinder will need to modified in order to achieve this requirement. The above picture shows the suspension components and how they may look in order to achieve the lightest possible design. About half an inch may be cut off from the inside of the suspension legs. Stress simulations and calculations will need to be performed to ensure that the new lightened chassis can handle the load of all the components that will be mounted to the base platform.

Mobile Phone Pan and Tilt System Design

Figure 10: Pan and Tilt System design

The use of a Pan/Tilt mobile encasement is required in order to help the Pathfinder navigate through the course. The holder can be designed for an Android or Iphone. The above picture shows a proposed design model for an Iphone 6. Measurements were taken from an Iphone six and these exact measurements were used in the above model. The Pan/Tilt system will be driven by servos that will be mounted directly to the Pan/Tilt chassis. The above model does not include the servo that controls the “pan” movement. Future design will include the second servo. Wiring for the servo motors will be run through the support tube and then ran to the electrical box via the bottom side of the base platform.

New Wheels

Figure 11: New wheels, McMaster-Carr 6″

In order for the Pathfinder to complete the course it will need to be equipped with new wheels. These wheels will have to be strong enough to support the load of the entire pathfinder and rugged enough to withstand the environment that the course will provide. The picture above is of a wheel sold by McMaster-Carr that may be used on the Pathfinder. The wheel is 6 inches in diameter and 1.5 inches wide. The axel has a diameter of 0.5 inches. The wheel hub is made of smooth steel and the actual wheel is made of solid rubber with hollow treads. The capacity of each wheel is 55 lbs. The wheel hub has ball bearings pressed into it to ensure smooth operation. Having a 6 inch diameter will allow the Pathfinder to get up stairs easier. Having a steel wheel hub may be too heavy therefore an aluminum wheel hub may be used instead. A wheel mounting hub will be designed in the future. This hub will properly connect the DC motor to the wheel. A link to the wheel specs can be found in the source material section.

Electrical, Wiring, AC Unit

Figure 12: Electrical box and top view of the chassis

It is necessary that all electronics be protected during the mission. An electrical box will be used to house all of the electronics such as the micro-controller and motor driver shields. The electrical box may be made out of metal or plastic and will be mounted in the best place possible to ensure even weight distribution. A cooling fan might be used in case the heat produced by the electronics gets too high. This fan will be built into the electrical box along with vents to ensure proper air flow. Future tests will need to be run with the electronics engineer to see how hot the electronics get. All wiring will be neatly mounted and covered for protection. The battery is the heaviest part of the electric system and will need to be mounted in the center of the base platform in order to maintain even weight distribution. The picture above shows a general idea of where the electronics will be mounted on the base platform relative to everything else.

Solar Panel Interconnection

The design of the actual solar panel support is not in our scope of work but it is necessary for us to know how it will look in order for us to figure out how it will be attached to the chassis. It is crucial that the solar panels have good weight distribution and that they are mounted on the base platform in the correct location. Working with the Solar Panel Group in the future will be necessary in order to figure out what the best location is.

Source Material

Spirit Rover:

https://en.wikipedia.org/wiki/Spirit_(rover)

Wheels:

http://www.mcmaster.com/#2331t11/=149w7jd

General Information on spring 2016 Pathfinder:

http://arxterra.com/spring-2016-pathfinder-preliminary-design-documentation/

Design and Unique Task Description

The following tests and experiments shall be conducted.

Solidworks simulations will need to be performed in order to figure out if the new lighter chassis is strong enough and to see if the center of mass is in the appropriate location. These tests include load and shear analysis (stress test) and various animations

Rolling tests will need to be performed on the new wheel to make sure they do not wobble and have a smooth rotation.

Pan/tilt platform may be animated to show proper mobility.

Weight distribution test with solar panel connected.

Fall 2016 Prosthetic Hand: Preliminary Design Document

September 22, 2016/in Prosthetic Hand/by Kimberly.Younger

Fall 2016 Velociraptor (Th): Preliminary Design Document

September 22, 2016/in Velociraptor (Th), Velociraptor Generation #3/by Paul Ahumada

Project Manager – Paul Ahumada

Electronics and Control Engineer – Kevin Armentrout

Manufacturer and Design Engineer – Victoria Osaji

Systems Engineer – Robert Licari

Table of Contents

Program Objectives/Mission Profile

By Paul Ahumada

3^rd Generation Velociraptor is a robot developed by the CSULB 2016 Fall Semester class that will expand on previous semester’s designs. The Velociraptor is to be a toy resembling Theropoda dinosaurs. Velociraptor shall compete in a Jurassic/Modern Game: Save The Human with other toys on the last day of class, December 15, 2016. The game will involve Velociraptor chasing another robot through various terrain by tele-robotic communication on the Arxterra Control Panel. The arena the Velociraptor must traverse is developed by the Game Committee and customer. The mission will display the robotic applications of the 3DoT Board developed by Arxterra and Velociraptor’s movement capabilities. – PM Paul Ahumada

Requirements and Verification

Program/Project

By Paul Ahumada

Level 1 Program Requirements

The Level 1 Program Requirements may resemble this:

The 3rd Generation Velociraptor shall participate in the Game: Save The Human proposed by the game committee
3rd Generation Velociraptor budget shall not cost more than $450.00. This estimate was based upon 2^nd and 1^st Generation Bipeds [7] [15]
The Velociraptor shall demonstrate its capabilities on this December 15, 2016 according to CSULB Calendar 2016-2017 [14]

Level 1 Project Requirements

The Level 1 Project Requirements may resemble this

Level 1 Requirements

The Velociraptor shall resemble a T-Rex of the Theropoda Dinosaur class [13]
The Velociraptor shall navigate through the game terrain provided by the game committee. Velociraptor shall:
1. Navigate on incline/declines no greater than 6.5 degrees
2. Shall navigate on uneven surface heights no larger than .5 cm
3. Shall utilize a foot design capable of traction on all surfaces
4. Battery shall provide sufficient power to robot for duration of the game
The Velociraptor shall statically walk [16]
The Velociraptor shall dynamically walk [16]
The Velociraptor shall use Bluetooth to communicate with Arxterra Control Panel [17]
The Velociraptor shall use a 3DoT board and implement I2C [17]
The Velociraptor shall use a Portable Power Source

System/Subsystem

Level 2 System Requirements

By Paul Ahumada

Shall implement a control system [PID or State Space] which shifts CoG on axis of legs maintain stability. The CoG shall be changed by two servos. There is one servo to control the head and one servo to control the tail. The acceleration and velocity of the CoG of the head and tail shall not exceed [data to be calculated] in order to avoid having momentum tip over the robot. [Level 1-1]
Shall implement control system [PID or State Space] which shifts CoG on axis of head, body and tail to maintain stability. The CoG shall be shifted by a servo controlling the platform of the body. The acceleration and velocity of the CoG of the body shall not exceed [data to be calculated] in order to avoid momentum causing robot to fall down. [Level 1-1]
Shall have two legs supporting mass of robot. [Level 1-1]
Shall use leg design that operates with cyclical movement that shall be controlled by a DC motor. [Level 1-1]
Shall implement a control system which shifts the CoG over the planted leg while statically walking. The shifted CoG mass shall be within [to be calculated value] mm center of foot. The distance shall not consider vertical distance, Z. The distance from CoG and center of foot shall be calculated by margin of stability [to be calculated]. [Level 1-3]
Shall implement a control system which tracks X, Y, and Z angles to the [to be found] precision. [Level 1-4]
Shall implement a control system which tracks acceleration in the X, Y, and Z planes to the [to be found] precision. [Level 1-4]
Shall track head and tail position to shift CoG by collecting data of servo angles to the [to be found] precision [Level 1-4]
Shall utilize Bluetooth LE interface to provide Velociraptor commands from Arxterra Control Panel [Level 1-5]
Shall connect head and tail servos via 3DoT Board servo interface. [Level 1-6]
Shall implement an IMU [to be determined what kind] that communicates via I2C at a frequency rate [to be found] Hz. IMU data that collected shall be implemented into control systems. [Level 1-6]
Shall use a CR123A 650mA rechargeable Li-ion battery from 3DoT Board [Level 1-6]
Shall implement a motor controller [to be determined what kind] on the motor shield that communicates via I2C at a frequency rate [to be found] Hz. [Level 1-6]
May use rechargeable batteries to power the Robot. [Level 1-7]
The robot shall be able to continuously operate in game arena for minimum one hour. [Level 1-2]
IMU shall send data as inputs to control systems for dynamic stability when encountering uneven surfaces and incline/declines [Level 1-2.1]
Model of foot [to be decided] design shall [calculated] surface area to provide stability and not impede movements
Traction of foot [to be determined] shall provide enough friction on all surfaces [study to be shown] of game terrain to prevent raptor falling over. [Level 1-2]
Shall change direction, left or right, by [to be determined arc] while walking. [Level 1-1]
Shall be able to change direction for range 0-360 degrees, left or right, while not walking. [Level 1-1]
Arduino Microcontroller Leonardo shall implement control algorithms [to be made] to be used in stability and user control of robot. [Level 1-7]

Level 2 Subsystem Requirements

Electronics Subsystem Requirements

By Kevin Armentrout

Shall use batteries with a series terminal voltage of 3.7V. [Level 2-12] [4]
Shall use leg motors with a gear ratio to produce a stall torque rating of at least 223 mN-m [Level 2-3] [Appendix]
Shall use a leg design with a primary lever arm length of at a maximum of 7cm [Level 2-3] [Appendix]
Shall use head and tail servos which produce a minimum of 50 mN-m of torque at 80 RPM and 125 mN-m of torque at 130 RPM. [Level 2-1] [Head and Tail Torque Graphs]
Shall use a platform positioning servo that operates with a max speed of 80 RPM and a minimum torque rating of 238 mN-m. [Level 2-18] [Platform Graphs]
Shall use a turning servo with a minimum torque rating of 139 mN-m. [Level 2-19] [Appendix]

Design Innovation

From our Creativity Presentation, we were able to generate ideas on how to talk challenges the 3rd Generation Velociraptor encounters. Major problems we must tackle for Fall 2016 is the ability to turn, CoG shifting along axis of head and tail, and changing the legs to cyclical movements. We have come across different solutions for each of these. For turning, we are thinking of using a servo to help the legs orientate a change in direction. Stabilizing an inverted pendulum will be the basis of our stabilization for the axis along the head and tail. Finally, the legs we are considering using are the UCI linkages because of their unique step pattern compared to Theo Jensen.

Creativity Exercise

Systems/Subsystem Design

Product Breakdown Structure

TBA

Electronic System Design

System Block Diagram

The electronic interface provides an idea of how the customer provided 3DoT board will move our robot. We used the 3DoT Block Diagram to get started. We will need a motor shield to connect to external devices that cannot fit onto the 3DoT board. Luckily, there is an I2C interface from the 3DoT board that allows us to add more devices. Because we need an I2C interface, we need an I2C chip that can connect to the amount of devices we needed. The I2C chip is explained in the Electronics research under design descriptions. The reason we do not have our DC motors directly connected to the 3DoT board is because it will always blow the polyfuse as determined by the mass of the robot. Further research will go into whether the 3DoT Dual Motor drive is the best fit in our motor shield. The electronics research goes into detail of the torque required to move our mass and the rpm needed.

Interface Definitions

TBA

Mechanical Design

TBA

Design and Unique Task Descriptions

Project Manager Research

As part of the game arena, friction coefficients of the surfaces must be found so our robot can maintain traction throughout the game. The table provided below shows that rubber has a higher static coefficient on cardboard than linoleum. This information helps if we would like to have rubber soles on our robot. Information that would be valuable that could not be found would be using plastic and also a study for friction coefficients on carpet. This information can be found from experimentation of by having a pulley design with one end having a mass dangling in the air and another end having our plastic or rubber mass. As we add more weight to the dangling mass, eventually the plastic or rubber mass on a surface will move.

Case Study Friction Coefficients	Static Frictional Coefficient
Rubber on Cardboard	.5-.8	Source Cardboard
Rubber on Linoleum	.3-.5	Source Linoleum

Electronics Research

By Kevin Armentrout

Leg Motors

Level II System requirements dictated that motors would be used as the locomotive method for the Raptor robot. This is challenging for a number of reasons. First, motor position cannot be accurately controlled to specify angles of motion. Even if motor shaft position was monitored by means of a rotary encoder or other shaft measurement device, starting position would be a challenge. Secondly, motors tend to occupy a larger space and weigh more than servos. [1]

Analysis was performed in R to measure the maximum and operational torque values of various lever-arms, using the weight from the previous semester’s raptor as a basis for analysis. Full analysis code is in the appendix below. This analysis was performed using lever arms from 6 to 10 cm and calculating the maximum operational torque due to gravity and centripetal force. 10cm was approximately the length of the raptor’s head, leg and tail from last semester. Our design would be a modification from the previous semester so it was important to consider other level arm distances that were not used from last semester. This importance was especially emphasized by the fact that the legs will need to be completely redesigned to allow for continuous motion. This brought upon the condition that the primary lever arm of the motors and servos may need to change to conform to motor torque requirements, thus the range from 6 to allow for further lever arm considerations.

Once maximum torque values were calculated, torque over the leg motion cycle was calculated by applying a sin to the position. Cursory analysis of the primary lever arm, which would be exerting the highest magnitude of torque on the motor, showed that the lever arm typically rotated between 210 and 330 degrees [2]. This corresponded to a value, which I identify as a realistic maximum, or sin(60) of the calculated maximum. Logical analysis of leg locomotion confirms this. Using the Y-Axis of your leg as a reference, it typically will not exceed 60 degrees on a single stepping motion. The realistic torque values for the legs at various lever-arm lengths is listed in the appendix below.

Head and Tail Servos

The level II requirement that dictated the need to move the head and the tail stemmed from the need to shift the CoG to the planted foot, or maintain in stationary during dynamic movement. To evaluate how the CoG will shift, an analysis on moments of inertia needed to be performed over the full motion of the tail. Disassembly of the previous semester’s raptor to weigh the individual segments was impractical, so an analysis of material density, and weight of the components used on the head and tail segments was done in its place.

Density of ABS plastic, as well as length and width of the tail was taken into account, as well as the dimensions of the battery holder. The batteries used were AAs, and dimensions and weight of the AA batteries were taken into tail and head mass calculations. The torque was based on centripetal speed of the servos. Analysis of 5V servos showed that the majority of servos were in the 80-130 RPM range, which was used for our analysis of torque due to centripetal force.

An additional factor for consideration, similar to the legs, was varying the head and tail radius, and its effect on the CoG and centripetal torque. Servos must be selected with torque rating that is greater than the curve shown below for the specified radius length.

Platform Servo

The platform servos will be used to move the entire control surface of the body in order to account for changes on the X-Z plane. In order to facilitate movement of the surface along this plane, we will need to account for the mass of the head and tail, as the Body components near the CoM will produce negligible torque due to the lever arm being of a small radius. This simplified the torque calculations to only concern the centripetal force of the motion along the Y axis, and the torque related to gravity. Below is the calculated chart with different servo speeds and head/tail radii. The selection of the Platform servo must exceed these values.

Turning Servo

Unlike the other electric components, the turning servo must be able to turn the entire platform left and right to control the robot’s direction. This requires the torque that is applied to the servo to not only be the entire mass of the robot, but also the additional force due to the frictional coefficients of the surfaces of the robot will walk on. The calculated number is the torque on the servo solely due to the mass of the robot. This number, still, is quite substantial, and other solutions may be needed to be explored to allow the robot the ability to turn in a precise manner.

Batteries

Batteries are to be considered for the following purposes. Primarily, their current capacity, as it will provide the necessary resource to power the robot’s electronics and actuators, and secondly, it’s form factor and weight as a method of balance for the robot. Last semester, and the semester previous did a clever design with the batteries, placing them as counter weights on the head and tail. This evenly distributed the CoG along the X and Y axis, and also allowed the CoG to shift as the tail moved. For this purpose, the AA form factor for batteries was considered as counter weights and primary power, and the slim form factor is considered as platform supplementary power.

Current draw was calculated by use of manufacturer ratings for representative components that fit the requirements for the motors and sensors, as well as the components of the 3DoT board. However, servo current load is not a required manufacturer listed quantity, and as such, is simply not listed on any of the servos we examined. Additionally, all servos listed on Sparkfun, Adafruit, Digikey, and Mouser have a minimum 5V rating. This would change the current-hours equivalent to a Watt-hour equivalent for consistency, as all other components will be powered via the 3.3V bus. For these points the servo calculations will be ignored for this initial power consumption analysis as they are not representative of actual values, and would be a best guess approximation.

The calculations took into account average motor load and peak sensor load to determine the following. Once again, these numbers are representative, and are not the actual final values that will be used for a full power analysis.

I2C

I2C functions in a daisy chain manner similar to USB, but has an address structure that is different. I2C can support up to 127 different addresses, but these addresses are unique and programmed at the hardware level [3]. Thus it is important that these addresses do not overlap in order to have proper sensor and control function. The 3DoT board is equipped with 2 Motor headers, 2 servo headers, and an I2C header, leaving at minimum 2 Servos that would need I2C control, and the IMU which would need I2C communication [4].

Motor Controller

A derived requirement from the number of servos and motors need for Robot operation is the need for an external motor controller shield. If the motors are to be placed on the shield, bi-directional motion would be necessary. This can be accomplished by means of an H-Bridge [5]. For the servos that would be attached, a PWM I2C controller would need to be utilized to ensure proper control over the devices. An ideal solution for rapid prototyping is a board that has both PWM functionality and H-Bridges for motor and servo control.

Inertial Mass Unit (IMU)

The need for an IMU comes from the requirement for dynamic stability of the Robot. In order to maintain the Robot dynamically stable, an accurate accountancy of both angular position on a three dimensional axis, and inertial shift detection by means of an accelerometer [6]. Due to the 3DoT board not having external pin headers except for those listed in the I2C descriptions, the interface for communicating with the IMU must be I2C.

Appendix

		Peak Torques (N-m)
	Radius	10 cm	9 cm	8 cm	7 cm	6 cm
Component	Platform	0.238	0.203	0.170	0.140	0.113
	Legs	0.279	0.251	0.223	0.192	0.167
	Head/Tail	0.050	0.040	0.031	0.023	0.017
	Turning	0.139	0.123	0.108	0.093	0.079

Representative Components Which Met Torque Criteria
Servo/ Motor	Torque (N-M)	Weight (g)	Cost ($)	NL Current (A)	FL Current (A)	RPM	Notes
Motors
ROB-12399	0.322	119	24.95	0.095	0.5	101	(@12V) [A6]
Tamiya 72005	0.235	140	13.95	0.15	2.7	51.3	[A7]
Tamiya 70168 – Double	0.223	120	9.25	0.15	2.1	38	[A1]
Servos
FS5103R	0.294	40	11.95	NL	NL	80	(@5v) [A8]
EMAX ES08A	0.148	8.5	9.9	NL	NL	83.3	(@5v) [A9]
Seeed 108090001	0.197	12.25	21.9	NL	NL	83.3	(@5v) [A10]
Seeed 108090002	0.245	19.96	24.9	NL	NL	100	(@5v) [A11]

Component	Average Current	Source
Leg Motors	1.583 A	[A1]
Leonardo (3DoT)	0.56 A	[A2-A3]
IMU	0.00686 A	[A4]
Motor Shield	0.01 A	[A5]
Total	2.16 A

R Source Code for Calculations

# Determined by the Servo

stepSize = (pi/180)*(360/3000)

thetaHead = seq(-pi/2,pi/2,stepSize)

thetaTail = -thetaHead

thetaLeg = seq(0,2*pi,stepSize)

# In RPM

MaxSpeed = seq(80,130,.1)

# Max Incline on Y Axis

MaxY = (6.5*pi/180)

# Centripital Acceleration

# http://www.engineeringtoolbox.com/centripetal-acceleration-d_1285.html

A = (2*pi*MaxSpeed/60)^2 * Radius/100

# AA weight is 23g

# AA dimensions are in cm, which is used to determine ABS plastic

# Battery holder mass

# http://data.energizer.com/PDFs/E91.pdf

innerLength = 5.050

innerWidth = 1.450 *2

innerHeight = 1.450

outerLength = innerLength + .5

outerWidth = innerWidth + .5

outerHeight = innerHeight + .5

HolderVolume = (outerLength * outerWidth * outerHeight) – (innerLength * innerWidth * innerHeight)

AA = 23

# ABS plastic weight is .97g/cc

# http://www.stelray.com/reference-tables.html

ABSDensity = .97

# Calulate tail and head weight

# Thickness of 1cm for consistant calculations

tailMass = 2*(AA) + (Radius*(1^2) + (HolderVolume)) *ABSDensity

headMass = tailMass

# Previous Semester’s Robot Mass in grams

# https://www.arxterra.com/spring-2016-velociraptor-project-summary/#Size_Weight

Mass = 657

BodyMass = Mass – tailMass – headMass

HeadPositionX = Radius*cos(thetaHead)

HeadPositionY = Radius*sin(thetaHead)

TailPositionX = -Radius*cos(thetaTail)

TailPositionY = -Radius*sin(thetaTail)

# For moments of mass

TailMassX = TailPositionX * tailMass

TailMassY = TailPositionY * tailMass

HeadMassX = HeadPositionX * headMass

HeadMassY = HeadPositionY * headMass

X_Moment = (TailMassX + HeadMassX) / (tailMass + headMass + BodyMass)

Y_Moment = (TailMassY + HeadMassY) / (tailMass + headMass + BodyMass)

g = 9.8

LeverArm = max(Y_Moment)

# Torque due to gravity (Y Axis)

MaxTorqueHeadY = (headMass/1000) * g * Radius/100

MaxTorqueTailY = (tailMass/1000) * g * Radius/100

# Realistic torque due to gravity

RealisticTorqueHeadY = MaxTorqueHeadY * sin(MaxY)

RealisticTorqueTailY = MaxTorqueTailY * sin(MaxY)

# Torque due to Acceleration (X Axis)

MaxTorqueHeadX = (headMass/1000) * A * Radius/100

MaxTorqueTailX = (tailMass/1000) * A * Radius/100

# Platform Maximum Torque (Y Axis)

MaxTorquePlatform = MaxTorqueHeadY + MaxTorqueTailY + ((headMass/1000) * A * Radius/100) + ((tailMass/1000) * A * Radius/100)

# Frictionless Turning Torque

MaxTurningTorque = ((Mass/1000) * g) * LeverArm/100

# Frictionless Leg Moving Torque

MaxLegTorque = (Mass/2)/1000 * g * LegRadius/100

LegTorque = abs(MaxLegTorque * sin(thetaLeg))

RealMaxLegTorque = abs(MaxLegTorque * sin(60/180 * pi))

Manufacturing Research

Materials Trade-Off Study:

Spring 2016 Velociraptor: Material Trade-Off-Study Update

The previous semester, spring 2016, did a very detailed material trade-off study that we liked based on Aluminum and PLA Filament (3D printing material). We found this very useful because we have ideas that we can now build off of. Although, our design may differ in some places and our requirements have changed a bit these are still information we can use because the basics requirements are covered such as walking statically and dynamically and being able to walk up and down uneven surfaces. What I really liked most is that they used the two different material depending on their needs. They used the aluminum for their bottom piece because they wanted to maximize the weight on the head and tail. Then they used the PLA filament for the foot that way the robot could walk statically and dynamically without slipping on different surfaces.

Unique Design:

Victoria Osaji

Create a 3D model of the Velociraptor using Solidworks. Send out to be 3D printed. (4 weeks)
Simulate the model and perform all testing in Solidworks. (2 weeks)
PCB Design on EagleCAD. (2weeks)

Sources

Project Manager:

Electronic and Control:

Manufacturer:

http://sites.uci.edu/markplecnik/projects/leg_mechanisms/leg_designs/
https://www.arxterra.com/spring-2016-velociraptor-material-trade-off-study-update/
https://www.arxterra.com/spring-2016-velociraptor-hardware-simulation/
https://www.arxterra.com/spring-2016-velociraptor-spring-experiment/

Fall 2016 Game: Save The Human

September 22, 2016/in Velociraptor (Th), Velociraptor Generation #3/by Paul Ahumada

Gaming Committee Team Members:

Velociraptor (Th) – Paul Ahumada

Velociraptor (W) – Lam Nguyen

Biped – Gifty Sackey

Goliath – Kristen Oduca

Table of Contents

Overview:

Biped has accidentally lost his way in the forest. Unbeknownst to Biped, Velociraptors lurk in the shadows. Biped must flee to the safe haven before the raptors get him. Better pick up a weapon and protect yourself! All robots shall navigate through terrain of the arena.

Rules:

Robots start at designated starting zones
If Biped makes it to the safe-haven zone, Biped wins
If Velociraptors make contact (touch) with Biped or Biped does not reach the safe-haven zone, Velociraptors win
Goliath shall only follow Biped
Biped can use a sensor to sense a weapon on a space that is 4inx4in. Biped will actuate (something obvious to the Velociraptor teams) that they currently possess a weapon. They remain invincible for 5 minutes. If a Velociraptor touches the Biped while it is invincible, they are given a yellow card. If they do this a second time, they are given a red card and will be removed from game by IA or Professor
Time Limit of 60 minutes
If a robot falls down during the game due to terrain, they are considered out and will be removed from game by IA or Professor
If Goliath accidentally bumps into any of the robots and knocks them down, that robot is removed from game by IA or Professor

View and control:

Biped controller shall see via Arxterra Android or iPhone mounted on Goliath and will operate in RC mode
Velociraptor teams shall see via cameras in fixed positions in game course and operate tele-robotically from the Arxterra control panel

Terrain:

Terrain shall be supplied by the participants
Arena size shall be front a 12ftx5ft
Terrain shall consist of cardboard
Terrain shall consist of no more than 30% of the arena area
Surfaces of arena shall consist of classroom floor (linoleum) and cardboard
Terrain shall be assembled by Customer and IA without the knowledge of participants
Terrain objects shall consist of hills and uneven surfaces made of cardboard
- Hills shall be a maximum of 1ftx1ft in area
  - Terrain incline/declines shall be no larger than 6.5 degrees
  - Uneven surfaces shall not be larger than .5cm in height when stepping on
- Uneven surfaces shall be strips of cutout cardboard with an area no larger 1inx1in
  - Uneven surfaces shall not be larger than .5cm in height

Fall 2016 Velociraptor (W): Preliminary Design Documentation

September 22, 2016/in Velociraptor (W), Velociraptor Generation #2/by LamNguyen

By: Lam Nguyen (Project Manager)

Hal Vongsahom (System Engineer)

Taylor Farr (Controls Engineer)

Aaron Choi (Manufacture Engineer)

Program Objective

Lam Nguyen (Project Manager)

The Fall 2016 Velociraptor is inspired by both the biped Titrus-III robot and the Theo Jansen biped robot. The Titrus-III was developed by the Tokyo Institute of Technology and the Theo Jansen biped robot was designed by the Gakken company. The objective for this year’s project is to avoid utilizing servos by implementing alternative motors to meet the customer’s demand. The most compatiable design for using alternative motors is the Theo Jansen biped robot known to model human giat motion that utlize continuous rotion with linkages.

Mission Profile

Lam Nguyen (Project Manager)

The Fall 2016 Velociraptor had the wonderful opportunity to be included in this years Game Arena called “Save the Humans”. Representing the dromaeosauridae theropod dinosaur from the Cretaceous period the fall the the Velociraptor will navigate through the game arena terrain and hunt down the Biped robot before reaching the safe-haven zone in a time duration of 30 minutes.

The Fall 2016 Velociraptor will demonstrate its navigation cabablities by operating telerobotically from the Arxterra control panel. With a fixed view of the game arena the Velociraptor will navigate through both flat surfaces and uneven surfaces such as linoleum and cardboard.

Requirements

Program Level 1 Requirements

Lam Nguyen (Project Manager)

According to the CSULB Fall 2016 Academic Calender, the Velociraptor biped robot shall be tested by Wednesday, December 14, 2016, the last day of EE400D [1].
The Fall 2016 Velociraptor biped robot budget shall be a limit of $400.00 [2].
The Fall 2016 Velociraptor biped robot shall participate in the game “Save the Humans” defined by the game committee. [3]

Project Level 1 Requirements

Lam Nguyen (Project Manager)

The Velociraptor biped robot shall resemble dromaeosauridae theropod dinosaur from the Cretaceous period. [4]
The Velociraptor shall be able to statically walk on the terrains of the game arena.
The Velociraptor shall be able to dynamically walk on the terrains of the game arena.
The Velociraptor shall use Bluetooth communication with the Arxterra Android or Iphone application.
The Velociraptor shall use a 3DoT board with a custom I2C shield.
The Velociraptor shall navigate through the game arena’s terrain.
The Velociraptor shall use a portable power source for the duration of the game “Save the Human”.

References

[1] Time, B. C. (n.d.). Final Exam Fall 2016 Schedule Charts. Retrieved September 21, 2016, from http://web.csulb.edu/depts/enrollment/registration/final_exam/fall_chart.html

[2] Khoivu0814. (2016). Retrieved September 21, 2016, from https://www.arxterra.com/spring-2016-velociraptor-preliminary-project-plan/

[3] Index of /~hill/ee400d. (n.d.). Retrieved September 21, 2016, from http://web.csulb.edu/~hill/ee400d/F’16%20Project%20Objectives%20and%20Mission%20Profile.pdf

[4] Dromaeosauridae. (n.d.). Retrieved September 21, 2016, from https://en.wikipedia.org/wiki/Dromaeosauridae

System/Subsystem Requirements

Project Level 2 Requirements – System Requirements

Lam Nguyen (Project Manager)

Hal Vongsahom (System Engineer)

Taylor Farr (Controls Engineer)

Aaron Choi (Manufacture Engineer)

The Velociraptor shall walk on two feet and use both head and tail to control the robot’s center of gravity.
The Velociraptor shall implement the head and tail to shift it’s center of gravity on one foot in order to statically walk in the game arena’s terrain.
The Velociraptor shall use an accelerometer and a gyroscope to detect its reference to x, y, z space to adjust it’s center of gravity to dynamically walk in the game arena’s terrain.
The Velociraptor shall use an HC-06 Bluetooth to communicated with the Arxterra Application to control the robot’s movement.
The 3DoT board shall receive commands from the HC-06 Bluetooth and decode the command data, and transmit the command data to the I2C to control the actuators.
The Velociraptor shall provide a lithium polymer battery to provide power for the duration of 30minutes from the game objective.
The Velociraptor shall be able to travel up an incline/decline slope no larger than 6.5 degrees.
In order to navigate around the game arena’s terrain the Velociraptor shall travel on cardbaord and class room floor, uneven surfaces of the terrain shall be no larger than 0.5 cm.

Subsystem Level 2 Requirement

Taylor Farr (Elecontrics Engineer)

In order for the velociraptor to be able to operate properly, an input and output system must be designed. For our inputs, we will be using a digital accelerometer to measure acceleration as well as a gyroscope to determine the position from a neutral point at any given time. [1] & [4]
The accelerometer shall be digital in order to reduce coding(Help from Hal). Trade-off studies shall be conducted in order to find an appropriate accelerometer that is compatible with Arduino. [1]
For actuators, motors shall be use to move the Velociraptor forward and performing actions in order to keep it stable. [2]
Servos shall be implemented in the head and tail to move the head and tail to shift the center of mass 30 degrees in either direction. In order to correlate the sensors and actuators, a microprocessor is required to interpret the data at input pins and then provide the appropriate signals to the output pins in order to activate the motors and servos. [2]
The motors for the legs shall provide enough torque to support the 900 grams. Operating speed shall be determined by how fast the velociraptor needs to move in order to control its dynamic walk. The torque necessary to move the robot and support the 900 grams must be taken into consideration. This calls for a trade-off study of motors and servos in order to pick the appropriate ones. [3]
Based on the speed and torque required, trade off studies shall be conducted to find an appropriate power supply that supplies enough current at the appropriate voltage.
Fritzing diagrams shall be utilized in order to map out circuits connected to Arduino that provide appropriate and accurate data. Once this has been established, we will model the electronics in LT Spice, send the circuits to Eagle, and then design the PCB.

Aaron Choi (Manufacturer Engineer)

In order to meet the customer’s demand in alternative motors the Velociraptor shall use the Theo Jansen Biped robot’s linkages for continuous movement. [5]
In order for the Velociraptor to operate the mass shall not surpass 1000 grams.

References

[1] MAV-blog. (n.d.). Retrieved September 21, 2016, from http://tom.pycke.be/mav/69/accelerometer-to-attitude

[2] @. (2014). How a Robot Can Keep Its Balance and Stand up Even if it Gets Kicked – Case Study – Smashing Robotics. Retrieved September 21, 2016, from http://www.smashingrobotics.com/how-a-robot-can-keep-its-balance-and-stand-up-even-if-it-get-kicked-case-study/

[3] http://www.robotshop.com/en/gear-motors.html

[4] MAV-blog. (n.d.). Retrieved September 21, 2016, from http://tom.pycke.be/mav/70/gyroscope-to-roll-pitch-and-yaw

[5] @. (n.d.). Theo Jansen-style Biped Robot kit by Gakken. Retrieved September 21, 2016, from https://www.adafruit.com/product/1841

Design Innovation

The team worked off of the creativity presentation, with ideas bouncing back and forth we considered additional problems and applied our research to find a solution. One of the main problems we have considered are the motors which provides a continous rotion for our Velociraptor. Since the customer demands motors instead of servos, that effects the design of the legs as well. For a model to follow we bought a Theo Jansen Biped Robot for further study of the linkages for the legs. We will create a design for the legs and chassis that with less amount of material as possible for prototyping.

Creativity Presentation

Creativity Presentation PowerPoint

System/Subsystem Design

Product Breakdown Structure

Hal Vongsahom (System Engineer)

Figure 1

The image display on Figure 1. the product breakdown structure. This is a high overview of the structure flowing from the top down to the structure and component of the velociraptor.

Power

The velociraptor shall be power by a portable supply source. The battery will power the systems 3Dot board, I2C, DC motors, Servos, and the Accelerometer/Gyroscope. This can be thought of as the food and energy necessary for the velociraptor to move.

Software

The software required by the customer is the Arxterra app. The Arxterra acts as a friendly user interface that will help control the movement of the velociraptor. The codes will be written in C++ in Arduino. All of the subroutine will be develop to properly control the movements of the velociraptor.

Communication

The main component to the velociraptor communicating properly is dependent on the Bluetooth. The Bluetooth will receive data packets that must be decoded. The Bluetooth will receive data from the Android phone.

Actuators

The actuators for our system are DC motor and Servos. The DC motor will control the legs to perform walking. The servos will govern the head and tail movement for the velociraptor. Another conceptual way to think of the actuators are it is the muscle of our systems.

Manufacture

This can be considered the bones, and the entire body of our system. The manufacture of the velociraptor head, tail, and body will be printed and constructed. The PCB will also be design and printed out to form the blood vessels of the velociraptor.

Reasoning

The customer requires our velociraptor navigate through the game arena with different surfaces and inclines/declines. Therefore, it is important for the design to incorporate as many DC motors or Servos to not restrict movement of the velociraptor.

Electronic System Design

System Block Diagram

Hal Vongsahom (System Engineer)

Figure 2

A system block diagram above shows the corresponding inputs, power, extended peripheral, outputs, and communication devices that will be use on this project. The image shows the input devices that will be sending data to the microcontroller will be the accelerometer and the wireless Bluetooth device. The communication that will contribute to controlling the velociraptor movement will be the Android phone and the Arxterra application. The portable battery device will power both the microcontroller, the I2C, and the outputs such as DC motors and Servos. This system diagram illustrates the important of the microcontroller acting as the brain for all other components to operate properly.

Interface Definition

Figure 3

Figure 4

The above image in Figure 4 below lists all the pins in the Arduino microcontroller. It also gives a clear understanding of how much digital pins and analog pins are on the microcontroller. This can then lead to us designate each pin to control the devices needed for the velociraptor to operate successfully.

Figure 5

Pins for the velociraptor in the above image

System Resource Map

Figure 6

The table above list the system resource. A new requirement this semester from the customer is that we are required to have an I2C board. The 3Dot board is utilizing an Arduino Leonardo and the pins for SCL (Clock line) and SDA (Data line) are limited to one each. Therefore, we extend the SCL and SDA with the I2C board to connect the MPU-6050 accelerometer/gyroscope.

In addition, the primary design for our velociraptor will be using 2 DC motors and 2 servos. The DC motors only require a Vcc and Gnd, and the servos require PWM. If our design requires more DC motor or Servo we can add this on the 3Dot board pins or the I2C board. This will overall give us more flexibility.

Resources

[1] https://github.com/Bouni/Arduino-Pinout & https://www.arxterra.com/spring-2016-velociraptor-preliminary-design-document/

Mechanical System Design

Taylor Farr (Elecontrics Engineer), Hal Vongsahom (System Engineer), & Aaron Choi (Manufacturer Engineer)

Leg Design

Previous generations of the Velociraptor utilized servos in the leg design. The controlled angle of rotation from the servos allowed the Velociraptor to walk statically. However, due to the customer’s demands, servos are not to be implemented within the leg design. Therefore, the Velociraptor shall utilize a DC motor. Since the DC motor use a continuous rotation, the Jansen’s Linkage shall be implemented with the leg design. The Jansen’s Linkage utilizes a joint to be driven by a continuous rotational motion.

Figure 3

In the Figure 3 above, the leg mechanism models a Jansen’s linkage. This system utilizes a fixed point and a rotating point to model the human walking gait.

Resources

[1] AMANDA GHASSAEI: HOME. (n.d.). Retrieved September 21, 2016, from http://www.amandaghassaei.com/files/thesis.pdf

[2] What’s The Difference Between DC, Servo & Stepper Motors? (2015). Retrieved September 21, 2016, from https://www.modmypi.com/blog/whats-the-difference-between-dc-servo-stepper-motors

Design and Unique Task Description

Taylor Farr (Elecontrics Engineer)

The previous semester was unsuccessful with dynamic walking due to their sensors. They used an analog accelerometer to measure walking up inclines, and the previous semester did not use a gyroscope. The problem with analog is the converted codes will have tons of lines of codes. Therefore, compile too much memory on the Arduino Leonardo. In addition, there sensors was not accurate because they did not use a gyroscope. Therefore, this semester we are using a gyroscope in our system. This can monitor the displacement of the body from the neutral balance state, and update in real time. Moreover, we will use a digital accelerometer and gyroscope so that the coding will be simpler thus speeding up the processing time.

Sensor Selection

We have selected the MPU0605 as the gyro/accelerometer. The reason we choose this particular device as a sensor is it has both the features of an accelerometer and gyroscope. It also has an analog to digital converter built in.

Motor Selection

Once the sensor has been selected, the next task is to select the appropriate DC motors for the legs. Some options are brushless, brushed, shunt, series, or stepper. From these options, we will conduct trade off studies. Based off these studies, we will select the appropriate motors and servos that satisfy the torque and speed needed based on weight requirements.

Power supply selection

Now that the motors have been determined, we will select the appropriate power supply based on the power consumption of the selected motors. Based on requirements, we will use lithium ion batteries.

Aaron Choi (Manufacturer Engineer)

Project level 1 requirements describe the velocraiptor to statically and dynamically walk. To improve the walking motion, the feet of the Velocraiptor shall implement a toe joint. This toe joint enhances performance and stability of biped robots [1], specifically increasing walking speed [2] and reducing energy consumption compared to a flat foot [3]

Resources

[1] Kwon, SangJoo, and Jinhee Park. “Kinesiology-Based Robot Foot Design for Human-Like Walking.” International Journal of Advanced Robotic Systems 9 (2012).http://cdn.intechopen.com/pdfs-wm/41665.pdf

[2] Ouezdou, Fathi Ben, Samer Alfayad, and Bachar Almasri. “Comparison of several kinds of feet for humanoid robot.” 5th IEEE-RAS International Conference on Humanoid Robots, 2005.. IEEE, 2005. http://ieeexplore.ieee.org/document/1573556/?arnumber=1573556

[3] Sellaouti, Ramzi, et al. “Faster and smoother walking of humanoid HRP-2 with passive toe joints.” 2006 IEEE/RSJ International Conference on Intelligent Robots and Systems. IEEE, 2006. http://ieeexplore.ieee.org/document/4059197/?arnumber=4059197