Members and Communities – Page 123

Spring 2016 Velociraptor: Research, Roles & Responsibilities

February 10, 2016/in Velociraptor, Velociraptor Generation #1/by Khoivu0814

Velociraptor Team:

Khoi Vu (Project Manager)

Camilla Jensen (Systems Engineer)

Ashlee Chang(Electronics & Control Engineer)

Mingyu Seo (Design & Manufacturing Engineer)

Khoi Vu (Project Manager)

I. Responsibilities

First major task as the project manager is to work with the president (Chad Arnett) and the customer (Dr. Gary Hill) to define the project’s mission objectives.

Once objectives are confirmed, the project manager would then work closely with the systems engineer to create programs and project level one requirements.
As the requirements are set, the project manager will provide the president and customer with a preliminary cost breakdown of the project, the projected cost will be based on previous generations of the robot.
After the preliminary cost is approved by the president and customer, the focus will be on the scheduling of team meetings, approving and reporting deadlines, and assigning tasks to individual engineers.
All documentation of the project will be handled by the project manager; this includes editing trade-off studies, blogs, meeting minutes, and project videos.
The project manager must assure that the robot’s performance meets the customer’s expectations.The project manager also ensures that the team’s contribution and performance to the project are at the highest.

II. Source Material:

Final Documentation MicroBiped, 5/16/15, Final Project Cost, https://www.arxterra.com/final-documentation-microbiped/
Fall MicroBiped Preliminary Project Plan, 10/1/15, Project Cost Estimation, https://www.arxterra.com/fall-2015-microbiped-preliminary-project-plan/
Fall 2015 MicroBiped Level 1 Requirements, 9/18/15, Level 1 Program and Project Requirement, https://www.arxterra.com/microbiped-level-1-requirements/
Fall 2015 MicroBiped Preliminary Project Plan, 10/1/15, Level 1 Requirements, https://www.arxterra.com/fall-2015-microbiped-preliminary-project-plan/
Microbiped Final Documentation, 12-09-2015, Project Schedule, https://www.arxterra.com/fall-2015-microbiped-preliminary-project-plan/
Microbiped Final Documentation, 12-09-2015, Final Video, https://www.arxterra.com/final-documentation-microbiped/

III.Literature Review:

A. Level 1 Requirements:

Fall 2015 MicroBiped did an amazing job in defining their level one requirements. While the majority of the requirements were met and exceeded, there were still minor mistakes that appeared. Some of the requirements were missing calculations that could have been included for further understanding of their thought process. For example, the incline degree was obtained from the obstacle without the explanation of how they got it. This confusion could be avoided if the team provided an image of the obstacle with measurements of the incline and some basic calculations. Below is the evaluation rubric of Fall 2015 MicroBiped Level 1 Requirement.

Evaluation questions for Fall 2015 MicroBiped Level 1 Requirements

B. New Requirements:

In the previous generation of MicroBiped robot, the ultrasonic proximity module was used. This sensor was added to the robot without a clear defined requirement for it. Therefore, this year’s team will implement a new requirement for the sensor that will enable the robot to completely stop when it detects an obstacle in its path and possibly having the robot navigate itself around the obstacle.

C. Project Cost:

Since Fall 2015 MicroBiped did not provide a final cost summary of their project, a preliminary cost of this year’s project will be a reflection of fall 2015 MicroBiped’s preliminary cost. Since, the preliminary cost is only an estimate, previous generations of MicroBiped’s project will also be looked at and taken into consideration. The Final Documentation of Spring 2015’s budget in particular was considered. In Spring 2015, their final cost of the project was $277.13 with some donations of parts. They collected a total of $122.00 in donations of parts. Therefore, the best estimation for this year’s project will be 400.00 with a margin of +/- 15%. The final estimation for this project will be approximately $400.00 +/- $60.

D. Project Schedule:

After taking into consideration the recommendation of the previous project manager, Paul Oo, and analyzing Fall 2015 MicroBiped’s schedule, the schedule of the project is critical to a project’s success. The Project Manager will collaborate with the systems engineer to create the most feasible schedule. In addition, it is important to also ensure that all engineers within the team follow the schedule closely to ensure the completion of the program.

E. Project Video:

The project video contains unnecessary humor that leads to its unprofessionalism. The project video should clearly demonstrate the engineering methods behind the project. Furthermore, subtitles would be a great addition to the video to clearly state what speakers are saying as some of the video was hard to hear with the background music.

Camilla Jensen (Systems Engineer)

I. Responsibilities

As a systems engineer, the main goal to make sure that the product and its system’s design meets the customer’s requirements by:

Systems design process: Meeting both the design and financial requirements for the project by looking at the system’s resources that are available and its cost effectiveness. The level two requirements will be set, after the level one requirements are defined by the project manager and the systems engineer.
Trade-off Studies: This method is used to determine the most feasible parts to design the system.
Technical Management process: Configuring the communication between interfaces. For the Velociraptor, that task includes configuring the mobile device app, Arxterra Application, to control the Velociraptor and sending signals wirelessly to the Arduino via Bluetooth.
- This requires coding in C++ written in the Arduino IDE, configuring the Arxterra Application, and implementing Bluetooth communication.
Product realization process: Generating product verification and validation test plans to ensure that each device will meet all defined requirements and validating it by testing prototypes until the final product can be manufactured.

Arxterra Application

The Arxterra application can be downloaded to any android phone. Then the application is used to communicate with the biped robot via Bluetooth.
- https://www.arxterra.com/bluetooth-interface-to-arxterra-application-in-progress/

Bluetooth (HC-06)

A Bluetooth component will be necessary to send data between the Arduino and a Bluetooth-equipped device such as an Android smartphone. Last semester used the HC-06 piece as well.
Bluetooth HC-06 datasheet:

https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf

Tutorial on how to setup the Bluetooth and Arduino:

http://www.instructables.com/id/Tutorial-Using-HC06-Bluetooth-to-Serial-Wireless-U/

II. Source Material

(1) Final Exam Fall 2015 Schedule Charts, 2/12/2016

http://web.csulb.edu/depts/enrollment/registration/final_exam/fall_chart.html

(2) Fall 2014 Biped Final Documentation, Detailed costs and schedule, 2/12/2016

https://www.arxterra.com/final-documentation/

(3) Project Biped, Programming, 2/12/2016

http://www.projectbiped.com/prototypes/prodos/programming

(4) Project Biped, Kinect, 2/12/2016

http://www.projectbiped.com/prototypes/fobo/kinect

(5) MicroBipedProject, Design of MicroBiped, 2/12/2016

https://www.arxterra.com/wp-content/uploads/2015/05/µBiPedProject-–-CDR_compiled.pdf

(6) The dinosaur-like biped robot TITRUS-III, 2/12/2016

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

(7) Spring 2015 MicroBiped Introduction, Mission profile, 2/12/2016

http://arxterra.com/micro-biped-intoduction/

(8) Bluetooth interface to Arxterra Application, 2/12/2016

https://www.arxterra.com/bluetooth-interface-to-arxterra-application-in-progress/

III. Works Cited

(9) Day to day parenting, Normal attention span by age (October 21, 2013), 2/12/2016

http://day2dayparenting.com/qa-normal-attention-span/

(10) Age determination guidelines: Relating children’s age to toy characteristics and play behaviour (September, 2002), 2/12/2016

https://www.cpsc.gov/PageFiles/113962/adg.pdf

(11) Tokyo Institute of Technology Hirose and Yoneda Lab, The dinosaur-like biped robot TITRUS-III (2010), 2/12/2016

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

(12) Friction and Coefficients of Friction, 2/12/2016

http://www.engineeringtoolbox.com/friction-coefficients-d_778.html

(13) United States Consumer Product Safety Commission, Toy Safety, 2/12/2016

http://www.cpsc.gov/en/Business–Manufacturing/Business-Education/Toy-Safety/

(14) NASA Systems Engineering Handbook Section 4.2 Technical Requirements Definition Start (page 40) and Appendix C page A: 279

IV. Level 2 Requirements Review

For the review of the previous semesters MicroBiped Level 2 requirements a list of questions from “The NASA Systems Engineering Handbook” [14] was used to determine the quality of each of the past level 2 requirements among others if these followed the tree structure and was linked to the level 1 requirements. To gain a better overview a table with the list of questions to which the requirements should answer yes to be a valuable requirement is shown in figure 1:

Evaluation questions for Fall 2015 MicroBiped Level 2 Requirements

For the first part of the level 2 requirements [1-4] the Fall 2015 MicroBiped project group did a good job stating correct quantitative requirements (Shall-statements), with accurate linkage to level 1 requirements and sufficient source material to verify facts.

On the second part of the level 2 requirements [5-11] the quality of statements fell short on some questions and these will be gone into detail. For the general part most of the requirements did not indicate the “shall”- statement to form an actual requirement.

Requirement #5:

To maintain balance by incorporating head and tail to the chassis is not a quantitative requirement. The link provided[4] was inaccurate referring to how the FOBO could be controlled by a human operator using Kinect and the Motion Control application, but neither was used for the MicroBiped. The link didn’t provide any verification for the incorporation of head and tail for the robot for it to improve its balance. Neither was any equations applied to verify that instalment of head and tail to the chassis would improve balance and therefore the linkage to level 1 req. 4 is also incorrect.

Improvement:

A back of the envelope calculation could verify if the instalment of head and tail will equal out the weight of the corps and thus improve the balance of the MicroBiped Hence the linkage to level 1 req. 4. Could be made since it will stabilize the travelling on two legs.

Requirement #6:

The source links provided[5,6] for the dimensions of the Biped doesn’t tell the actual dimensions of the Biped and therefore are not useful. Common logic can verify that the two-servo to one leg requirement will reduce the dimensions from the past robot using 6 servos per leg but there is no verifiable equations proving it correct. Thus the linkage to level 1 req. 5 is inadequate.

Improvement:

Again as for req. #5, a simple back of the envelope calculation of the dimensions of the past robot with 6 servos per leg vs. 2 servos per leg could verify if the this improvement will reduce the dimensions of the robot and thus verify the linkage and categorize as a MicroBiped.

Requirement #7:

The source material provided [7] doesn’t provide any information on the function of the gyroscope but only information on the mission profile of the Biped and the course it shall complete. Therefore the linkage is invalid and cannot be used to verify the linkage to level 1 req. 6 and 7.

Improvement:

Provide correct source material for the gyroscope indicating its function; how it will preserve the chassis balance when moving up an incline and over obstacles and thus verify the linkage to level 1 req. 6 and 7.

Requirement #8:

Good valuable requirement only stated wrong.

Improvement:

Correct to “shall”-statement.

Requirement #9:

Good valuable requirement. The source material provided indicates sufficient equations to calculate the friction of different terrains and thus verify level 1 req. 8. Statement is not of a requirement

Improvement:

Correct to “shall”-statement for the form of a correct requirement.

Requirement #10:

Good valuable requirement only stated wrong. No equations needed to verify this requirement and thus not provided.

Improvement:

Correct to “shall”-statement.

Requirement #11:

“The MicoBiped must avoid walls at a distance of (TBD). Determined by the mission profile.” This statement is utterly not quantitative, verifiable nor realizable. A requirement cannot contain a “To be determined” sentence as this is not giving anything to verify or realize and thus does not move the design progress forward but stall it. The requirement contains no equations but none are needed and no source material is provided. Likewise it is missing an actual link to the mission profile.

Improvement:

The distance of what the robot must avoid walls at can be determined from the customer’s objective or from the sensors range or and thus the requirement become quantitative. Provide a link to site of sensors and the requirement becomes verifiable. Last implement sensors and test prototype if requirement is realizable.

V. System Block Diagram

The system block diagram of the MicroBiped shows a good outline of how every device of the robot is connected to the brain, the microprocessor, and the brain distributes the commands from the control panel to the servos and sensors sends signals back to the brain to stabilize and navigate the MicroBiped successfully.

Ashlee Chang (Electronics & Control Engineer)

I. Responsibilities

The electronics and control engineer is primarily responsible for the selection of sensors, actuators, and power subsystems; laying out the circuit schematic; and compiling the C++ code necessary to control the operations of the velociraptor.

Sensors, actuators, and power subsystem options will be compared, selected, and then tested using a breadboard. Pros, cons, and trade-offs will be considered in the making of the decision. Parts under the responsibility of electronics and control for the velociraptor include: the battery, arduino + atmega32u4, ultrasonic sensor, servos, and the accelerometer.
Upon researching the requirements for the velociraptor’s electrical components, the fritzing diagram is ready to be laid out and tested on a breadboard. For circuit simulation, LTspice and Eagle CAD will be downloaded and utilized to map out the circuit before testing and future fabrication. After success, the results are given to manufacturing and design to implement the schematic on a printed circuit board.
C++ will be the primary coding language used to control the velociraptor.The ultrasonic sensor, accelerometer, and remote will be used as inputs to the microcontroller, and the program will carry out the necessary algorithms and relay the information to the servos to carry out walking and balancing operations.

II. Source Material

[1] Arxterra website, Fall 2015 MicroBiPed Summary

http://arxterra.com/?s=microbiped

[2] Arxterra website, Fall 2015 MicroBiPed Walking Code

http://arxterra.com/fall-2015-microbiped-walking-code/

[3] Arxterra website, Fall 2015 MicroBiPed Motion Sensor

http://arxterra.com/fall-2015-microbiped-motion-sensor/

[4] Arxterra website, Fall 2015 MicroBiPed Battery Updatae

http://arxterra.com/fall-2015-microbiped-battery-update/

[5] Arxterra website, Fall 2015 MicroBiPed Distance Sensor

http://arxterra.com/fall-2015-microbiped-distance-sensor/

[6] Arxterra website, Fall 2015 MicroBiPed Microcontroller

http://arxterra.com/fall-2015-microbiped-microcontroller/

[7] Arxterra website, Fall 2015 MicroBiPed Servo

http://arxterra.com/fall-2015-microbiped-servo/

[8] Arxterra website, Fall 2015 MicroBiPed Preliminary Design Documentation

http://arxterra.com/fall-2015-microbiped-preliminary-design-documentaion/

[9] Arxterra website, Fall 2015 MicroBiPed Power Budget

http://arxterra.com/fall-2015-power-budget/

III. Literature Review & Application to the Velociraptor (Based on Fall 2015’s MicroBiPed)

A. MicroBiPed Level 2 E&C-Related Requirements:

(4) To facilitate all the algorithmic functions of a walking BiPed, the Arduino MICRO with an ATmega 32u4 Microcontroller will be used to meet Level 1, requirement 4.

Verification: With the reduced amount of servos, the amount of PWM pins required are also reduced. Therefore the Arduino MICRO is the better choice in comparison to the Arduino UNO.

(5) To maintain balance (while retaining core features of a BiPed), installment of a head & tail will be incorporated to the chassis to adjust the center of balance and thus meet Level 1, requirement

Verification: The reduced freedom of movement also means less ways to balance while moving. To compensate, alternative appendages can be attached to maintain the center of balance while moving.

(6) To reduce the dimensions of the BiPed, the μBiPed shall use a two-servo to one-leg system to eliminate bulkiness and meet Level 1, requirement 5.

Verification: The previous semesters utilized 6 servos per leg to increase the articulation, but increased the bulk, weight, and the height. A more mechanical approach will be used to control the legs to imitate a velociraptor model.

(7) For the μBiPed to detect and adapt to inclines, a gyroscope shall be used to preserve chassis balance and meet Level 1, requirements 6 & 7.

Verification: Level 1, requirement 6 & 7 indicates that the BiPed shall move up and down inclines. To adapt to such scenarios, the μBiped must be able to keep the body balanced by adapting to its relative center of gravity.

(11) The μBiPed must avoid walls at a distance of (TBD). Determined by the mission profile. The distance may be determined based off of the constraints of the parts used to determine distance, or the customer may indicate distance.

Verification: Will have the μBiPed walk towards an object, i.e. a wall, and see if the μBiPed will stop or try and change path. The distance will be measured with a tape measure.

E&C Ashlee was present during the fall 2015 demonstration of the MicroBiPed showcased by Paul Oo and his design team. The MicroBiPed was only able to perform a “moonwalk;” the legs were moving, but the MicroBiPed’s position remained stationary. Upon placing the one of the MicroBiPed’s legs on a surface and the other dangling in the air, the MicroBiPed was unable to balance. The MicroBiPed failed most of the level two requirements listed above. Also noteable, the MicroBiPed only contained one servo for the head and tail.

B. MicroBiPed Fritzing Diagram

Fritzing diagram

This is the Fritzing Diagram provided by the E&C of previous semester. After choosing all of the necessary components, a fritzing diagram was created to map out the wiring before testing on a breadboard. The above components include: arduino, Bluetooth, gyroscope, ultrasonic sensor, and six servos. After successful testing on the breadboard, the message is relayed to the M&D division for printed circuit board designing.

C. MicroBiPed Walking Code (C++)

Walking libraries and coding in the Arduino software

Last semester, the data output type used was post width modulation (PWM) to control the servos.

The servo drivers were available on the website: https://github.com/adafruit/Adafruit-PWM-Servo-Driver-Library

D. Servo Motors

MicroBiPed servo

MicroBiPed servo trade-off study

The servo motors are responsible for converting electrical energy to mechanical energy, which will control the movement of the velociraptors head, tail, and two feet. Seeing the servos proved to be one of the most problematic issues of last semester, it is necessary to select one with a much larger torque. Comparing last to this semester’s servos, the JX PDI-6221MG provides 5x the torque of last years, but in addition also weighs 5x more. The trade-off are hefty, but the team plans to work around the cons of this vital component. Torque is a measure of “twisting force.” Servo specifications show that the units used are cm*kg. It can be calculated by using the cross product of force and distance, F = tau x d. With the torque specifications of the servo given, and the radius of rotation, a weight calculation can be made to see how much weight the servos can handle.

In order to address the concern of turning, two servos will be placed in each of the two legs in orthogonal planes to each other. The servos that rotate forward and backward will be for walking purposes, and the servos that rotate side to side are for turning.

In order to address the concern of balancing on an incline, two servos will be placed in each the head and tail in orthogonal planes to each other. The servos that rotate left and right will be for balancing (weight distribution) purposes while walking on a flat surface, and the servos that rotate up and down will be for balancing (weight distribution) purposes while walking up an incline.

Beginner-friendly video on the mechanics of servo motors:

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

Last semester’s servo:

http://www.headsuphobby.com/Towerpro-14g-MG92B-Digital-Metal-Gear-High-Torque-SubMicro-Servo-A-537.htm

Servo that the team is currently looking at for purchase (multiples of 4, x2, = 8 total):

http://www.banggood.com/4X-JX-PDI-6221MG-20KG-Large-Torque-Digital-Coreless-Servo-For-RC-Model-p-1031156.html

E. Accelerometer vs. Gyroscope

MicroBiPed gyroscope

MicroBiPed motion sensor trade-off study

This sensor is important for the velociraptor in terms of control balancing. Each determines the position and orientation of the object. The accelerometer may be a better option for this semester’s velociraptor (the previous semester went with the gyroscope.) The accelerometer seems more practical since the gyroscope measures rate of rotation around a particular axis.

The difference between the two sensors:

http://www.livescience.com/40103-accelerometer-vs-gyroscope.html

Last semester’s motion sensor:

https://developer.mbed.org/cookbook/ITG-3200-Gyroscope

Gyroscope: Uses the Earth’s gravity to determine orientation. It consists of a freely-rotating disk called a rotor, mounting onto a spinning axis in center of larger and more stable wheel. As the axis turns, the rotor remains stationary to indicate central gravitational pull, thus which was is “down.”
Accelerometer: measures non-gravitational acceleration. When an object goes from zero to some velocity, this sensor responds to vibrations associated with movement using microscopic crystals that go under stress when vibration occurs. From that stress, a voltage is generated to create a reading on any acceleration.

F. Ultrasonic Sensor

MicroBiPed Ultrasonic Sensor

MicroBiPed distance sensor trade-off study

This component will be able to detect objects a certain distance away without contact. The MicroBiPed had the requirement of detecting a closeby object, and as a result, maneuver around the object by turning. The Sain Smart ultrasonic sensor of last year was able to provide a measuring function of 2 cm to 400 cm of no contact. The ranging accuracy of this component can reach to 3 mm. The velociraptor has quite a few feet before reaching its obstacle, so this distance sensor would be an exceptional pick for this semester as well.

Last semester’s ultrasonic sensor (HC-SR04): http://www.sainsmart.com/ultrasonic-ranging-detector-mod-hc-sr04-distance-sensor.html

G. Microcontrollers

MicroBiPed microcontroller

MicroBiPed microcontroller trade-off study

Last semester used the atmega32u4. A trade-off study was conducted last semester between this microcontroller and the 328p. The servos and ultrasonic sensor will need eight and two PWM I/O pins, respectively. However, the 32u4 and 328p only house six and seven I/O pins, respectively. No compensation was documented on how the MicroBiPed team overcame this issue.

Last semester’s microprocessor (Atmega32u4):

http://www.atmel.com/devices/atmega32u4.aspx

Atmega328p:

http://www.atmel.com/devices/atmega328p.aspx

H. Power Subsystem

MicroBiPed battery

MicroBiPed battery trade-off study

The battery will be the last component considered. After reviewing all of the actuator and sensor power requirements, the battery will be chosen accordingly. MicroBiPed team’s deciding factor for this component was the fact it was rechargable, making it cheaper for the customer in long-term usage.

Last semester’s battery:

http://www.advantagehobby.com/106601/DYN1419/74V-2000mAh-2S-5C-LiPo-Receiver-Pack-18/?utm_source=google+shopping&utm_medium=organic&utm_campaign=product&gclid=CJSascKm88oCFQ6maQodXAMEYw

Mingyu Seo (Manufacturing Engineer)

I. Source Material

(1) Microbiped Project Requirements, Project Level 1 Requirements, 09-18-2015

https://www.arxterra.com/microbiped-level-1-requirements/

(2) Microbiped Project Requirements, Preliminary Design Documentation, 09-24-2015

https://www.arxterra.com/fall-2015-microbiped-preliminary-design-documentaion/

(3) Microbiped Final Documentation, Mass Budget, 11-27-2015

https://www.arxterra.com/fall-2015-microbiped-mass-budget/

(4) Microbiped Final Documentation, Stress Analysis, 12-09-2015

https://www.arxterra.com/fall-2015-microbiped-stress-analysis/

(5) Microbiped Final Documentation, Center of Mass, 12-09-2015

https://www.arxterra.com/fall-2015-microbiped-center-of-mass/

(6) Microbiped Final Documentation, PCB layout, 12-09-2015

https://www.arxterra.com/fall-2015-microbiped-pcb/

(7)Microbiped Final Documentation, Prototypes, 12-16-2015

https://www.arxterra.com/fall-2015-microbiped-prototype-2/

II. Work Cited:

(1) Robot Simulator: Dinosaur-like Robot in V-REP. (n.d.). Retrieved February 11, 2016, from https://www.youtube.com/watch?v=-u4Y6tWfYRg

(2) Chilson, L. (2013, January 26). The Difference Between ABS and PLA for 3D Printing. Retrieved February 11, 2016, from http://www.protoparadigm.com/news-updates/the-difference-between-abs-and-pla-for-3d-printing/

(3) What material should I use for 3D printing? | 3D Printing for Beginners. (2015, February 23). Retrieved February 11, 2016, from http://3dprintingforbeginners.com/filamentprimer-2/

(4) 3D printing versus molding. Retrieved February 11, 2016, from http://arxterra.com/3-d-printing-versus-molding/

III. Literature Review:

Manufacturing and Design Review of previous Biped Projects. This will include overview of previous Manufacturing and Design engineer’s approach as well as planning (focus on topics related to the importance of WBS (Work Breakdown Structure), materials and simulations).

IV. Overview of Manufacturing and Design Responsibility:

Create a prototype to test and validate subsystem commands provided by the Systems engineer.
Create 3D models using ‘Solidworks’ to run statics and simulations to determine the acceptability of the design.
Learn how to use CNC machines to fabricate components.
Design and print PCB and perform ERC and DRC checks.
Reflow soldering of the SMT discrete components and ICs onto the board.
Specify and order off-the-shelf parts.
Manufacturing will be responsible for full assembly of the Robot.

V. Note on WBS (Work Breakdown Structure):

The reason i have listed out the responsibility of the manufacturing engineer was to emphasize the importance of WBS (Work Breakdown Structure). Most of the blogs posted by previous microbiped had all engineers working on different research as well as tasks throughout the semester. The WBS not only assigns each engineer with specific tasks but also it helps the project manager to maintain and organize all procedure of the project. By simply looking at the dates of the blog posts, mass budget, stress analysis, Center of mass, PCB layout, and prototype was built and tested almost toward the end of the semester. According to microbiped level 2 requirement, the robot must be tested by December 10th 2015, but the 1st generation was tested on november 19th 2015. Due to limited time, the team was unable to run enough simulations using prototypes. The main problem was insufficient time to fix the robot which led to problems that will be defined below.
The three major problems that relate to the responsibility of the manufacturing engineer included size, weight and the joints of the robot.

VI. Size & Weight:

Previous generation components were made into solid parts which made the size of the robot exceed the project level 1 requirement, to be considered a miniaturized Biped Robot, exceeding the max height of (120mm). Solution to this problem was to create hollow parts rather than solid, and also in order to minimize the weight load on the body, we will be distributing our battery toward the head and the tail to evenly distribute and decrease the weight of the total robot.

VII. Joints:

Previous generation’s joints was unable to withstand the weight of the body, which led to the head and the tail not turning fast enough, and making the weight of the head and tail be held by the servos.In order to solve this problem, we will be designing a lever arm to allow the head and tail to move faster with the same torque, and design a new fram to hold the head and distribute the weight to the body, leaving the servos to only push the lever arms. Most importantly, we will be creating a 3rd joint to keep the legs more stable during static and dynamic walking as well as supporting the joints to hold up the weight of the body.

Velociraptor Solidwork prototype leg

VIII. Materials: (Prototype)

As a manufacturing engineer, the main task is to create a 3D model on Solidworks to run static simulations to determine the acceptability of the design. Through simulations, it will help us to determine the appropriate material that can withstand the weight of the body. Although running a simulation could determine the practical use of the material, it is crucial to print/mold components for our robot to actually run simulations for other possible problems. By looking at the chart below, we could compare the advantages and disadvantages between 3D printers and molding methods.
The previous generation created prototypes using molding method and wooden planks to build the joints for the robot. Although molding the joints could be a plausible material in building prototype due to the material’s strong resistance in heat as well as durability to withstand the weight of the body, it is very time consuming to create a mold and extremely hard reprinting the part. Prototypes should be built in a short amount of time with malleable materials such as plastic, wood or metal in order to easily customize and fix when a problem occurs. Through comparing 3D printing and molding, our team has decided to use the 3D printer for our first prototype. CNC machine has been excluded from our prototype material due to expensive printing costs and inability to make changes after.

3D printing versus molding method

Polylactic Acid (PLA)

The most optimal material that will be used for 3D printing is a Polylactic Acid (PLA) plastic, which is derived from renewable resources, such a cornstarch, sugarcane, tapioca roots or even potato starch. PLAs are widely used among home printers, hobbyists, and school making it easily accessible all through the semester. 3D printing parts are much quicker to produce, and allows the users to customize. One of the advantages of using a PLA is due to low melting point (50 ~ 60 degrees Celsius) of the material, we will be able to re-heat our printed components using hot air gun, for example, to modify the shapes to easily repair the components.

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.

Spring 2016 A-TeChToP Research Project

February 9, 2016/in A-TechTop Generation #4, A-TeChToP Wednesday/by A-TeChToP

By: Cody Dunn (Project Manager)

Omar Rojas (Systems Engineer: Emphasis Old Sensors)

Robin Yancey (Systems Engineer: Emphasis ECG) Read more

Fall 2015 MicroBiPed Summary

December 20, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

PROJECT SUMMARY

By Paul Oo (Project Manager)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Executive Summary

Project Objectives and Mission Profile:

Fall 2015 MicroBiPed (BiRex) is inspired by the BiPed designed by Jonathan Dowdall of Project BiPed. The profile for this semester’s project is to use the BiPed & μBiPed designs to create a toy robot. The chosen design for a BiPed toy is a Tyrannosaurus Rex. To push the profile towards a feasibility demonstration requires a large emphasis on performance and budget. The objective of this project is to complete an obstacle course whilst controlled and communicating with the Arxterra™ Android application.

The detailed changes made to the Project Objective and Mission Profile can be found here.

Design:

Figure 1 – Exploded Model

The image above shows the full 3D SOLIDWORKS structure. In this exploded view, the structure shows each individual component designed on SOLIDWORKS. Although there are additional components, (PCB, sensors, wires, and battery) this image shows the overall design of structure.

Details on the structure can be found further in this blog post under “Hardware Design.”

Project Features:

Figure 2 – BiLeg

Figure 3 – BiLegs

Figure 4 – BiHead

Figure 5 – BiTail

Figure 6 – BiFeet

The images above shows the creative solutions we implemented on this year’s µBiPed. During the production of the structure, our little BiRex was given the nickname of Bisexual T-Rex. Coincidentally, the name fit the design. Every one of these features have the capability to be flipped and still be functional.

Further analysis of Figure 6 (BiFeet) can be found in the Stress Analysis blog post.

System Design

Fig. 7 – System Block Diagram

The block diagram above shows the updated block diagram for BiRex. This system diagram shows the high level information; mainly connectivity between subsystems through their peripherals. The blocks are positioned based on their subsystem information. As taught in EE 346, the microcontroller (Arduino Micro) acts as the computer to receive (inputs) and send out (outputs) information throughout the whole system.

Each subsystem’s properties can be understood by reading the Updated Interface Matrix and Finalized System Block Diagram blog posts.

Experimental Results

Conducted Experiments:

List of Experiments
Title of Experiment	Type(s) of Experiment
Walking	Configuration and motion
Prototype	Leg, legs, and full structure
3D Printing	Servo holder
Battery	Power Budget
Gyroscope	Connection
Ultrasonic	Connection
Servo Driver	Connection
Servo	Leg, legs, and full structure
Ankle	Legs and full structure

The table above is a full list of experiments conducted after the PDR and up to the CDR. The titles that are bold are the next three topics (Battery, Prototypes, and Ankle) that give further information of each experiment.

Battery (Power Budget):

Item	Quantity	Max Consumption	Average Consumption	Total Average Consumption		Total Max Consumption
MG92B (servos)	6	0.7488170658	0.02	0.12		4.492902395
Arduino Micro (microcontoller)	1	0.85	0.37	0.37		0.85
Ultrasonic Sensor	1	0.015	0.015	0.015		0.015
Gyroscope	1	0.0065	0.0065	0.0065		0.0065
HC-06 (Bluetooth)	1	0.04	0.008	0.008		0.04
Total				0.5195		0.9115
			Regular Amps Available:	2	Surge Amps Available:	10
			Margin%:	284.985563	Margin%:	85.0343344

The above table presents the electronics subsystem that comprises of this year’s µBiPed project. The subsystem consists of both the main (Arduino Micro) and sub-components (servos, ultrasonic sensor, gyroscope, and Bluetooth communication). These components were then spec’d for quantity, max, average, total average, and total max current consumption. From this data, we used the specs from our chosen battery to find marginal current ratings.

The full description of the the system’s current draw can be found on the Power Budget blog post.

Prototypes:

This is the third video from the Prototypes blog post. This specific video shows how we used the prototype to get a better understanding for making our Bipedal robot walk. This model is considered the 2nd Generation (2.5) of prototyping BiRex. As you can see, it has difficulty walking. This lack of balance comes from the fact that our legs cannot support overall stability alone, thus verifying the need to add the head and tail.

Ankle:

Results:

Fig. 8 – Ankle: Stress Analysis

The von Mises test results. Solidworks allows you to determine which faces are stationary and which ones have forces acted on them. The ankle, which is the thick block, has all of the forces, and the red coloration indicates where the most vulnerable area is.

As a gauge, we considered the maximum force given by the robot as F = ma, which is the mass times the gravitational constant. In our case, 1.438 x 9.8 = 14.09N. The report indicated that the maximum force is above 65000N, which is way above our total forces.

Further details of the ankle design can be found on the Stress Analysis Blog Post.

Subsystem Design

Interface Definitions:

Table 1

Table 1 above show the 1st portion of project’s updated system interface definitions. The left side of the table has information on our subsystem components, while the right side is simply the microcontroller (Arduino Micro). Each component is then defined by its pinout data (pin number and pin symbol), which is then used as information for the microcontroller’s pinout.

Table 2

Table 2 above show the 2nd portion of project’s updated system interface definitions. Unlike the first table, this section focuses only on our servo interface.

Further details of interface matrix can be found on the Interface Matrix Update Blog Post.

Custom PCB Design:

Fritzing Diagram:

Fig. 9 – System Diagram

Breadboard:

Fig. 10 – Breadboard to Prototype (BinanoPed)

Schematic:

Fig. 11 – System Schematic

The system schematic blog post explains the steps needed to create an eagle file. The file used for BiRex is here: Eagle Schematic.

PCB:

Introduction:

The Final PCB layout is the responsibility of the Manufacturing engineer. To maximize the grade acquired for the assignment, a combination of through hole and SMD packages were utilized in the design.

Obstacles:

The problem presents itself when there are too many components on a board. Some components will have plenty of connections, sometimes to the point where there is no choice but to block other channels. Naturally, the solution to this would be to rotate the device. However, doing so can block even more channels. Another option is to create a double sided junctions. However, the double sided wires starts blocking other bottom sided channels utilized by other components. The only other option would be to go around it. Unfortunately, the free version of EAGLE has a limit of 2 in. x 2 ½ in; therefore, we do not have the liberty of space to maneuver around the conflicted part.

Final PCB Design. Note the part with the array of blue wires connected at the bottom left. That part is the servo driver, currently in the bottom of the board. Without it on the bottom, the order of the servo pins on the bottom would be convoluted.

The image above shows our finalized design for BiRex’s PCB. The red lines represent the copper tracing on top of the board, while the blue lines are underneath. An unpopular but effective method would be to have double sided SMD’s. By having an SMD on the bottom side, it is essentially mirrored by the axis that it is flipped on. This allows for some flexibility for routing.

Further details of interface matrix can be found on the PCB Blog Post. The full BRD file is provided here: MicroBiRex-Eagle.

Hardware Design:

3D Model:

The video above shows the simulation of the designed structure. The full STL file is provided here: Repaired. The full details can be found on the Center of Mass blog post.

Software Design:

Software System Block Diagram:

Walking Code (Introduction to IDE):

The walking code for the μBiped project was coded in the Arduino IDE using the basic syntax used in C, C++, and the like. The use of a servo-driver dictated the need of having the Adafruit servo-driver library (available here: https://github.com/adafruit/Adafruit-PWM-Servo-Driver-Library) added to the already existing Arduino libraries for use. The addition of this library allowed the use of more servos than would have normally been available using the Arduino alone.

PWM:

In order to control individual servos the Arduino would use PWM signals to the servo-driver with each PWM associated with a different angle. These different PWM values were then set in an array in order to allow smooth movement of the legs, head, and tail that the servos were made to control. In order to get smoother movement, longer arrays were required to show more individualized movements.

Fig. 1 – Include Files

The full details of the software design can be found on the Walking Code blog post. The full IDE file is here: IDE files.

Verification and Validation:

Test plans through verification and validation is needed to show the success of the project results. This document is then used by the course instructor. The document is essentially used as a checklist with results of the project tied to project and program requirements.

The full details of the test plans can be found on the Test Plans for Verification and Validation blog post.

Project Update:

Work Breakdown Structure:

The Work Breakdown Structure (WBS) is used by those that deal with higher level program information The list of those involved include, but are not limited to: Project Manager, Systems Engineer, President, and Division Managers.

Table 1 – Project Manager

Operation	Duration	Start	Finish	Resource Name
Project μBiPed	162 days	8/31/15	12/10/15	Paul Oo
Project Management	155 days	9/10/15	12/10/15	Paul Oo
Mission Objective	21 days	9/10/15	10/1/15	Paul Oo
Program Req.	21 days	9/10/15	10/1/15	Paul Oo
Work Allocation	21 days	9/10/15	10/1/15	Paul Oo
PDD	8 days	9/23/15	10/1/15	Paul Oo
PDR	7 days	10/1/15	10/8/15	Paul Oo
CDD	21 days	10/8/15	10/29/15	Paul Oo
CDR	7 days	10/29/15	11/5/15	Paul Oo
Documentation	168 days	8/24/15	12/9/15	Paul Oo
Final Presentation	35 days	11/5/15	12/10/15	Paul Oo
Project Video	70 days	10/1/15	12/10/15	Paul Oo

The table above (Table 1) shows the schedule created for the Project Manager. This schedule has been made to fit Fall 2015’s 400 D timeline and milestones. Furthermore, the schedule has been broken down according to program tasks (Mission Objective, Work Allocation, & Documentation). To improve this schedule, along with other members’, project managers should view this document from the first day of being assigned to their position.

The schedule for Systems, Manufacturing, and Controls Engineers can be found on the WBS blog post.

Mass Budget:

Mass is important for every project. The mass can affect both the hardware and software design. While, the components used for movement are affected by the structure (load), the software must account for the physical resistances the structure produces.

Part	Quantity	Individual Mass (grams)	Total (grams)	Margins
Servos	6	13.8	82.8	20%
#4 Hex Nuts and Bolts	18	20.7	372.6	10%
Frame	1	857.29	857.29	100%
Ultrasonic Sensor	1	8.5	8.5	10%
PCB (HC-06 & Arduino)	1	30.76	30.76	100%
Dynamite LiPo	1	86	86	10%
Grand Total (Grams)			1437.95	68%

The table above shows the data for mass of this year’s µBiPed project. The mass values obtained from data sheets are given a 10% margin of error. The frame’s mass is assumed to be an Aluminum build. Therefor, the mass may change drastically if a different material (polylactic acid) is more viable.

The full details of the mass budget can be found on the mass budget blog post.

Power Budget:

Power and Mass budgets are a bit more difficult to conclude early on. The reason comes from the changes that made to the structural and PCB designs as the semester progresses.

Item	Quantity	Max Consumption	Average Consumption	Total Average Consumption		Total Max Consumption
MG92B (servos)	6	0.7488170658	0.02	0.12		4.492902395
Arduino Micro (microcontoller)	1	0.85	0.37	0.37		0.85
Ultrasonic Sensor	1	0.015	0.015	0.015		0.015
Gyroscope	1	0.0065	0.0065	0.0065		0.0065
HC-06 (Bluetooth)	1	0.04	0.008	0.008		0.04
Total				0.5195		0.9115
			Regular Amps Available:	2	Surge Amps Available:	10
			Margin%:	284.985563	Margin%:	85.0343344

The above table presents the electronics subsystem that comprises of this year’s µBiPed project. The subsystem consists of both the main (Arduino Micro) and sub-components (*servos, ultrasonic sensor, gyroscope, and Bluetooth communication). These components were then spec’d for quantity, max, average, total average, and total max current consumption. From this data, we used the specs from our chosen battery to find marginal current ratings.

The full details to the battery used and power budget can be found on the battery update and power budget blog posts.

Progress:

There are a multitude of ways to record the progress of your project. We used project libre as our initial source for layout the schedule. Unfortunately, the software’s user interface just wasn’t well designed. Regardless, the progress had to be documented. The most useful tool for progress actually came from using action items from the group meeting notes. This table allowed us to keep in touch of how close we are to small and large milestones.

Systems Engineer Schedule

Systems Engineer – Work Breakdown Structure

Meeting Notes – Action Items

Project Video:

The project video is a summary of BiRex and how we used the engineering method to produce our final result.

Conclusion for 400 D:

In conclusion, although it may seem infeasible, sticking to the program schedule will be the deciding factor to how successful your project will turn out. The project manager and system engineer should work hand in hand throughout the entire schedule to plan and prepare for any contingencies. The work they distribute is then placed on the subsystem engineers: manufacturing, electronics, controls, etc. Below is the recommendations I have personally made for future 400 D students.

Scheduling – Realistic 15 weeks

Weeks 1 – 4 : Students have two responsibilities:

Become familiarized with their project (Project Documentation)
1. The professor should debrief the intensity of the course and progress made per project (suggesting the difficulty in learning curve per project)
2. The students should be assigned for their positions coming into the course (given that they are provided with brief and/or full outline of WBS)

Become familiarized with their roles (Role Documentation)
1. The students should be assigned role research as homework assignment:
  1. The students are then expected to present what they researched as an oral presentation (graded on content of information)
  2. Work with division managers to implement certain software assignments (then create blog posts off of what they learned)

The purpose of these assignments are then to create a PDR

Notes: High learning curve for Project Manager and Systems Engineer

Weeks 5 – 8 : Students have one responsibility: Apply new-found knowledge to implement PDR towards CDR

The Project Manager and System should collaborate for scheduling
1. The schedules can be referenced from getting access to Drive or PDR
The subsystems should begin tailoring the researched 3D model, PCB, and IDE files to meet their PDR (rapid prototypes)

Weeks 9 – 15 : More prototyping and testing

Documentation – Implementation (Project vs. Role)

Project: Arxterra – Archive

Archive blog posts for individual community

To make it clear, add the requirement of titling each blog post with Semester, Year, Community, and event of post.

Role: Drive – Meeting Notes, Folders, giving access

Meeting Notes should be the same format (use either BiRex’s) or template from Drive.
Folders should be implemented in Drive to allow clarity and ease of access.
Should the students need it, request for access to previous semester’s drive folders.

Role: Software – How-to, video blog post

The students should properly document their work and what they’ve learned.
1. How-To – Fractal Antenna is an example of a blog post that gives quantitative information.
2. Video blog post (record their work and orally annotate)

Fall 2015 MicroBiPed System Schematic

December 20, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

EAGLE SCHEMATIC

By Brian Walton (Controls Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction to Eagle:

Using EAGLE as a tool to build your schematic for all your subsystems offers multiple advantages:

1) Easy to use set-up aides with ease of schematic building
2) A large number of electronic companies support EAGLE and as such they provide libraries to add to your already existing EAGLE libraries to allow the use of their parts in the EAGLE software.
3) EAGLE comes with a built in PCB (Printed Circuit Board) software to easily go from the schematic to designing the PCB.
a) The available libraries allow using different size components as well as through-hole and surface-mounted components to add to the customization of the PCB to fit size and functionality requirements of the project at hand.
4) Building a schematic through EAGLE shows exactly what components are required for assembling the PCB allowing easy creation of a BoM (Bill of Materials) to simplify in the ordering of materials.

Our Eagle Schematic:

The full schematic can be downloaded from here: Eagle Schematic.

Fig. 1 – Complete Layout

Project μBiped, also known as Project BiRex and Project Little Foot, required the use of a servo driver, Arduino Micro, Ultrasonic, Gyroscope, Bluetooth, and Battery Reverse Protection.

Fig. 2 – Gyroscope

Figure 2 focuses on the gyroscope from the overall schematic. It was decided to place the IC (integrated circuit) for the gyroscope directly to the PCB instead of using through-hole pins for the component itself. As a result extra capacitors had to be added to maintain the functionality of the gyroscoope.

Fig. 3 – Bluetooth

Figure 3 focuses on the Bluetooth from the overall schematic. The HC-06 was placed directly onto the PCB to allow wireless communication with the Arxterra application on a phone. The layout chosen for the schematic dictated the use of a HC-06 without a backboard.

Fig. 4 – Servo Driver IC

Fig. 5 – Servo Driver components

Figure 4 focuses on the servo driver from the overall schematic. The servo driver IC was also laid directly onto the PCB, requiring extra resistors and a capacitor to maintain functionality. In conjunction with the servo driver, figure 5 shows the components needed to use the driver. It was required to have headers to be able to attach the servos to the PCB. Resistors were added onto the signal lines. The servo driver allowed the use of up to 16 servos which was quite a bit more than the 6 required for the project. The size requirement for the PCB allowed extra servo headers to be added to the design so the PCB allows for the use for up to 12 servos.

FIg. 6 – Arduino Micro and Ultrasonic Sensor

Figure 6 focuses on the Arduino Arduino and Ultrasonic Sensor from the overall schematic. The Arduino Micro and Ultrasonic were placed directly onto the PCB.

FIg. 7 – Battery

FIgure 7 focuses on the battery from the overall schematic. Battery Reverse Protection was added for added safety of components. The value of the capacitor used (1000 μF) was chosen based off of the number of servos used.

Notes:

Once the schematic is designed it is useful to label all connections and organize the schematic to aide in PCB design.
A copy of EAGLE can be downloaded here:
http://www.cadsoftusa.com/download-eagle/

Fall 2015 MicroBiped Walking Code

December 19, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

BIREX WALKING CODE

By Brian Walton (Controls Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction to IDE:

PWM:

Fig. 1 – Include Files

Fig. 2 – .h Files

Once the arrays started getting passed 100 individual elements the Arduino Processor no longer had enough memory to handle this. Therefor look-up tables had to be incorporated. Using look-up tables allowed the change from the Arduino being unable to handle the individual arrays (which at the time there were only 4 arrays), to being able to handle 12 individual arrays (only taking up 17% of the dynamic memory and 51% of program storage space). In order to use program memory, figures 1 & 2 show how all of the arrays had to be saved as “.h” files and saved in the same file as the Arduino program.

Array Variables:

Fig. 3 – Variable Names

Fig. 4 – Variable Names (2)

Fig. 5 – Variable Names (3)

Fig. 6 – Variable Names (4)

Figures 3, 4, & 5 shows the variables used in order to add ease to coding later. The variables i,j,k, and l were added in order to scroll through the individual arrays. The variables forward1 and forward2 were defined in order to communicate with the Arxtera application as the combination of these 2 variables would allow 4 different individualized movements desired by the project: forward, left, right, and standing still. The variables left1, left2, right1, right2, head, and tail are used to take the arrays and translate it to the 6 individual servos and allows the program to be more iterative.

Long Array:

Fig. 7 – Array Example

In the Arduino IDE the included files show up as long arrays in different tabs along the top of the IDE. The creation of these “.h” files were made in WordPad and is shown in Figure 7 & 8.

Fig. 8 – WordPad

In order to learn how to use program memory to save space Professor Hill gave an example that will walk you through the process: http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/(use the link that shows “Arduino_LookupTable.Zip”).

Fall 2015 MicroBiPed Verification and Validation Tests

December 16, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

VERIFICATIONS & VALIDATIONS REQUIREMENTS

By Railly Mateo (Systems Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Here is the link to the full Test Plans for Verification and Validation.

Fall 2015 MicroBiPed PCB

December 9, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

PCB DESIGN

By Michael Balagtas (Manufacturing Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction:

Obstacles:

There were some unforseen problems, however. When the board was mounted on the robot, all of the parts were nominal except for the ultrasonic pins, which are the 4 pins on the right of the picture. The pins were oriented in such a way that the ultrasonic was facing backwards; we needed to mirror the pins somehow. We used a daughter board to jury rig the pins into flipping to correct the mistake, which is the brownish board in the following picture.

Conclusion:

In summary, if the design needs a mirror, a double sided PCB can be utilized. However, it is important to note that it can limit the mounting capabilities. Furthermore, when using Eagle, having a reliable mouse aids in alleviating the amount of controls needed to design.

Fall 2015 MicroBiPed Center of Mass

December 9, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

WORST CASE SCENARIOS FOR CENTER OF MASS TESTING

By Michael Balagtas (Manufacturing Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introdcution:

Solidworks calculates the center of mass and the overall mass of the model based on the present stance of an assembly. While walking, it is important to have the center of mass as close to the most supported leg to maintain balance. Unfortunately, only Solidworks premium has the motion analysis option, which calculates the parameters while the model is in motion.

Method:

There is still an alternative to the center of mass study without the premium version, and that is with a worst case scenario test. That is, position the assembly in a manner where it is only supported by one foot, and the other is completely in the air. Naturally, there are two worst cases for a biped – one for the right leg and left leg worst case.

Worst Case Scenario: Right Foot. The information on the bottom comes from the mass properties option in the Solidworks tools tab. Note the purple axis on the robot. That shows the center of mass on the robot, which is close to the joint, which is a good thing while walking.

The image above shows the worst case scenario test along with mass properties on BiRex. The goal is to have the pink axis as close to the leg as possible. When the pink axis arrows are at the leg (with the foot that is planted on the ground), then the BiRex is balanced. Other methods outside of the frame could be used for compensation.

Conclusion:

For the 2015 Biped team, this method helped validate the Level 2 requirement of maintaining balance while the robot is walking. This does not account for other unforeseen problems, but this test helped with validating one of our core requirements.

Fall 2015 MicroBiPed Stress Analysis

December 9, 2015/in Biped Generation #2, Members and Communities, Velociraptor/by Plaulsible

STRESS ANALYSIS USING SOLIDWORKS

By Michael Balagtas (Manufacturing Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction:

(This blog is written to accommodate stress test studies on strain heavy designs).

Previous Biped Robots had multiple joints connected by the servos. As such, it was easy to assume that, so long as the servo enclosure was thick and strong enough, the Biped could withstand the forces acted upon it during operation. However, for the 2015 BiRex design, the legs and joints are all connected via screws and nuts for articulation. Also, in order to reduce weight and size, some parts were thinned and holed, reducing their durability. This presents the team with a problem with the strain put on the joints and the parts as the BiRex moved.

Solidworks:

The parts had to be designed just enough to be easily manufactured and durable for walking. To accomplish this, the SimulationXpress feature on Solidworks was used to analyze the part for breaking points. The Simulation allows a user to determine which faces of the part will have a force applied into it (in the team’s case, the ankles) and which parts are stationary. It then allows the user to pick the specific type of material that the part is made out of, to determine the constants. By pressing run, the simulation starts calculating.

Results:

The simulation then compiles a report in Microsoft Word that shows the simulation parameters and results. The most important is the von Mises Stress, which determines the force at which a material deforms. By being below this, the part is guaranteed to retain state after operation.

Spring 2016 Velociraptor: Research, Roles & Responsibilities

Table of Contents:

Velociraptor Team:

Khoi Vu (Project Manager)

I. Responsibilities

Camilla Jensen (Systems Engineer)

I. Responsibilities

II. Source Material

III. Works Cited

IV. Level 2 Requirements Review

V. System Block Diagram

Ashlee Chang (Electronics & Control Engineer)

I. Responsibilities

II. Source Material

III. Literature Review & Application to the Velociraptor (Based on Fall 2015’s MicroBiPed)

Mingyu Seo (Manufacturing Engineer)

I. Source Material

II. Work Cited:

III. Literature Review:

IV. Overview of Manufacturing and Design Responsibility:

V. Note on WBS (Work Breakdown Structure):

VI. Size & Weight:

VII. Joints:

VIII. Materials: (Prototype)

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

Project Manager Research

Missions, Systems and Test Research:

Electronics and Control Research:

Manufacturing and Design Research:

Spring 2016 A-TeChToP Research Project

Fall 2015 MicroBiPed Summary

Fall 2015 MicroBiPed System Schematic

Fall 2015 MicroBiped Walking Code

Fall 2015 MicroBiPed Verification and Validation Tests

Fall 2015 MicroBiPed PCB

Fall 2015 MicroBiPed Center of Mass

Fall 2015 MicroBiPed Stress Analysis

Like Us!