Spring 2016 A-TeChToP Preliminary Design Documentation

/in , /by

By: Cody Dunn (Project Manager)

Central Sensor Suite:

Omar Rojas (Systems Engineer)

Stephen Cortez (Electronics Engineer) Read more

SPARCCS Spring 2016: Preliminary Design Document

/in , , /by

By Mikhael Semaan (Project Manager), with contribution from

Jeremy Seiden (Systems and Subsystems),

Chelsea Mediavilla (Electronics and Control), and

Eric Hanna (Design and Manufacturing).

We review the preliminary design, including program and project objectives, requirements, system and subsystem design, work breakdown, and preliminary project schedule and plan.

Read more

Spring 2016 Velociraptor: Preliminary Design Document

/in , /by

Velociraptor Team:

Khoi Vu (Project Manager)

Camilla Jensen (Systems Engineer)

Ashlee Chang(Electronics & Control Engineer)

Mingyu Seo (Design & Manufacturing Engineer)

 

Table of Contents

 

Program Objectives/Mission Profile

By: PM Khoi Vu

The Spring 2015 Velociraptor biped was inspired by the robot Titrus-III; it was designed and created by Tokyo Institute of Technology. The purpose of this project is to design a Tyrannosaurus class biped robot to be used as a toy. The mission profile is to demonstrate the feasibility of the dinosaur biped as toy product. The objective of this project focuses on a toy with the ability to detect and avoid obstacles. The Velociraptor will be controlled by establishing a communication with the Arxterra Android application.

 

Requirements

Program/Project:

The requirements are divided into two categories, program and project. The program requirements are general requirements that the robot must fulfill, whereas project requirements are more specific to the appearance and ability of the robot. To ensure the success of this project, these requirements were set based on the customer’s objectives and mission profile.

 

Program Level 1 Requirement:

  1. According to the CSULB 2015-16 Academic Calendar, the Velociraptor biped shall demonstrate its feasibility as a toy by Monday, May 9, 2015 (Last Day of EE400D).
  2. The Velociraptor’s biped shall cost no more than $400.00. This limit was determined by analysis of the previous project estimated and the final cost of Fall 2015 MicroBiped, and Spring 2015 MicroBiped.
  3. The project shall follow the CSULB College of Engineering Health and Safety Policy before the Velociraptor can be demonstrated at CSULB.

 

Project Level 1 Requirements:

  1. The Velociraptor shall resemble a Tyrannosaurus class of dinosaurs as given in the objective.
  2. The word “biped” is defined as having two feet; therefore, the Velociraptor shall use two legs to move.
  3. According to the given course that the robot is to complete, the Velociraptor shall travel on multiple surfaces. Refer to course analysis for more detail.
  4. The Velociraptor shall be able to statically walk on all surfaces of the course
  5. The Velociraptor shall be able to dynamically walk on flat surfaces of the course.
  6. The Robot shall statically travel up a 6.5-degree incline according to the course analysis.
  7. The Robot shall have the ability to detect obstacles in its path.
  8. The robot shall make turns when an obstacle is detected and shall maneuver around the detected obstacles.
  9. The robot shall be controlled via Bluetooth communication with the Arxterra Android application.
  10. The Velociraptor shall be power using a portable power source.

 

System/Subsystem Requirements

Project Level 2 Requirements – Systems requirements

By: S&T Camilla Jensen

  1. According to the CSULB 2015-16 Academic Calendar, all the subsystems of the Velociraptor biped shall stay within the time phasing to complete project Velociraptor by due date Monday, May 9, 2015 (Last Day of EE400D) and thus meeting the Level 1, requirement 1.
  1. To have a realizable budget, the chassis shall be manufactured directly at CSULB and thus meeting the Level 1, requirement 
  1. In order for the project to meet the CSULB College of Engineering Health and Safety Policy, all project members shall read through and become thoroughly familiar with the policy and accordingly comply with the policy and working in a lab, and thus meeting the Level 1, requirement 3.
  1. To resemble a Tyrannosaurus class of dinosaurs, the chassis of the Velociraptor shall be cut out in hollow body parts to assemble a frame-like body structure in a material that is cost effective i.e. Stays within budget (Cost report) and sturdy enough to carry weight of Velociraptor (mass report) and thus meeting the Project Level 1, requirement 1.
  1. To facilitate the algorithmic functions of a Velociraptor Biped, an Arduino Microcontroller shall be implemented as the brain of the Velociraptor and thus meeting the Level 1, requirement 5.
  1. To maintain balance while performing static walking, a head and tail shall be implemented to the chassis of the Velociraptor to even out the shifted weight when standing on one leg and thus meet the Project Level 1, requirement 4. [6]
  1. For the Velociraptor to perform dynamic walking servos moving at a speed of 0.101 sec/12.5° shall be implemented to the chassis and thus meet the Project Level 1, requirement 5. [7]
  1. In order for the Velociraptor to travel on two different surfaces, the material that will be placed on the feet shall have a coefficient of friction of more than 1.0 in accordance to the Course Analysis as to refrain from slipping, and thus meet Project Level 1, requirement 3. [8] 
  1. For the Velociraptor to have the ability to travel up a 7-degree incline, an accelerometer shall be implemented to preserve the chassis balance and thus meeting the Level 1, requirement 9.
  1. In order for the robot to detect obstacles at a range of 20 cm in its path, ultrasonic sensors shall be implemented to the build of the Velociraptor and thus meeting the Project Level 1, requirement 7. [10] 
  1. To fully accommodate the movement of a turn, a total amount of 8 servos turning the robot at a an angle of min. 45 ° degrees(referring back to requirement 10) to avoid obstacles shall be implemented to the Velociraptor and thus meeting the Project Level 1, requirement 8.[11]
  2. In order to control the Velociraptor remotely, the Arxterra application for Android phone shall be implemented to the robot and thus meet Project Level 1, requirement 9.
  1. To establish the wireless connection between the Arxterra Application and the Velociraptor in order to control the robot a Bluetooth communication shall be executed into the system’s robot design to meet Project Level 1, requirement 9.
  2. In order to control the Velociraptor wirelessly, a battery shall be implemented to power the robot for a minimum of 60 minutes and supply power enough for the MCU and servos TBD in the power report to meet Project Level 1, requirement 10.

 

Design Innovation

By: PM Khoi Vu, E&C Ashlee Chang

 

Brainstorming Approach: Flaws of Previous Generation:

  • Size & Weight: In the previous generation of MicroBiped, solid printing of parts made the robot heavier than necessary. The material used also contributed to the weight of the robot.
  • Center of Mass: The head and tail did not counter the mass of the body. This caused the center of mass to not be supported by the foot for the essential balance of the robot.
  • Servos: Did not provide enough torque to turn the head and tails of the MicroBiped. This flaw will be further explained in the next part.
  • Joints: The weight of the head and tail of Fall 2015 MicroBiped was supported by the servos.Servos are not designed to support weight but rather provides torque to the system. The leg of MicroBiped was also missing a joint that may have prevented it from walking.

 

Attribute Listing: Possibility for the Next Generation Biped

There are many different attributes to focus on in design such as material, input devices, color, size, shape, taste, texture, hardness, and odor. Some of the few focused on for the velociraptor are listed below.

  • Material
    • Wood: Khoi has access to a woodshop. Using wood, we can manufacture parts of the body perhaps for a prototype. It would be difficult to implement wood on the final design of the velociraptor, as hollowing would be tedious and inaccurate.
    • Metal: Metal is easier to work with and to manufacture. Using light metals such as aluminum could solve the weight issue from last semester’s MicroBiPed.
  • Input Devices
    • Electroencephalogram: An EEG would definitely make the customer happier with a “cooler” design, but this remote was not easy to control. Brainwaves proved to be an inaccurate input method for the velociraptor.
    • Arxterra Control Panel: Most projects in the Robotics Company plan to use the Arxterra app as a remote for communication. This option has a lot less wow-factor, but will, in fact, communicate successfully having reliable Bluetooth.
  • Weight
    • Distribution: Weight distribution must be mapped out as to keep the velociraptor balanced. For instance, the head and tail of the velociraptor must contain a chunk of the overall weight to balance out the displacement of the left and right foot.
    • Material: Choice of material for the velociraptor can determine the success or failure for the velociraptor to perform. The material must be light enough to meet the servos torque requirements.
    • Components: Each electrical component adds more weight to the overall project. Trade-off tables must list important parameters comparing weight to other parameter ratios.

 

Lateral Thinking:

  • Forced Relationship Technique:
    • A biped that fly.
    • A biped with wheels.
    • A biped made of paper.

 

  • Point of View:
    • A biped that will be able to travel at lightspeed.
    • A biped that will be able to swim.
    • A biped that will walk using its arm and play basketball.

Solutions:

  • Size & Weight:  Reduce mass by printing out hollow parts and using better material for printing that may be lighter than what was used the previous generation.
  • Center of Mass: Increase mass of head and tail or move head and tail further away from the body to better balance the weight on the foot
  • Servos: Upgrade to servos with more torque and faster turning speed for easier maneuvering and to complete dynamic walking requirement.
  • Joints: New joints will be designed for the head and tail to distribute the weight to the body instead of the servos. The missing joint will be included to ensure the stability of the robot.

 

Systems/Subsystem Design

By: S&T Camilla Jensen

 

Product Breakdown Structure

Power

The Velociraptor will have power supplied from a portable source, such as a battery so that it can be controlled remotely from the Arxterra application on an Android phone.

Servos

As the mission objective states that the Velociraptor will be a biped robot so the research from last semester’s MicroBiped using the servos as motors to perform walking proved to be the best option. A study was conducted to compare the different servo options for the Velociraptor (servo trade-off study). Last semester’s MicroBiped failed to successfully walk; therefore, to improve on this feature for the Velociraptor, 8-10 servos are to be used to provide enough torque to conform to The Level 1 Project Requirements. Complying with The Level 1 Program Requirement #2 and taking into account the cost-effectiveness aspect, the trade-off study will be conducted to determine which servo to buy that will keep the cost of the servos within the program’s budget of $400 dollars.

Size

To follow the Level 1 Project Requirements, the Velociraptor will be a toy robot of no more than the size of last semester’s MicroBiped and Titrus-III, roughly measured, 40cm x 13cm x 11cm.

Sensors

To comply with the Level 1 requirement #8, Ultrasonic sensors will be implemented for obstacle detection and avoidance as described in the mission. To control the balance of the Velociraptor when walking up inclines, another sensor will be implemented to determine position and orientation. A research of last semester’s choice of a gyroscope for its MicroBiped followed and a trade-off study (Link to Accelerometer vs. Gyroscope trade-off study) of the Accelerometer vs. Gyroscope, the accelerometer qualified as the better option for the Velociraptor to measure and relay orientation information of the Velociraptor. The system will collect real time data from the sensors and send them to a third party application, the Arxterra app, which will be controlled by the user.

Communication

To control the Velociraptor wirelessly, an Android phone paired with the Arxterra Application will receive sensor data via a Bluetooth device and allow for remote control. Arxterra is a telerobotics company developing open source robots that can control the robots from anywhere with cell phone coverage. The Arxterra Control Panel allows for easy integration of a user interface on the Arxterra App to be controlled on the Android phone and thus fulfilling the Level 1 requirement #9.

Materials

The material of the Velociraptor must be strong and durable. A suitable material for this will be aluminum. Aluminum is both lightweight and sturdy and will be able to carry the added weight of the extra 2-4 servos that are to be implemented to the Velociraptor. Hollowing body parts on the CNC machine to manufacture a frame-like chassis will lower the weight while also reducing the costs of material. A study using SolidWorks will be conducted to verify the strength of aluminum to carry the weight of robot without bending or cracking.

Battery

The battery for the Velociraptor will need to provide power for 8 servos and the microcomputer. It will need to be rechargeable and more cost efficient in the longer run. The battery should provide power for the Velociraptor to complete the mission in one trial and thus when decided what servos to use, the  estimated time the robot will spend to complete the mission will be calculated. For the Velociraptor to statically walk, the battery should have a high discharge rate in order to deliver a large amount of power at one time for performing one step. For safety requirement, the maximum safe continuous discharge rate must be greater than the maximum current drawn from the servos and electronics board.  

 

Electronic System Design

By: S&T Camilla Jensen, E&C Ashlee Chang

 

1

Elementary approach to mapping the system

 

In order to accommodate all the requirements of the customer, the velociraptor will have many input sensors and output actuators in place. Based on the information obtained from the sensors, the velociraptor will in turn perform an action and output the information to the actuators. A list of all components is listed: sensors (ultrasonic sensor, accelerometer, Bluetooth), communication (Bluetooth in an Android), microcontroller, power source (battery), and actuators (servos). Below maps out a more complex block diagram. More details about the pin locations are shown in the Fritzing diagram.

 

 

2

 

Interface Definitions:

Screen Shot 2016-02-27 at 10.40.10 AM

Table 1: Pin connections for Arduino Microcontroller

Table 1 shows the total number of ports on the ATmeg32U4 board in combination with the Arduino pins. To estimate the pins needed to connect the components to control the Velociraptor a comparison with table 2 has been made to eliminate the leftover pins.

Screen Shot 2016-02-27 at 10.40.23 AM

Table 2: Pin connections for components of Velociraptor

System Resource Map:

By: Camilla Jensen (Systems Engineer)

Screen Shot 2016-02-27 at 11.20.27 AM

Table 1 shows the outcome of the comparison of table 1 and table 2 from the Interface Matrix. E&C engineer Ashley Chang performed a test of the of servo communication with the microcontroller and the test proved that the need for a servo driver as last semester used to communicate with the servos for the PMW signal is unnecessary as the servos are compatible to communicate with the microcontroller through digital I/O pins as well. Therefore, the servos for this semester Velociraptor are connected to the digital output pins 2-9 as shown in Table 1.

Fritzing Diagram:

By: M&D Mingyu Seo

Fritzing Diagram

 

 

Mechanical Design

By: M&D Mingyu Seo

 

Introduction

For the velociraptor biped, the design must not only be able to provide a new solution to incorporate biped features but also possible use for a future toy design. This design will demonstrate the feasibility of the dinosaur biped as a toy product and allow future semesters the flexibility of upgrading and reworking the design to be more interactive between the user and the robot. The design of the velociraptor biped will be based on structures designed by Titrus-III, created by Tokyo Institute of Technology, while incorporating new features such as ultrasonic sensor and accelerometer sensor.

 

Preliminary Sketches                                                                                           

Using the Titrus-III model as a reference, Figure 1 shows the  drawing if preliminary sketches by roughly defining the size of each component, which will adhere to the Velociraptor standards as prescribed in our level 1 project requirements. One of the parts I’ve emphasized was to keep the base of the foot to be parallel to the body to ensure stability.

 

Office Lens 20160216-234816Figure 1

Figure 2. shows the components that make up for the joint. The joint is made up of 8 different components, which includes a frame for the knee, 2 connectors from knee to ankle, 2 connectors for the 2 servos we’ll be using each leg, and 1 connector from knee to the body of the velociraptor to keep the legs stable and parallel to the body when we perform static and dynamic walking.

right leg

Figure 2

Design and Unique Task Descriptions

By: E&C Ashlee Chang, M&D Mingyu Seo

 

Subsystem description: Material and shape of the foot

Associated task description: Walking on two different terrains–linoleum and carpet.

  • The velociraptor must have a foot shape that will not hinder its ability to walk. The soles on the velociraptor will be of a different material than that of the wood, metal, or plastic of the body. To handle both the slippery tiles and fuzzy carpet, the soles must have a friction coefficient large enough to adhere to the floor without falling. Materials such as sandpaper and rubber will be researched and tested. This subsystem is connected to level one requirement #8–traveling on two different surfaces.

 

Subsystem description: Leg joint mechanism

Associated task description: Walking over a 0.5 cm rubber divider

  • Project level 1 requirements #6-8 describe the velociraptor being able to walk on two different surfaces. The mission room of VEC-501 has a rubber divider in between the hallway and the classroom of the ECS building, connecting the linoleum and carpet. The velociraptor must lift its foot high enough (over 0.5 cm) to be able to walk over this part of the mission. How tall the limbs are will determine how high the legs will be able to lift.

Subsystem description: Ultrasonic sensor

Associated task description: Object detection

  • Project level 2 requirement #8 specifies the need for the velociraptor to detect objects. After walking over the rubber divider onto the carpet, the an object will be awaiting the velociraptor on the other side. This object will most likely be a wall, such as a notebook held up. The ultrasonic sensor will constantly update the distance between the velociraptor body and the object. Upon reaching a certain distance difference, the velociraptor must respond.

 

Subsystem description: Turning mechanism

Associated task description: Velociraptor must turn in the case of an object being in its path

  • Upon object detection using an ultrasonic sensor, the velociraptor must be able to turn to maneuver around this object. There is a minimum requirement of 90* capability to turn, as specified in level 1 requirement #11. The turning mechanism will either be implemented by: (1) one leg taking larger steps than the other, or (2) an extra servo for each leg positioned perpendicular to the other leg servos to spin the entire joint. Level 2 requirement #9 specifies the need for the extra servos to successfully turn.

 

Subsystem description: Bluetooth

Associated task description: The velociraptor must be controlled wirelessly

  • Level 2 requirement #11 describes the velociraptor communication being wireless. The velociraptor will pick up a signal from the user using a Bluetooth module connected to the Arduino board.

 

Subsystem description: Android Arxterra App

Associated task description: A phone app will be used to remotely control the velociraptor

  • Level 2 requirement #10 shows the method of control of the velociraptor will be using an Android phone running the Arxterra App. The Bluetooth signals of both the phone and the velociraptor will be transmitted to one another; this includes sensor information and actions to perform.

 

Subsystem description: Balancing

Associated task description: Use of servos to move the head and tail to balance while walking

  • Project level 1 requirements #6-7 describes the velociraptor being able to stand on 2 legs and be able to statically walk, which uses the head and the tail as counterweight to balance on one leg while the other leg is up. Dynamic walking will require the velociraptor to walk without the head and tail for balance. Upon reaching the incline, the accelerometer sensor will detect disorientation and prevent the velociraptor from falling backwards by sending real-time data for the user to orientate the position of the servos. Simulations will be done through SolidWorks to determine the center of mass.

Subsystem description: Servo speed

Associated task description: Dynamic walking

  • Because the velociraptor must be able to perform dynamic walking (level 1 requirement #7), the servo speed becomes an important factor in the trade-off studies. Operating speed is measured by how many seconds it takes for a servo to rotate 60*. Both the legs (for walking) and the head and tail (for balancing) must be able to rotate at this quicker rate, so ideally all servos will be of the same operating speed and have the capability of spinning quickly. The quickest ones in the trade-off studies at 4.8 V of power were 0.12 s/60* and the slowest ones were 0.23 s/60*.

 

Subsystem description: Safety

Associated task description: Product category is a toy and must be safe for certain age groups

  • The objective states the velociraptor will be manufactured as a toy, and must also satisfy level 1 requirement #3–CSULB’s health and safety policy. The velociraptor shall not be of a hazard to the user, examples including sharp edges, ways to be electrocuted or burned, etc.

 

 

Spring 2016 Pathfinder Research Project

/in , /by

 

pf1 pf2

 

By:

Peiyuan Xu (Project Manager)

Xiong Lee (Mission, System and Test Engineer)

Juan Acosta (MCU Subsystem and Control Firmware)

Tuong Vu (Sensors, Actuators and Power)

Lindsay Levanas (Design and Manufacturing)

Table of Contents

 

Project Manager Research

 

Source Material

  1. Pathfinder Preliminary Documentation. 11/12/14 http://arxterra.com/wp-content/uploads/2014/11/Pathfinder-Preliminary-Documentation.pdf
  2. Pathfinder Final Documentation. 12/12/14 https://www.arxterra.com/pathfinder-final-documentation/
  3. Pathfinder Course Mapping. 10/30/14 https://www.arxterra.com/pathfinder-course-mapping/
  4. Pathfinder Final Video. 1/20/15 https://www.youtube.com/watch?v=p75FGE_HQl0

Review of Literature

Analysis of Past Level 1 Requirements 

Requirement Evaluation Rubric:

  1. Is the requirement, Quantitative, Verifiable, and Realizable?
  2. Is the requirement response to customer’s expectations?
  3. Does the requirement move the design process forward?
  4. Does requirement provide links to source material?

Rubric

 

Spring 2016 Discussion of Requirements from Fall 2014:

The Group clearly stated the issue that automation industry meets and the needs for them to develop autonomous and self-Sufficient machines. The project objective was generated properly based on the customer’s expectation. However, on the requirements level, the group did not use enough quantitative, verifiable, and realizable thinking to write their level 1 requirements. For number 5 and 6 of their requirements, there was no quantitative variables that can be measured or proved to meet their requirements. Those requirements could be improved by mentioning more details of the environment such as quantitative temperature, wind speed, dust level, etc. In addition, the word “shall” should be used instead of “must” in those two requirements. Some of the requirements are lack of source links for us to research them in details. Their preliminary research posted nearly at the end of the semester and included level 2 requirements as well. Their final documentation and preliminary research had very much the same content. Their final video documentation was made properly as it contains their design of work and testing activities. But one thing I noticed that for the video documentation, they did not include the final testing of Pathfinder running in the Mediterranean environment which was one of their requirements.

 

Spring 2016 New Project Objectives:

  • Pathfinder should be able to explore the desert area for a whole day.
  • Google Tango tablet will be used and installed onto the Pathfinder.
  • Solar panels will be used to charge the batteries.
  • Pathfinder allows to move certain amount of time and stops to wait for solar panels charging the battery and then continue exploring.
  • Pathfinder should autonomously go to a destination by clicking a point on the photo that google tango captures.
  • Make the Pathfinder cool

 

Spring 2016 New Level 1 Requirements:

Many changes will happens on the Pathfinder this semester. These include using solar panels to charge the batteries and also google Tango tablet will be used to navigate pathfinder instead of using GPS navigation/waypoints. Therefore our requirements will various from Fall 2014 semester. These may include:

  1. The pathfinder shall be able to handle the desert terrain. Meaning it will function properly for up to 100 degrees and has proper suspension system that can handle bumpy road condition.
  2. The pathfinder shall be self-sufficient by using solar panels.
  3. The pathfinder will explore the desert for at least 15 minutes and then it will recharge for up to 1 hour and repeat the steps for the rest of the day.
  4. Sealed environment for microprocessor, electronic components and Tango tablet
  5. An extra portable charger will be used to charge Tango tablet separately or an extra small panel will be used to do so.
  6. The weight of Pathfinder shall not exceed 17 pounds

 

Spring 2016 Preliminary Budget:

For our preliminary budget, we will assume to spend up to $150 on appropriate solar panels that have enough power to charge batteries in short amount of time. The Google Tango can be borrowed from the president form CSULB HKN society. Other mechanical parts and electronics can cost up to $150. Total cost will be limited to $300 negotiable.

Spring 2016 Discussion of Schedules:

  • The final project will be due on May 9th (The Final Exam date).

http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html

  • It is important to break down project to small tasks and schedule the due dates for each task. The project breakdown structure will be done by system engineer and from that, due dates for each task will be determined and announced by project manager.

 

Systems Engineer Research

By Xiong Lee (Mission, System, Tests)

Source Material:

Level 2 Requirements from Fall 2014 semester:

sy1 sy2 sy3 sys4

Summary of Level 2 Requirements:

Overall, their level 2 requirements were very good. They gave good documentations of what they did for their level two requirements. For example, how they designed their pan and tilt system for their android phone. There were things that could have been better documented. They didn’t list sources where they got the specs of their batteries, shield, arduino from.

Microprocessor and Arduino:

  • Atmega 2560 microprocessor
  • Arduino mega ADK
  1. Specs of the arduino
Microcontroller ATmega2560
Operating Voltage 5V
Input Voltage (recommended) 7-12V
Input Voltage (limits) 6-20V
Digital I/O Pins 54 (of which 15 provide PWM output)
Analog Input Pins 16
DC Current per I/O Pin 40 mA
DC Current for 3.3V Pin 50 mA
Flash Memory 256 KB of which 8 KB used by bootloader
SRAM 8 KB
EEPROM 4 KB
Clock Speed 16 MHz
USB Host Chip MAX3421E
Length 101.52 mm
Width 53.3 mm
Weight 36 g

Found on the website:

https://www.arduino.cc/en/Main/ArduinoBoardMegaADK

Some proposed level two requirements based on our level one requirement:

  1. A better electronic enclosure will be designed to keep the electronics protected (cooled).
  2. The solar panel should be able to charge the two 7.4 volt batteries for the motor as well as the 11.1 volt system battery.
  3. There will be an enclosure for the tablet to protect it from the environment.
  4. There will be Bluetooth communication from the tablet and arduino.

Testing:

Their testing of their products can be found here. They tested their GPS, Communication Bluetooth, batteries, weight and height clearance and their coding. Most of these testing had good documentations of what they did in the experiment. One thing was where they got their sources material from. They didn’t show sources to how the battery should be tested or etc…

 

Flowcharts/System block diagram:

http://arxterra.com/pathfinder-axterra-gps-communication-part-three/

http://arxterra.com/pathfinder-code-flowcharts/

http://arxterra.com/pathfinder-arxterra-communication-commands/

http://arxterra.com/pathfinder-pin-interface/

Their flowcharts and block diagrams were good. They specified everything they had on the pathfinder from their three batteries to the Bluetooth and GPS. For our system diagram, we’ll have to add the tablet and solar panel into the diagram. Our flowcharts will change because we have a different mission than what they have from the customer.

 

Interface System:

Their use of a separate pcb to store the sensors, regulators, Bluetooth, etc… (Shown above in the system block diagram) helped them make their electronics and wiring cleaner. Their diagram showed how each product interfaced with each other. On our project, we’ll have to make our Google Tango tablet communicate with the Arduino on the pathfinder. We’ll also have to use the arduino to communicate with the solar panel so it can charge up the batteries of the system and motors.

 

Electronics and Control Research

Sensors, Actuators and Power

By: Tuong Vu

E&C Division

Level 2 Sub-Requirements: (Based upon original level 2 requirements)

Servos :

  • The servo must be able to support the weight of the Google Tango, which is about 82 lbs. (370 g). Google tango  needs  to  be  on the  a  rotating platform in order to  navigate  the  pathfinder;  therefore,  the  servo  needs to have the capability  of rotating 360 degree.

Motors :

  • Generate enough torque to rotate the wheels in order for the chassis to move.
  • Need to handle  high  current
  • Protect these motors with a Buck regulator.

Battery.

  • Battery needs to supply enough voltage and current to drive the motor.
  • Keep stock battery.
  • Ni-Lithium battery 10000ma at 5 volt for Google Tango.

Solar panel.

  • The solar panel has to fit the pathfinder, and the weight of solar panel should be around 5 lbs. max. Need to be able to deliver enough current and voltage to charge the Google Tango   and motors’ batteries.

Buck regulator.

  • Batteries and motors protection, a simple buck converter can be used to step down the voltage. This is critical, over charging the battery   and oversupply the motors lead to heat building up within the components.

Charge/ discharge voltage regulator

  • Charge/ discharge voltage regulator disconnect or connect batteries from the solar panel at a certain voltage range. Pathfinder will have self-charge capability with this circuit installed.

Device Recommendations & Test Proposals:

Servos:

  • We will be using the stock motor from the previous class. (This decision may change in the future)
  • Test Servo to see if it can hold 5 lbs.

Motors:

  • We will be using the stock motor from the pathfinder. Base on testing, our motor needs about 1.8 voltage and 1.6 amps to turn on.
  • Test for the motor voltage and current required to turn under various load.

Solar Panel.

ec1

  • Conduct solar panel test to find the average output voltage and current.
  • Test charge/discharge circuit by using it to charge a 12-voltage 10A battery with the solar panel.

Buck regulator:

  • The role of the buck is to lower the voltage from the solar panel to the motors, protecting them from shock or heat damage. The current motor  on the path finder  is about 1.8 voltage  to turn on, so buck  regulator  needs  to lover  the voltage from the  solar panel or battery  down to 1.8 voltage.  Texas Instrument, Digi-key, and Mouser Electronic have the Buck Regulator we need for our project. We can self-build the Buck Regulator circuit.
  • We need to conduct some test to make sure the Buck Regulator can integrate with circuit.

Charge /discharge voltage regulator.

  • We will have to design this circuit from the ground up. The idea is using a power P–Channel Depletion Mosfet as a switch to control the flow of current from the solar panel to the motors’ batteries and Google Tango Tablet.
  • We need to build and test the design to make sure circuit can connect and disconnect the batteries from the solar panel.

Battery

  • We are using batteries from the previously installed on the pathfinder.
  • Test for the Maximum Voltage level of the batteries, in order to calibrate the voltage level that the “Charge /discharge voltage regulator” has to disconnect the batteries from the solar panel.

 

MCU Subsystem and Control Firmware

By: Juan Acosta

Source Material:

  1. Arxterra Website, Arduino

https://www.arxterra.com/rosco-and-pathfinder-arduino-code-versions-available/

  1. Arxterra Website, GitHub, Pathfinder_Rover

https://github.com/arxterra/Pathfinder_Rover

  1. Arxterra Website, Pathfinder, Pathfinder Final Documentation

http://arxterra.com/news-and-events/members/pathfinder-4/

 

Discussion based on previous Level 1 & 2 Requirements:

The previous design of the Pathfinder used modified Servos for pan and tilt control of the phone. Instead of modifying an existing servo, they should have bought an inexpensive servo with no limitations on turning radius to solve this minor issue. This could have saved a little time and helped moved the project along by allowing more time to focus in other areas that were having major issues.

The main loop program flow for the previous Pathfinder project was successful in drawing out the tasks of the Pathfinder. They implemented simple true or false checks in order decide what action the Pathfinder should take next. This looks like a fast, simple and effective way of implementing the main loop program.

The previous design’s code flowcharts were a good starting point for their final software implementation. They clearly defined sensor input triggers and appropriate decisions based on those inputs. They did not mention if their decisions or actions were a result of Level1 requirements, but it looks like they carefully planned out all of the necessary decisions the Pathfinder would have to make based on the terrain and lap objectives.

 

Discussion based on New Level 1 & 2 Requirements:

For the MCU Subsystem and Control Firmware section of the Electronics & Control Division, I will have to: 1) write the firmware required to translate commands from the tango tablet into control signals to the motors and servos in order to move the Pathfinder or move the pan and tilt field of view for the Google Tango, 2) Read sensors such as wheel decoders and translate into data bytes for calculating speed and distance to travel, and 3) implement control algorithms for controlling the charging of the Pathfinder’s solar panel charging network.

In order to code for tasks 1 and 2, I will reference and then modify the Pathfinder Code Flowcharts created by a past semester’s blog posting. I will also reference previously uploaded code for the Pathfinder that is available on GitHub from the Arxterra website.

Lastly, in order to code the algorithms for measuring and controlling the charge of the battery via solar panels, I will have to do further research on safe charging procedures and requirements and battery protection. I hope to have a scaled version of the Pathfinder available for prototyping and testing of the control firmware before final implementation to the final design.

Based on previous code for the Pathfinder, some of the level 2 requirements will have to be modified or deleted. For Example, our design will incorporate the Google Tango so there will be no need for obstacle avoidance measures and sensors since our design won’t be autonomous as it was defined as a level 1 requirement that the Google Tango is to act as a remote control with field of view. Examples of some of the code that I will have to tailor to our design are the programs written to measure battery consumption, drive the motors, and drive the servos. Programs that I might have to develop are charge controlling algorithms to safely charge and discharge the Pathfinder’s battery cells for optimal usage as define by the level 1 requirement needing the Pathfinder to be able to spend a day exploring the Amboy Crater.

A few of the programs previously written for the Pathfinder have not been uploaded or tested, so it will be crucial for me to start testing and debugging algorithms that are available on GitHub to determine which ones are viable and which ones I will need to code myself. It will be important for me to have working knowledge of how to code and upload programs onto the Arduino Board, so I will attend any and every training session that the Electronics & Control Division Manager hosts in order to continue to move this project forward. The Previous Design utilized an Arduino Mega so I will have to research on similarities and differences between the Uno and the Mega and see which one would be a better level 2 requirement solution.

 

Design and Manufacturing Research Work

By: Lindsay Levanas

Source Material

  1. Pathfinder Preliminary Project Documentation, Project Requirements 1. Sealed pan and tilt camera platform for an Android phone, pg. 3-4, 11/12/14 http://arxterra.com/pathfinder-preliminary-project-documentation/
  2. Pathfinder Preliminary Project Documentation, Project Requirements 2. Sealed environment for microprocessor and electronic components, pg. 4, 11/12/14 http://arxterra.com/pathfinder-preliminary-project-documentation/
  3. Pathfinder Preliminary Project Documentation, Project Requirements 5. Must be able to safely traverse mountainous terrain and avoid obstacles, pg. 5, 11/12/14http://arxterra.com/pathfinder-preliminary-project-documentation/
  4. Pathfinder Pan and Tilt Camera Platform, Theory, 10/26/14 http://arxterra.com/pathfinder-pan-and-tilt-camera-platform/
  5. Pathfinder Pan and Tilt Camera Platform, Procedure, 10/26/14 http://arxterra.com/pathfinder-pan-and-tilt-camera-platform/
  6. Pathfinder Preliminary Project Documentation, Major Project Elements 1. Sealed pan and tilt camera platform for an Android phone, pg. 7-8, 11/12/14 http://arxterra.com/pathfinder-preliminary-project-documentation/
  7. Pathfinder Preliminary Design, 11/12/14 http://arxterra.com/pathfinder-preliminary-design/
  8. Pathfinder Preliminary Project Documentation, Major Project Elements 2. Sealed environment for microprocessor and electronic components, pg. 8, 11/12/14http://arxterra.com/pathfinder-preliminary-project-documentation/
  9. Pathfinder 3D Printing, Introduction, 12/11/14 http://arxterra.com/pathfinder-3d-printing/
  10. Pathfinder Custom PCB Design, Background, 11/11/14http://arxterra.com/pathfinder-custom-pcb-design/
  11. Pathfinder Preliminary Project Documentation, Major Project Elements 5. Must be able to safely traverse mountainous terrain and avoid obstacles, pg. 10, 11/12/14http://arxterra.com/pathfinder-preliminary-project-documentation/
  12. Pathfinder Custom PCB Design, Schematic Components, 11/11/14 http://arxterra.com/pathfinder-custom-pcb-design/

 

Introduction

During the fall of 2014, the first Arxterra Pathfinder project was outlined and implemented. The basic concept was to mirror Mars rovers, both in their basic construction and autonomous ability. To this end, requirements were created to help guide the original designers in building a simplified Earth base model. Now, during the spring of 2016, a new group of engineers will work together to build upon the previous Arxterra Pathfinder project to bring it closer to the rovers that have been sent to Mars. Following below is a review centered on the design and manufacturing elements of Pathfinder’s requirements as discussed in its original documentation. The review will consist of the evaluation and modification of previous requirements to encompass the new project goals to implement Google Tango and solar panels in the current Pathfinder model, as well as new requirements where necessary.

 

Review of Pathfinder’s 3D simulated sealed pan and tilt camera platform for an Android phone requirement

Pathfinder’s first original requirement was to utilize a sealed pan and tilt camera platform for an Android phone.1 Using the dimensions of the Pathfinder’s base and the field of view measurement calculations from the Android phone’s camera, a design was selected and modeled.5 While the measurement requirements are quantitative, verifiable and realizable, the resulting 3D model of the pan and tilt platform is not, as not all measurement dimensions are given. The dimension of each piece is not defined, and so a working 3D model of this platform cannot be duplicated.  Located at the subsystem level (level 2), this 3D modeling requirement is linked to the project level (level 1) requirement for a sealed pan and tilt camera platform for an Android phone.6 With the proper measurements, this 3D model would move the design process forward, as materials for the parts could then be selected (by trade-off study, though this process is currently missing from Pathfinder’s documentation) and the final product could be constructed on Pathfinder’s base.

For the spring 2016 Pathfinder project, the above requirement and it’s subsequent requirements, trade-off studies, and measurement calculation process will not change much accept to accommodate a Google Tango tablet as the camera, instead of an Android phone. Also, as the 3D model of the pan and tilt platform is not clearly defined, a trade-off study of different designs and their measurements will be done.

Lastly, a new sublevel requirement will be added to account for temperature control of the sealed pan and tilt platform.

 

Review of Pathfinder’s 3D simulated preliminary design requirement

Another of Pathfinder’s project level (level 1) requirements was to create a sealed environment for the microprocessor and electronic components.2 Therefore a subsystem (level 2) requirement to 3D model the sealed environment was created.8 However, unlike the pan and tilt platform, the sealed environment for the electronics wasn’t modeled alone. Instead, both sealed environments were 3D modeled together with the body of Pathfinder to create the preliminary design requirement.7 As this design features 3D modeled pictures only, it is qualitative and not verifiable or realizable. Also, while the 3D modeled sealed environment for the electronics is linked to one of the project requirements, the Pathfinder 3D model as a whole is not. Therefore, it should be worded such that it encompasses the other two sealed environment requirements and should replace them as a project level (level 1) requirement. The sealed pan and tilt camera platform for an Android phone requirement, and the sealed environment for the microprocessor and electronic components requirement should then be redefined as subsystem (level 2) requirements so that the link back to the project level (level 1) requirements is easily traceable. Placed in this order, the preliminary design requirement would move the design forward, as then the subsystem requirements for the sealed environments would naturally follow. Finally, note that there are no links to source material and that no equations are used to calculate the initial set up for the preliminary design requirement.7

Similar to the 3D simulated sealed pan and tilt camera platform for an Android phone requirement, the 3D simulated preliminary design requirement is lacking in measurements and design trade-off studies. However, as the spring 2016 Pathfinder project will incorporate a Google Tango tablet and solar panels in its design, different structural trade-off studies then those mentioned to be missing will be conducted to account for the new design conditions.

Lastly, a new sublevel requirement will be added to account for temperature control of the sealed environment for the microprocessor and electronic components.

 

Review of Pathfinder’s 3D printer requirement

Based on the original documentation, the 3D printing of the sealed pan and tilt camera platform for an Android phone is a subsystem (level 2) requirement.9 As measurements are not given, the 3D printer requirement is qualitative only, and not verifiable or realizable. Had this requirement been listed under the project level (level 1) requirement of making the sealed pan and tilt camera platform for an Android phone, it would have been a subsystem (level 2) requirement, but it was not. 3D printing was however mentioned under the project level (level 1) requirement to make a sealed environment for the microprocessor and electronic components,8 but then there is no documentation on that manufacturing process. Both of the project level (level 1) requirements mentioned should contain 3D printing as a subsystem (level 2) requirement to help link the two levels together. No links to source material are mentioned, though one about the quality expectations of 3D printers would help. Such a source would allow for a more realistic and detailed requirement. Providing the quality of the 3D printed sealed pan and tilt camera platform for an Android phone is high, this requirement moves the design forward in that it may now be integrated onto the body of Pathfinder. Also, although none are mentioned, this requirement is based on the 3D simulation’s measurements and dimensions.

 

Review of Pathfinder’s Custom PCB Design requirement

As there is a project level (level 1) requirement for Pathfinder to safely traverse mountainous terrain and avoid obstacles, it follows that there is a subsystem (level 2) custom PCB Design to limit the amount of wires in the open.10, 11 Though a qualitative requirement, it is still both verifiable and realizable. No links to source material is listed, however there is both a picture and pin assignment chart included in the document, making it possible to replicate and verify the PCB design requirement.12 Slimming the electronic components on to a PCB moves the design forward to meet its project (level 1) requirement of safely traversing mountainous terrain and avoiding obstacles.3

For the spring 2016 Pathfinder project Google Tango will be used instead of the Android phone’s camera, GPS system, and sensors. In addition, Solar panels will be used to charge the batteries, therefore powering Pathfinder’s system. Both of these features will be implemented into the PCB while their previous counterparts are removed. As such, a different PCB board will be used based off of the new schematic that the electronics and control engineer (PCB Design) will design.

 

Conclusion

Pathfinder’s design and manufacturing will include 3D simulated models of Pathfinder as a whole, of the sealed pan and tilt camera platform for a Google Tango tablet, and of the sealed environment for the microprocessor and electronic components. From these models, parts may be either 3D printed or purchased. Finally, a custom PCB run by solar panels will be assembled.

 

Creativity Exercise:

Problem Statements:

  • Weight requires more current to run than solar panels can easily provide.
  • Runs on batteries, not solar panels. How and where can solar panels be fitted to Pathfinder?
  • Battery for Tango Tablet can only last about 45 minutes. How are we going to charge it constantly?
  • Cooling system for electronics. How do we keep the electronics from overheating?

 

 

creativity3creativity1 creativity2 creativity4 creativity5 creativity6

 

 

 

 

Spring 2016 Millennium Falcon Research

/in , /by

By:

Luis Valdivia (Project Manager)

Anthony Becerril (Mission, systems and test)

Juan Mendez (Design and manufacturing)

Kevin Nguyen (Electronics and Controls)

Table of Contents:

  1. Project Manager Research
  2. Mission, Systems and Test
  3. Design and Manufacturing
  4. Electronics and Controls
  5. Creativity Assignment

 

1. Project Manager Research:

Project Level 1 requirements:

Overview/Purpose: Highlight baseline qualitative requirements for the overall mission.

Mission  Objective(s) from previous semesters: Produce aircraft that performs flight path set by the customer. The aircraft must also maintain stability as it travels its flight path. To meet aesthetic requirements set by the customer, the vehicle must resemble a UFO or the Millennium Falcon as well as producing a light show

Mission requirements from previous semesters:

  • Complete the project before end of semester
  • Follow regulations and policies for the Federal Aviation Administration (FAA), Unmanned  Aircraft Systems (UAS) and College of Engineering (COE) health and safety.
  • Not exceed the budget
  • Aircraft will maintain stable altitude
  • Remote control aircraft and display light show
  • Meet aesthetic requirement set by the customer (look like a UFO or the millennium falcon).

Mishaps:

  • Not able to maintain stability due to uncontrolled yaw rotation thus failing flight path requirement.

Proposed solution for Spring 2016:

  • Correct yaw stability issue by performing case studies (if allowed by customer) of fans mounted at certain angles.
    • Design adjustable angle brackets.
  • researching counter rotating fans to correct yaw issue (if allowed by customer)
  • Review policies and regulations set by the aforementioned organizations.
  • Establish safety landing feature that will slowly land view at low battery voltage.
  • Design and Manufacture interchangeable landing leg system.

 

Project Budget:

Overview/Purpose: Keep track of budget to avoid overspending.

Budget based on previous semesters:

  • Work with cost estimate as an outline to follow this semester.
  • Preliminary budget based on previous  projects around $400

Mishap: None. Requirements were met by remaining under set budget.

Proposed solution(s) for Spring 2016:

  • Create spreadsheet that keeps track of budget for all vendors and components of the vehicle.
  • Weekly update main spreadsheet with all procurement details.
  • Emphasize consistent documentation format to make information easy to access during the semester.

 

Project Schedule:

Overview/Purpose: Set a work schedule to follow on a weekly basis throughout the semester..

Project schedule based on previous semesters.

  • Use level 1/2 requirements to establish appropriate schedule .
  • Keep track of time invested each week for all members.
  • Include status and completion for each member.

Proposed solution(s) for Spring 2016:

  • Document progress every time an action item is closed.

 

EVALUATION RUBRIC

  1. Is the requirement, Quantitative, Verifiable, and Realizable?
  2. Is the requirement located at the correct level (1 – program / Project)
  3. Is the requirement response to a higher level requirement or customer’s objective (Requirement Flow Down)? Is the linkage clearly defined?
  4. Does requirement provide links to source material?
  5. Does the requirement move the design process forward?
  6. Are equations used to calculate a requirement provided and are answers correct?
  7. The requirements that are missing are the hardest to discover and will be factored into your evaluation.
  8. Is language in the form of a requirement?
  9. Avoid multiple requirements within a paragraph (i.e., breakup statements that contain multiple requirements.)

Y= Yes

N= No

X= No answer needed

Level 1 Requirements based from previous semesters 1 2 3 4 5 6 7 8 9
Must complete the project before end of semester. Y Y N Y N N X Y X
Will follow regulations and policies for the FAA, UAS, & COE. Y Y Y Y N N X Y X
Must not exceed budget. (estimated $400 from last semester) Y Y N N N Y X Y X
Aircraft will maintain stable altitude while completing course. Y Y Y Y Y N X Y X
Remote control aircraft and display light show. Y Y Y N N N X N X
Meet aesthetic requirement set by the customer. Y Y N N Y N X Y X

Works cited:

 

  1. Arechiga, Danny. “Level 1 Requirements.” Arxterra. N.p., 16 Sept. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/level-1-requirements-4/>.
  2. Hatori, Ayaka. “Arxterra | Mission Objective and Level 1 Requirements.” Arxterra. N.p., 18 Mar. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/mission-objective-and-level-1-requirements/>.
  3. Hatori, Ayaka. “Final Documentation.” Arxterra. N.p., 13 May 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/final-documentation-3/>
  4. Hatori, Ayaka. “Arxterra | Final Documentation.” Arxterra. N.p., 13 May 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/executive-summary-final-project-documentation/>
  5. Hatori, Ayaka. “Mission Objective and Level 1 Requirements.” Arxterra. N.p., 8 Mar. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-intro/>.
  6. Mohideen, Shamir. “UFO Final Documentation.” Arxterra. N.p., 14 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-final-documentation/>.
  7. Mohideen, Shamir. “UFO Preliminary Project Documentation.” Arxterra. N.p., 28 Oct. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/ufopreliminary-project-documentation/>.
  8. Vo, Tuan, and Elaine Doan. “Level 1 Requirements.” Arxterra. N.p., 21 Apr. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/level-1-requirements/>.
  9. Teng, James. “UFO Preliminary Project Plan.” Arxterra. N.p., 30 Sept. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-preliminary-project-plan/>.
  10. Hatori, Ayaka. “Arxterra | Final Documentation.” Arxterra. N.p., 13 May 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/executive-summary-final-project-documentation/>.
  11. Stapleton, Anne. “Final Project Progress Report.” Arxterra. N.p., 19 Dec. 2013. Web. 11 Feb. 2016. <https://www.arxterra.com/project-progress-report/>.
  12. Mohideen, Shamir. “Schedule.” Arxterra. N.p., 14 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/schedule/>.
  13. Teng, James. “UFO Project Summary.” Arxterra. N.p., 17 Dec. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-project-summary/>.

 

2. Mission, Systems and Testing Research:

LEVEL 2 REQUIREMENTS:

Overview/Purpose: Detail level 2 requirements in alignments with level 1 requirements made to complete mission

 

Level 2 Requirements from previous semesters:

  • Quadcopter frame and electric ducted fans
  • specify UFO diameter and weight
  • Fire protection
  • LED ring for light show
  • Use of Electronic Speed Controllers (ESCs)
  • Control system consisting of microcontroller and flight controller
  • wireless communication via phone application and bluetooth module
  • Landing gear equipment
  • Shell mold for UFO appearance
  • Achieve flight and specify elevation and flight speed
  • Provide sufficient power for classroom flight

 

Mishaps: Stable flight has yet to be achieved with certain requirements never initiated (landing gear, flight, fire protection,…)
Proposed Spring 2016 Solution: revise level 2 requirements and consider new ones if new level 1 requirements are made

DIGITAL SIGNAL CANCELLATION:

Overview/Purpose: Implementation of signal cancellation from a digital approach, specifically by inverting the signal

 

Digital Signal Cancellation from previous semesters:

  • Via Simulink, simple cancellation made via inverting signal (sine wave used)
  • Via audio recording, cancellation attempted by simultaneously playing sounds of original signal and inverted signal (guidance with matlab code)

 

Mishaps: Cancellation failed via audio recordings
Proposed Spring 2016 Solution: Discuss with team if further work is necessary; If approved look into researching noise cancellation for aircrafts

NEOPIXEL LED LIGHT SHOW:

Overview/Purpose: A lightshow on the Adafruit NeoPixel Ring controlled with a microcontroller, bluetooth module, and app

 

NeoPixel LED Light Show from previous semesters:

  • LED control circuit w/o bluetooth to test custom light shows
  • LED control w/ bluetooth module via bluetooth terminal app
  • Light show integration with arxterra code
  • Created function/code from scratch for programming lightshow

 

Mishaps: None; successful creation of programmable LED light show; tape lights considered and never revisited
Proposed Spring 2016 Solution: Consider investigation light functions to display battery life

BLUETOOTH INTERFACE TO ARXTERRA APPLICATION:

Overview/Purpose: how to use bluetooth to control the UFO via phone

 

Bluetooth Interface from previous semesters:

  • step-by-step procedure on testing a bluetooth module with simple LED example
  • via phone application and Multiwii controller, the UFO can be controlled wirelessly

 

Mishaps: None; successful bluetooth integration
Proposed Spring 2016 Solution: Consider using, editing, or remaking method of controlling the UFO

ESC CURRENT DRAW TEST:

Overview/Purpose: Calculations of current draw from EDFs for overall power consideration

 

ESC Current Draw Test from previous semesters:

  • Completed testing and tabled results

 

Mishaps: Upon shorting, an upgrade was made to replace the ESC for short time to maximum throttle
Proposed Spring 2016 Solution: Consider retesting to check for functionality

EDFs (ELECTRIC DUCTED FANS):

Overview/Purpose: Overview on Electric Ducted Fans (EDFs) bought and installed on the UFO.

 

EDFs work from previous semesters:

  • Specifications provided: Dr. Mad 50mm 10 blade EDFs
  • Calculation of thrust outputs at various throttle levels for each EDF
    • Completed testing and tabled results
    • not perfectly linear
  • estimated weight: 1100g; 1100g thrust =  60%-70%; conclusion: stable flight = > 70% throttle
  • Cancelling horizontal torque of EDFs
    • New Fans: too costly and couldn’t find one to fit UFO model
    • Fan Tilt: tilt for counter clockwise thrust; concluded tilt will prevent spinning
    • Air Ducts: implement louvers to redirect airflow
  • Testing done on best number of blades
  • Solidworks simulation done to see if air ducts will minimize rotation in same direction

 

Mishaps:

  • Calculations of blade positioning seem incorrect
  • Cancelling of horizontal torque failed
  • Testing number of blades only considered three and ten blades
  • Air duct testing did not resolve unwanted rotation

Proposed Spring 2016 Solution: Retake tests and specifications

WIRELESS REMOTE COMMUNICATION USING XBEE RADIOS:

Overview/Purpose: wireless communication between the UFO and the user via an XBee Radio

 

Wireless Remote Communications from previous semesters:

  • controller: joysticks controlling vertical and horizontal via potentiometers
  • XBee: configuration, data, interpretation
  • vertical testing: joystick up increased fans accordingly

 

Proposed Spring 2016 Solution:

  • Consider getting new EDFs

UFO SYSTEM BLOCK DIAGRAM AND ELECTRICAL SCHEMATIC:

Overview/Purpose: Provided system block diagram and electrical interface diagram of UFO

 

System Block Diagram and Electrical Schematics from previous semesters:

  • outlines system block diagram
  • corresponding wiring diagram for system block diagram outlined

 

Mishaps: upon visual inspection, there is room for improvement
Proposed Spring 2016 Solution: Update with any changes made this semester

EVALUATION RUBRIC

  1. Is the requirement, Quantitative, Verifiable, and Realizable?
  2. Is the requirement located at the correct level (1 – program / Project)
  3. Is the requirement response to a higher level requirement or customer’s objective (Requirement Flow Down)? Is the linkage clearly defined?
  4. Does requirement provide links to source material?
  5. Does the requirement move the design process forward?
  6. Are equations used to calculate a requirement provided and are answers correct?
  7. The requirements that are missing are the hardest to discover and will be factored into your evaluation.
  8. Is language in the form of a requirement?
  9. Avoid multiple requirements within a paragraph (i.e., breakup statements that contain multiple requirements.)

Y= Yes

N= No

X= No answer needed

Level 2 Requirements based from previous semesters 1 2 3 4 5 6 7 8 9
UFO will be created with quadcopter frame and electric ducted fans Y Y Y N Y N X Y X
UFO will have specific diameter and weight Y Y N N N N X Y X
UFO will be protected against fires N Y Y Y Y N X Y X
UFO will utilize LED ring for light show Y Y Y N Y Y X Y X
UFO will use Electronic Speed Controllers (ESC) Y Y Y N Y N X Y X
UFO will use a microcontroller and flight controller as control system Y Y Y N Y N X Y X
UFO will be able to communicate wirelessly via Arxterra application and bluetooth module with specific range Y Y Y N Y N X Y X
UFO will be equipped with landing gear Y Y Y N Y N X Y X
UFO will have shell to give likeliness to UFO Y Y Y N Y N X Y X
UFO to achieve flight with specific elevation and speed Y Y Y Y Y N X N X
UFO to provide enough power for flight around classroom Y Y Y Y Y N X N X

 

Works cited:

  1. Hatori, Aya. “UFO Level 2 Requirements.” Arxterra. N.p., 4 Apr. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-level-2-requirements/>.
  2. Vo, Tuan, and Elaine Doan. “Level 2 Requirements.” Arxterra. N.p., 21 Apr. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/level-2-requirements-2/>.
  3. Nunez, Marco. “Digital Signal Cancellation.” Arxterra. N.p., 23 Nov. 2015. Web. 10 Feb. 2016. <https://www.arxterra.com/digital-signal-cancellation/>.
  4. Nunez, Marco. “Custom Programmable LED Light Shows.” Arxterra. N.p., 14 Nov. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/custom-programmable-led-light-shows/>.
  5. Nunez, Marco. “Creating NeoPixel Ring Lightshow.” Arxterra. N.p., 8 Nov. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/creating-neopixel-ring-lightshow/>.
  6. Webster, Logan. “How To: Light Show!” Arxterra. N.p., 20 Apr. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/how-to-light-show/>.
  7. Mohideen, Shamir. “LED Tape Lights for the UFO.” Arxterra. N.p., 13 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/led-tape-lights-for-the-ufo/>.
  8. Nunez, Marco. “Learning To Use a Bluetooth Module.” Arxterra. N.p., 20 Oct. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/learning-to-use-a-bluetooth-module/>.
  9. Alhammadi, Ahmed. “Bluetooth Interface to Arxterra Application.” Arxterra. N.p., 8 Apr. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/bluetooth-interface-to-arxterra-application-in-progress/>.
  10. Winter, Nathan. “ESC Current Draw Test.” Arxterra. N.p., 13 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/esc-current-draw-test/>.
  11. Winter, Nathan. “Electric Ducted Fans.” Arxterra. N.p., 13 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/electric-ducted-fans/>.
  12. Winter, Nathan. “Dr. Mad 50 Mm 10 Blade EDFs.” Arxterra. N.p., 13 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/dr-mad-50-mm-10-blade-edfs/>.
  13. Winter, Nathan. “EDF Thrust Test.” Arxterra. N.p., 13 Dec. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/edf-thrust-test/>.
  14. Winter, Nathan. “Cancelling the Horizontal Torque Produced by EDFs.” Arxterra. N.p., 25 Nov. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/cancelling-the-horizontal-torque-produced-by-edfs/>.
  15. Hatori, Ayaka. “Electric Ducted Fans – Number of Blades TOS.” Arxterra. N.p., 6 Mar. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/electric-ducted-fans-number-of-blades-tos/>.
  16. Montano, Juan. “Implementing the Air Ducts.” Arxterra. N.p., 20 May 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/implementing-the-air-ducts/>.
  17. Rice, Jake. “Wireless Remote Communication Using XBee Radios.” Arxterra. N.p., 20 Mar. 2014. Web. 11 Feb. 2016. <https://www.arxterra.com/wireless-remote-communication-using-xbee-radios/>.
  18. Stapleton, Anne. “System Block Diagram & Electrical Schematic.” Arxterra. N.p., 2 Dec. 2013. Web. 11 Feb. 2016. <https://www.arxterra.com/system-block-diagram-electrical-schematic/>.
  19. Ceballos, Salvador. “UFO System Block Diagram and Interface.” Arxterra. N.p., 8 Apr. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-system-block-diagram-and-interface/>.

 

3. Design and Manufacturing Research:

YAW Problem:

Overview/Purpose: The reaction wheels were to be fabricated in order for fix the Yaw problem

 

Research on previous semester work:

  • Group decided to make reaction wheels to solve the yaw problem.
  • Group decided that a cylinder design would work and that they should spin opposite of fans.
  • Determined that heavier material would produce more torque.
  • Group agreed to to use ABS plastic since it was the easiest to fabricate using a 3D printer
  • Fritzing diagram was developed
  • After receiving recommendations from the class president, the reaction wheels idea was scrapped and the group agreed to tilt the angle of thrust of the fans in order to mimic a quadcopter and fix the yaw problem.
  • Group decided to test if more blades on fan gave more thrust. They tested  3 blade fans vs 10 blade fans. They came to the conclusion that the 10 blade fan produced more thrust but ended up using a 5 blade fan because they did not have enough of the 10 blade fan to use.
  • From the previous semester it seems that the motor mounts required taping of the motors and to avoid this they had planned to use an acrylic block.
  • Solidworks was used to determine the airflow of the fans
  • Based on these simulations, it was determined that the air flows like an upside down whirlwind which would turn into a problem if they have another fan spinning the same direction. The airflow of two fans made the airflow go upward instead of straight down.
  • To fix this, the group decided to use an air duct to stabilize it. It seems like they still had a problem with the yaw and to fix this, they repositioned the air duct.

Mishaps

Proposed Solution for Spring 2016:

  • In order to speed up the process, we will be looking into changing the fans and will be performing different tests to see which fans work better. We may possibly get more fans or change the rotation of the fans.

UFO’s shell production:

Overview/Purpose: The purpose of the shell was to give the UFO a look that resembled the craft from the movie “ The day the Earth stood still”

Research on previous semester work:

  • Manufacturing Engineer worked with a Design Engineer to make the UFO Shell molding
  • 14 24x4x1 pieces of foam were glued together to make a piece big enough to make the mold.
  • Holes were then cut, though the group did not state how they determined the size and position of the holes and then painted the shell glossy gray.   
  • Group talked about mounting on a frame or shell and they agreed that frame mounting was better since it was cleaner and lighter and easier to work with.
  • They then researched the materials to construct the shell ( styrene or carbon fiber shell). They agreed to use Styrene since it was lighter and cheaper
  • A negative of the shell was created to be used on the UFO
  • Next they decided to vacuum form mold a shell. They had a shell from the previous semester and they were able to use it for the vacuum form molding. It proved to be a much better but they still had some issues  such as having a hole in the shell.
  • Their manufacturing Engineer made urethane foam mold on the lathe machine in the design lab. She did this by one inch by 1.5 inch of layers together with spray adhesives and waiting for them to bond. Next the holes for each motor were determined and done by using a 55mm drill press.
  • Next they used the plastic molding machine. Eight forms were made with each attempt adjustments were made to the mold. The shell was then painted silver.

Mishaps

  • They soon discovered that the lathe machine used to make the dome shape was 6 inches and would only provide 12 inches diameter. The shell diameter needed to be 15 inches.  To fix this, they cut the foam in half in order to make them separately then glue them back together. Two shells were made, one that was ⅛ of an inch and the other 1/16 an inch. After vacuuming the shell, the ⅛ ended up being too thick for the UFO so the group decided to stick to the 1/16 shell. (Fall 2015)
  • At first attempts the mold was left in high temperatures and became disfigured.(Spring 2015)
  • Apparently they attempted to removed the material from the lathe but it failed since they removed too much material. They had to remake the mold. (Spring 2015)
  • The group attempted to print out the ufo and then piece it together. Due of time constraints they were not able to get the mold right. They only got the prototype one and was considered to be 20 percent done.

Proposed Solution for Spring 2016:

  • We will model out our mold to look like the millenium falcon. Using the same techniques that previous semesters did, we will be making a mold for it but instead of making separate pieces to make it look like the ufo from “ The day the earth stood still”, we will be making different pieces to make it look like the Millenium falcon. We may end up making the bigger round piece the same way last semester did it, with the adjustments of the fans then bond on the additional pieces to make it look like the Millennium falcon. We will take precautions in order to not make the same mistakes from last semester such as speeding up the process using the lathe machine by taking the right dimensions and also not burning out the mold.

UFO’s PCB:

Overview/Purpose: To create a PCB and a surface mount device used to control the UFO and LED light show.

 

Research on previous semester work:

  • Group got rid of bundle of wires used to distribute the power to the ECS and LED’s
  • Labeling was added to the EagleCAD schematic so that everyone knew which part was which.
  • Copper pad was added around the board
  • Group decided to build a separate custom PCB for the battery protection of the circuit since the lithium polymer did not include a built in protection circuit.
  • They followed a protection circuit that was created by DIY Perks. They incorporated what they learned to their PCB and they combined the components required to protect the light show as well to the PCB.
  • Once silicon was applied to the carbon fiber mold, it took about 18 hours for it to cure.

Mishaps

  • When assembling the PCB the potentiometer was connected incorrectly but was quickly fixed. (Spring 2015)
  • The group wanted to have the Multiwii on top of the PCB with space in between but they did not have enough clearance to connect the Bluetooth module on top of the PCB. To fix this they used 90 degree male headers and then connected to the bluetooth module from the outside. (Spring 2015)
  • The group was missing a crystal oscillator. To fix this, they took another one and soldered it to the PCB. Test code worked but the custom code did not work, perhaps because the bluetooth module was syncing to the board properly. (Spring 2015)
  • Lastly they did not give the PCB enough space to distribute all current required to power the UFO. Connectors also broke while assembling it but they used wires to fix it.(Spring 2015)

Proposed Solution for Spring 2016: This semester, we will be ensuring that the PCB has enough space to make sure that current flows through smoothly. We will also be working on Soldering on the components properly. One thing that was notices was that some wires were not soldered on properly, therefore breaking off and possibly not making a proper connection.  We will also be insulating out wire components in order to not have a bundle of wires nested around.

 

Carbon Fiber Body:

Overview/Purpose: To build a carbon fiber body for the UFO using the design from the previous semester.

 

Research on previous semester work:

  • A silicon mold was made from the original 3D printed body and then the carbon fiber pieces were made from the mold.
  • A quarter of a mold was made since it is very expensive to make. apparently it is 25$ for two bottles.
  • 3D printed parts needed to be sanded down since undesired grooves were made while being printed.

Mishaps

Proposed Solution for Spring 2016: Not much modifications will be done to the carbon fiber body. The only improvement we are proposing is to add on a case for the battery since it is unprotected at the moment and want to protect it from getting damaged. Along with making a case we want to add on landing legs to it so the UFO will land safely instead of landing on the battery itself.

  1. Teng, James. “UFO Project Summary.” Arxterra. N.p., n.d. Web. 11 Feb. 2016. <https://www.arxterra.com/ufo-project-summary/>.
  2. Teng, James. “Reaction Wheel Research.” Arxterra. N.p., 26 Oct. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/reaction-wheel-research/>.
  3. Teng, James. “Reaction Wheel Material Trade-off Studies.” Arxterra. N.p., 29 Oct. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/reaction-wheel-material-trade-off-studies/>.
  4. Hatori, Ayaka. “Final Documentation.” Arxterra. N.p., 13 May 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/final-documentation-3/>.
  5. Hatori, Ayaka. “Electric Ducted Fans – Number of Blades TOS.” Arxterra. N.p., 6 May 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/electric-ducted-fans-number-of-blades-tos/>.
  6. Montano, Juan. “Implementing the Air Ducts.” Arxterra. N.p., 20 May 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/implementing-the-air-ducts/>.
  7. Montano, Juan. “Determining the Number of Fans.” Arxterra. N.p., 16 Mar. 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/determining-the-number-of-fans/>.
  8. Huynh, Tien-Phuc. “UFO Shell’s Production.” Arxterra. N.p., 6 Dec. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/ufo-shells-production/>.
  9. Sakurai, Catherine. “UFO Shell Trade off Studies.” Arxterra. N.p., 15 Apr. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/ufo-shell-trade-off-studies/>.
  10. Hatori, Ayaka. “Shell Molding.” Arxterra. N.p., 6 May 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/shell-molding/>.
  11. Hatori, Ayaka. “Completed Project with Progress Update.” Arxterra. N.p., 13 May 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/completed-project-with-progress-update/>.
  12. Vo, Tuan. “Building the UFO 1.02 (Code Name: George Michael).” Arxterra. N.p., 20 May 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/building-the-ufo-1-02-code-name-george-michael/>.
  13. Huynh, Tien-Phuc. N.p., 16 Dec. 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/ufos-printed-circuit-board/>.
  14. Hatori, Ayaka. N.p., 13 May 2015. Web. 11 Feb. 2016. <https://www.arxterra.com/pcb-design-battery-protection-circuit/>.
  15. Winter, Nathan. “Manufacture the Carbon Fiber Body.” Arxterra. N.p., 25 Nov. 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/manufacture-the-carbon-fiber-body/>.

 

4. Electronics and Controls Research:

YAW Control:

Overview/Purpose: Prevent UFO from spinning uncontrollably by stabilizing the yaw rotation.  

 

Yaw Control from previous semester:

  • 3 Possible Ideas:
    • Reaction Wheel spins in opposite direction to cancel out yaw rotation.
    • Attach a 5th fan on the side to counter the rotation caused by the other 4 fans
    • Tilt fans.

 

Mishaps:

  • Several experiments show that the reaction wheel would not work.
  • A 5th fan on the side would disturb the symmetry of the UFO and cause additional problems.

Proposed Solution for Spring 2016:

  • Tilting the EDFs is the easiest way to cancel out the yaw rotation. More experiments will be needed to determine the angles best suited for our UFO.

PID Tuning:

Overview/Purpose: Determine the best coefficient values for our PID controller so that we would achieve the most efficient stabilizing effect.

 

PID tuning from Previous Semester:

  • Used “EZ-GUI Ground Station” app to find P,I,D gains.
  • Strapped UFO to inverted chair for safety and easy tuning process.

 

Mishaps:

  • none

 

Proposed Solution for Spring 2016:

  • Discuss with team if further work is agreed upon.
  • Possibly incorporate other types of controller designs besides PID for more efficiency. ex.LQR

Analog Noise Cancellation:

Overview/Purpose: Use analog components to design a noise cancelling circuit to reduce the noise of the UFO.

 

Analog Noise Cancellation from Previous Semester:

  • Designed a noise cancelling circuit.
  • The circuit receives the input signal through a microphone.
  • Input signal is sent through a non-inverting amplifier to boost the voltage to workable levels.
  • The boosted signal is then sent through an inverting amplifier to shift it 180 degrees.
  • After amplifying and inverting the signal, it is sent to a speaker to produce noise.

 

Mishaps:

  • Theoretically, when this output noise is played alongside the input noise, the 2 should cancel each other out. It did not work as expected.
  • The input noise and the output noise must precisely synchronize in order to cancel out each other. This proved too difficult to achieve.

 

Proposed Solution for Spring 2016:

  • Discuss with team if further work is agreed upon.

Experiment: Battery Discharge Characteristics and Voltage Monitor:

 

Overview/Purpose:

  • Determine how long battery will last while UFO is running at 80% throttle.

 

Battery Discharge Characteristics and Voltage Monitor from previous Semester:

  • Test circuit was designed to read the voltage levels of each cell within the battery.
  • The UFO was then connected to the circuit and turned on at 80% throttle while the voltage levels were being monitored.
  • Data shows that the battery cells reached undesired levels at around 10 minutes.
  • Voltage reader was then constructed as a warning indicator of low battery levels.

 

Mishaps:

  • none.

Proposed Solution for Spring 2016:

  • Discuss with team if further work is agreed upon.
  • Possibly design a safety landing feature, where the UFO will shut off all wireless communication with the remote controller and automatically land when the battery levels are low.

Multiwii ESC and Receiver Connections:

 

Overview/Purpose:

  • Documentation on how to connect the ESC and receiver to the microcontroller.

 

Multiwii ESC and Receiver Connections from previous Semester:

  • Instructional post on which connectors go into which pins of the microcontroller.

 

Mishaps:

  • none.

 

Proposed Solution for Spring 2016:

  • This post will be used as a guideline when installing our ESC’s and receiver.

PCB Design – Battery Protection Circuit:

 

Overview/Purpose:

  • Instructional video on creating a Battery Protection Circuit to prevent over-discharging.

 

Battery Protection Circuit from previous Semester:

  • The LiPo battery in our possession does not have a Protection Circuit.
  • Design of a Battery Protection Circuit shall be included in the PCB.

 

Mishaps:

  • none

 

Proposed Solution for Spring 2016:

  • This post will be used as a guideline to include a Battery Protection Circuit in our own PCB.
  • Possibly add a feature to safely land at low battery levels to prevent UFO from crash landing when the battery shuts off.

PID Control and Tuning:

 

Overview/Purpose:

  • Informative Post on PID Control

 

PID Control and Tuning from previous Semester:

  • Detailed instructions on how to PID tune.
  • Links included for PID controller download for Arduino IDE.
  • Instructions on altering files to be compatible with UFO.

Mishaps:

  • none

 

Proposed Solution for Spring 2016:

  • similar set up will be used for PID tuning.

Trade-Off Study: Battery

 

Overview/Purpose:

  • Comparison of different types of batteries to determine best battery for UFO.

 

Battery Trade-Offs from previous Semester:

  • Used same trade-off study from Spring 2014
  • Turnigy nano-tech A-Spec G2 met all required specifications.

Mishaps:

  • none

 

Proposed Solution for Spring 2016:

  • Create updated chart with more options.

Quadcopter PID Control:

 

Overview/Purpose:

  • Informative post on PID control.

PID Control from previous Semester:

  • A PID controller measures the error between the actual and desired values.
  • It then makes corrections to the system to reduce the error and make the actual value as close to the desired value as possible.
  • The speed and efficiency of the correction is heavily dependant upon the P, I, and D coefficients of the controller.
  • Lists of pro and cons of each coefficient is shown in the post.

 

Mishaps:

  • none.

 

Proposed Solution for Spring 2016:

  • very informative post on PID control.
  • will use for future reference.

Trade-Off Study: Motor Battery Selection

 

Overview/Purpose:

 

  • Comparison of different types of batteries to determine best battery for UFO.

 

 

Battery Trade-Offs from previous Semester:

 

  • Study was done comparing cost, weight, capacity, max discharge rate, max current draw, max flight time, and capacity/weight ratio.

 

  • MaxAmps LiPo was chosen due to the high capacity and cost advantage, as well as the higher current draw than any other options.

 

Mishaps:

  • none

 

Proposed Solution for Spring 2016:

 

  • Create updated chart with more options.

Final Controls Update:

 

Overview/Purpose:

  • Detailed results of Fall 2013 quadcopter. Recommendations for future UFO project members.

 

Final Controls Update from previous Semester:

  • future recommendations:
    • tune PID more accurately
    • prevent yaw rotation
    • tinyduino is hard, use a different microcontroller if possible
      • EDFs provide more thrust than anticipated, so the UFO can support a heavier microcontroller if needed
      • breakout board on tinyduino is 1mm, extremely hard to work with.

 

Mishaps:

  • PID needs better tuning to improve stabilization during hover and turn operations.
  • yaw rotation out of control. design something to counter it.
  • tinyduino is not easy to work with.

 

Proposed Solution for Spring 2016:

  • research more on PID tuning.
  • research angle tilt of fans to counter yaw rotation.
  • new microcontroller if budget allows.

Experiment: Prototype Test

 

Overview/Purpose:

  • Conducted tests to determine whether quadcopter meets requirements and whether updates need to be made to the design.

 

Prototype Test from previous Semester:

  • 3 Tests: Rotation, Lift, Tilt
    • Test A(Rotation) results:  it is noted that the yaw rotation is caused by an increase in acceleration. if the velocity of the fans is slowly increased the rotation will be reduced.
    • Test B(Lift) results: around 36% applied thrust is required to lift the UFO and maintain hover.
    • Test C(Tilt) results: tilting the UFO succeeded but the tilt may not be enough for it to turn in the desired direction.

 

  1. Arechiga, Danny. “YAW Control.” Arxterra. N.p., 12 Dec. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/yaw-control/>.
  2. Arechiga, Danny. “PID Tuning.” Arxterra. N.p., 11 Dec. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/pid-tuning/>.
  3. Arechiga, Danny. “Analog Noise Cancellation.” Arxterra. N.p., 2 Dec. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/analog-noise-cancellation/>.
  4. Arechiga, Danny. “Battery Discharge Characteristics and Voltage Monitor.”Arxterra. N.p., 16 Dec. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/battery-discharge-characteristics-and-voltage-monitor/>.
  5. Arechiga, Danny. “Multiwii ESC and Receiver Connections.” Arxterra. N.p., 26 Oct. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/multiwii-esc-and-receiver-connections/>.
  6. Hatori, Ayaka. “PCB Design – Battery Protection Circuit.” Arxterra. N.p., 13 May 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/pcb-design-battery-protection-circuit/>.
  7. Ceballos, Salvador. “PID Control and Tuning.” Arxterra. N.p., 22 Apr. 2015. Web. 12 Feb. 2016. <https://www.arxterra.com/pid-control-and-tuning/>.
  8. Jackson, Anthony. “Battery.” Arxterra. N.p., 14 Dec. 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/battery/>.
  9. Mohideen, Shamir. “Quad-copter PID Control.” Arxterra. N.p., 13 Dec. 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/quad-copter-pid-control/>.
  10. Rice, Jake. “Motor Battery Selection.” Arxterra. N.p., 16 Mar. 2014. Web. 12 Feb. 2016. <https://www.arxterra.com/motor-battery-selection/>.
  11. Walth, Carlen. “Final Controls Update.” Arxterra. N.p., 18 Dec. 2013. Web. 12 Feb. 2016. <https://www.arxterra.com/final-controls-update/>.
  12. Walth, Carlen. “Prototype Testing Results.” Arxterra. N.p., 21 Dec. 2013. Web. 12 Feb. 2016. <https://www.arxterra.com/prototype-testing-results/>.

 

5. Creativity Assignment:

Random Nouns Generated:

  • Mattress
  • Helium
  • Shell
  • Bacon
  • Spring
  • Ball
  • Fish
  • Vehicle
  • Moon
  • Wing
  • Device
  • Mint
  • Kite
  • Wheel

How do we protect vehicle from crash landing damage/ hurting people?

  • Brainstorm
    • don’t crash
    • fly vehicle in mattress store
    • Slow down vehicle as it reaches certain height or battery voltage lowers
    • Give everyone helmets, protective vests, bubble wrap, safety goggles…
    • Hire professional baseball player to catch aircraft
  • Attribute
    • Create landing system
      • Add springs all over (the simpsons maggie)
      • modifiable landing legs
      • Small helium tanks to inflate balloons
    • Shell Material:
      • Titanium
      • Gold
      • Vibranium (Captain America)
      • Adamantium (Wolverine)
      • Plastic
      • Cotton
      • Duct Tape
  • Lateral thinking
    • Forced
    • Random Noun Generator:
      • Helium, Fish, Exhaust, Bacon, Dodge ball, Mattress, Spring, Shield
    • Create new casing to resemble a beach ball/ Dodge ball
    • Fish tail to control the vehicle.
    • Add Bacon strips for dogs (and hungry bacon lovers )to find in case we lose the vehicle
    • Use turtle shell, for battery protection
    • Attach Pillow as a landing gear
  • Different Point of View:
    • Send it to the moon, there isn’t as much gravity like earth to pull it down.

What can we do to control the Yaw rotation?

  • Brainstorm
    • tilt fans
    • alternate clockwise and counterclockwise fans
    • use reaction wheels
    • add wings
    • Have a volunteer counter rotation by hand
  • Attribute
    • heavier shell might be less prone to rotation
      • might reduce yaw rotation
  • Lateral thinking
    • Forced
      • Use coke and mentos propulsion
  • Diff POV
    • Build it in the future, use anti gravity propulsion
    • Fly the device on it’s side; now the yaw problem is a pitch problem
    • Use AI to stabilize itself
    • Build it in the past with no electronics, attach frame to a kite

Spring 2016 3D SMD: Research Project

/in /by

By: Bao Loc Doan (Project Manager)

Christine Vu (Systems Engineer)

Henry Nguyen (Electronics Engineer)

Nasser Alsharafi (Manufacturing)

Project Manager Research

Bao Loc Doan (Project Manager)

Mission Objective

When humans manually pick and place surface mount components onto a printed circuit board (PCB), there are problems with human accuracy and time efficiency. A pick and place surface mount device (SMD) is an automated device that can populate a printed circuit board (PCB) with surface mount components (resistors, capacitors, and IC chips) by referencing a Gerber file. The SMD pick and place machine will be able to pick the surface mount components up and place the components down at the correct location until the board is finished. The objective of this project is to create a pick and place SMD machine and the customer has expressed the desire to keep the overall budget of the project to be around $600.

Creativity

All creative ideas and brainstorming were done prior to establishing a firm base. You can read about our ideas given below in the link.

https://docs.google.com/presentation/d/1F_2NlVyMoYl47WXqDsclBF27teGJwjQjFWzvZX9yafo/edit?usp=sharing

Level 1 Requirements

To satisfy our gracious and generous customer, a list of requirements that our end product needs to meet were created. These requirements takes into account functionality, appearance, and price.

  1. The pick and place SMD machine shall pick up the component and place down the component with a 0.05 mm error (specification of Madell Corporation Model DP2006-2) .
  2. The pick and place SMD machine shall be able to complete at least one PCB.
  3. Arduino software for the pick and place SMD machine shall accept accurately at least one Gerber file per requirement of the course.
  4. The pick and place SMD machine shall operate automatically after pressing start once.
  5. The pick and place SMD machine shall be able to pick up from 4x 8mm reel feeders and an IC tray.
  6. Total cost of finished project must be under $600.
  7. Deadline to complete the pick and place SMD machine shall be before the end of Spring Semester 2016.

Work Breakdown Structure

The goal is to produce a working prototype by the end of the school semester (approximately 15 weeks). In order to meet that goal, a WBS (Work Breakdown Structure) needed to be created in order to allow group members to focus on their own specific divisions. The following graph is the WBS that I and our system engineer, Christine Vu, developed.

 

Work Breakdown Structure

Figure 1 – Work Breakdown Structure

Product Breakdown Structure

Now that we’ve developed what our WBS is, the next step that we took was developing a PBS (Product Breakdown Structure). The PBS will allows us to map out the key components of our design.

Product Breakdown Structure

Figure 2 – Product Breakdown Structure

Budget

Our preliminary budget ended up being slightly under the budget given by our customer. The bulk of the price (~$300) will be from the XY plotter that will be purchased from Ebay. Outsource labor takes into account the costs that the machinist will charge for their services. This number is merely an estimation and the number was given to me by a connection that I have to a machinist that would be willing to work with us.

Budget

Figure 3 – Estimated Budget

Systems Engineer Research

b345t fr0m th3 345t

Christine Vu (Systems Engineer)

As a systems engineer, one must consider the components that make up the project design to formulate requirements, functionality, and progress.

 

For the pick and place Surface Mount Device (SMD) machine, we had to include both the course’s requirements and requirements that will progress the design. In the requirements section, words like “shall”,  “must”, and “will” are equivalent and are mandatory to move the design forward. Words like “may” are suggestions that are optional to the design. It is also important to note that the table to hold PCB and the X-Y Table is used simultaneously and are equivalent. During the requirement-forming process, Henry Nguyen (Electronics) and I went over subsystem requirements while Bao Loc Doan (Project Manager) and I went over system requirements.

Level 2 System Requirements

Level 1 Requirements (L1):

  1. Pick and place SMD machine shall pick up the component and place down the component with a 0.05 mm error.

Level 2 System Requirement (L2):

L2 -1    SMT component shall have a vibration displacement of less than 0.05 mm from its original spot during the entire operation. This requirement is so that the placement of the SMT components would prevent incrementing error.

   1. The pick and place SMD machine shall be able to complete at least one PCB.

Level 2 System Requirement:

L2 – 2   Noise level of pick and place SMD machine during run-time shall be under 40 dB. This is a requirement so it would not disturb our customer.

  1. Software for pick and place 3D SMD machine must be able to translate maximum PCB size of a 4” x 3.2” Gerber file schematic.

Level 2 System Requirement:

L2 -3    Gerber file shall include at least one 0402 component. This is per requirement of great leader Hill.

  1. Pick and place SMD machine shall operate automatically after pressing start once.

Level 2 System Requirement:

L2 – 4     Pick and place SMD machine shall send zero error feedback.

  1. Pick and place SMD machine shall be able to pick up from 4x 8mm reel feeders and an IC tray.

Level 2 System Requirement:

L2 – 5     Pick and place SMD machine shall be clear of debris during operation, which would be pieces that are not part of the SMT components and are larger than the 402 metric component (0.4 mm x 0.2 mm, or 0.0157” x 0.0079”) and include wires. This requirement is so that when the PCB board is placed on a smooth surface, the application of solder paste will not be interfered.

  1. Cost must be under $600.

Level 2 System Requirement:

L2 – 6     Pick and place SMD machine budget sheet shall be under $600.

  1. Deadline to complete pick and place SMD machine’s final assembly shall be before the end of Spring Semester 2016.

Level 2 System Requirement:

L2 – 7     Pick and place SMD machine assembly schedule shall be submitted before February 11, 2016 at 11:59 PM.

 

Initial System Block Diagram

This block diagram was based on the Arxterra blog posts on RosCo from Fall 2015.It was discovered that the pick and place SMD machine can be operated using stepper motors as found through videos as shown on the MakeBlock X-Y Plotter. Another YouTube channel provided the entire run-through of the pick and place 3D SMD machine assembly, Scientist Razz. References of these videos are shown at the end of this blog post.

System Block Diagram

Figure 1. Initial System Block Diagram will control stepper motors.

 

System Interface Matrix

Pins on motor shield will be determined after further research on the benefits of buying a shield designing one.

AVR Arduino Bluetooth
PD0 (RX) Digital Pin 0 TX
PD1 (TX) Digital Pin 1 RX
PD2 (INT0) Digital Pin 2 Motor Shield
PD3 (INT1) Digital Pin 3 H-Bridge
PD4 Digital Pin 4 H-Bridge
PD5 Digital Pin 5 H-Bridge
PD6 Digital Pin 6 H-Bridge
PD7 Digital Pin 7 3D SMD
PB0 Digital Pin 8 X-Axis Stepper
PB1 Digital Pin 9 Y-Axis Stepper
PB2 Digital Pin 10 Z-Axis Stepper
PB3 Digital Pin 11 A-Axis Stepper
PB4 Digital Pin 12
PB6 Digital Pin 13
PC0 (ADC0) Analog Pin 0 (Digital Pin 14)
PC1 (ADC1) Analog Pin 1 (Digital Pin 15)
PC2 (ADC2) Analog Pin 2 (Digital Pin 16)
PC3 (ADC3) Analog Pin 3 (Digital Pin 17)
PC4 (ADC4) Analog Pin 4 (Digital Pin 18)
PC5 (ADC5) Analog Pin 5 (Digital Pin 19)
PC6 (ADC6) RESET

Figure 2. System Interface Matrix.

Validation Matrix:

Validation Product Activity Objective Method Results
Pick and place SMD Machine (Overall)
Customer will evaluate overall functionality and display of pick and place machine.
1.) Ensure that L2-1 and L2-2 are complied. 2.) Ensure that errors occurred during operation are picked up by machine per requirement L2-4. 3.) Ensure that machine is clean (clear of debris) per requirement L2-5. 3.) Evaluate overall budget costs per L2-6 and L2-24.
 Test — Vibration displacement of SMT component must be measured using precision caliper with +/- 0.002 mm tolerance and presented to customer.
Test — Measurement of noise level may be used by phone application.
Analysis — To evaluate budget costs, documentation of purchased products and an excel sheet that includes all pick and place SMD machine components shall be submitted.
Gerber File
Customer will view specifications on Gerber file.
1.) Ensure L2-3, L2-20, and L2-21 are complied.
 Analysis — Present Gerber file that would be used and include the smallest component 0402.
Analysis — Create software to translate 4″ x 3.2″ Gerber schematic.
Stepper Motor Operation
Customer shall evaluate motor display and software. This is combined because software will control the stepper motors.
1.) Ensure that L2-19, L2-20, and L2-21 are complied.
 Test — Stepper motor temperature may be measured on the outer surface.
Test — Error must be recognized by the software. Errors may be orientation of integrated circuit chips.
3D Axis (X, Y, Z) Control
Customer will evaluate motion of motors.
1.) Ensure that L2-12, L2-13 are complied.
 Test — Submit data of X- and Y-axes presenting a straight movement at an angle of 0 degrees with 2.5 degrees tolerance.
Test — Verification of Z-axes must present a straight movement of 90 +/- 2.5 degrees using data
Nozzle
Customer will evaluate overall functionality of nozzle.
1.) Ensure that L2-14, L2-15, and L2-16 are complied.
 Test — Rotation of nozzle shall be controlled to present the 180 degree rotation.
Test — During vacuum system assembly, allow vacuum to be constantly on to hold the SMT component upwards and record time for 4 seconds.
Belt Pulley Customer will evaluate assembly of pulley. 1.) Ensure that L2-18 is complied. Test — Verification of belt width and pulley wheel width may be measured separately.
X-Y Table/Aluminum Surface
Customer will evaluate assembly of working surface area that is X-Y table/aluminum surface.
1.) Ensure that L2-8, L2-9, L2-10, L2-11, L2-21, L2-22, and L2-23 are complied.
 Test — Measure table with an accurate, precise ruler to determine the dimensions of drilled holes and gap between clamp and PCB.
Test — Table slanting can be checked using a leveler or the pythagorean theorem based on dimensions measured by an accurate, precise ruler.
Wire Connections Customer will evaluate quality of wire assembly. 1.) Ensure that L2-17 is complied. Test — Verify that quality of wire connections are not strained and have slack.

Figure 3. Validation Matrix that covers Level 2 requirements. Deadline requirements were removed.

 

References:

MakeBlock X-Y Plotter:

http://www.makeblock.cc/xy-plotter-robot-kit/

Scientist Razz:

https://www.youtube.com/watch?v=1aL7_8LJ4E8

42BYG Stepper Motor Datasheet:

http://www.micropik.com/PDF/42byg[1].pdf

System Block Diagram & Systems Interface Matrix was based on RosCo’s Fall 2015 Design:

http://arxterra.com/rosco-updated-interface-definition-fall-2015/

Gerber File Processing:

https://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf

 

Electronic Engineer Research

Henry Nguyen (Electronic Engineer)

As an electronics and control engineer, we must consider possible softwares and hardware that help move our 3D SMD design process forward. An electronic engineer is responsible for several sub divisions such as PCB Design, Sensors, Actuators, and Power, and MCU Subsystem and Control Firmware. Due to this project being the first iteration of its kind, a lot of R&D needed to be done. PCB Design will be put on hold until it is required in the design.

PCB Design:

  1. We may need to design a PCB if the motor shield that comes with the X-Y Plotter does not power 4 H-Bridge due to an arduino output current of 40mA/
  2. Working from the interface matrix and block diagram created by our systems engineer (Christine Vu), we are required to design our Printed Circuit Board with maximum dimensions of 4”x3.2”.
  3. Create an electrical schematic in Eagle Cad.
  4. Create a Fritzing Diagram.
  5. Design and test circuit from our breadboard.

Sensors, Actuators, and Power:

  1. Stepper motor will rotate 180 degrees in order to pick up our components and orientate them on our PCB.
  2. Stepper motor are required for our vacuum head to move freely on our XY plotter.
  3. Determine power distribution of pick and place SMD machine.

MCU Subsystem and Control Firmware

  1. Write software that will control the vacuum head on our XY Plotter.
    1. Vacuum head on the A axis must be able to move freely within our X-Y working area of 10”x12”  +/- 2” tolerance.
    2. The actuator will also need another servo that can rotate the nozzle 180°in order to pick up components.
  2. Translate commands into control signals.
  3. Modify Brian Dorey’s software for Pick and Place in C# and use Visual Studio to write the application using  a smoothstepper ethernet board and Mach3.
    1. Based on Brian Dorey’s pick and place SMD, we will be legally using his software programs for our pick and place precision software.
      1. https://github.com/briandorey/pickandplacesoftware
    2. Find Gerber to Eagle translation
      1. http://www.cadsoftusa.com/downloads/file/eagle_pcb_power_tools5_06.exe
  4. Arduino may be used to control the feeder assembly
    1. https://github.com/briandorey/PNPControllerUSB/tree/master/atmel%20code

Subsystem Requirements

Level 1 Requirements (L1)

  1. Pick and Place SMD machine shall pick up the component and place down the component with a 0.05 mm error.

Level 2 Subsystem Requirements (L2 Sub):

Aluminum Table:

L2 – 8     Aluminum table will be 12.2047”x15.3543”(310mmx390mm) +/- 0.1” with small drilled holes in order to attach our clamping system.

L2 – 9     Table to hold PCB must be made of smooth aluminum with a clamping system which will be that holds the PCB with a gap of less than 0.5 mm.

L2 – 10     Table to hold PCB must be leveled at 0 +/- 2.5° with respect to the floor.

L2 – 11    Table to hold PCB shall be elevated to a minimum of 1” +/- 0.5” for solder paste heating.

Motor Movement:

L2 – 12     Motors moving in X-Y axes must be in a straight line at  0 +/- 2.5° with respect to the floor. The 2.5°tolerance is an estimate of human error. The physics of human error was only roughly studied due to the scope of this course.

L2 – 13     Motors moving in the Z-axis shall be moving in a straight line at 90 +/- 2.5° with respect to the floor.

L2 – 14     Motor that rotates the nozzle will be able to rotate 180° +/- 1°tolerance.

L2 – 15     At least one vacuum nozzle/head must be smaller than 0.4 mm x 0.2 mm (0.0157” x 0.0079”) by at least 0.1 mm +/- 0.05 mm. This size comes from the size of the smallest component, 0402 metric.

Vacuum System:

L2 – 16     Suction pressure of vacuum nozzle/head must be able to pick up integrated circuit components for at least 4 seconds.

L2 – 17     Wire connection configurations shall have a minimum bend radius of 11 times its diameter. This requirement is to relieve wire stress at rest and during operation.

L2 – 18     Width of belt to attach on pulley shall be less than 0.5 mm. This would help refrain the belt from slipping.

  1. Pick and place SMD machine shall be able to have a run-time of at least 4 hours.

Level 2 Subsystem Requirement:

L2 – 19     Temperature of stepper motor shall be under 131° +/- 1°Fahrenheit. This requirement is based on the 42BYG stepper motor that was used for the MakeBlock X-Y Plotter.

  1. Software for pick and place 3D SMD machine must be able to translate maximum PCB size of a 4” x 3.2” Gerber file schematic.

Level 2 Subsystem Requirement:

L2 – 20     Software shall translate with zero error.

  1. Pick and place SMD machine shall operate automatically after pressing start once.

Level 2 Subsystem Requirement:

L2 – 21     Software shall be able to recognize and self-correct all mistakes.

  1. Pick and Place SMD machine shall have  a maximum of 4x 8mm reel feeders and an IC tray.

Level 2 Subsystem Requirements:

L2 – 22     X-Y Table must be large enough to hold the standard free Eagle PCB dimensions (4” x 3.2”), with at least 5” around the PCB perimeter. The length of 5 inches is a safe measurement so that the PCB does not slip off during pick up.

L2 – 23     Size of working area shall be within 10”x12” with +/- 2” tolerance. This requirement is based on the X-Y Plotter from MakeBlock that we may be purchasing.

  1. Cost must be under $600.

Level 2 Subsystem Requirement:

L2 – 24     Components of the pick and place SMD machine shall list prices rounded to the nearest $1.

  1. Deadline to complete the pick and place SMD machine final assembly shall be before the end of Spring Semester 2016.

Level 2 Subsystem Requirement:

L2 – 25     X-Y Plotter, pick and place SMD surface, and vacuum system (nozzle and vacuum pump) shall arrive before March 25, 2016.

Plan

I watched several videos on Arduino and understand the general idea about coding in C; however, I am unsure if the application of the Arduino will only be used for our reel dispenser or also be used for our precision software for our 3D SMD project. Until we get our XY Plotter, stepper motors, and design, I will not be able to write any software until we know exactly what goes where. I also understand that Ryland Watts and Nick Lombardo are great sources to learn Arduino and C. When the time comes and my Electronics and Control position is necessary for working with Arduino, I will be sure to contact Ryland, Nick, and other knowledgeable sources. A lot of research was done on the specifications of X-Y plotter and and possible design ideas in order to proceed with our project.

 

Clamping System

Figure 1 – Clamping System

XY plotter robot

Figure 2 – XY Plotter Robot Kit

References:

Brian Dorey’s SMD Project

http://www.briandorey.com/category/DIY-Pick-and-Place

 

Manufacturing

Nasser Alsharafi (Manufacturing)

Vacuum System

The vacuum pump works as follows. Essentially the air compressor or vacuum pump is connected to a one-way check valve. The one way check valve is a standard mechanical device that cost around 12$. The one way check valve is connected to an electric solenoid. The solenoid is controlled via a microcontroller programmed for specific timing intervals. The size of the solenoid hose connection should be ¼”.

The solenoid then connects to the pick up needle that is specified below. The needle needs to be small enough to pick up the smallest SMD part that it can. The tank is not needed however can be useful if it is disconnected or inactive for a period of time.

Vacuum Pump

The vacuum system is currently being researched and optimized. One thought is an electric air compressor, and the other is a 1200CC aquarium pump. The one way check valve, solenoid, computer-programmed microcontroller, are already specified but can be changed as necessary later if the project is altered in the future. The nozzle is being researched. So far specification for a 0.41 by 0.19 nozzle have been found and priced at 30$. The aluminum surface can be custom ordered to any size necessary.

sparkfun vacuum

Figure 1 – Sparkfun Vacuum Pump

This is the Sparkfun Vacuum pump 12V. It cost around $15. It can work under 32° -120° F(0° -50°C). Most people who have used this device praised it for its quality. Most of the projects we researched online used this Vacuum pump for their pick and place projects. The only problem with is device that it might be noisy but since its relatively cheap we can try build a box that can reduce the noise. Also one of the methods that users reduced the noise for this pump is by running at lower voltage for example 8.5 volts, which was still able to lift a whole Bluetooth module. The barb connector is ¼” and should connect to another barb of same dimension.

An objective is that we want to keep the cost as low as we can. Perhaps, we would consider the electrical pumps as first, but if we want to make it cheaper possibly we could take the aquarium air pumps as an option. Aquarium Air pumps need to have the ability to make the tube pressured enough to pick the chips and place them at the board. As an example of an Aquarium Air pump we would consider Aqua Culture with 20 to 60 gallons, and its price is 7.61$. It has the ability to pump 1200 CC per minute. On the other hand, we have the electrical pumps that will be around 59$. Many reviews on the Aquarium Air state it has substituted the expensive electrical pumps very well.

Aquarium Air pump

Figure 2 – Aquarium Air Pump

Nozzle Head

After that we researched the nozzle head. We found multiple ways that people implemented the nozzle head. Our requirements list that our nozzle must be smaller than the smallest 0402 component, which is 0.4 mm x 0.2 mm. we found many nozzles that can work for our project and the following is an example.

Vacuum Nozzle

Figure 3 – Vacuum Nozzle

 

References:

Sparkfun Vacuum Pump:

https://www.sparkfun.com/products/10398

Nozzle Head:

http://www.aliexpress.com/store/product/SMT-MV-0402-NOZZLE/1457082_2050995547.html

Aquarium Air Pump:

http://www.walmart.com/ip/10532634?wmlspartner=wlpa&adid=22222222227001219214&wl0=&wl1=g&wl2=c&wl3=40341924752&wl4=&wl5=pla&wl6=56968315625&veh=sem

 

Spring 2016 RoFi: Research Projects and Creative Exercise

/in /by

Christopher Andelin (Project Manager)

Mario Ramirez (Systems Engineer)

Qui Du (Manufacturing Engineer)

Andrew Laqui (Electronics and Controls Engineer)

Henry Ruff (Electronics and Controls Engineer)

Table of Contents

Project Manager Research

Christopher Andelin (Project Manager)

Source Material

  1. Project Biped, Overview; http://www.projectbiped.com/prototypes/rofi
  2. Micro BiPed Introduction, Mission Objective and Mission Profile; http://arxterra.com/micro-biped-intoduction/
  3. Micro BiPed Requirements; http://arxterra.com/requirements/
  4. Micro BiPed Requirements Level 1 and 2, Cost, and Schedule; https://www.arxterra.com/final-documentation-microbiped/
  5. The Engineering Method; http://web.csulb.edu/~hill/ee400d/Lectures/Week%2002%20Engineering%20Method/b_Engineering%20Method.pdf
  6. Mission Profile and Project Objective; https://www.arxterra.com/fall-2015-microbiped-redefining-mission-objective/
  7. Mission Objective, Mission Profile, Level 1 and Level 2 Requirements, Cost, Schedule; https://www.arxterra.com/wp-content/uploads/2015/05/Spring-2015-%C2%B5BiPed-Perliminary-Design-Document.pdf

Mission Objective and Mission Profile

The Project Objective and Mission Profile is a statements of a problem to be solved.  If along the way the customer changes their minds it is okay to let the customer know that the change is out of scope and there may be an increase in cost of schedule slip.  The Mission Profile confirms that the Engineers design solves the customers’ problem through validation tests.

The Spring 2015 Mission Object biped project does not state a problem to be solved instead explains that the goal is to shrink the design to a micro biped.  The Mission Profile comprises of validation tests that are specific and appear feasible due to the design of the micro biped.

Level 1 program/ project requirements

The requirements of Spring 2015 biped project done correctly

  • requirements are quantitative, verifiable and realizable
  • provided source material
  • moves the design process forward
  • located at the correct level (1- program/project)
  • requirements are separated

Done incorrectly

  • used the word must instead of shall
  • no equations

Costs

  • The predicted cost of Spring’s 2015 biped project was $395.15 and the actual total cost was $277.13 (source 4)
  • Our Preliminary budget is $300.00

Scheduling

The Spring 2015 biped team spent a lot of time on planning, reviewing code, selecting a microcontroller, manufacturing, software and testing. It is advised to prepare for unforeseen circumstances (source 4).

 

Systems Engineer Research

Mario Ramirez (Systems Engineer)

Source Material

1.”Project Biped”, 1/31/2016 http://www.projectbiped.com/prototypes/rofi

2.”Fall 2015 microBiPed Summary”,BiPed, Page 1, 1/31/2016 https://www.arxterra.com/fall-2015-microbiped-summary/

3.” Fall 2015 MicroBiPed Verification and Validation Tests”, BiPed, Page 1, 2/1/2016 https://www.arxterra.com/wp-content/uploads/2015/12/Test-Plans-for-Verification-and-Validation.pdf

4.” Fall 2015 MicroBiPed Center of Mass”, BiPed, Page 1,2/1/2016  https://www.arxterra.com/fall-2015-microbiped-center-of-mass/

5.” Fall 2015 MicroBiPed Stress Analysis”, BiPed, Page1,2/1/2015 https://www.arxterra.com/fall-2015-microbiped-stress-analysis/

6.” Fall 2015 MicroBiPed Wiring Diagram”, BiPed, Page  ,2/1/2016 https://www.arxterra.com/fall-2015-microbiped-wiring-diagram/

7.” Fall 2015 MicroBiPed Center of Mass”, BiPed, Page  ,2/1/2016 https://www.arxterra.com/fall-2015-microbiped-center-of-mass/

  1. “Fall 2015 MicroBiPed Preliminary Project Plan”, Biped Page , 2/8/2016 https://www.arxterra.com/fall-2015-microbiped-preliminary-project-plan/#Requirements_Verification_Level_1_8211_Program_Requirements

 

RoFi is a two legged BiPed robot designed by Jonathan Dowdall.  RoFi should be able to walk on only two feet without falling over, avoid walls as well as other objects.  RoFi should be able to do these operations by communicating with the Arxterra app.

As the system engineer of the RoFi project group I am in charge of assisting with level 2 requirements, the cable tree, box diagrams, intangibles, testing, and verification/validation.  Reviewing Jonathan Dowdall’s website and the BiPed section on the Arxterra blog I have come up with a review of RoFi.

Level 1 requirements for RoFi consist of maintaining balance, be able to detect and adapt to incline or declines, avoid walls and objects using an ultrasonic sensor, and be able to communicate with the Arxterra app.  Most of requirements posted by previous teams were for a microBiPed.  Since we are working with an original size BiPed the level 1 dimension requirements do not apply to us and were omitted.  All these requirements are qualitative in my perspective because they give exact detail on what RoFi must be able to do and also lead to a design and further level 2 requirements.

Level 2 requirements for RoFi specify what is going to be designed in order to achieve the level 1 requirements.  For the level 1 requirement of avoiding walls to be met the level 2 requirement should state what sensor is being used and the reasoning behind it.  Some previous groups state using a ultrasonic range sensor and other groups do not state the sensor at all in their requirements.  For our level 2 requirements to lead to a proper design I think we need to state what sensor we will be using and why we chose that sensor.  Another level 2 requirement obtained from the blogs will be the use of a gyroscope to sense the incline or decline of the surface.  However, some research has lead me to believe that the gyroscope is not the most effective sensor.  Testing an accelerometer and comparing it to a gyroscope might lead to possible solutions.  Other level 2 requirements consist of: usage of Arduino Mega, Bluetooth used to communicate with Arxterra app, and grip pad on the soles of RoFI.  These requirements meet a qualitative and quantitative criteria in order to push the design of the project forward.

Validation/verification go hand in hand with requirements because the validation form goes through the requirements and states if and how those requirements were met.  I think previous teams did a good job with their validation form because I was clearly able to understand what requirements were easy to meet, which were more difficult, and which requirements were not able to be met.

Tests done for the BiPed robots consist of power distribution testing, servo torque testing, limb strain testing, and center of mass testing.  The blogs from previous teams state clearly the experiment they did and the results achieved.  However, not much detail in the process of how the experiment was always given.  I think enough detail should be given so the next engineer could redo the experiment if needed.  I also believe more testing on the ultrasonic sensor should be done.  Previous teams have testing on the connections of the sensor, but I did not see testing on the range of the sensor or if any objects cannot be distinguished by the sensor.

Intangibles are an important task for the systems, missions and tests division of any project.  I read some intangibles within tests of previous teams, but for clarity and future teams I believe a structured table would be beneficial so it is clear what teams in the future need to test for their design.

 

Electronics and Controls Engineer Research

Andrew Laqui (Electronics and Controls Engineer)

Source Material

https://www.arxterra.com/microsegbot-fall-15-final-document/

https://www.arxterra.com/spring-2016-velociraptor-roles-responsibilities/

  1. MicroSegbot Fall 15′ Final Document, Level 2 Requirements #7, February 2, 2016 https://www.arxterra.com/microsegbot-fall-15-final-document/
  2. MicroSegbot Fall 15′ Final Document, Bluetooth Trade-Off Study, February 2, 2016 http://arxterra.com/bluetooth-trade-off-study/
  3. MicroSegbot Fall 15′ Final Document, Microcontroller Trade-Off Study, February 2, 2016 http://arxterra.com/microcontroller-trade-off-study/
  4. Final Documentation MicroBiPed, Requirements level 1 and 2, Level 2 Requirements #1, February 10, 2016 http://arxterra.com/requirements/
  5. Final Documentation MicroBiPed, Requirements level 1 and 2, Level 2 Requirements #9, February 10, 2016 http://arxterra.com/requirements/

The level 2 requirement #7 from the MicroSegbot project from Fall 2015 stated that the robot must utilize a microcontroller that will support each component that is used in accomplishing the program requirements.

  • This requirement was not quantitative, but it was verifiable and realizable. The nature of this requirement was that it could not be quantitative. This requirement was a direct response to the level 1 requirement that stated, “The MicroSegbot will use an android phone/laptop to navigate wirelessly by the customer.” This requirement was appropriately a level 2 requirement because it was a requirement that would directly cover a level 1 requirement. There were no links in the document for this requirement other than a link to the beginning of the design document. This requirement moved the design process forward because it determined how the robot was controlled. There were no equations in this requirement. The language was not in the form of a requirement; the author did not use the word “shall” nor the word “should”.

 

The Bluetooth Trade-Off Study from the MicroSegbot project from Fall 2015 considered the level 2 design requirement #3. The author stated that Bluetooth communication was required because the robot was to be controlled by an android phone.

  • The trade-off study is quantitative because it speaks to the specific values for the specifications of two different Bluetooth devices. The study did not seem to contain any non-essential information. The study clearly expressed why the preferred device was chosen.

 

The Microcontroller Trade-Off Study from the MicroSegbot project from Fall 2015 considered the level 2 design requirement #7.

  • The study was quantitative because it compared 3 different devices based on different numerical values. The study does not contain any non-essential material. It compares nine different specifications that are all relevant to deciding which microcontroller would be preferred.

 

The level 2 requirement #1 from the μBiPed project from spring 2015 stated that the robot will utilize an HC-SR04™ ultrasonic sensor. The reason for this sensor is that it is less susceptible to noise and cost.

  • The requirement was not quantitative, but it was verifiable and realizable. The nature of this requirement is that it cannot be quantitative. It is located in the correct level because it clearly stated which level 1 requirement it was linked to. The requirement also contains a link that goes to the sensor study. This requirement moves the design process forward because the customer specifically wanted the robot to avoid obstacles, and this sensor will allow the robot to do that. No equations are used. The author should use the word ‘shall’ rather than ‘will’ in order to use the proper language for a requirement.

 

The level 2 requirement #9 from the μBiPed project from spring 2015 stated that a Bluetooth IC will be chosen to communicate with the Arxterra™ program. An IC must be used in order to minimize the μBiPed size and mass. The type of Bluetooth IC is HC-06.

  • The requirement was not quantitative, but it was verifiable and realizable. The nature of this requirement is that it also cannot be quantitative. It is located on the correct level, and it clearly stated which level 1 requirement it was linked to. The requirement does not contain any links to any source material. It could use a link to the specs for the IC or a link to a trade-off study as to why that IC was chosen. This requirement moves the design process forward because the customer wanted the robot to be able to be controlled remotely using the Arxterra™ program. No equations were used. The author should use the word ‘shall’ rather than ‘will’ in order to use the proper language for a requirement.

 

Manufacturing Engineer Research

Qui Du (Manufacturing Engineer)

Objective:

As a Manufacturing Engineer, I will be responsible for the PCB layout and assembly. My job is using the Eagle CAD programing to design the PCB (printed circuit board), perform ERC (electrical rule check) and DRC (design rule check), and generate the CAM file and upload to PCB house for fabrication. Beside of this, I also will be responsible for 3D modeling to design all Rofi printed parts by using Solidworks.

Source Materials:

  1. Barajas, Alejandro (Fall 2014).”Biped Final Documentation.” Arxterra Blog Post https://www.arxterra.com/final-documentation/
  2. Geijtenbeek, Thomas. “Flexible Muscle-Based Locomotion for Bipedal Creatures.” YouTube. https://www.youtube.com/watch?v=pgaEE27nsQw
  3. Kiley, Steven. “SolidWorks Intro Tutorial.” YouTube. YouTube, n.d. Web. 11 Feb. 2016.

https://www.youtube.com/watch?v=TvBoZ6kH3Q8

  1. Balagtas, Michael (Fall 2015).”MicroBiPed PCB.” Arxterra Blog Post

https://www.arxterra.com/fall-2015-microbiped-pcb/

  1. Blum, Jeremy. “Tutorial 1 for Eagle: Schematic Design.” YouTube

https://www.youtube.com/watch?v=1AXwjZoyNno

REVIEW OF MATERIALS:

  1. This blog is well organize and useful. I really love the “Ideas and advice for future classes” section because the biped project is hard project that maybe not be done in semesters or even years; It is helpful if a previous semester student document all of the obstacles and suggestions for future semester student to review. From this blog, I learn that getting a prototype for a Rofi before getting parts 3D-printed is very important because prototypes allow the team to see any probable design conflicts that can be corrected before final 3D-prints. This technique could save a lot of money and time. The other great advice that I learn from this blog is try to make a physical layout of how I imagine the board to look. Because even the PCB layout was designed correctly and functionality; in some circumstance, It might not match with pins of components which needed to attached to PCB layout. This issue might take a team a lot of time to solve or even lead the team to redesign a PCB layout; therefore, it is important to make a physical layout of how we imagine the board to look.
  2. As a manufacturing engineering, my main job is to design 3D modeling of a Biped on Solidworks; It is useful for me to visualize the flexible Muscle-Based locomotion for Bipedal creatures. From above video, it shows a control 3D muscle actuation of a biped which helps me to realize that the different dimension of a biped will lead to different types of movement so that I can choose the dimension type of my biped.

This video also shows how to optimize for different target speeds (different dimension of a biped have different target speeds). For example, for a too wide Bipet, we will be faced with an issue of low speed; however, for this type of biped, we will take an advantage of avoiding the biped to fall sideway. In contrast with a too wide Biped, a too tall Biped could achieve a high target speed, but it has an issue with being easy to fall down to all direction. From this information, I realize that the outfit of a biped is very important consideration to design a good Biped which could match with requirement of balancing and achieve a target speed. In other words, in order to design a desirable target speed biped, I really need to design the right outfit for the Biped.

  1. To get ready to handle my jobs position, I do self-training my 3D modeling by watching above training video. This video is well organize, and easy to follow step by step. It helps me to be familiar with Solidworks and future designing of printed parts for the Rofi such as: foot, servo band, servo wrap, or knee frame.
  2. From above blog, the manufacturing engineer had a problem with a free version of EAGLE since it has a limit of 2in x 2 1⁄2in; therefore he/ she did not have the liberty of space to maneuver around the conflicted part. If I am in this situation, I suggest he/ she tries to use a license version of EAGLE from school or try to reorganize the wires and components to make them more space less.
  3. As important as 3D modeling, Eagle CAD is software that I use to build the PCB layout. To get handy with this tool, I also watched some of training tutorials online and followed the instructions to repeat rebuilding it. By following the tutorial, here is a final result.

 

Electronics and Controls Engineer Research

Henry Ruff (Electronics and Controls Engineer)

Source Material

Project Biped

Jonathan Dowdall

  1. ROFI – Project Biped, 2/3/2016, http://www.projectbiped.com/prototypes/rofi
  2. Progress Setbacks, 11/7/2011, http://www.projectbiped.com/updates/blog/progressandasetback
  3. ROTH post mortem, 1/11/2012, http://www.projectbiped.com/updates/blog/rothpostmortem
  4. ROFI parts list, 2/3/2016, https://docs.google.com/spreadsheets/d/1PdzezPRsNnxsz-CfU83IURZGI23ftaexhAVR2sCV_Vs/edit#gid=0

Arxterra

  1. Requirements, 2/8/2016, https://www.arxterra.com/requirements/
  2. Fall 2015 MicroBiped Motion Sensor, 12/7/2015, https://www.arxterra.com/fall-2015-microbiped-motion-sensor/
  3. Fall 2015 MicroBiped Distance Sensor, 11/2/2015, https://www.arxterra.com/fall-2015-microbiped-battery-update/
  4. Fall 2015 MicroBiped Microcontroller, 11/3/2015, https://www.arxterra.com/fall-2015-microbiped-microcontroller/
  5. Fall 2015 MicroBiped Servo, 10/23/2015, https://www.arxterra.com/fall-2015-microbiped-servo/

 

Review of Literature

Project Biped – This documentation on projects ROFI and ROTH provides insight on design complications and specifications necessary for the requirements of building a bipedal robot. These studies elaborated on level-2 design requirements, with each portion working towards furthering the overall design. For more detailed specifications, the ROFI parts list provides exact components used previously, and this is a useful reference point. The ROFI website itself is a more direct resource as compared to the Arxterra posts, as the latter is not specifically for ROFI itself.

 

Arxterra – The Arxterra blog posts presented insight on component options and testing performed by previous, comparable biped projects. Furthermore, they outlined requirements for biped projects that can similarly be applied to the ROFI robot.

 

Requirements – A compilation of understanding of the previous articles, as well as observations and personal commentary on necessary adjustments or changes to the project overall.

  • Autonomous bipedal walking
    • Balanced during each frame of walking movement
      • Fast movement would keep balance, such as with human walking, but this is unfeasible for this project. Instead, slow movement would necessitate being able to have a center of gravity that is balanced during each frame of movement.
    • High torque servos
      • Microcontroller to handle servos
      • Servos cannot be utilized constantly due to risk of overheating
      • Servos should withstand weight of overall project
        • Servo strength/torque can be determined by physics calculations or modeling experimentation
        • If the overall weight can be reduced, then lighter servos can also potentially be used.
      • Able to handle sloped surfaces as well as varying textured surfaces
        • Gyroscope and accelerometer are viable for feedback that can be read and therefore controlled, to be able to make ROFI react in a way that will allow it to balance. Accelerometer is better able to handle inclines, as explained in the source material above.
        • Grip exists on the soles of ROFI’s feet, allowing it to be able to walk on feasible surfaces. Its movement also should raise each foot a high enough distance while remaining flat, to be able to avoid complications that would occur if its feet moved very close to the ground.
      • Pathfinding around obstacles
        • Can utilize ultrasonic or infrared sensors to determine distance and appropriate response, such as stopping at a gap or turning at a wall.
        • Needs a method of turning through bipedal motion
          • Design can be modified or servos used in a way that creates rotational torque to turn the body while still keeping balance
        • Obstacles include objects in the way as well as terrain differences
      • Controlled by Arduino board, with interaction with a mobile phone app.
        • As ROFI is autonomous, the main app interaction will be to turn it on or off.
      • Stabilization if disturbed by an external force from any angle, at any point of ROFI, and at any strength.
        • Accelerometer can be used to be read by ROFI, and then it will perform an appropriate equal force in the opposite direction to be able to balance itself.
        • A force too strong will not allow for ROFI to respond quick enough to balance, so there must be a determined limit as to what ROFI can feasibly respond to.

 

Creativity Exercise

Christopher Andelin (Project Manager)

Mario Ramirez (Systems Engineer)

Qui Du (Manufacturing Engineer)

Andrew Laqui (Electronics and Controls Engineer)

Henry Ruff (Electronics and Controls Engineer)

Problems

  1. The bolts screw directly into the plastic frame causing the bolts to come loose.
  2. Running time is 10 to 15 minutes.
  3. Cables are loose and exposed.
  4. Moving parts can cause harm.

Brainstorming Solutions

  1. Retrofit the broken frame by using SolidWorks 3D modeling.
  2. Screw hardware into rigid material instead of the plastic frame.
  3. Redesign current material by making it lighter ( less power consumption, help the battery last longer)
  4. Use lighter material for Rofi, for example: wood, aluminum, cardboard paper.
  5. Use shorter cables, reroute, and/or use enclosure
  6. Design a material that can be placed around RoFi’s legs in order to cover the moving parts and cables. Pants with pockets can hold various objects.

Lateral Thinking

Forced Relationship:

  1. Cheerios – Honey comb pattern for printed limbs.  This will reduce weight since less material will be used.  However, stress tests would need to be done in order to verify the new design could handle RoFi’s movement.
  2. Volleyball – Use as a protective layer to protect internal components and protect user.  
  3. Baby – Rofi can act as a baby monitor. It will follow the baby around, and if the baby cries, Rofi will notify the parent via cell phone.

Different Point of View

  1. Rofi – “What kind of accessories can I have?”
    • Reprogram RoFi to allow one leg remain bent when attached to a skateboard while the other leg kicks and pushes.
    • RoFi can have an assortment of outfits to customize the appearance.
      1. Dress/Wig
      2. Army Uniform
  2. Customer – “How else can I use RoFi other than just for a toy?
    • Program alarm clock to the phone. When the alarm goes off in the morning, RoFi will walk away, forcing the customer to catch up to RoFi and turn off the alarm.

Experiments

  1. Stress test for frame and hardware.
  2. Test the flexibility of the volleyball  material
  3. Verify that changes do not impede movement
  4. Overall heat of the system needs to be tested to insure that the added material will not cause RoFi’s components to overheat.

Questions

  1. Is there a way to lower costs?
  2. Will shorter cables impede movement?
  3. How will the phone be attached?
  4. Can we remove any unnecessary parts?
  5. Should we color code the wires?
  6. Can we salvage PCB parts?
  7. Can we use a smaller Arduino?
  8. Can we upgrade the power supplies?
  9. Are there any maintenance that needs to be performed?
  10. Does RoFi need to be stored in a particular environment?

SPARCCS Spring 2016: First Blog Post

/in , , /by

By Mikhael Semaan (Project Manager), with contribution from Jeremy Seiden (Mission, Systems, and Test), Chelsea Mediavilla (Electronics and Control), and Eric Hanna (Design and Manufacturing).

We review our roles through Club-provided reference material and through previous semesters’ blog posts. From this review, we formulate preliminary Level 1 Requirements, hint at Level 2 Requirements, and provide ideas for the direction of our project towards achieving the Club’s goals.

Read more

Spring 2016 3-DoT Goliath Research and Intro

/in , , , /by

Ayman Aljohani (Project Manager)

Tae Lee (Mission Systems & Test)

Kevin Moran (Electronics & Controls)

Rickeisha Brown (Manufacturing Division)

Jerry Lui (Manufacturing Division)

By: Ayman Aljohani (Project Manager):

The 3-Dot Goliath is a new project that will be working with a new board referred to as the 3- Dot board.

As a project manager, I will be responsible of my team’s final product, and making sure it meets the customer’s requirements (level 1 requirements) which are:

  • low-cost ( $ 90 total)
  • less 3D- printing time ( 6 hr maximum),small size Goliath look.
  •  successfully compete in a laser-tag  (optical transmission device)battle with  3-DOT Spider project.
  • sensor placed horizontally on the rover with zero degree along x-axis,located at a height of 3 inches above the ground.
  • When getting tagged three times, the rover should be disabled.
  • the rover should be piloted via a live camera view only.
  • looks of the RoSco has to be cool

From researching past projects, we have our preliminary budget as follows:

Tracks and wheels  – $17.33
Motors  – $11.50
Chassis- $5.07
ABS plastic- $ 18 (1 Kg)
PCB  -$10
3DOT board-$30
Periscope- $6.89
Total cost: $ 98.79
I also conduct weekly meetings to followup on weekly actions.
Documentation is very important part of my assignment as PM.
2-minutes video for our project as a marketing tool, is also required from a project manager.

In order to meet those requirements,  I have developed a work breakdown structure (WBS) where the the work is broken down into tasks assigned to each division with a deadline.

A prototype version of the project is schedule to be tested on week 5 of the semester.

A research on sensors in terms of (field of view, cost, safety, and interference from outside source) will be assigned to Systems engineer .Based on the research results, the type of sensor will be determined to be one of the following:

IR – LED – Laser – Ultrasonic

The research should focus on four main aspects:
  1. cost
  2. field of view
  3. safety
  4. interference from another external source i.e lights of the room, distance

 

The research will be joined efforts with our opponent robot team (3DOT Spider).

One important decision should be made as soon as possible is the type of communication devise used in laser-tag battle.

Source materials:

  1. micro rover objective and requirements,April 16,2015 
  2. RoSco budget , October 11, 2015
  3. Rover

By: Tae Lee (Mission Systems & Test) :

Source Material:

  1. Battery Comparison,NiCd vs NiMH vs. LiPo Battery Packs, 12-04-13,https://www.arxterra.com/battery-comparisons/
  2. System and Subsystem Requirements, Level 2 and Level 3 Requirements, 10-31-2013 https://www.arxterra.com/system-and-subsystem-requirements/
  3. I.Y. Laser Tag Electronics, Head, 2003, Sensors, http://www.lasertagparts.com/mtsensors.htm
  4. Project Summary, Major Project Features, 12-20-2013, https://www.arxterra.com/project-summary/
  5. Robot Block Diagram, http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/04%20Robot%20Block%20Diagram.pdf
  6. How to Make a Fritzing Diagram, 12-28-2014, http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/08%20How%20To%20Make%20Fritzing%20Diagram.pdf
  7. What is Arduino?, Fall 2015, http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/02%20Intro%20to%20Arduino.pdf

Introduction

The 3D Dot Rosco is a new project that will require a little bit of research.  We will be working with a new board referred to as the 3D Dot board.

Some of my responsibilities are performing

  • Verification and validation
  • Creating level 1 requirements
  • Creating the product breakdown structure.
  • Able to integrate everything together to create a product that meets the customer’s expectations.
  • Power Distribution
  • Testing of servos, motors, and sensors

From researching past projects I have noticed they used the Arduino board, Arduino motor shield, and a Bluetooth module that will be used to program a rover to do various tasks [7].  However, the new 3D dot board now incorporates all the hardware into a single board that will be used to control and perform various tasks on the rover.  The 3D dot has dimensions 1.38 x 1.73 inches making it portable and convenient when printing 3D parts for the RoSco.  Using the Arduino programming language (C++) we will then code and test the servo, motor, control panel, and the Bluetooth module[7].

Review of Literature:

Trade Off Studies of Batteries Review:

The blog post provided information on the research to determine which types of batteries will be suitable for the rover.

Notes for Requirements:

The research that was conducted on the type of batteries seemed unnecessary.  This section should be replaced with a tradeoff study on the uses of different batteries.  The group provided with informative information on the characteristics of the battery.  However, it is more important to provide calculations to determine which battery will last longer for the rover.  This requirement of comparing batteries does not contribute with moving the design forward.  It would be better to narrow down a few batteries and documenting the amount of current that can be produced by the battery.  Next step will to determine the milliampere-hour by adding up all the currents drained from each device to determine the total current.  By doing this we can than calculate an approximate value of how long the rover will last by multiplying the total current with the desired operation time [1].

Level 2 and Level Requirements Review:

The rover team provided a good understanding of the level 2 requirements before building the product.  They performed research on the terrain for obstacles and the distance that is needed to travel to fulfill the requirement.  This included simple calculations to approximate the distance that was needed to travel.  In addition, provided information and calculation of determining the required speed of .05 m/s. The next requirement was to determine a battery that will be used on the rover to last 20 minutes.  Performing a simple calculation, they were able to determine the type of battery needed (890mAh) [2].

Note on Level 2 Requirements:

A recommendation to improving the blog is to combine the level 2 and level 3 requirements.  An example of this is when they discussed the Power and the Power Storage.  These sections are closely related and should be combined to make it clear to the reader of choosing the battery that will be used on the rover [2].

I agree with most of the level 2 requirements; however, the power storage will be modified because of the various components that will be used on the rover.  The rover will be using a Bluetooth module, 3D Dot Board, laser, laser sensor, and two motors.  This will require different type of battery that will power these components.  In addition, the speed requirement will be changed by the customer needs.

Laser Communication Device:

We need to implement a sensor that is able to receive a certain wavelength from a laser.  Once the laser hits the sensor it will send a signal to an LED or a buzzer to indicate we got hit by the enemy.  The laser and the sensor will be connected to the 3D dot board and controlled by a wireless controller.  This field will be further researched to be implemented on our rover [3].

New Requirements:

  • Battle with spider bot
  • Control methods (ex. Bluetooth, Axterra, or Both)
  • Sound indicator (ex. Detect when hit or firing)
  • Have fun

System Block Diagram:

The systems engineer provided a satisfying block diagram that shows the electrical interface of the rover.  This includes the connections for the motor, illuminator, pan & tilt motor, and other components powered by the battery.  We will be able to apply a similar block diagram with a few changes to help us create the new rover [4].  These changes include the laser, laser sensor, and the 3D Dot board.

By : Kevin Moran (Electronics & Controls): 

Sources material :

Double Gearbox Motor

https://www.tamiyausa.com/items/geniuseries-educational-kits-50/educational-construction-38000/double-gearbox-70168

For more info on batteries

http://batteryuniversity.com/learn/article/understanding_lithium_ion

Level 2 Requirements: (Based on requirement to make a “low budget” and “cool” rover)

  • Motor selection

In this year’s project we will be using the 3DoT board which comes with a motor shield and a voltage booster from 3.5V to 5V to control the motor speed. I will be testing the board to ensure it meets the requirements to power the rover. The motors should not exceed a combined force of 5V since that is the board’s limitations

  • Battery Life

In order to meet the level one requirements for a game of laser tag, the length of the game must be decided in order to ensure the batteries chosen for the task of powering the rover last until the end of the game. The selection of the batteries will depend on their mAh, their discharge rate, and size. Since our rover is the next generation and because of level 1 requirements, we must ensure it fits in the overall design of rover.

  • Laser Tag Game

Level 1 requires that a game of laser tag be played between the Rosco team and the Spider bot. The length of the match is still to be determined. Lasers will not be allowed in this laser tag game. An LED will be used in its place. In order to be able to hit a target, the LED must be focused on the objective.

Rover from previous generations:

In order to build a next generation rover, I read the documentation on previous projects, trying to learn from their successes but also their mistakes. To demonstrate the effectiveness of the 3DoT board, our rover must exceed previous expectations and results. Below are a few of the experiments done by previous groups.

  • Waterproofing Servo Experiment

In order to ensure the survival of the rover through its respective test course, the team needed to waterproof their servos to ensure full functionality in wet conditions, and completion of the required task. They enclosed the PCB in waterproof box. They had to spray the servos with plastic dip and submerged them under water for thirty seconds in order to prove they were safe to work in wet conditions. The only problem I see with this way of waterproofing is in the long run of the project. For our specific project we will not be able to waterproof this way, for we are not using servos. However, since we are using a prototype 3DoT board we need to be extra careful to protect from any outside interference, such as a single drop of water. All of our circuitry must be inside the rover and protected by our 3D printed rover.

  • Field of Vision Experiment

In order to fully simulate a soldier crawling through a barbed wire course, the designed their rover to avoid obstacles, to match the speed of a soldier, and visualize what a soldier sees in the crawling position. They tried to find the information on the internet but were not successful, so they decided to perform an experiment on field of vision. They needed the field of vision of a HTC Evo phone.

  • Power Budget:

The majority of the power was used by 6 different servos and 4 different motors. They needed to know the current the rover uses in order to figure out if their batteries were enough to complete the task. They were given batteries with 700mAH capacity, 7.2V batteries were used on previous semesters. By building their prototype, they were able to determine the exact current their rover would use when it was operational. They discovered that their batteries allowed them to run their rover for 40 minutes. For our project I need to determine how much power the laser will use, and for how long our game of laser tag will last. I need to ensure sufficient battery life for the motors and the laser circuitry. Since it is our first time using the 3DoT board, I will also need to run experiments and seeing how it functions and if it uses up much battery life to function since it’s such a compact design

 

New Ideas to meet level 1 requirements

Since the rover has been done by previous teams before using the Arduino plus a motor shield along with other components, in order to make our project a new generation we must improve on previous models. However, we must be realistic, we will not be reinventing the motor or the batteries used for the rover. Our focus will be to improve on previously known data. We will choose a similar motor and batteries but according to our 3DoT board, to ensure full cooperation amongst the subsystems. Below are some ideas to meet the level 1 requirements

  • Motor
  • We will research if 2 separate motors, or a single double-gearbox motor with individual control for the sides works best with the 3DoT board. The location of where the motor is placed will also play an important role, as it will allow for maximum torque and efficiency
  • Battery Life
  • Since the 3DoT board has a place for a lithium battery, we will research and see if a battery that can fit there can meet all of our requirements. Such as the voltage, the amperage needed during a certain amount of time, and the discharge and charging rates. Since our goal is to reduce costs by reducing the size, it would be ideal to just have 1 set of batteries. We must also figure out a way to charge the battery once it is already in place. I have thought of creating a USB adaptor and placing it on the side of the rover to recharge the batteries as needed. We must also be able to determine the charge of the battery at any given moment.
  • Laser Tag Game
  • In order to ensure a successful game of laser tag, I have suggested adding the “laser” to the pen tilt that will be holding the phone and the periscope. The point of any game is to try and have a good time (usually by winning). If we are able to have the laser point in the direction of the center of the periscope, we can potentially be able to target the other team by moving the pen tilt until their sensors are in our sights. This will meet the level 1 requirements by reducing the amount of single moving parts, and allowing our team a successful game of laser tag.
  • Crazy Idea
  • Since our point is to demonstrate the ability of the 3DoT board to power a rover by itself, I have suggested trying to take that a step further. If we were to be able to have two android devices control the rover simultaneously, our rover will be very successful. Person 1 would control the movements of the rover and speed, while person 2 will be control the pen tilt and trying to hit the laser sensors. Both persons would have access to the camera on their devices.

 

By: Rickeisha Brown (Manufacturing Division): 

Source Material : 

Manufacturing our rover incorporates the actual publishing and printing of the PCB board, soldering IC components and other necessary components to the IC board, along with designing 3D structure components. We will use Eagle Cad to draft our design of circuit boards, create a Gerber file and place an order with a PCB manufacturing company of the Manufacturing Division Manager’s choice. It is vital that we confirm with systems and controls a final PCB board design before moving forward with Eagle Cad and Gerber files prior to printing. It is our goal to utilize production time effectively for adequate testing time.

As stated, we are responsible for the 3D design of rover components on a computer software that allows us to do so. For the sake of time ease and access, our manufacturing team will use SolidWorks. SolidWorks will allow us to draft all parts required to manufacture our rover including: the chassis, gears, battery holder and shell.

The customer requests that our manufacturing team design a rover which mimics the German Rover Goliath. The German Rover Goliath has a distinct height and length ratio, such as 1:3. However, the most recent rover designs are replicas of Mars Rover and/or NASA’s Curiosity Rover, which have a height/length ratio of 3:1. Goliaths requirements:

  • Lower Cost (comparison to recent RoSco specs)
  • Minimizing use of 3D-printing
  • Smaller/Compact design
  • Smaller PCB
  • 3D Printing Time: 6 hrs.
    • Chassis
      • Dimensions: 7.69×4.69×3.19
    • Miscellaneous bolts (prints provided by Division Manager: Kevin L.)
  • Goliath Replica
    • Tracks & wheel design
    • Chassis-body structure includes phone, PCB & 3 Dot wiring components
    • One level structure: no neck attached to pen tilt
    • Pen Tilt replaced Periscope
    • Range of view: Dependent on periscope specs-90 degree angle turns

Estimated total weight of Goliath Rover: 1.88-2.00 lbs

The manufacturing division will be responsible for the generation of an Eagle Cad design of the PCB Board, a 3D model of our Rover design using SolidWorks, & the calculation of material and supply needed to build the desired design.

cost estimate new   Goliath

By: Jerry Lui (Manufacturing Division):

Sources materials: 

http://www.toybuilderlabs.com/blogs/news/13053117-filament-volume-and-length

http://www.amazon.com/gp/product/B001VZJDY2?refRID=BT3DN2GHRMF7CEJ988CY&ref_=pd_ybh_a_4

Level 2 subsystem requirement

Chassis material has to be light weight (at least under 1.63lbs)

  • Based on the previous Rosco project, the prime material to use for 3D printing would be ABS.
  • The overall weight must at least be less than the previous teams Rosco chassis weight of 1.63lbs.

The overall cost has to be low (<$80)

  • As per customer suggestions 3D printing should be used. This will cut down on costs.
  • ABS is priced, on average, $20 per kg or $9.07 per pound which can significantly reduce weight compared to PLA.

A game has to be implemented in conjunction with the 3Dot Spider-bot team

  • A led has been suggested to replace the original laser tag system as per customer request.

The Rover must be similar to the german Goliath ROV

  • A prefabricated, commercial track has been proposed to meet the customer objective of having a wheel-tracked system.

rsz_jerry_sketch

Suggestions

  • The body of the old Rosco was fairly bulky which accounted for the majority of the 3.25lbs. A more skeletonized body was proposed to help minimize the weight, speed up printing time, reduce costs, and to make it look aesthetically pleasing as per customer objectives.
  • The reduced weight of the body will also minimize the strain on the motor(s), and tracks thus increasing product longevity.