System Overview:
Source Modules:
DeckLink: Receive video feed from the UAV.
FlightData: Receive flight data from the onboard autopilot.
UserInput: Receive user input.
Processor Modules: ? indicates possible but not confirmed module
Geolocation: Turn pixel coordinates into geographic coordinates
TargetAcquisition: Use ConvNet to identify target
GroundLocate?: Perform GeoPy calculations to identify bearing of tent relative to aircraft
Approach?: Handle taxi approach to the packages
Select?: Handle our package selection system
Command: Turn program instructions into flight instructions for the autopilot, i.e transmit coordinates and commands.
Control Modules:
Main Process: Central process that executes programs.
System Concepts:
Programs: Programs are held in the main process, they’re in concept, a series of instructions for how to use modules to complete a specific goal. They contain all module instantions, pipelines and calls to perform a task.
Modules: Modules have specialized tasks and are used to process or interpret data, whereas programs move data.
Process Control and Module Access: Modules are accessed by calling one public function that then controls execution. The public function will call all other required private member functions (private isn’t possible in Python but we will treat them as such). The module will then generate the required threads with the pipelines passed in and begin execution and feeding the pipelines. At no point are threads generated by the main process.
Asynchronous Operations: Asynchronous operations will be implemented with the Python threading library, the architecture we intend to use is producer-consumer via pipelines. This means that each thread will be a producer, consumer or both and therefore have one or more pipelines passed in on instantiation, which are then passed to threads. The threads then manage passing data along the pipeline from the first step in the program to the last. Note a pipeline is a threading concept, it is a class that serves to synchronize two threads and allow data to pass between them.
Singleton: All modules are only instantiated once, and therefore only one program is executed at a time. Program execution is controlled by user input.
Tasks:
Tasks will be broken down into “blocks”, tasks that need to be completed before other tasks can be completed. For example, a task in block 2 can start before one in block 1, using dummy functions, but it cannot be finalized until block 1 is complete. Planning for tasks in block 2 can occur before block 1 is complete, as well. Tasking will work bottom to top, starting at each module and working our way up to the main process. ? indicates lack of confirmation on tasking. Tasks are assigned by individual or subteam.
Block 1: Modules, Soft Deadline: February 21th
User Input Module → Atharva
TargetAcquisition Module → Addesh
This is just a wrapper of the YOLO functions provided in the prebuilt library we use.
Geolocation Module → Flight Team
Command Module + Flight Data → Command Team
GroundLocate → Search Team
Select → Taxi Team
Implement multithreading and instantiation architecture to each module → Shrinjay/Aryan?
Testing: Will occur after each module is completed, at discretion of team on feasability of testing at this stage. DeckLinkSrc is already implemented and is critical to test, alongside command, user input and target acquisition as these can be tested at this stage.
Block 2: Wiring, Soft Deadline: March 7th
Implement flight program → Flight Team
Implement search program → Search Team
Implement taxi program → Taxi Team
Implement helper functionality in main process → Shrinjay/Aryan?
Block 3: System Review, Soft Deadline: March 21st
A one-on-one review of each program, defining test conditions and additional unit + system tests if not already implemented → Shrinjay/Aryan as reviewers
Block 4: System Testing, Until Competition
Flight tests, reviews and modifications as needed.