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
Name | What was planned to do? | What was accomplished? |
---|---|---|
Andy Meyer | This list copied from Detailed Design Review.
|
The work on TinyXPC took far longer than expected due to 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.
|
|
Sabrina Ly |
|
|
Ben Palmer | This list copied from Detailed Design Review.
|
|
Mutahir Mustahsan | This list is copied from Detailed Design Review.
|
|
Atulya John | This list copied from Detailed Design Review.
|
|
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.
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
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.
Standard | Details |
---|---|
ASTM F2909-19 | Standard to address minimum requirements for determining if a drone is continually airworthy |
ASTM F2910-14 | Standard Specifications for designing and building small unmanned aerial systems |
ASTM F3002-14a | Standard Specifications for designing control systems for small unmanned aerial systems |
ASTM F3366 | Standard Specification for General Maintenance Manual |
ASTM 3201-16 | Standard Specification for ensuring dependability of software used on UAS |
NFPA 2400 | Small UAS for Public Safety |
FCC Part 15 | 15.247.a3 RF on the 5.8GHz band |
FCC Part 15 | 15.245 RF on the 2.4GHz band |
FAA 107.12 | Requirement for a remote pilot certificate with a small UAS rating |
FAA 107.29 | Daylight 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 107 | UAVs should weight less than 55 lbs |
FAA 107 | Visual 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-19 | School closes again before the end of the semester. | Safety | 3 | 5 | 15 | Pivot to documentation of existing systems. |
Injury | Someone could be hit by the drone or cut by the propeller. | Safety | 2 | 5 | 10 | Designate a spotter, mark dangerous areas, have carefully designed testing plans, and test drones away from residential areas. |
Loss of Drone | With the current budget, only one drone can be manufactured. Losing this drone could prove fatal to the project. | Resource | 2 | 4 | 8 | Test all subsystems on the VersaWing before deploying to minimize risk. If the drone is lost, pivot to the documentation of existing systems. |
Overspending | Budget is limited with no funding outside of team members and RIT. | Resource | 3 | 5 | 15 | All 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 Overheat | The 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. | 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 | 2 | 10 | It is likely the craft will vibrate, but functionality is expected to remain unharmed. No actions will be taken unless it becomes more severe. |
Magnetic Fields | Motors and power circuits will generate and collapse magnetic fields that may interfere with positional sensors. | Technical | 4 | 1 | 4 | 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 Variance | Noise on the sensors could prove fatal to our application. | Technical | 4 | 4 | 16 | Noise characterization, filtering, and calibration will be performed on the sensor packages. |
Software Bug | Unexpected bugs could prove fatal mid flight. | Technical | 3 | 5 | 15 | Software best practices and review processes can limit the probability of fatal bugs. |
Manufacturing Access | Manufacturing tools could be busy, or available building resources could be limited. | Time | 3 | 3 | 9 | Source materials and fabricate parts as soon as possible. |
Early Winter | Inclement conditions could make flight testing difficult. | Time | 2 | 4 | 8 | Outfit 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 | Time | 1 | 4 | 4 | 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.
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)
Name | 3-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. |