Spring 2016 Velociraptor: Updated Walking Code #3 (Final)

By: Ashlee Chang (E&C)

Table of Contents

Fulfilling Requirements

Level 1 requirements #4 is stated as follows:

The Velociraptor shall be able to statically walk on all surfaces of the course.

Level 2 requirements #9 is stated as follows:

For the Velociraptor to have the ability to travel up a 6.5-degree incline, an accelerometer shall be implemented to preserve the chassis balance.

Level 2 requirements #10 is stated as follows:

An ultrasonic sensor shall be implemented to the build of the robot to detect obstacles at a range of 20 cm.

Level 2 requirements #11 is stated as follows:

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.

Level 2 requirements #11 is stated as follows:

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.

Level 2 requirements #13 is stated as follows:

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.

These requirements were to be met through C++ coding done through Arduino’s software editor. However, due to the load of work in such tight time constraints, the dynamic walking is incomplete and the incline walking code is unfinished. This will be explained in the concluding remarks.

Final Arduino Folder

Below is a link to the final folder. The entirety of the folder will be broken down in this blog.

arxrobot_firmware FINAL

The original Bluetooth folder passed on utilized 20% of program storage memory. Some unneeded files were removed to conserve memory in the arxrobot_firmware folder: battery_selector and fuel_gauge. This brought down the program memory to 14%.

xxx

Contents of the final velociraptor folder

Look-Up Tables

As explained in the Walking Code #2 blog, servo angles were moved to Flash memory to compensate for the SRAM limitations. The majority of the code is within the cells from 1-170. Originally over 400 cells long, the LUT size has been optimized in trade-off with more if-then statements throughout the code. The LUT size could be shortened further.

aaa

LUT explanation

In cells 1-40 and 81-120 in the excel spreadsheet, the left leg and right leg will take a step. In 41-80 and 121-160, all leg servos are re-initializing as the head and tail sway directions. Lastly, 161-170 are dedicated to pre- and post-turning arrays. The point here is to bring the body closer to the floor so that the velociraptor could grasp the floor more roughly while turning.

Turning

For this blog, the turning code has been implemented. There were several approaches the group has brainstormed to accomplish this. By accident, it was discovered a turning mechanism could be a dragging mechanism where one leg drags behind as the other scoops backwards. It not only proved to be an effective turning method, but also the LUTs used for walking were also capable here. Originally, the turning code for each foot was over 100 cells long and took up 65% of program storage space. By using the same LUT values for static walking and turning, the space was optimized so that only 48% of program storage space was used.

afteroptimization

Program storage space optimization results

Object Detection

The velociraptor head measures 7 inches long. Thus, it was coded so that any object 6+7=13 inches in front of the ultrasonic sensor (half  of a foot from the head) would prohibit the velociraptor from moving forward. The user would have to hit the left or right turn button and go on from there.

Capturex

Upon passage clearance, the forward button will work

Bluetooth

Only four buttons were needed for our project: forward, left/right turn, and dynamic walking. Only the third and fifth element of the package were used in our particular application, which basically dictates which button is pressed. Additional coding was needed to make up for the fact that the Arduino Micro is a Leonardo device. Below shows one of the many modifications made by the S&T division manager to allow our Bluetooth to communicate with the Arxterra app.

serial

Leonardo device modification

Unfinished Business

Time constraints disallowed the further progress of the velociraptor as of the due date. In the LUTS, cells 171-355 (un-optimized size) are dedicated to dynamic walking. It was an in-progress task that was ultimately unsuccessful. A demonstration could be done, but the user would need to hold the robot as it jerks from side to side. It was difficult to code the velociraptor using momentum to keep afloat–finding that sweet spot between balance and imbalance.

The analog accelerometer is capable of sensing incline and using that data to initiate a new walking code that would bring the center of mass towards the head. This would require a completely new walking code with new angles: due to the geometry of the legs, just “re-positioning” all leg servos by the same angle would not in effect allow the velociraptor’s original walking code to walk any longer. A new set of angles need to be discovered where these changing angles would stay perpendicular to the floor. Not to mention, there arises a problem on how the velociraptor will react once it slowly reaches the 7* incline (i.e. before hitting the full 7* incline, the velociraptor already starts tilting backwards).

 

Spring 2016 Pathfinder: Mission Profile and Project Objective Update

By:

Peiyuan Xu (Project Manager)

Table of Contents

Mission Profile Update

The team received the PDR debrief from meeting with the customer, student assistant and the president. One of the comments they had was that the mission profile was unclear. The team then develop a new mission profile which will clarify the confusion of the current one.


mission WiFi Stength

Mission Profile:

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

 

Project Objective Update

The team received new requirements from the customer to design a new Pathfinder Prototype using Rocker Bogie Suspension system. Therefore, the project objective will be changed to accomplish the new requirements

Previous Project Objective:

The spring 2016 Pathfinder Rover was inspired by the design of NASA’s MARs Exploration Rover-“Sojourner”. The purpose of this Rover is to explore the beauty of CSULB campus at night in a self-sufficient way. The Pathfinder is allowed to have the solar panel charging the battery for up to 8 hours during the day time. Then the customer will spend 4 hours at night walking and exploring with the Pathfinder . The customer can use Arxterra control panel on the PC to navigate the Rover by using the cursor to click a point on the map. This generation of Pathfinder Rover is designed to test and implement SLAM (Simultaneous Localization and Mapping) technology for autonomous vehicles.

Current Project Objective:

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

 

 

Spring 2016 A-TeChToP Detailed Mission Profile

By: Cody Dunn (Project Manager)

Overview

This blog post discusses the Mission Profile in more detail and explains the California FITNESSGRAM, a standard test implemented at California public schools in elementary, middle, and high school.

Read more

Spring 2016 3DoT Goliath Final Project Document

 

By: Ayman Aljohani ( Project Manager)

Team members:

Ayman Aljohani (Project Manager)

Tae Lee ( Mission and Systems Engineer)

Kevin Moran (Electronics and control Engineer)

Jerry Lui (Manufacturing Engineer)

Table of Contents

Executive Summary

Objective

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

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

 

Mission Profile

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

 

Mission Objective Update

1

Level 1 Requirements

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

 

Level 2 Requirements

 

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

 

Preliminary Project Design Documentation found here

 

System Design

System Block Diagram

1

 

 

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

 

Experimental Results

Uploading the Firmware onto the 3Dot Board

 

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

 

Troubleshooting the 3DoT  Board

 

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

 

Arxterra Control Panel Test

 

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

 

Bluetooth Module Test

 

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

 

 

3DoT Goliath DC motor trade-off study

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

Motor trade-off study

Laser vs IR LED trade-off study

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

Laser vs IR trade-off study

Progression of laser tag components

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

 

Progression of Laser tag components

Making laser tag possible: The Schmitt trigger

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

Making Laser tag possible

Making laser tag possible: The receiver

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

The Receiver

Making laser tag possible: The emitter

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

The Emitter

Subsystem Design

Interface Definitions

2

3

3

 

 

 

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

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

1

 

CUSTOM PCB DESIGN

3DoT Goliath PCB Testing

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

Custom PCB Design Testing

Making Laser Tag Possible: Extending the IR Range

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

Extending the IR range

The PCB Layout

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

PCB Layout

 

PCB  physical layout

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

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

PCB Physical layout

SMD Soldering

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

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

SMD Soldering

 

3DoT Board Fabrication:

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

3DoT Board Fabrication

 

Hardware Design

 

Goliath Body dimensions

           

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

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

Preliminary Body Dimensions

 

Final body redesign

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

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

Final Body Design

 

SOFTWARE DESIGN

Updated Laser Tag Communication System

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

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

 

1

 

 

 

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

 

Making laser tag possible: Putting it all together

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

Putting it all together

Arxterra Firmware Motor Control Modification Test

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

 

3DoT Goliath IR Emitter/Receiver Code Test

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

 

Verification and Validation Test Plans

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

 

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

 

Project Overview

 

WBS:

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

 

1

 

 

 

 

Burndown Chart:

This is our final Burndown chart

Here is a link to the Burndown chart

1

 

 

Project Schedule:

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

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

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

 

1

Capture

 

 

 

 

Project Budgets:

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

Here is a link to Parts Request Form.

Here is a link to Project Budget.

Mass Budget

Power Budget

 

Concluding Thoughts:

Suggested Practice: 

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

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

Lesson Learned: 

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

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

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

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

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

 

Resources

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

 

Bluetooth Communication: Smart Phone Applications Spring 2016

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

Table of contents:
Introduction
EZ-GUI Ground Station
BTCon2Dron
Conclusion
Additional Resources

Introduction:

Upon setting up the new bluetooth module, the next step was researching application solutions on how to control the quadcopter with bluetooth communication. After researching, we found two android applications: EZ-GUI Ground Station and BTCon2Drone. The reason as to why we had only android applications is because when searching for applications on the apple store, there aren’t many applications that provide bluetooth communication or control for a quadcopter. A possibility as to why this is may be the difference in the process for publishing applications with apple being more strict than android therefore leading to less applications available. Also with apple being very unique and specific in its operating system, less applications are made for iPhones than for Android phones.  

 

EZ-GUI Ground Station
Our first application found was EZ-GUI Ground Station by Eziosoft. This application only provided us data being provided by the MultiWii board components. The data is being displayed on dashboards provided by the application main menu. One of the dashboards was premium and not accessible to use. Screenshots of the menu and dashboard are detailed below:

 

Click here To see an attempt at controlling the UFO quadcopter with the EZ-GUI app

 

BTCon2Drone
Our second application found was BTCon2Drone by PingguSoft. This application also provided data from the MultiWii board with the addition of the target feature of controlling the quadcopter. This application also has various dashboards but we focused on the controller one. With this controller we can control the quadcopter which takes us a step closer at controlling the quadcopter via bluetooth. Screenshots of the menu and dashboard are detailed below:

 

Click here  To see the BTCon2Drone control the UFO quadcopter

 

Conclusion:
Unfortunately this application has a twenty-four hour trial period with the full application costing five dollars. Another setback was during testing, the response time for controlling is slow and isn’t safe for our intentions of controlling during flight. Also when thrust gets to a high level, the bluetooth module starts to fail and disarming is no longer able to be executed. Further test and work is to be done to see if there are  ways to making this more reliable and robust for flight control. Applications are also subject to updates with changes in design and graphics or even being terminated which is why Arxterra application control is the end goal.

 

Additional Resources:
Previous Blog Post: Bluetooth Module Update (Spring 2016)
Previous Blog Post: Learning To Use a Bluetooth Module (Fall 2015)
Previous Blog Post: Bluetooth Interface to Arxterra Application (Spring 2015)
EZ-GUI Ground Station Application Download
BTCon2Drone Application Download

Verification and Validation Matrices Spring 2016 UFO

Posted by: Luis Valdivia (Project Manager)
Written by: Anthony Becerril (Mission, Systems, and Test Engineer)
In order to have mission success we look back to our requirements and seeing the status of meeting them. They have been updated after further discussion and meeting with the customer and their needs. The most up to date requirements are below:

Requirements:

Level 1
No. Requirement
1.1 The UFO Ab-ducted quadcopter must maintain stable flight during operation.
1.2 Project will be completed before the end of Spring 2016 semester.
1.3 Quadcopter must follow rules and regulations to ensure safety for the user(s).
1.4 Overall expenses for this project shall remain below the set budget of the customer.
1.5 Quadcopter will feature a light show with programmable user input.
1.6 The UFO Ab-ducted quadcopter will feature wireless communication for user input.
1.7 UFO Ab-ducted quadcopter will feature a durable shell to protect components.

Table 1.1 List of all Level 1 requirements for UFO Spring 2016

Level 2
No. Requirement
2.1.1 The UFO Ab-ducted quadcopter will counter the undesired Electric Ducted Fan (EDF) torque to maintain stable flight.
2.1.2 The UFO Ab-ducted quadcopter will complete the following flight course: successfully fly around a tree at the nearby park across from Whaley Park, Long Beach, California
2.3.1 The UFO Ab-ducted quadcopter will comply by the rules and regulations of the Federal Aviation Administration (FAA), Unmanned Aircraft Systems (UAS), and California State University, Long Beach’s College of Engineering (CSULB COE) flying policies.
2.4.1 Total overall expenses for the UFO Ab-ducted quadcopter project will be lower than $300.00 USD.
2.5.1 A custom lightshow will be made available through use of a NeoPixel and programmable via the Arxterra Application.
2.6.1 Wireless communication will operate using Radio Controlled (RC) communication to control the UFO Ab-ducted quadcopter’s vertical motion.
2.6.2 Wireless communication will operate using Bluetooth communication to control the UFO Ab-ducted quadcopter’s vertical motion.
2.7.1 The UFO Ab-ducted quadcopter’s protective shell will be manufactured of lexan plastic utilizing the vacuum form molding method.
2.7.2 A newly made Printed Circuit Board (PCB) will be manufactured to secure connectivity.

Table 1.2 List of all Level 2 requirements for UFO Spring 2016

These requirements are then broken down into Verification and Validation matrices. Our verification matrix follows through with all our requirements and properly tests all the work being done on the project by our team. There is a shall statement tied with a verification method to get results that lead to a pass or fail of the requirement. As for validation, this matrix is to be used during the final demonstration where the customer will assess the project status through the listed validation statements. Not including the validation matrix, all requirements in the verification matrix will also be followed up with a blog post for each listed item to details the results and conclude whether it passes or fails.
Verification Matrix:

 

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

Table 1.3  Verification Matrix for UFO Spring 2016

 

Validation Matrix:

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

Table 1.4 Validation Matrix for UFO Spring 2016

Spring 2016 A-TeChToP Final Hardware Design

By: Mimy Ho (Manufacturing Engineer)

Introduction

Up to this point, we have the 3D printed case, completed and working PCB, and the battery that we finalized that we use for the Central Sensor Suite.  So, we are moving forward to the next step of the project is to assemble our final product. This blog post will explain in detail how the material is chosen for the strap, what kind of wires will be used and how to attach the sensors to the strap.

Read more

Spring 2016 A-TeChToP Seizure Detection Methodology

By: Rose Leidenfrost (Electronics Engineer)

Overview

This post covers the methodology, hardware, software of the seizure detection circuit using the Arduino Pro Mini.

Read more

Spring 2016 AdBot Software Design

By Don T. (Mission, Systems, and Test)
Dang Le (Project Manager)

The software block diagram shows the order that the firmware handles data and calls main functions.

Software Block Diagram

Figure 1 Software Block Diagram

Software/Firmware Design Details

In the arxrobot_firmware tab, edit just #define project TRUE. The loop() function basically calls commandDecoder(). The command tab is where the commandDecoder() function is written. It checks a command packet (several bytes of information from the Arxterra app for each kind of AdBot activity) if it is correct. It usually is; Editing the firmware does not require using CoolTerm and finding LRC byte. When the packet passes this decode checkpoint, the commandHandler() is called. This function determines what kind of operation the packet does. The packet could be for controlling a motor or moving a servo. Scroll down in the pinouts_robot tab and a list of robot operations are shown. Next to each operation is a hex value, which is equivalent to the packet’s third byte, which usually is thought of as data[2]. When the firmware is loaded onto the Arduino Uno, and the Arxterra app sends a packet to the Arduino Uno, the firmware looks at data[2], looks up the operation name in the pinouts tab, and finds in the command tab what function the operation name calls. These functions for example are move_TB6612FNG() and move_servo() and they are located in any of the available tabs. Arduino scripts that are moved to subfolders within the arxrobot_firmware folder are no longer part of the firmware code and will not load onto the Arduino Uno or show up when the arxrobot_firmware scripts open. Note: Arduino understands the compound addition operator “A += B” as a shortcut of writing, A = A + B.

AdBot Pinouts

The AdB1 tab contains functions to run the DC drive motors. The pinout connections the Arduino recognizes is listed below.

Motor Front Left

const int aIn1 = 2;
const int aIn2 = 4;
const int aPWM = 3;

Motor Front Right

const int bIn1 = 7;
const int bIn2 = 6;
const int bPWM = 5;

Motor Back Left

const int cIn1 = 8;
const int cIn2 = 9;
const int cPWM = 10;

Motor Back Right

const int dIn1 = 13;
const int dIn2 = 12;
const int dPWM = 11;

Servo

const int SERVO_1 = A0;

move_TB6612FNG and run_TB6612FNG functions

An L298 half bridges has two channels to control two motors separately. With each channel, Arduino connects to a first input pin (C), a second input pin (D), and an enable pin (Ven). When the enable pin is written to low, the corresponding motor is free running. When the enable pin is written to high, the motor can move forward, move backwards, or stop.

 L298N

Resource Files

The software block diagram is created using the full version of Shapes.

Link 1 Software Block Diagram.shapesdoc

Link 2 RoSco Arduino Sketches

Link 3 AdBot Arduino firmware

Spring 2016 A-TeChToP Updated Level 1 and 2 Requirements

By: Cody Dunn (Project Manager)

Omar Rojas (Systems Engineer, Central Sensor Suite)

Robin Yancey (Systems Engineer, Seizure Watch)

Introduction

The A-TeChToP project was ultimately split into two different projects for manageability. Therefore, it was important to create requirements for both the Central Sensor Suite and the Seizure Watch. The Level 1 and Level 2 requirements are outlined in this post.

Read more