Fall 2015 MicroBiPed Summary

PROJECT SUMMARY

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

Executive Summary

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:

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:

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

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:

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

Breadboard:

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.

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.

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.

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:

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

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

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

1. The Project Manager and System should collaborate for scheduling
   1. The schedules can be referenced from getting access to Drive or PDR
2. 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

1. Archive blog posts for individual community

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

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

Role: Software – How-to, video blog post

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