Pick and Place – Preliminary Design Document

Belinda Vivas (Project Manager)

Amber Scardina (Mission, Systems, and Test)

Kevin Ruelas (Electronics and Control)

Tyler Jones (Manufacturing)

Chastin Realubit (Manufacturing)

 

Table of Contents

 

Program Objective/Mission Profile

By: Belinda Vivas (Project Manager)

Objective

The second generation of the Pick and Place will create a 3-Dot 454 PC Board. It will ensure precision through the addition of a camera system, addition of a variety of components, design upgrade, and a user friendly mechanism. A CSV file will be created for this generation, to implement a better interface between the user and the machine. A manual will be provided for this generation, as well as for the Madell Pick and Place for which extensive research is being done to implement the design of the camera (edge detection) system and software interface. A more detailed list of the customer’s needs can be found on the link provided.

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

Requirements

Level 1 Program/Project Requirements

By:  Belinda Vivas (Project Manager)

  1. Through research on the Pick and Place first generation, the Madell Pick and Place, and the customer needs the following requirements will be implemented for the design of the second generation. This requirements will allow to define a clear structure for the design, engineering, and further requirements for the project.
  2. The pick and place shall have an attached compartment to hold accessories for the pick and place.
  3. The pick and place shall meet the EE 400D cabinet specifications for storage purposes.
  4. The pick and place shall incorporate a camera for edge detection.
  5. The pick and place shall have resources to aid the user of the pick and place in set-up and configuration of the pick and place.
  6. The pick and place shall have a case to protect the pick and place from its surroundings.
  7. The pick and place shall produce a 3Dot board in a specified time. This specified time is currently set for one hour, although after trade-off studies are conducted this time may change.
  8. The user of the pick and place shall be able to set-up and configure the machine in a specified time. This specified time is currently set for two hours, although after trade-off studies are conducted this time may change.
  9. The pick and place should have minimal movement from outside sources.
  10. The pick and place shall cost no more than $500.
  11. The pick and place shall be completed by Wednesday 17th, 2017.
  12. The pick and place should have an emergency shut off button.

Level 2 System/Subsystem Requirements

Level 2 System Requirements of Pick and Place (1st Generation) Analysis

By Amber Scardina (Mission, Systems, & Test)

Listed above are the Level 2 Requirements for the first generation pick and place. The Level 2 Requirements for the first generation demonstrates the functionality of the current pick and place machine. After analyzing these requirements, the following updates need to be made:

 

  1. Size: The pick and place needs to be stored in the EE 400D cabinet.
  2. More Components: Additional feeders and component trays need to be added to accommodate all components for a complete 3Dot EE 400D board. The reels on the first generation will be removed.

 

Given the updates listed above, the other level 2 requirements from the pick and place first generation should still hold true for the second generation, exhibiting the same functionality. After trade-off are conducted, more updates and level 2 requirements for the software and manufacturing subsystems may be required in order to successfully verify and validate the level 1 requirements. Additional Level 2 Requirements will be included in the second generation to make the pick and place user-friendly. In the next section below, the level 2 requirements for the pick and place second generation is listed.

 

Source Material:

  1. https://www.arxterra.com/spring-2016-smd-pick-and-place-machine-preliminary-design-document/
  2. http://arxterra.com/goliath-fall-2016-preliminary-design-documentation/#Design_Innovation

Level 2 Subsystems Requirements of Pick and Place (1st Generation) Analysis

By Amber Scardina (Mission, Systems, & Test)

The level 2 subsystems requirements for the pick and place 1st generation can be found in the following link:

https://www.arxterra.com/spring-2016-smd-pick-and-place-machine-preliminary-design-document/

The subsystem requirements should still hold true for the second generation. The system should contain the original manufactured parts (except the reel mechanism), with the addition of new parts to verify and validate the level 2 system and level 1 program/project requirements. The level 2 subsystem requirements helped describe the functionality of the system that will be incorporated into training materials for the second generation.

Level 2 System/Subsystem Requirements of Pick and Place (2nd Generation)

By Amber Scardina (Mission, Systems, & Test)

 

1.     The pick and place shall have an attached compartment to hold accessories for the pick and place. Accessories for the pick and place may include: pump, paste, components, etc.

a.     The dimensions of the pick and place and the attached compartment shall meet the EE 400D cabinet specifications.

b.     The attached compartment shall not interfere with the functionality of the pick and place machine.

2.     The pick and place shall meet the EE 400D cabinet specifications for storage purposes.

a.     The legs of the pick and place should be raised to meet of the specifications of the attached compartment.

b.     The Z/A axis should not be removed from the pick and place in order to be stored in the cabinet.

3.     The pick and place shall incorporate a camera.

a.     The camera of the pick and place shall be used to incorporate edge detection technology.

4.     The pick and place shall have resources to aid the user of the pick and place in set-up and configuration of the pick and place.

a.     The resources for the pick and place shall include a video tutorial on how to handle (set-up) and configure the machine.

b.     The resources for the pick and place machine shall include a written manual to assist the user in set-up and configuration.

c.      The pick and place shall include sample (test) files for the user to practice with the machine.

d.     The resources for the pick and place shall include a section for troubleshooting the machine.

5.     The pick and place shall have a case to protect the pick and place from its surroundings.

a.     The case shall enclose the machine to meet the EE400D cabinet specifications.

6.     The pick and place shall produce a 3Dot board in a specified time. This specified time is currently set for one hour, although after trade-off studies are conducted this time may change.

a.     The pick and place shall be faster than human production time. Human production time for a 3Dot board is currently established as four hours.

7.     The user of the pick and place shall be able to set-up and configure the machine in a specified time. This specified time is currently set for two hours, although after trade-off studies are conducted this time may change.

 

Source Material:

1.     https://www.arxterra.com/spring-2016-smd-pick-and-place-machine-preliminary-design-document/

2.     http://web.csulb.edu/~hill/ee400d/Lectures/Week%2004%20Modeling/b_L2%20Requirements.pdf

 

Design Innovations

Creative Solutions

By: Belinda Vivas

A creative exercise was executed by the members of the team to begin the process of brainstorming ideas to incorporate new innovative design ideas for the Second Generation of the Pick and Place. Focusing mainly on the problem of mounting the electronic components into the PC Board without them moving out of place. Also, how to implement a better overall design for a more user friendly generation.

https://drive.google.com/open?id=0B9iWYCBTJWEERHB6Y1BHX2owdFU

Systems/Subsystem Design

Product Breakdown Structure

By Amber Scardina (Mission, Systems, & Test) and Belinda Vivas (Project Manager)

  

The Product Breakdown Structure (PBS) demonstrates the updated system and subsystems for the Pick and Place 2nd generation. The updates for the pick and place can be classified in three categories: Customer Interface, Software, and Manufacturing. These categories are described by the Level 1 Program/Project Requirements. The customer shall interface easily with the pick and place machine by giving the customer numerous resources for set-up and configuration. The software will be updated to accommodate customer interfacing, in addition to new edge detection software that will be written for the camera. A possible LCD may be incorporated to display the current electrical components that need to be loaded or placed. The pick and place will also undergo several manufacturing updates. The manufacturing updates on the pick and place includes a nozzle redesign to accommodate a camera to implement the edge detection software. The pick and place machine will also add more feeders and component trays to accommodate a 3Dot board with different type of components as well as an underneath compartment to store accessories for the machine. Accessories for the machine include: pump, paste, stencil, power cords, and electrical components. Other manufacturing additions include updating the specifications of the pick and place machine to accommodate the EE400D closet. After trade-off studies are conducted, the technical requirements for the pick and place 2nd generation will be more clea defined.

Source Material:

1.     https://www.arxterra.com/spring-2016-smd-pick-and-place-machine-preliminary-design-document/

2.     http://web.csulb.edu/~hill/ee400d/Documentation%20Lecture%20Series/04%20Preliminary%20Design%20Document.pdf

Electronic System Design

By Kevin Ruelas (Electronics and Control Engineer)

Camera

A Cameras should be installed on the machine to incorporate edge detection software. Edge detection will function when the component is picked up and measured and placed onto the board. More research will need to conducted in order to develop the edge detection software.

Another design option: An additional camera can be used to detect whether a component is present on the tray or not and display an “error” message if the tray is empty. Cameras should be chosen so that it is able to capture a high resolution image of the smallest component the machine can pick up. (0402 size). They may also require flash LEDs in order to achieve a bright and crisp image.

LCD

A small screen should be installed and display the current component being picked up and placed onto the board. This display should also display the current status of the machine. Depending on its current operation, a user input pad will be considered. User should be able to input component coordinates and name and press a “Place” button to place the part. Size of the display and place of installation is still pending. Software for the LCD display will need to be developed.

Wires

The wiring for the pick and place should remain unchanged from the first generation.

Button

A kill switch should be implemented to isolate the machine from power in case of emergency or for maintenance. Software for the kill switch will need to be developed.

 

System Block Diagram

By Amber Scardina (Mission, System, & Test) and Belinda Vivas (Project Manager)

 

The system block diagram above describes the how information is sent in the pick and place system. The information is sent from the user using EagleCad, converted into Gcode, then sent to the microprocessor (Arduino Uno). From the Arduino Uno, the data is sent to a Me Orion board to control the motors for each axis. With the addition of a camera and edge detection technology, the system will allow for calibration of coordinates if necessary. Once the nozzle is confirmed to be at the correct coordinates, the data is sent to

 

Interface Definitions

By Amber Scardina (Mission, System, & Test) and Belinda Vivas (Project Manager)

 

The diagram shown above describes how the user will interface with the pick and place. Note: this method has remained unchanged from the first generation.

The link below shows the pin mapping of the Arduino Uno, which will be the same implementation for the second generation of the Pick and Place:

https://www.arxterra.com/spring-2016-smd-pick-and-place-machine-preliminary-design-document/#Design_and_Unique_Tasks

Mechanical Design

By Tyler Jones – Manufacturing

The basic overview of the current design for the pick and place is fully functional and can place 0402 components, as well as larger size components such as integrated circuits and 0603 sized components. The pick and place machine operates on a belt system in the X and Y axes. The Z axis contains the nozzle which can be lower and lifted using a linear actuator. The machine is controlled from an Arduino Uno microcontroller and Me Orion shield. Currently the software is being retested and calibrated for use.

 The second generation requirements for the pick and place however will impact the current design. The second generation mechanical design will need to fulfill a size requirement of being able to fit in storage cabinets. Also a much more user friendly design must be incorporated so that the average user can easily manufacture boards without advanced technical knowledge. This will call for a smaller, more compact machine, and must be able to maintain the current precision and accuracy of the first generation. The Z- axis must be able to turn on a geared platform 90 degrees for setup and take down this eliminates the height problem.

 The requirements also specify a speedy setup process so that boards may be manufactured quickly. This will call for an all in one style machine without any lose parts. Also the current design implements an automated reel feeder system. This will have to be re -designed however because the second generation will be designed to populate a 3DoT board, using a variety of more components. This renders the reel feeders to be useless because they can only provide thousands of only six types of parts. Additionally the current IC tray must be re-designed because it should also offer a more versatile range of ICs to be used.

In order to fulfill user friendly requirements the pick and place should incorporate a small emergency stop button on the side this will shut off the power to the machine if there are any errors or malfunctions being used. Each of these design elements; the new feeder system, the new sizing, new Z axis that can rotate, and the push button will be discussed further on in this article.

Second Generation Feeder Trays

The feeder trays can be made so that the grooves fit a universal tape reel size. This will allow multiple types of tape sizes to be fit into the grooves.

The trays can be 3D printed using ABS plastic and color coded according to part sizes.

Multiple trays can populate the table so that all parts can be utilized by the machine.

The groove size for the tape reels to fit snugly without stalling the tape is 0.317 inches.

The length of the groove should be enough so that at least 30 of each part can fit. This will safely cover the maximum number 3DoT board’s parts that are identical for each individual board design.

A tape peeling and reel feeding mechanism may have to be employed after exploring the software capabilities.

Downsizing Second Generation Pick and Place

The 2nd Generation Pick and Place must be made smaller. This is so that the machine can be easily transported, and setup for ease of use. The image above represents a solid works draft of the machine. The legs can be lengthened by 4 inches providing a space below the pick and place so that the pump can be mounted.

 This also makes it so that the pick and place can be stored in a cabinet in the upright position. It provides a convenient area to have the used part tape land, as well as an area for putting the spare components or component strips. The under tray can be made from aluminum or sheet metal so that the pick and place is still lightweight. 

Getting rid of the reel feeder system provides more stability, because there is no longer an aluminum feeder and large reel hanging from the side of the machine. This also cuts down on height and width, as well as weight.

The absence of a reel feeder also creates more surface area to populate the picking surface with more IC trays and cameras.

Rotating the Z-Axis

The diagram above shows how the Z – Axis can be rotated by 90 degrees from vertical to horizontal.

Using a rack and pinion the whole Z – axis can be rotated and locked into position. This allows for more height clearance and ease of use. The Z axis stands 7.5 inches above the XY Axis. Allowing the Axis to be locked in 90 degrees from the Z axis eliminates all but about 1 inch to stand above the Axis. This creates enough room to store in a cabinet.

It is essential that the locking mechanism be very tight in order to prevent misalignment. It is also essential for the mechanism to be simplistic and small itself.

Emergency Button

The schematic above shows the sizing and dimensions for the emergency push button. This will be implemented as a way to stop the machine from processing any further components.  The position of the button needs to be within reach of the operator, and on the same axis as where the parts are placed into the grooves.

Depending on the software development the emergency button may be implemented in power circuit as an override switch.

 

Design and Unique Tasks

By Amber Scardina (Mission, System, & Test) and Belinda Vivas (Project Manager)

Trade – Off Studies

Several will be conducted in the following weeks to confirm our level 2 requirements. The tradeoff studies conducted:

·       Set Up time – The time to set-up and configure the machine by the user will be measured.

·       Production Time – The time to pick and place an entire 3Dot board by the user will be measured.

·       Material of Case –  Possible materials of the case will be tested in order to support the weight of the pick and place machine.

·       Material of Compartment – Possible materials for the compartment will be tested in order to set the weight specifications for the pick and place machine.

·       Size of Component Trays – The “free space” on the pick and place machine will be measured to set the size specifications for the additional component trays.

·       Size of the EE400D Cabinet – The EE 400D cabinet will be measured to set the size specifications of the pick and place machine.

 

Modeling

The modeling for the second generation pick and place should follow the software design of the first generation. Mechanical design will be upgraded for a more user friendlier generation and better calibration system.

https://www.arxterra.com/spring-2016-3d-smd-final-documentation/

Rapid Prototyping

The pick and place should be functioning as it is defined by the final documentation of first generation. The pick and place machine is currently in progress on setting up, running the software, and checking the wiring connectivity. Depending on how the tests run to implement the software we will decide on introducing a new software for the second generation (OpenPnP).

Spring 2017 SpiderBot: Preliminary Design Document

SpiderBot Team:

Project Manager – Nicholas Jacobs

Missions, Systems and Test Engieer – Jeff Funetes

Electronics and Control Engineer – Shaun Pasoz

Design and Manufacturing Engineer – Daniel Matias

Table of Contents

 

 

Program Objectives

By Nicholas Jacobs – Project Manager

The Spring 2017 SpiderBot is the 2nd generation SpiderBot. The customer has requested that SpiderBot utilize a 3DOT microcontroller board with a custom SMD I2C board. The customer also specified that SpiderBot be controlled from the Arxterra App via a Bluetooth communication link or by the Arxterra’s web interface.  Lastly, the customer expects iterations of the engineering method, a neat and orderly cable tree, and an aesthetically appealing design.

 

Mission Profile

By Nicholas Jacobs – Project Manager

The Spring 2017 SpiderBot will be an 8-legged that is built upon the Terra Spider design concept. The SpiderBot will be validated to the customer during an end of the semester Pac-Man style game. SpiderBot’s role in the game is to provide live aerial video footage to enable participants to navigate a maze and reach a target square of the maze. Moving from outside the maze to the grappling launch point, then raising from the floor to an elevated position, and then providing a live video feed will demonstrate all SpiderBot’s design specifications stated in the Project Objectives.

 

Requirements

Program Level 1 Objectives:

By Project Manager Nicholas Jacobs

  1.  The SpiderBot project shall be completed by 10 May 2017. One week before Finals week (10 May 2017) http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html
  1.  Total production cost must not exceed $250.00 US.
  2.  Spiderbot shall participate in the end of the semester Pac-Man style game. http://web.csulb.edu/~hill/ee400d/S’17%20Project%20Objectives%20and%20Mission%20Profile.pdf

Project Level 1 Requirements

By Project Manager Nicholas Jacobs

  1. SpiderBot will incorporate the 3Dot controller, SMD I2C boards.
  2. SpiderBot will be controlled by the Arxterra App using bluetooth.
  3. SpiderBot shall incorporate a smartphone or NTSC camera to provide real-time battlefield conditions to bi-ped and velociraptor remotely.
  4. SpiderBot should climb a wall by means of a rope/harness mechanism.
  5. SpiderBot shall be able to move forward, backwards and turn both left and right through use of DC motors.
  6. SpideBot shall compact size.
  7.  Will play in end of semester games
  8. Should provide video feed

Project Level 2 Requirements

By Mission, System, and Test Engineer Jeff Fuentes

  1. Spiderbot shall utilize the integrated 3.7v Li-ion battery to power the SpiderBot for 20 minutes.
    1. SpiderBor shall incorporate 2 seperate batteries to supply DC motors and servos and another 3DOT board, and motor driver.
  2. Spiderbot shall receive commands from the arxterra app via the HM-10 Bluetooth module on the the 3DoT board.
    1. SpiderBot shall establish a reliable comunication link up to 10 meters. 3DOT board will serve as the peripheal device and the smartphone will serve the central device. HM-10
  3. SpiderBot shall implement an Android smartphone or TTL Serial JPEG (capable of NTSC) camera to provide battlefield footage.
    1. NTSC camera will be an Adafruit NTSC Camera.
  4. Spiderbot shall utilize an Ultra-Micro Servo to drive the  rope/harness mechanism.
  5. Spiderbot shall utilize the TB6612FNG Dual DC Motor Driver to walk on 8 legs, through sets of 4, each driven by one motor.
  6. Spiderbot shall incorporate 3d printed parts that take no longer than two hours to print. 
    1. SpiderBot shall weight 3lbs or less. 

Design Innovation

Creative Solution

By Project Manager Nicholas Jacobs

From our Creative Design solutions, the SpiderBot team has decided to implement a unique idea into the Spring 2017 design. The end-user has specifed the need for a real-time video feed that will be provided to the control interface of two contending robots. SpiderBot will deliever an aerial view of the battle arena. The idea for an aerial view was the product of our Duncker Diagram which presented the issue of how our SpiderBot will climb a wall. Intially a suction cup system was proposed to adhere the SpiderBot to the wall. During the Attributes Listing design appraoch and after further consideration of the suction cup approach, the decision was made to scrap the suction cup idea. Our unique idea to provide the aerial video feed is to implement a grappling hook that would shoot and secure onto an anchor that will support the weight of SpiderBot allowing it to retract itself into an elevated position in order to provide aerial coverage.

 

Systems/Subsystem Design

 

Product Breakdown Structure

 

Electronic System Design

By Electronic and Control Engineer Shaun Pasoz

Last semester’s SpiderBot ran into several areas of difficulty; the worst of which was dynamic walking. They used servo motors to control the actions of the robot. While servos are excellent devices as they provide feedback from the motor, their pitfall is they cannot sustain a large amount of weight.  Therefore, this semester we have been tasked to implement a SpiderBot featuring DC motors.

Since the 3DoT board can only supply a current of 450mA, it is highly probably that we will need to implement an external power supply. In order to get the greatest motor efficiency, the first step is to decide on what configuration we would like to choose for our power supply. The following table shows a simple trade-off study between different batteries.

Battery: Weight: Rated Voltage: Capacity: Cost: Size: Discharge:
Ultrafire 18350 1200mAh 3.7V Unprotected Lithium Ion (Li-ion) Button Top Battery 20.9g 3.7V 1200mAh 4.95 35×18.5 mm N/A
6V Tenergy 1600mAh NiMH Side by Side Battery Pack with Hitec Connector 130g 6V 1600mAh 10.99 84x17x30.  mm 10C (10.6A Calculated)
Efest 18650 3000mAh Flat Top Battery – Purple Series 46g 3.7V 3000mAh 8 18.23×65.02mm 20A Continuous

System Block Diagram

By Mission, System, and Test Engineer Jeff Fuentes

The system block diagram displays how Spiderbot’s proposed inputs and outputs will function.  The 3DoT board can supply its own power, but it is not enough for all the peripherals we will be using.  Communication and telemetry will be handled by the 3DoT board consisting of the HM-10 Bluetooth LE module, an android phone, and the Arxterra app.  The motor outputs on the 3DOT board will drive two DC motors which will supply mechanical engery to a set of four legs each.  As dictated by the mission objective, Spiderbot will make use of a camera and harness/grappling mechanism via servo control. An external PCB will allow for further function if the 3DoT board cannot fully deliver.

3DoT Board Schematic

  1. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/3DoT%20Datasheets/Block%20Diagram.pdf
  2. https://www.arxterra.com/3dot/

Fritzing Diagram

Mechanical Design

By Maunfacturing Engineer Daniel Matias

Our spiderbot will be based off the terrabot model and be built using 3D printed ABS plastic parts for our first rapid prototype. I will design the parts myself using solid works to have them 3D printer ready.

The body of the spiderbot will be large enough to house the 3Dot Board and two motors with gears to run the Theo Jansen walking mechanism for the legs.

Design and Unique Task Description

By Mission, System, and Test Engineer Jeff Fuentes

 

Nicholas Jacobs

  1. Research prospective sources for material/services

 

Jefferson Fuentes (Missions, Systems, and Test Engineer)

  1. Design potential schematic to begin fritzing diagrams
  2. Work in conjunction with E&C (P, Shaun) to analyze power requirements needed for motors and peripherals
  3. Begin decoding and designing Arxterra app.
  4. Conduct trade off studies concerning DC Motors alongside E&C
  5. Conduct trade off studies concerning our harness/grappling mechanism

 

Shaun Pasoz (Electronics & Control Engineer)

  1. Consult fellow Electronics and Control engineers to discuss parameters to implement a game to demonstrate 3DoT Board capabilities.
  2. Examine trade-off studies for various batteries and motors.
  3. Work on simulations for motor control through the Arduino Uno board to help limit decisions between motor choices.
  4. After choosing motor, stress tests on motor gear systems need to be conducted to detail the max current draw based on the weight of the robot.
  5. After deciding on proper motors, batteries, and control systems, conduct tests to analyze how long the battery can run on a single charge.
  6. Create a Fritzing diagram using parts from interface matrix
  7. After finalizing electronic layout, create a PCB layout using CAD software.
  8. Consult Systems Engineer to develop software subroutines to make the SpiderBot perform its tasks.

Daniel Matias (Manufacturing Engineer)

  1. Conduct trade-off study to determine which material will best suit our needs
  2. Begin designing and implementing 3D models to be potentially built
  3. Begin preliminary EagleCAD files to gain an idea of layout

 

Resources:

http://arxterra.com/preliminary-design-document-4/#h.pit64qv19iz

http://web.csulb.edu/~hill/ee400d/Documentation%20Lecture%20Series/04%20Preliminary%20Design%20Document.pdf

http://web.csulb.edu/~hill/ee400d/Lectures/Week%2004%20Modeling/c_Design%20Process%20and%20Modeling.pptx

Spring 2017 BiPed Preliminary Design Document

The BiPed Team:

Alexander Clavel – Project Manager

Jacob Cheney – Missions, Systems, and Test

Abraham Falcon – Electronics and Control

Mikaela Hess – Manufacturing and Design

Phong Nguyen – Manufacturing and Design

Table of Contents

Program Objectives/Mission Profile:

By Alexander Clavel (Project Manager)

The customer has asked for a 7th generation robot that will be able to walk with the use of DC motors in replacement of servos. Based on the request of the customer, the bipedal robot will participate in the “end of semester” game. During the game, the robot will do battle with the velociraptor while using video support that is provided by the spider bot and pathfinder rover. With live video feed, the biped will be controlled with the Arxterra phone application to complete its mission.

Spring 2017 Requirements:

Project: Level 1 Requirements

By Alexander Clavel (Project Manager)

  1. The biped shall be able to achieve a static walk using dc motors.
  2. The Biped should be able to turn.
  3. The biped shall be able to participate in the “end of game” semester.

As stated by the customer

    4. The biped shall be controlled with the use of the Arxterra phone application.

As dictated by rules of the game

    5. The biped shall utilize a 3Dot board with custom SMD I2C shield.

As dictated by rules of the game

     6. The biped should be able to operate for an hour.

     7. The biped should be able to achieve dynamic walking.

     8. The biped shall fit within the classroom cabinets (size to be determined)

As instructed by the customer

     9. The biped shall be completed by the last day of class on Monday, May 15th, 2017.

As listed in the school schedule

MST: Level 2 System/Subsystem Requirements:

By Jacob Cheney (Mission, Systems, and Test)

  1. The BiPed shall have a Bluetooth v 4 .0 BLE Transceiver integrated circuit that will be able to communicate with an Android or iPhone.
  2. To maintain balance while static walking, the Biped shall use two servos as ankles to shift the center of gravity.
  3. The 3Dot Board shall receive commands from the Arxterra app via Bluetooth Transceiver. It will then decode and transmit data to the DC motors and servos.

E&C: Level 2 System/Subsystem Requirements:

By Abraham Falcon (Electronics and Control)

Abraham Falcon (Electronics and Control)

  1. The Biped will use two DC Motors for each hip for the walking movement.
  2. The Biped will use two Servo Motors for each ankle for a legs side movement.
  3. The Biped will use two Servo Motors for a turning movement.
  4. The Battery’s duration will last up to an hour.
  5. DC motor shall operate at 5 Volts for a static walk.
  6. Servo Motor shall operate at 5 Volts for a static walk.

Source Material:

https://www.arxterra.com/3dot/

M&D: Level 2 System/Subsystem Requirements:

By Mikaela Hess (Manufacturing and Design)

  1. The Biped will have a height restriction in order for it to fit in the closet with dimensions to be determined.
  2. The Biped will have legs designed to hold up the weight of a 3 dot board, Arduino, servos and the DC Motors.
  3. The Biped shall have an implemented design that makes the legs close together for better control of the center of gravity in order to achieve static walking.
  4. The Biped shall optimize the constant speed of the Biped for an hour by designing a leg that optimizes each length of each step in order to play the end of the semester game.
  5. The Biped should add an additional feature to the static design in order to achieve dynamic walking

Design Innovation:

Alexander Clavel ( Project Manager )

Through research of previous semesters requirements and final results, we developed our own areas of focus to create solutions for. Until now, most BiPed projects utilized servos to achieve walking, but ours will require the use of DC motors. As of yet, walking with DC motors has not been achieved so that has become our main area of focus. The Theo-Jansen approach gives us an initial approach to accomplish walking. Taking the “end of semester” game into consideration, the robot will also need to be balanced and be able to turn. Some ideas that were elicited from our creative exercises were to bring the legs closer in to allow for an easier shift in the center of gravity. Using the creative method, we devised different possible solutions for these problems.

Creativity Solution Slides

Systems/Subsystem Design:

By Jacob Cheney (Mission, Systems, and Test)

Product Breakdown Structure:

The product Breakdown Structure (PBS) is used to plan and display the outcomes of our project. The goal is to break down the product as much as possible to ensure nothing is overlooked. The hierarchical structure begins with the final product at the top followed by subcategorized elements below.

 

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

Good PBS Example (Velociraptor)

Electronic System Design:

System Block Diagram

The System Block Diagram shows the outputs for the ports of the DC motors, Servo motors, and the input for external power. The LDO 5V Regulator is used to increase the 3Dot board output voltage to the operating voltage for the Servo Motors. An Android or iPhone device with an Arxterra App will be used to control the Biped.

Source Material:

Fall 2016 Biped – Updated System/Software Block Diagrams  

 

Interface Definitions

 

Mechanical Design

By Mikaela Hess (Manufacturing and Design)

Pictured above is the initial idea that the Manufacturing engineers have designed. As can be seen above, we have the DC motors moving in the center of the body of the biped in order to have better control of the center of gravity. To make this happen, we must create a distance between the two DC motors large enough so that the two servos sized feet can be picked up and land onto the ground without disturbances. To go without the disturbances, we must create a distance of one servo between the DC motors, and an additional ⅕ of an inch of room to adjust for human error. Next, we placed the body on top of the DC motors, facing the other way in order to counteract the weight of the DC motors on either side, for better stability. This idea of having a long body was actually created from the Creative Project, where we forced a truck onto our biped design. The overall size of this Biped is to be under 10 inches. The body of the Biped is expected to be no more than 3 inches and the servo on the feet are expected to be no higher than 1 inch. With those calculations and the 1-inch radius in which the leg is designed to move around, the actual leg is to be designed in a total of 4-5 inches.

The actual walking of the biped is broken down into 5 steps here. In order to follow this design, the pictures are color coded according to the design’s components. In blue we have the representation of the circular path created by the DC motor and the pink segment. The pink segment is a sturdy piece of material that is directly linked to the DC motor and has a loose joint connection to the leg of the Biped, or the yellow piece in the picture above. Both legs start off in position one where the legs are bent and at rest at x and y equal zero on a radian circular graph. One leg then shifts its weight over by moving the leg over at an angle theta from resting position to the side by a servo. Once that is done, the DC motor then turns on and moves the pink segment to the negative pi over two positions on the same radial circular graph. This makes the body shift upward and lifts the other leg along with the body. After the segment goes to negative pi over two, it will move to pi on the radian graph, the ankle with resume its original position, causing the biped to take a step and then the legs will be programmed to reach equilibrium and resume its original position. Once that happens, the other leg repeats the same process and vice versa. Overall, the Biped should walk.

Once this design was created, I sent more photos and information to a Michael Oran Tobin, a Control Systems Engineer for California with PE Certification #CS7494. Once I had explained the servo use and parameters of the total design, it was made clear that my design would fail. What I failed to notice was the joint at the knee and the segment (yellow and pink where they connect), was that because there was no control onto that joint that the body could give out. As well, my design required precision that only DC motors with rotary encoding. A recommendation was made to use either a memory wire that straightens when current is given and loosens when there is none, or to use a servo at the knee for better control. The servo at the knee was decided to be a better option due to the memory wire being in early production and may not be able to handle the weight of the servo and leg. After going over the entire design, Michael Tobin strongly recommended doing more research on how humans walk and to consider how humans move their feet towards the center of gravity line to walk and then moves outward for better balance. As well, he suggested using a second wheel for better control of the joints. These pictures and ideas are pictured below and were made by Michael Tobin.

Overall, the design needs to reconfigured. More servos and research need to be done in order to create a working and walking Biped. The difficulty in this task is that most designs for biped are made using solely servos or stepper motors, which means this Biped leg design has to be made from scratch, but with help from other engineers and more research, it should be made possible. Also, a discussion with the project team and customer should be set up in the near future to discuss the use of more servos or motors.

Mechanical Design (Continued)

By Phong Nguyen (Manufacturing and Design)

This picture shows us a biped design based on human structure (hip, knees, and feet). As shown above, we decided to design the Biped with two DC motors for each hip, two servo motors for each ankle, and two Servo Motors for a turning movement. The DC motors are responsible for lifting up the whole leg while the servo motors will be used to shift the center of gravity. If we want to turn left or turn right, the servo motor at ankle will be able to accomplish that like last semesters biped. Under the foot, we will use high friction material such as sandpaper, rubber, or plastic. 

http://robogames.net/symposium/2007/07-108-Vaidyanathan-AnnaUniv-AnalysisofBipedalWalkingRobot.pdf

http://embeddedprogrammer.blogspot.com/2012/08/simulation-of-humanoid-robot.html

Design and Unique Task Descriptions:

Electronics and Control

By Abraham Falcon (Electronics and Control)

Biped Electronics and Control Design Process/Analysis

According to 3Dot Board specifications, it only supports 5V Turbo Boost for driving DC motors and for the Servo Motors to be operated at 5V. Using a rated 12V DC Motor to be power at 5V to measure the current draw at no load conditions and stall current to know the maximum current the motor will use to determine the Biped Battery total current it can supply. Also, for a Servo Motor to be power at 5V to measure no load current and stall current to determine the maximum current it will draw to know what battery is needed.

 

Biped Electronics and Control Tasks

  • Choose DC Motors to be compatible with the 3Dot Board’s TB6612FNG Dual Motor Driver.
  • Choose Servo Motors to be compatible with the 3Dot Board’s Two 3.7v Micro and Ultra-Micro Servo ports using a Voltage Regulator.
  • Perform Trade-Off Study on DC Motors to select for Biped for the 3Dot Board.
  • Perform Trade-Off Study on Servo Motors to select for Biped for the 3Dot Board.
  • Do Servo Motor Analysis to know what are the specs on a load condition on the Servo Motor and know how much mass it can handle at its maximum current.
  • DC Motor Analysis to determine the maximum current under a load condition and know what is the maximum mass it can handle.
  • Measure all currents of the motors to know the total current for the Biped Battery’s Specifications.
  • Select a Power supply that will handle all the current that the motors are consuming.
  • Create a Fritzing Diagram and test it on a breadboard to assure its properly working.
  • Use Eagle CAD to create an electrical schematic (PCB).
  • Using Arduino IDE to program the DC Motors and Servo Motors to work properly and to be successful.

Source Material:

Fall 2016 Biped – Updated Schematics  

http://arxterra.com/goliath-fall-2016-preliminary-design-documentation/

Manufacturing and Design

By Mikaela Hess (Manufacturing and Design)

Manufacturing Tasks

  • Measure the cabinet’s height and reduce it by one inch and make that the height requirement (so there is room for error).
  • Perform Trade-Off studies to see what implemented structures are used to make a robot walk using DC motors.
  • Weigh out the servos and DC motors, 3 Dot Board, and Arduino to know the total weight capacity.
  • Design a foot that has better grip and curvature for a smoother transition in steps.
  • Perform a Trade-Off study to see what materials are the lightest and sturdiest material to handle the weight.

 

Battery Blog Post

Conducted by:  Luis J. Martinez (Mission, Systems, and Test Engineer)

Battery (Duration, Powertrain)

As selected from our previous trade-off studies, the battery of choice for powering our Prosthetic Arm, in conjunction with the Prosthetic Hand, recognized as the Upper-Limb Prosthetic System was the 14.8V (4S), 1600–mAh Zippy Compact Lithium-Ion Polymer (LiPo) battery.

Incorporated into our system to fulfill the requirements for duration (L1-3) and powertrain (L2-7), associated tests were conducted in the verification and validation phase of the Prosthetic Arm system and are summarized as follow:

Duration (L1-3)

Following preliminary calculations calling for a 1500-mAh capacity, the battery was first charged to its full capacity through use of the Imax B6AC Professional Balance Charger/ Discharger in accordance with LiPo battery safety guidelines as referenced from a previous semester.  Setting the charger to top off the LiPo cells at a maximum of 4.2V each, the battery was charged to a maximum voltage  of 16.8V in 50:04 minutes.

Upon reaching its full charge, the battery was then set up in a configuration to discharge at a constant rate until the voltage dropped to 12V, a minimum voltage recommended by LiPo battery safety guidelines.

The duration test concluded in approximately 3 hours and 45 minutes, drawing an average of 0.317 Ah (amp-hours) during hour 1, 0.4 Ah during hours 2 and 3 each, and 0.3 Ah during the final 45 minutes, totaling to 1.417 Ah in capacity over the entire duration.  

Based on a 3.2A total draw on 12V for the Upper-Limb Prosthetic System, where the Prosthetic Arm and Prosthetic Hand systems are estimated to draw 2A and 0.7 A on 12V, and 1A and 0.1A on 5V respectively, the test yield of 1.41A is considered passing due to the fact the Upper-Limb Prosthetic System will not be drawing a constant 3.2A during the entire 20 minute duration time.

Factors such as a two-digit significant figure on the current draw for the battery discharger, and given the battery was programmed to stop discharging upon reaching an overall 12V per precautionary guidelines to avoid permanent damage to the cells, the 1.417 Ah yield is conservative and considered to have enough head room to permit a 20 minute meal duration.

Powertrain (L2-7)

For the powertrain test, calculations were made indicative of a 3.43 ohm, 42 W load to test a 3.5A draw on 12V, and a 5 ohm, 5W load to test for a 1A draw on 5V.  After powering our Printed Circuit Board (PCB) and connecting the 3.43 ohm load on 12V, with an in-series ammeter to measure current, a measured current draw of 3.056A were effectively verified drawn from the 12V source – this due only to the fact that a 42W resistor was not available, and our test was conducted with a 25W resistor instead.  Afterwards, the load was swapped out to the 5 ohm power resistor corresponding to the 1A test.  Respectively, this experiment yielded a measured current draw of 0.949A, effectively verifying the current draw from the 5V source.  In conclusion, the powertrain test proved the capacity of the Prosthetic Arm system to deliver 3.5A on 12V and 1A on 5V respectively, should the Upper-Limb Prosthetic System need it.

Final Blog Post – Prosthetic Arm (Fall 2016)

Table of Contents

Executive Summary

Program Objective

By Carolina Barrera

 

The objective of the Prosthetic Arm is to engineer and design an arm that will help position the hand in three-dimensional space. The arm should allow the hand to reach the mouth as well as the dinner table (tray) to allow the user to pick up food items from the table and back.

Mission Profile

By Carolina Barrera

 

The arm in conjunction with the Hand group should allow a veteran amputee to complete an independent task as eating a Quarter Pounder meal by himself. The arm should be able to fit a long-sleeve tank/sweater that helps the discretion of the device.

Level 1 Requirements

By Luis Martinez

Final system requirements updated for the last demonstration include the custom PCB requirement per the criteria of Professor Hill, aesthetics, and noise.  These specifications can be found at HERE in addition to the link ABOVE.

 

The Design

The system implements a MyoWare sensor that reads myoelectric signals from the bicep, and sends them to the MCU to control the up and down movement in the arm.

 

If you want to be directed to a specific topic in the system design documents use the links below. Click HERE to have access to the folder with all the 3D printed, and lasser-cut SolidWorks designs

 System Design

System Block Diagram

by Luis Martinez

The system block diagram, depicting high-level block interactions between the electronic and controls subsystem responsible for supplying power, and managing sensory inputs, and the manufacturing subsystem, responsible for physical layout of the overall system structure, inclusive of the printed circuit board (PCB) can be found HERE.

Experimental Results

Trade-off Studies

Motor (the newest one 100:1 gearbox over 27:1)

by Fabian Suske

The blog post shows specifications the Electronics and Control Engineer accounted for when selecting the right motor for our project. The trade-off studies were done comparing a $500 motor and the one that we initially selected. However, this motor (Bipolar stepper with a 27:1 gearbox) was later replaced for a motor with the same specifications but a bigger gear ratio (100:1).

Trade-off studies for the motor can be found (HERE)

 Battery

by Fabian Suske

The use of a battery was crucial for our design since portability and powertrain were two of our system requirements. The battery should supply enough power to both systems and meet a 20 minutes required duration.

Trade-off studies for the battery can be found (HERE)

 Subsystem Design

Interface Definitions

by Luis Martinez

The updated interface definitions detailing interactions between the Teensy 3.2 microcontroller for the Prosthetic Arm, respective Myoware and temperature sensors, in addition to motor control and voltage regulating components can be found HERE.

 Hardware Design

by Forrest Pino

The design of the arm implements a bicep and integrated forearm design. The two pieces are mainly 3D printed, but they have a couple of laser-cut acrylic pieces. The bicep structure is meant to be a strong and sturdy structure that holds and lifts the forearm, the hand and less than 1 pound of additional weight. The forearm design was meant to be a lighter and less compact structure, but yet strong so it doesn’t break with the weight of the hand, while held by the bicep.

Also, a vest was developed as a holding mechanism of the arm in case the weight of the arm gets on the way of the EMG sensor. However, this far we can test without the vest.

There is a blog post regarding the development and evolution of the hardware design of the bicep. For more information, click HERE

Advancement of the Design and Testing

Once the design was complete, a simulation was implemented in order to test the selected materials. The main pieces of the design were either printed with plastic filament or were cut from a sheet of acrylic that was purchased at a local hardware store. The printed pieces were made available by the division manager for manufacturing since he built and owned a 3D printer. The laser cut acrylic pieces were able to be accomplished because Professor Hill allowed access to a laser cutting machine. The designed pieces were constructed in a way that would allow them to fit together similar to puzzle pieces. These pieces would then be fastened together using nuts and bolts of various lengths and diameters depending on the available space surrounding the fastener holes. Since the utilized material is known, then a simulation can be constructed in order to simulate specific stresses and forces that a design may undergo. The simulation that was constructed for the bicep implemented stress under gravity and a 20 lb∙f at the axis where elbow rotation occurs. The 20 lb∙f was selected because the force exceeds what is required of our system and if capable, the design would be suitable for what is expected. In order to properly simulate the system, one must select various characteristics that would help mimic the system properly. Since fasteners were not constructed in the 3D modeling, bonded surfaces were implemented where the various parts touched each other. This allowed for the pieces to remain secured in position when undergoing external forces within the simulation. The top plate of the design was chosen to be the fixed surface in the simulation so that the simulation would more closely mimic the mounting of the arm in real life.

 

The image below highlights the areas in which the design experiences the most deformation due to the external forces that are applied. The blue areas experience the least change while the areas in red experience the most deformation. The image below seems to show that under the current forces, the design would not be able to sustain its structural integrity. Although, the deforming that occurs in the images are greatly exaggerated due to characteristics that were set for the test. In the images, one can see that the scale for the alterations is in microns. The actual deformations in the real life implementation would go unnoticed.

The image below illustrates the design from behind while highlighting the stress that is experienced inside. Internally, the area that experiences the most stress would be the bracket that supports the battery. Despite the fact that the battery support appears to be losing its shape, the changes that are experienced are less than a few microns.

Figure 5.2.1.1

The image below shows the design from the front.  The force that was applied to the axis of rotation for the elbow was implemented to occur in a fashion that was normal to the interior face of the bored holes for the gear shaft. The slight curvature inward is due to the bored section that surrounds the holes meant for the gear shaft. These recessed sections were implemented so that mounting brackets for the gear shaft could be affixed slightly below the surfaces of the walls of the bicep.

Figure 5.2.1.2

The image below illustrates the design from behind while highlighting the stress that is experienced inside. Internally, the area that experiences the most stress would be the bracket that supports the battery. Despite the fact that the battery support appears to be losing its shape, the changes that are experienced are less than a few microns.

Figure 5.2.1.3

The image below shows the design from the front.  The force that was applied to the axis of rotation for the elbow was implemented to occur in a fashion that was normal to the interior face of the bored holes for the gear shaft. The slight curvature inward is due to the bored section that surrounds the holes meant for the gear shaft. These recessed sections were implemented so that mounting brackets for the gear shaft could be affixed slightly below the surfaces of the walls of the bicep.

The Support System

Demoing the project became a challenge since the team was unable to come into contact with a volunteer that happened to have the amputation that would benefit the most from our design. Since an amputee would not be utilized, a plan was set so that the prosthetic arm could be displayed in a manner that would mimic its use by an amputee.

The image below illustrates the support system that would allow the prosthetic arm to be suspended in the air with minimal effort from the user. A camping/travel backpack was utilized for the support system and was modified to better fit the needs of the project. The actual pack of the backpack was removed since it did not serve any purpose to the project. The top bar of the backpack was removed and replaced with copper pipe. The copper pipe and couplers were donated by Chris Pino and the access to his tools allowed for the proper cuts and drills to be made. The side bars were shortened on the top and bottom so that the overall size could be reduced. Luckily, the copper pipe was about the same size as the pipe used in the pack which helped to make fitting easier. The soft metals that were utilized were easy for drills and allowed for set screws to be placed. The screws helped secure the modifications and kept the structural integrity intact.

Figure 5.2.2.1

The image below highlights the positioning of the prosthetic arm compared to the user. The backpack originally utilized a push-button mechanism that allowed the user to detach bar meant to help facilitate storage. The push-button mechanism was taken and implemented so that the pipes that facilitate position could be removed and vertical positioning could be selected based on the user. From the image below, one can see that drill holes were made and that a fastening pin from the backpack was used to aid in vertical positioning. An issue that was encountered was determining the lengths of the pipes that would hang over the shoulder. At this point, it was decided that further work would be done on the attachment of the arm before pipe lengths could be finalized.

Figure 5.2.2.2

The image below highlights the positioning of the prosthetic arm compared to the user. The backpack originally utilized a push-button mechanism that allowed the user to detach bar meant to help facilitate storage. The push-button mechanism was taken and implemented so that the pipes that facilitate position could be removed and vertical positioning could be selected based on the user. From the image below, one can see that drill holes were made and that a fastening pin from the backpack was used to aid in vertical positioning. An issue that was encountered was determining the lengths of the pipes that would hang over the shoulder. At this point, it was decided that further work would be done on the attachment of the arm before pipe lengths could be finalized.

Figure 5.2.2.3

Once the knee pad was in place, then proper pipe lengths could finalize. The image below shows the final outcome of the support system. The attachments that were used for securing the prosthetic arm to the support system were pneumatic tool couplings. The pneumatic tool pieces and their arrangement were beneficial to the design because their swivel actions helped to mimic the movements that occur in a shoulder and allowed for easy detachment.

Figure 5.2.2.4

The image below shows how a user would attach and demo the prosthetic arm. The pneumatic tool couplings would simulate shoulder movement while the kneepad attachment would help guide the prosthetic arm alongside the user’s arm.

Figure 5.2.2.5

Software Design

by Fabian Suske

Arduino Codding

A blog post regarding the Codding of the Prosthetic Arm is available in HERE

Verification and Validation

Updated Requirements: Program Requirements

by Luis Martinez

In consultation with the customer, various iterations of the program/ project (L1) and system/ subsystem (L2) requirements were enacted throughout the duration of the project in effort to avoid redundancies and reallocate resources towards specifications for mission success.

Program requirements addressing schedule, cost, and storage were satisfactorily met and can be found here.

System Requirements

by Luis Martinez

Final system requirements updated for the last demonstration include the custom PCB requirement per the criteria of Professor Hill, aesthetics, and noise.  These specifications can be found at HERE in addition to the link ABOVE.

Subsystem Requirements

by Luis Martinez

Final subsystem requirements updated for the last demonstration include the specification for a 55 degrees Celsius activation setpoint for a temperature sensor safety feature, and the size specification to be a focus on a 35 cm +/- 5 cm length allocation from the elbow to the tip of the middle finger on the Upper-Limb-Prosthetic System.  These specifications can be found HERE.

Project Update

Work Breakdown Structure

by Carolina Barrera

The WBS is found HERE

Resource Reports

Mass Report

by Luis Martinez

Overall, power requirements were significantly lower than the petitioned allocation for 3.5A on 12V and 1A on 5V as evidenced HERE.

Power Report

by Luis Martinez

 

In terms of mass, the Upper-Limb Prosthetic System measured in at 1.321 kg (2.912 lbs) from the elbow to the tip of the fingers in actuality, with theoretical summation of weights shown HERE . Overall, the system weighed in at 1.99 kg (4.39 lbs), with individual component weights referenced in the same link as above.  Both systems complied within their respective mass limits.

 

Cost Report

by Carolina Barrera

By the end of the semester we were 1.42% under budget. However, there are items that we just eat the cost for. Many of them because the person that purchase didn’t keep a hold of them or just forgot to keep them.

Click HERE to look at our finalized cost report

MyoWare muscle sensor is thee sensor we are utilizing to read the myoelectric signals from the upper arm of the amputee so we are able to flex and extend the arm (perform vertical motion).

Electrodes are implemented with the EMG sensor so the user is able to stick the sensor to the bicep and read the Myoelectric signals from it.

Bipolar Stepper is the motor located at the elbow joint that will allow a +60 and -90 degrees of motion in the vertical axis. This motor should have enough torque as lo lift the weight generated by thee forearm, the hand and the heaviest food item of a Quarter Pound with Cheese meal

For the project it is necessary to have a Vest to hold the arm. This vest will help with the simulation of the system since will be mounted to someone’s torso. It should hold the arm parallel to the torso and also leave some space for the ideal placement of the sensor in the bicep.

The Battery is a Zippy Compact 35C Series 1600 with a Voltage of 18.5 V. The battery is crucial for the operation of the Upper-Limb Prosthetic System since it will be powering the motor in the arm, the EMC sensor and the Hand ‘s MCU, and components.

We bought a 3D Printing Filament (PLA) reel before we knew filament was going to be provided by the class’ instructor. This was not included to the estimated price nor to the actual price (30 is multiplying 0). We just added to keep accountancy in our group. In other words, we are not expecting to be reimbursed for this item.

The PCB is our finalized circuit layout in a board. We are in our first iteration of the board, but we prepared in case we needed to order a modified (fixed) board.

The IC small electronics are all the small components (capacitor, resistors, inductors, ICs and kill-switch) implemented in the manufacturing of the PCB

Miscellaneous Mechanical includes all the structural aesthetic components for the arm or the vest. This amount is allocated to vacuum form components that benefited the aesthetics, and mount of the project

Project Schedule 

By Carolina Barrera

The last update reported in schedule was CDR. In this report, it was shown that the “actual” line was starting to deviate from the “ideal” line. Meaning that we were getting behind in schedule with activities we were supposed to be doing, and we didn’t. Getting the PCB components, redesigning the forearm for integration and integration itself brought a few setbacks in our original design.

The next section shows our burn down diagram, and a brief description of pinpoint deadlines.

 

The burn-down shows is a good way to see the progress of the project, and the overall tasks during the semester. Time – counted in weeks, is along the horizontal axis, and the tasks are numbered, and added to be counted as completed on the vertical axis. The grey line is the “ideal” graph, which shows a uniform and constant completion of tasks during the given time. The yellow line shows the “actual” graph; the rate and actual items completed by the team in the time reflected. The numbers along these two lines are milestones along the progress of the project. For example, (1) corresponds to week 2, and is the week that the groups were assign. Little progress was done, but the group as a team was consolidated. (2) represents the research presentation on week 3. Studies were made to evaluate the best approach to complete the project. This involved planning, and minor advances in design; rough ideas. (3) is the Preliminary Design Review (PDR). (4) is Critical Design Review (CDR). (5) is the date the Arm and the Hand group scheduled as physical integration. However, no physical integration was accomplished by then. This is why the yellow lines grows slightly further from the grey line in this point. It should be made clear that even though integration didn’t happen, the two groups had independent advancements. We had our vest built, and our first PCB was almost finished.

Among the items pending after the final demo, and verification and validation were testing the integrated system, and generation of intangibles. Also, because of reasons beyond us, our MCU burnt on the day of the last demo, which didn’t give us an opportunity to demo our part on the entire system on the date of our final.

Concluding Statement

By Carolina Barrera

At the last phase of the development cycle of our project, we came up with aspects that could be improved in further iterations of the project. Challenges that include: the successful implementation of a kill switch as a safety feature of the arm, or trying to obtain the collaboration of an actual amputee for the project, or even trying to make a socket for the arm so it actually fits an amputee.

 

Future generations could take upon these challenges, and come up with improvement where we left off. The idea of documenting all these is that the generations to come use them as a baseline for their design. We might be able to shorten the path just a little, so they have a head-start in all this process.

As a team, we are very proud of what we accomplished. We learnt multiple aspects of the engineering method, experience the operational schema when working in an organizational matrix, and finally, we truly developed a more sophisticated use of our soft-skills. We hope our work helps you or inspire you. It is a beautiful process to see your ideas become tangible, and even more when they have the potential to help or impact a community.

 Resources

Codding Prosthetic Arm

Written by: Fabian Suske

Approved by: Carolina Barrera

Table of Contents

 

Intro:

In order to fulfill mission success, the selected components need to brought to live. Therefore the MCU Teensy needed to be programmed.

 

Objective:

The objective of the Code is to read the EMG sensor, the temperature sensor, the kill switch as well as moving the motor. Due the components chosen a variety of challenges needed to be addressed. The main challenge arises due to using a stepper motor in combination with the Allegro A4988 stepper motor driver. This combination needs constant signals from the MCU to the driver while moving. Therefore pulling of items like the kill switch or the temperature sensor are not possible. As a result Interrupt Service Routines (ISR) were used for almost everything.

 

Main components:

EMG

The first ISR was used to read the EMG signals. Prototyping has shown that pulling this value, the way it is required, is not sufficient enough. The arm then reacts funny and junky. It also has a poor response time. Most of this results in the fact, that the user starts using the arm in the middle of the pulling process. As a result the long burst might be interpreted as short ones. Or short ones not at all.

 

This problems were solved once the ISR was implemented. If the user starts using the arm, the Teensy registers an interrupt at the assorted pin. Then the burst duration algorithm “kicks” in and delivers an accurate result.

The code to detect if the user operates the arm or if noise triggered the interrupt is as short as possible in order to not interrupt the movement of the arm.

 

Temperature Sensor

The temperature sensor was another challenge. The way the sensor is designed to work as followed: After a few byte were written into registers on the sensor the sensors starts the temperature reading. Then the user has to wait at least 750ms (a little more is better) before the measurement can be read. If the user tries to read the measurement faster the senor either return one of his “default” values 0 or 85 or it simply returns the last measured value. If the value continuously is read to fast, the value displayed might be obsolete and wrong.

Waiting for 750ms on the other hand is not acceptable while the motor is running. An ISR that performs the reading in a smart way has been implemented:

The ISR will be handled by a timer object. Every time the timer has an overflow the ISR is triggered. Once the ISR is called it checks a flag to see if the sensor is currently reading a measurement or not. If the measurement is not in progress a measurement is started. Once the ISR is triggered the second time 800ms later the values are ready to be read.

In this way no time is wasted with a delay function.

Kill switch

The kill switch is handled in a similar fashion as the EMG sensor. In case the kill switch is triggered due to an external interrupt, the ISR then sends a low signal to the enable pin of the LDO which then shuts down the entire system.

 

Motor control

The last part that’s needs to be coded is the motor control. The previously mentioned EMG-ISR has provided us with the direction of movement (Up, Down or Stop). The constantly called motor routine then moves the arm in the desired way.

In order to not violate our range of motion a few functions needed to be implemented additionally. The 150 degrees of freedom needed to be translated into degrees the motor actually travels. Once the position of the motor was found a routine checked if the desired motion is valid. If the motion is not valid, the arm travels the maximum possible distance.

 

Temperature Protection

In order to shut down the system once an unsafe operating temperature of 55°C is reached yet another ISR has been implemented. This ISR is also based on a timer. Once this ISR detects that the temperature is unsafe, the system is shut down in the same fashion as with the kill switch

Fall 2016 Velociraptor (W): Final Project Document

By Lam Nguyen (Project Manager)

Table of Contents



Executive Summary of Project



Project Objectives

For CSULB Fall 2016 semester, the Velociraptor biped robot project will branch off to a new species of dinosaurs and set up a new baseline with the Theo Jansen robot design. The Velociraptor is to be a toy robot resembling a Theropodous dinosuar suborder by it’s static walking movement. The objective of this project focuses on utilizing a Theo Jansen design to produce a walking robot that will be remotely controlled through Bluetooth communication by using the Arxterra Control Panel. The robot’s application will have a 3DoT MCU board and demonstrate it’s feasibility by participating in a game with other robots.

Mission Profile

The Mission Profile of the Fall 16 Velociraptor is to participate in the game arena called Save the Robot on the last day of school, December 14th 2016 at 9:00 am. The game will involve Velociraptor chasing other toy robots through various terrains tele-robotically from the Arxterra control panel. The robot’s application of the 3DoT board MCU will demonstrate it’s walking capabilities by navigating through terrains in a game.



Project Features



DC motors

Apart from previous semester the Velociraptor’s project design had problems with servos that actuates a walking motion. DC motors were introduced to have a continuous rotation for our walking motion.

3D Model – Theo Jansen Biped Robot Model

In order to design the robot with the Theo Jansen model as the project baseline. The project used Solidworks 3D modeling to validate and verify new designs within a short period of time. Using unique applications from Solidworks the mass properties helped save time and money on both printing the parts.

1

Picture 1. Theo Jansen BiPed Robot Model

Rotary Sensor and A/D Converter

With the new actuators for the walking motion. DC motors has less precision for every full rotation, therefore by using rotary sensors and A/D converter we will be able to track each leg’s position for a stepping motion.
6

Picture 2. Rotary Sensor

8

Picture 3. A/D Converter

Experiment List/CheckList

For the Final Verification and Validation Test Plan the project was given a checklist that stated the project’s requirements and experiments to figure out the results.

velociraptor-experiment-listchecklist



System Design



System Block Diagram

2

Figure 4: System block diagram Velociraptor (W)

The system block diagram for the velociraptor group was designed in order to use an external PCB that would be able to interact with the 3dot board embedded system. The system block diagram displays the overall connections that are needed to make the controls of the velociraptor possible. For the velociraptor PCB, it will have stepper motor drivers (A3901) which will have 2 stepper motors which control the linear actuators. With the help of the actuators we will be able to change the pattern of the step. For instance if the velociraptor needs to go up an incline, it would be able to step higher and not hit its foot against the bottom of the incline. In order to have the stepper motor driver be compatible with the I2C interface, we will utilize a GPIO expander that is I2C compatible. The driver will control the linear actuators. The linear actuators will change the radius of the rotational movement which will change the motion of the leg movement. For more information on each block of the diagram, readers are advised to visit the blog post link cited below.

 



Subsystem Design



Interface Definitions

3

Figure 5. Interface Definition

The above figure is for the interface definition which is linked  to the cabling tree diagram. Both of the above figures are linked in the sense that the interface definition is an outlined pin layout from the EagleCAD schematic while the cabling tree demonstrates what the layout will look like. The EagleCAD schematic was designed by the electronics engineer and through that the manufacturing engineer is able to know how to design the PCB and have the right connections.

4

Figure 6. Cable Tree

In the cable tree diagram, there is more details regarding the connection types; the wire lengths and also the gauge sizes. The cable tree diagram that has been provided below is based on the system block diagram and follows the same format and layout.



Mission Command and Control



The command and control of the velociraptor was to be designed in such a way that both the systems and electronics engineer have a good understanding of the 3DoT library provided by Professor Hill. The library needed to be modified in order to be able to include the custom command for each senior design group. For procedures on how to create custom commands and how to create a custom telemetry commands on the Arxtera control panel, readers should visit the systems blog post on how to create custom commands as well as telemetry commands. For the telemetry we will be displaying the roll, pitch and the left right rotary sensor values. A rotary encoder will be able to tell us how much in each direction the encoder has been turned. The custom command is when we have information that is being sent to the robot from the user. The custom command that we created for static walking for instance; it lets the velociraptor know when to start walking. However, telemetry would be the robot sending back information to the user what the leg placement is. There are two separate blog posts on custom commands and telemetry commands. Both of these blogs can be reviewed in order to gain a better understanding of the commands.



Electronic Design

Rotary Sensor

The rotary encoder is necessary to know the position of the dc motors. Without them, the walking motion would be a disaster. They are potentiometers. The signal is converted to a digital, and it is read via I2C.

Control Algorithm Code

The C++ code is a control algorithm for the velociraptor. It moves the servo which moves the head and tail to control the center of mass. It uses DC motors and rotary encoders to control the legs properly. Overall, it controls its walking motion and its turning.



Firmware

Software Block Diagram

The software block diagram shows a detailed description of what coding blocks information were needed to implement the move commands for the velociraptor. For instance, dynamic walking was a walking style in which the customer would have liked to accomplish but unfortunately wasn’t successful. For the static walking motor commands, the velociraptor was programmed to be able move forward, move backwards, turn right and turn left. The turn commands go into details about describing how a turn occurs after the foot has been planted in a stable position while the other foot is continuously being moved until the robot is able to turn in the specified direction. Identifying the necessary components and flow chart diagrams of what the velociraptor motor commands were supposed to do, made the coding a little bit easier when it was time to implement it in Arduino.

Sample of Code:

Link: telemetry-and-custom-command-sample-arduino-code-1



PCB Schematic

Fritzing Diagram/EagleCAD Schematic

The Fritzing diagram and Eagle schematic lays out how the components connect together on the PCB. Fritzing gives you a more visual representation while Eagle shows all the details of the connections. Once the Eagle schematic is complete, the manufacturing engineer fabricates the board so that it can be coded.



PCB Layout

The PCB layout was carried out through EagleCAD. The design utilized thru-hole components and L-shaped form to integrate with the 3DotBoard.  Majority of the IC components were placed on the top layer to utilize a SMT solder paste stencil for reflow soldering. Only one IC component was placed on the bottom layer, which will be soldered through hand soldering. The picture below shows the PCB layout for the custom PCB of the Velociraptor. Decoupling capacitors were placed close to the IC components and wire sizes were adjusted to prevent problems with the power and signal lines. For PCB fabrication, OSH Park was chosen.
For more information, the blog post below will give detailed information regarding the PCB layout.



Hardware Design

To fulfill requirements, a modified version of the Theo Jansen linkage was integrated with the leg design. The continuous rotation of the linkage corresponded with the continuous motion of a DC motor. The design was created in SolidWorks to observe features such as center of mass. The center of mass was accurately calculated from a custom library of densities in SolidWorks. Subsystem components, such as the toe joint and see-saw body, were to fulfill requirements and improve the design from previous generations of the Velociraptor.

 

For more information, the blogpost below will give thorough information regarding the hardware design.


 

 


Verification and Validation Test

The verification and validation matrix is a complied version of the requirements that the velociraptor group was required meet. In this matrix below, we notice that the requirements have been labeled as either a shall, should or will. For this Wednesday velociraptor group, we were able to accomplish about half of the will requirements that were expected from us. In the figure below, readers can find a copy of the verification and validation report. Matrix has been provided below in order to give viewers a better understanding of project requirements.



Project Status



Power Allocation

For the power allocation report, the velociraptor robot consumes a total of 375mA when in complete motion. Based on a torque test performed by the electronics engineer in our group, we were able to determine that the DC motors can move a mass that is at a 1000g maximum. Due to robot size being 348g, we know that the motors will be able to successfully control the robot without stalling.

Mass Allocation

The overall weight of the velociraptor is 348g which is only using 34.8% of our maximum requirement of having it not weigh more than 350g. This therefore fulfills our requirement of the total mass and also makes it possible to have the GM9 motors supply enough torque to move the velociraptor. The final mass report which is provided in the figure will be able to provide more information about the overall weight distribution of other components.

Cost Report

The cost budget was finalized by the customer to allocate the cost to each project. In the end the customer was the deciding factor for the Velociraptor (W)  budget. In the cost report the items were provided by the customer were $0.00 and this help the project lower the budget to $46.55.



Product Breakdown Structurea

Figure 7. Product Breakdown Structure

The product breakdown structure above was categorized into 5 sections:

  1. Movement System
  2. Control
  3. Software Control
  4. Power
  5. 3DoTBoard/PCB Board

The PBS was worked with Paul Auhmada from the Velociraptor (Th) class. The movement system pointed to the mechanical design, servos, and dc motors. The Controls had attributes for sensors. The Software Control had communication and control algorithm code applications. The 3DoTBoard/PCB board was for the external PCB board unique to each projects design.



Work BreakDown Structure

aa

Figure 8. Work Breakdown Structure

The Work Breakdown Structure allocated the task to different divisions of the team. This semester this project the system engineer and the electronics and controls engineer had a huge learning curve therefore there were difficulties to push the project forward in a short period of time. Therefore the system engineer role were covered by both PM’s of each Velociraptor. The electrical and controls engineer role was assisted by their division manager.



Project Schedule

The project schedule indicates the number of tasks needed to follow in order to complete the project. Unfortunately the project reached some obstacles in the electronics and mechanical design.aaaa

Figure 9: Project Schedule

The burndown structure shows two different graphs where the orange line indicates the tasks remaining to complete the project and the blue line indicates the expected tasks completed. As you can see the path diverged early in the semester, where our systems engineer had reached some obstacles in the task. This problem ended up affecting the rest of the divisions due to time.

The project is marked as 80% complete and needed to implement the feet design of our robot and the control algorithm with the rotary sensor.

aaa

Figure 10: Burndown Structure



Conclusion

The Velociraptor this semester had face many problems to move the project foward. The Theo Jansen Linkages designs was set but when the group assembled our first prototype we noticed that the feet design was one of the issues in having the robot balanced when stationary. There was problems with every division and the delays caused other work to be pushed back. The control algorithm used to move the robot forward and turn was not completed by the final project demonstration. The foot design was one of the biggest problem that needed to be implemented to have the robot balanced when the robot walks.

Future Projects:

  1. The manufacturing engineering should start on the mechanical design as soon as possible if not then the manufacturer will face bigger problems towards the end.
  2. The electronics and controls engineer should learn C++ from the start to be prepared for coding tasks.
  3. The system engineer should not only focus on the requirements but also be ready to think about all factors. Know that the system design is the baseline of the project, therefore if something is changed from the system’s side then there is a possibility this could affect other divisions.



Project Resources

[1] Project Video: https://www.youtube.com/watch?v=1fSIvmpCkRk

[2] Critical Design Review: critical-design-review

[3] Preliminary Design Review: preliminary-design-review and preliminary-design-review PowerPoint

[4] Microsoft Project : projecct-schedule-1

[5] Verification and Validation document: verification-and-validation-test-plan-results

[6] Solidworks File: https://www.dropbox.com/s/9mycah24zwdqag8/Velociraptor.zip?dl=0

[7] Fritzing Files: fritzing-diagram

[8] EagleCAD Files: eaglecad

[9] Control Algorithm Code: control-algorithm

[10] MatLab Code for Torque studies: matlab-code

[11] Complete Bill of Materials (BOM): bill-of-material

 

Pathfinder Fall 2016 Final Summary

Table of Contents

Project Overview

By Sabina Subedi, Project Manager

Project Objective

The Pathfinder is an autonomous rover that is self-sufficient using solar panels. The design of the Pathfinder is inspired by the twin Mars rovers “Spirit and Opportunity.” The Pathfinder will utilize navigation waypoints on Arxterra control panel to traverse through the defined course, articulating ultrasonic range finders and LiDar sensor for obstacle avoidance. Digital slip differential will be implemented for unmanned turning of the rover during it’s course. In order to save battery, the Pathfinder will integrate sensors that will send signals to the motors to stop the wheels from spinning under no load conditions.

Mission Profile

The Pathfinder must successfully navigate a 0.18 mile (roundtrip) course to and from the solar panel charging station defined by the solar panel subproject group. The mapped out course contains 2 staircases with 3 steps each, then concrete path leading to solar panels charging station. The Pathfinder shall travel up and down the steps. The Pathfinder shall avoid any obstacles along the way, using ultrasonic and LiDAR sensors. Pathfinder shall complete its mission in one evening.  The pathfinder shall conduct its mission at night for better operation of the LiDar sensor.

The Design

one

Project Features:

  • Rocker Bogie suspension system
    • High clearance chassis
    • Superior stability on uneven surfaces
    • Obstacle climbing capability
  • Pan and tilt system
    • 2 servos for the rotation of the system, one for pan & one for tilt
    • Provides live video feed utilizing a cellular phone camera
    • Enclosed to protect the phone from external environment
  • GPS Navigation Mode with obstacle avoidance

System Design: 

By Jose Alcantar, Electronics and Controls Engineer

uno

The system block diagram above generalizes how the sensors and actuators will interface through the Arduino Leonardo. First, the Bluetooth receives and transmits any data and the Arduino decodes the data and takes action. The Arduino will either receive sensor data or drive the motors, depending on the commands sent. The diagram also shows the I/O expander is used to control the motor drivers and servos.

Experimental Results:

By Jose Alcantar, Electronics and Controls Engineer

No load conditions threshold:

picture3

The plot above shows the current draw data from one motor driven by the VNH5019. The purpose of this experiment was to find a threshold for finding the current drawn at no load conditions. From the graph, the no load current draw is about 500 mA and when a load is applied the motor draws about 1.3A. The threshold is necessary to set the threshold and shut off the motors when the current draw falls below this threshold.  

Field of View test for Ultrasonic Sensor:

picture1

Purpose:

Testing the field of view on the HC-SR04 to find a suitable mounting position for the two ultrasonic sensors along the front of the rover.

Procedure:

An object was placed in front of the ultrasonic sensor about 25 inches away; the position of the object was marked and moved in increments of 5 inches until the object was out of view. When the object was no longer detected the position was marked. The angle of the field of view was then calculated.

Results:

Based on the experiment, the angle of the field of view was found to be 18 degrees when measuring an object 25 inches away. The position of the sensors was determined by considering the clearance needed on each side of the rover. When considering the solar panels, the two ultrasonic sensors need to detect obstacles at least 5 inches to each side of the chassis. This will allow the pathfinder to avoid obstacles that may bump into the solar panels.

Subsystem Design:

By Jose Alcantar, Electronics and Controls Engineer

Interface Definition:

quatro

The above table shows the main pinout from the Arduino Leonardo. The main interfacing boards are the three VNH5019 motor drivers the PCA9685 I/O expander, the Bluetooth module, the LEDS, Ultrasonic sensors and the LIDAR.

cinco

The above table shows the interconnections of the PCA96805 I/O expander. The majority of the pins control the direction pins of the 6 H-Bridges and the pan and tilt servos.

Software Design:

By Jose Alcantar, Electronics and Controls Engineer

seis

The above flowchart demonstrates how the Arduino receives the incoming data from the Arxterra App and acts based on the commands sent. When a command is sent the command, decoder determines which function to begin. Depending on the mode the Pathfinder will go into either Manual mode, GPS navigation mode or charging state. The called function will drive the motors and read sensor values to complete the requested action.

siete

The flow chart demonstrates how the pathfinder will act when avoiding obstacles. The pathfinder will read sensor values and go into either state 1, 2 or 3 depending on the reading of the sensor values. The rover will then either avoid left, avoid right or move forward.

Waypoint Navigation Mode:

ocho

For waypoint navigation mode, the Arduino reads the waypoint coordinates and current coordinates of the pathfinder. Then the distance and heading to the next waypoint is calculated the rover then begins moving to its destination while actively avoiding obstacles and continously updating coordinate data. Once the waypoint is reached the waypoint data is deleted and manual mode is activated.

For more detail on the Waypoint navigatioin algotithm see:

http://arxterra.com/waypoint-navigation/

Manual Mode Flowchart:

nueve

The flowchart shows the basic algorithm to drive the motors when the direction pad is used to control the pathfinder and pan and tilt servos.

For a more detailed explanation of the MOVE functions see:

http://arxterra.com/implementing-move-command-firmware/

Cable Tree

By Nick Lukin, Design and Manufacturing

The cable tree shows approximately where the wires outside of the main PCB will be laid out on the Pathfinder. It includes connectors for items that can be taken on and off the chassis.

cabletree2cabletree3 cabletree

Hardware Design

By Nicholas Lukin, Design and Manufacturing Engineer

Introduction

The overall mechanical design consisted of various key features that ensured the customers design requirements were met. The first feature is the pan and tilt phone system. The customer required that the Pathfinder come equipped with an electronically controlled pan and tilt phone holding mechanism. The next feature is the rocker bogie suspension system. This suspension system helped fulfill the requirement of going over rough desert terrain and makes it possible to climb up and down obstacles such as stairs and rocks. The next feature is that the Pathfinder is made out of material that can withstand desert conditions as per the requirement stated by the customer. The final feature is the seamless interfacing areas on the chassis that makes it possible to properly interface with the solar panels that will be attached to the top of the chassis.

one

Form Factor

 

Rocker Bogie Suspension System

 two

Figure 1: Exploded View

 Figure 1 shows the exploded view of the entire chassis including the rocker bogie suspension system. The system itself allows the pathfinder to go over uneven surfaces while maintaining stability and traction. There are two pivot points located in the suspension system. The middle pivot point is attached directly to the top plate of the chassis and allows the plate to stay level while traversing up and down obstacles such as stairs. The back pivot point allows for a further range of motion when going over various obstacles. Having two independent suspension sides allows the Pathfinder to go over a variety of terrain. Each side reacts independently to obstacles which allows the center of mass to stay relativity stable and low.

 

Tube Leg Design and Material

  three

Figure 2: Tube Leg Design

In order to make the Pathfinder look as close as possible to the Spirit/Opportunity rovers it was decided to make the legs of the rocker bogie suspension system out of tubing instead of plate like the previous Pathfinder designs. Not only did this make the Pathfinder look more realistic but it also added more strength to the overall design. It was decided that the material used for the design would be 6061-T6 aluminum because of its high corrosion resistance and overall strength. Figure 2 shows the overall mass properties of the Pathfinder.

four

Figure 3: Mass Properties

The overall weight of the Pathfinder is about 25 pounds as shown in figure 2. This weight it light enough to ensure that the motors do not get overworked. If non aerospace grade aluminum was used such as plain 6061 the weight would be around 32 pounds which is a 20% increase.

Fabrication of Overall Chassis

 five

Figure 3: 2-D Drawing for Fabrication

 

The first step in the fabrication process was to obtain the proper 2-D drawing in order to figure out what material needed to be machined and what needed to be welded. It was decided that the back legs, the top plate and the top side plate would all need to be cut and machined. Figure 4 below shows the machining process.

six seven

Figure 4: Machining Legs and Top Plate

 

eight

Figure 5: Fabricating Legs

 

Proper measuring tools had to be used in order to make sure the legs were the correct size and that the overall chassis would be straight when it was planted on all six wheels. Tubing needed to be cut at the proper angles (135 degrees) and welded. Special attention needed to be given while welding to ensure the metal did not warp and create an unwanted dimension.

nine

Figure 6: Final Leg Fabrication

Figure 6 shows the final leg fabrication. Each leg was nearly identical to one another. This helped achieve the goal of keeping symmetry throughout the entire design and made sure the Pathfinder would achieve the proper form factor as required by the customer.

ten

Figure 7: Light/Sensor Bar

 It was a requirement that the Pathfinder was equipped with some type of lighting and ultrasonic sensors. In order to properly attach the lights and sensors to the chassis it was necessary to custom fabricate some type of holding mechanism. A light/sensor bar was machined in order to properly attach the critical lights and sensors. Figure 7 shows the final product.

eleven

Figure 8: Final Chassis Design

 Figure 8 shows the final chassis completed with the pan and tilt phone system, wheels and electrical all attached. The final design looks nearly identical to the solid works model. Careful preparation and precise fabrication achieved a design that is accurate and that meets the customers’ expectations. 

Pan and Tilt Phone System

 

twelve 

Figure 9: Pan and Tilt Phone Holder

 

In order for the Pathfinder to see where it is going and to properly connect to the Arxterra control panel the customer required that a Pan and Tilt phone system be built. The system would need to house a Samsung Galaxy S7 edge and be able to withstand a desert environment. The design of the system can be seen in figure 9. The system is controlled through the Arxterra control panel via two servos. We decided to make the phone holder out of 6061-T6 material just like the chassis. This would ensure that the phone would be properly protected and that it was light enough so the servos could move it.

thirteen

Figure 10: Pan and Tilt Exploded

It was also necessary to attach a lidar sensor to the front of the phone case. Lidar was needed in order to properly implement an autonomous driving mode system. The front plate of the phone holder was designed to leave room for the cameras of the phone, to house the lidar sensor and to properly expose the communication antennas of the phone. All these features can be seen in figure 10.

 

fourteen

Figure 11: Fabricating Phone Holder

Figure 11 shows the fabrication of the camera view holes of the front case of the phone holder. It was necessary to properly measure the distance between the top of the phone to the end of the camera to make sure that there was no interference between the metal and the camera.

 

fifteen

Figure 12: Final Product

Figure 12 shows the final build of the pan and tilt phone holder mechanism. It was necessary to utilize an off the shelf gimbal system to mechanically drive the pan motion of the holder. This part was connected to the pan servo and ensured smooth lateral operation of the entire system.

Interfacing the Solar Panels

 sixteen

Figure 13: Solar Panels Interfacing

It was necessary that the chassis and solar panels seamlessly interface as per the requirement of the customer. Proper interfacing was achieved by creating mounting stand offs on the top plate of the chassis of the Pathfinder. The solar panels would then have holes that would properly align with the mounting pads and a small thumb screw would be used in order to properly secure the connection. These stand offs can be seen on the top plate of the chassis in Figure 13. The pan and tilt phone holder would also need to come off by hand in order to properly interface. This was achieved by machining a threaded stud to the top of the phone holder stand. The customer could then easily screw the phone holder on and off by hand.

 

Figure 14: Actual Interfacing

Figure 14 shows the actual interfacing of the solar panels and the chassis assembly. The 4 thumb screws that were utilized can be seen in figure 14. It was also noticeable that the proper form factor was achieved between the solar panels and the chassis.

 

PCB Layout

eighteen

Figure 15: Final PCB Design

A custom PCB design was required in order to interface all of the boards that were utilized to control the Pathfinder. The overall function of the board was to take various pins from the Arduino and rout those pins to other boards that could directly connect to the custom PCB. Two ultrasonic sensors, a Bluetooth module, a servo driver board, a LED interface, a LIDAR connection and 3 motor driver boards would all be able to directly connect to the board. The board would also implement a buck converter in order to step down the main battery supply voltage from 12V down to 6V to properly charge the phone in the phone holder system.

Interface Design

In order to properly route all the wires from the Arduino pins to the proper locations it was necessary to lay the board out in an efficient manner. All the pins that required headers were laid out as close to the edge of the board as possible. They were also spaced apart so that room was left for whatever connectors would be used. 45 degree bends were utilized on all traces in order to maintain a clean and professional looking PCB. A ground plane was utilized for all ground connections and a power bus was used in order to properly connect VCC across all pin connections. A power plane could not be used since the buck converter would also be on the same board and would be utilizing a different voltage level at its input.

Buck Converter

 nineteen

Figure 16: Typical Buck Design

 The LM2596 chip was selected for the buck converter. This chip allows a maximum of 3 amps to be passed through it and has an input voltage range of up to 40 volts and can step down voltages as low as 3.3 volts. For the phone charger we designed the buck converter to output 6 volts to properly charge the Samsung Galaxy S7 edge. All surface mount components were utilized for the design and attention to detail was key during the lay out process. Per the data sheet it was necessary to place the inductor and capacitors as close to the chip as possible. It was also necessary to use the correct size power traces to prevent overheating and possible damage to the board. The buck converter was designed to output a max of 1 amps and therefore a maximum power trace of .032 inches was used. This thick trace can be seen on figure 15 at the input of the buck converter. A micro usb was used on the output of the buck so the phone could easily plug into the charger.

 

Soldering Process

 

Figure 17: Soldering the Board 

The custom PCB was soldered by hand and then was tested for proper functionality. It was noticed that there was a direct short between ground and Vcc. Initially it was thought that the soldering process caused the short but upon further inspection it was determined that the board came shorted from the factory. Two other boards that were not yet soldered were tested and they both had direct shorts between Vcc and ground.

Verification and Validation Test

https://drive.google.com/open?id=0Bzq09K9mZabrd0E4a01mUElLdlE

Work Breakdown Structure (WBS)

wbs

Resource Reports

Please refer to the Project Resources section to find the resource reports, including Mass, Cost and Power Report.

Top Level Schedule

schedule

The general top level schedule was created using the generic rubric provided on the class website. The top level schedule specific to the Pathfinder (Chassis subproject) was created using the Work Breakdown Structure above and the general top level schedule. This schedule consists of all tasks that are to be completed before the end of the semester, December 15th, 2016. The project milestones are broken down into four phases: Planning, Design, Assembly and Project Launch. The tasks within the different phases are then divided up by the divisions. All division members are assigned specific tasks that they are responsible for, per “Job Descriptions” document available on the class website. Main tasks then were broken down into sub-tasks, if applicable. All tasks include start and finish dates, as well as percent complete. 

Conclusion and Future Plans

Overall the project was a success as we were able to build a functioning rover that achieved the majority of the requirements that were established by the customer. The mechanical design worked as expected with only some small issues. One improvement that is necessary is adding stops to the back pivot point of the rocker bogie suspension system. The range of motion needs to be limited at some point in order to properly go up obstacles such as stairs. Another improvement would be to possibly get bigger wheels. The larger the wheels the better it can go up and over obstacles. I believe that the current design is sufficient for future students to build off of and improve upon.

Project Resources

 

Fall 2016 Velociraptor (W): Analog to Digital Converter

By: Taylor Farr (Electronics and Control)

Approved by Lam Nguyen (Project Manager)

Table of Contents

Introduction

I chose to use the Adafruit ADS 1015 analog to digital converter. This will be used to convert the analog signals from the rotary converter to digital ones. This ADC communicates via I2C, so this satisfies our level 2 requirement.

Materials

  • 3382 Series 12mm Rotary Position Sensor
  • Adafruit ADS1015
  • Screwdriver
  • Breadboard
  • Wires
  • USB Cable
  • Laptop
  • Test Code
  • Arduino
  • protractor

Procedures

  1. Connect the ADC to the breadboard.
  2. Connect Vcc to the 3.3 volt pin on the Arduino and breadboard.
  3. Connect ground to one of the ground pins on the Arduino.
  4. Connect SCL and SDA to the SCL and SDA pins on the Arduino.
  5. Connect the Vcc of the rotary encoder to the Vcc on the breadboard.
  6. Connect ground of the rotary encoder to ground on the breadboard.
  7. Connect the signal output of the rotary encoder to the A0 pin on the ADC.
  8. Upload test code to Arduino and open the serial monitor.
  9. Using the screwdriver and protractor, move the position of the ADC to different angles and observe the digital readings on the screen.

Results

Angle (degrees) Bit reading
0 1
45 115
90 222
180 550
225 667
270 827
350 1101

Conclusion

From The table of results, we can see the digitized results of the rotary encoder. The ADC is a 12 bit analog to digital converter. The voltage on our PCB is about 3.3 volts. This is why we do not read the full span of the 11 bits (211 = 2048). Now that we know the range as well as the specific values of the encoder at specific angles, we can use this to update the control algorithm for the velociraptor.