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.
- 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.
- 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
Requestor ID | Block ID | Target ID | Size | Data |
---|---|---|---|---|
0 | 0 | 5 | 2 | 0x1701 |
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
S01 Test Plan
S03 Test Plan
S04 Test Plan
S05 Test Plan
S06 Test Plan
S07 Test Plan
S10 Test Plan
S11 Test Plan
S12 Test Plan
S13 Test Plan
S14 Test Plan
S15 Test Plan
S19, S20, S21 Test Plan
S22 Test Plan
S23 Test Plan
S24, S25 Test Plan
S26 Test Plan
S27 Test Plan
S29 Test Plan
S31 Test Plan
S36 Test Plan
S37 Test Plan
S38 Test Plan
S39 Test Plan
S41 Test Plan
Risk Assessment
Risk | Description | Risk Type | Likelihood (0-5) | Severity (0-5) | Importance (L x S) | Action(s) Taken |
---|---|---|---|---|---|---|
Motor Overheat | The motors are designed to be cooled by air passing through the motor in flight. | Technical | 2 | 2 | 4 | Takeoff and landing are when this risk is greatest. Because these modes are a small portion of the operation of the craft, no actions will be taken unless it becomes more severe. |
Vibrations | Flight and motors will cause vibrations over the craft. | Technical | 5 | 3 | 15 | It is likely the craft will vibrate, but functionality is expected to remain unharmed. No actions will be taken unless it becomes more severe. |
Motor Magnetic Fields | Motors will generate and collapse magnetic fields that may interfere with positional sensors. | Technical | 4 | 2 | 8 | The sensor package should be placed as far away from the motors as possible. |
IMU Drift | The IMU is expected to lose accuracy because of noise and other factors. | Technical | 3 | 2 | 6 | This will be handled via filtering and calibration. |
Prop Wash | The propellers cause air to approach the wings in waves. | Technical | 5 | 1 | 10 | Prop wash is expected to have minimal impact. No actions will be taken unless it becomes severe. |
COVID-19 | We are currently facing a pandemic that has everyone social distancing. | Safety | 5 | 5 | 25 | Zoom meetings instead of class meetings. Team members must rely on online communications to get work done. |
Overbudget | Budget is limited - no funding outside of team members and RIT | Resource | 3 | 5 | 15 | Avoid |
Fabrication | Machine shop/Construct tools could be busy, or available building resources could be limited | Time | 3 | 3 | 9 | As soon as a preliminary design is settled upon, start to source materials and fabricate parts as they become finalized, not once all parts are finalized |
Software (telemetry) | Telemetry is difficult, and difficult to debug. Significant technical challenge. | Technical | 3 | 3 | 9 | Start early, plan ahead for this challenge, since it will be necessary during testing. |
Injury | Someone could be hit by the drone, or cut by the spinning prop | Safety | 2 | 5 | 10 | Have a designated drone spotter when testing, mark dangerous area on drone with labels, have a testing plan with steps clearly outlined to ensure personnel safety, only test drone in areas away from residential areas |
Drone Protection | Effective crash mitigation tech may be expensive or technically difficult to implement, affect CR's and putting drone safety at risk | Resource | 4 | 3 | 12 | Choose a concept which has crash protection built in. Ensure pilots are trained before flying the real aircraft. |
Efficient Wiring | Small problems in wiring and electrical design can become troublesome quickly. | Technical | 3 | 3 | 9 | Consider current flows, do initial testing. Overbuild subsystems likely to cause problems (engine power subsystem, for example). |
Testing | A quick, accurate, and safe way to test drones is critical given that we cannot test on campus | Technical/Time | 5 | 4 | 20 | Choose a concept which we are capable of testing. |
Flight Time | The drone should be able to maintain flight long enough to test fully and not worry about sudden loss of power mid-flight | Technical | 2 | 4 | 8 | Choose a concept for which we can optimize power consumption and therefore flight time. |
Limited Number of Drones | Only so many testing drones can be constructed with budget constraints | Resource | 3 | 3 | 9 | We will only be able to build one drone, but we have two indoor aircraft that may be used as trainers. |
Loss of Team Member | Reduced work capacity due to missing/absent team members. | Resource | 5 | 1 | 5 | Mitigation plan is to reduce our dependency on custom mechanical parts. (Ben is leaving) |
Customer Redirection | A new customer is added, thus changing CRs | Time | 1 | 4 | 4 | Mitigated. At this point it is not feasible for the team to take on a new customer. |
Customer Absence | No official outside customer is identified, leaving us with speculated CRs and little expert knowledge | Information | 5 | 2 | 10 | We have been continuing our design validation and analysis techniques. |
Extended Winter | Inclement conditions make flight testing difficult | Time | 2 | 4 | 8 | Find resources where we can reserve indoor flying space, even if small. |
Unexpected Roadblock | Unforeseen technical hurdle, miscommunication or serious bug not found in testing | Technical | 5 | 3 | 15 | Plan project. Break large tasks into smaller ones until they can not be broken down further. Ensure communications are clear and quick. |
Team Communication | Wealth of information spread across platforms and people could create discrepancies in planning | Personal | 5 | 1 | 5 | Communicate in advance of personnel absences, after every meeting post in group chat what assignments were and the expected due dates so there is accountability |
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