Fall 2017 BiPed: Preliminary Design Document

By:

Piyush Jain (Project Manager)

Zachary Bruyn & Yasin Khalil (Electronics & Controls)

Natalie Arevalo (Manufacturing)

Melwin Pakpahan (Missions, Systems, & Test)

Program Objective

By: Piyush Jain (Project Manager)

The objective of Project BiPed is to design and manufacture a miniature bipedal robot. The BiPed shall incorporate a Theo Jansen leg design, use a single DC motor and mini servo for walking and turning, and shall use a similar joint mechanism as the 2017 Spring Velociraptor [1].

The model of the BiPed shall use the same principle mechanics as Theo Jansen models, with the design inspired by the 2017 Spring Velociraptor. The difference between the design shall be:

  1. The head shall be removed and the tail replaced altogether with a different system of allocating the mass to retain a proper center of mass.
  2. Replace clunky hip design with something more compact which has a smaller turning radius.

Mission Profile

The mission of Project BiPed is to design the BiPed to navigate a predesigned maze [1]. The BiPed shall be able to navigate the maze with user input from the Arxterra App/Control Panel. The BiPed will be able to memorize the user-defined path and will be able to navigate it autonomously. In addition, the BiPed will acknowledge other robots while traversing the maze and avoid collisions.

References:

[1] http://web.csulb.edu/~hill/ee444/2%20The%20Mission.pdf

Requirements and Verifications

Program Level 1 Requirements

By: Piyush Jain (Project Manager)

L1-1: The Biped shall be finished by Wednesday, December 13, 2017 [1]

L1-2: The Biped shall not exceed a budget limit of $250.00

L1-3: The Biped Shall be a toy robot.

Project Level 1 Requirements

By: Piyush Jain (Project Manager)

L1-4: The BiPed shall navigate the maze with user-defined inputs.[2]

L1-5: The BiPed shall memorize said user-defined path and navigate it autonomously.

L1-6: The BiPed shall navigate the maze in seven minutes or less.

L1-7: The BiPed shall navigate the maze without colliding into other robots.

L1-8: The BiPed will be controlled by a 3DoT board.

L1-9: The BiPed will be able to walk on cloth, linoleum, and paper.

L1-10: All electronic components shall be able to be disassembled and reassembled within 20 minutes.[3]

L1-11: All 3D printed robot components shall be printed in less than 6 hours, with no single print session taking longer than 2 hours.[3]

References:

[1] http://web.csulb.edu/gobeach/depts/enrollment/dates/registration.html

[2] http://web.csulb.edu/~hill/ee444/2%20The%20Mission.pdf

[3] http://web.csulb.edu/~hill/ee400d/Project%20and%20Mission%20Objectives.pdf

 

System/Subsystem: Level 2 Requirements

By: Melwin Pakpahan (Missions, Systems, & Test)

L2-1: Operate using the Arxterra Android/iPhone application. This includes navigating the maze, with and without user input, as well as turning and walking. L1-4

L2-2: Have Bluetooth communication which will sync with the Arxterra Android/iPhone application L1-3

L2-3: Be integrated with all the appropriate libraries to communicate with all electronic devices. L1-8

L2-4: Use a gyroscope/accelerometer to help navigate its way through the maze. L1-4

L2-5: Use a proximity sensor to detect and avoid other robots in the maze. L1-7

L2-6: Design the BiPed’s feet size to be approximately 3″ by 2.5″. L1-3

L2-7: Design the BiPed’s hip size to not exceed 3″. L1-3

L2-8: Design the BiPed’s center of mass shifting system to not exceed 5″ in length and width. L1-3

L2-9: Choose a motor which will provide enough torque to support the weight of the BiPed. L1-6

L2-10: Design the BiPed to be less than 1.5 pounds. L1-6

L2-11: Be powered by one RCR123A Lithium Polymer Battery which will operate for a minimum of 10 minutes before recharge.

L2-13: Utilize one mini servo for turning and one for the mass shifting mechanism. L1-6

L2-14: Be wired in a manner which is professional and shall not interfere with when navigating the maze. L1-6

L2-15: Have two leaf springs on each foot, for stability and flexibility of the feet. [1] L1-9

 

Design Innovation

By: Piyush Jain (Project Manager)

Working from the previous semester’s built BiPed chassis, the team came up with potential problems we might encounter. With respect to the customer’s demands, our main problems were turning the Biped, while maintaining a small turning radius, and the static walk, with the feet in close proximity, all while maintaining a proper balance for the BiPed. We decided we would focus on turning the BiPed as that is the biggest challenge. From our creativity exercise, we surmised different methods of turning including : having a 3″ or less turning gears for the hips, having a joint system similar to humans, and removing the turning gear all together and attaching wheels to legs to drive the BiPed through the maze. The first two methods were thought up during the brainstorming approach, while the last one was thought up during the attritube listing. After going over all our options, we decided to design a turning gear which will be less an 3″ because that will give us the greatest control in how the BiPed turns.

 

System/Subsystem Design

Product Breakdown Structure

By: Piyush Jain ( Project Manager)

Power

The Biped shall be powered by a singular portable CR123A Lithium Polymer Battery. The battery shall power the 3DoT board, 1 DC Motors, 1 Servos, I2C, and the Accelerometer/Gyroscope.

Actuator

The actuators for the BiPed are 1 DC Motors and Servos. The DC Motor will control the leg movement for walking, while the servo will control the turning mechanism.

Communication

The Software for the BiPed will be in C++ and written in Arduino sketch. The code shall control the motor functions and communicate with the Bluetooth module. The module will be controlled via the Arxterra control panel, synched to an Android or iPhone.

Manufacturing

With the chassis prebuilt, we will focus on creating an optimal design for the hip and feet. The hip shall be able to turn with a small turning radius, to fit within the parameters of the maze, while the feet shall be designed to stabilize the structure. In addition, the center-of-mass distribution shall be manufactured as to maintain a center of balance when walking and turning.

PCB

Our design will incorporate two PCB boards. The first will be the 3DoT board, provided by Professor Hill, which will contain the microcontroller and shall control the servos and motors. The second will be the custom PCB board which shall control everything else.

Electronic System Design

System Block Diagram

By: Zachary Bruyn (Electronics & Control)

 

The Microcontroller has inputs of the battery and input sensors. The battery shall power the BiPed and the Input Sensors; accelerometer/gyroscope and proximity sensor help to navigate the BiPed thru the maze. The Actuators; DC motors and servos help to physically move the BiPed. The communication device includes the Arxterra application, control panel, Android/iPhone, and Bluetooth device give the user the ability to control the BiPed.

Interface Definition

By: Melwin Pakpahan (Mission, Systems, and Test)

The interface definition shown below defines the pins of the ATmega32U4. The microcontroller has a modest selection of programmable pins to configure. In the future, trade-off studies will be conducted to determine which resources would best suit components and how to configure them accordingly [1]

 

 

 

 

Reference:

[1] https://www.arduino.cc/en/Hacking/PinMapping32u4

Mechanical Design

By: Natalie Arevalo (Manufacturing)

The overall design of this semester’s BiPed project can be broken down into four major sections: feet, legs, hips, and center-of-mass shifting mechanism.

The project as a whole can be seen as an iteration of the Spring 2017 Velociraptor project or modification of the Velociraptor project into a BiPed. As a result, the design of the BiPed will be kept as top-heavy however the head-tail component of the velociraptor will be eliminated. Although the body of the BiPed will be kept heavy to keep its moment of inertia small, the weight will be kept confined to the center-of-mass shifting mechanism as well as the servos and motors. In addition, stability in the legs and feet will be increased by using different materials as that of the previous project for the feet as well as by making the feet bigger to better distribute the weight along to using different springs.

Feet

The size of the feet will be increased so that the weight of the top-heavy robot can be better distributed as it’s walking. Additionally, the shape of the feet was also modified to minimize the amount of material to be used in the manufacturing. Since most of the weight of the robot will be exerted on the corners of the feet, just like how the weight of humans is placed on the toes and heels of the foot, the shape was kept with four major corners.

Back of envelope design

A trade-off study in conjunction with a simulation in SolidWorks will be later conducted to determine which design will work the best for the BiPed. Furthermore, the feet will be incorporated into the BiPed so that they can hinge as the robot takes a step. To increase the stability of the feet and therefore the ankle part of the robot, a leaf spring will be used in place of a traditional spring. The leaf spring will provide the better stability while still maintaining enough flexibility for the foot to flex at every step taken.

Legs

The leg design from the Spring 2017 Velociraptor project will be kept the same. The design used previously is the linkage system found in the Theo Jansen Walking Biped. The linkage system already mimics the kinetics behind walking. Furthermore, the design eliminates the need for taking into account the hinge movement of the knee since the leg rotates at the hip and creates that movement on its own. 

Leg Design Model from Wiki [1]

Reference:

[1] https://en.wikipedia.org/wiki/Jansen%27s_linkage#/media/File:Jansen%27s_Linkage.svg

Hips

 The hips as a whole are being made smaller in width so as to make them have a tighter look them. This is going to be accomplished by making gears in the hips that allowed the velociraptor to turn have a smaller radius. Additionally, the space between the universal joint and the rotating disk of the hip/leg will be made much smaller. With these two modifications, the hips will be made smaller in diameter which will decrease the distance of rotation during turning as well as decrease the time it takes the robot to turn and therefore navigate the maze. A quick Solidworks model is provided below based on preliminary talks on the optimal design.

Center-Of-Mass Shifting Mechanism

In order to modify the velociraptor design into a BiPed, the head-tail component was completely eliminated. As a result, a center-of-mass shifting mechanism had to be created in order to shift the center of gravity of the BiPed as it is turning so that the toy will not fall over during this motion. The inspiration for the mechanism came once again from the Theo Jansen Walking Biped. The weight shifting mechanism used in this robot can be seen here:

Essentially, this mechanism would be implemented in an automated version instead of a purely mechanical way. A weight will be placed as part of the body of the robot that will be slowly shifted by a motor to the opposite side of the pivot point of the BiPed as its turning. The modeling and simulation of this mechanism will be done in the future.

Design & Unique Task Description

By: Piyush Jain (Project Manager)

The BiPed shall incorporate a single 3.7v battery which shall power the BiPed through the three maze trials. The battery will be able to be recharged in between the trials. The BiPed shall use one mini servo and one DC motor to help turn and perform a static walk. The turning mechanism shall employ a small turning radius. The static walk shall ensure that the feet are kept in close proximity.

BiPed Tasks

  • Conduct trade-off study to choose the optimal DC motor and servo for given parameters. – October 11th
  • Create the fritzing diagram to test the breadboard. – October 10th
  • From the fritzing diagram create PCB on Eagle CAD. – October 16th
  • Using Arduino IDE to create control algorithm for the servo and DC motor – November 29th
  • Design Center of Mass part to maintain balance during walking, turning and stopping. – October 29th
  • Design lightweight and efficient models for the legs and hip. – October 15th
  • Configure proximity sensor to detect other robots while traversing the maze. – October 6th
  • Create Interface Diagram which is compatible with both 3DoT chassis and BiPed. – October 11th

 

Work BreakDown Structure

By: Piyush Jain ( Project Manager)

The Work Breakdown Structure displays in an easy to read manner for the tasks which need to be completed by the respected division engineers. It details the kind of work which has to be done, moving forward, in order to have a successful BiPed by December 13, 2017. The tasks were derived from the Lv 1 requirements agreed upon by the customer.

 

Project Schedule

By: Piyush Jain (Project Manager)

The Project Schedule details the project timeline from a Top-Level/Subsystem Level perspective. The Top Level consists of four main sections; Planning Phase, Design Phase, Assembly Phase, and Project Launch. These four sections help to guide the project towards mission success by breaking the work down into realizable goals.

 

The System/Subsystem Level was designed to complement the Work BreakDown Structure. It details the specific work which needs to be done by each engineer in their specific division. It allots specific time to each task such that the project will be completed by December 13, 2017. It is broken down into the Manufacturing, MST, and E&C division.

Top Level Schedule

System/Subsystem Level Tasks

 

 

 

 

Burn Down

By: Piyush Jain (Project Manager)

The Burn Down Schedule shows the amount of work needed to be completed in order for the mission to be a success. The blue linear line shows the ideal schedule for the amount of work per week.  The orange line indicates the actual work to be done. As shown, the work increases in loads as the semester progresses.

 

System Resource Reports

By: Melwin Pakpahan (Missions, Systems, & Test)

The Lv 2 requirement for the BiPed is to be under 850 grams or roughly 1.5 pounds. This was selected so the BiPed would be able to traverse the maze in a timely manner. A rough mass report was generated to guide us to hit our Lv 2 requirement. According to this report, we are well under the 850 grams. Our biggest item of uncertainty is the frame of the BiPed. It is estimated to come in at 300 grams, which is 200 grams less than the previous semesters’ design.

 

A preliminary power report is provided below. The power report is missing much of the Electronic & Control engineering work because we had many problems with the engineer. By October 25th, 2017 we shall have an updated power report.

Project Cost Estimate

By: Piyush Jain (Project Manager)

The main program requirement for this BiPed is that it shall not exceed $250.00. A project budget cost was formulated with this requirement in mind. As seen by the image below, we are well below the limit of $250.00. We are able to reduce the cost of this project by obtaining several times from Hill, including the DC motor and mini servo. Also, the sensors decided will be of low cost and optimal performance. The main cost of the project will be the frame of the BiPed because we decided to incorporate a more compact, yet sturdy design. The item of most concern is the custom PCB. Even with a $10 estimate, based on a quick research, we will need to conduct a more in-depth research as to which companies can provide us a high quality, low-cost single board.

 

Spring 2017 BiPed – Final Blog Post

By: Alexander Clavel (Project Manager)

Project BiPed Team:

Alexander Clavel (Project Manager)

Jacob Cheney (Systems)

Abraham Falcon (Electronics & Control)

Mikaela Hess (Manufacturing)

Executive Summary


Program Objective

The BiPed team was assigned the task of designing a 7th generation bipedal toy robot utilizing a 3Dot board. The robot was to use D.C. motors as the main driver for walking motion instead of the more frequently used servo based motion. Project Biped was to be able to demonstrate static walking and should be able to demonstrate the ability to dynamic walk and turn. Our project overall was to cost lest than $200.00 as well as be completed and ready to participate in the end of semester game on May 15th, 2017.

Mission Profile

The Biped shall be able to participate in the end of semester “Pacman” game where the goal is to navigate a maze while being remotely controlled. The velociraptor acts as the ghosts and attempts to catch up to the biped. If the biped is caught, then the velociraptor wins. There are also red colored dots placed around the maze that will count as points once a robot walks over it. The robot will then count the dot and continue on with the game. The time limit of the game lasts up to a maximum of 30 minutes. Viewing of the game will be provided by the spiderbot which will be hanging above the maze and relaying live video feed through the arxterra control panel. The game rules can be referred to here.

Project Features

Ankle Turning Servos

One of the main focus and key features of our robot is that we will use servos in the ankle to turn the robot. Traditionally when turning, you would change the speed at which the individual legs move reference to each other. You could  have one leg moving while he other remains stationary or you can even have them rotate opposite of each other. For our design, none of the would work considering that we were using just one D.C. motor to power everything. Since we had one motor that rotate both legs simultaneously, we thought to get one leg off the ground and then to turn it from there. This proved to be an acceptable solution and perfect feature for our robot.

 

Tilt Box For Counterweight

The other challenge for us was to be able to shift the center of mass of the robot to each leg as it would walk. Whenever a leg would lift up, the robot would immediately tilt over and fall. To attach this issue, we copied the idea from a Theo-Jansen video that was seen on the internet. The idea was to have a ball, or some sort of smooth weighted object move back and forth from side to side. The weighted object in question would obviously need to have weighed a majority of the entire systems weight to be able shift the center of mass, so mass allocations was a concern but we fell within requirements. In our design we incorporated a wooden box that would look like arms, and had a cam attached right beneath it to tilt the box back and forth effectively moving the ball back and forth.

This blog post goes more in depth with how the tilt box is essential to the robot.

http://arxterra.com/spring-2017-biped-working-prototypewalking-balancing-experiment/

Bluetooth Controlled Movement

The robot will be able to be controlled using the arxterra phone application or through a computer using the arxterra control panel. Due to the mission profile stating that we will be viewing game through a video, we needed to make the robot able to be controlled remotely. For our design we included a bluetooth module on the Arduino and from there was able to remotely control the BiPed. (3Dots were the planned component but through certain situations we were not able to use them and resorted to using an Arduino)

 

Simplistic/Straight Leg Design

For our robot we decided to go with  a straight legged design instead of the more popular approach of using linkages. A few reasons for this is that we wanted to keep the robot as light as possible and as simple as possible. Adding linkages means more parts and more connections that need to be held together and ultimately adds more weight. More connections means more fasteners (or something of the sort) and the linkages would add material stress into consideration in more places than we intended. Keeping a straight leg would limit our focus on stress to only a few areas. We also essentially wanted to start over from scratch  considering the last generation did not work with a D.C. motor source driven motion. If we were able to get it to walk, turn and succeed in all its functions, then the next class would be able to improve on  it even more. It would be a lot more difficult for a class to try and find out what was wrong with the last one and improve it, than get a perfectly functioning one and improve it.

System Design

System Block Diagram

The system Block Diagram shows the inputs and outputs of our robotic system. From the input side we have the HM-10 Bluetooth module that receives data from the Arxterra application and an Adafruit color sensor that detects when the Biped is standing on a red surface. For outputs we have two servos and a DC motor that enable the robot to walk and turn. Lastly we have 3 LEDs to provide a visual effect. Two will be the “eyes” of the robot and one will be toggled on and off based on the color sensor inputs.

Subsystem Design


Experimental Results

We were able to test out and experiment on all the key components of our robot. The main concerns are all listed in this section of the blog post.

Servo Torque Test

D.C. Motor Stress Test

Color Sensor Experiment

Servo Turning Test

Interface Definition

Custom PCB

The BiPed utilizes a total of 8 pins from the Arduino microcontroller. The left and right ankle servos are controlled by PWM pins 9 and 10 while the DC motor and color sensor are controlled by the I2C lines. Data will be transmitted through the Tx and Rx lines that are directly connected to the HM-10 Bluetooth module. All of the connected devices run off of the supplied 5V.

Mission Command and Control

Updated Software Block Diagram

The BiPed software contains six different subroutines. Five subroutines control the robots movements and one controls the color sensor and LED. The software begins by first decoding incoming data packets, then each subroutine is called based on the decoded command in the commandHandler

Electronics Design

Some of the main components to the robot would be the Pololu 200:1 D.C. motor. We chose this one specifically because it had high torque and would be able to move the robot even with all the weight we were placing on it. Further more, we only used one and that helped a lot with our mass allocations. There are other components such as HXT900 micro servos and a RGB color sensor. Additional information on the components can be found here.

Firmware

All of the code and firmware that was used to control the walking, turning, and color sensor can be found here.

PCB Schematic/Layout

We designed our PCB to be able to function modularly from the rest of the system. In short, the robot itself can still be able to perform its main function of walking and turning without it. The main purpose for the PCB was to be able to participate in the game. For that end, we needed the robot to be able to detect dots and to light up LEDs in accordance to those dots. Initially in our first design we had the PCB with many more functions. It had two more servos connected to it to serve as a way to shift the center of mass. Now that we are using a tilting box with moving ball bearings, that is no longer needed. It also adds to the simplicity of the design and allows us to keep everything as small and light weight as possible. Now that we have two less servos to deal with, it leaves more room for us on our mass allocations. The blog post above can provide more detail into the PCB.

Hardware Design

The above blog post is a show of one of the initial designs that we had previously had in mind. It again utilizes the straight leg, minimal linkage design. After progressing past this one we were able to look back on it and in retrospect really see where most of the flaws were coming from. Some of the key issues are as follows:

  1. Off-centered weight (D.C. motor sticking out of the body to the right)
  2. Unreliable pulley system
  3. Unacceptable leg design (overlapping)
  4. No center of gravity shift or consideration.
  5. Incorrect use of gear ratios (not specified in the blog post)

From these five lessons as well as others, we were able to come up with a better design and improve off the last one. The main difference with the newer design as opposed to the one before is that the dc motor is not centered in the middle. This makes it easier for balancing and the shifting of the center of mass. Now that most of the components are in the middle, the weighted ball can move from side to side at equal lengths. We also moved away from the pulley system completely. The blog post below as well as the images may provide better insight into the actual physical design.

Verification & Validation Test

We had written up our verification and validation in accordance to the new format which we had linked in the link below. The verification matrix is also included within the test plan and it documents all of the requirements that we were aiming to hit and those of which that we had not.

Verification & Validation Test Plan

Project Status


Power Allocation

The Table above shows the maximum current the robot can draw at one particular time. This would mean both servos and the DC motor are at full power. The max current draw is 600 mA with a 60 mA margin. Our battery can only supply around 650 mA at a given time so this means our contingency is actually negative. While this may seem bad, its an impossible scenario because our robot will never be running all 3 actuators at one time.

This table shows the max current of each actuator with the total capacity of our battery. The goal here is to ensure the battery has enough energy to power the Biped for at least 30 minutes. Since the robot will only be using one actuator at a time, the worst case scenario would be the Arduino (200 mA) and the DC motor (100 mA) running at full power. At 300 mA our battery is rated with a total capacity of 400 mAh. This means our robot will be able to supply power much longer than our desired minimum.

Mass Allocation

Cost Report

Receipt Vendor                Item            Unit Price Quantity Total Cost (Including Shipping) Purchased By
1 Pololu 200:1 Plastic Gear Motor 5.75 1 23.70 Abraham Falcon
2 Adafruit RGB Color Sensor w/ IR Filter and White LED – TCS34725 PID: 1334 7.95 1 23.94 Abraham Falcon
3 Mouser 1 K Ohm Thick Film Resistor 0.10 3 0.30 Abraham Falcon
3 Mouser Standard LEDs (Red Diffused) 0.360 2 0.72 Abraham Falcon
3 Mouser Standard LEDs (Green Diffused) 0.360 1 0.36 Abraham Falcon
3 Mouser 10 uF Multilayer Ceramic Capacitors 0.60 1 0.60 Abraham Falcon
3 Mouser 10 K Ohm Thick Film Resistor 0.10 3 0.30 Abraham Falcon
3 Mouser Semiconductors I2C Bus LED / LED Display Drivers 2.31 1 2.31 Abraham Falcon
3 Mouser Molex KK 100 Hdr Assy Bkwy / Headers and Wire Housing 0.27 2 0.54 Abraham Falcon
3 Mouser Molex BREAKAWAY HDR VERT 2 / Headers and Wire Housing 0.16 3 0.48 Abraham Falcon
3 Mouser (Shipping+Tax) 19.83 1 19.83 Abraham Falcon
4 Home Depot Acrylic Sheet 10.27 1 11.17 Alexander Clavel
5 Staples Staedtler Math Zip 4.99 1 4.99 Alexander Clavel
5 Staples Loctite Liquid Super Glue 5.99 1 5.99 Alexander Clavel
6 Amazon 120 Pc RC Parts Lot (Plastic Gears, Pulley…) 13.95 1 19.94 Alexander Clavel
7 Amazon Geebot Pulley Combination Package 9.99 1 9.99 Alexander Clavel
7 Amazon Ajax Scientific Plastic Loose Pulley, 50 mm Diameter 8.52 1 8.52 Alexander Clavel
7 Amazon Ajax Scientific Plastic Loose Pulley, 25 mm Diameter 8.21 1 8.21 Alexander Clavel
7 Amazon (Shipping +Tax) 7.81 1 7.81 Alexander Clavel
8 Amazon 2 of HXT900 9g Micro Servo 6.49 1 12.98 Alexander Clavel
9 Amazon 120 Pc RC Parts Lot (Plastic Gears, Pulley…) 13.95 1 13.95 Alexander Clavel
9 Amazon 10 PCs 2mm Dia 250mm Length Stainless Steel Rod Shaft 7.51 1 7.51 Alexander Clavel
Total: 184.14  Budget Allocation:

200.00

Updated Schedule

Top Level

Subsystem

Much of the top level schedule had remained the same mostly because most of the top level tasks had been completed. In the subsystem schedule you can see that some of the tasks mainly in electronics and control and in manufacturing had been pushed back some. This was mostly due to manufacturing’s inability to be able to produce and assemble a working prototype.

Burndown and Percent Complete

The project ended up being rushed at the end but we were able to finish on time. There were many bumps along the road like components not working, or accidental drops that hindered the progress of the project as a whole but in the end we were able to finish everything on time.

Summary / Concluding Thoughts


Results

In the end the project was completed on time. We were able to create a statically walking BiPed that was bluetooth remotely controlled and was able to turn up to 180 degrees. We stayed within budget costs and weight limits that were set. The only issue was that nearing the demonstration date, the BiPed was dropped and the timing for the tilt box was thrown off and ultimately threw off the entire walking motion. We continuously tried to solve the problem before demonstrating it, but we ended up running out of time. Although it did not walk on the actual day of the demonstration, we are happy that we were able to get a fully functional system running and working exactly as we had intended it to. We can strongly say that this is a strong base for the next class to try and improve on it especially because it is a system that works.

We also ended up running out of time because we had planned to laser cut the entire body our of plastic and to make it look sleek and nice. Due to being rushed and having limited time for testing, this was not able to happen. We had, at the end, printed out the head unit, body, and legs, but had not completed the tilting box, cams for the box, and the servo brackets to hold the feet. Ultimately it ended up looking like an evil Santa Claus due to the request of the customer wanting it to be more “toy-like” and fun looking.

The two different videos below show the BiPed in 2 different stages of its development. The first video shows the BiPEd with minimal weight on it and purely tests the functionality of it’s ability to turn and walk forward. The second video is in the final stages of its production and has (for all intents and purposes) the amount of weight that it would normally carry. In this test we decided to test out one of the requirements that it be bluetooth controlled from a distance of 5 feet. Jacob in the background is controlling the BiPed as it walks forward from a measure distance of 5 feet. All of this shows the success of the project in itself.

Video 1

Video 2

Lessons Learned/Future Suggestions

******THIS IS A MECHANICALLY CHALLENGING PROJECT*******

When you look at this project as a whole, we are studying to become electrical engineers and in all honesty do not focus too much on the physical aspects of a system. Granted, we have our basic physics courses and knowledge, but we are not experts on the mechanics of robots. That being said, manufacturing division must be a huge focus of the project managers from the beginning of the semester. From the very beginning you need to focus on getting a system that is structurally sound and something that works. If you cannot do that then, it does not matter how amazing of an electrical engineer you or any of your teammates are. If you cannot produce a testable system that is structurally sound, you will not be able to progress at all. The issue that I ran into with my project group was that at the time that my systems and electronics engineers were ready to test, my manufacturing had not yet produced a testable model. This was where the brunt of our time was spent. More time should have gone into studying and researching how to actually design the physical aspects of the robot. The assumption was that it was going to be quick and easy was one of our biggest downfalls.

The other very destructive aspect of our project process was that we spent much too long in the “creative” aspect of our design. There were many times where we keep throwing out ideas that we thought would be “cool” or innovative where instead we should have stuck to one idea, one solution and worked on it from there. There were three specific times where we worked an initial design and then from there, we thought of “a better way to do it”. We then scrapped the first option and completely started anew with the next one. This happened 3 times and it pushed us far back past our schedule than I had originally intended. This leads into the role as the project manager. Sometimes you just have to push your engineers. You cannot be worried about them liking you and you cannot have things be personal between you and your team. The project is a team effort and everyone has to do their part. If someone is slacking you have to be able to tell them in a firm manner that they are not performing the way that they should be. I made the mistake of trying to be too nice. I feel that in doing that, it gave certain individuals the idea that they were able to push due dates back on me. The difficult part that you will have to figure out on your own is being able to discern that sensitive line between destroying their motivation to do any work, and the firm hand that will keep them doing their job.

Lastly, when it really comes down to it and there is no other option, the project manager must step in to get the job done. There may be a time where a certain division is not doing their job and no matter what you do, they just do not improve or produce acceptable work. It is at that time that you must step in and just complete the work yourself. Whether you do that by getting help from the other division members/manager, or you step in to do the work yourself. As the project manager, results and ultimately mission success falls completely on you. Yes you may find a fault in one of your divisions, and yes it may be clear where things went wrong, but you are the one who’s job it is it make sure those don’t happen. I found myself in the situation where I waited to long to do just that. I could not wait any longer and I had to step in to build the physical aspect of the robot myself. It was done with just enough time, but it was a stressful and extremely arduous process. If I was able to identify the problem sooner and stepped in sooner, we may have been able to get in a few more tests than we had actually completed. We may have been able to make the robot more durable and last longer. The point is that you are ultimate quality control and the performance and quality of the project rests on you.

In summary:

  1. Focus on the physical robot mechanics and structural aspects
  2. Do the research, and not just when you think it is enough (Continually question your design for flaws)
  3. Do not jump around on options. Once you have picked a design, stick with it until you have exhausted all solutions
  4. Push project members to do their job
  5. Quality control the work that is being done by your members
  6. BE PREPARED TO STEP IN AND DO ANY JOB THAT IS REQUIRED

Resources


  1. Project Video
  2. CDR
  3. PDR
  4. Project Libre (excel Burndown)
  5. Verification & Validation
  6. SolidWorks
  7. Fritzing Files
  8. EagleCAD Files
  9. Code

Spring 2017 BiPed – Color Sensor Experiment

By: Abraham Falcon (Electronics and Control)

Approved by: Alexander Clavel (Project Manager)

Introduction

The electronics and control engineer job is to find the right equipment and test it for its project functionality. To make sure the biped can participate in the game it must have a color sensor to detect the red dots placed on the floor. This experiment was done to see if the adafruit color sensor can sense red and to discover what the best range of detection is. As per the requirements of our project, this test was able to verify that we were indeed able to detect dots as well able to detect the dots at the specified distance of 2mm.

Equipment

Material Quality
Arduino Uno (any family of Arduino) 1
USB Printer Cable 1
Breadboard 1
Male to Male Jumper Wires 4
Color Paper (Red)

(Any objects that is red in color)

1

Table 1

Arduino Code

The code below is from adafruit which can be located in the reference section of this post. The purpose of the following code is to be able to give feedback on the raw data of the colors. We were able to test this by placing different colors under the sensor and observing the given data.

#include <Wire.h>

#include “Adafruit_TCS34725.h”

Adafruit_TCS34725 tcs = Adafruit_TCS34725(TCS34725_INTEGRATIONTIME_700MS, TCS34725_GAIN_1X);

void setup()

{

  Serial.begin(9600);

}

void loop()

{

  uint16_t r, g, b, c, colorTemp, lux;

  delay(25);

  tcs.getRawData(&r, &g, &b, &c);

  colorTemp = tcs.calculateColorTemperature(r, g, b);

  lux = tcs.calculateLux(r, g, b);

  Serial.print(“Lux: “); Serial.print(lux, DEC); Serial.print(” – “);

  Serial.print(“R: “); Serial.print(r, DEC); Serial.print(” “);

  Serial.print(“G: “); Serial.print(g, DEC); Serial.print(” “);

  Serial.print(“B: “); Serial.print(b, DEC); Serial.print(” “);

  Serial.print(“C: “); Serial.print(c, DEC); Serial.print(” “);

  Serial.println(” “);

}

This code using the raw data from previous code from Adafruit will now check for red color since it is part of the requirements for the BiPed.

#include <Wire.h>

#include “Adafruit_TCS34725.h”

Adafruit_TCS34725 tcs = Adafruit_TCS34725(TCS34725_INTEGRATIONTIME_700MS, TCS34725_GAIN_1X);

void setup()

{

  Serial.begin(9600);

}

void loop()

{

  uint16_t r, g, b, c, colorTemp, lux;

  delay(25);

  tcs.getRawData(&r, &g, &b, &c);

  colorTemp = tcs.calculateColorTemperature(r, g, b);

  lux = tcs.calculateLux(r, g, b);

  float ColorAverage, RED, GREEN, BLUE;

  ColorAverage = (r + g + b) / 3;

  RED = r / ColorAverage;

  GREEN = g / ColorAverage;

  BLUE = b / ColorAverage;

  if (RED > 1.4 && GREEN < 0.9 && BLUE < 0.9)

  {

    Serial.println(“RED Detected”);

  }

}

Experiment

To perform the experiment, the color sensor was placed on the breadboard for easy connection. The color sensor itself  has four connections and the Arduino was powered by the computer through USB connection. The four connections that are being used are SDA, SCL, Vin and GND. Vin and GND are connected respectively to the Arduino for 3.3 volts and ground. Below is how the color sensor is connected to the Arduino to the computer.

Figure 1

Figure 2 shows the mini breadboard we were using to test the actual sensing of the color red. There were various other objects of different sizes and colors that were used to see whether or not the sensor is was picking only red or if there were any errors of any kind. We did not want the sensor to pick up a bright orange when what we really wanted was red. We were able to verify that it only detected red and on any other color would not light up the LED counter.

Figure 2

To conduct this test, the red mini breadboard was placed on top of the sensor to detect red and to see how this color sensor performs. Figure 3 shows the set up and how the test was actually performed. This was the first step to show that the components were performing the way we wanted it. Once we had verified that it was picking up red and only counting the red objects we then moved on to trying to find the optimal distance.

Figure 3

Figure 4

Figure 4 shows the test that was done to find out the operational range of the color sensor. The setup was very basic in the way that the color sensor was connected to the Arduino and placed side ways. A tape measure was placed along side it to indicate distance. The red mini bread board was then placed at varying distances. We initially put the sensor an inch away from the red object, but nothing was detected. From there we continuously moved the red object an eighth of an inch closer and closer until the red color was detected. The resulting distance happened to be about half an inch. This distance is well over our required detection distance of 2mm.

Analysis/Data

Table of Results

Color Sensor Operating Voltage (Volts) Operating Range for Biped (Inch)
Adafruit RGB Color Sensor 3.3 V 0.5 in

Table 2

Raw Color Data

Figure 5

Figure 5 shows the raw data for the colors, which are red, green, and blue. This sensor detects and uses this raw data as a reference code to be implemented to detect red for biped function. The raw data shown is sensing red green and blue, but the point was to take account of the red values. To do this we took the red, green, and blue raw values to a sum which will be called the average. So we then used the total raw values and then divided the specific color raw values to get the ratio of those colors from the sensor raw data. Using this ratio, we can make conditions where it reads only red when these conditions are true. In the section of Arduino codes, the code for reading red is provided. This code will help detect red and to be use for biped main code.

Arduino Serial Monitor Test of Detection

Figure 6

Using the previous codes to detect red the red mini breadboard was detected and shown on the Arduino serial monitor. This code is successful for detecting red and will be used for biped main code.

Conclusion

Performing this color sensor experiment we can see that this sensor will operate successfully for the biped to participate in the game. This sensor will help the biped be able to read red dots placed on the floor. It also shows that the color sensor will perform well and beyond the range of what is actually required. In conclusion the tests were successful and showed that the mission is achievable.

References

  1. http://www.makerblog.at/2015/01/farben-erkennen-mit-dem-rgb-sensor-tcs34725-und-dem-arduino/
  2. https://learn.adafruit.com/adafruit-color-sensors?view=all – programming

Spring 2017 BiPed – Arxterra Control/Code

By: Jacob Cheney (Systems)

Approved By: Alexander Clavel (Project Manager)

Introduction

During the final mission, where the BiPed will compete in the end of the semester game, it is required that our robot is controlled via Bluetooth. In order to accomplish this task, the BiPed will be equipped with a Bluetooth 4.0 transceiver that will receive commands from the Arxterra application on an iPhone. In this blog post I will be going over the design and test process that took place order to make wireless communication possible.

Custom Commands

The Arxterra application is a robotics iPhone app that was specifically designed to control a robot over Bluetooth. It works by sending packets of data to the BiPed where it will then be decoded to control our system. To ensure our BiPed is receiving the correct data, we must first define our custom commands within the app itself.

Figure 1: Arxterra Remote Control

Our BiPed utilizes 5 basic movements in order to navigate through a maze, they include walking, turning left 90 degrees, turning right 90 degrees, turning left 180 degrees and turning right 180 degrees. Because of this, we must create 5 custom commands to distinguish each function from another.

Within the app, each movement is assigned to a specific command ID. For our BiPed, the assignments are as follows:

Custom Command Command ID
Walk 0x01
Left Turn 0x41
Left 180 0x42
Right Turn 0x43
Right 180 0x44

Once the custom commands are defined, the app is ready to begin transmitting data. In order to actually do anything with these commands, we must now program the BiPed to decode the data packets.

BiPed Firmware

In this section I will go over the BiPed code and how it translates the incoming stream of data.

First we defined variables within the Arduino code that correspond to each command.

Next, within the CommandDecoder subroutine, every command packet the BiPed receives is broken down into individual bytes and read into an array called data.

Then the CommandHandler subroutine is called and assigns the variable cmd to equal the 2nd byte within the data array, this is where the command ID byte is found. Finally using if-else statements, the code is configured to call each movement subroutine based on the Command ID that was sent. This is shown below.

Looking at the code, you can see that I added Serial.print’s before every subroutine is called. This was used during the test phase to ensure the correct subroutine was being called when each command was sent.

Conclusion

After initializing all of the command variables and implementing a series of conditional if-else statements, the BiPed is now able to communicate wirelessly with the Arxterra app.

Spring 2017 BiPed – Working Prototype/Walking and Balancing Experiment

By: Alexander Clavel (Project Manager)

Approved By: Alexander Clavel (Project Manager)

Introduction

This post will cover an updated design of the last prototype as there were issues with functionality and acceptability by the customer. From the last design we had, it did not account for shifting the center of mass at all and had no way to balance its self during each step. Instead it used overlapping feet in which case was pointed out by the customer as unacceptable. This new design incorporates a similar gear box as the last with modified feet and an added balancing system.

New Design

Figure 1

The main difference between with the new prototype is the ability to shift its center of mass. That was also the main issue with the customer as he pointed out the sloppy and sluggish walking movement of the last prototype. Figure 1 shows what the new design is centered upon which is a tilt box with a moving ball bearing. The idea behind it is that as the BiPed takes each step, the box will tilt and roll the weighted ball to shift the center of mass onto the other foot. Timing was a big issue with this design as the mass had to be shifted just as the opposite foot was being planted to become the main support. If it was done too early or too late then the robot would have fallen over.

Another central design change is that instead of putting the DC motor slightly to the side, I put it directly into the middle as shown in Figure 3 below. This plays an important role in keeping the center of mass in the center and making it easier to shift the mass from one foot to the other. In this entire system as shown in the picture, the DC motor is what takes up most of the weight. As it is, the entire system weighs less than 200 g. What this means for the robot is that most of the weight is placed lower to the ground. This makes it easier to achieve static walking and keeps it more balanced as opposed to placing most of the weight at the top.

Method of Balancing

Figure 2

Figure 3

Figure 4

Figure 2 and 3 shows how the robot would stand on one foot to stay balanced. In figure 2, the box is shown to be tilted and in which case the ball bear is sitting on the left side (right side of the picture) of the robot allowing it to stand only on the left foot. Figure 4 shows the placement of the bearing  when shifting to one side. The feet in the images are a “C” shaped configuration, but it should not be confused with overlapping as in the last prototype. It is to be noted that the shape of the foot could be manipulated very easily, but for the sake of testing how balanced it would be, they were made to be large enough to be certain that it would cover wherever the center of mass shifted to.

This was the starting point to moving forward with the product. There are requirements stating that the BiPed should be able to statically walk which by definition is being able to maintain it’s balance throughout each stage of its walking. It should also still be able to stay upright even when power is shut off. This design evidentally works as shown in the pictures as there is not power attached to the robot but still is able to remain standing.

Walking & Static Balance Experiment

The design as shown in the figures above was not enough to keep it walking continuously. There was another CAM that was needed to be able to tilt the box back and forth. The completed prototype and design is shown in Figure 5 below.

Figure 5

Figure 5 shows the Biped in mid step as it starts to lift up its right foot (left side of the picture) and starting to shift its weight. The leg CAMs and the box CAM are all connected through to the same motor and share the same gear ratio so that the rotational speed is synced perfectly. As the feet are turning, the small pegs on the long metal shaft are rotating at the same rate. The position of the pegs is what allows for the shifting of the weight at the opportune moment. As a peg completes a rotation, the more elongated part of the peg will make contact with the box and tilt it up inevitably rocking the ball bearing to the opposite side. This took much trial and error to find the optimal positioning.

Once the optimal position was found, I connected the motor to the battery and let it run freely. The result was that it walked exactly as I wanted it and it was able to stay stable throughout the entire walk. Here a short video can be found as to the actual walking footage and balancing test.

Conclusion

In the end, static walking had been achieved but can still be improved on. The robot is able to statically walk but the inertia of the moving ball does seem to have a slight affect on the robot as it rocks the biped slightly. It is still able to walk in a straight line but it can be improved upon. The final design should include something to dampen the ball bearing like perhaps a sponge or spring as to soften the momentum. This should prevent the robot from any sort of falling due to any kind of sideways momentum.

Spring 2017 BiPed – Servo Turning Test

By: Jacob Cheney (Systems)

Approved By: Alexander Clavel (Project Manager)

Introduction

Based on mission objectives, where the BiPed has to maneuver through a maze in order to evade the Velociraptor, it is imperative that the BiPed is able to turn efficiently. Accomplishing this task is not as easy as it seems, as a bipedal itself must maintain balance at all times. The idea we came up with is to place one servo at the bottom of each leg to act as an ankle. Unlike a human ankle, these ankles will be able to turn 180 degrees to ‘twist’ the robot around to its new direction. Once the robot achieves its new desired orientation, it will take a step with the other foot and simultaneously reorient the original turning foot back to its starting position. This is required because the servos we are using can only turn 180 degrees.

In this section I will be discussing the code in detail and how it will translate to our mechanical design. For testing purposes, the only materials used were an Arduino Uno and a Hextronic HXT900 hobby servo that was attached to a square piece of hobby wood, acting as a foot. The V+ of the servo was connected to the 5V terminal, ground to GND and the signal pin was connected to digital pin 10.  This setup is shown below.

Code/Tests

Figure 1: Servo to Arduino Connections

Beginning with the initialization part of the code we start by including the servo.h file, which includes most of the commands we will be using. Then we defined our left and right servos and set our initial positions that we wanted our servos to start at.

 

Figure 2: Servo Initializations

Moving on to the setup function, we set up our Arduino outputs so that the control pin for the left ankle will be connected to digital pin 10 and the right ankle will be connected to digital pin 9.

Figure 3: Setup Function

Next we are going to skip over the main loop for now to talk about the different subroutines we will be using. For our mission, each ankle will have to do 4 movements; turn 90 degrees left, turn 90 degrees right, turn 180 degrees left, turn 180 degrees right. Depending on which leg is turning, these will be in a different order. For example, lets say the robot is standing on its left foot and wants to make a simple left turn. The servo will have to turn left 90 degrees, then turn right 90 degrees once that leg is off the ground to get back to its original position. If we started on the right foot, the servo would have to turn right 90 degrees first, then left 90 degrees the next time it is off the ground to return to its original position. The robot would also have to do the same exact series of movements to turn around except the servo will be turning 180 degrees instead of 90. In order to implement these movements, we will have to write one subroutine for each movement.

Since there are four movements for each leg, that would translate to eight subroutines total. These subroutines include; LeftTurnLeft, LeftReturnLeft, LeftTurnAround, LeftReturnAround, RightTurnRight, RightReturnRight, RightTurnAround and RightReturnAround. Each subroutine does exactly what the name implies.

Looking in to the left turning subroutine shown below, I will talk about the methods I used to accomplish the task.

Figure 4: LeftTurnLeft Subroutine

The implementation was simple. Using a for loop and the servo.write function, the servo moves one degree with a specified delay time in between, which determines the overall speed. For this subroutine I used a delay time of 20 milliseconds so the total time would be just 0.020*90 = 1.8 seconds to move from 0 degrees to 90 degrees.

Once I had one subroutine working, I was able to use the first one as a template for the rest. The whole list is shown below.

 

Figure 5: List of Subroutines

After creating our subroutines, we are finally able to jump into our main loop where each of the servo subroutines will be called. For the final mission, the BiPed will be commanded via Bluetooth. But for testing purposes only, I will be using the serial monitor to input commands. There are many ways to do this, but for simplicity I will be using the switch-case method, where certain letters will be translated into certain functions. The loop is shown below.

Figure 6: Main Loop

From the lower half of the screenshot you can see case ‘f ‘: LeftTurnLeft. This means that when ‘f ’ is typed into the serial command window, it will call the LeftTurnLeft subroutine with a delay time of 20 milliseconds. I cut off the rest of the cases but it continues to list every correlation between input letters and their subroutine.

Finally, after creating all of the subroutines and command inputs, it was time to test it out. Using the same connections that were laid out before, with the control pin connected to digital pin 9, I sent the commands through the serial monitor and verified the result.

Figure 7: Serial Monitor

It works! Not only did the servo follow the command, but the result is also displayed on the window. To test the right leg I just moved the control pin from digital pin 10 to digital pin 9 on the Arduino.

Conclusion

We were able to test all sorts of turning and verify that for our needs of the game and our mission objectives, we will be able to achieve mission success.

Spring 2017 BiPed – BiPed Prototype/Walking Experiment

By: Alexander Clavel (Project Manager)

Approved by: Alexander Clavel (Project Manager)

Introduction

The BiPed projects goal is to be able to create a walking bipedal robot that is able to perform static walking. The definition of static walking is walking that remains constantly balanced throughout the robots entire walk. In theory, when the power to the robot is cut off, the BiPed should stay standing and balanced. This is one of our main requirements. This blog post shows the process of building one of the prototypes.

Design/Construction

The overall construction which included buying all the parts and materials and then assembling them together took a little less than a day. We decided to go with a design that was found through reserach on youtube of walking bipeds. We were looking to find something simplistic as to be able to stay light on the material as well as the power draw on the electrical components. The BiPed we based this prototype off can be found here in a video. In the video, the biped uses a straight leg with no linkage and uses circular motion to walk forward. It is also a very small design that reaches a little under 20 centimeters in height which is something we would like to incorporate in ours.

Gear Box

Figure 1

Figure 2

This was the first attempt at using a gear/pulley combination to drive the robot. The white round gears on the outside of the wood area in figure 1 show the rotational movement that the legs would be taking during the walking motion and the actual legs would be connected to the metal pegs sticking out. The rubberband in the pulley in figure 1 would wrap up to the pulley that is attached to the motor in figure 2. I tried using a 1 to 1 ratio for the pulley on the shaft to the pulley that will drive the 2 gears next to it. From reasearch done and experience with cars, I learned that using a smaller radius for the driver to a larger radius produces more torque, but less speed. For our requirements we will be needing that torque to be able to drive the robot, but we will also need to keep it fast enough to pass our speed requirement. From this reasoning I tried a 2 to 1 or 3 to 1 for the purpose of testing the walking motion. The two additional bevel gears in figure 2 were to work towards a solution for the balancing problem, but it was never completely finished due the professor not liking the design of our feet (which overlapped each other) so the design was to be changed anyways.

Leg Design/Movement

Figure 3

As stated before, there is a single wooden board for the legs that use a rotational motion for the legs. Figure 3 shows a side view of the gear box where the legs would be attached. The bottom of the robot is to the right of the image. This being just a test, I placed the pegs very close to the shaft because I just wanted to at least see if it would rotate. The final product would have to have a larger radius from peg to shaft so that the robot will be able to get a decent distance with each step. Again our design was kicked back because the feet  that were attached were overlapping to account for the balancing. Without the overlapping feet, the balancing mechanism at the top of the robot would have had to be completed.

Conclusion

Figure 4

Figure 4 shows the entire main body of the biped attached. Again the rubberband is connected from the pulley in the gearbox to the pulley driver connected to the motor. The legs were not added to the image, but again, they are connected to the metal pegs sticking out on the sides. To restate it, the gear at the top of the robot is vestigal at this point and doesn’t serve a purpose for this prototype but should play a bigger part in the final product. When completely assembled, the robot shows that it does indeed give a clean walking motion while being held in the air. When placed on the ground the robot does “walk”, but it was a very rough, sloppy, and unbalanced motion. As it moves forward it does wobble side to side to a large degree, but at a very slow pace. Concluding comments would be that:

  • It does perform a walking motion
  • It does not stay balanced without the overlapping feet unless a balancing mechanism can be created
  • The walking speed is very slow.

There will need to be more adjustments to the prototype for application on the final product.

Referrences

  1. http://www.blocklayer.com/pulley-belteng.aspx
  2. http://tech.txdi.org/gearsandpulleys
  3. https://www.youtube.com/watch?v=Z7N0xCDVzIA&feature=youtu.be

Spring 2017 BiPed – D.C. Motor Stress Experiment

By: Abraham Falcon (Electronics and Control)

Approved By: Alexander Clavel (Project Manager)

Introduction

Electronics and Control engineer job is to do an experiment on the D.C. motor to see if it can the handle the weight needed for the biped to walk. The following experiment was to determine if the chosen D.C. motor can handle the Biped’s total weight while one foot is off the ground and the other supports the entire system. The maximum stress weight of the Biped was chosen to be at 500 grams which is also what was used to determine out projects mass allocation. The test was also done to calculate exactly how much power consumption came from the D.C. motor and to determine if this would be acceptable to last up to the 30 minutes duration for the Pacman Game.

Experiment

 

Table of results:

Servo Motor Stress Weight Operating Voltage (Volts) Stress Current

(Amps)

Pololu 200:1 Plastic Gearmotor 500 grams 6 volts 100 mA

 

This experiment was done by hooking up the D.C.  motor to a battery rated at 6 volts and with a digital multimeter in series. The weight of 500 grams was attached to a custom-built pulley wheel that was attached to the shaft of the D.C. motor. Also the radius of the custom-built pulley wheel was measured out to be about 1cm.

Here is an example of the D.C. motor connection without the weight and you can see that with no load the D.C. motor runs at the highest of 62.289 mA

The setup from above picture was used but added a custom-built pulley wheel to the motor with a weight of 500 grams. The D.C. motor lifted the weight of 500 grams and the current was measured. From observation, this D.C. motor can handle the stress weight of the biped at 500 grames and the current was measured to be at its highest of 100 mA. All recorded results from this experiment is listed on the table of results above.

Here below are two pictures of the custom-built pulley wheel which was used for the experiment of Biped’s stress weight.

Conclusion

Performing this experiment, it showed that this Pololu 200:1 Plastic Gearmotor will allow for the Biped to be able to walk and also shows that for the current, the power consumption is low enough for the D.C. motor to be able to last for 30 minutes. This experiment concluded that this D.C. motor will work and it does fit our requirements for this Biped. In the references section, there is a video starting from 5:01 till 6:02 that shows how the custom-built pulley wheel was made and used for this experiment. The second reference was also a basing of the setup of this experiment to lift the weight and measure the current of the D.C. motor.

References

  1. https://www.youtube.com/watch?v=YGjBOsd9Z2g&index=2&list=FLoSP5pt7W0bsWc1xuJASmww
  2. https://www.clear.rice.edu/elec201/Book/motors.html

Spring 2017 End of Semester Game “Pacman”

By: Alexander Clavel

Apporved By: Game Committee

Game Committee Members:

Amber Scardina – TRC President

Alexander Clavel – BiPed Project Manager

Nicholas Jacobs – Spiderbot Project Manager

Jesus Enriquez – Velociraptor Project Manager

Overview:

The BiPed and Velociraptor will participate in a game of PacMan. Both robots will start on opposite ends of a maze with the BiPed initially acting as PacMan and trying to avoid the other robot. The BiPed and the Velociraptor will attempt to collect as many “dots” or points as possible within the allotted time limit. The Velociraptor will initially act as the “ghost” and try to catch Pacman before the end of the game while also collecting points. The game will start once the Spiderbot has reached its position and begins video feed. The game will last a maximum of 30 minutes.

Rules:

–   Spiderbot will walk into the maze and then place itself above the maze for video set up

   Biped will start off as “Pacman” while the velociraptor starts as the “ghost”

  Both robots will start in different ends of the maze

   There will be red dots on the ground which will be “counted” and displayed on both robots as they pass over a dot.

–   If the Velociraptor reaches and “eats” the BiPed before the 30 minutes then the raptor wins

   If the Velociraptor does not “eat” the BiPed then the winner will be determined by who has the most dots counted.

   There will be special grid squares to make the velociraptor vulnerable to being “eaten” and will reverse the rolls

–   If the BiPed can reach the velociraptor within the time limit then the velociraptor loses.

   Live aerial video feed will be provided by the Spiderbot

   Time limit of 30 minutes OR when the ghost catches Pacman OR when one group reaches 5 dots first.

–   If a robot falls over, that will count as a deducted point and they will start again at their starting area.

–   Points will be deducted at the end of the game by subtracting the endgame amount from the number of times the robot has fallen

View and Control:

      BiPed and Velociraptor will view the gaming field through video feed provided by the Spiderbot

      Both Robots will be controlled through the arxterra control panel

Terrain:

      35 in x 56 in area

–       Flat paper taped across the tiled floor of the classroom

      No physical walls

–       The Maze will be printed on paper

      7 inch width for walkways for the robots

      Roof with steel area for magnet and supports made of wood for the spiderbot height TBD

 

Game map to be updated , Dots to be added***

SpiderBot and Velociraptor Starting Point – Left Opening

BiPed Starting Point – Right Opening

Spring 2017 BiPed – Servo Ankle Stress Experiment

By: Abraham Falcon (Electronics and Control)

Approved by: Alexander Clavel (Project Manager)

Introduction:

Electronics and Control engineer job is to do an experiment on the servo motor to see if it can the handle the weight needed to perform the funtion of turning at the ankle. The following experiment is to know if the chosen servo motor can handle the Biped’s weight. The stress weight of the Biped was chosen to be at 500 grams as to be the maximum weight, but our actual weight should be lower than this. The experiment is also to see if the power consumption of the servo will exceed our maximum of 500 mA.

Experiment:

Table of results:

Servo Motor Servo Location Stress Weight Operating Voltage (Volts) Stress Current

(Amps)

HXT900 Micro Servo Ankles 500 grams 3.3 volts 270 mA

This experiment was done by hooking up the servo motor to the arduino and the digital multimeter in series. The weight of 500 grams was attached to a servo plastic gear with a radius of 1cm.

 

Here is an example of the servo connection without the weight and you can see that with no load the servo runs at the highest 71.961 ma.

The setup from above picture was used but added the weight of 500 grams. To simulate the weight of the ankle from Biped weight the servo was put upside down and observed if the full rotation of the gear on the servo with the weight performs well. By observing the weight on this servo, it can handle the stress weight of the biped and the current was around 270 mA.

Conclusion:

The experiment was preformed and showed that this HXT900 Micro Servo will make Biped be able to turn on the ankles and the current shows that the power consumption is under 500 mA. This experiment concluded that this servo will be effective for the ankles to turn. In the references section shows a video of the servo torque test of this type of servo chosen and this was a guide to perform this experiment.

Referrences:

  1. https://www.youtube.com/watch?v=dCgiE0xpToI&index=11&list=FLoSP5pt7W0bsWc1xuJASmww&t=168s