Detailed Design

Team Vision for Detailed Design Phase

The primary goal for the detailed design phase was to further narrow down and eliminate options such that we are left with the best possible solution to the problem defined in the problem definition phase. 

Detailed design phase goals:

• Narrow down and eliminate options to reach a "final" design.
• Develop detailed flowcharts and diagrams to describe designs and design choices.
• Develop CAD models for mechanical designs.  
• Develop prototypes to serve as proof of concept.
• Make part selections for components whenever possible.
• Develop a complete BOM using the parts that were selected.

Prototyping, Engineering Analysis, Simulation

Mechanical Models

Airfoil Options

The airfoil cross-section was decided in the last phase to be the S7055 due to its flat bottom (easier to manufacture) and its fantastic lift to drag ratio.

When lofting this airfoil (S7055) in CAD, by keeping the chords of the base and tip coincident, the airfoil was shown to taper in the vertical direction, which is normal but may have been difficult to manufacture. A second loft was made wherein the wing does not taper in the vertical direction (dubbed the S7055-bp1). To understand if these wing profiles had any advantage or disadvantage over the other, they were put through a basic simulation.

The simulation was run in SimScale, and consisted of analyzing the velocity vectors of air moving around the airfoil at cruising speed (40km/h) head on - that is, parallel to the chord. Slice of each velocity profile are taken at 0.1999m from the base (midsection) and 0.7500m from the base (tip), respectively, for each wing profile.

the results are discussed below.

Airfoil Air Velocity Simulation

• S7055 "Plain" Airfoil:
  

The regular tapered profile showed natural velocity distributions. This is what was expected. (NOTE: 0.1999m from base on left, 0.7500m from base on right)

• S7055-bp1 Airfoil:

The custom wing profile had many difference from the regular profile. The high velocity air over the top surface of the wing was faster for the S7055-bp1 than for the S7055, indicating better potential lift. However, the air bleeding under the wing on the -bp1 also moved faster, potentially cancelling out any benefits. Additionally, in the picture on the right (0.7500m from base) shows that the concentration of high velocity air is toward the back of the camber, meaning the lift vector would be acting against the forward motion of the craft. This lift vector would be lost almost altogether during high angles of attack when airflow separation occurs near the back of the camber.

Ultimately, it was decided that the -bp1 was too volatile to justify it's perceived ease of manufacturability, and the regular taper was moved forward.

Fuselage 

Main inspiration for design came from the Wingtra Wingtra One Tail-Sitting VTOL


From this design there were key features we wanted to extract for the fuselage

• • • Relatively thin not too bulky
    • Panel to access internal electronics
    • Electronics holder so we can manage the electronics easily
    • Wide tail to hold UAV upright
    • Symmetrical

Have to make sure that all the electronics fit and are not too crowded. Have to make sure panel is easily accessible and functional. Make sure that wing connections line up with each other to remain symmetrical as well as the electronics inside. Our goal is to make this type of UAV however at a much cheaper price point therefore for material selection for the fuselage, balsa wood with a combination of foam are good options for the general fuselage shape. For the electronics holder an option such as 3D printing would be ideal. These would be good options because all materials are relatively cheap. Foam is also easy to shape while providing the sturdiness we need.

Emergency Release

• Most existing designs on the market were very similar Examples are shown below:

From these existing designs, the key features extracted were:

• • Slim Canister
  • Attached Servo to hold down lid
  • Compression spring inside 
  • Rolled up parachute

Overall, the parachute design was pretty straight forward just needed a vessel to hold the parachute tightly wrapped up with a spring underneath and a servo holding the lid down. (Preferably a metal servo strong enough for this task). 

Once the servo moves its head the spring will decompress deploying the parachute for our needs. These simple components lead to our initial design of the Emergency Launch

Power Calculations

PDB Benchmarking and Selection

MatekSys FCHUB-12S                                                                             MatekSys FCHUB-6S                                                                               MatekSys FCHUB-W

Based on benchmarking the available boards, the MatekSys FCHUB-12S was selected due to its features. We require a PDB that can output greater than 15 A of continuous currents and can also output 5V and 3.3 V for other electronics. The FCHUB-12S is the only PDB that could satisfy these requirements and was hence chosen.

Drawings, Schematics, Flow Charts, Simulations

CAD Models

Wing CAD Model

The wing was modeled in parts and assembled in SolidWorks 2019-20. The ribs are made of laser-cut balsa wood. The spanwise spars are made of carbon fiber, as is the axle about with the elevon hinges. The wing is designed to be weather sturdy: the only sensitive electronics housed in it are the rangefinders in the tip (see below), all other electronics (such as the ESC's or the elevon servos) are actually housed in the fuselage. This makes it easy to weather proof the fuselage and keep the wings light. The motors are exposed to any weather conditions the wing might see, but they are rated for outdoor use.

The motor mount nacelle is 3D printed in ABS plastic (with an infill <100% - TBD - to further reduce weight). It anchors around both spanwise spars to keep it level with the chord, and will be glued in place as well as kept in place with spacers. The motor is attached to the nacelle via 4 M3  stainless steel screws. The wing tip (for now) is similarly 3D printed in ABS plastic. This serves to keep the wing tip sturdy during turbulent maneuvers or protect the components housed inside in the event of a crash. The reange finders, used to determine the levelness of the ground below when landing via VTOL maneuvers are housed in the tips, and are currently set up to point down towards the ground. They are set deep into the tip to encourage airflow over the tip to pass over the rangefinder gap with minimal consequence. Ideally, this may be further covered with a clear laminate plastic to enhance airflow, so long as the rangefinder utility is intact.

The axle about which the elevon hinges is anchored in the wing by a small aluminum bracket. This will need to be machined special, but it is comprised of simple geometries. The bracket is held to the wing rib supporting it by 2 18-8 stainless steel screws.

Fuselage CAD Model (Parts)

The fuselage was modeled in parts and assembled in SolidWorks 2019-20. The main body (pictured on left) was designed with the intent to hold the electronics, be large enough to support the wings and not too bulky/intrusive. The body is going to be made out of balsa wood (skeleton) with foam supports. The wing will most likely be made of Balsa wood as well. The electronics holder (pictured on the right) is intended to be one solid plate that makes it easy for anyone to know which electronic goes where and keep them stationery in flight. The plate will allow us to screw in any chips and servos. The additional benefit of making such a board is that we are now able to remove all the electronics at once if we desire and if we wanted to change configurations changing the file is not that difficult. This will most likely be 3D printed

this is the panel top (left) and the connector pin to allow us to open and close the fuselage and easily access the internal electronics. The connector pins design will probably change due to its length and not being as sturdy as we would like but this provides a good baseline of what we are thinking. The panel will also most likely be 3D printed.

Fuselage Assembly

Emergency Release CAD Models and Assembly

Using the existing designs as reference we developed a parachute emergency release to look something like the images above. The emergency release should be able to fabricated by 3D printed and then adding the external components (Servo, Parachute, Spring) after. Overall, a simple effective design. Since the air frame is not finalized attaching the chute is not yet included in the design.

Part Drawings Fuselage and Emergency Release (Note: Some dimensions will change)

• Fuselage
  
• Emergency Release
  
  
  

Full CAD Assembly

The full model was assembled using SolidWorks 2019-20.

There is an inch of clearance between the props and the fuselage. This will allow for minimal fuselage effect on prop wash while still keeping the props close enough to the fuselage to minimize the moment arm caused but the loading due to the weight of the motor/nacelle subassembly.

She looks pretty, doesn't she?

Power Scheme

Single Power Supply with Power Distribution Board

• The main power supply is a 4200 mAh 4S LiPo battery connected to a power distribution board.
• The power distribution board is a MatekSys PDB FCHUB-12S that can output both 12V to the ESCs and 5V/3.3V to other components.
• Least noisy option compared to other power schemes.
• Example connections from PDB to other components are shown below.
• All components in grey will be protected using capacitors to prevent damage from electrostatic discharge.

Example Connections from PDB to Other Electronics

• The chosen power distribution board (MatekSys PDB FCHUB-12S) is designed for a quad-copter, hence the four 12 V outputs. 
• The above schematic shows connections to possible electronics. 
• Please note that the connection diagram above shows the presence of a flight controller on the board, however this will not be present in our design since we are using other micro-controllers for flight controls.

System Architecture

Highlights:

• Three separate processors each perform the task of telemetry, high level control, and flight control.
• ATMEGA644PA uses three UARTs and one SPI.
• Raspberry Pi Zero uses two I2C, one SPI, and one UART.
• K64 uses one FTM with four channels, two UARTs, and two I2C.
• The ATMEGA644PA will handle initialization of the FPV transmitter and the telemetry unit.
• RC control bypasses the central controller (Raspberry Pi Zero) via the ATMEGA644PA in order to reduce latency of remote control.
• The Raspberry Pi Zero is responsible for the camera and GPS information.
• Debugging logs are exported from the Raspberry Pi Zero over USB or WiFi.
• The K64 will output PWM signals to all four control surfaces of the aircraft.
• The three rangefinders are for VTOL takeoff and landing. These will require startup configuration in order to configure their I2C addresses.

Debug and Status System

Course Correction and Motor Control

Highlights:

• Either remote control or a GPS location is received via telemetry.
• While remote control is exerted, flight path planning stops and yields to the remote control.
• Remote control provides orientation deltas to the K64. Thus, when no deltas are provided, the current course is maintained.
• The Raspberry Pi Zero is in charge of high level flight plans and controls the craft by sending a desired orientation to the mechanical control system.
• The K64 sends orientation data to the Raspberry Pi Zero.
• The K64 is responsible for mechanical control.
• The K64 calculates the deviation of the current orientation to the requested orientation and feeds this into multiple PIDs for each action surface.

Message Queues and TinyXPC

The System Architecture is driven by Message Queues, which serve several purposes

• Simplifies main control loop to message routing. (reduces merge conflicts!)
• Separates code by module, requiring only a consistent interface to each module that can be documented ahead of time. (No style conflicts!)
• Abstracts function calls and remote procedure calls by message sending/receiving operations.
• Eases end-to-end debug due to state flow traceability.
• Documentation is in a consistent format for each module's interface.
• Modules are easily versioned and validated at system POST, removing strange compile-time errors due to version mismatches.

Messages do not contain "composite data" in this architecture (no pointers to complex data structures).  Thus, serialization of messages is easy, making it possible to transmit them over a serial link.

TinyXPC Message Block Format

TinyXPC is a Data-Link Layer protocol for embedded systems and inter-process communication.  It is focused on point-to-point links and emphasizes remote function calls with its request/target ID fields, which are inspired by PCIe's bus/device/function routing scheme.  These point-to-point links allow two devices to call functions on each other and track responses, as well as allow message reordering with the block ID field.  The TinyXPC message router can be used on both sides of the PHY link (UART in our case) to handle message reordering and calling the appropriate native functions to handle a message block.

A New Look at Telemetry

New Telemetry system uses mesh-networking 802.15 ZigBee in Point-to-Point networking mode.  ZigBee is a long range wireless PHY standard with low latency.  The most common implementation is Digi's XBee radio package, which also includes bluetooth on some models.

Research still needs to be done on the most optimal antennae to use, but half-wave dipoles are commonly used.

The Digi XBee PRO contains a microcontroller which can be reprogrammed with some small amount of user code.  We may be able to save costs on the Telemetry subsystem if this microcontroller can do what we need.

Highlights:

• Either remote control or a GPS location is received via telemetry.
• While remote control is exerted, flight path planning stops and yields to the remote control.
• Remote control provides orientation deltas to the K64. Thus, when no deltas are provided, the current course is maintained.
• The Raspberry Pi Zero is in charge of high level flight plans and controls the craft by sending a desired orientation to the mechanical control system.
• The K64 sends orientation data to the Raspberry Pi Zero.
• The K64 is responsible for mechanical control.
• The K64 calculates the deviation of the current orientation to the requested orientation and feeds this into multiple PIDs for each action surface.

System State Architecture

States:

• Init
  
  •  Initial system state
• Wait
  
  • Hold system until new messages need to be sent
• Send
  
  • Send formatted messages

States:

• Init
  • Initial System State
• Message Update
  • Wait for new message inputs
• Message Processing
  • Process new message
• Return Override
  • Override Input indicated, indicate flight plan is to return home
• Flight Mode
  • Format flight mode based upon received message
• Send
  • Send Flight plan message

States:

• Init/Setup
  • Wait for new Inputs
  • Move to either video or picture state depending on new inputs
• Take Picture
  • Takes Picture
• Picture Captured
  • Indicates that a Picture was Taken
• Start Video
  • Start the Video on the Camera
• Video Done
  • Stop the Video on the Camera
• Storage 
  • Will store the Picture taken or Video
• Malfunction
  • Indicates either a camera malfunction or storage malfunction (Insufficient storage)
  • Format appropriate error message
• Done
  • Send all necessary update messages

States:

• TakeOff
  
  • Send necessary commands for TakeOff sequence
• Hover
  • Send necessary commands for Hover sequence
• Unstable
  • Sends necessary commands for Unstable state
  • Also may indicate transition sequences
    • Ex. Hold Hover due to Takeoff still being performed
    • Will lock in unstable state if Hover or Cruise sequence needs to be held
• Cruise
  • Send necessary commands for Cruise sequence
• Land
  • Send necessary commands for Landing sequence

Bill of Materials

Test Plans

Risk Assessment

Plans for next phase

Team Plans

The next phase is the subsystem build and test prep phase in MSD II. The objective of this phase is to re-familiarize ourselves with the designs that we developed in MSD I and to get material and components ready for the building and testing our subsystems. Since we were not able to do much prototyping we will also try to do some prototyping over the first few weeks of MSD II. The following are our individual plans for the summer and the MSD II phase:

Individual Plans

Atulya 

• Get familiar with the PDB from Matek.
• Develop test plans for the ERs that are "tricky" to test.
• Figure out how to do subsystem build and test prep if we are still going through the pandemic in the fall.
• Research risks involved in the building and testing of drone power subsytems and how to mitigate those risks.

Ben

• Work with Mutahir to ensuring pieces fit together and plan build.
• Work with Andy to develop a model for simulation flights.
• Continue to iterate design, including:
  
  • Redesign tip to be as light as possible, more easily conform to the trailing edge curve of the wing, set the rangefinder at an angle so it points down at 270* (measured from horizontal) during hover, and add a better Hoerner undercut to minimize spillover.
  • Potentially extend nacelle forward.
  • Check design for elevon hinge motion interferences due to shell.
  • Try to minimize shell weight while maximizing shell thickness.

Mutahir

• Work with Ben to make sure our wing design and body design mesh perfectly
• Work with Ben on planning the build.
• Work on prototyping parachute 
• Work with team on component placement and wiring to make it easy to work on

Piers

• Work with Andy to create a simulation model for the aircraft control systems
• Work on the development infrastructure for the embedded software team (devops)
• Research flight control schemes
• Research quaternions
• Research optimal methods to tune and configure PID controllers

Sabrina

• Start executing purchasing plan and purchasing necessary materials ahead of time in order to begin prototyping in MSDII
• Work with Andy in developing the Debugging system
• Start implementing the test plans for software, ie develop expected messages when testing functionality
• Become familiar with the chosen simulator for the control system

Andy

• Build a simulator for our control system around Flight Gear

• Research quaternion based orientation models

• Develop more message request-response pairs

• Develop the Message Queue system

• Develop the Debugging Subsystem

• Work with the mechanical team on manufacturing frame components and nailing down any remaining fuzzy data