Fall 2016 BiPed : Preliminary Project Plan

Gifty Sackey (Project Manager)

Brandon Perez (Systems Engineer)

Ryan Daly (Electronics and Controls Engineer)

Ijya Karki (Manufacturing Engineer)

Table of Contents

Work Breakdown Structure

Gifty Sackey (Project Manager)

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

final-wbs-tree-diagram

Figure 1 : Work Breakdown Structure

Product Breakdown Structure

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

product-breakdown-structure

Figure 2 : Product Breakdown Structure

 Project Schedule 

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

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

Burn down and Project Percent Completion

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

breakdown-chart

Figure 3 : Breakdown Chart

Project Cost Estimate

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

cost-report-2-1

Figure 4 : Cost Estimates

System Resource Reports

Brandon Perez (Systems Engineer)

Mass Report

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

mass-report-2

Figure 5: Mass Report

Power Report

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

power-report-5

Figure 6 : Power Report

Fall 2016 BiPed : The Preliminary Design Documentation

By:    Gifty Sackey (Project Manager)

          Brandon Perez(Mission, Systems and Test)

          Ryan Daly(Electronics and Control)

          Ijya Karki(Manufacturing)

Mission Objective and Mission Profile

– Gifty Sackey (Project Manager)

The Robot Company has assigned our engineering team to design the 6th generation of the Biped robot, however, this model will utilize a non-servo based walking motion. The Biped should be able to statically walk with a final goal of being able to demonstrate dynamic walking. The Biped should be able to walk on various surfaces and walk on terrains that have an inclination of a maximum 6.5 degrees. In addition to that, the Biped need to walk around while avoiding obstacles with the help of ultrasonic sensors. The design change was initiated due to the fact that prior Biped models had gears wear out before its mission objectives were completed. In the initial stage of the product, the customer would like this Biped to be able to run on DC motors and be able to turn both left and right on. At the end of the build, the Biped will be asked to participate in a game where it needs to be to be able to outrun velociraptors and climb over different inclinations.

Table of Contents

Suggestions for future Biped teams:

  • Get approval for all purchases – Due to time constraints, our team was in a rush to get parts in to begin implementation.  We focused our attention on completing our mission objective without considering our customers’ expectations.  It is important to complete the objective as well as pleasing the customer.
  • Replace servos with better quality – We had servo issues throughout the semester. We always had a spare servo in hand due to the unpredictability of servo failure.
  • Make RoFi lighter – The servos would spasm causing RoFi to fall.
  • Lower the center of mass – Due to RoFi being so top heavy, it was difficult implementing walking on an inclined surface.
  • Implement the ultrasonic sensor, accelerometer/gyroscope and cordless walking – Due to customer request, we focused a lot of our attention getting RoFi to walk the figure 8 obstacle course and neglected other features.
  • Get RoFi asap – We had to do a lot of documentation throughout the semester, we did not get to work on RoFi until about one month into the semester.
  • Project Manager – As Project Manager I had a lot of paperwork in the beginning of the semester. Work slowed down in the third month, so I dedicated a lot of my time getting RoFi to walk and assisted the engineers where I could.
  • Be cautious of free 3D printing – Verify that the quality of the 3D printing material is to your liking.
  • Understanding the customer – Realize that the customer has multiple projects and classes and will claim things were said or were not said that you may need to address.  Communicate and verify all concerns with the customer, student teacher and president.
  • Update Mission Objective – Our mission objective said that the incline was 8 and 6 degrees; we measured the incline and it varied from 14 to 7 degrees.  The room was also a burden to work in because the room was popular for labs and lectures.

https://www.arxterra.com/spring-2016-rofi-project-summary/#Program_Objectives_Mission_Profile

Comments – Gifty Sackey (Project Manager)

I find this section of the blog post to have been extremely helpful.  The above section which was provided by last semester’s project manager identified areas to focus on when building future BiPed because they might have overlooked it when they were building their own robots. This section is to help us learn from last semester’s mistakes and have a little bit of an easier time when building future Biped robots.

Review of Literature

Analysis of Past Level 1 Requirements

Requirement Evaluation Rubric

  1. Is the requirement, Quantitative, Verifiable, and Realizable?
  2. Is the requirement located at the correct level (1 –Program/Project)
  3. Is the requirement response to a higher level requirement or customer’s objective (Requirement Flow Down)? Is the linkage clearly defined?
  4. Does requirement provide link to source material?
  5. Does requirement move the design process forward?
  6. Are equations used to calculate a requirement provided and are answers correct?
  7. The requirements that are missing are the hardest to discover and will be factored into your evaluation.
  8. Is language in form of a requirement?
  9. Avoid multiple requirements within a paragraph (i.e breakup statements that contain multiple requirements)
Requirements from Spring 2016 Wednesday Requirement Evaluation Rubric Number
1 2 3 4 5 6 7 8 9
Modifications to RoFi shall not exceed $320 Y N N N N N Y Y Y
RoFi shall acknowledge and avoid objects within 3 feet Y Y Y N Y Y N Y Y
RoFi shall traverse carpet, linoleum tile, and metal surfaces N Y Y N Y Y Y Y Y
RoFi’s runtime shall be greater than 15 minutes Y Y Y N Y Y Y Y Y
RoFi shall cross over a threshold, at approximately a 45° angle and a height of 2 cm Y Y Y N Y Y Y Y Y
RoFi shall ascend an incline that is initially an 8° slope which then decreases to a 6° slope Y Y Y N Y Y Y Y Y
RoFi shall complete the figure 8 obstacle course through the Arxterra Application during finals week (Monday, May 9 – Saturday, May 14, 2016) Y Y Y N Y Y Y Y Y
Vision shall be provided through the on board phone N Y Y N Y N N Y Y

Section 3: Requirements 

-Gifty Sackey (Project Manager)

Spring 2016 New Requirements: Level 1

  1. The Biped will be finished by the 9th of December, 2016 as designed in the CSULB calendar to correspond with the duration of the EE 400D class.

http://web.csulb.edu/~hill/ee400d/F’16%20Syllabus.pdf

  1. Shall use one 3Dot board embedded system.

http://web.csulb.edu/~hill/ee400d/F’16%20Project%20Objectives%20and%20Mission%20Profile.pdf

  1. Shall use one custom SMD I2C shield.

http://web.csulb.edu/~hill/ee400d/F’16%20Project%20Objectives%20and%20Mission%20Profile.pdf

  1. The BiPed shall participate in an end of semester (December 9th, 2016) game where the BiPed’s goal is to outrun Velociraptor out of the arena with Goliath serving as its “eyes.”

 http://web.csulb.edu/~hill/ee400d/F’16%20Project%20Objectives%20and%20Mission%20Profile.pdf

  1.  The BiPed shall use two DC motors to control walking movement of two legs. The choice of the DC motor will be compatible with the 3DOT board.   
  1. The BiPed shall walk statically and should demonstrate dynamic walking over flat, inclined, and declined surfaces for the entire duration of the game without falling over.
  1.  Control of the walking robots will use the Arxterra Android or iPhone application operating in RC mode

http://web.csulb.edu/~hill/ee400d/F’16%20Project%20Objectives%20and%20Mission%20Profile.pdf

  1.  The BiPed should be able to turn left and right at a maximum of 90 degrees at a time. 
  1. The BiPed should be able to maneuver around the arena and should avoid collisions with surrounding objects.

System/Subsystem (Level 2)

– Brandon Perez (Missions, Systems and Test)

  1. Should use four ultrasonic sensors to support the BiPed in preventing numerous collisions into surrounding objects. Refer to requirement 9, level 1.

Quantitative: four ultrasonic sensors.

Verifiable: Through the use of ultrasonic sensors, the BiPed should be able to detect nearby obstacles such as walls, and react accordingly so as to not run into these objects.

Realizable: The BiPed should have one sensor on the four “faces” of the robot: one on front, one on back, one on each side. The BiPed should be able to be aware of its environment in all four directions.

2. BiPed will have a Bluetooth v 4 .0 BLE Transceiver integrated circuit that will be able to communicate with the class website of Arxterra. Refer to requirement 7, level 1.

Quantitative: The BiPed should use one Bluetooth v 4.0 BLE Transceiver.

Verifiable: The BiPed will be controllable through the use of the Arxterra Android or iPhone application.

Realizable: The 3Dot Board will utilize the a Bluetooth v 4 .0 BLE Transceiver to communicate with the Arxterra application to be remote controlled.

3. The 3Dot board shall be powered by a single CR123A 3.7V 650mA rechargeable Li-ion battery. A 9V battery will be used to amplify the 3Dot board’s signals. Refer to requirement 2 and 4, level 1.

Quantitative: The 3Dot Board will use a single CR123A 3.7V 650mA battery and one 9V battery will be used as an external power source.

Verifiable: Through the use of the CR123A battery to power of the 3Dot Board the 3Dot Board’s 5V turbo boost and dual DC motor driver should power the 1.5V-9V DC Motors. The 9V battery will be used to amplify the 3Dot Board’s 3.7V signals to drive the 4.8V servo motors.

4. The Biped will use 2 DC motor to control its main walking motion. Refer to requirement 5, level 1.

Quantitative: The BiPed will use two DC motors for walking.

Verifiable: The Biped should be able to walk with the use of two DC motors.

Realizable: A DC motor will be placed in each leg to drive the walking motion

5. The Biped should use one wheel attached to one motor on each foot to execute the left and right turns. Refer to requirement 8, level 1.

Quantitative: The Biped should use one wheel attached to one motor on each foot (two wheels in total total).

Verifiable: The Biped’s wheels will be tested to ensure that it successfully turns left and right.

Realizable: A wheel on the side of the foot running clockwise or counterclockwise will help drag the feet and therefore position the Biped into the desired angle it wants to face when performing a turn.  

6. The I2C shield will utilize 4-pin connectors as well as a four pin cable assembly to connect the four ultrasonic sensors via the I2C interface. Refer to requirement 3, level 1.

Quantitative: 4-pin connectors, four pin cable, four ultrasonic sensors

Verifiable:  An ultrasonic sensor would be tested to ensure proper communication with the I2C interface

Realizable: The 4 ultrasonic sensors in each face of the BiPed (90 degrees apart) will help ensure the BiPed or the user has awareness of its surroundings.

7. Biped should use a gyroscope as a sensor to determine its position with respect to the ground and shift center of mass in front of it or behind it when walking on inclined or declined surfaces respectively. The MPU-6050 (Gyroscope + accelerometer) should be used since it was implemented by previous BiPed projects and test software is readily available.  Refer to requirement 6, level 1.

Quantitative: Rotating gears at the hips will be 180 degrees out of phase

Verifiable:  The BiPed should have the center of mass shifted from one  foot to the other foot as a result of the hip placement of each leg being out of phase by 180 degrees  during the gear rotation at the hips.

Realizable: Shifting the weight over one foot to the other will help ensure our BiPed is stable and balanced at all times during the complete walking cycle on both flat, inclined, and declined surfaces.

Section 3: Design Innovation

– Gifty Sackey (Project Manager)

The brainstorming and brain writing exercise mainly focused on answering three main problems we needed to consider when implementing and building the Biped. Among the problems we had to consider, was for the Biped to be able to maintain balance, while walking on bumpy terrain and inclined planes; the biped should be able to turn left and right and lastly the biped must be able to outrun its opponents. In completing our brainstorming requirements, we used the attributes listing, dunker diagram models and lateral thinking methods.

System/Subsystem (Level 2)

  1. Should use four ultrasonic sensors to support the Biped in preventing numerous collisions into surrounding objects. Refer to requirement 9, level 1.

Quantitative: four ultrasonic sensors.

Verifiable: Through the use of ultrasonic sensors, the Biped should be able to detect nearby obstacles such as walls, and react accordingly so as to not run into these objects.

Realizable: The Biped should have one sensor on the four “faces” of the robot: one on front, one on back, one on each side. The Biped should be able to be aware of its environment in all four directions.

2. BiPed will have a Bluetooth v 4 .0 BLE Transceiver integrated circuit that will be able to communicate with the class website of Arxterra. Refer to requirement 7, level 1.

Quantitative: The Biped should use one Bluetooth v 4.0 BLE Transceiver.

Verifiable: The Biped will be controllable through the use of the Arxterra Android or iPhone application.

Realizable: The 3Dot Board will utilize the a Bluetooth v 4 .0 BLE Transceiver to communicate with the Arxterra application to be remote controlled.

3. The 3Dot board shall be powered by a single CR123A 3.7V 650mA rechargeable Li-ion battery. A 9V battery will be used to amplify the 3Dot board’s signals. Refer to requirement 2 and 4, level 1.

Quantitative: The 3Dot Board will use a single CR123A 3.7V 650mA battery and one 9V battery will be used as an external power source.

Verifiable: Through the use of the CR123A battery to power of the 3Dot Board the 3Dot Board’s 5V turbo boost and dual DC motor driver should power the 1.5V-9V DC Motors. The 9V battery will be used to amplify the 3Dot Board’s 3.7V signals to drive the 4.8V servo motors.

4. The Biped will use 2 DC motor to control its main walking motion. Refer to requirement 5, level 1.

Quantitative: The Biped will use two DC motors for walking.

Verifiable: The Biped should be able to walk with the use of two DC motors.

Realizable: A DC motor will be placed in each leg to drive the walking motion

5. The Biped should use one wheel attached to one motor on each foot to execute the left and right turns. Refers to requirement 8, level 1.

Quantitative: The Biped should use one wheel attached to one motor on each foot (two wheels in total total).

Verifiable: The Biped’s wheels will be tested to ensure that it successfully turns left and right.

Realizable: A wheel on the side of the foot running clockwise or counterclockwise will help drag the feet and therefore position the Biped into the desired angle it wants to face when performing a turn.  

6. The I2C shield will utilize 4-pin connectors as well as a four pin cable assembly to connect the four ultrasonic sensors via the I2C interface. Refer to requirement 3, level 1.

Quantitative: 4-pin connectors, four pin cable, four ultrasonic sensors

Verifiable:  An ultrasonic sensor would be tested to ensure proper communication with the I2C interface

Realizable: The 4 ultrasonic sensors in each face of the BiPed (90 degrees apart) will help ensure the BiPed or the user has awareness of its surroundings.

7. Biped should use a gyroscope as a sensor to determine its position with respect to the ground and shift center of mass in front of it or behind it when walking on inclined or declined surfaces respectively. The MPU-6050 (Gyroscope + accelerometer) should be used since it was implemented by previous BiPed projects and test software is readily available.  Refer to requirement 6, level 1.

Quantitative: Rotating gears at the hips will be 180 degrees out of phase

Verifiable:  The Biped should have the center of mass shifted from one  foot to the other foot as a result of the hip placement of each leg being out of phase by 180 degrees  during the gear rotation at the hips.

Realizable: Shifting the weight over one foot to the other will help ensure our BiPed is stable and balanced at all times during the complete walking cycle on both flat, inclined, and declined surfaces.

Section 3: Design Innovation

The brainstorming and brain writing exercise mainly focused on answering three main problems we needed to consider when implementing and building the Biped. Among the problems we had to consider, was for the Biped to be able to maintain balance, while walking on bumpy terrain and inclined planes; the biped should be able to turn left and right and lastly the biped must be able to outrun its opponents. In completing our brainstorming requirements, we used the attributes listing, dunker diagram models and lateral thinking methods.

Section 4: Systems/Subsystem Design  

  1. Product Breakdown Structure Refer to : http://web.csulb.edu/~hill/ee400d/Lectures/Week%2004%20Modeling/e_Product%20Breakdown%20Structure.pdf

Section 5: Electronic System Design

Brandon Perez (Mission, Systems and Test)

  1. System Block Diagram

system-block-diagram3

  • Fritzing diagrams

frizzing-diagramfriz

Section 6: Mechanical Design

3D mechanical rendering of the system with subassemblies clearly identified (exploded view of the system)

  1. Descriptions of the subsystems, their interfaces and requirements

Section 7: Design and Unique Task Descriptions

Subsystem Descriptions (Ryan Daly – Electronics Engineer)

  1. Electronic components will be sourced from distributors in the U.S. with quantity already in stock to receive components promptly to begin construction as soon as possible.
  2. Wireless control of the Biped will be done using the Arxterra app and a Bluetooth module connected to our 3Dot Board. This includes walking, stopping, and turning the Biped in RC mode.
  3. The Bluetooth module will be chosen to have a supply voltage of 3.3V per the 3Dot Board’s voltage capacity.
  4. The ultrasonic sensors will be chosen to be compatible with the 3Dot Board’s I2C interface and power capabilities.
  5. A gyroscope sensor will be chosen to be compatible with the 3Dot Board’s I2C interface and power capabilities.
  6. The DC motors will be chosen to be compatible with the 3Dot Board’s power capabilities.
  7. The servo motors will be chosen to be compatible with the 3Dot Board’s power capabilities.
  8. Power supplies will be chosen so that the robot can operate for at least 30 minutes.
  9. Power supplies will be designed to supply the correct voltage to each component.

http://web.csulb.edu/~hill/ee400d/F’16%20Project%20Objectives%20and%20Mission%20Profile.pdf

Subsystem Tasks

  1. Bluetooth Module

Subsystem Description

Wireless control of the Biped will be done using the Arxterra app and a Bluetooth module connected to our 3Dot Board. This includes walking, stopping, and turning the Biped in RC mode.

Subsystem Task

Find a Bluetooth module that is compatible with the 3Dot Board that will allow for communication between it and the Arxterra app.

Design Process

The 3Dot Board supports the use of a Bluetooth Module to communicate wirelessly with the Arxterra App. The ATmega 32U4, which is what controls the 3Dot board, has two pins for controlling a Bluetooth module: RXD (Digital Pin 2) and TXD (Digital Pin 3). Therefore, we are looking for a Bluetooth module with 4-pins (RS232 interface): Vcc, Gnd, RXD, and TXD. Vcc is something to keep in mind since our 3Dot Board only outputs 3.3V. Therefore, our Bluetooth module must either be compatible with 3.3V or we must create another power supply circuit and tap that voltage to power the module.

Previous semester’s Goliath, who also used the 3Dot board for their design, used the HC-06 Bluetooth Module. Pathfinder used this module also. This device is an acceptable choice for this project. This module only requires 3.3V-6V for operation, so it would work great with the 3Dot’s on board power supply. It also supports the 4-pin serial interface we are looking for. Furthermore, this module is cost effective at ~$8.99 and provides coverage for up to 30ft.

Testing

A test should first be conducted using an Arduino and our preferred Bluetooth module while we wait for or 3Dot board’s production to familiarize ourselves with the method of Bluetooth communication. The test should include functionality at 3.3V since that is what our 3Dot board will supply, as well as effective communications at distances up to 30ft.

  1.    Ultrasonic Sensors

Subsystem Description

Ultrasonic sensors will be used to detect the Biped’s surrounding environment.

Subsystem Task

The ultrasonic sensors will be chosen to be compatible with the 3Dot Board’s I2C interface and power capabilities.

Design Process

Four ultrasonic sensors will be placed on each “face” of the biped: one on the front, one on the back, and one on each side. These ultrasonic sensors should utilize the I2C interface.

Devantech SRF02 Low Cost Ultrasonic Range Finder is a good option. The cost is relatively low ($13) compared to other similar I2C ultrasonic sensors starting in the $20s. This sensor can detect ranges from 15cm to 6m which is comparably better than the cheaper HC-SR04 which can only detect up to 500 cm. One thing to keep in mind is that the SRF02 requires a supply voltage of 5V and should not exceed 5.5V, so we should route the 5V power supply on our shield to power this sensor.

Testing

The ultrasonic sensor will be tested to be sure that the servos respond quick enough that our robot will come to a complete stop or avoid obstacles, without falling over, when detected.

  1.     Gyroscope Sensor

Subsystem Description

A Gyroscope Sensor will be used to detect tilting of the Biped so that it can balance itself on inclined planes.

Subsystem Task

A gyroscope sensor will be chosen to be compatible with the 3Dot Board’s I2C interface and power capabilities.

Design Process

A gyroscope sensor will be located at the torso of the Biped and should have an I2C interface to connect with the 3Dot Board’s pcb shield. The gyroscope will work to detect tilts that the Biped will encounter, which could either be from being pushed by an external force or by walking up inclined planes. This will provide feedback to the microcontroller to stabilize our robot.

The MPU-6050 requires 2.375V-3.46V to operate and has an I2C interface as well, which would make this sensor appropriate for use on our robot.

Testing

The gyroscope sensor should be tested such that when a forward tilt is experienced, the servo motors that will be located at the ankles of the robot will turn so that the feet will tilt forward for the Biped to balance. Furthermore, if the sensor detects a backwards tilt, the servo motors will tilt the feet backwards to balance.

  1.     DC Motors

Subsystem Description

Four DC motors will be used on the Biped: two at the hips to drive the walking motion and two at the feet to drive the turning motion.

Subsystem Task

DC motors will be chosen to be compatible with the 3Dot’s onboard dual DC motor drivers. Since the 3Dot board currently only supports 2 DC motors we must be able to generate our own circuit on our shield that can drive two more DC motors.

Design Process

Two DC Motors at the hips will spin the gears that will drive the walking motion. This method will shift the center of mass from left to right to allow for walking and eliminate the need of a servo motor at the hips to shift the hips left and right. These two DC motors will be driven by the TB6612FNG Dual DC Motor Drive located on the 3Dot Board. The DC motors will be rated to operate at 5V since the 3Dot Board supports a 5v Turbo Boost for driving DC motors.

The Biped will use two DC motors located at its feet to turn left and right. We have already used up the two DC motor drivers on the 3Dot board and we will need to use two more. To accomplish this, we can add a similar motor driver circuit that we see on the 3Dot board to our pcb shield. This would require us to tap the 5V power source on the shield to power a TB6612FNG Dual DC Motor Driver. This motor driver requires a supply voltage of 2.7-5.5V. The Motor Driver also uses six digital input pins to control the rotation of the motor. Our 3Dot board does not have any accessible DIOs so we will use TI P/N PCF8574 which is an IC chip with an I2C interface that outputs 8 DIOs. We will use these DIOs to control the TB6612FNG. This 8-Bit I/O Expander for the I2C-Bus requires 2.5-6.6V for operation so we will route the 5V power supply from our shield to power this IC chip.

Testing

The DC motors should be tested such that they provide torque even when under load, showing that they can move our robot.

  1.     Servo Motors

Subsystem Description

The Biped will use two servo motors: one at each foot to tilt its feet forwards and backwards to stabilize itself when walking up or down inclined/declined planes.

Subsystem Task

Servo Motors must be chosen to either be compatible with the 3Dot Board’s onboard 3.7V servo dual servo motor driver ports.

Design Process

The 3Dot board supports 2 servo motors, capable of operating both motors at 3.3V. The problem is that most servo motors are operational at around 4-6V. To overcome this problem, we will route the pins for the servo motors to our shield which will use a 9V battery and an LM7805 voltage regulator to power the servo. While Vcc will require 5V, a 3.3V PWM signal will be sufficient to drive the servo.

Testing

The servo motors will be testing to ensure that a Vcc of 5V and a 3.3V PWM signal will be sufficient to drive them since this is what our design calls for. Furthermore, as explained above, we will need to test these servos with other sensors to make sure that they respond to the feedback from the sensors.

  1.     Power Supply

Subsystem Task

The Biped’s power supplies must be chosen such that each component will receive the proper power for operation.

Design Process

The 3Dot Board has two battery connection points. The first battery holder supports a CR123A 3.7V 650mA rechargeable Li-ion battery. The second is an external battery connector where we will connect a second 3.7V battery which, when looking at the block diagram for the 3Dot board, shows that these batteries will be connected in parallel. Choosing a 3.7V battery as the second batter is important for a few reasons. First, when connecting batteries in parallel, they should always be the same voltage, especially if the lower voltage battery is rechargeable. The battery with a higher voltage will charge the battery with a lower voltage, and with no protection circuit for charging the battery, it could overcharge and become damaged. So then, why use another battery at all? If we use two 3.7V batteries in parallel, we can increase the available current and the milliamp-hours. Increasing the available current is useful because we are feeding this 3.7V into a 2.5W boost converter. This boost converter will draw a higher current at a lower voltage to convert this power into a higher voltage with a lower current. It does this to boost the incoming 3.7V to about 5V to power the TB6612FNG Dual DC Motor Driver.

A second power source will exist on the pcb shield that will consist of a 9V battery and an LM7805 voltage regulator to generate a 5V power supply for the components in our design that are not compatible with 3.3V and need 5V to operate.

Testing

Testing each component with the exact power that we will be supplying it with our 3Dot board will be crucial in determining the functionality of each component in our finalized system.

Manufacturing Engineer Research

 (Manufacturing Engineer -Ijya Karki)

Review of Literature

Reviewing old material provides a greater insight on why past Biped projects were successful or not successful. My focus of reviewing old material was on the different Manufacturing complications and successes to guide how our group could tackle various problems.

3D Printing

Final Project Debriefing, December 20, 2013 https://www.arxterra.com/final-project-debriefing/

3D Printing Versus Molding, April 28, 2015 https://www.arxterra.com/3-d-printing-versus-molding/

Fall 2013 documented the successful, precise 3D printed parts. They predicted a long lifespan of the printed plastic components. The main issues that were encountered occurred later in the project when additional modified designs of parts were created. They had trouble with screwing the components together and the fit of the old and new parts.

Spring 2015 documented the reasons that 3D printing was chosen. The main reasons were because 3D printing is customizable, and cheap. They specified renting a machine for 30$ (not including the cost of plastic.) The main con the team expressed about 3D printing is the limitation that the material must be plastic. The team explored the option to mold materials. Pros of molding is the strength of the molded object. Cons of molding is that it isn’t as customizable as 3D printing, and it costs a lot.

This team faced problems after 3D printing. The manufacturing engineer forgot to allow room to loop wires through the different brackets that were created.  

Materials

Material Choice, April 28, 2015 https://www.arxterra.com/material-choice/

ABS or PLA? Choosing The Right Filament http://makezine.com/2014/11/11/abs-or-pla-choosing-the-right-filament/

Spring 2015 documented the various plastics considered for 3D printing. The group chose to go with PLA plastic because it is lightweight and cheap. Some noted disadvantage of PLA was limited flexibility, and the fact that it is weaker than molded plastic. Advantages of ABS plastic is it is more flexible, and it has as higher temperature resistance than PLA. Some disadvantages of ABS is that it is harder to 3D print and more time consuming. Advantages of molded standard plastic is that it has the strongest bond compared to PLA and ABS. Disadvantage of standard plastic is price and harder to modify parts than 3D printing.

PCB Layout

PCB Design, November 18, 2014 https://www.arxterra.com/pcb-design/

Spring 2016 RoFi PCB Layout, May 1, 2016 https://www.arxterra.com/spring-2016-rofi-pcb-layout/

Fall 2014 documented the custom design of their PCB. Manufacturing completed the soldering of the board. They highlighted their PCB layout as one of the successes of the semester. It performed the as anticipated.

Spring 2016 provides a list of steps to make sure that the group’s created PCB design is compatible with the Fabrication House DRC check. The documentation also provides steps on converting file type to gerber files. This group’s project summary explains how the gerber files are given to the president who then orders the board and the components. It took a week and a half to get all the components. The Manufacturing Engineer is responsible to solder these parts together.

Ideas and Advice

Final Documentation MicroBiPed, May 16, 2015 https://www.arxterra.com/final-documentation-microbiped/

Fall 2013 suggested to increase the size of any components around the chosen motor to allow room for the motor to spin.

Fall 2014 suggested to prototype the Biped before printing the actual parts. Avoiding 3D printing for the prototype is possible, we would just have to explore our options. Prior to assembling the custom PCB design,, draw out the anticipated look of the board. They faced issues with connecting female pins to the PCB. They ended up using jumper wires to connect the ground pin.

Spring 2016 suggests to purchase parts after the approval of the customer. Confirm that the 3D material is the best type for the project before committing to the material. Document all interaction with the customer to avoid confusion in the future regarding things that were asked for. If values change make sure to update documentation or make note of the change.

Review of Old Requirements

Requirements, April 21, 2015 https://www.arxterra.com/requirements/

Examining past level 1 requirements that pertain to manufacturing

Requirement Evaluation Rubric Number
1 2 3 4 5 6 7 8 9
Design a new custom PCB (Fall 2014) Y Y Y N Y N N Y
The μBiPed must weigh no more than 1 kilogram in order to facilitate the miniaturized size of the μBiPed. Otherwise, if the μBiPed is too heavy the project may not be realizable (Spring 2015) Y N Y N Y N N Y
The μBiPed must be miniaturized as is dictated by its own name, size 7 inches (Spring 2015) Y Y Y N Y N N Y

Examining past level 2 requirements that pertain to Manufacturing

Requirement Evaluation Rubric Number
1 2 3 4 5 6 7 8 9
Manufacture Professional custom PCB to help alleviate any loose wires hanging on the robot and reduce weight distribution (Fall 2014) N Y Y N Y N N Y
In order to successfully miniaturize the μBiPed, micro-servos will be used. Type of micro-servos are MG92b after testing. The project must test the micro servos using SolidWorks or through math analysis in order to determine if micro servos provide enough torque to complete the project (Spring 2015) N Y Y N Y N N Y
Due to the miniaturization of the μBiPed, a PCB board will be fabricated that includes the wiring for the gyro, the Bluetooth IC, and the servo pins that will allow for the microcontroller to interface with the assembly (Spring 2015) N Y Y N Y N N Y
In order to traverse multiple surfaces the μBiPed’s legs must have some type of thread or rubber sole added to it (Spring 2015) N Y Y N Y N N Y
A lightweight material must be used for the frame in order to keep within the specific mass restrictions of the μBiPed; the type of material is PLA. Testing must be done as to whether or not the μBiPed can be made of plastic, or if a lighter material must be used (Spring 2015) N Y Y N Y N N Y

Most of the listed requirements do not meet 1 of the rubric because they miss the quantitative requirement. Requirements that didn’t miss 2 of the rubric were placed in the wrong level of requirements. No requirements evaluated provide a link to source material, therefore they do not meet 4 of the rubric. No requirement needed equations which is 7 on the rubric. No requirement meet is formatted in the right language, thus it does not meet 8 on the rubric. Requirements that did not meet 9 had a requirement that could have been split up into two sections.

Fall 2016

Going through the old Biped blog posts, I got a clearer view about the complications past groups ran into. I was also able to determine what manufacturing strategies were most beneficial. By evaluating older requirements, I have a better understanding about how to continue with my subsystem requirements. First I will discuss the suggestions I have for the upcoming semester.

3D Printing

3D printing has been successful for the past semesters. I would suggest continuing forward with this method to produce parts of our robot. Cautionary facts to consider will be the time it takes to print, the spacing of material (or wires), and picking the right dimension of screws.

Materials

Due to the fact that we will be 3D printing our parts, we will have to use plastic. To keep the cost of our robot low, we could go with PLA.

PCB Layout

The main concern with the PCB layout is the ordering/arrival time of the product. I suggest to factor this time into the schedule.

Ideas and Advice

I would like to utilize the advice provided by past semesters as much as possible so that we can avoid as much problems as possible. I suggest creating 3D models of components while keeping in mind that we may need room to move or add wires. I suggest that we make as many sketches as possible to visualize our product before finalizing ideas. I also suggest checking up with the customer weekly to make sure that we are producing the product that the customer had in mind.

3d-image-of-biped

3D modeling

Wheels

Wheels added to the Biped will help the robot turn right and left. One foot will remain stationary on the the ground while the second foot will slightly be elevated in the air. The wheel attached to the foot that is still on the ground will rotate backwards and turn the biped in the direction of whichever foot is on the ground. For example, when the biped is on the left foot it will turn left and when the biped is on the right foot it will turn right.

Body

The final body design dimension is yet to be finalized. However the body width will be larger than the body height. This goal is to keep the body close to the ground as possible.

Legs / Feet

The feet will be connected to the body through the leg parts. Although the final design dimensions have not been chosen, the feet itself will be larger than the width of the body to prevent it from loosing stability.

Spring 2016 3DoT Goliath Final Project Document

 

By: Ayman Aljohani ( Project Manager)

Team members:

Ayman Aljohani (Project Manager)

Tae Lee ( Mission and Systems Engineer)

Kevin Moran (Electronics and control Engineer)

Jerry Lui (Manufacturing Engineer)

Table of Contents

Executive Summary

Objective

The objective of the 3DOT Goliath is to design a small-scaled version of the Goliath Tank, as a toy, that meets the following

requirements: Safe: uses IR transmitter and receiver. Less than 6 hours printing time. Piloted via live cam on an Android phone. Low cost: should not exceed $80 total. Controlled by 3DOT board. Looks cool and inspired by the Goliath Tank. Periscope must be attached to an Android phone laying horizontally zero degree with the x-axis.

 

Mission Profile

The mission profile of this project is to play a “laser-tag” battle with the 3DOT Spider. Every hit will require a 5 second delay in between to avoid multiple tags.  With each hit the buzzer will make a sound to indicate that it got hit.  After receiving the third hit the robot will be disabled and play a short song afterwards.  The game will take place in a 6 ft. x 6ft area on the linoleum floor. The maximum distance for detection from the detector will be 5 ft.

 

Mission Objective Update

1

Level 1 Requirements

  • Laser tag game must be safe for children
    • Uses IR transmitter and  receiver to stimulate a game of tag
  • Less than  6 hours printing time
  • Piloted via live cam on an Android phone
  • Low cost: should not exceed  $80  total
  • Controlled by 3DOT board
  • Looks cool and inspired by the Goliath Tank
  • Periscope on an Android      phone degree with the x-axis

 

Level 2 Requirements

 

  • The rover will be controlled by two individual DC motors (3-5V)
  • Battery duration should last to the whole period of the battle 15 min
  • Controlled via Bluetooth using an Android Device
  • Print parts of rover individually
  • LED will be used for a game of laser tag
  • Laser sensors (on PCB) must be 3 inches

 

Preliminary Project Design Documentation found here

 

System Design

System Block Diagram

1

 

 

The figure below will show how each components on the Goliath will be connected and how they will interact with each other.  

 

Experimental Results

Uploading the Firmware onto the 3Dot Board

 

After assembling the 3Dot Board we need to program the ATMEL 32U4 chip by uploading a firmware.  Without the firmware we will not be able to upload any programs onto the ATMEL 32U4.  A detailed explanation will be provided by the following link:  Upload Firmware

 

Troubleshooting the 3DoT  Board

 

After assembling the 3Dot board I had to make sure that each component was soldered correctly.  In addition, testing the motor driver by uploading a program using the Arduino IDE onto the 3Dot Board.  To know more about the test procedure, check out the following link:  3Dot Board Troubleshooting

 

Arxterra Control Panel Test

 

To be able to use the Arxterra Control Panel from the website we had to perform a couple of tests.  The test is to make sure that the communication between the android Arxterra application communicates with the Arxterra control panel (1) on the computer.  To know how the test was implemented check the link:  Arxterra Control Panel Test  

 

Bluetooth Module Test

 

Before we implement the Bluetooth module onto the Arxterra Firmware we had to perform a simple test to see how the Bluetooth module functions.  The test will allow us to see the information we send from the android device using the BlueStick Control, which will than be displayed on the Arduino serial port.  The link will provide a detailed explanation of the test performed:  Bluetooth Module Test

 

 

3DoT Goliath DC motor trade-off study

In this post, it was my job to narrow down from a few DC motors to just two and do a trade-off study in order to figure out which one would work best. The motors were compared in regards to customer requirements. The motor chosen had to fit all customer requirements, including some requirements needed in order to make the project successful.

Motor trade-off study

Laser vs IR LED trade-off study

In the beginning of the semester, we began comparing two different method for meeting the project requirement of having a laser tag game. We tested both a laser and IR led with their respective receivers.  The benefits of the laser were the range and low power consumption; the problem was the safety with using lasers. The IR LED was very safety to use, unfortunately the range was very low, as the light diffused. At this point we believed the laser would make the perfect candidate for the game.

Laser vs IR trade-off study

Progression of laser tag components

In this post I explain my reasoning in the progression of the different technologies we wanted to use to make the laser tag possible. The laser and IR emitter were giving me trouble in order to design the game. Another idea was to use a visible LED and turn that into brighter light using the same idea of a flashlight. Testing proved successful as I was able to increase the range, and maintain the safety. As it would turn out, the LED light would not a viable option either, yes be ready to have your ideas rejected often, that is life.

 

Progression of Laser tag components

Making laser tag possible: The Schmitt trigger

In this post I discuss why a Schmitt trigger is needed in order to make the laser tag game successful. Since I will be using an IR emitter/receiver, the signal output is analog which is very hard to control. By using the Schmitt trigger I am able to invert this signal and convert it to a single bit digital signal output, which we are able to monitor better.

Making Laser tag possible

Making laser tag possible: The receiver

By recommendation of my division manager, for the receiver we used an infrared transistor SPH 310 (Opto-semiconductor).  In the post I include the analog voltages outputs using both Arduino plotter and monitor. You will find basic code to test the analog voltages as well as my EAGLE CAD drawing.

The Receiver

Making laser tag possible: The emitter

In this post I discuss the IR emitter, which is built by using a few resistors, an IR LED, and a 2n2222 NPN transistor. The calculation for the resistor that I have selected are provided. This emitter will be able to be controlled on/off by controlling the voltage that is sent to the base of the transistor. The EAGLE CAD schematic is also included.

The Emitter

Subsystem Design

Interface Definitions

2

3

3

 

 

 

The following table will provide the pins for the Atmega32u4 Microcontroller 3Dot Board:

Now we will narrow down the number of pins we will be using on the Atmega32u4 Microcontroller:

1

 

CUSTOM PCB DESIGN

3DoT Goliath PCB Testing

Once the PCB was assembled by manufacturing engineer, it was my job to ensure it would work. With the help of the division manager, and systems engineer we were able to determine the problem. The blog post goes through our mistake and how we solved the problem, as well as a recommendation for when you have to design your PCB.

Custom PCB Design Testing

Making Laser Tag Possible: Extending the IR Range

With the PCB working correctly, I realized that the range was around 6-8 inches. That range needed to increase in order to make a more entertaining laser tag game. With the help of a lens and an online formula I tried to concentrate the IR LED in order to increase the range. Here you will find a very helpful formula that will help you with this problem.

Extending the IR range

The PCB Layout

In this blog post you will find the process I had to go through in order to finalize the final PCB layout. From the design on Fritzing, to testing the circuit, and finally designing it on Eagle CAD. All files have been provided by Eagle CAD. Pay attention to the Phoenix 254 connectors, as well as grounding everything to ensure your circuit works.

PCB Layout

 

PCB  physical layout

For the PCB layout blog post I go detail on the methods and a few tips and tricks regarding the layout of the board and the usage of EagleCAD. The main thing to remember is the trace width guide. For boards that aren’t powering much (simple light show, 1 or 2 small motors) the trace width can be fairly thing but for anything that requires more power (over 500mA) one should consult the guide to properly determine the width otherwise it won’t be able to supply enough power.

Remember to manually layout your traces! The auto route is terrible.

PCB Physical layout

SMD Soldering

The SMD soldering blog is just quick tutorial on how to solder small IC’s and surface mount components. I’ve included a very good video on how to SMD solder using a hot air gun and soldering iron for the larger SMD components (0805 resistors, etc.)

Note: Due to an issue with embedding the video won’t play properly. Open it in another tab and you’ll be able to view it.

SMD Soldering

 

3DoT Board Fabrication:

The 3DoT Board was soldered by project manager and tested by System Engineer.

3DoT Board Fabrication

 

Hardware Design

 

Goliath Body dimensions

           

This blog was created to give a quick overview of our preliminary design and various features within Solidworks (filter types). Although this design was created before one of our manufacturing engineers had to drop the general dimensions remained the same. The body is still designed to house all of the components (3dot board or Arduino nano, battery box, motor cage, phone, etc.).

The filet options are mainly for aesthetic purposes. Instead of rounding off the corners of cutouts a conic rho profile can be used which generates a pointed, yet rounded, corner.

Preliminary Body Dimensions

 

Final body redesign

Since the manufacturing engineer that was originally tasked to create the body had to drop the course, I had to redesign the body to meet the requirements set out from the beginning of the course.

This blog just briefly goes over what to be done and what compromises were made to meet the majority of the requirements (only one requirement was not fully met at 50% -> exact replica of Goliath tank).

Final Body Design

 

SOFTWARE DESIGN

Updated Laser Tag Communication System

The new modified flow chart (shown below) will incorporate the new laser communication system.  New features  will include an automatic turn after receiving a single hit to avoid multiple hits in less than a second.  In addition, to disabling the Goliath and playing a short song after the third hit.  

The finalized flowchart  for the laser communication system for the Goliath is shown below:

 

1

 

 

 

The arduino C++ code that will be implemented in reference to the flowchart on the Goliath will be available by following the link:  Goliath-Arxterra Firmware

 

Making laser tag possible: Putting it all together

The final blog post in the sequence of making laser tag possible. Here you will find the final product of the emitter/ receiver combo. I have also included a flowchart showing exactly how our circuit will work. The circuit is to detect three different hits by an IR LED. After each hit a piezo buzzer will make a tone sound, after the third hit we play a melody and the rover is deactivated. The final code and output results are included.

Putting it all together

Arxterra Firmware Motor Control Modification Test

The 3Dot Board was not given at the time, so we had to use the Arduino Uno and the Arduino Motor Shield.  The Arxterra Firmware that was given to use had the motor controls for the Sparkfun Pro Micro with the Dual Motor Driver.  Hence, we had to make modifications to the firmware to work with the Arduino Uno and the Arduino Motor Shield.  

 

3DoT Goliath IR Emitter/Receiver Code Test

The early stages of development of the laser tag system required research and testing.  To see how IR worked we performed a basic test using IR Mid-Range Proximity Sensor (TSSP4P38) and a remote control (IR Emitter).  Follow the link to see a detailed explanation of the testing procedure for the circuit setup and the code used to test the sensor.

 

Verification and Validation Test Plans

We will perform a verification on the requirements that was discussed by the customer.  Each subsystem engineer will perform a verification test to verify that it meets level 1 and level 2 requirements.  A verification document/verification matrix are given in order to verify each requirements.  

 

In addition, a validation will be required to test the mission profile (rules of the game) by following a similar test plans as the verification.  For validation we will validate the test plans using a validation document on how to perform the test and validation matrix to check off the validated requirement.

 

Project Overview

 

WBS:

The WBS has been updated after resources allocations, one of the manufacturing engineer was assigned to work on PCB layout, and the other one was responsible for chassis design. A link to the WBS is here

 

1

 

 

 

 

Burndown Chart:

This is our final Burndown chart

Here is a link to the Burndown chart

1

 

 

Project Schedule:

The project schedule is divided into two levels, high level requirement under “planning phase”, and level 2 requirements which is broken down to tasks. Project Schedule

Here is a screenshot of the updated project schedule. The project  percent completion is 100% .

The project schedule was created on a very useful tool, Smartsheet. Here is a link to full details blog post. Smartsheet .  

 

1

Capture

 

 

 

 

Project Budgets:

One of level 1 requirements is budget. It is the project manager’s responsibility to keep track of budget, one way to do that is to have a parts request form. Any team member should fill out the request, print it out,  sign it , and get the PM approval before proceeding with any purchase. Our actual project budget is $85

Here is a link to Parts Request Form.

Here is a link to Project Budget.

Mass Budget

Power Budget

 

Concluding Thoughts:

Suggested Practice: 

As a project manager, I had to work closely with each division engineer, especially Systems Engineer. I learned a lot through this experience. In the beginning of the semester, we had to sit with customer, president, and student assistant to define level 1 requirement of the project. That  process, iteration, is a continuous process in which a project manager verifies the customer’s requirements and provides options. The Goliath mission was to battle 3DoT Spider, thus it is important that both team work closely to define game rules and communications means between two robots. Also, another important thing is beam-width of IR, in our project we used IR, should be the same for a laser-tag game to be fun. The customer requirements will be very simple in terms of wording, but project manager and team should critically think of being creative thinking out of the box.

For a project to be completed in a timely manner, the team has to meet at least twice a week, one during regular class time, and another during the week. We had to meet three times a week to complete our project, twice on campus and once online. Communication between team member is highly important, so from the first meeting we decided to use Google Hangout app to communicate with each other.

Lesson Learned: 

Preliminary Design Review, and Critical Design Review should have  detailed information about the project. Project Manager should start preparing for CDR and PDR two weeks before the deadline.

Project video is a useful tool to promote the project, thus it is advised that Project Manager plan the video from the beginning of the semester by recording clips of the engineering method followed toward the final product.  

Smartsheet was a powerful project management tool that helped me easily managed my team. At the same time, it is good platform for communication between team members to have discussions about certain task assignment or requirement clarification. I strongly encourage project managers to use it, here is some information about it.   

Blog post is a good way to pass the knowledge to successors, therefore I encourage all team members to post on Arxterra regularly.  

After all, this was a challenging experience that expanded my understanding of real world engineering problems.

 

Resources

  1. Project Video
  2. CDR Presentation for Goliath  (Prezi)
  3. PDR Presentation for Goliath
  4. Project Schedule on Smartsheet 
    1. Project Burndown
    2. Project Schedule on Google Spreadsheet
  5. Verification and Validation documents
  6. Solidworks Chassis File for Goliath
  7. Fritzing Files for Goliath
  8. EagleCAD Custom PCB Files for Goliath
  9. Burndown Excel File
  10. Arduino and/or C++ Code
  11. BOM
  12. Other Files (Parts Purchase Request) , Team Members Evaluation Rubric 

 

Spring 2016 3DoT Goliath, Body Redesign

By: Jerry Lui (Manufacturing Engineer)

 

This blog post is to address the redesign of the body to meet the following specific requirements:

  • Print time under 6 hours
  • Scaled model of the Goliath tank
  • Phone and components must fit within the body
  • Sensors must be at a height of 3 inches

1

 

 

To meet the requirement of printing under 6 hours, a major redesign of the body had to be done.

 

To cut down on the print time, prefabricated Tamiya wheels and tracks were used.

 

https://www.pololu.com/product/106

 

Parts of the body were removed and replaced with thin trusses to help with the stability of the body.

 

The printer supplied by Professor Hill was lacking around 0.5’’ to properly print the base and top in one go so I had to split the parts within Solidworks to 2 parts.

 

The height of the sensors and emitters was set to that it was exactly at 3 inches (+/- 0.01inches due to the PLA shrinking and expanding from the print)

 

The body was printed with a 25% fill density, x1.2 wall thickness (typically x0.8 and x1.2 and always a factor of 0.4), and at a speed of 40mm/s. The print time was barely affected when changed to 0.8 so I opted to add slightly more rigidity to the body this way.

 

The body’s dimensions are essentially scaled down to the width of my Galaxy S4 phone (also held on by a ledge within the body) but it couldn’t have been an exact replica of the Goliath tank due to the print time requirement. There just wasn’t enough time to print all of the side panels and bolts while fitting the phone within the body of the rover.

 

The total print time came out to around 5hr 57minutes.

2

 

3

 

4

 

Capture

 

Conclusion

The redesign has met all but one requirement partially (scaled model). The model has the general shape of the tank but is lacking the panels and bolts.

 

Sources

 

https://www.pololu.com/product/106

 

Spring 2016 3DOT Making Laser Tag Possible: The PCB Layout.

By: Kevin Moran (Electronics and Control Engineer)

 

For Fall 2016’s 3DoT Goliath it was my job to design from scratch a printed circuit board that would allow our rover to emit and IR signal, and also process a receiving signal.  This process started as a messy image on my notebook, and was later processed into a cleaner Fritzing diagram. The diagram for the circuit changed as the weeks progressed due to help from my division manager, and my attempts at making this circuit better each time.

Capture

 

 

Testing:

Before processing to order the PCB a good amount of time went into testing the circuit below. I had to ensure that the capacitors used for removing the unwanted AC components from the power source were doing their job. I spent many hours testing various resistor sizes in order to ensure that the voltage thresholds were the correct ones with our 5V voltage supple. Once I felt sure of my decisions I moved to the next step, which was to design this circuit on Eagle CAD, in order to have the manufacturing engineer design the PCB board and order it.  By this point, I already knew my emitter/ receiver combo worked, and that using the Schmitt trigger I was able to clean this analog signal and convert it to a single bit digital signal.

 1

 

 

PCB Layout:

 

As can be seen below, all of the components are named, and have specific values. These values were obtained during the testing stage. All components of the circuit are properly grounded and given access to the power supply. The Piezo buzzer is hooked up to the 220 ohm speaker to regulate it output level. All other resistors were calculated to ensure the circuit works properly.

Note: If you are reading this, you will be provided with access to my Eagle Cad, and Fritzing diagram files, hopefully the next generation rover has an easier time.

2

 

 

Final Product: Put together by manufacturing engineer Jerry Lui

 

3

 

Sources:

Jeffrey Cool: Division Manager (Life savior)

http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/schmitt.html

http://www.eng.utah.edu/~cs5789/handouts/piezo.pdf

 

 

Spring 2016 3DOT Making Laser Tag Possible: Extending the IR emitter Range

By: Kevin Moran (Electronics and Control Engineer)

 

 

One of the things I mentioned in the previous posts, was that by using an IR emitter (LED), the range was very limited. Testing showed an average range of 3-6 inches. In order to have a reasonable range for the emitter, it was necessary to concentrate that diffused light. One idea was to use lenses to concentrate the light, the opposite idea of a flashlight which spreads out a smaller area light.

There were many lenses to choose from such as:

Convex: Helps light rays to converge into a single smaller area

Concave: Causes light rays to diverge or spread out (Opposite of what we needed).

Spherical: Which are less focused and produce a wider light beam

Compound: Which increases the focus while decreasing image distortion

The lenses that were decided to use along with Spiderbot’s E&C engineering were the convex lenses, since our emitter had a short range due to the diffusion of the light rays, it was a good idea to concentrate those rays into a small area.

Calculations:

Looking online, we came across this formula that allowed us to calculate the distance that the IR LED would have to be from the lense in order to increase the range, to a distance that would work with our requirements

Using this formula and the values provided by the image below, we were able to calculate a suitable range.

1

 

2

 

Using the diameter of the lenses I already had on me, along with the half angle provided by the datasheet of the IR LED. I came up with values to plug into this equation.

 

D = 11.3mm diameter (lens)

F = focal length

Θ = 40 (half angle intensity of the current emitter we are using)

D > 2*F*tan (Θ)

11.3mm > 2 * F * tan (40)

F < 6.73 mm

 

 

In conclusion in order to use the given lens diameter with our particular IR LED, the focal length (distance from LED to lens) has to be less than 6.73 mm. I asked the manufacturing engineer to provide with a small tube that can be used to further test these distances.  As can be appreciated by the picture below, the light intensity has increased as long as our range to about 16 inches. We will continue to test to extend this range even more.

3

 

Sources:

http://alumnus.caltech.edu/~leif/infratag/lens_choice.html

http://physics.stackexchange.com/questions/146956/howtochoserightlensforconcentratingirsignal

http://micro.magnet.fsu.edu/optics/lightandcolor/lenses.html

Kent Hayes: Ordered the lenses for both teams