Fall 2016 BiPed : The Preliminary Design Documentation

/in , /by

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.

Preliminary Design Document – Prosthetic Arm (Fall 2016)

/in /by

By:

Carolina Barrera (Mission Objective, Creativity, WBS, Budget)

Luis Martinez ( Requirements, WBS, PBS)

Fabian Suske (Electronic and Control System)

Forrest Pino (Mechanical Design)

Hector Martinez(Mechanical Design).

Table of Contents

 MISSION OBJECTIVE (by Carolina Barrera, Project Manager)

Amputees are part of the aftermath in any warfare. When soldiers return from their mission with disabilities or missing one of their extremities, it is challenging for them to adapt to a new lifestyle. Technology has advanced far enough as to offer them an opportunity to get back to some of their previously regular activities using a prosthetic limb. In our specific case we have a soldier with a missing arm, and our mission – in conjunction with the Prosthetic Hand group in the other class, is to design and engineer a device that will help him/her perform an independent task as to eat a Quarter Pounder with Cheese meal by himself/herself.

To provide a better understanding to the reader and to avoid any confusion, a couple of definitions need to be provided at the beginning of this document. Hence, The Prosthetic Arm is defined as the device going from mid-bicep and continues down the arm until the point of integration with the Prosthetic Hand. The prosthetic Hand will be addressed as the device from the point of integration with the Prosthetic Arm down the metacarpals and including the fingertips. Finally, we will refer to the Upper-limb prosthetic system to the conjunction of the two projects, The Prosthetic Arm and The Prosthetic Hand.

 CREATIVITY

All brainstorming and brainwriting ideas were done to come up with potential solutions for inconsistencies and possibly complications with the design. You can read on our approach and previous and future concerns in the following link:

https://drive.google.com/drive/u/0/folders/0B7_Bk0we7jCYS3R6SjBYOUYwVn

REQUIREMENTS:

 LEVEL 1 PROGRAM/PROJECT REQUIREMENTS (by Carolina Barrera and Luis Martinez, Project Manager and Systems Engineer)

To satisfy the expectations of our customer, a team of engineers came up with a set of requirements from our end describing components and processes that are needed in order to excel in customer satisfaction at the delivery of our finalized product:

  1. The Prosthetic Arm shall operate together with the Prosthetic Hand to complete the mission, as components of the Upper-limb Prosthetic System.
  1. The Prosthetic Arm should have a range of motion localized at the elbow of (at least) + 60 degrees and – 90 degrees in the vertical axis, allowing the user to pick up individual food components of a meal, for consumption.(http://www.webmd.com/first-aid/bones-of-the-arm) and https://www.umc.edu/uploadedFiles/UMCedu/Content/Education/Schools/Medicine/Clinical_Science/Orthopedic_Surgery__Rehabilitation/Sports_Medicine/BiomechanicsoftheElbow.pdf
  1. The Prosthetic Arm shall have the capacity to operate for 20 minutes, based on the American average time per day spent statistics for “eating and drinking”. (http://www.bls.gov/news.release/atus.t02.htm Based on medium sized burger, fries, and drink components.)
  1. The Prosthetic Arm shall be able to lift the weight of the Prosthetic Hand and the weight of each individual McDonald’s Quarter Pounder with Cheese food item, in addition to its own weight.  (http://calorielab.com/restaurants/mcdonalds/1 Estimated dividing by three meals per day, and rounding.)
  1. The Prosthetic Arm must be controlled by the soldier independently.
  1. The total cost of the Prosthetic Arm project shall be below $500.
  1. The project shall be completed by the end of Fall 2016- end of academic semester for the California State University, Long Beach.(https://web.csulb.edu/divisions/aa/calendars/documents/2016-2017AcademicCalendar.pdf)
  1. The Project shall fit in one of Professor’s Hill room cabinets, hence its maximum dimensions should be determined by the dimension of the cabinet.

LEVEL 2 SYSTEM/SUBSYSTEM REQUIREMENTS (by Luis Martinez, Systems Engineer)

L2-1 (Duration) The duration of the meal time permitted by the Prosthetic Arm shall begin upon the Prosthetic Arm first making contact with the selected food item from the McDonald’s Quarter Pounder with Cheese meal.

 

Explanation:  To allow an amputee using the Prosthetic Arm 20 minutes of time to engage in consumption of a McDonald’s Quarter Pounder with Cheese meal, there must be a quantifiable start point for taking time, which is thus defined at the moment contact through the prosthetic is made with the respective meal component of choice.

 

L2-2 (Power Capacity) The battery system for the Prosthetic Arm shall have a minimum capacity of 1500 mAh.

 

Explanation:  Based off an estimated current draw of 4.5A from the Prosthetic Hand and Prosthetic Arm power systems combined, a meal duration of 20 mins. yields a preliminary calculation for a 1500 mAh capacity requirement (http://www.powerstream.com/battery-capacity-calculations.htm)

 

L2-3 (Weight Capacity):  The Prosthetic Arm shall have the capacity to lift 5.49 lbs. ± 1.34 lbs.

 

Explanation:  The Prosthetic Arm will be responsible for lifting the weight of the Prosthetic Hand, the weight of each individual food item from the McDonald’s Quarter Pounder with Cheese meal respectively, and its own forearm weight.  Based on an average soldier’s combined forearm and hand weight of 3.8912 lbs. (men and women combined), calculated from average soldier weights and corresponding total body weight percentages for forearm and hand respectively, and the weight of the heaviest individual food item from the McDonald’s Quarter Pounder with Cheese meal (1.52917 lbs. for 21 fl oz Coca-Cola soft drink).

Drink Weight (21 fl oz):  1.5917 lbs. for Coca-Cola (1.3692 if water), derived from respective densities

Burger Weight (7 oz):  0.4375 lbs.

Fries Weight (4 oz.):  0.25 lbs.

Average Soldier Weight, Forearm + Hand (1.765 kg ± 0.61 kg):   3.8912 lbs. ± 1.34 lbs.

Weight Capacity = Heaviest Food Item (1.5917 lbs.) + Average Soldier Weight, Forearm + Hand (3.8912 lbs.) = 5.49 lbs. ± 1.34 lbs.

http://chemistry.elmhurst.edu/vchembook/121Adensitycoke.html

http://calorielab.com/restaurants/mcdonalds/1

 

L2-4 (Torque) The motor for the Prosthetic Arm shall be rated for a minimum torque output of 10.634 Nm.

 

Explanation:  Following a weight capacity requirement for 5.49 lbs. ± 1.34 lbs. (2.49 kg ± 0.6078 kg), and assuming an arm length of 14 in (35 cm), the torque requirement is estimated as follows:

figure-3-1-therefore-a-motor

L2-5 (Control) The Prosthetic Arm shall acquire input from sensors that detect bicep movement in the vertical plane.

 

Explanation:  In order to achieve the mission objective of allowing an amputee with a prosthetic arm to eat a McDonald’s Quarter Pounder with Cheese meal, the arm must have the degree of freedom in the vertical plane (assuming the Earth’s surface as a reference X-Y plane).  Following a L1 requirement for the arm to be controlled through biological signals, it is imperative that movement in the bicep be detected as this muscle allows movement in the defined vertical plane of interest.

BREAKDOWN STRUCTURE:

 WORK BREAKDOWN STRUCTURE (by Carolina Barrera and Luis Martinez, Project Manager and Systems Engineer)

By the end of the Fall semester we should have completed a functional and somewhat polished prototype of a prosthetic arm. In order to meet our goal, we need to work and accomplish simpler tasks from smaller components, so that later in the semester these small parts can be integrated into the bigger, and more complex project. In other words, we need to break down the work into manageable sections so the subsystems can be working in parallel as much as possible. Figure 1 is the Work Breakdown Structure developed by Systems Engineer, Luis Martinez and Project Manager, Carolina Barrera.

wbs_visio

Figure 2- Work Breakdown Structure Diagram

PRODUCT BREAKDOWN STRUCTURE (by Luis Martinez, Systems Engineer)

Similar to the WBS, there is the Product Breakdown Structure. The PBS breaks down the bigger components of the system into smaller pieces that can be built and tested in an initial phase of the project, and later integrated to other subsystems to come up with the overall system as a result. The Product Breakdown Structure is:

pbs_visio

Figure 3 – Product Breakdown Structure

BUDGET

The estimated budget is presented below. We have omitted Ground Shipping and taxes because we are waiting on getting our material approved so we can buy them. For now, it would be wise to round up our number and we agreed on a margin of $100 in case of an accident and also in case we have to pay for 3D printing. This is how we came up with the budget of no more than $500 for the Robotic Arm project.

 

estimated-budget_1st-iteraation

Table 1 – Estimated Budget (First Iteration)

ELECTRONICS AND CONTROL SYSTEM (by Fabian Suske, Electronics and Control Engineer )

BASIC CONCEPT

A brief brainstorming about the prosthetic arm came to the conclusion that biomedical signals (bio signals) shall be used to control the arm. The two kinds of bio signals are EMG (Electromyography) and EEG (Electroencephalogram). The following research showed that both methods would be possible to implement. There are projects available which utilize each signals. But the hassle to get good EEG signals is much bigger then to get good EMG Signals.

Another aspect that came up in the brainstorming was the high precision needed to reach the target of feeding the soldier. Since servos were restricted to use. The focus led to stepper motors. Stepper motors are due to their mechanical construction very precise.

This ideas led to the following basic concept (figure 3):

figure3

Figure 3 – Basic Concept (Electronics)

EMG Signals are acquired by the MyoWare Sensor Shield. The signals are then send to the Teensy 3.2 MCU. There the signals are processed. The Teensy drives then the designated stepper motors. The motor for the “lifting” action is located above the elbow and is directly connected to the Teensy. The second motor used for radial movement is located below the elbow and is driven by the MKR 1000 MCU. This MCU has Wifi Capability onboard. This allows the system to be remote controlled (as a plan B). The MKR 1000 is also in charge of the power distribution (not included in this graphic). The two MCUs will communicate between each other.

References:

The project requirements state that a Quarter Pounder with Cheese meal shall be consumed. Based on this information we can measure the weight that has to be lifted.

Burger: 196 g.

Soda: 1.369 lbs.

Fries: 142 g.

The heaviest item is the soda with 1.369 lbs. The Hand subsystem stated that their subsystem shall not be heavier than 3 lbs. The weight of the arm itself shall not exceed ¾ lbs. With an allocated weight of 1 lbs. to the electronics the part of the system is around 6lbs. Since estimations were made a margin of 1 lbs is added. So the total adds up to 7lbs (3,17kg).

With an estimated length of the arm of 35cm (14 in) the motor has to deliver a torque of more then 10,8815 N

figure-3-1-therefore-a-motor

Therefore a motor with at least 10,888Nm is required.

Most stepper motors (in our budget) output a torque of 1.5-3NM. So a gear must be used to achieve the needed torque.

Since stepper motors operate at 12V and the MCUs run at less than 5Vs it is not possible to operate them directly of the MCU. Hence a stepper motor driver (stepper driver) must be used.

The stepper driver should be a Surface Mounted Device (SMD, SMT (Technology)). Also the motor should be controlled used with Step and Direction. This type is easy and simple and is sufficient. Therefore the Allegro A4988 stepper driver has been chosen. This driver operates on 3-5.5V and drives motors at 12 VTo limit the thermal output the driver will be operated at under 1 A Load Current.

Therefore the Phidget PHI-3321 stepper motor has been chosen. It operates at 12V and draws a maximum current of 670 mA

figure4

Figure 4 – Stepper Motor for the Elbow

The smaller motor used to rotate the wrist or elbow must still be TBD, but should require less current than the PHI 3321 since less torque is required.

Reference:

POWERTRAIN:

Since the Upper-limb Prosthetic System should work together as a system a common powertrain will be used. Since the space in the hand is limited the powertrain will be implemented in the prosthetic arm.

Based on the given requirements the powertrain can be dimensioned. The Hand needs up to 2.5A on 12V as well as up to 1A on 5V The MCUs operate at 3.3V but can be powered with 5V.

So the prosthetic System needs two Voltage Levels to power the System.

On the 12V level 700mA (peak) each for the steppers and 2.5A (peak) for the Hand sum to a total of 3,9A. On the 5V side the Hand requires 1A and the MCUs in the Arm need an estimated current of 200mA.

To provide 5V without a second power source a 12-5V buck converter will be used. This will add around 500mA to the 12V rail. So the 12V rail must provide 4,4A (peak).

Given this specification the Microchip MIC29502 LDO Voltage regulator has been chosen. This LDO has an enable pin so the 12V can be completely shut off. This provides some interesting efficiency features.

The fact that this LDO can be sampled for free is a plus.

To provide 5V 1A a buck converter will be used due to high efficiency compared to a LDO or fixed Voltage regulator. This also minimizes the head that will be dissipated.

The Linear Technologies LT3971A Buck Converter provides 1.3A continuous Current (up to 2A peak)

This Chip could also be sampled for free.

To power the 12V LDO 14,7V Li-Po Batteries will be used. Li-Pos are wildly available since they’re common in the RC market. 14.7V is the next higher available Voltage above 12V. A higher voltage is required by the LDO.

The size of the batteries has to be more than 1500mAh since the prosthetic system will drain around 4.5A and the time has to be 20 mins minimum. The size of the battery is TBD by the weight and volume that can be allocated to it.

References:

 SENSOR:

The MyoWare EMG has been chosen to rapid prototype because it’s widely used.

The sensor operates between 2.9 and 5,7V and connects to an analog pin on the MCU. The input voltage will be outputted to the analog pin so if you supply it with 5V and connect it to an MCU that operates at 3.3V it will cause damage to it.

To achieve better results in distinguishing the different movements two or more sensors will be used.

figure5

Figure 5 – MyoWare Test with Arduino MKR1000

 

 

 

 

 

 

References:-

system-block-diagram

Figure 6 – System Block Diagram

Given this components the complete System Block diagram is shown in “Figure 3 System Block Diagram”.

The two MCUs are used to reduce the cable tree between the upper arm and the forearm. Since only Power and the I2C Interface must run between (instead of individual cables for the Sensors and Motors).

The Teensy MCU will be located in the upper arm since it is the smaller board. (In the upper arm is less space available.

The MKR 1000 with the Wi-Fi capability will be located in the forearm.

The I2C Interface will connect the two MCUs to allow communication.

References:

MECHANICAL DESIGN (by Forrest Pino, Manufacturing Engineer)

The prosthetic arm project will stem from multiple design ideas and will incorporate the key components that will make this project a success. The prosthetic arm project will utilize modified .stl files from the open source robotics project, InMoov, in order to satisfy the requirements. The provided forearm files will be edited in order to accommodate the robotic hand that will be attached to the prosthetic arm. The .stl files for the forearm will experience most of the modification and will mostly be a guide for the prosthetic arm. Fig. 7 was provided by the InMoov project site and shows the out layering of the forearm. The forearm coverings may be removed completely or modified in a way that shows the internal structure of the arm.

figure7

Figure 7 – Basic Design for the Prosthetic Arm

figure8

Figure 8 – Inside the Forearm Structure

figure9

Figure 9 – Forearm and Elbow Assembly

 

 

 

 

 

 

 

Fig. 8 and Fig. 9 are internal housing designs provide by the InMoov open source project. The InMoov project made use of servos in the forearm while the prosthetic arm group will not be doing the same. The component housing structure for the InMoov design will most likely be removed.
The robotic hand project will not be utilizing the hand designs from the InMoov so integration between the two will be a custom design. The length of our forearm will also be determined by the specifications of the robotic hand. In order to counteract the weight of the arm, the forearm will be shortened as to not overload the DC motor with excessive leverage. One method of reducing weight will be editing .stl files so that less surface area will be printed and structural integrity will remain intact.

figure10

Figure 10 – InMoov design for Forearm

The InMoov site provided Fig. 10. The image shows and labels each part that was utilized in the InMoov design for the forearm. Since the forearm length may be reduced greatly, the only components that may be utilized will be the ones closest to the elbow. The Prosthetic Hand project will be in charge of creating the wrist so the components associated with the wrist in the InMoov design will be removed.

The methods of power and control for the prosthetic arm will differ greatly from the InMoov project. The degree of alteration means that the housing of the internal components will need to be custom. Depending on the size of the forearm, most of the components may need to be housed in the bicep of the prosthetic arm. The mechanism in the bicep that relates to extensions and contractions may not be suitable for our design and can be supplemented for system that utilizes a pulley. Utilizing a pulley could produce less friction than the InMoov design and would provide space for the PCB and other components. If a pulley were to be used, a mounting bracket would be needed for the motor. During research, an .stl file was acquired that would provide insight as to how mounting of the motor would be applied to the bicep.

Since an amputee will not be able to assist, a stand will be developed for testing and demoing. The current design will utilize PVC pipe and a hinge mechanism that will simulate shoulder movements. The stand will allow the prosthetic arm to hang in an orientation that would be similar to an amputee with a prosthetic arm. For demoing purposes, a member of the group will be able to guide the shoulder movements of the prosthetic arm while the other members demonstrate the effectiveness of the artificial limb.

figure11

Figure 11- Interconnection of the forearm and bicep

Figure 11 displays the interconnection of the forearm and bicep. The servos used in the InMoov design exceed the capabilities of the DC motor that will be utilized. This may lead to an alternate design that would provide movement to the forearm through a pulley system.

Refences:

SPECIAL ASSIGNMENTS AND DUE DATES: (by Hector Martinez, Manufacturing Engineer)

Design and Unique Task

  • Meet with Prosthetic Hand to ensure proper mating of hand and arm(9/20/16)
  • Analyze InMoov prosthetic arm design and look to modify and simplify for our mission objective (9/21/16-9/28/16)
    • i.e. no need to house strings and motors in forearm based on preliminary Prosthetic Hand design(Instructables: TACT Low-cost, Advanced Prosthetic Hand).
    • Modify InMoov heavy duty bicep design to fit our mission efficiently.
  • Look into design modifications to lighten system weight (9/21/16 – 9/28/16)
    • Trade-off study in materials (weight vs cost)
    • Search for design techniques to reduce weight. i.e. cutting a pattern into the shell
  • Study, analyze, and take apart existing prosthetic arm in ET-111 Lab (9/21/16-9/28/16)
  • Look into cost effective design for a stand to hold prosthetic arm, as well as provide limited movement. (9/21/16-9/28/16)
  • Study gearing, gear ratios, and gear options (9/21/16-9/28/16)
    • Trade-off study between off the shelf gears and 3D printed

 

NOTE:

Our 2×2 picture was taken from:

http://inhabitat.com/inmoov-is-an-open-source-3d-printed-humanoid-robot/inmoov-3d-printed-printer-robot-open-source-gael-langevin-face/

Since our project structure is going to be based on the InMoov arm.

 

Spring 2016 Pathfinder: Project Summary

/in , /by


IMG_3253

By:

Peiyuan Xu (Project Manager)

Approved by Peiyuan Xu (Project Manager)

Approved by Xiong Lee (System Engineer)

Table of Contents

Executive Summary

Project Objectives

The spring 2016 Pathfinder Rover was inspired by NASA’s MARs Exploration Rover-“Sojourner”. The profile for this semester’s project is to imitate the design of “Sojourner” Rover to prototype a new generation of Pathfinder Rover that implements the Rocker Bogie Suspension System as well as being self-sufficient by using solar panels. The Pathfinder is allowed to have the solar panels charging the battery for up to 8 hours during the day time. Then the customer can spend up to 4 hours at night walking and exploring with the Pathfinder. Ultimately, The customer can use Arxterra control panel on the PC to navigate the Rover by using the cursor to click a point on the map. This generation of Pathfinder Rover is also designed to test and implement SLAM (Simultaneous Localization and Mapping) technology for autonomous vehicles.

Mission Profile:

mission WiFi Stength                                                             Figure 1 – CSULB WiFi Strength map

Since our Pathfinder Rover will be tested at the entire CSULB campus. We need to find out where there is the best Wi-Fi signal  in order to gain the stable video stream from the android phone to the Arxterra. The system engineer Xiong Lee was able to use an android App called Wi-Fi Maximiser to map out the  Wi-Fi signal strength around CSULB campus.  Based on the strength of the Wi-Fi signal, our mission will be narrowed down to the area covered with green on the map. We suggest the customer not to go through the area covered with red because there might be some packet loss and signal lag around the area. We also think this Wi-Fi signal strength map can be useful for other EE 400D project in which case they need to explore the CSULB campus as well.

The changes that made to the Mission Profile and Project Objective can be found here:

Spring 2016 Pathfinder: Mission Profile and Project Objective Update

Design

3D illustration

                                                                      Figure 2 – 3D Model                  

The image above is the 3D illustration in SolidWorks that shows the overall design of the pathfinder.

3D illustratioin2

                                                                Figure 3 – Exploded Model                              

This image above gives the exploded view of the Project design. On the top is the Tilt system with the encasement for Google Tango tablet and Android Phone. Below that are the 3 solar panels with resemble the shape of the Arxterra logo. Then there is a metal box to protect all the electronic components. Following that is our new chassis with Rocker Bogie System.

For more details on the structures of this design, refer to:

Spring 2016 Pathfinder Design and Manufacturing – Rocker Bogie Suspension System Design

Spring 2016 Pathfinder Design and Manufacturing – Tilt System Finalized Design

Project Features:

Rocker Bogie Suspension System

  • Designed for superior vehicle stability on the uneven surface
  • Obstacle-Climbing Capability
  • High-clearance chassis
  • Slow-speed application

62                                                                 Figure 4 – Rocker Bogie System

New Tilt system for Tango tablet and Android Phone

  • Has two servos. One controls Pan system, one controls Tilt system
  • Allow stream video from Android Phone correlates with Point Cloud data in Google Tango tablet
  • Protect the phone and Tango tablet

1615                                                                       Figure 5 – Tilt System

Solar Panels

  • Self-sufficient
  • Use three pieces of solar panels to resemble the Arxterra logo

13421                                                                    Figure 6 – Solar Panels

SLAM  (Project Tango Modules)

Access to the Point Cloud Data (send data out via Tango Bluetooth API)

Use Depth perception and IMU sensors to navigate Pathfinder go where the user wants to go (Developing)

Screenshot_2016-04-07-22-38-12                                                                 Figure 7 – Point Cloud App

System Design

1                                                            Figure 8 – System Block Diagram

The system block diagram above shows how all of the components interface with each other. First, transmission of data from an android phone or the Arxterra control panel via HC-06 Bluetooth module will tell the Arduino Mega what to do. The Arduino Mega will interpret this data and send it out through the motor shield or servo driver to drive the pathfinders movement. The system block diagram also depicts how the charge controller will interface the power supply and the solar panels to the VHN5019 Motor shield that will drive the pathfinder.

For more information about the system design, refer to:

Spring 2016 Pathfinder: System Block Diagram & Interface Matrix

Experimental Results:

Current Drawn By Motors

2                                                         Figure 9 – Current Drawn Test

The purpose of this test is to find the current drawn by the motors on different terrains and in different driving modes (Braking abruptly, Rotating (Under High Stress) and Running forward/backward (Normal Driving) . This test is crucial for us to gain the discharging time of the batteries in order to meet the Level 1 requirement of constantly running for 4 hours.

For Project Level 1 requirements, refer to:

http://arxterra.com/spring-2016-pathfinder-preliminary-project-plan/

Results:

Peak current: 4.8 A (Under highest stress)

-Ex. braking abruptly, rotating, etc

Average current: 1.2 A (Normal driving)

Theoretical discharge time:

20 Ah / 4.8 A = 4.16 hours (high stress)

20 Ah/ 1.5 A = 13.33 hours (normal driving)

Actual Discharge time to 50% : 6.5 hours

This test is conducted for the Wild Thumper chassis

Video Demo

For more information about this current drawn test, refer to:

Spring 2016 Pathfinder: Current Drawn Test

Charging Batteries Using Solar Panels

3                                                         Figure 10 – Solar Panels charging the batteries

The project objective stated that the pathfinder needs to be self-sufficient by using solar panels. This test is to measure the total current the solar panels can supply at direct sunlight. In reality, the charging capability of solar panels will vary depends on the weather condition, therefore, we include some of the other tests for comparison of the worst case scenario.

Results:

-Direct sunlight: 850 – 950 mA

-Shady area: 500 – 750 mA

-Rain or cloudy: 100 – 300  mA

  •  Important note (current supply  by the solar panel  determine the time required  to  charge the battery )
  • After charging these batteries in direct sunlight for 8 hours, the voltage level of the batteries increased from 4.0 V to 6.5V which is from 54% to 87%.
  • This would meet our Level 1 requirement since it takes around 6 hours of normal conditions run time to deplete our batteries from 7.4 V to 3.4 V.

For more information on how we implement solar panels, refer to:

Spring 2016 Pathfinder Solar Panels Implementation

Project Tango Modules

Screenshot_2016-04-07-22-38-12                                                        Figure 11 – Project Tango: Point Cloud

This spring 2016 Pathfinder project used Google’s Project Tango as a platform to test and implement SLAM (Simultaneous Localization and Mapping) technology for autonomous vehicles. Project Tango uses computer vision to give device the ability to know the position in the relative 3D space as well as the distance from the surrounding objects to the device itself.

For more research work of the Project Tango, refer to:

Spring 2016 Pathfinder: Project Tango Preliminary Research

For more details of the project Tango modules our team accomplished or attempted, refer to:

Spring 2016 Pathfinder: Project Tango Bluetooth API

Spring 2016 Pathfinder: Project Tango – Interactive Visualization of data from Tango using Paraview

Spring 2016 Pathfinder: Project Tango Module#5 – Android to Arduino Via Bluetooth

Subsystem Design

Interface Definition

2 3 4                                                           Figure 12 – Interface Matrix

The above interface matrix shows in depth on which pins are used on the Arduino Mega.

For further details on interface matrix, refer to:

Spring 2016 Pathfinder: System Block Diagram & Interface Matrix

One improvement we had after PDR debrief was to highlight the rows and columns with different colors in the interface matrix. Each color represents the corresponding pins used by the component. That makes it a lot easier for us to track the subsystem level pinouts. Also this makes it easy for audience to see during the presentation.

Custom PCB Design

Fritzing Diagram

1                                                           Figure 13 – Fritzing Diagram

Breadboard

2                                                            Figure 14 – Breadboard

PCB Schematic

1                                                              Figure 15 – PCB System Schematic

2                                                                Figure 16 – Buck Regulator

PCB Layout

9                                                             Figure 17 – PCB Layout

The pathfinder project needs a custom PCB to integrate all the electronic components, which included: VNH5019 motor shield, PCA9685 Servo PWM Controller, two servos, six DC motors, HC-06 Bluetooth Module, two HC-SR04 ultrasonic sensors, two LED Headlights. The custom PCB also take advantage of the leftover pins on the Arduino Mega. A buck regulator is required to step down the voltage from 12 V to 5.5 V in order to protect the servo driver. The advantage of using buck regulator over the voltage regulator is to keep a constant current.

For further details about the PCB system schematic design and layout, refer to:

Spring 2016 Pathfinder: PCB System Schematic

Spring 2016 Pathfinder: Design and Manufacturing – PCB Layout

Hardware Design

Overall Design

Picture1                                                           Figure 18 – Pathfinder overall Design

3D illustration                                                            Figure 19 – 3D Illustration

3D illustratioin2                                                            Figure 20 – Exploded View

**Rocker Bogie System**

6                                                                 Figure 21 – Rocker Bogie System

f15                                                              Figure 22 – Exploded View

**Tilt System**

16                                                                       Figure 23 – Tilt System

15                                                                    Figure 24 – Exploded View

These above pictures demonstrate the hardware design from the overall 3D models to breakdowns parts of the pathfinder rover design.

The goal of Spring 2016’s Pathfinder is to hold a Google Tango tablet, phone, solar panels in the shape of the Arxterra logo, a tilt system, and an electronic box. To best traverse obstacles, a rocker bogie suspension system design was chosen, with a top surface area of 12in x 18in. Modeled after ServoCity’s runt rover, the chassis was scaled to meet the surface area required for the above mentioned parts. The tilt system was designed to hold the tablet, phone and tilt servo. Lastly, all parts were modeled on the chassis.

For further details of the hardware design, refer to:

Spring 2016 Pathfinder Design and Manufacturing – Tilt System Design

Spring 2016 Pathfinder Design and Manufacturing – Tilt System Finalized Design

Spring 2016 Pathfinder Design and Manufacturing – Rocker Bogie Suspension System Design

Spring 2016 Pathfinder: Design and Manufacturing – Chassis Selection Through the Iterative Design Loop

Software Design

Software System Block Diagram

1                                                        Figure 25 – Software System Block Diagram

The software design follows the system block diagram and focus on the subsystem level software modules development.

For further details on how each software modules works, refer to:

Spring 2016 Pathfinder: Software Design

For reference of Arduino code controlling motors and servos through coolterm, refer to:

Spring 2016 Pathfinder: Software Design

For reference of controlling motors through Arxterra, refer to

Spring 2016 Pathfinder: Bluetooth Communication with the Arxterra App

For reference of controlling servos through Arxterra, refer to

Spring 2016 Pathfinder: Arxterra Servo Control for Pan and Tilt

Verification and Validation Test Plans

Verification and Test Plans are required to prove that the project can meet the L1/L2 requirements.

Since our team received new requirements of building a new pathfinder in a short period of time, many of the verification tests had not yet been done due to the heavy work of manufacturing. The project final demo then was been used for some of the verification and validation tests.

For more details of the verification matrix and Validation Test Plans, refer to the “project resource”

Project Update

Work Breakdown Structure

WBS                                                              Figure 26 – Work Breakdown Structure

This work breakdown structure demonstrates all the work needed to be done for this project Pathfinder Rover. There are four branches that indicates different job duties and division works assigned to the system and subsystem engineers.

Resource Report

Mass Report & Power report

The mass report and power report are both missing because our team did not have enough time to update the reports for the new pathfinder. 

For previous mass report and power report, refer to “CDR presentaion” in Project resource file

Cost Report

cost report

 

Project Schedule and Progress

1 2 3 4 5

Above is the final schedule for this spring 2016 Pathfinder Rover Project. The Project Overall duration is 65 school days. This schedule was made and managed by the project manager to keep on track of the project overall progress. The tasks highlighted in green are the major tasks our team accomplished during this semester, while those tasks highlighted in yellow are the tasks our team had difficulties and could not accomplish them on time. In this semester, our team was able to fully tested, debugged and implemented the code for motors control and servos control for pan and tilt system through both coolterm and Arxterra. Another progress we made was to build a new generation of pathfinder by implementing Rocker Bogie Suspension System and solar panels self-charging capability. However, the team had troubles of implementing Project tango modules to the pathfinder.

BurnDown

BD

Completion

completion

The Project Overall completion is 83%.

 

Concluding Thoughts:

Lessons learned the hard way

  1. The major problem our Pathfinder Team had was Project Tango. It is fairly new and has many limitations on sensor abilities as well. After we done the research of project tango, we realized that it requires extensive knowledge of Java programming and Android App development to accomplish the mission. Unfortunately none of the team member had that experience.
  2. The second issue we had was that the project requirements kept changing during the beginning of the semester. The mission profile went from daytime at desert terrain to night time at CSULB campus. The is due to the fact that the tango’s IR sensors for depth perception is generally restricted to indoor environments (sun and incandescent IR light can drown out structured light sensing).
  3. The third issue we had was that the manufacturing process for the aluminum sheets took too long from the rough cutting to mill finish. The aluminum was cut by hand by group members that weren’t supposed to be involved. As the project manager, I decided to let the the whole team contribute on assembling the parts during the final week to accomplish the mission. But the downside was that we did not have enough time to redo some of the verification tests for new chassis and motors.
  4. It is hard to manage the conflicts among cost, schedule and performance. Our pathfinder team was having trouble on getting all the parts we wanted. We were approved to get an extra budget of $300, yet, we still did not have enough money to get better wheels. The wheels problem lowered our project performance on obstacle climbing test.

Future Plans for Pathfinder

  1. Keep working on Project Tango. It is recommended to have 1 or 2 team members who has good knowledge of Android App development or some students from computer science major who can commit to help this project.
  2. The experimental results in this blog post need to be updated.
  3. The Mass and Power report need to be updated.
  4. Change the wheels on the pathfinder.
  5. Improve the encasement for tango (sealed, waterproof). This pathfinder can be taken to the wild area.
  6. Think of a way to rearrange the weight on top of the pathfinder. One issue we had was that the weight distribution was more on the backside, therefore it gives unstableness when climbing the obstacles.

Future Plans for project manager

  1. I think the project manager needs to be trained on their project management skills. Learning how to manage the cost, schedule and performance. A good way is to have a guest speaker give a short lecture on that.
  2. Project manager should post a project update blog post every two weeks. It can help them to keep on track of the project progress and schedules. It is also Easy for team member to follow.

Project Resource Files

Project Video

PDR

CDR

Project Schedule

Verification and Validation Documents

Solidworks File

Fritzing File

EagleCAD File

Arduino Code

PCB Library

Bill of Material(1)

Bill of Material(2)

 

 

 

 

 

 

 

 

 

 

 

 

 

         

 

 

 

Spring 2016 A-TeChToP Central Sensor Suite Sensor Post #2

/in , /by

By: Stephen Cortez (Electronics Engineer)

Introduction

This blog post will cover the remaining two sensors that were made by the group, which includes the ECG and blood oximeter. Research concluded that commercial devices for these categories were either too large or too expensive to implement into the project, requiring custom sensors.

Read more

Spring 2016 AdBot Materials Trade-off Study

/in , /by

By Muhammad Maqbool (Manufacturing and Design)

There are many different types of material we used to finish our final design. The body and the arms of our AdBot were made of aluminum of 0.125” thickness that we obtained from McMaster. The reason for using aluminum instead of plastic was the size of our body and we wanted a strong and reliable material—something that would not fall apart. It was impossible to 3D print the body of our AdBot. Our president Ryland had access to welding tools and drill press; he helped us put the body together and did a pretty good job with it and we ended up saving a lot of money. Our major concern after the body was put together was the weight. The body is strong but it is heavy.

For our 3D printing material, we went with ABS plastic because:

  • ABS is stronger than PLA
  • Cost less
    • Easy to use
  • Heat-resistant
  • Water-resistant

Source: http://www.makergeeks.com

UFO Quadcopter Project Summary (Spring 2016)

/in , /by

Luis Valdivia (Project Manager)
Juan Mendez (Manufacturing Engineer)
Anthony Becerril  (Systems Engineer)
Kevin Nguyen (Electronics Engineer)

 

Table of Contents:

  • Project Overview
    • Executive Summary
    • System Design
    • Experimental Results
    • Subsystem Design
      • Interface Definitions
      • Custom PCB Design
      • Hardware Design
    • Software Design
    • Verification and Validation Test Plans
    • Project Update
    • Project Demonstrations
  • Project Blog Posts
  • Concluding Thoughts
  • Project Resources

 

Project Overview:
 These series of summaries break down all the project efforts done throughout this semester of work. This overview follows our Critical Design Review with the Debrief details here.

Executive Summary

  • Project Objectives
    • The program objective is to ultimately achieve stable flight with our UFO Quadcopter while in operation. A 5th fan will be used as attempt to counter unwanted yaw rotation thus maintaining stability without surpassing weight limitations. The UFO Quadcopter will feature connectivity to an RC Controller and also a smartphone device via Bluetooth.
  • Mission Profile
    • Following safety requirements by CSULB and FAA, UFO Ab-ducted will fly vehicle in open field away from CSULB for a minimum of 7 seconds. The aircraft must display FAA registration code, FA3C74WXLT , while in flight. The user must also follow these safety requirements set by the FAA:
      • I will fly below 400 feet
      • I will fly within visual line of sight
      • I will be aware of FAA airspace requirements: www.faa.gov/go/uastfr
      • I will not fly directly over people
      • I will not fly over stadiums and sports events
      • I will not fly near emergency response efforts such as fires
      • I will not fly near aircraft, especially near airports
      • I will not fly under the influence
  • The Design
    • Flap assembly

finalflap123

Figure 1.1 CAD Model of UFO quadcopter and thrust vectoring flaps

    • Thrust Vector Control assembly

finalcones123

Figure 1.2 CAD Model of UFO quadcopter and thrust vectoring attachments

    • Additional Fan assembly

finaladditionalfans123

Figure 1.3  CAD Model of UFO quadcopter and additional side fans

System Design

  • System Block Diagram
    • Our system block diagram’s main component is our flight controller, the MultiWii 328P. Through use of our Lithium Polymer battery, we are able to power all our electronics as outlined below:

finalinterface123

Figure 1.4 System block diagram of UFO quadcopter Spring 2016

Experimental Results

One experiment that was done was a torque experiment. This was done in order to find the torque that the yaw problem was producing and with the results we would be able to use to counter that torque. Research was conducted to create a proper test. A torque apparatus was then built where the test was conducted. The procedure for the test and results can be found in UFO Torque Test Spring 2016.

To figure out the necessary thrust from the 5th and 6th fan, we used the highest torque test reading .0515Nm along with the 6 inch fan rod and the torque formula using in physics class. Using the equation m=(Torque)/(g*radius) , we conclude m=(.0515Nm)/(9.8 *6 inches)  –> m=.03448Kg is the necessary thrust counter the yaw rotation caused from the 4 EDFs. Since we used two side fans, we can set the output thrust for each fan to 17.24 grams. Using the buck converter, we turned down the voltage to produce that thrust per fan (2 fans). From the results we need to keep the output voltage from the buck to be roughly 1.91 volts to produce around 17 grams. Below we demonstrate the measure thrust values of the 5th and 6th fans with respect to different voltages.

Voltage Thrust
2.97V 33 g
1.92V 18 g
1.9V 14 g
1.56V 8 g

Table 1.1 Demonstrates the relation between Voltage and Thrust for the additional side fans.

The current drain experiment consisted of a shunt resistor and a multimeter to measure the current draw. Since our motors draw large amounts of current, the multimeter was not able to take any proper measurements. To bypass this, a shunt resistor was used to measure voltage rather than current. After finding the voltage across the shunt, simple calculations can be done to acquire the current measurements. Details on this test can be found in Current Draw Spring 2016

 

Testing the functionality of Bluetooth vs. RC, an experiment was done by controlling the quad with each controller and incrementing the distance until connection was lost. The RC controller proved to be much more reliable and can communicate at well over 30 feet. The bluetooth communication often had trouble disarming the quad so it can’t stop the quad once things get out of hand. Information on Bluetooth Communication can be found the Bluetooth Communication: Smart Phone Applications Spring 2016 blogpost.

 

Details on RC Communication with the UFO can be found on our RC Control Spring 2016  blogpost.

 

Subsystem Design                                                                

  • Interface Definition
    • Our interface definition is as follows:

finalinterfacechart123

Figure 1.5 Interface definition demonstrating ports used in the project

    • Following our interface definition is our wiring tree where all hardware is laid out and details on connections. It is as follows:

finalcabletree123

Figure 1.6 Cable Tree of overall electronics for UFO Spring 2016

  • Custom PCB Design

Fritzing:
Since PCB fabrication is a time-and-costly procedure, a prototype must be developed to ensure that the PCB would work the first time. The first step to the prototype is the Fritzing Diagram. The Fritzing Diagram maps out all the connections of the components on a breadboard.

Physical Board:
Continuing off the Fritzing Diagram, the physical prototype is implemented on a breadboard and tested using a power supply. The power supply was set to 14.8V to simulate the battery and the output was measured to be 4.94V.

Schematic:
After the prototype was confirmed to be working, the next step is to design the schematic for the PCB. The components had to be carefully chosen to include SMD packages. The components had to be changed multiple times since those packages were not available on DigiKey. Once all the required components were on the schematic and all the connections were wired properly, the Eagle files were given to the Manufacturing Engineer to do the layout.

Layout:
After designing a PCB schematic for the project, a layout had to be done in order to have it fabricated. The board was designed to be mounted on the UFO. Components were placed properly and trace widths were modified. Once the board was laid out, it was sent to be fabricated and then it was built. Further details can be found in UFO PCB Layout Spring 2016.   

  • Hardware Design

Several designs were taken into consideration in order to fix the yaw problem. The original design was to implement thrust vector control. This was done by adding attachments to the electric ducted fans and which would be able to control the direction of the thrust produced using servos. Unfortunately due to some unexpected issues, the idea of thrust vector control could not be implemented. Further details such as 3D models, dimensions for the original design can be viewed in Designs of 3D Printed Attachments Spring 2016.

Since this idea did not work, an alternative solution was thought of. The next approach was to add additional fans to counter the yaw problem. This did not give us issues as the previous design did. Further details about this alternate design can be viewed in Spring 2016 5th Fan Bracket Design.

Minor modifications were done to the UFO in order to increase the space for the battery while reducing the weight. Details can be viewed in Spring 2016 Re-design of Structure Rods.  

Software Design 

  • First provide general block diagram of the software system, followed by arduino software modules responsible for communicating with the android app, specifically command and telemetry decoding and encoding.
  • Subsystem software unique to product presented.
  • Next talk about command and telemetry, (few critical subsystem software modules (1 or 2).
    • For each module present, pseudo-code and/or flowcharts to provide an overview of the software
    • Also provide sample code

Verification & Validation Test Plan Matrices

  • Verification Matrix
Requirement Number(s) Shall Statement Verification Method Summary Verification Method Results Pass/Fail
1.1, 2.1.1, 2.1.2, 2.1.3 UFO Ab-ducted quadcopter shall maintain stable flight for at least 7 seconds. Quadcopter will be timed via digital stopwatch from start of flight to end of flight. Flight will also be recorded to verify flight duration. Only flights that are stable with minimal yaw rotation will be accepted. Time must be within the tolerance of +/- 0.2 seconds (time between 6.8-7.2 seconds). Test TBD TBD
1.2 Project shall be completed before end of Spring 2016 semester which ends on Friday, May 13th, 2016. Project efforts shall be completed by Friday, May 13th, 2016 therefore no more work to be done thereafter Analysis Project was completed at the conclusion of Friday, May 13th, 2016. All documents and efforts were completed at the end of this day Pass
1.3, 2.3.1 UFO Ab-ducted quadcopter shall comply by rules and regulations of the Federal Aviation Administration (FAA), Unmanned Aircraft Systems (UAS), and California State University, Long Beach’s College of Engineering’s flying policies. To fulfill compliance of FAA, UAS and CSULB COE, the quad copter shall be registered as a flying object and shall not break any rules and regulations Inspection quadcopter is officially registered. It was registered under the identification number FA3C74WXLT. It also abides by the rules and regulations such as: Pass
1.4 Budget for this project shall remain below provided budget of 167 U.S. Dollars Shall have approved budget with evidence via reciepts with the total cost lower than the provided budget Analysis Budget was submitted and approved at a total of $156.34 with supporting documents and information to complete the reimbursement process Pass
1.5, 2.5.1 UFO Ab-ducted quacopter shall feature a light show of at least 3 unique patterns. The lightshow shall be displayed and while on display is to give at least 3 unique patterns Inspection TBD TBD
1.6, 2.6.1, 2.6.2 The UFO Ab-ducted quadcopter shall be capable of control with wireless communication for a range of at least 10 feet. The wireless communication will be setup and tested with increasing distances away from the quadcopter being recorded Test TBD TBD
1.7, 2.7.1 The UFO Ab-ducted quadcopter’s Printed Circuit Board (PCB) shall power at least one servo at 5 five volts via a buck converter. Each pin and component on the PCB will be tested to give the 5 volts from the battery/voltage source. Test TBD TBD

Table 1.2

    Verification Matrix with requirement numbers
  • Validation Matrix
Requirement Number Objective Validation Method Summary Validation Method Pass/Fail
1.1, 2.1.1, 2.1.2, 2.1.3 UFO Ab-ducted quadcopter shall maintain stable flight. Customer will evaluate stable flight of quadcopter. Demonstation
1.3, 2.3.1 UFO Ab-ducted quadcopter shall comply by rules and regulations of the Federal Aviation Administration (FAA), Unmanned Aircraft Systems (UAS), and California State University, Long Beach’s College of Engineering’s flying policies. Customer will observe registration number and paperwork. Inspection
1.4 Budget for this project shall remain below provided budget of 167 U.S. Dollars Customer will observe and confirm budget paperwork. Inspection
1.5, 2.5.1 UFO Ab-ducted quacopter shall feature a light show of at least 3 unique patterns. Customer will observe lightshow. Inspection
1.6, 2.6.1, 2.6.2 The UFO Ab-ducted quadcopter shall be capable of wireless communication. Customer will observe wireless communication via RC and bluetooth. Demonstation
1.7 The UFO Ab-ducted quadcopter’s PCB shall power at least one servo via buck converter. Customer will observe servo powered via PCB servo driver. Demonstation

Table 1.3 Validation Matrix with requirements, objectives, and summaries

Project Update

  • Work Breakdown Structure

finalwbs123

Figure 1.7 Work Breakdown Structure for the engineers in each division

  • Resource Reports

final mass budget5

Figure 1.8 Resource report referring to Mass report for UFO Spring 2016

finalpowerbudget123

Figure 1.9 Resource report referring to Power report for UFO Spring 2016

costreportfinal5

Figure 1.10 Resource report referring to Cost report for UFO Spring 2016

  • Schedule
    • Project Libre:

The project schedule was documented using, Project Libre. Every task was listed under each engineering division to display the engineer responsible for each task.

finallibre1123

finallibre2123

finallibre3123

  • Burndown

burndownfinal5

Project Demonstration

Project Blog Posts

Lipo Battery Safety Spring 2016
This post is a step by step guide on how to use the LiPo charger. Failure to handle the LiPo in a safe manner may result in damaged batteries….or worse self injury to user.

Lipo charger

PCB Design: Schematic – Spring 2016
This blog post includes full detailed explanations on the components used within our PCB. Images of the components on Eagle Schematic are posted above each paragraph to give the reader a better understanding. Full schematic image is provided to show the connections between each component.

thumbnailforpcb

Current Draw Spring 2016
High powered motors are difficult to measure with a multimeter since the current draw exceeds the specifications of the meter. This post explains how to measure the current draw by measuring the voltage and resistance instead.

20160424_210322123

RC Control Spring 2016
RC control is a must for quadcopters since bluetooth is short-ranged and unreliable. This post will guide the user through setting up the transmitter and receiver as well as setting the proper configurations on the MultiWii.

rc controller123

Prototype: Fritzing and Breadboarding – Spring 2016
To ensure that the PCB works the first time, a prototype is needed to test the functionality of the circuit. This blogpost overviews the process of creating the prototype circuit.

Fritzingfinalized123

Spring 2016 Trade off study: 5 Blade EDF vs 10 Blade EDF
This blogpost compares the different thrust outputs from 5 Blade EDFs and 10 Blade EDFs. We demonstrate different throttle positions on our RC controller which correspond to different thrust from. We will finally see which fan is the strongest!  

BO3GFEVO

UFO Mass-Thrust Trade Off Studies Spring 2016.
Trade off studies were performed in order to determine how much weight the UFO can have before it got too heavy to lift off. An equation was found which allowed us to calculate the max weight. In order to confirm this equation with the UFO weight, servos, 3D printed attachments were added on. 

20160419_201321

Bluetooth Communication: Smart Phone Applications
Going over communication and controls, this post summarizes the smart phone applications used to receive data from the quadcopter flight controller sensors as well as use other applications to control the quadcopter rather than RC control.

phone

Bluetooth Module Update Spring 2016
This details the bluetooth modules used previously and the new one implemented moving forward in series with the MultiWii flight controller and its GUI.

bluetooth123

Verification and Validation Matrices Spring 2016 UFO
As detailed on the verification matrix, the following requirements have their own pass/fail results detailed:

1.1verif5
1.1 – Stable Flight
1.2 – Project Completion
1.3 – FAA, UAS, CSULB COE Compliance
1.4 – Project Budget
1.5 – Lightshow
1.6 – Wireless Communication
1.7 – PCB

 

UFO Spring 2016 – EDF Area Coverage With Flap Length Calculations
We performed some calculations to determine the size of the allowable flap length on our EDFs. Using Microsoft Excel, we were able to determine an array of sizes with their corresponding output thrust.

mvw123

Using Multiple servos without servo driver UFO spring 2016
As a way of rapid prototyping our system without a servo driver, we wrote a blogpost to show an alternative to controlling servos. This method involves a simple wiring diagram with example code for various methods.

IMG_20160327_211605829

UFO Light Show Setup
The Neopixel ring is the aesthetic cornerstone of our wondrous quadcopter. This blogpost shows how to setup the hardware and software for the lightshow.

Screen Shot 2016-04-20 at 21.59.20

Project Preliminary Design Spring 2016 Millennium Falcon
This is our continuing on our research blog post which together is known as our Preliminary Design Review. It outline the beginning of all our work and sets up our fundamental understanding of project moving forward.

MF Shell

Spring 2016 Millennium Falcon Research
This post is an outline of our research of past quadcopter projects and possible solutions for approaching these solution.

 

Millennium Falcon5

Spring 2016 Millennium Falcon Preliminary Design Document
A Preliminary Design was put together for presentation by all group members. Here Program objective, Level 1 and 2 Requirements were defined along with Product Breakdown structures and project designs. Further details about the sections mentioned can be found in Spring 2016 Millennium Falcon Preliminary Design Document.

possibleMF55

Concluding Thoughts:

Improvements for next semester:

  1. Next semesters should focus on flying the aircraft for more than 7 seconds.
    1. Consider a battery with a higher current capacity.
    2. Different fans. The ones we are using consume so much power at a small output thrust. Since we were extremely close to the weight limit, it seemed like the only option was to replace fans. Also, getting new fans with the option of 2 clockwise and 2 counter clockwise, will automatically eliminate the thrust and all excess hardware used to counter it. The multiwii knows how to talk to 2 clock wise and 2 counter clockwise fans, not all 4 clockwise.
  2. Include an emergency kill switch for the quadcopter in case disarming function does not work. When we tried using the Bluetooth app, BTCon2Drone, the disarm function would not register. To ensure safety to the user(s), include some sort of wireless command to disconnect the system from the battery.

Lessons learned:

  1. Don’t use the battery without the LiPo alarm. It is dangerous to overcharge a battery as well as over discharging it, ESPECIALLY A LIPO BATTERY.
    1. When we first started this project, no one was familiar with LiPo batteries. During one of our tests we over discharged a battery because we didn’t use the LiPo alarm. Luckily we were able to disconnect the battery the second we noticed a drop in performance. Fortunately no one was hurt, but our battery got a bit puffy from its original form.
  2. Always keep spare equipment around! Throughout the semester EDFs stopped working on us, ESCs burnt up and batteries failed. We were lucky enough to have a back up or order a replace before major deadlines. No one expects their equipment to fail, but anomalies are unpredictable to all electronic devices.

 

Things we could have done different:

  1. Implement different circuit to for servo driver. Ideally we chose a Buck converter to step down the 14.8V to 5V. Although, we did not realize the servos would hog enough current to prevent other servos from actuating. After testing our PCB we were able to control 1 servo while any additional servos would stall or jitter. We would advise further research of even current distribution between all servos.
  2. Upgrade the existing quadcopter frame. We didn’t realize this suggestion until after we noticed some of the carbon rods were caved in from over tightening of set screws. Since this frame has been passed down for a few semesters, it would be a good idea to check its condition and consider upgrading to a new frame.

 

Project Resources:

 

To best complete the transitioning of this project for future students, a resources folder was compiled into a Google Drive folder. The access to this folder is here: https://drive.google.com/folderview?id=0B5GCeIa4TgwtNjM0VXBoNTBTWDg&usp=sharing

 

It is best to read the “UFO_SP16_AResourceSummary” document and following through with all the additional, provided documents in the resources folder and get up to speed on the project’s progress.

Verification: Requirement 1.5 – Lightshow

/in , /by

Posted by: Luis Valdivia (Project Manager)
Written by: Anthony Becerril (Mission, Systems, and Test Engineer)

 

Following the Verification and Validation Matrices, this post follows the level 1 requirement 1.5 – designing and implementing a lightshow to display at least 3 unique patterns. This also satisfies its corresponding level 2 requirements if applicable.

 

To meet the requirement, the use of the NeoPixel LED Ring had to be implemented into the quadcopter and designed to properly work through the Printed Circuit Board (PCB) and display at least 3 unique patterns. Following the previous post on the lightshow,  The lightshow properly works and has been emulated successfully. Next, through use of our PCB, the LED ring is to be powered and programmed to display the lightshow. The PCB was unable to produce the light show emulated before due to the problems of going through I2C. Supporting documentation is provided below and we have completed and failed this requirement.

 

Additional Resources:

Previous Blog Post: Verification and Validation Matrices (Spring 2016)

Previous Blog Post: UFO Light Show Setup (Spring 2016)

Spring 2016 AdBot Final Project Documentation

/in , /by

AdBot Final Robot 2

AdBot is a robot that can drives around campus in place of a person passing out flyers.

Dang Le (Project Manager, Electronics and Control)
Don Tran (Mission, Systems, and Test)
Muhammad Siddiqui (Manufacturing and Design)

Table of Contents

Executive Summary

Program Objective
The project objective is to build a rover that will simulate a flyer distributor advertising CSULB’s Eta Kappa Nu social, guest speaker, and technical events on campus. Using a single power source the rover will launch from, and return to, an HKN advertisement booth and run in a general high foot-traffic area on campus which consists of flat areas, sloping areas, and stair ways, as shown in the course map. The rover will be controlled remotely using a computer with internet connection. Negotiations of budget resulted in the rover to cost less than or equal to $250. There is to be expected 0 to 16 mph wind during the course run on May 13th (Reported in Weather Report) [1].

Mission Profile
The perimeter of the grass is 275 ft / 84 m. The north and south sides are leveled. The east side has 9 steps. The west end is a ramp.

Figure 1 Test Course

Figure 1 Test Course

Level 1 Customer Requirements
1.1 AdBot shall travel at 4.55 ft/s at the pace of an individual delivering flyers.
1.2 AdBot shall follow CSULB Regulations for Activities and Advertising.
1.3 AdBot shall launch from the HKN booth and return.
1.4 AdBot shall operating with one power source.
1.5 AdBot shall be controlled remotely through Arxterra Control Panel.
1.6 AdBot shall go up nine steps of a staircase.
1.7 The budget shall be $250
1.8 AdBot shall protect its hardware from weather conditions on the day of the final.

Level 2 Requirements
1.1 AdBot shall turn at 84 rpm.
1.2 AdBot’s sign holder shall be within 3 ft.
1.3 The course shall be completed in 8 min.
1.4 AdBot’s current draw shall require 1000 mAh.
1.5 The Arxterra app can connect via bluetooth within 3 ft.
1.6 AdBot shall provide 25 kg-cm torque to straighten out.
1.6 The sign shall be 5.3 in. from the back of the chassis.
1.6 AdBot shall not bend at the motors or servos due to weight.

Design Solutions
Tracks instead of wheels make AdBot look military. They can drive over obstacles on the ground without getting stuck.

Prototyping

For the PDR, the chassis was built out of wood and 3D printed wheels. The 3D printed tracks had more tension in hopes that they do not fall off. The wheels had longer treads. AdBot was powered by battery. It moved with differential drive control and could drive forward, backwards, and turn. The tracks shifted on the wheels. The servos moved using an unsigned byte, slider from 0-90, custom command in Arxterra.

For the CDR, the chassis was built out of 6061 aluminum. The wheels were reprinted and prevent the tracks from undoing. The left side tracks moved together; the same goes for the right side.The motors were switched to higher torque ones and changed from 6 V to 12 V. Without a battery yet, AdBot was powered with a AC to DC wall adapter and wire. The geared motor to lift the arms was not finished.

Prototype

Motor Driver Trade-Off Study
The Arduino pins supply less than 0.040 A. The solution to drive motors is to find motor drivers. The trade-off study is in this link here.

Motor Trade-Off Study and Torque Test
DC motors are commercially available and offer choices. The motors have gears that changes thousands of rpm into hundreds. The motors of interest offer more torque force with decreasing speeds. Several motors are purchased and tested as stores do not claim the torque information or stall current. This link link has information.

Experiments
AdBot was taken to lab equipment to measure the motor specifications. Free multimeters have a 0.020 A limit. The torque test apparatus was used on motors. 1K, 5K, 10K, and 20K potentiometers could not stall the motors. The motor shafts were held onto a bearing by a screw and the bearing was attached to a wheel. This was done in order to provide grip to cause stalling. More information is here .

Subsystem Design

PCB Design
The custom PCB is a shield that fits on top of the Arduino Uno. It contains motor drivers to supply current to five motors. It features an HC-06 bluetooth module. The layout and schematic are in these links here and here. We made a through-hole PCB, but had to remake it into surface mounted.

AdBot Final PCB

AdBot Schematic

Arduino Software Code Design
The firmware folder has many files containing multiple functions. The commandDecoder receives information from the Arxterra app in the form of a command packet and authenticates it. It will then pass the data packet to commandHandler to distinguish out if this is a move operation or camera-related operation and whatnot. The Arduino code then passes the packet to a function that will work on it. move_TB6612FNG() receives a packet for driving. The code is in this link here.

Software Block Diagram

Software Block Diagram

Interface Matrix Definitions and System Block Diagram
A system block diagram and interface matrix are available so that this project can be replicated. They show the components that are used and wire connections. AdBot’s interface matrix begins displaying all the Arduino Uno’s pins and names. Components are placed in columns. When an Arduino pin is not vacant anymore, the row turns white to indicate that the next component cannot place a jumper lead in the white box. The table and diagrams are in linked here.

Interface Matrix Definition

Interface Matrix Definition

Hardware Design

There are many different types of material we used to finish our final design. We wanted to use strong and reliable materials. Material trade-off study is described in this page here.

Our project manager worked on the schematic and the manufacturing engineer put together the layout. One of the problems our manufacturing engineer faced while doing the layout was the positioning of the pins that will be connected directly to the Arduino Uno. Information about the custom PCB manufacturing is in this link.

Start out with understanding the basic design of AdBot. It consists of a total of eight big wheels, eight tension wheels, four tracks, two gears, one wooden shaft, one wooden pole, one pole holder, and one flat top. The design for the wheels and tracks are from previous semester’s RoSco. I modified them so that they work for AdBot requirements. Details about designing in SolidWorks is here.

Verification and Validation

Verification Test Plans
AdBot’s performance depends on the test plan. These plans show the requirements were considered and are kept when constructing AdBot. The table is linked here.

Verification Table

Validation Test Plans
The customer looks at qualitative features of the product built. Validation tests are done on the day of the final demonstration. The table is linked here.

Validation Table

Project Status

Mass Budget
Knowing individual masses lets the manufacturers know what components or materials to take out or replace. The allocated mass is based on the overall masses to stall the drive motors.

Mass Report

Power Budget
Power Report

Cost Budget

The construction of AdBot rover received a $250 budget. After the first few weeks, $100 was spent on breadboard parts and the chassis. The team has to keep track of our budget during the time building the project. Luckily we saved money and time on shipping due to our team purchasing Amazon prime. The project ended up with approximate $208 of spending—not including the PCB fabrication and SMD components. The cost of the end product is shown.

Cost Report

Project Schedule and Work Breakdown Structure

Project Libre was used to schedule the semester. The WBS illustrates the members’ duties in the schedule and pace to complete those. The depictions are shown

Schedule_1

Schedule_2

Final_BurnDown

The burndown line will not reach zero in software.

Schedule_3

 

Project Demonstration

Concluding Thoughts

AdBot is designed after a tank, and it is built from the ground up on a $250 budget. We ordered several parts from China to save several dollars. This mistake delayed our project for the CDR presentation. We spent a lot of our money during the design phase too on tools and parts to learn to use. With four weeks left and no electronics engineer to make a new schematic, the systems engineer, manufacturing engineer, and I worked extra overtime. The systems engineer had a difficult time writing and troubleshooting his C++ functions that receives commands from the Arxterra application. I was busy a lot in the project, because having one person working on manufacturing is not enough. Construction requires multiple heads to check, cut, drill, and build correctly. Everyone worked on software and tasks almost everyday for months.

The front motors at the end of the arms on AdBot are heavy. It places enough tension on the shaft to shake the servo around, which is screwed onto brackets. In this situation, the president helped us mount the servo securely. To make AdBot better, we should move the motors inside the chassis to drive the four front wheels. The tracks are too long to print on certain machines. The printed tracks took a long time to work on, but after printing, they do not come out as expected. On the final, we used metal tracks.

 

Resource Files

The system and software block diagrams are created using the full version of Shapes.

AdBot Video

CDR

PDR

Project Libre Schedule

Verification & Validation Table

SolidWorks Model Files

EagleCAD Schematic

RoSco Arduino Firmware

AdBot Arduino Firmware

AdBot Interface Matrix Definition Excel Sheet

Software Block Diagram

System Block Diagram

AdBot Bill of Materials