Preliminary Project Plan

By Martin Diaz (Project Manager)

Adan Rodriguez (Mission System and Test)

Moses Holley ( Electronics and Control)

John Her (Manufacturing)

Edgardo Villalobos (Solar Manufacturing)

 

WBS

By Martin Diaz (PM),

Adan Rodriguez(Mission,Systems)

 

The work breakdown structure organizes the work needed to complete the project by putting task under each engineer. For our WBS the work of the system engineer was organized into 3 blocks, System Design, Software, and system tests. The work of the ENC engineer was organized into 4 blocks, Electronic Design, Research/Experiments, Microcontroller and PCB, and finally MCU Subsystem and control. The work of the Manufacturing engineer was broken down into  5 blocks, Mechanical Design, Research, 3D simulations, and manufacturing parts and assemblies, and assemble Mini-Pathfinder.

 

Schedule

By Martin Diaz (PM)

The project schedule was created by using Project Libre. Each Task in the WBS was put as task into Project Libre and then the start and end dates were assigned. When a task depended on a other task to be finished first dependencies were assigned. This can be done by clicking and dragging arrows to other boxes. The program will automatically adjust the task.

Burndown

By Martin Diaz (PM)

The Burndown is a chart that shows how much work is left to complete the project vs time.  The Burndown was calculated by moving the task in the schedule to columns in excel and then assigning the percent completion for each task. The ideal percent completion and real percent completion were then plotted vs time.

Power Allocation

By Adan Rodriguez (Mission and Systems)

John Her (Manufacturing)

Moses Holley (ENC)

Edgardo Villalobos (Solar-Manufacturing)

 

The power rating for all of the components on the Power Allocation Report list were calculated using specification sheets of corresponding components. We approximated our mission duration to be 1 hour (one fourth the duration of the Pathfinder’s mission due to our rover being one fourth scale in size). Using the specification sheets to find current ratings of the components, we multiplied the current ratings by one hour to calculate power ratings in milliamp-hours. For the motor drivers, we looked at the power consumption of the IC and divided the operating voltage to get the current draw (0.78W/6V=130mA). The I2C I/O Expander is rated for output of 25 milliamps per pin and we will be utilizing 6 pins implying a total power consumption of 150 milliamp-hours. The Project Power Allocation was set to be slightly higher than the total Expected Power. Note that the Project’s Power Allocation value was used to aid in determining which battery to choose for our mission.

Mass Allocation

By Adan Rodriguez (Mission and Systems)

John Her (Manufacturing)

Moses Holley (ENC)

Edgardo Villalobos (Solar-Manufacturing)

 

Estimates of the 3Dot Board and Custom SMD Board were based off the fact that they are similar in size to the Raspberry-Pi Board (31 millimeters x 66 millimeters). The chassis, solar panel and suspension system were weighed with a scale. Corresponding Sources of expected weights is provided under the Source column. The Project Mass Allocation was set to be slightly higher than the total Expected Weight.

Cost Allocation

By Adan Rodriguez (Mission and Systems)

John Her (Manufacturing)

Moses Holley (ENC)

Edgardo Villalobos (Solar-Manufacturing)

 

The current battery that we intend to buy may be switched out for a different battery after the Mini Pathfinder is built and tested for its power efficiency. About one third of the products that will make up the Mini Pathfinder will be free of charge due to our team members already possessing certain products. Corresponding sources of expected pricing is provided under the Source column. Because the Mini Pathfinder didn’t have a cost requirement the Project Cost Allocation was set to be slightly higher than the total Expected Cost.

Fall 2016 Solar Panels: The Solar Panel Sandwich (the “Encapsulation”)

By Ridwan Maassarani (Design and Manufacturing)

Approved by Inna Echual (Project Manager)

Introduction

In order to secure the cells onto the panel, one must consider the way of “sandwiching” the cells onto place. A rubber substrate was used for insulating the solar cells from the aluminum sheet. Here, I will review the “sandwich” method of encapsulation.

PV Back Sheet [1]

The first substrate considered was PV Back Sheet, which can be bought from aliexpress. This could reduce the thickness of the overall layers and, as explained by Dunmore, a supplier of solar panel material, “the PV back sheet is a photovoltaic laminate that protects the PV module from UV, moisture and weather while acting as an electrical insulator. DUN-SOLAR™ PV back sheets are available in a variety of constructions for both traditional rigid PV modules, like the one shown above, as well as thin film PV modules and solar power concentrators.”

EVA Layer [1][2]

Next, there’s the EVA layer, and according to Dunmore is a “thermoplastic containing ethylene vinyl acetate which is used to encapsulate the photovoltaic cells.” EVA encapsulation might not be the way to go since it needs to be heated which renders the cells inaccessible. And the cells need to be serviceable as part of our project requirement. For our panels, I took a couple of sticker paper and laser cut individual square cut outs to place each cells in its cavity and then when the acrylic is attached, there would be not visual gap between the cells and the acrylic. This did not work since I did not make my sticker paper thick enough. I modeled the shape I needed using Solidworks to ensure every cell in our current design had a cavity to sit in. Then I generated the dxf file that would then be used by the laser machine to cut the sticker paper, as shown in Figure 1.

sticker

Figure 1: Sticker Paper

Then comes the EPE insulations which is an extra layer of insulation, protecting the PV cells from being damaged from additional voltage seeping into the cells and damaging them.

Finally, there’s glass, which was substituted with acrylic in our final product which based on a PDF document written by Arkema, a leading specialty chemicals and advanced materials company says that it transmits 92% of the suns light striking it at the perpendicular.

The entire sandwiching process can be seen in Figure 2.

sandwich

Figure 2: Sandwich Process

References

[1] Solar Back Sheet: http://www.dunmore.com/products/solar-back-sheet.html

[2] Eva Film: http://sinovoltaics.com/learning-center/materials/ethylene-vinyl-acetate-eva-film-composition-and-application/

[3] Plexiglass: http://www.plexiglas.com/export/sites/plexiglas/.content/medias/downloads/sheet-docs/plexiglas-optical-and-transmission-characteristics.pdf

2016 Spring: 3DoT David Final Project Blog Post

By 3DoT David team:

Omar Mouline                                 (Project Manager)

Christopher Hirunthanakorn          (Missions, Systems and Test Engineer)

Kent Hayes                                    (Electronics and Control Engineer)

Andrew Saprid                               (Manufacturing and Design Engineer)

Executive sumary

One of the 3Dot David project objectives was to build a small-sized spider bot that can walk using two motors. When the project was assigned to us, we did research on different movement mechanisms in order to choose the one that best suits our requirements. The research results can be found on this blog post: Spider Bot Different Mechanism Research

Project Objectives

The objective of 3DOT David Spider is to use scaled model of the Hexbug prototype to produce a cool project for the DIY community. The preferred method of control is to use Bluetooth communication between the remote-control (Iphone or Android) and the microcontroller on board of the spider The finished product must meet the following Program and Project Requirements:

  • System processing using a microcontroller (either the 3DoT Board or Sparcs Macro.)
  • Total production cost must not exceed $80.00.
  • Short 3D Printing ( Not exceeding 6 hours and less than 2 hours for each single print)
  • Control The Spider Bot from Arxterra app ( Android or Iphone) using bluetooth
  • 3Dot david must be able to perform a safe interactive game with other projects in a specific field and date as Defined in mission profile

Mission Profile

The Mission Profile for the 3DoT projects is to perform robotic combat. With regards to the College of Engineering Health & Safety Policy, the projects must meet the following Requirements:

  • The game will take place in ECS 315 in a 6 x 6 ft. area on the linoleum floor.
  • Go head to head with other robots in an indoor game of IR tag
  • The emitter must hit the detector in a straight line from a maximum distance of 5 ft.
  • Every time a player is “tagged” by the IR tagging system, a sound will go off
  • Delay time after each tag shall be 5 seconds
  • When either robot has been “tagged” 3 times, the bot will shut down, indicating the game is over.
  • The entire game will last from 10-15 mins

Updated requirements:
Program requirement:

  1. As a senior design project for Spring 2016, the project shall be completed by May 13th, 2016 Monday, May 9, 2016 2:45PM – 4:45PM (Final day) on the linoleum floor of ECS315 at CSULB.http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html
  2. As a senior design project for Spring 2016, Documentation of the 3Dot Spider-bot shall be completed by the 25th of April http://web.csulb.edu/~hill/ee400d/Syllabus.pdf

Project Requirement:

  1. The 3DoT David shall be a robot that demonstrates the capability of the new 3DoT micro-controller for DIY hobbyists.
  2. The 3DoT David shall be a low cost project with a total cost that does not exceed $79.95, which includes the cost for 3D printing, PCB, battery, and other components.
  3. To document the difference between development cost and final product cost, the 3DoT spider project must create a Project Budget and a Product Budget.
  4. The 3DoT David shall be controlled by the Arxterra App used on a smartphone.
  5. The 3DoT David shall incorporate 3D printed parts to demonstrate the feasibility of the 3DoT board for 3D printed robots.
  6. The 3DoT David shall have a maximum 3D printing time of six hours for production of parts to ensure the quick production of the robot. Any single print cannot exceed 2 hours.
  7. The 3DoT David shall compete with other robots in a game of tag to demonstrate the functionality of the robot. The basic rules of the game are using an IR emitter to tag the opposing robot, must compete in a 6×6 ft area, have a delay period of 5 seconds after each tag, and be disabled for 10 seconds after three tags.

System requirements:

  1. The 3DoT David shall utilize the HC-06 Bluetooth module on the 3DoT board in order to receive commands from the Arxterra App using a smartphone.
  2. The 3DoT David shall use a single 3.7V Lithium-ion battery or a 3.7V Lithium-ion Polymer (LIPO) battery to provide power for the robot. The 3DoT board will be providing power to all of the peripherals and uses a 3.7 Lithium-ion battery as its power source.
  3. The 3DoT David shall use two micro motors for the movement system of the robot.
  4. The 3DoT David shall use an infrared LED emitter and infrared detector for the tagging system in the game of tag.
  5. The 3DoT David shall be disabled for 10 seconds after being tagged three times to signify the end of a round in the game of tag. This means the robot does not respond to any commands for 10 seconds.
  6. The 3DoT David shall operate for 10 to 15 minutes, which should be equivalent to three rounds of the game of tag.
  7. The 3DoT David shall use a small speaker to produce the buzzing sounds to indicate the end of a round in the game of tag.
  8. The 3DoT David shall use a 3D printed chassis and legs. This follows from the project level requirement about using 3D printed parts.
  9. The 3DoT David shall include a PCB that uses a Schmitt Trigger circuit to convert the analog output from the IR detector into a digital output to be handled by the 3DoT board. It will also have a voltage follower and anti-aliasing filter for the synchronization of the two motors. This PCB shall also provide the connections from the 3DoT board to the peripherals such as the IR emitter, IR detector, and micro motors.

Subsystem requirements:

  1. The micro motors shall operate in between the supply voltage of 3.7V-5.0V, be able to rotate 360 degrees continuously, have a stall current of no more than 250 mA, and cost no more than $10 each in order to stay within our budget.
  2. The 3DoT David shall be made from PLA or ABS filament in order to minimize the mass of the robot and be strong enough to hold its weight.
  3. The IR emitter and IR detector shall be positioned at least 3 inches from the bottom of the 3DoT David.
  4. The maximum distance for the IR detector to detect a direct hit shall be 5 ft. This threshold is for when the IR emitter of the other robot is directly aligned with the IR detector, not when it is at an angle.
  5. The spider-bot shall have six legs to operate its course to battle robots.

Project key features

Design Change

We have been working nine weeks to design the the Hex bug in Solid Work, in week 9 our team with the agreement of the customer decided to Change the design for these reasons:

The hex bug design:

  1. Had a lot of small parts that needed to be printed with precision
  2. It was very complex for a beginner in solid work to design without a professional formation and the right help.
  3. 3D print resource provided couldn’t print our small parts with the precision we needed.
  4. All the part for the design needed to be 3D printed which will be impossible to accomplish with the time restriction given by the costumer.
  5. We couldn’t use any option other than 3D printing to fit our budget.

The geared design:

  1. We were able to be creative and adjust the design to our needs.
  2. The gear movement need some adjustment since the prototype walked only straight. we added a motor to control each side of legs.
  3. By adding the motor we were able to compile the moment of the spider. When we turn off the right motor the spider turn right and vice versa.
  4. Less part to print and they all were able to print with precision
  5. We could of used different method like laser cutting to get some parts but the 3D printing time was enough for our requirements.
  6. The Solid work design level of complexity was little bit higher than the formation and help provided by the division for the manufacturing engineer but not as high as the level of complexity of the Hex bug design.

Tagging System (interactive game)

For the interactive game we had 3 options : Laser tag, IR tag, and Ultrasonic. After doing research on each option, we settled with IR tagging system for its safety. In the pictures below, some arguments about why we choose the IR are shown:

Screen Shot 2016-05-06 at 1.02.16 PM

Motor Control

After assembling the 3DoT David, we found that the motor synchronization is optional. The leg position helped the robot to move forward even if the motors are not in sync. Before that, we looked at different possibilities on how to synchronize the two motors and it is shown on the table below:

Screen Shot 2016-05-06 at 1.05.15 PM

We ended up choosing the Flex resistor. After implementing it to our robot we found that there is a slight improvement when the spider movement was more in sync. However, we decide to remove the flex resistor with the agreement of the customer because of the limited improvement and the limited number of pins available on the 3DoT board.

Innovative Design Solutions

In every step of assembling the 3Dot David, the team discovered issues. By brainstorming ideas, solutions are found and implemented into the design.

Design Evolution

With the solutions found, legs, bottom plate, and top plate are adjusted in Solidworks. By adjusting the parts, the 3Dot David will be able to move freely as it accomplishes its mission.

Design Evolution (for more details click here to go to the blog post) :

Gear Instability

Three tests were made in order to obtain stability for the gears moving the legs as it rotates. The first test was putting screws inside the center hole of the gears, but the screws were heavy affecting the motion of the gear. The second test was implementing white gears into the rapid prototype made of wood. The motors worked perfectly with these gears. However, the gears were too light, which causes concern when inserting the leg on the gear. The issue was solved by implementing extrusions on the testing board in the third test.

Gear Instability (for more details click here to go to the blog post)

Joint Solution

In order for the leg to rotate freely, the joint must be lightweight plastic material. The joint was made in solidworks. The concern about it is that making a connection to secure the joint to the gear. A second solution was made by inserting a tube as a joint. However, there is much labor in sanding the tubes.  A joint solution is found by using one of the parts in the white gear bag for the legs to rotate freely.

Joint Solution (for more details click here to go to the blog post)

System Design

The system design for the 3DoT David is explained in detail in the following blog post. The system block diagram, interface definitions, and system resource reports are all presented there.

System Design (for more details click here to go to the blog post):

If you want to be directed to a specific topic in the system design blog post use the links below:

Trade-off studies

IR Trade-off Study

This study shows off the emitters and detectors relevant to our project according to specifications made by the electronics and control engineer. There is a table with the specs of emitters and a table with specs of detectors.

IR Trade-off Study (for more details click here to go to the blog post)

Servos and motors trade-off study

This trade off study was conducted in order to determine the best way to control our spider’s walking movements. There are brief descriptions of what motors and servos are, and how one may work better than the other for our project.

Servos and Motors Trade-off Study (for more details click here to go to the blog post)

Experimental Results

Leg Movement Angle Study

Calculations are done to find the distance of the final lift of the leg attached to the gear from the surface by using trigonometric equations. The leg must be lifted in order the spider to walk. If the leg is not able to lift, the spider is not going to walk. Thus, a blocker is created to make the leg lift as the gear rotates 360 degrees.

Leg Movement Angle Study (for more details click here to go to the blog post)

Gear Train

The gear train is an important mechanism for the 3Dot David that keeps it moving from place to place. Calculations are done to get the reasonable rotational speed of the gear by finding the gear ratio and using the given rpm of the motor at 120 rpm, or 2 cycles per second with the large gear.

Gear Train (for more details click here to go to the blog post)

Cam Simulation

The first prototype is made with a Cam Simulation simulated in Solidworks. Further details to every part are explained in the  CAM movement system.  However, the design proved to be complex, and it could exceed the 6 hour limit printing time. The CAM simulation had many mates and crashed because of it.

Cam Simulation (for more details click here to go to the blog post)

IR Lens Study

This study was conducted to determine a lens for increasing the range of the infrared emitter to meet the game requirement of 5ft. We will see the various types of lenses as well as calculations for the physics of light through lenses. The conclusion shows what

IR Lens Study (for more details click here to go to the blog post)

Motor Driver Control

This blog post explains how we controlled the motors from the sparkfun Pro Micro using the sparkfun TB6612FNG motor driver. It includes screenshots of the code being used with the sparkfun Pro Micro board to drive PWM signals for how fast the motors should rotate, as well as test functions for turning left, right, and reversing.

Motor Driver Control (for more details click here to go to the blog post)

IR emitter/detector testing

These are the test results of the IR tagging system done by connecting the schmitt trigger, BJT, emitter, and detector circuits. We show how the range is affected as we increase certain resistor values as well as the voltages being read from the output of the schmitt trigger and IR detector.

IR emitter/detector testing (for more details click here to go to the blog post)

3DoT Board motor Current Safety Test

Since there was a change with the mechanical design of our spider, there was the issue of the old motors not being able to rotate the new gears. Therefore we needed to search for motors that were strong enough to turn the gears. The solution to the problem was to use geared motors, which are motors with a gear train that reduces their speed while increasing the torque. However, with this increase in torque, there is also an increase in how much current the motors would demand. We conducted a comprehensive test to show that the current would not exceed 450mA, where the results are stored inside of tables.

3DoT board motor safety test (for more details click here to go to the blog post)

Subsystem design

Interface definitions

Final Interface Definitions 1 Final Interface Definitions 2

This matrix describes how each subsystem will be connected to the main controller (Atmega 32u4) and what those pins are referred to on each respective system. This is covered in more detail in the system design blog post.

System Design (for more details click here to go to the blog post)

Custom PCB Design

The PCB design includes a signal processing circuit, a BJT to drive current to our IR emitter, a speaker, and voltage buffers. Each circuit is thoroughly explained in the PCB design blog post 

PCB Design (for more details click here to go to the blog post)

Hardware Design

The Solidworks simulation folder has all the parts to simulate the 3Dot David. The adjusted parts for the Final David are the parts adjusted to solve issues as the team assembled it during the process.The mechanical design is explained in the link below:

Hardware design (for more details click here to go to the blog post)

The STL files are to be physically printed from Solid Work. The link below contains the zipped STL files:  

Final STL files (click here to access files)

Software Design

The software design for the 3DoT David is explained in detail in this blog post. It goes into depth about the individual modules and what the software has to do.

Software Design  (for more details click here to go to the blog post)

Additionally, the specific changes to the Arxterra firmware as the project progressed are covered in the following blog post. It provides information on the addition and removal of code to accomplish the tasks laid out in the software design blog post.

Arxterra firmware configuration(for more details click here to go to the blog post)

Verification and Validation Documents

In order to prove that the desired product was built properly and achieves its purpose, verification and validation must be done. The verification and validation matrices lists the requirements related to the tests that must be performed and their results. Those documents can be found here.

Verification matrix (for more details click here to go to the blog post)

Validation matrix (for more details click here to go to the blog post)

The verification and validation test plans provide all of the instructions for the tests to be performed and can be found here.

Verification test plan(for more details click here to go to the blog post)

Validation test plan (for more details click here to go to the blog post)

Project final status

The picture below shows The table of task and status of completion. The important tasks were taken from the project schedule presented already on the CDR and PDR, Those tasks were used to build the the project percentage completion graph and burn down graph.

Screen Shot 2016-05-09 at 12.31.34 PM

Completion %

The graph below show the average Vs. the actual completion percentage by week during the 16 weeks of the semester.

Screen Shot 2016-05-09 at 12.16.03 PM

Final burn down

The graph below show the average Vs. the actual task completion graph by week during the 16 weeks of the semester. As asked, when the teem start a task we mark it as 50% completed and when the task is completed we add another 50%.

From the burn down graph we can see that from week 6 to 8 our project was delayed because of issues of the old design. After week 8, we began working on the new design and we are able to recover the lost time.

Screen Shot 2016-05-09 at 12.06.07 PM

Previous Project Blog Posts:

The following Table of Contents blog post was created to organize all of the blog posts for our project and make it easier for future students to access resources related to their role.

All the blog posts made 2016 3DoT David spring semester by department (click here)

Concluding Thought

I found that the project manager position is the most stressful position in the 400D class since our grade is relies on the outcome of the project. But through this post. There were a lot of things that I had to learn on my own and I would have appreciated it if there was some kind of training plan for project managers. Additionally, I would have liked to be able to sit in on the training sessions for the other divisions, so that I could have a better understanding of what they were working on.

Issues encountered :

  • I would advise to choose the right design from the beginning of the semester: our project start was very stressful during the first 8 weeks and that was due to the design that was assigned to us. The mechanism and the shape design was complex for a beginner in solid works specially if they could not get any useful information, which i think it was the division manager part.
  • Improve IR range: It took both teams time to decide what type of tagging system to use between Laser, IR, LED and other than that the we couldn’t find a fast shipping for the lenses which delayed us more. We would have liked more time to test the IR tagging system before the due date
  • Size of the Spider: After searching different kind of gear, we decided to use gears that will give us durability and stability unfortunately they were a little big. If we were able to find smaller gears we would of reduced the size of the spider

If we went back in time, other than applying for a division manager position, i would have chosen to implement the Jerry Mantzel mechanism instead of the Hex Bug mechanism that was provided.

Resources links

  1. Project Video
  2. CDR Powerpoint
  3. PDR Powerpoint
  4. Project Libre File
  5. Verification Matrix
  6. Verification Test Plan
  7. Validation Matrix
  8. Validation Test Plan
  9. SolidWorks Files:
  10. Frizting Files
  11. EagleCAD Files
  12. Arxterra Firmware Code

Spring 2016 3DoT Goliath Final Project Document

 

By: Ayman Aljohani ( Project Manager)

Team members:

Ayman Aljohani (Project Manager)

Tae Lee ( Mission and Systems Engineer)

Kevin Moran (Electronics and control Engineer)

Jerry Lui (Manufacturing Engineer)

Executive Summary

Objective

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

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

 

Mission Profile

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

 

Mission Objective Update

1

Level 1 Requirements

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

 

Level 2 Requirements

 

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

 

Preliminary Project Design Documentation found here

 

System Design

System Block Diagram

1

 

 

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

 

Experimental Results

Uploading the Firmware onto the 3Dot Board

 

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

 

Troubleshooting the 3DoT  Board

 

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

 

Arxterra Control Panel Test

 

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

 

Bluetooth Module Test

 

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

 

 

3DoT Goliath DC motor trade-off study

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

Motor trade-off study

Laser vs IR LED trade-off study

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

Laser vs IR trade-off study

Progression of laser tag components

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

 

Progression of Laser tag components

Making laser tag possible: The Schmitt trigger

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

Making Laser tag possible

Making laser tag possible: The receiver

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

The Receiver

Making laser tag possible: The emitter

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

The Emitter

Subsystem Design

Interface Definitions

2

3

3

 

 

 

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

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

1

 

CUSTOM PCB DESIGN

3DoT Goliath PCB Testing

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

Custom PCB Design Testing

Making Laser Tag Possible: Extending the IR Range

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

Extending the IR range

The PCB Layout

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

PCB Layout

 

PCB  physical layout

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

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

PCB Physical layout

SMD Soldering

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

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

SMD Soldering

 

3DoT Board Fabrication:

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

3DoT Board Fabrication

 

Hardware Design

 

Goliath Body dimensions

           

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

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

Preliminary Body Dimensions

 

Final body redesign

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

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

Final Body Design

 

SOFTWARE DESIGN

Updated Laser Tag Communication System

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

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

 

1

 

 

 

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

 

Making laser tag possible: Putting it all together

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

Putting it all together

Arxterra Firmware Motor Control Modification Test

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

 

3DoT Goliath IR Emitter/Receiver Code Test

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

 

Verification and Validation Test Plans

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

 

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

 

Project Overview

 

WBS:

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

 

1

 

 

 

 

Burndown Chart:

This is our final Burndown chart

Here is a link to the Burndown chart

1

 

 

Project Schedule:

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

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

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

 

1

Capture

 

 

 

 

Project Budgets:

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

Here is a link to Parts Request Form.

Here is a link to Project Budget.

Mass Budget

Power Budget

 

Concluding Thoughts:

Suggested Practice: 

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

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

Lesson Learned: 

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

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

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

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

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

 

Resources

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

 

Spring 2016: 3DoT David Software Design

BY: Christopher Hirunthanakorn (Missions, Systems and Test Engineer)

Introduction:

The purpose of this blog post is to summarize all of the work that has been done for the software design of the 3DoT David and inform the reader of the final state of the software. It will cover the software flow chart to introduce the tasks the software has to accomplish and then explain the different modules in the software block diagram. Finally, a brief overview of how each module works in the final version of the code will be provided.

Related Level 2 Requirement:

  • The 3DoT David shall be controlled by the Arxterra App used on a smartphone.

Software Flow Chart


CDR Software Flow Chart

The software flow chart shown here shows what the modified Arxterra firmware that will be programmed to the 3DoT board will do. The program will start by initializing all pins and variables used such as the pins for the Sparkfun Dual Motor Driver TB6612FNG, the IR emitter, IR detector, and speaker. Next, it will check to see if a command is sent via bluetooth from the ArxRobot App. If a command was sent, the commandDecoder and commandHandler functions will be executed and the action related to the command sent will be done. When no command is detected, the program will check if the IR detector has registered a tag from an opposing robot. If it is tagged, a sound will be made and the tag counter will be incremented. When the tag counter reaches three, a song will play, the robot will be disabled for 10 seconds, and the tag counter will reset before the loop continues. If there was no tag detected, the program will send any telemetry data that is required. Currently, there was no requirement for the 3DoT David to send any telemetry back to the ArxRobot App.

Software Block Diagram

CDR Software Block Diagram(1)(1)

The software block diagram shown here explains what the different modules do and the types of inputs/outputs of each module. The modules are the commandDecoder, commandHandler, Move Robot, Motor Phase Control, IR Emitter On, Tag Tracker, Robot Disabled, and Telemetry.

CommandDecoder Module

For the commandDecoder module, the input is the command data that comes from the ArxRobot App through bluetooth. This data is sent one byte at a time and the commandDecoder module saves this data into an array. Once the entire array is received, this module verifies that all of the data was sent correctly using a state machine and that the command ID matches one of the defined commands. It outputs this array for other modules to use.

CommandHandler Module

For the commandHandler module, the input is the data array containing the command information sent from the ArxRobot App. This module will check the command ID from the array and then execute the corresponding functions for that command. Those functions must be defined individually. If there are any custom commands that need to be added, a corresponding if statement is required to modify the commandHandler module to handle that command ID. There are no outputs from this module.

Move Robot Module

For the Move Robot Module, the input is the command data that comes from the ArxRobot App through bluetooth. This module includes all of the functions required to move the 3DoT David and is only executed when the move command is sent from the app. It uses the functions defined in the sparkfun_TB6612FNG.ino file and a custom function that operates the motors based on the direction of the move command that was sent. The outputs of this module are the control signals for the Sparkfun dual motor driver and the PWM values for the motor speed, which are designated as digital pins PB5, PB6, PC6, PD7, PF5, PF6, and PF7.

Motor Phase Control Module

For the Motor Phase Control module, the inputs are the current outputs from the flexible resistor sensors. This module processes those inputs using the code that was provided by the Electronics & Control Division Manager Jeffery Cool. It will compare the two inputs and determine if one of the motors is moving faster than the other. This works because the two inputs will be equal if the motors are in phase. The module will make the two motors in phase by changing the speed of the motors. The output of this module are the PWM values for the motors.

This module was tested and had a slight improvement to the movement of the 3DoT David but it was determined that it was not necessary. It is not implemented in the final version of the firmware because of the limited number of pins that are readily available on the 3DoT Board.

IR Emitter On Module

For the IR Emitter On module, there are no inputs. It will only be called by the commandHandler module when the correct command is received. The purpose of this module is to send the command signal to turn on the IR emitter and attempt to tag the opposing robot. It is not always on and will only be turned on when the correct command is received. The module outputs the control signal to the digital pin PD1.

Tag Tracker Module

For the Tag Tracker module, the input is the current output from the IR detector. If the signal that is being detected at the digital pin PD0 is low, that means a tag has not been detected. When the signal is high, this module will increment the tag counter which starts at zero. After the tag counter reaches three, this module will call the Robot Disabled module and then reset the tag counter to zero. This module will also create a 5 second delay before it checks the output from the IR detector to prevent consecutive tags. There are no outputs from this module.

Robot Disabled Module

For the Robot Disabled module, there are no inputs. When it is called by the tag tracker module, this module will prevent the robot from responding to any commands for 10 seconds and play a short song to indicate that the 3DoT David is disabled. There are no outputs from this module.

Telemetry Module

For the Telemetry module, the inputs will vary depending on what type of telemetry needs to be sent back to the ArxRobot App. This module will collect the current values from the sensors on the robot and send that information back to the app. It should be called at a maximum frequency of 1 Hz in order to prevent data overload. The output of this module will be a data array that is sent via bluetooth. For the 3DoT David, there was no telemetry that was required.

Implementation of modules

For the Move Robot module, the existing code was designed for operating a rover and needed to be modified to fit our robot’s movement system. With the new movement system design, both motors will need to be controlled at the same time in order to move because each motor is driving one set of three legs. Additionally, the smoothest movement of the legs required the PWM value to be set to the maximum of 255. If it was any less, the motion of the 3DoT David would look very slow and feel weird. Because of the way the ArxRobot App is set up, the user has to press and hold the direction button to increase the speed of the motors to move in that direction. The code was changed so that the PWM value would be a constant 255 and that the leg movements would be fluid.

For the IR Emitter On module, it was decided that the IR emitter will be turned on whenever the 3DoT David is moving and is off the rest of the time. This is because the ArxRobot App can only send one command at a time and the alternative method of controlling the IR emitter would be using a slider on the app to turn it on or off. Implementing this in the code was easily done by incorporating the command into section of the commandHandler function that executed the move commands.

For the Tag Tracker and Robot Disabled modules, code was added to the main loop to check the output of the IR detector and if the 3DoT David should be disabled. The code is executed after the commandHandler function is called and checks if the robot has been tagged. If so, a counter would be incremented and if that counter reaches three, the robot will be disabled. When hit, the speaker will make a sound and the robot will not check for tags for 5 seconds. When the robot is disabled, it will not respond to any commands for 10 seconds and play a short song to indicate this change. All of this is done by using a flag variable to keep track of whether or not a tag has occurred. The flag will be cleared after 5 seconds have passed. When this has happened three times, the code will enter a loop that keeps it from responding to commands for 10 seconds.

Additionally, all of the extraneous code that was a part of the latest version of the arxterra firmware was removed. This includes all of the telemetry and sensor definitions that were left over from older projects that are not being used for the 3DoT David. All of the code used for debugging and testing were also removed or commented out to make sure additional processing time was not being used up. Comments were also added to help future students understand how the code functions.

The final version of the Arxterra Firmware (click here)

 

RC Control Spring 2016

Posted by: Luis Valdivia(Project Manager)
Written by: Kevin Nguyen(Electronics and Controls)

 

Table of Contents:
– Introduction
– Transmitter and Receiver
– Setting up the MultiWii
– MultiWii GUI
– Arming and Disarming

 

Introduction:
Being able to use the RC controller early on in this project will be very beneficial since it will make testing safer and more efficient. Since EDF’s spin at very high rpms, it is not a good idea to keep your hands on the quadcopter while testing. The RC controller will allow you to test the quadcopter at a safe distance. An added benefit to using the RC controller is that it doesn’t add that much weight to your system. All that is needed for the quad to communicate with the controller is the receiver. This blog will guide you through setting up RC control.

 

Transmitter and Receiver:
The RC controller that we used is the HK-T4A V2. This comes with a transmitter and a receiver. Most likely, you will be using the same controller as us so they would already be binded, but if not, follow this video to bind your devices. The transmitter will be from the remote controller. It will send a 2.4Ghz signal to the receiver on the MultiWii. The RC signal is much more reliable than bluetooth and is capable of transmitting at much further distances.
The transmitter controls the throttle, yaw, pitch, and roll of the quadcopter. The left joystick controls the throttle and the yaw; Vertical direction controls the throttle, horizontal direction controls the yaw. The right joystick controls the pitch and the roll; Vertical direction controls the pitch, horizontal direction controls the roll.

rc controller

 

Fig 1.1 RC Controller

The receiver is connected to the MultiWii. Each channel on the receiver corresponds to a command on the controller. The transmitter sends out signals in the form of radio waves and the receiver converts those signals to electrical signals for the MultiWii to read. The connections on the receiver must be connected to the appropriate pins on the MultiWii in order to control it properly. Refer to this blogpost for MultiWii connections.

rc receiver

Fig 1.2 HK-T4A Receiver

Setting up the MultiWii:

To set up the MultiWii to be compatible with your quad, you need to download the MultiWii source code here. After getting the source code, go into the config.h file and select the appropriate configurations based on your project. To select an option, simply remove the comments(//).

For our project, we used:
#define QUADX
#define MINTHROTTLE 1150
#define MAXTHROTTLE 2000
#define I2C_SPEED 400000L
#define INTERNAL_I2C_PULLUPS
#define FREEIMUv035_BMP

Copy and paste this anywhere into the config.h file:
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}

Some things to mention are that the minthrottle should be kept as is. The quadcopter needs to be under a certain throttle to arm and if the minthrottle is set too high it won’t reach that arming point. Another thing is that for the board options, the MultiWii isn’t listed there, using FREEIMUv035_BMP would work as well.

MultiWii GUI:
The zip download for the source code included a GUI as well. The gui can be used to change the PID settings and calibrate the sensors. The GUI only monitors the sensors, you can’t control the device through it.

Arming and Disarming:
The most important commands for controlling the quadcopter is arming and disarming. Arming connects transmitter and receiver so that you can begin communication. Disarming disconnects the communication. If it flies out of control during testing, you can disarm to stop the motors from spinning. Typically, to arm you pull the throttle down and yaw to the right. To disarm you pull the throttle down and yaw to the left. This is convenient since you can arm and disarm with one joystick. The arming and disarming commands can be changed in the config.h file.

Works Cited:
https://www.youtube.com/watch?v=JyAyM1f_O3Q
http://www.arxterra.com/multiwii-esc-and-receiver-connections/
http://dl.btc.pl/kamami_wa/hk_27033_2.pdf

 

 

Spring 2016 AdBot Critical Design Review

The Rover should travel on level area, ramp area, and stair ways during the mission test.

Critical Design Review

By Dang Le, Project Manager

  • Dang Le (Project Manager)
  • Don Tran (System Engineer)
  • Muhammad Ali Siddiqui (Electronic Engineer)
  • Muhammad Maqbool (Manufacturing Engineer)

Executive Summary

Program Objective/Mission Profile

Program Objective

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

Mission Profile

The total distance is approximated in 344fts. The perimeter of the grass is 275 ft / 84 m. The north and south sides are leveled. The east side has 9 steps. The west end is a ramp.

Mission-CDR-72dpi

The front of USU building

The Design

The main component in our rover design are including

  • Four drive motors (2 on the front and 2 on the back).
  • One gearbox motor (for the center).
  • Six wheels and tracks.
  • Two arms with supported by horizontal shaft and gear.
  • Pole holder for advertising and smart phone.

Adbotexplosive-72dpi

Project Features

  • Rover with advertising sign will be traveled up stairs and slope area in front of USU building.
  • Rover will be run and return to HKN advertisement booth in a single charge.
  • One shaft  with high torque gear box motor to support the lifting arms weight during the stair climbing.
  • Operator will be controlled remotely using Arxterra application with computer wifi connection.
  • Innovative wheels design to have a better track grip.
  • New aerodynamic body design to reduce weight and wind resistance

Custom PCB Design

Fritzing diagram circuit with three H-bridge and I2C protocol IC to drive five motors with using Arduino and firmware coding.

CDR-Frizing-72dpi

Fritzing Diagram

 

Custom-PCB-72dpi

Breadboard testing transmit and received data with using H-bridge IC circuit and Arduino coding.

 

PCB layout

PCBlayout-CDR-72dpi

 

Hardware Design

By Muhammad Maqbool, Manufacturing Engineer

The body of our AdBot is set to be 12” x 8” x 2”. The Body is made of Aluminum. I got separate sheets of Aluminum each with a thickness of 0.125 inch and I welded them together with the help Ryland Walts. The reason for choosing Aluminum is that for our AdBot we wanted a strong body that would not get damaged if our AdBot hits the stairs or anyone try to kick it.

The body consist of two holes in the back each of a diameter of 0.16 inches, the holes provide a path for the driving motors to directly connect with the wheel. The two holes in the front of the body provides a path for the shaft to pass through and will be connected to the free moving wheels and arms.

The wheels are printed using ABS plastic. ABS plastic is the most cost effective material. Each Wheel has a diameter of 2.5 inches and a thickness of 0.7 inch. The arms of the our AdBot will be of Aluminum as wheel, the arms will be 6” x 1” with a thickness of 0.125 inch. We have two motors in the front of the arm that will be driving the front wheels at all times. I have designed the gear for the shaft and the motor myself. As the motor rotates the gear on it rotates with it hence rotating the gear on the shaft and lifting the arms. I have designed two arm holder myself that will hold the arm on the shaft at all times.

The top of our AdBot is more aerodynamic by adding curves to it so it can go fast. The top is 12” x 8” and will sit on the body and I will screw them both. I will design a pole holder that will hold our pole hence holding our sign.

Adbot-topview-72dpi

top-CDR-72dpi Demension-CDR-72dpi

Software Design

Test code for controlling motors with Arxterra Application

SW-CDR-72dpi

SW-master-Slave-CDR

 

Project Update

By Dang Le, Project Manager

Work Breakdown Structure (WBS)

As a project manager, who created and assigned tasks for each member within the team throughout the project. A work breakdown structure (WBS) that showed each of team member who had responsible for their tasks. There could be a change during the mission task depend who has more free time and ability to take workload from other member. Here is our delegation tasks that showed in display below.

WBS-CDR-72dpi

Budget Report updated

As a Project manager, I have to keep track on our budget to make sure it still within our given budget. The most expense is on prototype component and chassis. Unfortunately, our rover were bigger compare to previous semester, thus we have to look for the difference type of tracks that can support our rover during the mission test course. First, we thought we could use 6V DC motor for our rover ( these motor are free from previous semester), but now due to the rover is too heavy and may not be able to travel on stair ways and long distance, so we may replaced with 12V DC motor for final demo. Our budget report with expected cost right now without five of 12 V DC motors is $220.44.

Cost-report-CDR-72dpi

 

Schedule Updated

Project schedule is the software that used to create a task schedule and plan in this project for a specific date to be completed. As the project moved on, we could see which tasks we were completed or behind the schedule. The schedule showed in green check mark that indicated these tasks were completed. However, the main concern was the PCB schematic and PCB wiring layout. We have built a new schematic, which more complicated than our thought due to more parts on PCB and not enough clearance between one trace to another, thus our team member were having so much trouble when doing the layout. Furthermore, we were down by one of our team member electronic engineer. Thus, we were behind the schedule as our planned. Another issue was main tracks for our rover. The current track we have as the same last semester that was not support enough for our rover during the mission test. We are still looking for the tank track and 12 V DC motor with high torque for our AdBot.

ProjectSchedule1-CDR-72dpi ProjectSchedule2-CDR-72dpi

 

Status and Percent Complete

Here is the status and percent burn down  as we move along until this time. The charts showed that we were behind on software coding, PCB layout, and hardware as well.

PercentcompleteCDR-72dpi BurnDownCDR-72dpi

Project Demonstrations

click the link below to watch the AdBot demonstration

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

 

 

Spring 2016 Additional Fan Bracket Design

Posted by: Luis Valdivia (Project Manager)
Written by: Juan Mendez (Manufacturing Engineer)

Table of Contents:
Introduction
Design
Conclusion

Introduction:
Since weight became an issue with our vehicle, we had to think of an alternative solution to fix the yaw problem. Our alternative solution was to add an additional brushless fan to counter the yaw problem. In order to add on another fan we needed to find a way to mount it on to the current frame. We thought of drilling new holes on to the frame to add on to the bracket, but instead of making new holes, we decided to use the ones that were already on the frame. In order to put the fan between two of the ducted fans, I had to use the holes that were between two of the current metal brackets. I modeled the bracket to be 1.67 by .31 inches as shown in Figure 1 so that they can fit perfectly between two ducted fans.

Figure 1 Demonstrating dimensions of 5th fanbracket

5thfanbracket

Design:

I wanted to make sure that the bracket would enclose the bracket provided by the brushless fan so I made the bracket extend approximately 1.25 inches as shown in Figure 1.
After measuring the bracket that came with with brushless fan, we saw that it was 3.4 by 3.4 mm thick. This is equivalent to .13 inches. In order to make sure that the brushless fan bracket could fit into mine, I made the inner cut of .14 by .14 inches so it can slip in smoothly as shown in Figure 2A. In order to make sure that the 3D printer could print the part without having it warp, I had to make the outer dimensions be .33 by .34 inches thick as shown in Figure 2B. This allowed the part to be printed without any trouble.

Figure 2A and Figure 2B Demonstrating dimensions of bracket design

bracket design

Conclusion:

The result were the parts fabricated shown below in Figure 3 A & B. The brackets were able to mount on smoothly into the brushless fans with no problem. They were then easily mounted on between the ducted fans on the vehicle as seen in Figure 4. Additional brackets were fabricated incase we needed to add a 6th fan to fix the yaw problem.

Figure 3A and Figure 3B alternate angles of 3D printed brackets

printed piece

Figure 4 5th fan attached to 3D printed bracket

attached

2016 Spring 2016: 3DoT David CDR ppt and CDR Debrief

BY: Omar Mouline (Project Manager),

On 04/20/2016 the the professor Gary Hill and with the assistance of the President gave us a debrief on our CDR. in the link blow is the CDR power point that was presented on the 04/06/2016 :

3DoT David CDR

First slide:

Screen Shot 2016-04-25 at 8.58.19 PM

Remark:

Points were deducted For the picture used in the title page. The picture had to be a picture of our design.

Experimental Result

Screen Shot 2016-04-25 at 9.02.17 PM

Problem: 

The RPM calculation did not look right. The values were too large for the gear ratio we are using.

Solution:

The RPM calculation was recalculated and documented in this Blog Post:

  1. Gear Train

Subsystem Design: PCB Schematic

Screen Shot 2016-04-25 at 9.10.11 PM

Problem:

Capacitor value is too big for the PCB. what was the justification for the 2200 uF capacitor?

Solution:

The Electronics engineer worked with the division manager and they are planing to change the capacitor

President Remarks:

Create a training document on bypass capacitor.

Look at similar boards and copy them.

Hardware DesignScreen Shot 2016-04-25 at 9.17.20 PM

Problem:

Worried about the gearing and motor torque.

Solution

We were very precise on the correction of our studies on the subject and we have it all explain on these blog posts:

  1. Servos and Motor Trade-off Study Servos and Motor Trade-off Study
  2. Gear Train

Software design:

Screen Shot 2016-04-25 at 9.23.25 PM

Remark:

Detector code looked weak. This code was used just to test if the IR components functioned. The actual detector code will be developed and tested once the prototype is assembled.

Power report

Screen Shot 2016-04-25 at 9.33.10 PM

Problem:

All values on the power report are under no load conditions. These values will change when the robot is operating.

Solution:

We will get the actual measurement of voltage and current for each component when it is operating.

Project Update

Screen Shot 2016-04-25 at 9.25.58 PM

Problem:

Lot of work were done over spring break, still more problems to solve.

Solution:

For the burndown the 50% for starting a task and 50% to complete the task does not give us an exact ready. The change of project design made us rush the tasks to come back on time. We finished a lot hard task in a very short time, we did our best and we were not on a little bit behind time, but since we were starting all the tasks and accomplished some it showed that we were in a good schedule.

General Remarks

  • Nice project schedule, does not look like on schedule.
    • it is normal since we changed the design.
  • have 3 caps for incoming power
  • Double check if the motors will work with system restrictions.