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

Critical Design Review Debrief Spring 2016 UFO

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

 

This blogpost will cover the debrief to our group after presenting out Critical Design Review. Next to every topic is the grade received along with feedback from our instructor and division managers. Click here to access our Critical Design Review.

Table of contents:
-Title
-Exec. Summary
-System Design
-Experimental Results
-Interface Definition
-Connection Wiring Diagram
-Custom PCB
-Hardware Design
-Software Design
-Verification and Validation
-Project Update
-Demonstration

 

  • Title: 10
    • Well put together

 

 

  • Exec. Summary: 9.13
    • MultiWii versus Arduino when testing?
    • Was the MultiWii going to control servos?
      • Code of MultiWii can be modified to control servos via servo driver
      • Tricky to mess with code, but if confident you can change without problems then go ahead
      • Minimal impact on CPU to avoid problems with MultiWii
      • Concern: no capability indicated on CDR about servo driver being implemented

 

 

  • System Design: 8.4
    • System Block Diagram
      • PCB wasn’t as detailed; could have gotten more details on how PCB is connected with everything

 

 

  • Experimental Results: 8.5
    • Overview slide gave list of tests but with no results; was later presented but a bit unaligned in presenting
    • Current test was done nicely; curve fit was well done
    • Torque test data well presented
    • Curve fitting is an art; don’t let excel do it for you rather find an equation; explain more as to why the curve equation is what it is
    • Intuitively it seems a straight line works; maybe curve fit with 1/x (find evidence behind equation)

 

 

  • Interface Definition: 7.44
    • Missing LED in list of pins

 

 

  • Connection Wiring Diagram:  
    • Missing wire lengths

 

 

  • Custom PCB: 8.81
    • Design should have prototype with servo driver
    • Solid, clean design
    • Need to be able to test ITC

 

 

  • Hardware Design: 7.06
    • Missing calculation regarding cancelling/countering yaw rotation; data was presented but no evidence on what will counter

 

 

  • Software Design: 5.38
    • Missing; no linkage; could have used it during servos
    • Big chunk that wasn’t there
    • Block diagram was not accurate and not overlooked compared to original draft
    • Presentation confusion regarding block diagram
    • Software testing was done via arduino not MultiWii

 

 

  • Verification and Validation: 7.5
    • Having aesthetically friendly shell was a “favorite” (not quantitative)
    • wasn’t sure if there was requirement for lightshow
    • Verification was passed but no data with completed tests
    • Validation looked similar to verification; more into detail on customer want
    • Looks like it might be missing requirements; not sure if it could all be met
    • Some test seemed as if they could have been completed already but wasn’t sure??
    • These matrices will be used for day of final to check off pass or fail; SUBJECT TO CHANGE FOR FINAL
      • Go through matrix, go over each requirement; consider adding these as a column:
        • Functional ~50%
          • Should mainly consists of flight
          • Create functional requirements
        • Nonfunctional ~50%
          • Rather static tests, qualitative
          •  Scrap the light show! He doesn’t care!
          • Requirements overall good

 

  • Project Update: 8.85
    • Looked good! Actually acknowledge being behind schedule
    • Resource Reports
      • Uncertainty 100%?? (resource reports)
      • Power report could use more info on the battery; otherwise fine

 

 

  • Demonstration: 7.39
    • Various videos provided regarding progress
    • Curve fitting wasn’t strong due to excel use

 

 

  • Overall:
    • Degree of difficulty: 1
    • CDR: 7.95

Project Update/Review:

  • As mentioned in CDR, weight is an issue -> tests done to see what weight that can be lifted
    • Videos provided
    • Weight classes:
      • No attachments
      • Legs
      • Legs and servo holds
      • Legs, servo holds, servos
  • Solutions:
    • No attachments and new fans aren’t approved
    • 5th Fan & smaller battery
      • Will 5th fan thrust match yaw rotation?
      • Smaller battery how?
      • Add tail rotor
  • Notes:
    • Weight with no attachments: 1287
    • Calculated possibility: 1300
    • PCB now what? With servos ditched and light show not cared for, no need for PCB
    • Save mass on:
      • PCB
      • Shell
  • DO:
    • Test old fans VS new fans
    • Tail rotor
    • Smaller battery
    • GET IT TO FLY! THAT’S IT! STABLE FLIGHT AND THAT’S IT
      • Credit only comes from flight. That is it.

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
https://www.arxterra.com/multiwii-esc-and-receiver-connections/
http://dl.btc.pl/kamami_wa/hk_27033_2.pdf

 

 

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

Spring 2016 re-design of structure rods

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

Table of contents
Introduction
Approach
Re-design

Introduction

Space and weight was an issue with the vehicle. Since we were going to add a buck converter to control the brushless fans we had to reduce the weight of our current vehicle in order to compensate for the weight added on by the brushless fans and buck converter. We also noticed, some of the rod ends were broken from over tightening the set screws to the brackets (from previous semesters). Figure below demonstrates the damaged rods. 

Figure 1.1 Demonstration of damaged Carbon Fiber rods

20160501_135111

Approach

To reduce the weight, I redesigned the rods that were hold the ducted fans together and made them smaller in length. There were three rods that held the fans together, One of which was 6 inches long and the other two were 2.75 inches long. This was a simple modification. I made the rods to be .46 inches in diameter which was the same size as the previous rods. Since we wanted the rods to be shorter, I made them 1.7 inches long. By doing so, we were able to get rid of the long rod and have four individual rods for each ducted fan. We were able to reduce the weight from 5 grams to 3 grams. 

Re-design

Figure 1.2 Design of rod next to 3d print of rod

rodcomparison

Figure 1.3 New position of battery due to 3d printed rod

We were also able to remove the middle part of the frame which gave us more space to work with. Now we have no worries about the battery hitting the floor or any surface that the vehicle is resting on.

batterycomparison

Spring 2016 Trade off study: 5 Blade EDF vs 10 Blade EDF

Written by: Luis Valdivia (Project Manager)
Posted by: Luis Valdivia (Project Manager)

Table of contents
Introduction
Results
Conclusion

 

Introduction:
Due to weight concerns, the spring 2016 UFO Ab-ducted group was advised [by the instructor] to perform trade off studies between 5 blade Electric Ducted Fans (EDFs) and 10 blade Electric Ducted Fans (EDFs). This study will give our group and understanding the benefit of either configuration. Ideally, the 5 blade fans would be lighter than the 10 blade fans. If we are able to deliver the same amount of thrust with a lighter fan, our vehicle would be able to achieve liftoff with the same sized EDFs.

 

Results:
Weighing both EDFs, we measured the 5 blade EDF at 93g and the 10 blade EDF at 100g.

Figure 1.1 Weight of 5 blade EDF (in grams)

5bladeweight

Figure 1.2  Weight of 10 blade EDF (in grams)

10bladeweight

Table 1.1 results from different thrust values for 5 blades edfs and 10 blade edfs

Throttle 5 blade EDF (g) 10 blade EDF (g) Allowed weight of vehicle with 5 blades in (g) Allowed weight of vehicle with 5 blades in (g)
off 0 0 0 0
min 7 7 14 14
mid 140 235 280 470
max 530 650 1060 1300

Figure 1.3 Throttle position at minimum (after multiwii has been armed)

zerothrust

Figure 1.4 Throttle position at middle

midthrust

Figure 1.5 Throttle position at maximum

fullthrottle

Conclusion:

Measuring the thrust with the setup in figure 1.6 and figure 1.7 , we concluded the 10 blade fans produced more thrust with no significant change in weight or size to the 5 blade competitors. For our application, it seems like the 10 blade fans will bring in slightly more weight that won’t contribute to much since they produce almost twice the amount of thrust the the 5 blade fans.

Figure 1.6  Set up used to measure thrust (in grams) of 5 blades

5bladethrustweight

Figure 1.7 Set up used to measure thrust (in grams) of 10 blades

10bladethrustweight

Design(s) of 3D printed attachments Spring 2016

Posted by: Luis Valdivia (Project Manager)

Written by: Juan Mendez (Manufacturing Engineer)

Our vehicle has a yaw problem which causes it to be unstable. After brainstorming a few ideas, we have decided to attack this problem by adding on attachments in order to perform thrust vector control using servos and also be adding flaps to redirect the direction of the thrust.

Before making our design, there were several parameters that we had to take into account such as ensuring that the attachments fit the ducted fans. For one we needed to keep the attachments as light as possible to not add on too much weight on to the vehicle however we could not for too light for several reasons. The parts that were 3D printed needed to be no less than 2 mm thick. The reason for this is because the 3D printer that we were using could not print any less than that. We first had a prototype printed to see if we could use a 3D printed part that was the thin. Once we had printed it, we saw that the part was way too thin to use and was easily broken. In order to make sure that the attachments weren’t too thin to break, we increased the thickness to 2.54mm which is roughly .1 inches thick. Once we printed a small prototype, we saw that it was much more durable than the 2mm one and we were able to easily drill through it without breaking as seen in Figure 1. 

Figure 1  3D printed duct attachment 

duct ring

The next minor challenge that I had to consider was being able to mount on servos to the attachments. The servos were measured to have a height of 1.18 inches and needed to be mounted on to the cylindrical shape. We were initially going to make brackets and screw them in to lock the servos in place however it would be a challenge since we did not have a flat surface and we did not know if adding on screws into the attachment would affect the air flow. After consulting with my project manager, he suggested extruding a thin block out of the attachments and then mounting them onto their. I went with this suggestion and properly dimensioned the extrusion to fit the servo. Initially I designed the extrusion block to be roughly 1x .2x 2.25 inches in size. From there I made an inner cut that was .53x 1.19 inches so the servo can easily fit in (Figure 2). I had these printed and checked to see if both servo EDF could fit on to the attachment. Sure enough both did. In order to secure the servo, I had to drill into the extruded block. For this reason I made the block .2 inches thick, so it would not break off when drilling (Figure 3). Once making the holes, the servo was easily mounted on to the attachments.

Figure 2 CAD of thrust vector chamber with servo flaps (side view)

side view of chamber

Figure 3 CAD of thrust vector chamber with servo flaps (top view)

top view of chamber

        Next we had to make sure that these attachments fit into our Electric Ducted fans. The ducted fans that we were using have an outer diameter of 53mm. I dimensioned the attachments to be slightly bigger than this in order for it to be able to slip on to the EDF. In order to not waste material and time, I had only one attachment be printed. Sure enough it did not fit and was way too tight to even slip on without damaging the attachment. I made designed the attachments to have roughly an inner diameter of 54.1mm which was approximately 2.13 inches (Figure 4) with an outer diameter of 2.23mm (Figure 5). Once making the adjustments, we were able to slip on the prototype into the EDF.

Figure 4  CAD of thrust vector chamber demonstrating inner diameter

idkwhatthisis      

Figure 5  CAD of thrust vector chamber demonstrating outer diameter

idkwhatthisis2

        Since we were going into thrust vectoring, I needed to make sure that the servos could move the attachments without causing any problems. One of the issues I noticed when designing the attachments was that after it rotating roughly 45 degrees, there was going to be a gap that would make air leak out, which could cause an addition issue when trying to stabilize the vehicle. To fix this problem, I made an inner cylinder to close off the gap and made it to have an outer diameter of 1.75 inches (Figure 6) and a length of 1 inch (Figure 7). Because of this, when the middle attachment rotated, there was no gap to leak air. The fabricated part can be shown in Figure 8A & B.

Figure 6 CAD of thrust vector chamber demonstrating inner diameter (second level)

idkwhatthisis3

Figure 7 CAD of thrust vector chamber demonstrating outer diameter (second level)

idkwhatthisis4

Figure 8A 3D Printed thrust vector chamber (side view)

idkwhatthisis5

Figure 8B 3D Printed thrust vector chamber (alternate view)

idkwhatthisis6

        Next was to design the middle attachment. The middle attachment was a much simpler design since much was learned from making the top one. This one just needed to have an inner diameter that was slightly bigger than the top one so it can fit and move. In order to give it a bit more space to move, this attachment had in inner diameter of 2.3 inches (Figure 9). In order to mount on this attachment to the top one, I made the mounts to be roughly 1 inch tall to compensate for the inch clearance that was given from the top attachment. I made a pilot hole on this that is in the center of the mount which was roughly .5 inches from the top of the attachment (Figure 10). An extrude block was added on to this attachment as the previous one, however an additional extrude block was added on in the back in order to have the servo joint attached on to it (Figure 11). There, the top servo was going to push and pull on to this attachment. Ideally this part was not meant to be this long, however we needed to give enough space for the servo. To control the bottom attachment. The fabricated part can be shown in Figure 12.

Figure 9 CAD of thrust vector chamber demonstrating inner diameter

idkwhatthisis7

Figure 10 CAD of thrust vector chamber attachments

idkwhatthisis8

Figure 11 CAD of thrust vector chamber (second level)

idkwhatthisis9

Figure 12 3D Printed thrust vector chamber

idkwhatthisis10

        Lastly we needed to make the bottom attachment. This was the simplest design since it was a funnel shape. In height, the funnel ended up being roughly two inches. As before, an extruded block was added on to this but just to connect to the servo, not to mount on (Figure 13). The fabricated part can be shown in Figure 14.

Figure 13 CAD of thrust vector chamber (lowest level)

idkwhatthisis11

Figure 14 3D printed thrust vector chamber (lowest level)

idkwhatthisis12

                Our second design was to control the yaw by adding flaps to counter the direction of the thrust. For this design, the top part was relatively similar to the previous one except it this not have an additional cylinder to close off any air gap. Also the height was made slightly smaller for the same reason of not having to worry about the air gap. The height of this attachment was roughly 3.83 inches with the same thickness and diameters of the previous design (Figure 15). The reason for this height again was because the EDF height including the coils was roughly 2.82 inches so I needed to make sure that there was a hole big enough to fit in the wires to power it on (Figure 16). In order to make this hole big enough, I needed to make sure there was enough space to make it. Also I needed to make sure that the flaps had enough space to mount on to the attachment.

                                                       

Figure 15 CAD of thrust vector chamber demonstrating dimensions

idkwhatthisis13

Figure 16 CAD of thrust vector chamber with inner diameter

idkwhatthisis14

        There was much thought put into making the flaps to control the direction of the thrust. Initially the idea was to have the flaps go inside and the servo would rotate it however the problem with this was that it could not go in the middle of the attachment. The reason for this is because as the flap turned, there would be a big gap which would leak air out in a direction which would not be in our control. To attempt to solve this, we thought of making the top part of the flap bigger to block off the air gap. The problem with is now was that the top part was going to easily hit the attachment and would not let the flap rotate the way it should. The third idea was had was to remove the flap from being in the middle and putting it in the inner corner of the attachment. This did not work simply because the flap would not be able to rotate without hitting the attachment. After thinking it over with the project manager, we decided to mount on the flap outside of the attachment. I designed the flap to be able to mount on to the cylindrical attachment by making it the same shape. Some parts were trimmed off in order for it to not scrape when moving. The flap itself was designed as a prototype. It was made wide enough to cover the thrust of the EDF and long enough to redirect the thrust. The flap was made .2 inches thick in order to make it durable and hard to break as the EDF was going to be pushing against it. Similarly to the previous designs, and extruded part was added on simply to be able to attach the servo joint to push and pull the flap. The model and fabricated part can be seen in Figure 17A & B.

Figure 17A CAD of thrust vector flap

idkwhatthisis15

Figure 17B 3D printed thrust vector flap

idkwhatthisis16

 

Lastly we noticed that if we were going to use all these attachments then we were going to have a problem with the legs since the attachments were long and were going to hit the floor. I modeled out new legs which were long enough so the attachments wouldn’t hit the ground when standing. These legs were approximately 7.25 inches long total but was given one inch clearance to mount them on to the vehicle (Figure 18). They were designed to be .2 inches thick so they would not break easily since it was supporting the weight of the vehicle. The fabricated part can be seen in Figure 19.

Figure 19 CAD of replacement legs                                  

idkwhatthisis17

Figure 19 3D printed replacement leg

leg

Though these attachments have been modeled and fabricated, we were not able to use any of them nor the servos simply because the added too much weight to the vehicle and made it too heavy to fly. Even adding on the servos alone made the vehicle too have so we could not use those however these concepts can be used for future semesters if they choose to go with a similar approach and taking account the weight ahead of time.

Current Draw spring 2016

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

 

Table of Contents:
– Introduction
– Shunt Resistor
– Results

Introduction:
We encountered a problem while measuring the current draw of the motors; the motors were drawing too much current for the multimeter to read. To solve this, we used a shunt resistor setup to measure the voltage across the resistor and calculate our current draw. Using this method, we can avoid directly measuring the high current which could damage our multimeter.

shunt resistor123

Fig 1.1 Shunt Resistor Setup

This setup is used to measure the current draw of high powered devices. Our load would be the motors and the supply is a 14V source.

 

Shunt Resistor:
The specs of the shunt resistor is 300A, 50mV. That means that the resistor would have a 50mV voltage drop at the maximum current of 300A. Since Ohm’s Law says that the voltage is proportional to the current across a resistor, we can simplify that to 6A per mV. Knowing this, we can calculate the current draw by multiplying the measured voltage by 6A/mV.

Another alternative to calculating the current draw would be to calculate the resistance of the shunt and divide that by the measured current draw. Using Ohm’s Law we can calculate the resistance of the shunt to be:

50mV = 300A*R

R = 50mA/300V =  0.1666mOhms

Shunt Resistors typically have very small values so that it doesn’t affect the circuit. The tolerance is very small, 0.1%, for accurate measurements. To measure the current draw using this method, we divide the measured voltage by 0.16666mOhms.

 

Those two methods described above are 2 ways of realizing an identical solution. Multiplying by 6 is the same as dividing by 0.16666.

shuntcomponent123

Fig 1.2 Shunt Resistor

Low Resistance, Low Tolerance resistor that serves many applications. One of its purposes could be used for measuring high current.

 

Results:
Using this method we were able to accurately measure the current draw of our high powered motors. The results we got was that each motor drew approximately 11.85A at full throttle with our setup. 4 Motors would draw a total of 47.4A. Using this data, we determined that our battery was safe to use with these motors. The battery we have is capable of safely supplying 135A continuous load current which is far above what we require.

UFO Spring 2016 – EDF Area Coverage With Flap Length Calculations

Written and posted by: Luis Valdivia (Project Manager)

Table of contents:
Introduction
Approach
Formulas
Conclusion
Possible Solution

 

Introduction:
When attempting to angle the thrust coming from the Electric Ducted Fan (EDF), there is a risk of covering the ducted fan area to prevent vertical flight. This post will explain our research done to determine the maximum area allowed to control the aircraft without losing vertical thrust.

 

Approach:
Using middle school math, we can figure out the area of the flap size and the area of the duct.

Figure 1.1 demonstrates the area of the duct being covered by the flap, along with formulas for area. 

areamiddleschoolmath123

Because of the size of the EDFs, we will assume the length of the flap is fixed at 55mm. The Width of the flap will depend on the area of the opened duct, aka the area of the circle. For a fully opened duct (meaning no coverage of the circle) we can produce a maximum thrust of 650g with a flap of length 0mm. With a partially opened duct (meaning half of the circle is covered) we can produce half the thrust of 324.99g with a flap length of 27.5mm. Finally, for a fully closed fan duct we will produce 0g of thrust with a flap of length 55mm.
Inputting our 3 sets of values into excel, we can fit a linear line into our data plot to obtain the equation of our line. This equation will help us calculate more values to get a better understanding of the range between flap length and available output thrust.

Figure 1.2 Linear fit plot of Duct Area vs. Thrust (with equation of line)

AreavThrust123

Figure 1.3 Linear fit plot of Duct Area vs. Flap Length (with equation of line)

ductvflaplength123

 

Formulas

Area of duct = 2*π*(radius*percentage of opened duct)

Length of flap = 55mm(100 – percentage of opened duct)

Area of flap = length of flap * 55mm

Thrust (g) Area of duct Length (mm) area of flap (mm^2) % of open fan
650 345.4 0 0 100.00%
643.48137 341.946 0.55 30.25 99.00%
636.9815581 338.492 1.1 60.5 98.00%
630.4817463 335.038 1.65 90.75 97.00%
623.9819345 331.584 2.2 121 96.00%
617.4821227 328.13 2.75 151.25 95.00%
610.9823109 324.676 3.3 181.5 94.00%
604.4824991 321.222 3.85 211.75 93.00%
597.9826872 317.768 4.4 242 92.00%
591.4828754 314.314 4.95 272.25 91.00%
584.9830636 310.86 5.5 302.5 90.00%

 

Conclusion:

As you can see, the thrust output from the EDFs will beginning to decrease if we cover the duct. Although, from a previous blog post we mentioned the necessary thrust to lift the weight of the aircraft. The necessary thrust to lift a quadcopter weighing in at 1291g is 645.5g thrust for each EDF. From our table above, it seems like covering the duct at anything greater than 0.55mm will prevent our UFO from lifting off the ground.

 

Possible solution:

In order to continue the project with thrust vectoring, the EDFs will have to be swapped with fans of thrust greater than 650g. Another solution is to reduce as much weight as possible to lift the UFO and vector the thrust we a reasonably sized flap.