Operation Manual 8.1. Successfully Operating the FDL

8. Operation Manual

8.1. Successfully Operating the FDL

Below is a step by step instruction on how to use the FDL.

1. 
   Turn on the ArduPilot Mega and give it 15 seconds to initialize and calibrate
   
2. 
   Ensure that the FDL battery is disconnected and the FDL switch is in the off position (Pointing up)
   
3. 
   Ensure that the SD Card has been formatted and is empty to avoid any errors in writing
   
4. 
   Insert the micro SD Card into the SD Card socket of the FDL
   
5. 
   Now connect the FDL battery to the connector located in the back
   
6. 
   Flip the power switch and the FDL will begin to run instantaneously
   
7. 
   Now, fly the plane
   
8. 
   Upon successful landing, remove the SD Card
   
9. 
   Now power down the system by placing the switch back into the off position and disconnect the battery
   
10. 
    Insert the SD Card into a computer with the FDL Analysis software
    
11. 
    Run the software and locate the log file labeled “TestFile1.txt” on the SD Card
    
12. 
    Now specify the location and name of the file you would like to create
    
13. 
    Look to the location specified and the analysis file will be printed with all of the desired coefficients
    
14. 
    Also, the software compiles a readable text version of the file created by the FDL. The file, “output.txt”, is located in the same folder as the executable. NOTE – “Output.txt” is overwritten with each run of the software.
    

9. Administrative Content

9.1. Project Milestones

1. 
   Obtain all software and hardware design tools.
   
2. 
   Obtain sample parts and being validating them.
   
3. 
   Transfer block diagrams into actual code or schematic drawings.
   
   1. 
      Hardware schematic capture, PCB design (layout, routing, stack-up)
      
4. 
   Validate, simulate, and debug hardware and software designs
   

1. 
   Test the plane, autopilot, data-logger, and software.
   
2. 
   Implement designs into a prototype PCB, and program with software application
   
3. 
   Prototype tested and working by December 15, 2011.
   

Looking back to the earlier set goals, it can be said that we have accomplished our set milestones for the most part. By saying that we only accomplished our milestones for the most part simply means that we were not able to achieve at completing all of them, yet the ones with the highest priority were accomplished. For illustration, we were able to obtain all necessary tools, create block diagrams and create a finalized rough draft for our design. One of the objectives that slipped through the cracks is really being able to sample some of the hardware from vendors and start some sample testing – a handful of parts were ordered and received, but time did not allow for us to test as we would have like to.

The most important thing that we have learned from our milestones is that setting milestones is a good reminder to keep one’s self on track to meet that desired goal. On the other hand, the best way to stay on top of these demands would be to create a weekly or bi-weekly schedule that sets several smaller checkpoints rather than a few large achievements. The aim of having more, minor milestones is to consistently keep ourselves engaged in the development of our prototype and not become too distracted by the wants and needs or our personal lives and eventually leaving ourselves with a large lump sum of work to accomplish in a very short period of time. Hence, this is why we devised a way to break up the targets into multiple smaller ones that can be accomplished on a bi-weekly schedule.

A detailed schedule for the fall can be found below. This agenda serves as a way to remind the team to stay in constant communication and to track progress made towards the ultimate end goal of a working prototype.