Biped 2016 Fall – Final Documentation

Introduction Project Overview

Project Objective

Team Biped will produce a two legged 6th generation toy biped robot that will replace the traditionally used servos with a dc motor and achieve static walking. By utilizing the 3Dot Board, the robot will participate in the end of semester, December 14th, 2016, game called: Save the Human.

Mission Profile

Biped shall compete, alongside other toys such as Goliath and Velociraptors, in an end of semester approximately hour long game: Save The Human. Biped should successfully walk, using Goliath’s live video feed as the field of view, from the opposite end of the room to the finish area without coming into contact with a Velociraptor. The Biped will  maneuver through multiple obstacles by turning through walls, sensing color pads, and stepping through uneven terrain placed on top of Linoleum floors.

build4

Project Features

A key component of our design is replacing the ankles with servos. The ankle servo eliminates having to use two dc motors to accomplish a pivot turn. The placement of the servos provides a strategic way to balance on on foot and then turn the entire body to face the desired direction.

 

turning

Requirements

System Block Diagram

Interface Definition

Interface Matrix and Cable Tree

 

Mission Command and Control

Software Design

Arxterra App Communication

Custom Commands

custom-comands

Electronics Design

Component Selection and Trade Off Studies

Electronic Experiments

 

Firmware

PCB Schematics

PCB Layout

lay1

lay

Hardware Design

Hardware Experiment

Hardware Selection – Trade Off Studies

 

Verification and Validation Test

Project Status

Updated Mass and Power

Cost Report

 

Vendor Item Unit Price Quantity EE Dept. /Total EE Dept. Extended Cost
1 LOWE’S Miscellaneous Hardware 54.31 54.31
2 Mouser Electronics 27.82 27.82
3 Pololu Hardware (Motor/Gearbox/ Wires) 9.55 9.55
4 Hobby People Electronics (Battery/ Connectors) 16.33 16.33
5 Oshpark Color Pad PCB 0.60 0.60
6 Oshpark Shield PCB 20.45 20.45
Total: 129.05
Allocated Budget 125.00

Schedule and Burndown

Resources

[1] Project video

[2] PDR

[3] CDR

[4] Eagle Design

[5] Biped Code

[6] Solidworks 

[7] Animation/ Simulation

[8] PCB layout

Fall Biped 2016- Hardware Alternative Updates

By: Alan Valles (Electronics and Control)
Approved by: Ijya Karki (Project Manager)

Table of Contents

Introduction

The purpose of this document is to provide suggestions for the next iteration of the design of the PCB shield for the Biped. These improvements are based on feedback and experience in the manufacturing, design and build of the PCB.

Analysis

The engineering method is an iterative process. There are several suggestions and improvements that can be made to Biped schematics in [2]  to improve performance of the system.

The Schematics since CDR were not revised much. However, after the realized PCB system was put together and tested, there are several updates that I would make for the next revision of the shield. I would add pin headers for the I2C bus. This would allow for flexibility in future iterations for the Biped Project. In the future, I also would have changed the design to incorporate locking headers like the Ph-series of battery and motor connectors for the rest of the external peripherals. These will allow for more secure connections. The combination of jumper wires and pin headers was not a fixed connection and caused major amounts of headache due to contacts not connecting. It lead to perplexing troubleshooting in order to see if bugs were software related or hardware related.

33

Figure 1. Circuit System.

Next, I would add a protection circuit to prevent reverse current in the event of reverse polarity. The chosen lm1084 does not have this built into it. However, the battery was hooked up with reverse polarity the first time. The LM1084 was a robust chip because after reversing polarity of input the LDO still held up fine and output 5V to the rest of the systems. TI offers some quick suggestions to mitigate this issue, by using a protection diode or FET as shown.

34

Figure 2. NMOS FET in the Ground Return Path.

Next, The Ext- connection was not solidly grounded on the PCB, rather it created a GND connection on the 3Dot board itself. To correct this issue, traces and or vias to GND plane can be created near the connector of the Battery for stronger connection to GND. Finally, another issue was that 3.3V and Ext+ were being paralleled on the PCB that was ordered. After discussion and analysis, the president and I were able to fix this by isolating the connecting point by cutting a copper trace. The GND connection on the shield was never connected to EXT- connection on the 3dot. A small wire was post manufacturing. But the future shield should tie these point together at some point.  Also the SDA and SCL lines were crossed for A2D converter so that would obviously be fixed in next iterations.

35

Figure 3. After PCB in Production.

These are some of the changes that were recognized after our PCB was in production that should be fixed for the next iteration.

Conclusion

In conclusion, the pin headers for encoder connector, and other external peripherals would be changed to a locking style, a reverse current protection circuit would be added and various clean up work would be done such as tying GND to Ext-.

Reference

[1] http://www.ti.com/lit/an/slva139/slva139.pdf

[2] http://arxterra.com/fall-2016-biped-updated-schematics/

 

Fall Biped 2016- Color Sensor Design

By: Alan Valles (Electronics and Control) Approved by: Ijya Karki (Project Manager) Table of Contents Introduction  The purpose of this blog post is to explain the function and design of the custom PCB color sensor that was made. Analysis This color sensor was made to meet our requirements and detect color pads below. Two version […]

Fall Biped 2016- Verification Matrix and Validation

By: Brandon Perez (Missions, Systems, and Test)
Approved by: Ijya Karki (Project Manager)

Req. No. “The Biped Shall” Statement Success Criteria Method Results Pass / Fail

Introduction

This report covers the Test Plans for Verifying and Validating our Requirements.

Matrix

L1-1 Shall be ready to participate in the game “Save The Human” on December 14th, 2016. The project must be fully functional and presentable by December 14th, 2016. Demo FAIL
L1-2 Shall not exceed a cost of $125.00 to construct. The project must not exceed a budget of $125.00. Inspect PASS
L1-3 Will use a 3Dot board, have a custom PCB, and utilize the I2C interface. The project must contain a 3Dot board as the main control unit for the system, have a custom-built PCB, and utilize the I2C interface on the 3Dot board. Inspect PASS
L1-4 Shall be able to walk a minimum speed of 0.32mm/sec. The Biped shall have to walk a straight path at a speed of 0.32mm per second. Test FAIL
L1-5 Shall be able to turn up to 180 degrees on each of its sides. When the Biped is initiating a turn, the angle that it turns its body shall be any angle ranging from 0-180 degrees. Test PASS
L1-6 Shall be controlled telepathically up to 20ft away through the Arxterra App. When controlling the Biped via Arxterra Control Panel on a mobile device, the Biped shall be able to be controlled up to 20ft away from the user. Test PASS
L1-7 Will have a mass less than or equal to 750 grams. The total Biped’s mass shall not exceed 750 grams. Test PASS
L1-8 Shall be able to operate for a minimum duration of 1.00 hour. The Biped system shall have to operate for a minimum duration of 1.00 hour Test PASS
L1-9 Should be able to walk on angled surfaces with max slope of (+/-) 6.5 degrees. The Biped should be able to walk on inclines of 6.5-degree slope and declines of -6.5-degree slope. Test FAIL
L1-10 Should be able to walk on uneven surface heights of 0.5 cm or less. The Biped shall remain stable when walking over obstacles spread over the ground which shall have heights ranging from 0 mm to 5 mm. Test FAIL
L2-1 Will have a DC motor that can operate effectively at 5V and produce torque of 9.75e-3 ft*lbs. The DC Motor shall have an operating voltage of 5V or greater and shall have to produce a minimum torque of 9.75×10^-3 ft*lbs. Test PASS
L2-2 Will have servos that can operate effectively at 5V and horizontally move a mass of 68g. The servos being used to control the Bipeds arms shall have an operating voltage of 5V or greater and shall be able to turn horizontally the Biped’s arm’s mass of 80g. Test PASS
L2-3 Will have a rotary encoder to read the shaft’s position at a rate of 40 times the Motor RPM. The shaft encoder shall give a reading of the shafts position at a minimum rate of 40x[Motor RPM] to ensure the MPU has a resolution Test PASS
L2-4 Shall use an RGB LED to display the color of the color pad for a minute duration. When the Biped steps on top of the color pads, the color of the pads shall be displayed on the RGB LED for a minute duration. Test PASS
L2-5 Should have an IMU to detect inclines and decline angle deviations up to (+/-)6.5 degrees. The IMU should provide readings of the angle deviation when the Biped is walking on angled surfaces for all angles between -6.5 and 6.5 degrees. Test FAIL
L2-6 Will use a battery with a capacity rated at 560mAh or greater. The battery for the system must be rated at a capacity of 560mAh or greater. Inspect PASS

Level 1 Requirement 1:
Shall be ready to participate in the game “Save The Human” on December 14th, 2016.

Tools:

  1. Biped (final product)
  2. Calendar
  3. Clock

Procedure:

  1. If the Biped is complete, look at the calendar and record the current date.
  2. Look at the clock, and record the current time.
  3. Verify that the current time and date is before 9:30AM December 14th, 2016

RESULTS: By the time of final demonstration, the Biped was not able to walk. Our DC Motor Gearbox had gears that would constantly slip against each other causing our walk movement to stall at most times. In result, we did not meet the schedule requirement.

11

Level 1 Requirement 2:
Shall not exceed a cost of $125.00 to construct.

Tools:

  1. Biped Expense Report

Procedure:

  1. Look at the expense report and record the total Biped expenditure.
  2. Verify that total expenditure does not exceed $125.00.

RESULTS:

12

We have totaled $129.05 of expenses so we are $4.05 over budget. Regardless that we are over budget, we have still been within the customer’s contingency which is a reasonable 3.2% over budget.

13

Level 1 Requirement 3:
Will use a 3Dot board, have a custom PCB, and utilize the I2C interface.

Tools:

  1. Biped (final product)

Procedure:

  1. Inspect the Biped to verify a 3Dot board is being used when operated.
  2. Inspect the Biped to verify a custom-built PCB is being used when operated.
  3. Inspect the Biped to verify the I2C peripheral interface is being used when operated.

RESULTS: In the 3 pictures, below, we show 3 different perspectives of the of the 3DOT board and PCB encasement in our Biped.

The 3Dot’s board 12C peripheral interface pins are mapped to the custom built PCB for I/O access. Since we have a 3Dot board, a custom-built PCB, and are utilizing the I2C interface, this requirement has been met.

14

In the 3 pictures, below, we show 3 different perspectives of the of the 3DOT board and PCB encasement in our Biped. The 3Dot’s board 12C peripheral interface pins are mapped to the custom built PCB for I/O access. Since we have a 3Dot board, a custom-built PCB, and are utilizing the I2C interface, this requirement has been met.

15

13

Level 1 Requirement 4:
Shall be able to walk a speed of 0.32mm /sec.

Tools:

  1. Stop watch
  2. Measuring tape
  3. Biped with Arxterra Control
  4. Poster paper 3’x3’
  5. Marker
  6. String

Procedure:

  1. Mark the center point on the poster with the marker.
  2. Draw a circle of radius of 1ft around the center point using the string.
  3. Draw a radius on the circle.
  4. Place the Biped on the center mark made in step 1 facing the direction of the radius.
  5. Start a timer on the stopwatch and have the Biped operate its walking motion until it walks outside the circle and then stop the timer.
  6. Record the time it took for the Biped to reach outside the circle.
  7. Use V=D/T to determine the speed.
  8. Measure the angle at which the Biped walked with respect to the expected path to determine how straight the Biped walked.

RESULTS: Unfortunately, our Biped was unable to walk without falling over. To point out the obvious issues, too much mass had been concentrated in the front of the Biped which caused it to fall frontward. For improvement up our design, we should extend the feet out by about 1cm.

11

Level 1 Requirement 5:
Shall be able to turn 180 degrees on each of its sides.

Tools:

  1. Protractor
  2. 8”x11” white paper
  3. Marker
  4. Biped with Arxterra Control

Procedure:

  1. Place the Biped on top of the center of the White 8”x11” sheet of paper.
  2. Use the marker to draw a line directly out from where the Biped is facing on the white sheet of paper.
  3. Initiate the Biped to turn at angles ranging from 30 to 180 degrees in increments of 30 degrees. With each new turn, the Biped should be replaced facing its original direction.
  4. With each turn implemented, draw lines out from where the Biped is facing on the paper when it is in its new facing position.
  5. Determine how accurately the Biped performed the turns by measuring the angles of each of the lines with respect to the original position.

RESULTS:

We began this test by initiating a turn on the Biped when it was standing on one leg.

16

The Biped was able to take a turn here of 44 degrees when standing on one leg. The turning requirement was set to be accomplished when walking, however we were able to independently turn without ever be in the walking motion, therefore this requirement has been met to some degree of turning, literally.

13

Level 1 Requirement 6:
Shall be controlled in RC mode in the Arxterra App up to 20ft away.

Tools:

  1. Measuring Tape
  2. Biped with Arxterra Control Panel on Mobile Device

Procedure

  1. Start the experiment by initiating a custom command to the Biped at 2ft away.
  2. Make sure no obstacles are in the way when sending commands and repeat the process by moving 2ft further each time until the Biped does not respond to the commands being sent.
  3. Record the distance at which the Biped did not respond to the commands from the mobile device.
  4. Verify that the distance recorded is greater or equal to 20ft.

RESULTS:

We began this test by setting up the Biped 20ft away from the user who was sending commands via Arxterra control.

17

Due to limited time, we had only tested directly above 20ft away. In the picture you can see the view of a tape measure being extended out to confirm we were at least 20 ft away from the Biped to meet the RC Mode requirement. We could confirm that our biped was still able to receive commands at 20ft away, therefore we met this requirement.

13

Level 1 Requirement 7:
Will have a mass less than or equal to 750 grams.

Tools:

  1. Scale with accuracy of (+/-) 0.5g
  2. Biped

Procedure:

  1. Turn on the scale and set the reading value to grams (g).
  2. Place the Biped on the scale and read the value of the mass.
  3. Verify the mass does not exceed 750g.

RESULTS:

We begin by setting our Biped on the scale to determine its final mass.

18

The mass of the Biped is measured to be 466 grams. The mass requirement for our Biped is to be less than or equal to 750 grams, therefore this requirement has been met.

13

Level 1 Requirement 8:
Shall be able to operate for a minimum duration of 1 hour.

Tools:

  1. Biped
  2. Multimeter with current reading

Procedure:

  1. Measure the current drawn from the battery when the Biped is walking for the course of a minute.
  2. Determine the average current drawn from the battery over the minute duration.
  3. Verify that this value does not exceed the mAh rating on the system’s battery.

RESULTS: We begin the test by measuring the current drawn from the battery when the Biped is running the motor to produce its walking motion. We use an ammeter in series with the battery terminal and the DC motor pin. We recorded a video for a minute duration and then extracted the values from the ammeter throughout the video and provided them below.

We begin the test by measuring the current drawn from the battery when the Biped is running the motor to produce its walking motion. We use an ammeter in series with the battery terminal and the DC motor pin. We recorded a video for a minute duration and then extracted the values from the ammeter throughout the video and provided them below.

19

Data Collected from Ammeter: [0.68 0.14 0.12 0.14 0.10 0.19 0.09 0.37 0.33 0.93 0.47 0.48 0.38 0.35 0.44 0.41 0.45 0.40 0.47 0.33 0.42 0.61 0.57 0.42 0.37 0.88 0.39 0.53 0.64 0.87 1.14 0.98 0.64 0.82 0.46 0.48 0.29 0.33 0.58 0.41 0.55 0.39 0.50 0.56 0.72 0.90 0.40 0.60 0.49 0.71 0.40 0.66 1.21 0.75 0.34 0.39 0.52 0.35 0.36 0.98 0.42 0.54 0.54 0.51 0.71 0.72 0.76 0.96 0.78 0.51 0.59 0.34 0.31 0.26 0.62 0.33 0.20 0.28 0.25 0.20 0.42 0.51 0.62 0.61 0.43 0.57 0.66 0.45 0.36 0.52 0.42 0.38 0.45 0.32 0.18 0.22 0.28 0.32 0.20 0.41 0.37 0.48 0.52 0.58 0.27 0.29 0.35 0.27 0.14 0.22 0.19 0.16 0.13 0.20 0.21 0.29 0.40 0.55 0.46 0.55 0.48 0.46 0.40 0.34 0.23 0.25 0.35 0.37 0.25 0.30 0.24 0.35 0.31 0.29 0.49 0.54 0.48 0.56 0.62 0.38 0.24 0.19 0.15 0.25 0.28]

I then proceeded to calculate the average in MATLAB.

20

Since our walking motion is our most energy expensive operation, we can assume that we walk the entire duration of the game to get the maximum energy expense throughout the entire game duration.

If we assume the Biped will be walking the entire game, (which in reality, it won’t) it would consume 440mA x 1hr = 440 mAh of energy from the battery. Since our battery can provide 800 mAh of energy theoretically, then our battery should have sufficient energy for providing power to the Biped for the entire game duration of an hour.

13

Level 1 Requirement 9:
Should be able to walk on angled surfaces with max slope of (+/-) 6.5 degrees.

Tools:

  1. Biped with Arxterra Control (final product)
  2. Ramp of 6.5 degrees

Procedure:

  1. Operate the Biped and have it walk up against the incline and verify it doesn’t fall over.
  2. Operate the Biped and have it walk down the incline (decline) and verify it doesn’t fall over.

RESULTS: Unfortunately, our testing and design had been narrowed and focused towards the walking portion of the design, so we disregarded testing on inclines. 

11

Level 1 Requirement 10:
Should be able to walk on uneven surface heights of 0.5 cm or less.

Tools:

  1. Biped with Arxterra Control (final product)
  2. Cardboard cutout 6”x6” of 0.5 cm thickness

Procedure:

  1. Place the Biped on the floor.
  2. Place the carboard cutout a couple of inches away from the Biped.
  3. Operate the Biped and have it walk towards the cutout.
  4. Verify that the Biped can walk over the cardboard cutout without falling over.

RESULTS: Unfortunately, our testing and design had been narrowed and focused towards the walking portion of the design, so we disregarded testing walking on uneven surfaces.

11

Level 2 Requirement 1:
Will have a DC motor that can operate effectively at 5V and produce torque of 9.75e-3 ft*lbs.

Tools:

  1. DC Motor
  2. String
  3. Water bottle
  4. Scale
  5. Ruler

Procedure:

  1. Measure the shaft Radius for the DC Motor being used on the Biped.
  2. Divide the torque required [9.75×10^-3 ft*lbs] by the obtained shaft radius to get the weight.
  3. Fill the water bottle with water till it weighs as much as the value obtained in step 2.
  4. Tie the string several times around the motor shaft until it does not slip off.
  5. Tie the other end of the string the water bottle.
  6. Power the DC motor against the edge of a table with the water bottle hanging from the shaft.
  7. Verify that the motor can lift the water bottle.

RESULTS: We have set our DC motor torque requirement in the units of ft*lbs for making our calculation easier. We proceed to measure the diameter of our motor shaft to determine its radius.

We used calipers to measure the DC Motor shaft diameter.

21

T = F*L

T = 9.75×10^-3 ft*lbs

L = 2.6mm/2 = 1.3mm

1.3mm = 0.0043 in

F = (9.75×10^-3 ft*lbs)/(4.3×10^-3 ft) = 2.26 lbs = 36.28 oz

Since our DC Motor is already rated at 5V, no test must be done for the first part of the requirement. As far as the torque requirement, the DC Motor was successfully able to lift the gallon of water up, therefore this requirement has been met.

22

13

Level 2 Requirement 2:
Will have servo that can operate effectively at 5V and horizontally move a mass of 68g.

Tools:

  1. Servos being used to control the Biped’s arms
  2. Servo shaft connector piece
  3. Small tray 3” diameter
  4. Water Bottle

Procedure:

  1. Place the servo with the shaft axis facing upright.
  2. Attach the servo shaft connector and place the tray on top of the connector.
  3. Make sure the tray is secure on top of the servo’s connector.
  4. Fill the water bottle until it weighs 68g.
  5. Place the water bottle on top of the tray.
  6. Operate the servo and verify that it can turn over its full range while having the mass over it.

RESULTS:

Since our servo is rated at 5V already, no test is necessary for the first part of the requirement. To check if our servo can horizontally move a mass of 68g, we set the servo upright and attach a platform to carry the several different masses.

 

23

It was found through this experiment that the servo could horizontally move the masses on top of the platform up to 400g. We concluded that we that servo could meet the requirement so we suspended further testing of heavier masses.

24

13

Level 2 Requirement 3:
Will have a rotary encoder to read the shaft’s position at a rate of 40 times the Motor RPM.

Tools:

  1. 3Dot Board
  2. Rotary Encoder interfaced onto the 3Dot board
  3. Rotary Encoder test code

Procedure:

  1. Run the test code for the rotary encoder.
  2. Be sure to have a serial communication from the 3Dot board to your computer to see the sensor values.
  3. Turn the potentiometer of the rotary encoder and verify that the sensor can read values at various positions.

RESULTS:

We began this test by timing how long it too our motor to turn its shaft a full 360 degrees under the load of the legs it must move.

25

Time per motor revolution: 11.71sec

26

MOTOR RPM = (60secs per min)/(11.71sec) = 5.12

Therefore, our rotary encoder must read values at a rate of 40×5.12 = 204.8 times/minute to get a sufficient resolution of the shaft position.

We then began to try and measure how fast our rotary encoder could take values so wrote an Arduino code to write a timestamp after every rotary encoder reading.

Our values being outputted at the computer for time are in units of milliseconds. If you look at the picture at the left, you can see that each of the time readings are spaced by 4 milliseconds.

Therefore the sample rate for our rotary encoders ADC is 60/(4×10^-3 Hz) = 15,000 times per minute.

This sample rate is clearly sufficient for our system, therefore this requirement is met.

Level 2 Requirement 4:
Shall use an RGB LED to display the color of the color pad for a minute duration.

Tools:

  1. 3Dot Board
  2. Color Senor interfaced with 3Dot board
  3. Color sensor test code
  4. RGB LED
  5. Red, blue, and green construction paper

Procedure:

  1. Interface the Color Sensor and the RGB LED with 3Dot board.
  2. Run the test code for the color sensor and have the sensor readings output to the RGB LED.
  3. Place the red construction paper near the color sensor and verify the LED lights up red.
  4. Place the blue construction paper near the color sensor and verify the LED lights up blue.
  5. Place the green construction paper near the color sensor and verify the LED lights up green.

RESULTS:

We began testing the color sensor by seeing if our sensor was reading values. We placed the Biped above 3 different colored construction papers of color red, blue, and green.

27

The above pictures show our Biped testing the color sensor on the foot. To determine if our color sensor was reading the values, we send the sensor values via seirial communciation to be displayed on our computer.

28

We were able to successfully distinguish the color of the construction with the data we were receiving on our monitor. Our color sesnor was sucessful, however we were not able to display the value on the RGB LED since our GPIO expander on our custom PCB was having issues.

Level 2 Requirement 5:
Should have an IMU to detect inclines and decline angle deviations up to (+/-)6.5 degrees.

Tools:

  1. 3Dot Board
  2. IMU
  3. IMU Test Code

Procedure:

  1. Interface the IMU with the 3Dot through the I2C peripheral interface.
  2. Run Test code for the IMU on the 3Dot.
  3. Be sure to have a serial communication from the 3Dot board to your computer to see the sensor values.
  4. Once code is running, tilt the sensor at various angles.
  5. Verify that the sensor responds well to all angles being tilted at.

RESULTS: Due to limited time, we decided to not include an IMU in our final design since it would require more testing and its effectives would only benefit us if our system had already passed walking.

11

Level 2 Requirement 6:
Will use a battery with a capacity rated at 560mAh or greater.

Tools:

  1. Battery being used for Biped

Procedure:

  1. Identify the Capacity in mAh for the battery being used on the Biped
  2. Verify that the batteries capacity exceeds 560 mAh.

RESULTS:

29

Our battery is rated at 800 mAh, therefore this requirement has been met.

13

 

Fall Biped 2016- Interface Definition and Cable Tree

By: Brandon Perez (Missions, Systems, and Test)
Approved By: Ijya Karki (Project Manager)

Table of Contents

Introduction

This report will cover the interface definition and cable tree.

Table Information

1

Figure 1. 3DOT Interface Matrix.

On the top, here, we have our interface definition presented at CDR that has been updated to match our final Biped design. On the left, you can see the interface definition of the 3Dot board while on the right, you can see the interface definition for the 16-port GPIO expander that was included onto out custom-built PCB.

One of the changes that we made to the 3Dot interface was removing the second DC motor from the design. We worked with one DC motor to make design work. We attached both legs 180 degrees out of phase to the shaft output of our DC Motor gearbox.

On the GPIO expander, we removed the “body servo” which was supposed to helped shift the center-of-mass either in front of the Biped or behind the Biped when it would walk on inclines or declined, respectively. We omitted that servo because it was causing our Biped to weight up to 1kg with all the mass attached the servo.

 

Cable Information

2

Figure 2. Biped Cable.

Here on this image, we see the Cable tree which corresponds to the final design we have for the Biped. Since the “body servo” was removed, we have removed on set of cabling leading to one of the servos in the center of the figure right below the head. Our wire lengths and type for the servos correspond to the wires that our already on the servos. The cables for the servos are routed out of the head encasement and directly to the servos through a path between the legs. The wires for the color sensor that leads to the foot was the only set that was hand soldered and routed.

Conclusion

The interface definition and cable criteria are described above according to the design for the final Biped.

Fall Biped 2016- Motor and Battery

By: Alan Valles (Electronics and Control)
Approved by: Ijya Karki (Project Manager)

Introduction

The purpose of this document is to show all the updated schematic and hardware changes since CDR.

Hardware Design

The Final Hardware design of our robot was slightly different than what we had spec’d for CDR. The Motor stayed the same, it was a pololu 1117 size 130 motor. However, the gearbox that it went into was different. The final motor selected was the Tamiya 907710.[1] This motor was selected based on its gear ratio which was able to provide the Biped with even more torque than the previous model. Our Motor had an output RPM of m 11500 RPM at its shaft. We needed more torque due to the fact that our latest linkage design was larger/ longer than the previous design.  The Tamiya 70110 4-speed Crank Axle Gearbox Kit had 4 ratio option, 5402:1, 126:1,441:1 and 1543:1.

8

Figure 1. Speed Crank Axle.

These ratios dropped the output RPM to 2.2, 7.45, 27, and 16RPM respectively.

The only observed issue with this gearbox was that the gears internally seemed to be rubbing together when under large amounts of mechanical load. I noticed that there was an unsettling amount of play in the gears when it was put together.

10

Figure 2. Gearbox.

I suspect that once the load past a certain limit, the gears shifted to the left touched the high RPM green gear. This caused a clicking sound during random intervals of the walking motion.

Battery

9

Figure 3. Battery.

The battery was changed to a hobby people 7.4v 800mA Battery.[2] This battery was chosen over our previous battery because, we did not have to wait for shipping. Lithium batteries have a risk of catching fire which means that they are not shipped by air, only on trucks. Thus, it was much easier to go to the physical location of hobby people and purchase the needed battery and connector right on the spot. The form factor of the battery was absolutely perfect for our design as well. It had the dimensions of 12x35x68 mmm and weighted around 50g. Thus it was the perfect size for a RC Biped. Also, the pololu 117 motor had around 550mA operational current when attached to the 70110 gearbox. This was done by measuring it with a Digital Multimeter. Therefore, a rough calculation of power would be 650mA*5V = 3.25 W and the battery has a capacity of 7.4* 800mAH = 5.92 Wh. Thus, the battery still appears to meet our requirements that state we should play the game for an hour.

Conclusion

In Conclusion, The Battery and motor were changed to the hobby people 2S Lip and the Tamiya 70110 gearbox, respectively. This was done to increase the realized torque demand of the linkage assembly which was updated in order to meet customer request.

References

[1] https://www.pololu.com/product/68

[2] http://www.hobbypeople.net/index.php/hobby-people-7-4v-800mah-2s-30c-lipo-battery-bec-plug.html

[3] http://arxterra.com/fall-2016-biped-updated-motor-study/

Fall Biped 2016- Software Structure

By: Alan Valles (Electronics and Control)
Approved By: Ijya Karki (Project Manager)

Table of Contents

Introduction

The purpose of this document is to demonstrate software logic behind the Biped.

Analysis

The Fall 2016 Biped had a requirement which stated that the Biped had to be controlled using RC mode in the Arxterra App. The main feature of the app is a directional pad which is controlled by the Move Command. There is also a capability of adding Custom Commands. Electronics and System Engineers had several ideas and thought about the best way to utilize these. However, the backbone of our software and electronics subsystem design is a rotary position sensor. The selected rotary position sensor is the Bourns 3382. The rotary position sensor is a potentiometer that can spin forward up to 100000 cycles.[1]This means the inner rotor can be spinning freely.[1] All of the logic to be implemented is dependent on the readings of this value. As shown in the diagram below. The unsigned integer values between 0 and 1642. This value can be changed by setting the gain of the ADS1015 A2D converter in the set up loop. Therefore, logic can be implemented to control the robot in 330/360 of its walking motion.

3

Figure 1. Encoder Value

Thus, as the encoder value increases or decreases we continue to check to position and move the arms to the side of the foot that is planted. Ain0 shown in the picture above correlate to the variable adc0.

Poll a2d converter after every loop.

4

Based on position of walking motion i.e. shaft position, adjust arms accordingly.

5

Essentially when the user presses forward on rc mode in the move command, the robot will move and if the robot is on its left foot, the arms will move to left side and if on right foot, the arms will move to right side.

Also, the servohandler custom command was overridden to read color sensor and display LED using sx1509 gpio library. The final design was meant to use millis function inside loop as shown in reference [2]. It was commented out in the code that is uploaded to the zip file.

6

Conclusion

In conclusion, these are some of the code snippets for the Biped Group Design. Please see the Zip file for more information or our previous software blog post for library information.[3]

 

Reference

[1] http://www.bourns.com/pdfs/3382.pdf

[2] https://www.arduino.cc/en/Tutorial/BlinkWithoutDelay

[3] https://www.arxterra.com/fall-2016-biped-codesoftware-update/

Resources

[1] Biped Code

Fall Biped 2016- Quantitative Values for our Requirements

By: Brandon Perez
Approved by: Ijya Karki (Project Manager)

Table of Contents

Introduction

A final update of the requirements with completed values is provided below. The reason for preparing quantitative requirements is to ensure that during the validation and verification tests, we have more testable criteria.

Level 1 Requirements

The Biped shall statement…

  1. Shall be ready to participate in the game “Save the Human” on December 14th, 2016.

-Date has been determined for the semester duration and scheduling for class finals.

  1. Shall not exceed a cost of $125 to construct.

-Budget has been determined by the customer.

  1. Will use a 3Dot board, have a custom-built PCB, and utilize the I2C interface.

-These requirements have been set by the customer.

  1. Shall be able to walk a minimum speed of 0.32 mm/sec.

-Based on the expected arena size, we have estimated an expected worst case scenario   path of 45ft during the entire game duration. The red path on the picture below indicates an expected path for our Biped to travel which totals up to 23ft. We decided to double up the expected distance traveled due to a 100% uncertainty. With a 45ft distance to travel as a worst case scenario in a duration of an hour, we have set our minimum speed requirement to be 0.32 mm/sec because 45ft*(25.4mm/inch)*(12inches/ft)/(3600secs) = 0.32 mm/sec.

29

  1. Shall be able to turn up to 180 degrees on each of its sides.

-The servos that have been provided to us have a 180-degree range of motion. We can restrict this range of motion even less, but we have decided to work with this full range because we will be able to turn 180 degrees from any side, which means our robot has the capability of turning directly around no matter what foot is placed on the ground.

  1. Shall be controlled in RC mode with custom commands on the Arxterra App up to 20ft away.

We are to control the Biped in RC mode during the game as it is a requirement by the customer. Since the longest dimension of the arena is 12ft, we would operate the Biped at 12ft away in the case we were right at the edge of the arena with the mobile device on the floor.

  1. Will have a mass less than or equal to 750 grams.

We were provided the servos to our group by the customer at no cost, therefore we conducted an experiment to see how much weight the servo could handle on top of its shaft’s axis while still being able to operate properly. The reason behind this type of load test instead of the traditional motor torque test was because these servos are being placed underneath the legs of the Biped to act as ankles to help turn the Biped. It was found the servos would still be able to turn loads up to approximately 750 grams which had defined our mass limit for our Biped.

  1. Shall be able to detect color pads in the arena of red, blue, and green color.

One of the requirements for the Biped to participate in the end-of-semester game, “Save the Human” is that the Biped must be able to detect “power-up” zones upon which the Biped can have vulnerability against the opponents. The power-up zones will be indicated by red, blue, and green color pads.

  1. Shall be able to operate for a minimum duration of an hour.

The Game Committee, which is the organization of Project managers for the groups participating in “Save the Human”, have decided that the game duration will possibly take up to an hour.

  1. Should be able to walk on inclines and decline having max angle deviations of (+/-)6.5 degrees.

The angle climb requirement along with the maximum angle deviations have been set by the Game Committee. This requirement has been dropped from a “shall” statement to a “should” due to lack of progress with achieving walking.

  1. Should be able to walk on uneven surface heights of 0.5 cm.

The height climb requirement has been a traditional requirement following from previous generations of Bipeds for capability of climbing over small heights. The max height deviation of 0.5cm has been set by the game committee.

Level 2 Requirements

The Biped shall statement…

  1. Will have a DC motor that can operate effectively at 5V and produce a torque of 9.75×10^-3 ft*lbs to effectively move the Biped’s legs.

The DC Motor we are to use must be rated at 5V to operate effectively with the 5V supply from the 3Dot’s DC Motor driver. A torque of 9.75×10^-3 ft*lbs has been determined because the Biped’s legs weigh 70 grams = 0.15 lbs each, and are cranked at 1 cm = 0.0325 ft from the DC motors axis. We used the formula T=F*d to obtain the minimum torque required of our motors.

  1. Will have a servo that can operate effectively at 5V and capable of horizontally moving a mass of 68g to effectively move the Biped’s arms.

The servos that will be used to control the Biped’s arms must be able to move the combined mass of the 3D printed arms over to both the left and right side of the Biped. They must have an operating voltage of 5V or greater because they are being powered through the external power source which will be supplying 5V with the use of an LDO regulator. The servos must be capable.

  1. Will use a rotary encoder to provide data regarding the shaft position at a rate of 40xMotor Speed to help effectively keep the leg-movement system in synchronous with the arm-raising system.

The rate of the rotary encoder has been chosen to be a ratio of 40:1 with respect to the motor speed to ensure an optimum resolution of the motor shaft position during operation that way the Biped can maintain stability when walking.

  1. Shall use an RGB LED to display the color of the color pads for a minute duration when walking over the “Power-Up” zones.

An RGB LED has been chosen to be an indicator for the user to know that the color sensor has detected the color of the color pads. When the Biped picks up the color of the power-up zone color pads using the color sensor, the resulting color shall be displayed on the RGB LED for a minute duration.

  1. Should use an IMU to detect incline levels and correct its center-of-mass when walking on inclines and declines of (+/-) 6.5 degrees.

An IMU has been chosen as our sensor or chose for detecting when the Biped is walking on inclines or declines of max angle deviations of (+/-)6.5 degrees which is the value that has been set by The Game Committee.

  1. Will use a battery capable of providing 560 mAh.

It was found that the amount of current drawn during our most energy expensive operation, walking, was 560mA. We decided to use this basis as our average current drawn from the battery. If our system must operate for a whole hour, then our battery must provide at least 560mAh because 560mA drawn for the course of an hour will have resulted in 560mAh of total energy consumed.

Conclusion

This is the final update to the requirements that will be used to come up with the verification and validation matrix. Once the matrix is completed, Biped can begin conducting tests as proof of our accomplishments.

Fall Biped 2016- Design Document

By: Hector Martinez
Approved By: Ijya Karki (Project Manager)

Table of Contents

Introduction

Requirement

The Biped design correlates to all level 1 and level 2 requirements because the body will house all components.

This design document reviews the design process for Biped starting at week 9 of the semester. Up until week 9, the manufacturing engineer for Biped was Ijya Karki and I was co-engineer for manufacturing of Prosthetic Arm. Having done my research on prosthetics and robotic arms, I had zero knowledge of biped robotics. With two weeks until CDR, I had a steep learning curve. In order to be an effective addition to Biped, I had to understand the current design, model it on SolidWorks, and build a prototype. There was no time for me to research biped technology or come up with a new design so we had to move forward with the group’s current design.

Version 1

The Biped design at week 9 featured a weight shifting body, dual dc motor gearbox, shaft encoders, and servos. Weight shifting would be controlled by the servos, one servo would shift weight left and right to  aid in walking while the other servo would shift weight front and back to assist with incline walking. Shaft encoders would help track the position of each foot which would aid in coding. Everything would be housed in a multi layered body. This current design was under review by the current group and there were changes they wanted to make, I was asked to review the design and make changes necessary to ensure walking. I was also tasked with developing a turning mechanism because the current design did not have a way to turn.

13

Fig. 1 – Design of the Biped at week 9 of the semester.

While simulating on SolidWorks, I discovered the walking mechanism was unstable and a more robust system was necessary. Based on the above design, the group wanted two motors that powered the legs connected at the front and the back of the legs, opposed to one at the front, we believed this would solve the stability issues while walking. I came up with the idea of adding servos at the bottom of the feet to assist with turning. Adding servos to the bottom of the feet would create ankles, we would then attach new feet to the servo to complete a turn.

Version 2

14

Fig. 2 – Preliminary drawing of how arms could be used to balance Biped.

Before I start modeling on SolidWorks I always put ideas on paper, by doing this, I can start to think about what aspects of my ideas are feasible. For example, figure 2 is a drawing of an initial idea I had for arms that could be rotated forward or backwards with servos to help when walking on inclines. Seeing it on paper, I realized that this design would not help with level waking because there wasn’t a way to extend the arms out to the side to shift center of mass left or right. By putting my ideas on paper first, I was able to quickly realize that this idea was not useful for Biped. Had I decided to simulate on SolidWorks only, I would have spent considerable time designing before coming to the same conclusion.

15

Fig. 3 – Ver. 2 of Biped design, featuring a servo at the ankle that will assist with turning.

The group believed that instead of having a body capable of shifting weight, a simpler approach was to have weighted arms capable of rotating 180 degrees on the horizontal plane. This would accomplish level walking as well as walking at an incline. Figure 3 features the servo housed in the leg with a foot attached with a servo gear. While the Biped is mid step, it has to balance on one foot, if the servo is turned in this position the whole Biped can turn and complete the step in a new direction.

16

Fig. 4 – Ver. 2 of Biped, featuring two motors to power the legs and the servos inside the body to power each of the arms.

By rotating the arms forward or back, the Biped would be able to shift its weight forward or back while walking on inclines. While taking a step on level ground, one of the arms would extend out while the other arm is rotated forward. This will shift the center of mass of the biped to one of the feet so the free leg can take a step. Figure 4 features the two servos inside the body which would control each arm. Below the body are the two motors that will be used to control the legs. One motor is connected at the front link of the leg while the other motor is connected to the rear link. The legs would have to be 180 degrees out of phase with each other to produce walking.

One week before CDR, the customer was asked to review the progress of the current design and to our surprise he was not pleased with any part of it. The customer had concerns that the feet were too far apart and weight shifting would not be accomplished. He liked the idea of having arms to shift weight, but did not like that the arms were extended out at all times. Apparently there was some miscommunication as to the number of motors the customer wanted to use for walking, he wanted the Biped to accomplish walking using only one motor. The only thing the customer liked about version 2 was the servos at the ankle to accomplish turning.

Version 3

With a clearer vision of what the customer wanted, I needed a crash course on robotic walking. I sought the help of Aaron Choi the manufacturing engineer for Velociraptor and he pointed me in the direction of the Theo Jansen Biped (TJB) toy. The TJB featured a single crank shaft to produce walking and ball bearings which acted as weights to shift weight while walking.

17

Fig. 5 – Theo Jansen Biped toy that would become the inspiration for the final Biped design.

By incorporating a single shaft to produce walking, we would be able to use a single motor. The customer insisted on using arms to control weight shifting, therefore, we did not look into incorporating ball bearings as a mechanism in version 3 of our design. At this point, I was extremely overwhelmed and I was seriously questioning my new found abilities on SolidWorks. Luckily, Aaron had 8 weeks of research on Theo Jansen walking technology and helped me, a lot. With his help, I was able to produce version 3 of Biped.

18a18b

Fig. 6 – Preliminary sketch/design of Ver. 3 of Biped, featuring Theo Jansen linkages and a single motor.

For version 3 of Biped I decided to get really creative in the way I would incorporate the servo into the Theo Jansen linkages. As can be seen above, I decided to house the servo in between the bottom triangle of the Theo Jansen mechanism. I believed that adding a servo to the bottom of the triangle would cause Biped to be too tall and possibly unstable. Brandon Perez, our mission systems and test (MST) engineer, provided me with a motor that featured a single shaft which extruded from both sides of the motor. I could use this motor to attach the legs to the shaft at 180 degrees out of phase to produce walking. Additionally, the width of the motor and single shaft gave the Biped a total width of 5cm, versus 9cm from previous versions.

yello

Fig. 7 – Ver. 3 of Biped. Additional features include servo controlled arms that hang to the side, TJB legs, servo controlled weight at the top to control incline walking.

I continued designing taking into consideration our requirements. One requirement was to have color sensors that would be able to sense color pads on the floor. The figure above doesn’t show the sensor housing, but the reason for the boxy feet is because the sensors would be housed under the feet. We concluded that the best place for the color sensor would be as close to the floor since that’s where the color pads would be located. The figure below shows how these feet were designed as well as how the servos would attach to the feet.

19

Fig. 8 – Design sketches of color sensor housing as well as servo/foot mate.

For CDR, we featured a Biped which we expected to look much like the final product. I added weights to the arms and top rear servo to simulate weight shifting for level walking and walking on inclines. The motor, servos, PCB, and 3Dot were all at their final locations. The faint outline of a body can be seen in the figure below. We were very pleased with this latest design and were confident the customer would be as well.

20

Fig. 9 – Design presented at CDR featuring attached weights, PCB, and simulated walking.

Unexpectedly, we were received a lot of criticism for our design. Once again, the customer complained about the width of the feet. The customer raised concerns that the Biped was too wide and would like the legs to be much closer together. The customer did like how the arms could move, but did not like how the design was implemented. The customer also liked the body design but did not like the body length, he thought the body was too long and would prefer something shorter. The criticism only grew when we presented our prototype because the prototype only validated the concerns of the customer.

21

Fig. 10 – First prototype presented at CDR, the goal was to demonstrate static walking only.

The customer was not at all happy with our first prototype and gave us another week to present a second prototype. During the initial tests of this first prototype, we realized that the customer concerns were in fact right, the width of the Biped was too wide to be able to shift weight. We decided to scrap this design and work on something narrower. Figure 4 features the TJB toy with very narrow legs, the linkage design also incorporates weight shifting. Once again, I was under the gun to produce a new design in less than a week. Luckily we had in our possession, a TJB toy, and I was able to make all the measurements to create a design.

Version 4

22

Fig. 11 – Initial drawings of TJB crankshaft, lobe design, and spacing.

23

Fig. 12 – Leg design for Version 4/prototype 2 based on TJB toy.

24

Fig. 13 – Incomplete prototype 2 with TJB toy inspired legs.

For version 4 I decided to copy the TJB toy, literally. I measured all the linkages, created them on SolidWorks, and laser cut them on acrylic. Laser cutting turned out to be considerably faster than 3D printing and was ideal for prototyping. Although prototype 2 was still somewhat wide it was a start in the right direction because the Biped actually demonstrated balancing and something that resembled walking. To fix the width issue, we needed to source a shorter motor shaft. The current shaft was 6cm and we were able to find one that was 3cm. This new shorter shaft would allow the Biped legs to be closer together. We also had issues with the gear that was provided with the motor, because Theo Jansen linkages are specific dimensions, we needed to scale our linkages to match the size of that motor gear. We realized after the prototype was built and during prototype 2 demonstration the motor would stall because the gear would hit the leg linkages. Additionally, the servo in the ankle had to be scraped because the TJB toy has a very specific foot linkages that help shift weight, the servo between these linkages obstructed the motion necessary to shift weight.

Version 5

With the issues of version 4 resolved, I was able to move onto the body design. After doing extensive work with laser cutting, I figured it would be much faster to laser cut a body rather than 3D print. By laser cutting joints into the body pieces, I would be able to fit these together with little effort.

25

Fig. 14 – Sketches of what the body could look like. Featured are notches for easy assembly.

Based on CDR feedback, we knew the customer liked the body design which was inspired by the Star Wars ATST walker. We were not able to design arms that extended from the side of the Biped, the need for a narrow body restricted the amount of space available for additional servos. Instead I decided to house our external battery on a tray being held out by “arms”. These arms are laser cut on acrylic and the battery tray is screwed on to them.

26

Fig. 15 – Final SolidWorks design of Biped featuring TJB legs, servo at the ankles, ATST body, and arms holding a battery tray.

Manufacturing went right up to the day of the final. Along with Alan Valles from E&C, we worked through the night to produce a walking Biped. While Alan uploaded and tested code, I routed, soldered, and managed wires. During the final presentation we played in Save the Human game in which Velociraptor Bipeds from other groups were to attack our human biped. Unfortunately, our Biped did not perform as expected. We did not have enough time to test the walking code with the balance code to produce stable walking.

27

Fig. 16 – Final Biped project as presented on the day of the final.

We were able to test the turning code which did produce turning. I believe if we had managed our time better we would have definitely produced a walking Biped.

28

Fig. 17 – Final design balancing on one foot to produce turning.

Conclusion

The design of this project was a long and grueling endeavor. Looking back, there are some things I would do differently. First, I would make sure to have clear expectations from the customer. When the customer is unsure of what he wants, the manufacturing engineer is expected to come up with a design that will wow the customer. This is a lose-lose situation because if such a design is reached then you are now on the hook for delivering every aspect of that design, and designs that wow are usually very intricate and complex. If such a design is not reached, then the customer is able to reject all designs, wasting value time in the process. This is even more important in a case like mine, where I had 8 weeks to do 16 weeks’ worth of work. Secondly, don’t allow others to influence your design unless you want them to. By allowing other people to influence your design you lose track of the wants of the customer. This doesn’t mean you shouldn’t seek for help, by getting someone else’s input you are able to attack a challenge in a different way. Although this was a tough project, it was very rewarding. Our leg design was by far the most complicated design out of all biped projects. The legs actually moved in a motion very similar to the TJB toy and when placed on a surface to walk, the Biped was able to walk with some human help for balance. If this group was together from the beginning of the semester, Biped would have walked and turned successfully on the day of the final.

Resources

[1] Solidworks 

 

Fall Biped 2016- Foot Design

By: Hector Martinez (Manufacturing Engineer)
Approved by: Ijya Karki (Project Manager)

Table of Contents

Introduction

Requirement

“Shall be able to walk a minimum speed of 0.32 mm/sec.”

After CDR, we discovered that our foot design was inhibiting the weight shifting that the Theo Jansen Biped (TJB) toy provides. After careful inspection, it was noted that a simple design oversight resulted in a failed CDR demonstration.

Foot Testing and Design Methods

8

Fig. 1 – TJB toy foot with weight shifted on left foot.

The image above shows the TJB toy with its weight shifted to the left foot. Notice the link on the right with the metal cylinder, this ankle link is what causes the TJB to lean to the left and shift its weight. In this position, the right foot is able to take a step. Also notice that the ankle link is not perpendicular to the foot, instead, the angle between the ankle link and foot is necessary to allow the biped to lean. Without this clearance the biped would not be able to shift its weight and take a step.

9

Fig. 2 – CDR foot with changed orientation of mounting bracket for ankle link.

While designing our biped, I ran into an issue which I believed to have a simple solution. The links for our TJB inspired legs are being laser cut, all the links are oriented the same direction except the ankle link. I decided to change the orientation of the ankle link to match the rest of the links because this would make laser cutting easier. I failed to realize that by changing the orientation of the ankle link I also changed the orientation of the pivot angle.

10

Fig. 3 – Close-up of 3D printed foot for CDR.

Notice in the picture above that the pivot angle of the ankle link is now parallel to the foot and not perpendicular as shown in figure 1. This change caused the mounting bracket to collide with the ankle link, restricting the angle necessary to make the biped lean. There was not enough time to 3D print a new foot with the proper mounting bracket orientation, thus, a quick solution was to break the top of the mounting brackets and super glue a machine screw to hold the ankle link in place. This was by no means an ideal solution and in order to make the foot work properly and redesign is necessary.

Conclusion

11

Fig. 4 – Redesigned foot which will be used on final product.

In order to make the foot work properly the orientation of the mounting bracket for the ankle link had to be changed to match that of the TJB toy. Additionally, the ankle link will have to be 3D printed to accommodate the orientation of the mounting bracket as well as the orientation of the rest of the leg links, which are offset by 90 degrees.

References

[1] http://www.rubberbug.com/walking.htm

Resources

[1] Solidworks