This phase was used to review project design and make necessary changes before moving into the building phase. In addition timelines for building and testing were constructed with both overall phases and individual plans for the different teams working on different sections of the drone. The purchasing plan was also updated to now include a record of purchases,  an estimated time until the parts arrive, and keep track of the budget as different parts are ordered.

Team Vision for Build & Test Prep Phase


NameWhat was planned to do?What was accomplished?

Andy Meyer

This list copied from Detailed Design Review.
  • R&D on TinyXPC communications and message routing
  • 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
  • R&D on TinyXPC communications and message routing
  • Research quaternion based orientation models
  • Develop the Debugging Subsystem

The work on TinyXPC took far longer than expected due to
learning a whole new field of programming.

On top of this, low-overhead debugging was delayed due to lack of a
working message protocol, but much of the difficult work is complete,
and the research is also complete.
Piers Kwan

This list copied from Detailed Design Review.

  • Create a simulation model for the aircraft control systems.
  • Work on the development infrastructure for the embedded software team.
  • Research flight control schemes/quaternions.
  • Research optimal methods to tune and configure PID controllers.
  • An idea for a simulation model around data analysis was theorized.
    Missing the data to actually fabricate this model.
  • Worked with Andy to create a template for K64 development on GitHub.
  • Researched and tested quaternion models and rotations.
    Created a quaternion visualizer that can be used to assist controls development.
  • Deferring the research on controls tuning for when we have more data
    on the response of the control surfaces of the aircraft.
  • Developed an initial I2C driver for the K64.

Sabrina Ly

  • Update Purchasing plan to keep track of materials purchased and to be purchased
  • Work with team to nail down which exact components need to be purchased
  • Begin purchasing materials for build phases
  • Work on testing schemes and plans
  • Purchasing record created to keep track of purchases made and budget remaining
  • First round of materials all set up to be purchased (pending approval)
  • Worked with Andy to ensure that necessary drivers and files were installed to interface with the k64 microcontroller upon personal computer
  • Testing phase held off until some code can be developed to test

Ben PalmerThis list copied from Detailed Design Review.
  • 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.
  • Build plan is mostly in place - final tweaks necessary to ensure fuselage fits wings and vice versa, but no major changes expected
  • Nacelle has been extended
  • Elevon interferences not an issue
  • Individual ribs prepared for CNC or laser cutting
  • Necessary torque analysis of elevons performed
  • Additional planning and modeling for Versa Wing test bed completed with Mutahir
    • Launcher spring analysis completed
    • Landing legs design and analysis completed

Mutahir Mustahsan

This list is copied from Detailed Design Review.

  • 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
  • Parachute canister was redesigned
    • Added electronics holder for independent testing off the drone and back-up/primary power to ensure it works
      • Battery Holder
      • Micro Controller slot
    • Added Spring Cap
    • New Shape and Top design
    • Added 2nd spring to handle shock absorption
  • Build plan is mostly in place regarding versa wing retrofit and general idea of theoretical build plan.
    • i.e. what will be made where: construct/machine shop
  • Designed new motor mounts for versa wing retrofit to emulate theoretical design
Atulya John

This list copied from Detailed Design Review.

  • 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.
  • Power calculations were redone to match the specifications of the versa wing.
  • Familiarized myself with the schematics provided on the matek datasheet.
  • Issues w.r.t. PDB purchase were sorted out.
    • Decided to purchase it ourselves.
  • Test plans for almost all engineering requirements have been developed.


Test Plan Summary

Test Plans

Test plans were compiled into separate pages for simplicity and easy tracking. The links below display the pages for each individual test plan. Some test plans cover more than one engineering requirement and as such have multiple requirements attached to their name. Each testing plan has team members assigned to it to detail how each testing phase was executed and to ensure that all engineering requirements get full-filled by the end of this project.


Safety Standards

The following safety standards designated below detail standard specifications to adhere to as the team moves onto the build and test portions of this project.


StandardDetails
ASTM F2909-19Standard to address minimum requirements for determining if a drone is continually airworthy
ASTM F2910-14Standard Specifications for designing and building small unmanned aerial systems
ASTM F3002-14aStandard Specifications for designing control systems for small unmanned aerial systems
ASTM F3366Standard Specification for General Maintenance Manual
ASTM 3201-16Standard Specification for ensuring dependability of software used on UAS
NFPA 2400

Small UAS for Public Safety

FCC Part 1515.247.a3 RF on the 5.8GHz band
FCC Part 1515.245 RF on the 2.4GHz band
FAA 107.12Requirement for a remote pilot certificate with a small UAS rating
FAA 107.29Daylight Operation. No persons may operate a small unmanned aircraft system during night.
FAA 107.51

Operating Limitations.

The groundspeed of a UAS may not exceed 87 knots (100mph).

The altitude of the UAS cannot be higher than 400 feet above ground level (unless there are structures...)

FAA 107UAVs should weight less than 55 lbs
FAA 107Visual line of sight must always be maintained with pilot and drone

Risk and Problem Tracking

Copied from Detailed Design Review.

The following tables detail our risk management plans and which risks we have taken into account in order to mitigate the effect of these risks if they come to fruition. (The same table can be seen in our Detailed Design Review page.) Currently there are no ongoing problems related to these risks.

Ongoing

Risk

Description

Risk Type

Likelihood

(0-5)

Severity

(0-5)

Importance

(L x S)

Action(s) Taken

COVID-19School closes again before the end of the semester.Safety3515Pivot to documentation of existing systems.
InjurySomeone could be hit by the drone or cut by the propeller.Safety2510Designate a spotter, mark dangerous areas, have carefully designed testing plans, and test drones away from residential areas.
Loss of DroneWith the current budget, only one drone can be manufactured. Losing this drone could prove fatal to the project.Resource248Test all subsystems on the VersaWing before deploying to minimize risk. If the drone is lost, pivot to the documentation of existing systems.
OverspendingBudget is limited with no funding outside of team members and RIT.Resource3515All parts are picked out such that the budget is not violated. Ensure that modifications to the design are necessary and do not vastly violate the existing budget.
Motor OverheatThe motors are designed to be cooled by air passing through the motor in flight. This could potentially overheat in VTOL mode as less air is passing through the motors.Technical224Takeoff 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.
VibrationsFlight and motors will cause vibrations over the craft.Technical5210It is likely the craft will vibrate, but functionality is expected to remain unharmed. No actions will be taken unless it becomes more severe.
Magnetic FieldsMotors and power circuits will generate and collapse magnetic fields that may interfere with positional sensors.Technical414

The sensor package should be placed as far away from the magnetic fields as possible. It seems that it is unlikely that these fields will cause significant errors in the sensors.

Sensor VarianceNoise on the sensors could prove fatal to our application.Technical4416Noise characterization, filtering, and calibration will be performed on the sensor packages.
Software BugUnexpected bugs could prove fatal mid flight.Technical3515Software best practices and review processes can limit the probability of fatal bugs.
Manufacturing AccessManufacturing tools could be busy, or available building resources could be limited.Time339Source materials and fabricate parts as soon as possible.
Early WinterInclement conditions could make flight testing difficult.Time248Outfit the VersaWing so that computer subsystems are able to be tested. Manufacture drone as soon as possible to maximize number of flight tests.



The table of resolved risks outlines which risks no longer pose a threat as they have been resolved through one circumstance or another.

Resolved

Risk

Description

Risk Type

Likelihood

(0-5)

Severity

(0-5)

Importance

(L x S)

Action(s) Taken

Customer Redirection

A new customer is added, thus changing CRs

Time144

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.

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)

Design Review Materials

Updated Detailed Design

Any updated details to the overall design of this project have been added to the detailed design page. Such changes include the addition of a test VersaWing for the purpose of testing electronics and onboard systems on a craft that is not the final drone to mitigate the risk of destruction upon crashing and allow for greater versability in testing. Note: All changes to the updated design have been marked with red section headers.

Below is a link to the updated detailed design page which includes updated build plans.

Updated Detailed Design

Plans for next phase

Here is our work breakdown by person (only tracked, new tasks are listed, some tasks are unassigned (epics, closed tickets), or untracked (status update work, supporting research, anything relating to bureaucracy satisfaction programs).

Additionally, here is our work breakdown by epic and by time. Some epics have many subtasks, others have relatively few, or track unknown subtasks (where the work breakdown is not 100% clear).

Both of the above charts were generated from our Jira, and are updated once every fifteen minutes on our dashboard!

(MSD2-## correspond to tasks outlined and assigned in Jira allow for easy work tracking and accountability)

Name3-Week Plan

Andy Meyer

MSD2-35, MSD2-36, MSD2-42

These are the XPC-related tasks.  Completion of these implies that inter-board and interprocess communications (meaning ground control as well) will be complete.

MSD2-37, MSD2-13, MSD2-14

These are the debugging-related tasks.  Completion of these implies low-overhead, low-latency debug and logging for the aircraft and all subsystems.  This will enable subsystem testing and will also enable black box support, in-air debug logging, and will reduce the processor effort of debugging significantly.

Piers Kwan

MSD2-9

This task describes the completion of the I2C driver with interrupt and DMA capabilities. This will be the foundation of the entire sensor subsystem for the K64.

MSD2-62, MSD2-63

Using the I2C driver from MSD2-9, these tasks involve the integration of the IMU and distance sensors over I2C. Each device will have to be initialized over I2C.

MSD2-11

In this task, the quaternion interpolation system is prototyped in python. This will be a modified version of SLERP and will be visualized using the existing quaternion visualizer.

Sabrina Ly

MSD 2-25

This task corresponds to completing a timing analysis on the k64 to check whether float operations separate from integer operations.

MSD2-38, MSD2-39, MSD2-40

These tasks are the driver related tasks. Completion of these include create the PWM drivers for the different servos and ESCs.

MSD2-65

This task falls under the sensor subsystem category and includes interfacing with the GPS.

Ben Palmer

MSD2-43

This task involves sourcing balsa wood for the wing ribs, converting CAD files into gcode, and laser cutting the wing ribs to prepare for assembly.

Once the spars and elevon axles have arrived, I will work with Mutahir to assemble the ribs and nacelles onto the spars and glue them in place.

MSD2-44

This task involves machine elevon brackets from aluminum and fitting them with appropriate bearings.

MSD2-48

This task involves the successful printing and implementation of the Versa Wing landing legs

Mutahir Mustahsan

MSD2-46, MSD2-49

These tasks are related to 3D printing the motor nacelles and making sure they securely fit to the Versa wing and can be adapted to the theoretical design as well

MSD2-54

This task involves fully assembling the fuselage and the parachute canister. Realistically only the parachute canister will be done first as it is needed for the versa wing retro fit.

MSD2-47

This task involves 3D printing the electronics holder. This will be submitted to print when revisions to the design have been made due to the PCB changes

Atulya John

MSD 2-18, MSD 2-76

These tasks correspond to wiring and interconnects. I will be researching and developing a solution for wiring and interconnections (power and signal distribution). I will work with Andy to figure out the most feasible interconnect solution.

MSD 2-77, MSD 2-79, MSD 2-75

These tasks are related to the testing of the power distribution board. They involve researching and familiarizing myself with the PDB and then testing the PDB.

MSD 2-78

This is an easy one. It relates to purchasing the PDB. It is in progress and I will be placing the order in the next few days.

  • No labels