diff --git a/biblio.bib b/biblio.bib index 9271a6e..3770a43 100644 --- a/biblio.bib +++ b/biblio.bib @@ -4,3 +4,276 @@ @article{achiam2023gpt journal={arXiv preprint arXiv:2303.08774}, year={2023} } +@misc{rightmoveCheckThis, + author = {{R}ightmove}, + title = {{C}heck out this {W}arehouse to lease on {R}ightmove --- rightmove.co.uk}, + howpublished = {\url{https://www.rightmove.co.uk/properties/148534730\#/?channel={C}{O}{M}\_{L}{E}{T}}}, + year = {2026}, + note = {[Accessed 27-04-2026]}, + journal = {N/A} +} +@misc{outdoorlaserLasergamingEXCLUSIVE, + author = {{L}asergaming}, + title = {{L}asergaming 2hr {E}{X}{C}{L}{U}{S}{I}{V}{E} {G}roup {S}ession - {D}ay - for {A}dults - {L}asergaming {O}xford --- outdoorlaser.com}, + howpublished = {\url{https://outdoorlaser.com/product/exclusive-lasergaming-2hr-group-session-day-for-adults/}}, + year = {2026}, + note = {[Accessed 27-04-2026]}, + journal = {N/A} +} +@misc{chabounconstructionMuchDoes, + author = {}, + title = {{H}ow much does a house renovation cost​ ? 2025 {G}uide --- chabounconstruction.com}, + howpublished = {\url{https://chabounconstruction.com/house-renovation-cost/}}, + year = {}, + note = {[Accessed 27-04-2026]}, + journal = {N/A} +} +@misc{testedSafetyNet, + author = {}, + title = {Building-Site Safety Net EN 1263-1 by the m² (Custom-Made) | Safetynet365 --- safetynet365.com}, + howpublished = {\url{https://safetynet365.com/Fall-Safety-Nets/Custom-Made-by-the-m/Fall-Safety-Net-by-the-m-Custom-Made::59.html}}, + year = {c2009-2026}, + note = {[Accessed 11-05-2026]}, + journal = {N/A} +} +@misc{thinSafetyNet, + author = {}, + title = {Safety Net by the m² (Custom-Made) 1.5/100 mm | Safetynet365 --- safetynet365.com}, + howpublished = {\url{https://safetynet365.com/Safety-Nets-by-the-m/Net-by-the-m-Custom-Made::15.html}}, + year = {c2009-2026}, + note = {[Accessed 11-05-2026]}, + journal = {N/A} +} +@misc{usedSafetyNet, + author = {}, + title = {Safety Net by the m² (Customised) 2.3/100 mm | Safetynet365 --- safetynet365.com}, + howpublished = {\url{https://safetynet365.com/Safety-Nets-by-the-m/Net-by-the-m-Custom-Made::22.html}}, + year = {c2009-2026}, + note = {[Accessed 11-05-2026]}, + journal = {N/A} +} + +@misc{geeksforgeeksBluetoothFrameStructure, + author = {}, + title = {{B}luetooth-{F}rame {S}tructure - {G}eeksfor{G}eeks --- geeksforgeeks.org}, + howpublished = {\url{https://www.geeksforgeeks.org/computer-networks/bluetooth-frame-structure/}}, + year = {}, + note = {[Accessed 03-05-2026]}, + journal = {N/A} +} + +@misc{pang2024modelingtradeoffthroughputreliability, + title={Modeling the Trade-off between Throughput and Reliability in a Bluetooth Low Energy Connection}, + author={Bozheng Pang and Tim Claeys and Hans Hallez and Jeroen Boydens}, + year={2024}, + eprint={2405.01231}, + archivePrefix={arXiv}, + primaryClass={cs.NI}, + url={https://arxiv.org/abs/2405.01231}, +} +@misc{key, + author = {}, + title = {}, + howpublished = {\url{https://howiwifi.com/2020/07/13/802-11-frame-types-and-formats/}}, + year = {2020}, + note = {[Accessed 06-05-2026]}, +} + +@misc{brotherhobby_avenger28065, + author = {{BrotherHobby}}, + title = {{Avenger 2806.5 Motor}}, + howpublished = {\url{https://www.brotherhobbystore.com/products/avenger-28065-motor}}, + year = {2026}, + note = {[Accessed 09-05-2026]}, +} + +@misc{hqprop_8x4x3, + author = {{HQProp}}, + title = {{HQProp 8X4X3 Grey (2CW+2CCW) Poly Carbonate}}, + howpublished = {\url{https://www.hqprop.com/hqprop-8x4x3-grey-1cw1ccw-poly-carbonate-p0411.html}}, + year = {2026}, + note = {[Accessed 09-05-2026]}, +} + +@misc{mit_propeller_performance, + author = {{MIT}}, + title = {{Propeller Performance}}, + howpublished = {\url{https://web.mit.edu/16.unified/www/FALL/thermodynamics/notes/node86.html}}, + year = {2006}, + note = {[Accessed 09-05-2026]}, +} + +@misc{littlebee_spring_40a, + author = {{All Drones Racers}}, + title = {{ESC LittleBee Spring 40A BLHeli\_S DShot600 2S--4S}}, + howpublished = {\url{https://all-drones-racers.fr/en/little-bee/695-esc-little-bee-spring-40a-blhelis-dshot600-2s-4s.html}}, + year = {2026}, + note = {[Accessed 09-05-2026]}, +} + +@misc{tattu_bashing_4s_5000mah, + author = {{Motion RC / Motionew}}, + title = {{Battery LiPo 4S 5000mAh 50C Tattu Bashing}}, + howpublished = {\url{https://www.motionew.com/shop/power-solution/battery-lipo-4s-5000mah-50c-tattu-bashing/}}, + year = {2026}, + note = {[Accessed 09-05-2026]}, +} + +@misc{gensace_4s_5000mah, + author = {{Buddy RC}}, + title = {{Gens Ace 5000mAh 4S1P 50C 14.8V HardCase LiPo Battery}}, + howpublished = {\url{https://www.buddyrc.com/products/gens-ace-5000mah-14-8v-50c-4s1p-hardcase-lipo-battery14-with-deans-plug-1}}, + year = {2026}, + note = {[Accessed 09-05-2026]}, +} + +@misc{holybro_pdb_300a, + author = {{Holybro}}, + title = {{Power Distribution Board (PDB) 300A}}, + howpublished = {\url{https://holybro.com/products/power-distribution-board-pdb-300a-side-entry}}, + year = {2026}, + note = {[Accessed 09-05-2026]}, +} + +@misc{pololu_d24v90f5, + author = {{Pololu}}, + title = {{5V, 9A Step-Down Voltage Regulator D24V90F5}}, + howpublished = {\url{https://www.pololu.com/product/2866}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{arduino_uno_rev3, + author = {{Arduino}}, + title = {{Arduino Uno Rev3}}, + howpublished = {\url{https://store.arduino.cc/products/arduino-uno-rev3}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{arduino_uno_r4_wifi, + author = {{Arduino}}, + title = {{Arduino Uno R4 WiFi}}, + howpublished = {\url{https://store.arduino.cc/products/uno-r4-wifi}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{raspberrypi4_specs, + author = {{Raspberry Pi}}, + title = {{Raspberry Pi 4 Model B Specifications}}, + howpublished = {\url{https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{raspberrypi5_specs, + author = {{Raspberry Pi}}, + title = {{Raspberry Pi 5 Specifications}}, + howpublished = {\url{https://www.raspberrypi.com/products/raspberry-pi-5/}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{sparkfun_icm20948, + author = {{SparkFun Electronics}}, + title = {{SparkFun 9DoF IMU Breakout - ICM-20948 (Qwiic)}}, + howpublished = {\url{https://www.sparkfun.com/sparkfun-9dof-imu-breakout-icm-20948-qwiic.html}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{st_vl53l1x, + author = {{STMicroelectronics}}, + title = {{VL53L1X Time-of-Flight Ranging Sensor Datasheet}}, + howpublished = {\url{https://www.st.com/resource/en/datasheet/vl53l1x.pdf}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{st_vl53l5cx, + author = {{STMicroelectronics}}, + title = {{VL53L5CX Multizone Time-of-Flight Ranging Sensor Datasheet}}, + howpublished = {\url{https://www.st.com/resource/en/datasheet/vl53l5cx.pdf}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{ukhsa_laser_safety, + author = {{UK Health Security Agency}}, + title = {{Laser radiation: safety advice}}, + howpublished = {\url{https://www.gov.uk/government/publications/laser-radiation-safety-advice/laser-radiation-safety-advice}}, + year = {2025}, + note = {[Accessed 11-05-2026]}, +} + +@misc{bsi_laser_safety_60825, + author = {{British Standards Institution}}, + title = {{BS EN 60825-1:2014+A11:2021 Safety of laser products -- Equipment classification and requirements}}, + howpublished = {\url{https://knowledge.bsigroup.com/products/safety-of-laser-products-equipment-classification-and-requirements-1}}, + year = {2021}, + note = {[Accessed 11-05-2026]}, +} + +@misc{EnergyPrices, + author = {}, + title = {}, + howpublished = {\url{https://assets.publishing.service.gov.uk/media/68da5e91dadf7616351e4b5e/quarterly-energy-prices-september-2025.pdf}}, + year = {}, + note = {[Accessed 11-05-2026]}, +} + +@misc{UValueRegs, + author = {}, + title = {{B}uilding {R}egs {U}-{V}alues: {L}imiting \& {N}otional {V}alues | {S}{A}{P}gen --- sapgen.co.uk}, + howpublished = {\url{https://www.sapgen.co.uk/building-regs-u-values/}}, + year = {}, + note = {[Accessed 11-05-2026]}, +} + +@misc{mediaperformancePaidSocial, + author = {Simon}, + title = {{P}aid {S}ocial {A}dvertising {C}osts {U}{K} 2026 | {M}edia {P}erformance --- mediaperformance.co.uk}, + howpublished = {\url{https://www.mediaperformance.co.uk/paid-social-advertising-costs-uk-2026/}}, + year = {}, + note = {[Accessed 11-05-2026]}, +} + +@article{LEE201090, +title = {Usability principles and best practices for the user interface design of complex 3D architectural design and engineering tools}, +journal = {International Journal of Human-Computer Studies}, +volume = {68}, +number = {1}, +pages = {90-104}, +year = {2010}, +issn = {1071-5819}, +doi = {https://doi.org/10.1016/j.ijhcs.2009.10.001}, +url = {https://www.sciencedirect.com/science/article/pii/S1071581909001451}, +author = {Ghang Lee and Charles M. Eastman and Tarang Taunk and Chun-Heng Ho}, +keywords = {User interface (UI), Computer-aided design (CAD), 3D engineering design, Best practices, Usability principles}, +abstract = {This study proposes usability principles for the user interfaces (UI) design of complex 3D parametric architectural design and engineering tools. Numerous usability principles have been developed for generic desktop or web applications. The authors tried to apply existing usability principles as guidelines for evaluating complex 3D design and engineering applications. However, the principles were too generic and high-level to be useful as design or evaluation guidelines. The authors, all with more than 10 or 30 years of experience with various CAD systems, selected and reviewed 10 state-of-the-art 3D parametric design and engineering applications and captured what they thought were best practices, as screenshots and videos. The collected best practices were reviewed through a series of discussion sessions. During the discussion sessions, UI design principles underlying the collected best practices were characterized in the line of existing UI principles. Based on the best practices and the derived common UI principles, a new set of refined and detailed UI principles were proposed for improving and evaluating 3D parametric engineering design tools in the future.} +} + +@misc{zhang_learning_2016, + title = {Learning {Deep} {Control} {Policies} for {Autonomous} {Aerial} {Vehicles} with {MPC}-{Guided} {Policy} {Search}}, + url = {http://arxiv.org/abs/1509.06791}, + doi = {10.48550/arXiv.1509.06791}, + abstract = {Model predictive control (MPC) is an effective method for controlling robotic systems, particularly autonomous aerial vehicles such as quadcopters. However, application of MPC can be computationally demanding, and typically requires estimating the state of the system, which can be challenging in complex, unstructured environments. Reinforcement learning can in principle forego the need for explicit state estimation and acquire a policy that directly maps sensor readings to actions, but is difficult to apply to unstable systems that are liable to fail catastrophically during training before an effective policy has been found. We propose to combine MPC with reinforcement learning in the framework of guided policy search, where MPC is used to generate data at training time, under full state observations provided by an instrumented training environment. This data is used to train a deep neural network policy, which is allowed to access only the raw observations from the vehicle's onboard sensors. After training, the neural network policy can successfully control the robot without knowledge of the full state, and at a fraction of the computational cost of MPC. We evaluate our method by learning obstacle avoidance policies for a simulated quadrotor, using simulated onboard sensors and no explicit state estimation at test time.}, + urldate = {2026-05-12}, + publisher = {arXiv}, + author = {Zhang, Tianhao and Kahn, Gregory and Levine, Sergey and Abbeel, Pieter}, + month = feb, + year = {2016}, + note = {arXiv:1509.06791 [cs.LG]}, + keywords = {Computer Science - Machine Learning, Computer Science - Robotics}, + file = {Preprint PDF:C\:\\Users\\tommy\\Zotero\\storage\\MJEEVG99\\Zhang et al. - 2016 - Learning Deep Control Policies for Autonomous Aerial Vehicles with MPC-Guided Policy Search.pdf:application/pdf;Snapshot:C\:\\Users\\tommy\\Zotero\\storage\\94W9UGJF\\1509.html:text/html}, +} + +@misc{IsaacLab, + author = {}, + title = {Isaac Lab | NVIDIA Developer --- developer.nvidia.com}, + howpublished = {\url{https://developer.nvidia.com/isaac/lab}}, + year = {c2026}, + note = {[Accessed 12-05-2026]}, + journal = {N/A} +} \ No newline at end of file diff --git a/figs/1_RGB.png b/figs/1_RGB.png new file mode 100644 index 0000000..a4b55d2 Binary files /dev/null and b/figs/1_RGB.png differ diff --git a/figs/2_DepthMap.png b/figs/2_DepthMap.png new file mode 100644 index 0000000..d842cec Binary files /dev/null and b/figs/2_DepthMap.png differ diff --git a/figs/3x3 map matrix.png b/figs/3x3 map matrix.png new file mode 100644 index 0000000..53227a4 Binary files /dev/null and b/figs/3x3 map matrix.png differ diff --git a/figs/3x3 map.png b/figs/3x3 map.png new file mode 100644 index 0000000..820a735 Binary files /dev/null and b/figs/3x3 map.png differ diff --git a/figs/App_Screenshots/0_Login_Screen.jpg b/figs/App_Screenshots/0_Login_Screen.jpg new file mode 100644 index 0000000..5a7c3bb Binary files /dev/null and b/figs/App_Screenshots/0_Login_Screen.jpg differ diff --git a/figs/App_Screenshots/1_Profile_Screen.jpg b/figs/App_Screenshots/1_Profile_Screen.jpg new file mode 100644 index 0000000..d59b7ab Binary files /dev/null and b/figs/App_Screenshots/1_Profile_Screen.jpg differ diff --git a/figs/App_Screenshots/2_1_Leaderboard_All.jpg b/figs/App_Screenshots/2_1_Leaderboard_All.jpg new file mode 100644 index 0000000..77ed8b3 Binary files /dev/null and b/figs/App_Screenshots/2_1_Leaderboard_All.jpg differ diff --git a/figs/App_Screenshots/2_2_1_Leaderboard_Friends_No_Alice.jpg b/figs/App_Screenshots/2_2_1_Leaderboard_Friends_No_Alice.jpg new file mode 100644 index 0000000..c04e793 Binary files /dev/null and b/figs/App_Screenshots/2_2_1_Leaderboard_Friends_No_Alice.jpg differ diff --git a/figs/App_Screenshots/2_2_2_Leaderboard_Friends_Alice.jpg b/figs/App_Screenshots/2_2_2_Leaderboard_Friends_Alice.jpg new file mode 100644 index 0000000..cbabc65 Binary files /dev/null and b/figs/App_Screenshots/2_2_2_Leaderboard_Friends_Alice.jpg differ diff --git a/figs/App_Screenshots/3_1_Achievements_Lifetime.jpg b/figs/App_Screenshots/3_1_Achievements_Lifetime.jpg new file mode 100644 index 0000000..844b793 Binary files /dev/null and b/figs/App_Screenshots/3_1_Achievements_Lifetime.jpg differ diff --git a/figs/App_Screenshots/3_2_Achievements_Monthly.jpg b/figs/App_Screenshots/3_2_Achievements_Monthly.jpg new file mode 100644 index 0000000..2706355 Binary files /dev/null and b/figs/App_Screenshots/3_2_Achievements_Monthly.jpg differ diff --git a/figs/App_Screenshots/4_1_Community_Friends.jpg b/figs/App_Screenshots/4_1_Community_Friends.jpg new file mode 100644 index 0000000..dae27fe Binary files /dev/null and b/figs/App_Screenshots/4_1_Community_Friends.jpg differ diff --git a/figs/App_Screenshots/4_2_1_Community_Requests_Receiving.jpg b/figs/App_Screenshots/4_2_1_Community_Requests_Receiving.jpg new file mode 100644 index 0000000..2369607 Binary files /dev/null and b/figs/App_Screenshots/4_2_1_Community_Requests_Receiving.jpg differ diff --git a/figs/App_Screenshots/4_2_2_Community_Requests_Making.jpg b/figs/App_Screenshots/4_2_2_Community_Requests_Making.jpg new file mode 100644 index 0000000..e2ba804 Binary files /dev/null and b/figs/App_Screenshots/4_2_2_Community_Requests_Making.jpg differ diff --git a/figs/App_Screenshots/5_Play_In_Person.jpg b/figs/App_Screenshots/5_Play_In_Person.jpg new file mode 100644 index 0000000..55bf70b Binary files /dev/null and b/figs/App_Screenshots/5_Play_In_Person.jpg differ diff --git a/figs/App_Screenshots/Bottom_Panel.png b/figs/App_Screenshots/Bottom_Panel.png new file mode 100644 index 0000000..b7c4cba Binary files /dev/null and b/figs/App_Screenshots/Bottom_Panel.png differ diff --git a/figs/App_Screenshots/Fried_Request_Box.png b/figs/App_Screenshots/Fried_Request_Box.png new file mode 100644 index 0000000..928c3b3 Binary files /dev/null and b/figs/App_Screenshots/Fried_Request_Box.png differ diff --git a/figs/Bluetoothframestructure-660x253.png b/figs/Bluetoothframestructure-660x253.png new file mode 100644 index 0000000..bf22e0b Binary files /dev/null and b/figs/Bluetoothframestructure-660x253.png differ diff --git a/figs/CameraLocalToWorld.png b/figs/CameraLocalToWorld.png new file mode 100644 index 0000000..cece3b9 Binary files /dev/null and b/figs/CameraLocalToWorld.png differ diff --git a/figs/CameraProjection.png b/figs/CameraProjection.png new file mode 100644 index 0000000..d740267 Binary files /dev/null and b/figs/CameraProjection.png differ diff --git a/figs/CameraProjection_SimilarTriangles.png b/figs/CameraProjection_SimilarTriangles.png new file mode 100644 index 0000000..654fc0e Binary files /dev/null and b/figs/CameraProjection_SimilarTriangles.png differ diff --git a/figs/CrouchDeformation_Plot.pdf b/figs/CrouchDeformation_Plot.pdf new file mode 100644 index 0000000..eff1b09 Binary files /dev/null and b/figs/CrouchDeformation_Plot.pdf differ diff --git a/figs/Database_Screenshot.png b/figs/Database_Screenshot.png new file mode 100644 index 0000000..a525335 Binary files /dev/null and b/figs/Database_Screenshot.png differ diff --git a/figs/DepthEstimationTests.pdf b/figs/DepthEstimationTests.pdf new file mode 100644 index 0000000..a414c28 Binary files /dev/null and b/figs/DepthEstimationTests.pdf differ diff --git a/figs/Finance/Discounted Payback Sensitivity.png b/figs/Finance/Discounted Payback Sensitivity.png new file mode 100644 index 0000000..e486fc5 Binary files /dev/null and b/figs/Finance/Discounted Payback Sensitivity.png differ diff --git a/figs/Finance/NPV Profile.png b/figs/Finance/NPV Profile.png new file mode 100644 index 0000000..f4457b3 Binary files /dev/null and b/figs/Finance/NPV Profile.png differ diff --git a/figs/Finance/Optimal_Cost_per_Game_vs_Elasticity.png b/figs/Finance/Optimal_Cost_per_Game_vs_Elasticity.png new file mode 100644 index 0000000..61e9971 Binary files /dev/null and b/figs/Finance/Optimal_Cost_per_Game_vs_Elasticity.png differ diff --git a/figs/Finance/Sensitivity_Analysis_Price_Elastic_Utility.png b/figs/Finance/Sensitivity_Analysis_Price_Elastic_Utility.png new file mode 100644 index 0000000..35e4eab Binary files /dev/null and b/figs/Finance/Sensitivity_Analysis_Price_Elastic_Utility.png differ diff --git a/figs/Finance/Sensitivity_Analysis_Price_Fixed_Utility.png b/figs/Finance/Sensitivity_Analysis_Price_Fixed_Utility.png new file mode 100644 index 0000000..ac4af53 Binary files /dev/null and b/figs/Finance/Sensitivity_Analysis_Price_Fixed_Utility.png differ diff --git a/figs/Finance/Sensitivity_Analysis_Utility_Fixed_Price.png b/figs/Finance/Sensitivity_Analysis_Utility_Fixed_Price.png new file mode 100644 index 0000000..2256ad0 Binary files /dev/null and b/figs/Finance/Sensitivity_Analysis_Utility_Fixed_Price.png differ diff --git a/figs/High-Level/Flow2.png b/figs/High-Level/Flow2.png new file mode 100644 index 0000000..1662894 Binary files /dev/null and b/figs/High-Level/Flow2.png differ diff --git a/figs/High-Level/SearchMode.png b/figs/High-Level/SearchMode.png new file mode 100644 index 0000000..7cd8d0f Binary files /dev/null and b/figs/High-Level/SearchMode.png differ diff --git a/figs/High-Level/ShootMode.png b/figs/High-Level/ShootMode.png new file mode 100644 index 0000000..94cceed Binary files /dev/null and b/figs/High-Level/ShootMode.png differ diff --git a/figs/High-Level/StatesList.png b/figs/High-Level/StatesList.png new file mode 100644 index 0000000..04bc187 Binary files /dev/null and b/figs/High-Level/StatesList.png differ diff --git a/figs/High-Level/TrackMode.png b/figs/High-Level/TrackMode.png new file mode 100644 index 0000000..25f8aa2 Binary files /dev/null and b/figs/High-Level/TrackMode.png differ diff --git a/figs/LinearTranslation_Plot.pdf b/figs/LinearTranslation_Plot.pdf new file mode 100644 index 0000000..fd288b4 Binary files /dev/null and b/figs/LinearTranslation_Plot.pdf differ diff --git a/figs/Occlusion_Test.pdf b/figs/Occlusion_Test.pdf new file mode 100644 index 0000000..5c4f96f Binary files /dev/null and b/figs/Occlusion_Test.pdf differ diff --git a/figs/RaycastGameView.png b/figs/RaycastGameView.png new file mode 100644 index 0000000..c10de61 Binary files /dev/null and b/figs/RaycastGameView.png differ diff --git a/figs/RaycastSceneView.png b/figs/RaycastSceneView.png new file mode 100644 index 0000000..970758b Binary files /dev/null and b/figs/RaycastSceneView.png differ diff --git a/figs/SyntheticDatasetOverview.pdf b/figs/SyntheticDatasetOverview.pdf new file mode 100644 index 0000000..890b856 Binary files /dev/null and b/figs/SyntheticDatasetOverview.pdf differ diff --git a/figs/Synthetic_F_Dark_Classification.pdf b/figs/Synthetic_F_Dark_Classification.pdf new file mode 100644 index 0000000..57392f6 Binary files /dev/null and b/figs/Synthetic_F_Dark_Classification.pdf differ diff --git a/figs/Synthetic_F_Dark_Confidence.pdf b/figs/Synthetic_F_Dark_Confidence.pdf new file mode 100644 index 0000000..adc12f0 Binary files /dev/null and b/figs/Synthetic_F_Dark_Confidence.pdf differ diff --git a/figs/VisDrone_F_Dark_Classification.pdf b/figs/VisDrone_F_Dark_Classification.pdf new file mode 100644 index 0000000..5600193 Binary files /dev/null and b/figs/VisDrone_F_Dark_Classification.pdf differ diff --git a/figs/VisDrone_F_Dark_Confidence.pdf b/figs/VisDrone_F_Dark_Confidence.pdf new file mode 100644 index 0000000..679d25c Binary files /dev/null and b/figs/VisDrone_F_Dark_Confidence.pdf differ diff --git a/figs/VisDrone_F_Light_Classification.pdf b/figs/VisDrone_F_Light_Classification.pdf new file mode 100644 index 0000000..f4990d9 Binary files /dev/null and b/figs/VisDrone_F_Light_Classification.pdf differ diff --git a/figs/VisDrone_F_Light_Confidence.pdf b/figs/VisDrone_F_Light_Confidence.pdf new file mode 100644 index 0000000..9567b94 Binary files /dev/null and b/figs/VisDrone_F_Light_Confidence.pdf differ diff --git a/figs/YawRotation_Plot.pdf b/figs/YawRotation_Plot.pdf new file mode 100644 index 0000000..e290f69 Binary files /dev/null and b/figs/YawRotation_Plot.pdf differ diff --git a/figs/env_daylight.png b/figs/env_daylight.png new file mode 100644 index 0000000..47e9896 Binary files /dev/null and b/figs/env_daylight.png differ diff --git a/figs/env_lowlight.png b/figs/env_lowlight.png new file mode 100644 index 0000000..1224b63 Binary files /dev/null and b/figs/env_lowlight.png differ diff --git a/figs/frame-format.png b/figs/frame-format.png new file mode 100644 index 0000000..c631870 Binary files /dev/null and b/figs/frame-format.png differ diff --git a/figs/risk-assessment.png b/figs/risk-assessment.png new file mode 100644 index 0000000..b1aac86 Binary files /dev/null and b/figs/risk-assessment.png differ diff --git a/figs/sensor_pipeline.pdf b/figs/sensor_pipeline.pdf new file mode 100644 index 0000000..bc596b8 Binary files /dev/null and b/figs/sensor_pipeline.pdf differ diff --git a/figs/synthetic_BoxF1_curve.png b/figs/synthetic_BoxF1_curve.png new file mode 100644 index 0000000..da1dae1 Binary files /dev/null and b/figs/synthetic_BoxF1_curve.png differ diff --git a/figs/synthetic_training_results.png b/figs/synthetic_training_results.png new file mode 100644 index 0000000..7de6c87 Binary files /dev/null and b/figs/synthetic_training_results.png differ diff --git a/figs/synthetic_val_batch0_pred.jpg b/figs/synthetic_val_batch0_pred.jpg new file mode 100644 index 0000000..5148d5d Binary files /dev/null and b/figs/synthetic_val_batch0_pred.jpg differ diff --git a/figs/visdrone-dataset-cover.jpg b/figs/visdrone-dataset-cover.jpg new file mode 100644 index 0000000..e1f0a32 Binary files /dev/null and b/figs/visdrone-dataset-cover.jpg differ diff --git a/figs/visdrone_BoxF1_curve.png b/figs/visdrone_BoxF1_curve.png new file mode 100644 index 0000000..c501ea8 Binary files /dev/null and b/figs/visdrone_BoxF1_curve.png differ diff --git a/figs/visdrone_training_results.png b/figs/visdrone_training_results.png new file mode 100644 index 0000000..171fe03 Binary files /dev/null and b/figs/visdrone_training_results.png differ diff --git a/figs/visdrone_val_batch0_pred.jpg b/figs/visdrone_val_batch0_pred.jpg new file mode 100644 index 0000000..6dd0178 Binary files /dev/null and b/figs/visdrone_val_batch0_pred.jpg differ diff --git a/main.tex b/main.tex index ec49cff..10668b7 100644 --- a/main.tex +++ b/main.tex @@ -1,99 +1,2450 @@ \documentclass{report_template_oxford} -\newacronym{3yp}{3YP}{Third-Year Project} -\title{3YP report template} -\subtitle{Anyhting or empty} -\author{Daniele De Martini} -\date{March 2025} +\usepackage{float} +\usepackage{tabularx} +\usepackage{wrapfig} +\usepackage{booktabs} +\usepackage{graphicx} +\usepackage{fontspec} +\usepackage{amsmath} +\usepackage[colorlinks=true, linkcolor=blue, citecolor=blue, urlcolor=blue]{hyperref} + +\title{Laser Tag using a Multiagent Drone System} +\subtitle{Report for the system and software design of a multiagent drone system to play Laser Tag} +\author{Shing Hei Rickie Chan, Thomas August, Rishabh Luthra, Richard Usherwood} +\date{March 2026} \begin{document} \maketitle +\pagenumbering{roman} +\newpage % Abstract % - Concise summary of report % - Naming of essential outcomes % - As short as possible while providing key points % - Less than 1 page -\pagenumbering{roman} -\newpage \addcontentsline{toc}{section}{Abstract} \fancyhead[C]{Student author of section} \section*{Abstract} - -\lipsum[1] - \newpage + \fancyhead[C]{} \tableofcontents - \newpage + \addcontentsline{toc}{section}{List of Figures} \listoffigures - \newpage + \addcontentsline{toc}{section}{List of Tables} \listoftables - \newpage + \addcontentsline{toc}{section}{Glossary} +\newacronym{3yp}{3YP}{Third-Year Project} +\newacronym{fov}{FoV}{Field of View} +\newacronym{swapc}{SWaP-C}{Size, Weight, Power, and Cost} +\newacronym{lidar}{LiDAR}{Light Detection and Ranging} +\newacronym{rgbd}{RGB-D}{Red Green Blue-Depth} +\newacronym{ir}{IR}{Infrared} +\newacronym{yolo}{YOLO}{You Only Look Once} +\newacronym{cnn}{CNN}{Convolutional Neural Network} +\newacronym{coco}{COCO}{Common Objects in Context} +\newacronym{onnx}{ONNX}{Open Neural Network Exchange} +\newacronym{imu}{IMU}{Inertial Measurement Unit} +\newacronym{npv}{NPV}{Net Present Value} +\newacronym{wacc}{WACC}{Weight Averaged Cost of Capital} +\newacronyn{tv}{TV}{Terminal Value} +\newacronym{irr}{IRR}{Internal Rate of Return} \printglossaries +\newpage + +\pagenumbering{arabic} % Introduction % - Provide background and motivation % - Provide boundaries and goals to the project % - Give a short overview of report structure -\newpage -\pagenumbering{arabic} -\fancyhead[C]{Student1 author of section} \section{Introduction} -\lipsum[1-5] +\fancyhead[C]{Student2 author of section} +\subsection{An awesome Acronym} +You can use acronyms for your \gls{3yp} exactly as I did here. +You can define them in the header of this file and they will appear in the glossary section. +\newpage + +\section{Literature Review} +\newpage + +\section{Gameplay} % Ritchie +\fancyhead[C]{Richard Usherwood} +\subsection{Overview} +Players are equipped with "Laser Guns" (Infrared emitters that fire encoded data), and helmets and vests containing Infrared sensors. The drones are equipped with "Turrets" that fire emit Infrared radiation (see Section \ref{Turret} and Infrared sensors as well. When they are not flying, they are dormant in a "standby location" where they can have batteries replaced by employees if required. The drones, guns, helmets and vests connect via Wi-Fi to a central server. If the player is hit, they must navigate to a designated "timeout" area of the maze, in which they are safe from drones, and wait for 10 seconds. The player's gun and helmet/vest sensors are connected via the central server, so, when a player is hit, their gun will not work until their timeout has been completed (triggered by the player shooting a receiver in the timeout zone twice, more than 10 seconds apart). Play takes place in a maze built with 5 metre high felt-covered ply-wood walls in a converted warehouse. The drones fly overhead (separated from players by a net at three metres height for safety, see Section \ref{risk-assessment}). The players play cooperatively, against the drones.\newline + + +Two "game modes" exist: "Wave Mode" and "Objective Mode". These are summarised in the following sections. +\subsection{Wave Mode} +In "Wave Mode", the players must attempt to defeat a number of drones, released in an order designed to be both challenging and engaging. When the drone is hit, it returns to its standby location, where it will remain. If all of the players are timing out at the same time (having been hit), they lose. If all of the drones have been hit, they win. This constitutes a single wave. The players can choose from a catalogue of waves (in future accessible through the companion app, see Section \ref{app}), ranging from tutorial level to advanced. Each level will be marked with a numerical difficulty rating. This allows a team to end a game with an understandable, clear metric of how well they performed: the difficulty rating of the hardest wave in which they won. This will also serve as a clear metric of a team's improvement with time, encouraging them to return. In future, this will be displayed in the companion app, allowing players to compare metrics with their friends. + +\subsection{Objective Mode} +In "Objective Mode", the players must attempt to navigate the maze to complete objectives, such as "Hold this button for 5 seconds", or "Shoot this target on the wall", which will be communicated to the players via speakers (in future they will be communicated via a LED display embedded in the Laser-Guns). They must complete all objectives within a defined time to "pass" the level. While they are completing these objectives, the drones are flying overhead and attempting to shoot at the players, just as in Wave Mode. Similarly, the players must timeout for 10 seconds in a particular area of the maze if hit, and the drones will exit the game if hit, but will return after a short timeout. If all players timeout at once, they lose; if they exceed the time limit for the level, they lose; if they complete all objectives, they win. If they win, they will progress to a harder level. Just as in "Wave Mode", the levels will be designed and play-tested to be both challenging, engaging; a catalogue of levels marked with a numerical difficulty can be selected in-app.\newline + +\subsection{Difficulty Scaling} +Since the levels increase in difficulty, there is little need to scale difficulty according to a players' skill: if the players are inexperienced, they will only play easy levels, and there will be levels to suit players of all skill levels. However, the difficulty of the levels may need to change according to the number of players in a team. This can be achieved in a number of ways. For example, the number of drones could be adjusted, the top speed of the drones could be capped, and artificial inaccuracy could be added to the shooting of the drones. \newline + +It is very difficult to know which methods of adjusting difficulty will result in a game that is both enjoyable and balanced, for a range of numbers of people. Hence, deciding exactly how to perform this adjustment will require play-testing, in the arena, once it has been created. +\newpage +\section{System Architecture and Integration} \label{system} % Everyone except Ritchie + +\subsection{Simulation Representation of the Hardware} %Rickie +\subsubsection{Geometric and Physical Abstraction} +\subsubsection{Propulsion and Motion Representation} +\subsubsection{Collision and Sensor Simplifications} + +\newpage + +%%%%%%%%%----------------End of System Architecture---------------%%%%%%%%% + +\section{Drone Hardware and Electronics Design} % Rickie +\fancyhead[C]{Shing Hei Rickie Chan} + +\subsection{Context} + +The project decision was to develop a custom drone hardware design in preference to using an existing commercial platform. This was motivated by the need to co-design the airframe, electronics, sensing equipment, and game-specific payload around the requirements of an indoor multi-agent laser-tag system. Various options may offer good flight performance and easy maintenance, but are generally optimized for less intense activities and outdoor environments, and therefore provide limited flexibility for integrating custom sensing, weapon-tagged hardware, and protective structures. + +In addition, commercial drones tend to be quite closed off in terms of hardware and software access - modifications would require a complete investigation into the drone design before implementations, which would pose a challenge given the time-frame of the project. Designing our own platform allowed more freedom to choose components, organize the internal layout, and include additional features necessary to the game-play. + +% - add additional references to an investigation into commercial platforms +% - conduct a pros and cons list for the final decision +% - include references +% - ensure overall flow makes sense + +\subsection{Design Objectives and Constraints} +\subsubsection{Operational Requirements} + +At core level, the drone design must be able to achieve basic drone operations for game-play - being able to function as a usable aerial game platform within an indoor environment: +\begin{itemize} + \item sufficient thrust for stable flight + \item reliable movement for indoor environment + \item have required electronics and payload onboard platform + \item enough battery-life for meaningful gameplay +\end{itemize} + +\subsubsection{Safety Constraints} + +As the drone is intended to operate indoors in relative proximity to players during game-play, safety became a top priority. It was vital to reduce risks associated with collisions, exposed components, poor landings, and potential failure during operation. This led to a number of safety related constraints that influenced the overall drone design and the way the game is played: +\begin{itemize} + \item \textbf{Operation around players: } The drone is intended to operate in an indoor environment rather than large spacious areas. This drastically increases the proximity between players and drones which poses as an immediate safety concern. + \item \textbf{Close proximity to obstacles: } The environment itself introduces additional safety concerns. The drone would need to move around walls, corners, and other potential obstacles - which increases the risk of potential collisions during game-play. + \item \textbf{Protection for components: } One major safety constraint was reducing the risk of exposed components such as propellers and wires. The blade guards became an important part of the design, reducing both the chance of injury and risk of disabling the drone during minor collisions. + \item \textbf{Stable recovery and landing: } It was vital for the drone to be able to return to its post (or battery recharging station) reliably, and land safely after being disabled or encounter an error. The landing structure had to be considered from a safety point of view - hence a stable geometry would help reduce the chance of drone damage. +\end{itemize} + +\subsubsection{Game-play Requirements} + + The drone needs to be a capable opponent - able to dodge, attack and wander throughout the arena - and able to support the systems needed for the overall project itself (which includes being cost-effective). This led to several requirements that influences the size, layout, performance, and maintainability of the final design. +\begin{itemize} + \item \textbf{Indoor Movement: } Contrary to the safety requirement, the drone must also be a capable opponent rather than a still target. This means the design must be able to allow for navigation and some form of evasive movement. This poses as a tradeoff between gameplay and safety. + \item \textbf{Visibility and challenge: } The drone had to be large and visible enough for players to clearly recognize the target during gameplay, while still being agile enough to move around. A design too small would be difficult to engage while a design too large or too slow would reduce gameplay quality. + \item \textbf{Supporting game systems and battery: } The drone needs to carry additional hardware required for gameplay, such as IR transmitters and receivers, cameras, sensors, and onboard computing. These systems add weight and take up internal space. In addition, the design needs to allow for enough operating time for meaningful game-play. + \item \textbf{Easy maintenance and replace-ability: } Given the game is a multi-agent system rather than a single platform, the design needs to remain practical to maintain, to repair, and to replace. Minor damage during operation should not require a whole drone to be rebuilt, so replaceable parts and a maintainable layout becomes an important constraint. +\end{itemize} + +\subsubsection{Simulation Scope and General Design Assumptions} + +The project was carried out mainly through simulation; the hardware design was developed as a realistic engineering model rather than as a fully built and tested prototype. This means that the design was based on CAD modeling, component data sheets, and estimated performance values through online data and program testing. The simulation provided a means of presenting how the drone would be integrated into the wider system consistently. As a result, some real-world effects, such as full electronics integration, dynamic flight behavior, and measured sensor performance, were simplified or left for future work. + +\subsubsection{Summarized Table for Design Criteria} + +\begin{table}[htbp] +\centering +\caption{Summarised starter design criteria for the drone platform.} +\label{tab:starter_design_criteria} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l X @{}} +\toprule +\textbf{Design Parameter} & \textbf{Target / Requirement} \\ +\midrule +Operating environment & Indoor arena with close proximity to players, walls, and obstacles \\ +Operational role & Stable and manoeuvrable aerial platform for indoor gameplay \\ +Configuration & Compact quadrotor platform \\ +Maximum mass & $\leq 4.0$ kg \\ +Maximum width & $\leq 600$ mm \\ +Target cost per unit & \pounds300--\pounds500 \\ +Target game duration & 45 min \\ +Target drone endurance & 8-10 min before recharge \\ +Visibility requirement & Large enough to be clearly visible for indoor game-play \\ +Internal space requirement & Sufficient internal volume for onboard electronics \\ +Safety requirement & Safe indoor operation, protected moving parts, and stable landing capability \\ +Maintainability requirement & Easy maintenance with cheap replaceable damaged parts \\ +Structural requirement & Airframe must support normal flight loads and minor impact conditions \\ +Game-play requirement & Agile enough to act as a believable and challenging in-game opponent \\ +Simulation requirement & Geometry suitable for representation in simulation \\ +\bottomrule +\end{tabularx} +\end{table} + +\subsection{Electronics Design and Component Selection} +\subsubsection{Propulsion System} + +Since the drone was intended to operate in relatively confined spaces and act as an active game-play opponent, the propulsion system needed enough thrust for stable flight while allowing rapid responsive movement. A four-rotor configuration was selected as the most practical solution in avoiding the additional mechanical and control complexity that would come with more unusual multi-rotor arrangements. + +\paragraph{Motor Selection} + +The motor is required to provide a large thrust margin while remaining compact enough to fit in a tight rotor-arm layout. From the design criteria, the drone mass was limited to 4.0kg which corresponds to a weight of approximately +\[ +W = mg = 4.0 \times 9.81 = 39.2~\text{N}. +\] +For a quadrotor configuration with a target thrust-to-weight ratio of approximately 2:1, the total thrust was therefore around 78.5 N, or around 19.6 N per motor. + +\begin{table}[htbp] +\centering +\caption{Motor specifications. Data adapted from the BrotherHobby Avenger 2806.5 manufacturer specification \cite{brotherhobby_avenger28065}.} +\label{tab:motor_specifications} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Parameter} & \textbf{Value} & \textbf{Design relevance} \\ +\midrule +Selected motor & BrotherHobby Avenger 2806.5 1300KV & Main propulsion motor \\ +Motor type & Brushless & Suitable for multirotor propulsion \\ +KV rating & 1300KV & Suitable for thrust-focused operation \\ +Mass & 41 g & Four motors contribute approximately 164g \\ +Cell compatibility & 4--6S LiPo & Sets the required battery range for the final power system \\ +Bolt & M3, 19 mm $\times$ 19 mm & Defines the motor mounting interface \\ +Wire specification & 18 AWG, 20 cm & ESC and wiring \\ +Target thrust per motor & $\approx 19.6$ N & 4 motors provides approximately 78.5 N \\ +\bottomrule +\end{tabularx} +\end{table} + +%%%%% FIGURE: Manufacturer image/ specification drawing of the BrotherHobby Avenger 2806.5 motor + +The Avenger 2806.5 was selected because it provided a strong thrust margin without requiring an excessively large motor. Each motors has 41g mass, keeping the four-motor set reasonably light at 164g before propellers and mounting hardware. Its 19mm x 19mm mounting pattern also gave clear interface for motor mount design. + +\paragraph{Propeller Choice} + +The propeller was selected based on geometry as it directly affects the thrust, clearance, and overall rotor-arm design. The propeller was required to provide enough lift when paired with the selected motor, while remaining sizeable for an indoor drone platform. + +We selected using an 8x4x3 propeller, where the notation refers to 8 inch diameter, 4 inch pitch, and 3-blade configuration. A manufacturer dataset for an HQProp 8x4x3 propeller was used as a reference for dimensions and mass, which formed the basis for the certain assumptions related to the rotor-arm design. + +\begin{table}[htbp] +\centering +\caption{8$\times$4$\times$3 propeller specifications. Data from an HQProp 8$\times$4$\times$3 propeller dataset \cite{hqprop_8x4x3}.} +\label{tab:propeller_specifications} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Parameter} & \textbf{Reference Value} & \textbf{Design Relevance} \\ +\midrule +Propeller geometry & 8$\times$4$\times$3 & Defines the intended propeller size and type \\ +Diameter & 8 inch & Sets swept area and required clearance from the airframe \\ +Pitch & 4 inch & Moderate pitch suitable for thrust-focused operation \\ +Blade count & 3 blades & Provides higher thrust capability than a comparable 2-blade propeller \\ +Reference material & Polycarbonate & Representative lightweight multirotor propeller material \\ +Reference mass & 13 g & Four propellers contribute approximately 52 g \\ +Rotation requirement & 2 CW + 2 CCW & Required for balanced quadrotor operation \\ +\bottomrule +\end{tabularx} +\end{table} + +%%%%% FIGURE: Representative 8×4×3 propeller geometry used for sizing and clearance assumptions. Manufacturer data from an HQProp 8×4×3 propeller was used as a reference dataset for mass, hub dimensions, and shaft compatibility. + +The 8x4x3 propeller geometry was chosen as this motor-prop configuration matched the thrust specifications of the design while also remaining within a practical size range for the airframe. The 8-inch diameter increased the swept area while the 3-blade configuration helped support higher thrust within a limited diameter - which improved lift capability without excessive propeller span in an indoor environment. + +\paragraph{Validity Check for Motor-Prop Configuration} + +To check whether the assumed thrust of the motor-propeller configuration was physically reasonable, a static propeller thrust coefficient estimate was used. For a propeller operating in static conditions, the thrust can be approximated using: + +\[ +T = C_T \rho n^2 D^4 +\] + +where \(T\) is thrust, \(C_T\) is thrust coefficient, \(\rho\) is air density, \(n\) is rotational speed (revolutions per second), \(D\) is propeller diameter. \cite{mit_propeller_performance}. + +From the selected propeller geometry, the diameter was +\[ +D = 8~\text{in} = 0.2032~\text{m} +\] + +The standard sea-level air density was assumed as +\[ +\rho = 1.225~\text{kg m}^{-3}. +\] + +The target thrust per motor was taken as previously calculated +\[ +T = 19.6~\text{N}, +\] + +Rearranging the equations for n gives + +\[ +n = \sqrt{\frac{T}{C_T \rho D^4}}. +\] + +The ideal no-load speed of the motor can be estimated from the motor \(K_V\) rating: + +\[ +RPM_0= K_V V +\] + +For the selected 1300KV motor on a 4S LiPo supply, + +\[ +RPM_0 = 1300 \times 14.8 = 19240~\text{rpm}. +\] + +However, this is an ideal case. In practice, the motor will not reach this speed when driving the propeller as the propeller applies aerodynamic load. A factor is included to account for this: + +\[ +RPM_{\text{loaded}} = \eta_{\text{rpm}} RPM_0, +\] + +where \(\eta_{\text{rpm}}\) represents the fraction of no-load speed achieved under propeller load. As a quick estimate, factors between 0.75 and 0.90 (in increments of 0.05) were considered. + +\begin{table}[htbp] +\centering +\caption{Estimated loaded motor speeds for different loaded RPM factors.} +\label{tab:loaded_rpm_factors} +\renewcommand{\arraystretch}{1.15} +\begin{tabular}{@{} c c @{}} +\toprule +\textbf{Loaded RPM Factor, \(\eta_{\text{rpm}}\)} & \textbf{Loaded RPM} \\ +\midrule +0.75 & 14,430 rpm \\ +0.80 & 15,392 rpm \\ +0.85 & 16,354 rpm \\ +0.90 & 17,316 rpm \\ +\bottomrule +\end{tabular} +\end{table} + +As there was no given exact thrust coefficients,therefore we tested using 0.100, 0.125, and 0.150 + +\begin{table}[htbp] +\centering +\caption{Estimated thrust per motor for different loaded RPM factors and thrust coefficients.} +\label{tab:motor_prop_validity_check} +\renewcommand{\arraystretch}{1.15} +\small +\begin{tabular}{@{} c c c c c @{}} +\toprule +\textbf{\(\eta_{\text{rpm}}\)} & \textbf{Loaded RPM} & \textbf{\(T\), \(C_T=0.100\)} & \textbf{\(T\), \(C_T=0.125\)} & \textbf{\(T\), \(C_T=0.150\)} \\ +\midrule +0.75 & 14,430 rpm & 12.1 N & 15.1 N & 18.1 N \\ +0.80 & 15,392 rpm & 13.7 N & 17.2 N & 20.6 N \\ +0.85 & 16,354 rpm & 15.5 N & 19.4 N & 23.3 N \\ +0.90 & 17,316 rpm & 17.4 N & 21.7 N & 26.1 N \\ +\bottomrule +\end{tabular} +\end{table} + +From the table 4 and 5, the target thrust of approximately \(19.6~\text{N}\) per motor is not achieved under the most conservative assumptions(where \(C_T = 0.100\)). However, it becomes achievable for higher thrust coefficient values. For \(C_T = 0.125\), the combination reaches approximately \(19.4~\text{N}\) at 85\% of the no-load speed. For \(C_T = 0.150\), the target exceeded at around 80\% no load speed. + +This suggests that the target max thrust of \(19.6~\text{N}\) is theoretically plausible for this motor-propeller configuration on a 4S supply - but only when the real thrust coefficient is closer to mid-range values and the motor can maintain between 80--85\% of its no-load speed under load. This calculation does not experimentally validate the propulsion system as the real thrust would depend on a number of other factors such as ESC behavior and battery voltage sag. + +However, the target max value is not the same as minimum thrust required for flight. Given the total weight is approximately \(39.2~\text{N}\), the hover thrust required per motor is \(9.8~\text{N}\) for a quadrotor configuration. This means the selected propulsion configuration has a massive theoretical margin above the hover requirement. Even if the real thrust is lower than the assumed \(19.6~\text{N}\), the drone should still perform admirably, though additional margin would be needed for maneuvering, disturbance rejection, and stable control. However, this proves that the 2:1 thrust-to-weight ratio gives a large and safe tolerance. + +\paragraph{ESC Selection} + +The ESC is used to control the speed of each motor and provide fast response to throttle commands from the flight controller. Since the propulsion system uses four motors, the design requires one ESC per motor. The selected ESC was the LittleBee Spring 40A. + +\begin{table}[htbp] +\centering +\caption{ESC specifications. Data from available supplier specifications \cite{littlebee_spring_40a}.} +\label{tab:esc_specifications} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Parameter} & \textbf{Manufacturer / Supplier Specification} & \textbf{Design Relevance} \\ +\midrule +Selected ESC & LittleBee Spring 40A & Speed controller for each brushless motor \\ +Input voltage & 2--6S LiPo & Compatible with the intended multirotor power range \\ +Continuous current & 40 A & Provides current capacity for high-throttle motor operation \\ +Size & Approximately 35 mm $\times$ 17 mm & Compact \\ +Weight & Approximately 12 g with wires & Low mass \\ +Supported protocols & OneShot, MultiShot, DShot & Suitable for fast multirotor throttle control \\ +\bottomrule +\end{tabularx} +\end{table} + +As shown in the table 6, the available LittleBee Spring 40A specifications list \(2-6~\text{S}\) LiPo input, \(40~\text{A}\) continuous current, with compact dimensions. + +%%%%%Figure: LittleBee Spring 40A ESC selected for motor speed control. Its compact size and 2–6S input range made it suitable for integration with the quadrotor propulsion system. + +This ESC was chosen as it matched the propulsion system requirements while remaining compact enough to fit within the airframe. However, as the ESC has no built-in BEC, the lower voltage electronics must be powered through a separate voltage regulation stage, which is addressed in the power system design. + +\subsubsection{Power System} + +The power system must be designed to supply both the high-current propulsion system and the lower-voltage onboard electronics. The propulsion system requires direct battery power for the four ESCs and brushless motors. Meanwhile, the onboard computer, sensors, and game-specific electronics must receive regulated lower-voltage supplies. As a result, the power system will be split into two main parts: a high power battery path and a regulated path using voltage conversion. + +\paragraph{Battery Selection} + +The battery selection was driven by the propulsion system as it was expected the motors and ESCs would consume significantly more power than other onboard electronics. The battery had to provide a suitable voltage and discharge capability for the hardware, while also remaining practical in terms of mass, size and internal packaging. A 3S LiPo option was initially considered as earlier propulsion combinations included 3S-compatible specifications. However, once the final motor-propeller configuration was selected, the 3S option was disregarded for a more suitable 4S 5000 mAH LiPo battery. This provided nominal voltage for \(14.8~\text{V}\), matching the motor and ESC requirements more appropriately, while maintaining a target capacity for approximately 10 minutes of drone operation before recharge. +\begin{table}[htbp] +\centering +\caption{4S 5000 mAh LiPo Battery specifications. Data adapted from commercially viable sources \cite{tattu_bashing_4s_5000mah, gensace_4s_5000mah}.} +\label{tab:battery_specifications} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Parameter} & \textbf{Representative Specification} & \textbf{Design Relevance} \\ +\midrule +Battery type & LiPo battery pack & Suitable for high-current drone propulsion \\ +Cell count & 4S / 4 cells & Matches propulsion requirements \\ +Nominal voltage & 14.8 V & Used for motor speed and power-system calculations \\ +Capacity & 5000 mAh / 5 Ah & Supports the target endurance before recharge \\ +Representative mass range & 390--589 g & Gives a realistic range for mass \\ +Representative dimensions & 32 $\times$ 42 $\times$ 132 mm to 138 $\times$ 46 $\times$ 50 mm & realistic range for battery bay sizing and packaging \\ +Battery count & 1 pack per drone & Simplifies packaging and recharge \\ +\bottomrule +\end{tabularx} +\end{table} + +%%%%%FIGURE:4S 5000mAH Battery - Power system modeled after selected Battery choice + +This battery was selected as a representative design choice as it matched the voltage requirements of the final propulsion system. The \(14.8~\text{V}\) is suitable for the selected ESC and motor configuration while the \(5000~\text{mAh}\) also provided the target \(10~\text{minutes}\) of drone operation before recharge. The mass range of \(390-589~\text{g}\) was also acceptable, leaving more than enough mass capacity for other components of the drone. + +\paragraph{Proving Endurance} + +To prove the 5000mAH capacity can theoretically last around 10 minutes of flight time before recharge, we may use the representative data. + +For a 4S 5000 mAh LiPo battery, the nominal voltage is \(14.8~\text{V}\) and the capacity is \(5~\text{Ah}\). The nominal battery energy is therefore +\[ +E=VC = 14.8 \times 5 = 74~\text{Wh} +\] + +In practice, it is not recommended to fully discharge a LiPo battery as doing so may reduce its lifespan. We may assume that 80\% of the nominal capacity is usable, the available energy becomes +\[ +E_{\text{usable}} = 0.8 \times 74 = 59.2~\text{Wh} +\] + +As per the requirement, the target endurance before recharge was approximately 10 minutes, or +\[ +t = \frac{10}{60} = 0.167~\text{h} +\] + +The maximum average power draw is therefore +\[ +P_{\text{avg,max}} = \frac{E_{\text{usable}}}{t} +\] +\[ +P_{\text{avg,max}} = \frac{59.2}{0.167} \approx 355~\text{W}. +\] + +The corresponding current draw is +\[ +I_{\text{avg}} = \frac{P_{\text{avg,max}}}{V} +\] +\[ +I_{\text{avg}} = \frac{355}{14.8} \approx 24~\text{A}. +\] + +The theoretical continuous current capability of the battery can be estimated from its C-rating. Consider a \(50~\text{C}\) discharge rating: + +\[ +I_{\text{max}} = 5 \times 50 = 250~\text{A}. +\] + +This suggests that the battery is theoretically capable of supplying the required current for the propulsion system, as the estimated average current is much lower than the continuous discharge limit. However, the main limiting factor is not the maximum current capability, but the total available energy. Therefore, achieving the 10 minute target depends on the average power consumption of all onboard electronics - keeping below approximately \(355~\text{W}\). + +\paragraph{Power distribution} + +We require a component for power distribution used to route the main battery output to the four ESCs safely and with enough current margin. Since each motor is driven by a separate ESC, a PDB must be able to supply the combined current demand of all propulsion channels. + +Given the ESCs are rated \(40~\text{A}\) each, the combined theoretical maximum ESC demand is: + +\[ +4\times40=160\text{A} +\] + +We require a high-current PDB, which was chosen to be the Holybro Power Distribution Board 300A. It is specified with a \(300~\text{A}\) continuous current rating, \(1000~\text{A}\) burst rating,\(10~\text{oz}\) copper PCB design, and XT90/XT30 connector options. The \(300~\text{A}\)continuous rating gives a clear margin above the theoretical maximum ESC demand. + +\begin{table}[htbp] +\centering +\caption{PDB specifications. Data from the Holybro PDB 300A specification \cite{holybro_pdb_300a}.} +\label{tab:pdb_specifications} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Parameter} & \textbf{Manufacturer / Supplier Specification} & \textbf{Design Relevance} \\ +\midrule +Selected PDB & Holybro Power Distribution Board 300A & Main PDB \\ +Continuous current rating & 300 A & Provides margin above theoretical maximum \\ +Burst current rating & 1000 A & Provides tolerance for short-duration spikes \\ +PCB design & 10 oz copper & Safe method of wiring \\ +Connector options & XT90 and XT30 options available & Main connection route \\ +Mounting holes & M3 mounting holes & Main attachment to drone hull \\ +\bottomrule +\end{tabularx} +\end{table} + +%%%%%Figure X: Holybro Power Distribution Board 300A selected for high-current battery-to-ESC power distribution. + +It should be noted that the PDB is responsible for distributing the main battery power. Other components such as the onboard computer, sensors and other electronics may require regulated lower-voltage supplies. Direct connection may cause damage to the components. + +\newpage -\begin{figure} +\paragraph{Voltage Regulation} + +Voltage regulation is vital for ensuring the integrity of more sensitive electronics. The 4S LiPo battery supplies \(14.8~\text{V}\) which is suitable for the propulsion system but is too high for onboard electronics which require \(5~\text{V}\). For this reason, we require a dedicated step-down regulator to separate the low-voltage electronics from the high-voltage system. A good regulator considered is the Pololu D24V90F5 \(5~\text{V}\) regulator which could be used in a real prototype, as its input voltage range is compatible with the 4S battery system. + +\begin{table}[htbp] +\centering +\caption{ 5 V step-down regulator specifications. Data from Pololu D24V90F5 manufacturer \cite{pololu_d24v90f5}.} +\label{tab:voltage_regulator_specifications} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Parameter} & \textbf{Manufacturer Specification} & \textbf{Design Relevance} \\ +\midrule +Regulator & Pololu D24V90F5 & 5 V step-down regulator \\ +Regulator type & Step-down / buck regulator & steps down the higher 4S battery voltage \\ +Input voltage range & 5--38 V & Compatible with the 14.8 V 4S LiPo battery \\ +Output voltage & Fixed 5 V & Suitable for the Raspberry Pi and other 5 V electronics \\ +Efficiency & 80--95\% & Reduces power loss and heating \\ +Size & 40.6 mm $\times$ 20.3 mm $\times$ 7.6 mm & Sizable for integration into drone electronics circuit \\ +Weight & Approximately 4.8 g & Low mass contribution to the overall drone design \\ +\bottomrule +\end{tabularx} +\end{table} + +%%%%%FIGURE: 5V, 9A Step-Down Voltage Regulator D24V90F5 + +Pololu D24V90F5 serves as a suitable regulator as it can step the \(14.8~\text{V}\) 4S battery Voltage down to a stable \(5~\text{V}\) voltage. It has an input range of \(5-38~\text{V}\) which is compatible with the main battery while the current output is suitable for the Raspberry Pi, sensors, and other electronics. + +\paragraph{Power-system Summary} + +The final power system will be divided into two main sections: A high-current propulsion path and a low-voltage electronics path. The propulsion path directly draws power from the battery into the ESCs and motors, while the electronics path step-down the \(14.8~\text{V}\) Battery voltage to \(5~\text{V}\) for onboard computer and other voltage sensitive electronics. + +\begin{table}[htbp] +\centering +\caption{Summary of the drone power-system architecture.} +\label{tab:power_system_summary} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l l X @{}} +\toprule +\textbf{Power System Component} & \textbf{Selected Choice} & \textbf{Main Role} \\ +\midrule +Main battery & 4S 5000 mAh LiPo & Supplies the entire electronic system \\ +High-current distribution & Holybro PDB 300A & Distributes battery power to the four ESCs \\ +Motor control & 4 $\times$ LittleBee Spring 40A ESCs & Controls power delivery to each brush-less motor \\ +Propulsion loads & 4 $\times$ brush-less motors & Generate lift and maneuvering thrust \\ +Voltage regulation & Pololu D24V90F5 5 V regulator & Steps battery voltage down to a regulated 5 V \\ +\bottomrule +\end{tabularx} +\end{table} + +%%%%%Figure: Perhaps include an image of the power system layout + +\subsubsection{Onboard Computing and Communication} + +Before investigating deeper into the topic of onboard computing and communication, it is vital to define its role within the overall drone system. Each drone is required to have a local processing unit that handles specific tasks that needed to happen directly on the drone, such as sensor processing, low-to mid-level control, and execution of pre-trained control or perception models during game-play. This includes responding to sensor inputs, player tracking, and carrying out motion commands in real time. + +However, as explained in other sections, the drone is not intended to make all these decisions independently onboard. High-level control (i.e. game logic and drone coordination) will be handled via a central server housed outside the arena. The onboard computer would therefore be required to communicate drone states, sensor data, and status updates to the server while simultaneously receiving instructions. This meant that the onboard companion computer needed to provide more capability than a simple micro-controller, while still remaining light, compact and inexpensive. + +\paragraph{Onboard Computer} + +Several hardware options were considered for the onboard computer. The main choice was between an Arduino-based micro-controller and Raspberry Pi single-board computer. Arduino boards are attractive as they are generally low-cost, easily programmable, lightweight and generally suitable for direct hardware control. However, they lacked the necessary processing power and memory to run pre-trained models, and often require additional modules for Wi-Fi communication. They also lacked camera and high-level software support. + +A two-board Arduino setup was considered, where one board would handle lower-level hardware control and another would manage communication or higher-level tasks. However this would increase general complexity in wiring and packaging while still not solving the main processing limitation. For this reason, the design moved towards investigating the usage of Raspberry Pi. + +\begin{table}[htbp] +\centering +\caption{Arduino options considered. Data from Arduino product specifications \cite{arduino_uno_rev3, arduino_uno_r4_wifi}.} +\label{tab:arduino_comparison} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l X X @{}} +\toprule +\textbf{Parameter} & \textbf{Arduino Uno Rev3} & \textbf{Arduino Uno R4 WiFi} \\ +\midrule +Processing unit & ATmega328P microcontroller & Renesas RA4M1 Arm Cortex-M4 microcontroller \\ + +Clock speed & 16 MHz & 48 MHz main core; ESP32-S3 up to 240 MHz for wireless module \\ + +Memory & 32 KB flash, 2 KB SRAM, 1 KB EEPROM & 256 KB flash, 32 KB RAM, 8 KB EEPROM on main MCU \\ + +Integrated wireless modules & None; external Wi-Fi/Bluetooth module required & Built-in Wi-Fi and Bluetooth \\ + +I/O interfaces & GPIO, PWM, analog inputs & GPIO, PWM, analog inputs \\ + +Camera support & No camera interface & No Raspberry Pi-style camera/software ecosystem \\ + +Weight & Approximately 25 g & Approximately 48 g \\ + +Approx price & \pounds20--\pounds25 & \pounds25--\pounds35 \\ +\bottomrule +\end{tabularx} +\end{table} + +\begin{table}[htbp] +\centering +\caption{Comparison of Raspberry Pi single-board computer. Data from official Raspberry Pi \cite{raspberrypi4_specs, raspberrypi5_specs}.} +\label{tab:raspberrypi_comparison} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l X X @{}} +\toprule +\textbf{Parameter} & \textbf{Raspberry Pi 4 Model B} & \textbf{Raspberry Pi 5} \\ +\midrule +Processor & Broadcom BCM2711 quad-core Cortex-A72 64-bit SoC & Broadcom BCM2712 quad-core Cortex-A76 64-bit SoC \\ + +Clock speed & 1.8 GHz & 2.4 GHz \\ + +Relative performance & sufficient for deployed models & Approximately 2--3$\times$ CPU performance relative to Raspberry Pi 4 \\ + +Memory options & 1 GB, 2 GB, 4 GB, or 8 GB LPDDR4 & 1 GB, 2 GB, 4 GB, 8 GB, or 16 GB LPDDR4X \\ + +Wireless LAN & 2.4 GHz and 5.0 GHz IEEE 802.11ac Wi-Fi & Dual-band 802.11ac Wi-Fi \\ + +Bluetooth & Bluetooth 5.0, BLE & Bluetooth 5.0, BLE \\ + +GPIO & Raspberry Pi standard 40-pin GPIO header & Raspberry Pi standard 40-pin GPIO header \\ + +Camera interface & 2-lane MIPI CSI camera port & 2 $\times$ 4-lane MIPI camera/display transceivers \\ + +USB & 2 $\times$ USB 3.0, 2 $\times$ USB 2.0 & 2 $\times$ USB 3.0, 2 $\times$ USB 2.0 \\ + +Approximate cost & From \$35, depending on RAM option & From \$45, depending on RAM option \\ + +\bottomrule +\end{tabularx} +\end{table} + +Two main Rasperry Pi single-board computers were considered, the Raspberry Pi 4 Model B and the Raspberry Pi 5 - specs are shown in Table~\ref{tab:raspberrypi_comparison}. + +Despite the strong performance offered by the Raspberry Pi 5, its additional computing capabilities were not considered important as the project was using pre-trained models rather than training onboard. The \textbf{Raspberry Pi 4 Model B} was chosen as the onboard computer as it provided a good balance between processing, cost and integration. In addition, it provided the required Wi-Fi, GPIO, USB, and camera interfaces, while being easier to power and package inside the drone. + +%%%%%FIGURE: Raspberry Pi 4 Model B +%%%%%FIGURE: Rapsberry Pi 5 + +\paragraph{Communication Interface} + +From a hardware point of view, the main communication requirement was that the drone could connect wirelessly to the external server. The Raspberry Pi 4 Model B included built-in dual band Wi-Fi and Bluetooth. Wi-Fi would be used to connect between the drone and the server, while the Bluetooth could be reserved for short-range setup or debugging if required. Detailed comparison between both methods are covered in the networking section of the report. + +\paragraph{Interface with Sensors and Control Hardware} + +Drone electronics will connect to the onboard computer via the GPIO, serial, USB, and camera-related interfaces. The camera would connect to the Raspberry Pi through USB, allowing the Raspberry Pi to receive camera, depth, and other processed visual data from the camera module. Sensors such as the IMU and ToF would connect through standard buses which allows the Raspberry Pi to read data during flight operations. The IR receivers would connect to GPIO pins while the IR emitter would be controlled through a GPIO output signal. The gimbal/turret servos would be driven using PWM control signals, allowing onboard system to aim the camera and IR emitter simultaneously. ESCs would receive power directly from the battery via the PDB, while the Raspberry Pi would command motor speeds. The Raspberry Pi, as mentioned previously, will be powered from via the regulated 5V voltage. + +\subsubsection{Sensors and Game-Specific Electronics} + +\paragraph{Camera} + +The camera selected by the visual perception work-stream was the OAK-D Lite used for player detection and tracking. In this hardware section, the camera is considered from an integration point of view. The OAK-D Lite connects to the Raspberry Pi through USB hence the drone body must be designed to ensure both the USB connection and cable routing are practical inside the drone body. Its power draw also need to be included in the 5V electronics power budget. Mechanically, the camera must be placed with a clear field of view - placed in line with the IR emitter inside a gimble/turret where they can move simultaneously. There should be no obstruction by the airframe, turret structure, or wiring. More detailed reasoning behind the camera choice can be found in the visual detection pipeline covered separately under "Mid Level Control". + +%%%%%FIGURE:OAK D Lite + +\paragraph{Flight Control Sensors} + +Suitable flight control sensors were needed to give the drone basic state information required for basic motion and awareness. Chosen sensors were intended to provide local state information that could support stabilization, height referencing, and obstacle awareness during indoor operations: the IMU measured body motion, the ToF sensor provided ceiling-distance and side distance information for nearby obstacles. + +A barometer was not selected as a height sensor despite being commonly used in drones for altitude estimation. Given the indoor environment and close proximity between walls and ceilings, pressure-based height estimation is less reliable. Instead, an upward-facing ToF sensor was considered more appropriate for indoor environment, where the ceiling height can be known in advance. + +\begin{table}[htbp] +\centering +\caption{Flight-control sensors used for local motion and distance awareness} \cite{sparkfun_icm20948, st_vl53l1x, st_vl53l5cx} +\label{tab:flight_control_sensors} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l X X X @{}} +\toprule +\textbf{Sensor} & \textbf{Role} & \textbf{Placement / Orientation} & \textbf{Key Specification} \\ +\midrule +SparkFun ICM-20948 IMU & Measures drone motion and orientation/state & Housed inside hull, near the centre & 9-axis IMU: 3-axis accelerometer, 3-axis gyroscope, 3-axis magnetometer; I\textsuperscript{2}C/SPI support \\ + +VL53L1X ToF sensor & Provides vertical distance reference & Mounted pointing upwards & ToF ranging up to approximately 4 m; up to 50 Hz ranging frequency \\ + +VL53L5CX ToF sensors & Provides side obstacle awareness and short-range distance sensing & Mounted facing outwards on multiple sides of the drone & 8$\times$8 multizone ToF sensing; up to 4 m range; \\ +\bottomrule +\end{tabularx} +\end{table} + +The SparkFun ICM-20948 IMU provides local motion and orientation feedback. It is housed inside the drone, near the center of the drone body, where it can measure acceleration, angular-rate, and magnetic-field measurements representative of the airframe while simultaneously protected from impact. + +The VL53L1X and VL53L5CX ToF sensors are included based on the requirements from the control development work. These sensors provide compact distance measurements for the pre-trained RL control policy and local navigation assumptions. In the hardware design, the VL53L1X is placed at the top of the drone, facing directly upward to provide distance measurements from the ceiling. Meanwhile, the VL53L5CX sensors are placed around the drone exterior to provide awareness to side obstacles. + +\paragraph{IR Tagging System} + +For game-specific components, the drone is required to have an infrared tagging system capable of tagging players and detecting when it has been tagged. Despite the project name, the physical hardware uses infrared rather than actual lasers. This is due to safety and regulatory reasons: laser products usage are subject to classification and safety requirements under UK regulations - such as the BS EN/IEC 60825-1 \cite{bsi_laser_safety_60825}, and guidance notes that laser radiation risks harm to eyes and skin \cite{ukhsa_laser_safety}. Using Infra-red based system is therefore more appropriate for indoor game-play, where players and drones operate near each other. In terms of hardware, we focus on how the IR components are physically installed into the overall drone design. + +\textbf{IR emitter} - Mounted on the gimbal/turret alongside the camera so tagging direction is aligned with the aiming direction. The emitter is housed in a compact cylindrical mount - around 10mm in diameter. + +\textbf{IR receiver} - These IR sensors should be distributed around the drone hull where they should be exposed enough to detect incoming IR signals. The receiver spacing should also be dense enough to ensure reliable hit registration during game-play, so players can have an easier time shooting at the drones. + +%%%%%FIGURE: - a choice between the sensors and emitter, or the installation process. + +\subsection{Mechanical Design Development} + +After investigating and selecting the main electronics, the mechanical design aims to transform the selected components into a physical drone layout. Most modeling and assembly designs was carried out in Fusion 360, while standard component models such as motors, batteries, sensors, and other components were either simplified into representative objects based on specified dimensions or downloaded from online libraries to save time. The goal is to define how the components are mounted, protected, and accessed while also ensuring easily manufacturable and cheap parts that are simple to assemble. + +\subsubsection{Early Design Concepts} + +The early concepts tested out basic airframe layouts. The first concept followed a compact quadrotor arrangement, taking inspiration from commercial drones - featuring a central body, four rotor positions, and a space for a centrally mounted turret system. This gave a simple starting point, but as more electronic components were introduced into the CAD assembly, internal packaging became the main issue. + +%%%%%FIGURE: First Drone CAD + +The second and third concepts continued to investigate into symmetrical quadrotor layouts with increased body volume. One version even featured blade-guards, but made the drone noticeably larger, bulkier and less refined than the original concept. Scaling up the size solved some layout issues, but caused the platform to be less suitable for indoor game environment where the drone was required to be compact. In addition, earlier versions treated the airframe as one large connected body, which was not practical for assembly, manufacturing or repair. + +%%%%%FIGURE: Second Drone CAD and Third Drone CAD + +This led to a complete change in direction for the final design: a modular mirrored layout, where the rotor arms are separate from the main body and secured using linkage parts and bolts. This allows the body, arms, linkages, and mounts to be manufactured separately and assembled more easily. The key design areas are the central main body, rotor arms and motor mounts, and turret/gimbal assembly - at which we will go into detail in the following sections. + +%%%%%FIGURE: Final Assembled Drone CAD + +\subsubsection{Main Body Design} + +The main body is composed of three main parts: the top hull, the bottom hull, and the electronics basket. + +%%%%%FIGURE:An image of the entire central body - exploded + +The \textbf{top hull} forms an upper protective cover. It acts as a shield to the internal electronics from direct contact while simultaneously ensure all components are inside. It is designed to give the drone a smooth external shape which helps avoid a bulky appearance and gives the drone a more refined final form. + +The \textbf{bottom hull} forms the lower section of the drone and includes the landing gear. It has a boat-like shape that helps enclose the electronics bay while providing a stable base structure. The helicopter-style skid landing gear is directly integrated into the lower section. This landing gear layout was chosen such that it provides a simple, lightweight, and low-maintenance structure. The wide stance improves stability during take-off and landing. + +The \textbf{electronics basket} acts as a removable internal frame used to hold the main electronics, wiring, and mounting points. It also connects the structure between the central body, and the rotor-arm assemblies. Keeping the basket separate from the outer hull means the electronic components can be accessed for maintenance without dismantling the entire drone. + +All three body sections are held together using \textbf{bolt fasteners}. This may not be an optimal fastening method, however, is a reasonable choice for the current design stage given they are simple, low-cost, and make the body easier to assemble or disassemble. + +There also includes a central opening that passes through the bottom hull and electronics basket for the gimbal/turret assembly. The electronics basket includes a dedicated gimbal/turret mounting feature, where the servo connecting the basket and the gimbal/turret may be installed. + +\begin{table}[htbp] +\centering +\caption{Estimated printed mass of central body} +\label{tab:main_body_mass_estimate} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l r r r @{}} +\toprule +\textbf{Component} & \textbf{Solid CAD Mass} & \textbf{Infill Assumption} & \textbf{Estimated Printed Mass} \\ +\midrule +Top hull & 764.457 g & 20\% & 152.9 g \\ +Bottom hull + landing gear & 1163.830 g & 25\% & 291.0 g \\ +Electronics basket & 604.322 g & 30\% & 181.3 g \\ +\midrule +\textbf{Total main body assembly} & \textbf{2532.609 g} & -- & \textbf{625.1 g} \\ +\bottomrule +\end{tabularx} +\end{table} + +The values in Table~\ref{tab:main_body_mass_estimate} were estimated from the Fusion 360 CAD model using assigned ABS material properties. Given Fusion 360 gives a solid CAD mass, this is not expected to represent the final manufactured mass as parts would be 3D printed with partial infill. The infill assumptions provide a more realistic approximation of the printed body mass - which reduces the main body assembly from 2532.6g to approximately 625.1g. Note that this value does not account for wall thickness, slicing setting and print orientation. + +\begin{table}[htbp] +\centering +\caption{Maximum CAD dimensions of the main body components} +\label{tab:main_body_dimensions} +\renewcommand{\arraystretch}{1.15} +\begin{tabular}{@{} l r r r @{}} +\toprule +\textbf{Component} & \textbf{X (mm)} & \textbf{Y (mm)} & \textbf{Z (mm)} \\ +\midrule +Top hull & 207.47 & 360.64 & 65.02 \\ +Electronics basket & 255.20 & 260.20 & 70.00 \\ +Bottom hull + landing gear & 234.00 & 418.65 & 144.90 \\ +\bottomrule +\end{tabular} +\end{table} + +\subsubsection{Rotor Arm and Motor Mount Design} + +The rotor-arm assembly is made up of the front and rear rotor arms, blade guards, and linkage parts, which mounts the propulsion system and connect to the main body. + +%%%%%FIGURE:Front Rotor + Blueprint +%%%%%FIGURE:Rear Rotor + Blueprint + +The \textbf{rotor arms} support the motor and positions them away from the central body to provide clearance for the propellers. The motor mounts are already integrated to the overall part, so the motor can be fixed directly to the arm. The front and rear arms have slightly different geometries. + +The \textbf{blade guards} surround the propeller area and acts as a protective structure against minor collisions. The main purpose is to reduce the chance of propeller collisions and prevent immediately disabling the drone. They can be directly attached to the rotor arms. Further detail on the structural analysis of the blade guards will be within the section on "Preliminary Engineering Evaluation". + +The \textbf{linkage parts} connect the rotor arms to the electronics basket. These small parts allow the arms to be assembled separately from the main body and are secured using bolt fasteners. This type of assembly allows damaged arm or linkage to be replaced without rebuilding the full drone body. As these parts transfer load between arms and body, they are treated as vital structural components and will use higher infill then the rest of the body. + +\begin{table}[htbp] +\centering +\caption{Estimated printed mass of one side of the rotor-arm and blade-guard assembly.} +\label{tab:rotor_arm_mass_estimate} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l r r r @{}} +\toprule +\textbf{Component} & \textbf{Solid CAD Mass} & \textbf{Infill Assumption} & \textbf{Estimated Printed Mass} \\ +\midrule +Rear blade guard & 91.2 g & 35\% & 31.9 g \\ +Front blade guard & 86.3 g & 35\% & 30.2 g \\ +Rear rotor arm & 129.1 g & 60\% & 77.5 g \\ +Rear upper linkage & 3.8 g & 80\% & 3.0 g \\ +Rear lower linkage & 3.8 g & 80\% & 3.0 g \\ +Front rotor arm & 171.5 g & 60\% & 102.9 g \\ +Front upper linkage & 3.7 g & 80\% & 3.0 g \\ +Front lower linkage & 3.7 g & 80\% & 3.0 g \\ +\midrule +\textbf{Total one-side assembly} & \textbf{493.1 g} & -- & \textbf{254.5 g} \\ +\bottomrule +\end{tabularx} +\end{table} + +The values in Table~\ref{tab:rotor_arm_mass_estimate} were estimated from the Fusion 360 CAD model using the properties assigned of ABS material. Just like the main body, the Fusion 360 reports the solid-body CAD mass, therefore we estimate the real manufactured mass using base infill assumptions. Note that this estimate does not account for wall thickness, slicing settings, print orientation, or bolt fastener mass. + +\begin{table}[htbp] +\centering +\caption{Maximum length of one side of the rotor-arm and blade-guard assembly} +\label{tab:rotor_arm_dimensions} +\renewcommand{\arraystretch}{1.15} +\begin{tabular}{@{} l r r r @{}} +\toprule +\textbf{Component} & \textbf{X (mm)} & \textbf{Y (mm)} & \textbf{Z (mm)} \\ +\midrule +Rear blade guard & 207.51 & 167.16 & 113.00 \\ +Front blade guard & 117.50 & 207.51 & 118.00 \\ +Rear rotor arm + motor mount & 75.00 & 50.00 & 120.00 \\ +Rear linkage 1 & 40.00 & 20.00 & 5.00 \\ +Rear linkage 2 & 40.00 & 20.00 & 5.00 \\ +Front rotor arm + motor mount & 75.00 & 50.00 & 140.00 \\ +Front upper linkage & 40.00 & 20.00 & 5.00 \\ +Front lower linkage & 40.00 & 20.00 & 5.00 \\ +\bottomrule +\end{tabular} +\end{table} + +Note that the measurements are maximum lengths on each axis, rather than rectangular measurements. The blade guards and rotor arms have circular geometry around the propeller area - these measurements are useful for checking propeller clearance but should not be interpreted as box-shaped component dimensions. + +\subsubsection{Turret/Gimbal Design} + +The gimbal turret designed included requirements from the visual learning process, where the camera was required to roll, pitch, and yaw. The design took inspiration from traditional industrial two-axis gimbals, but an with an additional yaw axis which provided a 3-axis movement. The camera and IR emitter needed to remain aligned to ensure aiming and tagging were done in the same direction. A reminder previously where the OAK D Lite camera was used as a reference to designing the dimensions of the gimbal. + +Mechanically, the gimbal is mounted through the central opening in the bottom hull and electronics basket. + +%%%%%FIGURE:Blueprint for Gimbal (without motor) - with blueprint + +The \textbf{coupler} forms the main connection between the yaw actuator and the electronics basket. It defines the mounting region for the servomotor output and provide the space where the square axial component will be installed. + +The \textbf{gimbal installation plate} is positioned below the coupler and is used to close up the interface between the gimbal and the drone body. It also secures the lower part of the installation interface which keeps the yaw mechanism aligned and provide tighter space for wires to help reduce entanglement issues. + +The \textbf{square axial component}square Axial component supports the pitch-axis motor and provides the structural frame for the upper gimbal mechanisms. It is directly installed to the yaw mechanism allowing the overall gimbal to move in yaw motion - it is only in contact with the servomotor output. The pitch motion is produced by mounting a gimbal motor onto the square axial component, with the motor output connected to the gimbal pitch axis component. This allows camera and IR emitter to tile upward and downward. + +The \textbf{gimbal pitch axis component} acts as the moving structure for pitch stage and provides roll-axis motor mount. The roll motion is produced by mounting the roll gimbal motor onto the pitch axis component, with the motor output connected to the gimbal roll axis component. This creates a second controlled axis above the yaw and pitch stages. + +The \textbf{gimbal roll axis component} provides the mounting location for the OAK-D Lite camera and IR emitter. As the camera and IR emitter are mounted on the same final axis, the visual tracking direction and IR tagging direction remain aligned. + +Together, the yaw servo, pitch motor, and roll motor allow the turret to achieve 3-axis movement. + +%%%%%FIGURE: showing the final gimbal assembly + +\begin{table}[htbp] +\centering +\caption{Estimated printed mass of gimbal turret components using Fusion 360 solid-body mass and assumed 3D-print infill percentages.} +\label{tab:gimbal_mass_estimate} +\renewcommand{\arraystretch}{1.15} +\begin{tabularx}{\textwidth}{@{} l r r r @{}} +\toprule +\textbf{Component} & \textbf{Solid CAD Mass} & \textbf{Infill Assumption} & \textbf{Estimated Printed Mass} \\ +\midrule +Gimbal installation plate & 21.58 g & 50\% & 10.8 g \\ +Square axial component & 12.23 g & 70\% & 8.6 g \\ +Gimbal pitch axis component & 6.65 g & 70\% & 4.7 g \\ +Gimbal roll axis component & 5.21 g & 70\% & 3.6 g \\ +Coupler & 20.89 g & 80\% & 16.7 g \\ +\midrule +\textbf{Total gimbal assembly} & \textbf{66.55 g} & -- & \textbf{44.4 g} \\ +\bottomrule +\end{tabularx} +\end{table} + +Table~\ref{tab:gimbal_mass_estimate} shows the mass of the solid body from Fusion 360 using assigned ABS material properties. Estimations were made using infill assumptions for each component which reduced the final mass from 66.55g to 44.4g - excluding the camera, IR emitter, gimbal motors and servo. + +\paragraph{Servomotor and Gimbal Motor} + +The gimbal turret uses two actuator types as mentioned previously. The MG90S servo is used for the yaw axis, while the Quanum 2208 brush-less gimbal motors are used for the pitch and roll axes. Servo was used for the Yaw stage in order to provide compact rotation at the base, while the pitch and roll may be better with smoother gimbal-style motion. + +\subsubsection{Overall Airframe Configuration - Assembly} +\paragraph{Internal Component Layout} + +\subsection{Preliminary Engineering Evaluation} +\subsubsection{Structural Assessment of Critical Components} +\subsubsection{Feasibility of the Final Design} + +\newpage + +\section{Player Hardware Design} +\subsection{Vest} +\subsection{Helmet} +\subsection{Weapon} + +%%%%%%%%%----------------end of Hardware---------------%%%%%%%%% + +\section{Map} \label{map} +\fancyhead[C]{Thomas August} +In our game, we will have humans and drones interacting with each other in close proximity within the same arena, and hence we need to design a map for this arena which is accessible to both players and drones and allows the two to safely interact with each other. We discussed this as a group, considering player enjoyment, game complexity, drone localisation, and drone movement, and concluded that a floor to ceiling maze design would be best. + +\subsection{Maze Design} +For continuity throughout our project, we decided to design an exact map layout in order to use the same one for all parts of this project. Since we plan to hire a warehouse for the arena to be setup in, we want to utilise the space as much as possible, and hence we chose to use a grid graph with edge constraints for our map design. This means that all cells on the map are accessible and the walls are represented by the edges connecting the cells which can either be blocked if there is a wall or not blocked if there is no wall. We designed the map by adding borders to cells in an Excel document and used a python script to convert this to a csv file containing a 2 bit integer for each grid cell. The least and most significant bits of this integer indicate if there is a wall on the north and west sides of the cell respectively. The presence of south or east walls are found by checking the north or west walls of the corresponding adjacent cell to avoid repeating information and increasing the size of the stored map matrix. An example of a map and it's wall matrix are shown below. + +\begin{figure}[htbp] \centering - \includegraphics[width=0.5\linewidth]{example-image-duck} - \caption{An awesome image of a duck.} - \label{fig:enter-label} + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=0.6\textwidth]{figs/3x3 map.png} + \caption{3x3 map} + \label{fig:3x3Map} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=0.8\textwidth]{figs/3x3 map matrix.png} + \caption{Wall matrix for the 3x3 map} + \label{fig:3x3WallMatrix} + \end{subfigure} + + \caption{An example 3x3 map, (\subref{fig:3x3Map}), and its corresponding wall matrix, (\subref{fig:3x3WallMatrix}).} + \label{fig:wallMatrixDemo} \end{figure} -\fancyhead[C]{Student2 author of section} -\subsection{An awesome image} +\newpage % REPLACE WITH IMAGE -\lipsum[1-2] +\subsection{Map Separation} +In order to make the maze a safe environment for the players and drones to occupy at the same time and interact with each other, we decided to implement a safety net above the players to separate the drones from the players and mitigate injuries due to a drone falling onto a player during a malfunction. This safety net will run throughout the whole maze and we will have the home base of the drones and players on opposite sides with half walls connecting the net to the floor or ceiling for the drone and player home bases respectively. This completely separates the drones from the players with a physical barrier at all times, greatly reducing the risk of a human-drone collision incident. This separation between players and drones also allows us to customise each section independently so that we can have obstacles, doorways and windows in the player area while keeping the drone area free of obstructions. This setup allows us to have a more interesting arena for the players while minimising the chance of collision for the drones. +\subsection{Map Dimensions} +After deciding on the general design and layout of the map, we next looked at the exact dimensions of the map. The dimensions we chose are, 2x2m grid squares, with the net and ceiling at 3m and 5m height respectively. The grid square dimensions allow sufficient space for the drones to move around without feeling too large for the players. The net height is high enough to be out of reach from players allowing them to move around freely as if it was not there, and the ceiling height allows sufficient space for the drones to move around without being too tall to fit in a small warehouse. -\subsection{An awesome table} +\subsection{Net Material} +We plan to use industrial safety nets to separate the players from the drones as these are tested and reliable. From our research we found a company called SafetyNet365 that make custom safety nets with many different variants, allowing us to choose the mesh size and material diameter among other parameters. We first considered their fall safety nets, which are designed for construction sites to catch workers if they fall, and we chose the largest mesh size of to minimise the area blocked by the net. This net we will call net A, \cite{testedSafetyNet}. As seen in Table \ref{} below, this has an energy absorption of 4.8kJ, but if we calculate the kinetic energy of our $4kg$ drone falling the maximum distance of $2m$ with maximum thrust downwards and a thrust to weight ratio of $2$, the kinetic energy at impact would be $235J$, assuming $g=9.81$. Therefore, the energy absorption of this net far exceeds our needs, so we next considered nets with thinner material diameter. The only nets on their website that have energy absorption listed have $5mm$ material diameter, so in order to consider the energy absorption of other nets we will have to estimate it ourselves. Since the specifications include the maximum tensile force $F$ and breaking elongation $\Delta$ for a single rope, we can calculate the maximum energy stored in each rope as $E=F\Delta L$, where $L$ is the mesh size, the distance between two rope connections. If we then assume that the energy absorption of the net is proportional to the maximum energy stored in a single thread, then we can estimate the energy absorption of an identical net with only the tensile strength, breaking elongation, and mesh size changed. Since this is already a bold assumption, we chose to keep the breaking elongation and mesh size the same and look for a net with thinner material diameter and therefore less maximum tensile force, while keeping all other parameters the same. This simplifies the proportion equation to $EA = k F$, where $EA$ is the energy absorption and $k$ is a constant. We then picked the net with the thinnest material diameter but all other parameters the same to get a lower bound of the energy absorption. This net we will call net B, \cite{thinSafetyNet}. Using the values in Table \ref{} below, we can estimate the energy absorption of net B, $EA_B$, from that of net A, $EA_A$, using the formula $EA_B = EA_A \cdot F_B/F_A$, giving $EA_B = 375J$. This is larger than the predicted maximum energy of the drone upon impact with a safety factor of 1.6, however this is not a very large safety factor, especially with the bold assumptions made above. Ideally we would like a safety factor of at least 3 to cover us from the assumptions made above so we increased the material diameter until this condition was met, giving us the final choice of net C, \cite{usedSafetyNet}. Calculating the energy absorption for this net gives $EA_C = EA_A \cdot F_C/F_A = 1200J$, which gives a safety factor of 5.1 which is well above the proposed minimum of 3. -\begin{table}[h] +\begin{table}[htbp] \centering - \begin{tabular}{@{}lll@{}} + \caption{Net specifications} + \label{tab:net} + \small + \begin{tabularx}{\textwidth}{cccc} \toprule - \textbf{Fruit} & \textbf{Color} & \textbf{Average Weight (g)} \\ \midrule - Apple & Red & 182 \\ - Banana & Yellow & 118 \\ - Orange & Orange & 131 \\ - Grape & Purple & 5 \\ - Watermelon & Green & 9000 \\ \bottomrule - \end{tabular} - \caption{An awesome table, by GPT-4o mini \cite{achiam2023gpt}.} - \label{tab:my_label} + \textbf{} & \textbf{Net A} & \textbf{Net B} & \textbf{Net C} \\ + \midrule + Material Diameter / mm & 5 & 1.5 & 0.5 \\ + \midrule + Mesh Size / mm & 100x100 & 100x100 & 100x100 \\ + \midrule + Max Tensile Strength / N & 3200 & 250 & 800 \\ + \midrule + Breaking Elongation / \% & 15 & 15 & 15 \\ + \midrule + Energy Absorption / J & 4800 & 375 & 1200 \\ + \midrule + Energy Absorption Safety Factor & 20.4 & 1.6 & 5.1 \\ + \bottomrule + \end{tabularx} \end{table} -\lipsum[1-6] +\newpage -\subsection{An awesome Acronym} +\section{State Estimation} \label{state estimation} % Tommy +\fancyhead[C]{Thomas August} % -You can use acronyms for your \gls{3yp} exactly as I did here. -You can define them in the header of this file and they will appear in the glossary section. +\newpage +\section{Network and Communications} +Ritchie +\subsection{Overview} +Network and Communications are not strictly necessary for a single wave of the game. Without them, each drone would act according the the information that it had gathered (location of the players, location of other drones etc.), and would not have access to the information that other drones had gathered. +There are a couple of advantages to handling information without a central server: +\begin{itemize} + \item Perceived Fairness: the drones will not have access to information they have not gathered themselves, just like the human players. + \item Robustness: if each drone acts individually, there is no single thing that can go wrong that would entirely derail the game (the way a central server crash would). +\end{itemize} +Alternatively, a central server could be used to give drones high-level instructions, and to share information pertaining to the state of the game. This method of handling information also has some advantages: +\begin{itemize} + \item Complexity: it is much easier to create a program that, with access to all of the available information, controls the drones in the desired manner than it is to create a program that, with different drones following the same program with differing levels of information, will have the same desired effect. + \item Hardware Costs: if the central high-level decision making is done locally on the processer of each drone, rather than in a central server, not only will a higher-powered processer be needed in the drone, but a larger battery will be needed to power it, so more powerful motors will be required to lift the batter, and so on, driving up hardware costs. +\end{itemize} + +It was decided, considering the pros and cons listed above, to use a central server to carry out high-level decision making. Different methods of handling communications between the drones and the server are discussed below. + +\subsection{Bluetooth} +Bluetooth is a short-ranged wireless communication system, which is designed for low-power device-to-device communications. It uses 79 channels, \(1\text{MHz}\) apart, from 2.402 to 2.480 GHz, hopping between them constantly - that is to say, information is sent by changes in frequency as opposed to changes in amplitude or phase. The signal is decoded wither using Frequency Hopping Spread Spectrum (FHSS, used in Classic Bluetooth), or Gaussian Frequency Shift Keying (GFSK, in Bluetooth Low Energy, BLE). In any given connection, one device acts as a "master", and up to seven devices act as "slaves". During connection, Time-Division-Duplexing is used to avoid collisions. Time is split into \(625\mu\text{s}\) divisions. The master communicated in even slots, and the slaves communicate in odd slots. The public technical information website GeeksForGeeks gives an overview of Bluetooth Data transfer \cite{geeksforgeeksBluetoothFrameStructure}; each data packet or "frame" is structured as follows: + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/Bluetoothframestructure-660x253.png} + \caption{Bluetooth Information Packet Structure} + \label{fig:BlueStruct} +\end{figure} +A bluetooth connection requires very little power. However, a bluetooth connection has a fairly low bit rate compared with a Wi-Fi connection (1-10 \(\text{Mbps}\)). It is also much less reliable than a Wi-Fi connection. Connection drop-out and communication failures are common in Bluetooth connections. Furthermore the maximum number of seven slaves connected to a single master will pose a problem since it will be necessary for up to 10 drones to be connected to the server at a time, requiring a secondary server, the purpose of which is to manage communication between some drones and the server. This would be possible, but inconvenient and prone to fault. + +\subsection{Wi-Fi} +Wi-Fi medium-ranged wireless communication system, designed for fast transfer of data and reliable server-to-device communication. It typically runs at frequencies of \(\textasciitilde\)2.4\(\text{GHz}\), \(\textasciitilde\)5\(\text{GHz}\) or \(\textasciitilde\)6\(\text{GHz}\), transferring data over 3, 25 or 60 non-overlapping channels of bandwidth 20\(\text{MHz}\) respectively, and Orthogonal Frequency Division Multiplexing (OFDM) is used to decode signals. HowIWiFi.com, an information page dedicated to Wi-Fi, gives an overview of Frame Types and Formats \cite{key}; each data packet or "frame" is structured as follow: +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/frame-format.png} + \caption{Wi-Fi Information Packet Structure} + \label{fig:Wi-FiStruct} +\end{figure} + +A Wi-Fi connection has much lower latency than Bluetooth, and has a much higher maximum bitrate than Bluetooth. However, the data that is likely to be needed is small enough that this will not be important. However, Wi-Fi is much more reliable than Bluetooth, and this is especially true at distances above ten meters; Bluetooth was designed for low bitrate, low power, short-range communication between a small number of devices, whereas Wi-Fi was designed for high bitrate, medium power, medium-range communication between a large number of devices. + +For these reasons, Wi-Fi is selected as the networking medium between the drones and the server. The server will be a desktop computer (with Wi-Fi capability), and the drones, helmets and vests all contain a Raspberry Pi 4, with Wi-Fi capability. + +\newpage +\section{High Level Control} % Ritchie +\fancyhead[C]{Richard Usherwood} % Ritchie +\subsection{Context} +The objective of the High Level Control Protocol is to create a series of algorithms which take game states (positions of human players, positions of drones etc.) as their inputs, and give a high-level behaviour of a drone as their output. This is achieved through splitting the drones' behaviour into several "modes", in which some information and computing is performed in the server, and transmitted to the drones via Wi-Fi, and some information storage and computing is performed onboard the drone, according to an Information Responsibility Protocol. +% \subsection{Drone States} +% A set of drone "states" or "modes", describing the drone's behaviour, are shown below in Figure \ref{fig:StatesList}. \newline +% \begin{figure}[htbp] +% \centering +% \includegraphics[width=0.7\linewidth]{figs/High-Level/StatesList.png} +% \caption{A List of Drone States} +% \label{fig:StatesList} +% \end{figure} \newline +% An overview of the purpose of each state is given below. + +\subsection{Drone Modes} +A set of drone "modes" or "states", describing the drone's high-level behaviour, have been defined. They are: +\begin{itemize} + \item Dormant Mode + \item Search Mode + \item Movement Mode + \item Track Mode + \item Shoot Mode + \item Collision Avoidance Mode +\end{itemize} +An overview of the purpoe of each state is given below. + +\subsubsection{Dormant Mode} +This is the "default mode" of the drones, designed for waiting between rounds or games on standby, when not actively involved in the game - it is triggered by the end of a round, or by the powering on of the drone. +\subsubsection{Search Mode} +This is the initial mode of a drone upon entering a game. In this mode, the drone is exploring an area of the map decided by the central server, looking for a target. The flow diagram describing the conditions under which the drone will change out of Search Mode is shown below, in Figure \ref{fig:FlowSearch}. +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/High-Level/SearchMode.png} + \caption{Flow Chart Describing Mode Changes, centred on Search Mode} + \label{fig:FlowSearch} +\end{figure} +\subsubsection{Track Mode} +This is the mode the drone is in when is has seen a human player which is not within shooting range. In this mode, the drone's objective is to get close enough to the player to shoot them. The flow diagram describing the conditions under which the drone will change out of Track Mode is shown below, in Figure \ref{fig:FlowTrack}. +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/High-Level/TrackMode.png} + \caption{Flow Chart Describing Mode Changes, centred on Track Mode} + \label{fig:FlowTrack} +\end{figure} +\subsubsection{Shoot Mode} +This is the mode the drone is in when it has identified a player within shooting range of itself. In this mode, the drone will try to shoot the player. The flow diagram describing the conditions under which the drone will change out of Shoot Mode is shown below, in Figure \ref{fig:FlowShoot}. +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/High-Level/ShootMode.png} + \caption{Flow Chart Describing Mode Changes, centred on Shoot Mode} + \label{fig:FlowShoot} +\end{figure} +\subsubsection{Movement Mode} +This is the mode the drone is in when it has been "called for help" - something that happens when a drone detects that more than one player is within shooting range of itself. This mode can only be reached from Search Mode. +\subsubsection{Collision Avoidance} +This mode is triggered either when the drone detects it is about to collide into a wall, or when the server detects it is about to collide into another drone. This mode can be accessed from any mode (except Dormant Mode). + +\subsection{Logic} +The flow charts shown in Figures \ref{fig:FlowSearch}, \ref{fig:FlowTrack} and \ref{fig:FlowShoot} are section of a larger flowchart describing the state change logic of the drones, shown in Figure \ref{fig:FlowBig}, in the appendix. The red boxes denote information shared between drones (managed by the server via Wi-Fi). It is worth noting that Dormant Mode and Collision Avoidance Mode have been omitted for the sake of readability. Since these two states are considered "higher-priority" than the others, each decision chain implicitly contains the question boxes: "Am I about to crash?" and "Has the wave ended?". + +\newpage + + +\subsection{Information Responsibility} +\fancyhead[C]{Thomas August} % Tommy + + +\newpage +\section{Mid Level Control} % Tommy, Rishabh +\fancyhead[C]{Rishabh Luthra} +\subsection{Visual Perception and Player Tracking} % Rishabh +\subsubsection{Context} + +The fundamental objective of the autonomous multiagent system is to actively compete against human players in a dynamic laser environment. To play the game effectively, the drones require a reliable way to identify and track opponents whilst navigating through the maze environment. While pathfinding algorithms can navigate the fixed geometry of a maze, human players represent highly dynamic variables. Therefore, a real-time perception system is required to continuously locate the targets, maintain visual lock, and output kinematic commands to the drone's flight controller and gimbal. + +This section details the design and implementation of this perception system. To achieve these operational requirements, the subsystem is engineered around three core objectives: +\begin{itemize} + \item Reliably distinguishing a human player from background obstacles and other drones to ensure that the system locks onto the correct target. + \item Calculating the target's 3D Cartesian coordinates relative to the drone's local frame. + \item Maintaining a continuous state estimate of the target's trajectory to handle temporary line-of-sight occlusions caused by walls and obstacles. +\end{itemize} + +\subsubsection{Sensor Selection} % (Rishabh - can be moved somewhere else, just put it here to make sure it's covered) + +% To Do: +% - check references +% - include an image on stereo depth and maybe of the test setup [done] +% - a few sentences on why to focus on the depth mechanism +% - interesting to note that relative depth estimation is possible using ml methods but it would fail due to the compute cost as well as its unreliability to retrieve exact depth metrics +% - add distance measurements into inline equations +% - check acronyms like rgb +% - section on Unity simulation environment (map generation, why Unity is beneficial, reference synthetic data generation) +% - maybe move the rgb and stereo images to be horizontal on the page above and then sensor architecture standalone on the page after [done] +% - reference Figure 6, 13, 14 (check all figures are referenced) + +In order to transition from the objectives to the physical implementation, we require a sensor payload that can provide high-fidelity data without compromising flight performance or game mechanics. + +Quadcopters are inherently underactuated mechanical systems [ref]; to achieve horizontal translation, the drone must pitch ($\theta$) or roll ($\phi$) in the direction of travel. If the visual sensor is rigidly mounted to the chassis, any forward acceleration pitches the sensor towards the floor, which may force the target out of the \gls{fov}. In order to resolve this, the sensor payload must be mounted to a 3-axis active gimbal. The gimbal acts as a kinematic decoupler, executing rotation transformations to maintain the camera frame at a fixed angle relative to the horizon, regardless of the drone's orientation. + +With the camera isolated from the drone's tilt, the next step is to select the specific imaging hardware for 3D spatial localisation of the target. While a standard 2D camera provides the line-of-sight data necessary to keep the drone facing the target, it lacks the absolute depth measurement ($Z$) required to establish a complete relative coordinate frame. Several of the evaluated hardware options are classified as \gls{rgbd} sensors, denoting that they capture standard colour video (RGB) alongside a depth map (D). We evaluated four standard approaches based on \gls{swapc} constraints alongside their compatibility within the laser tag environment. + +\begin{table}[htbp] + \centering + \caption{\gls{swapc} Evaluation of 3D Spatial Localisation Sensor Options [ref]} + \label{tab:sensor_swapc} + \small + \begin{tabularx}{\textwidth}{@{}llcccX@{}} + \toprule + \textbf{Sensor Type} & \textbf{Typical Hardware} & \textbf{Mass (g)} & \textbf{Power (W)} & \textbf{Cost (£)} & \textbf{Depth Mechanism} \\ + \midrule + Micro LiDAR & RPLidar A1 & 170 & 0.5 & $\sim 100$ & Active ToF \\ + \midrule + Active RGB-D & Orbbec Astra Mini Pro & 35 & 2.5 & $\sim 110$ & Structured Light \\ + \midrule + Passive Stereo & OAK-D Lite & 61 & 2.5 -- 3.0 & $\sim 125$ & Passive Stereo Disparity \\ + \midrule + Monocular RGB & RPi AI Camera & 24 & $< 1.5$ & $\sim 60$ & Software Estimation \\ + \bottomrule + \end{tabularx} +\end{table} + +While \gls{lidar} and active \gls{rgbd} cameras provide accurate native depth data, they were rejected due to their interference with the laser tag scoring system. + +Both camera systems operate by emitting \gls{ir} light into the environment. For example, the Orbbec Astra Mini Pro is a structured light system and relies on an onboard \gls{ir} projector to cast a dense grid pattern across the room to calculate depth. The laser tag scoring system relies on detecting specific IR pulses between the drones and players. In a confined maze environment, any \gls{ir} projection from the cameras will likely reflect off walls (multipath interference) and also flood the players' hit receivers with noise and cause false registrations. Therefore, we deemed that any active payload would be incompatible with the game mechanics. + +The decision between Monocular RGB and Passive Stereo requires a trade-off between \gls{swapc} efficiency and depth accuracy. + +A monocular camera (for example, the Raspberry Pi AI Camera) offers the best \gls{swapc} profile since it weights 24g and draws less than 1.5W. This means that it has a negligible impact on the quadcopter's flight dynamics. However, a single lens cannot natively measure depth and to extract 3D coordinates from a 2D feed, the system must rely on a geometric prior. This can be done by assuming a standard geometric height for a human or similarly the area of the bounding box (which can then be fine tuned during implementation). A standard method assumes the physical cross-sectional area of the human target ($A_{prior}$) is constant. The distance $Z$ is then calculated using the focal length ($f$) and the pixel area of the bounding box ($A_{px}$): +\begin{equation} + Z = f \cdot \sqrt{\frac{A_{prior}}{A_{px}}} +\end{equation} +Whilst this is computationally inexpensive, this method is fragile in dynamic environments. Since we have assumed a geometric prior, if the player crouches or turns sideways, their bounding box area ($A_{px}$) shrinks while their physical distance from the camera remains identical. This means that this will be misinterpreted as the player moving further away and cause the drone to accelerate forwards. + +It is worth noting that machine learning (ML) architectures can estimate depth from a monocular feed without relying on geometric priors. However these methods are rejected due to \gls{swapc} limitations as running real-time inference whist achieving a high frame rate incurs a high computational cost. Moreover, these models typically output relative depth rather than the absolute depth that is required. + +On the other hand, a passive stereoscopic system, such as the Luxonis OAK-D Lite, resolves this posture vulnerability by extracting depth natively through pixel disparity. The camera uses two lenses separated by a known baseline distance $B$. When the system detects a player, it registers a specific visual feature (such as the centroid of the bounding box) on both the left and right image sensors. As the lenses are physically offset, this feature appears at slightly different horizontal pixel coordinates on each sensor. This horizontal shift is the disparity ($d$). The system then calculates the absolute depth ($Z$) using the camera's focal length ($f$) with the equation: +\begin{equation} + Z = \frac{f \cdot B}{d} +\end{equation} +Geometrically, as the target moves closer to the sensors, the viewing angle from each lens becomes more acute. This leads to the feature shifting further apart horizontally across the two image planes and hence $d$ increases. Since this calculation relies entirely on the horizontal parallax of a specific coordinate rather than the total pixel area of the bounding box ($A_{px}$), the depth estimation remains stable even if the player turns sideways. Furthermore, since this disparity mapping relies purely on ambient light, it ensures that there is no infrared interference with the game mechanics. + +To compare the performance of monocular and stereo depth estimation under geometric transformations, we constructed a simulation environment of the proposed hardware in Unity. The cameras were configured with a 1920x1080 resolution, with a $60^\circ$ \gls{fov}, a focal length of 935.31px, and a stereo baseline of 0.075m. We used a cuboid measuring 0.5m wide, 1.8m tall, and 0.2m deep to represent an average player. The objective was to observe how both camera architectures respond to changes in the target across three scenarios. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/DepthEstimationTests.pdf} + \caption{Overview of the experimental setup comparing monocular and stereo depth estimation under geometric transformations.} + \label{fig:depth_estimation_test} +\end{figure} + + +\textbf{(1) Linear Movement} + +We began with a baseline calibration and translated the target linearly from 5m to 15m along the Z-axis. Within this scenario, the target's physical dimensions and orientation remained fixed. As demonstrated in Figure \ref{fig:linear_translation}, both the monocular camera system and stereo camera system accurately map the physical ground truth. This establishes that both approaches are viable for tracking rigid bodies under ideal conditions. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/LinearTranslation_Plot.pdf} + \caption{Comparison of monocular and stereo depth estimation against physical ground truth during linear translation from 5m to 15m} + \label{fig:linear_translation} +\end{figure} + +\newpage + +\textbf{(2) Changes in Target Orientation} + +In a practical laser tag environment, players are unlikely to follow linear trajectories. To evaluate how the depth tracking systems handle changes in orientation, we simulate a player turning sideways by rotating the target from $0^\circ$ to $90^\circ$ on its yaw axis. As the target rotates around its 5.1m centroid, the physical ground truth, which is represented by the closest physical surface, shifts from 5.0m down to 4.85m. + +As illustrated in Figure \ref{fig:yaw_rotation}, there is a slight discrepancy between the physical ground truth and the stereo estimation during the turn. While the ground truth tracks the foremost surface, the stereo algorithm calculates the depth based on the centroid of the 2D bounding box. This means that during the rotation, the stereo estimate settles at the $5.1 \text{ m}$ centre of mass and as the rotation reaches $90^\circ$, the camera's view is restricted to the 0.2m side profile and this causes the stereo centroid calculation to fall to the 4.85m ground truth. + +As the target turns, its 2D profile narrows and the monocular algorithm, which is reliant on the pixel area, misinterprets this narrowing as the target moving further away. This means that the depth estimate from the monocular camera diverges from the ground truth. This specific scenario highlights a limitation of the monocular approach, as the system cannot distinguish between a change in the target's orientation and its actual distance. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/YawRotation_Plot.pdf} + \caption{Comparison of depth estimation models during target yaw rotation from $0^\circ$ to $90^\circ$ at a nominal 5.0 m depth.} + \label{fig:yaw_rotation} +\end{figure} + +\textbf{(3) Changes in Target Posture} + +We also evaluated the systems against a reduction in the target's vertical height, to simulate the motion of crouching. Similar to the changes in the target's orientation, the monocular algorithm misinterprets the shrinking of the target as an increase in depth, leading to the depth overestimation seen in Figure \ref{fig:crouch_deformation}. + +This scenario highlights the advantage of the stereo system with the stereo estimate accurately tracking the ground truth. This confirms that the geometric baseline approach of the stereo model is \textbf{robust} to physical deformation, whereas the area approach of the monocular model will fail when the target's posture changes. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/CrouchDeformation_Plot.pdf} + \caption{Comparison of depth estimation models during crouching at a constant physical depth} + \label{fig:crouch_deformation} +\end{figure} + +\textbf{Consequently, the passive stereoscopic system is selected for the sensor payload attached to the drone's gimbal. While the monocular camera presents a favourable \gls{swapc} profile, the simulations demonstrate that area-based depth estimation is insufficient for reliable depth estimation. The system cannot reliably distinguish between a change in the target posture or orientation from a change in physical depth. +} +The passive stereo system resolves this by estimating depth via horizontal pixel disparity ($d$) and provides a \textbf{robust} depth estimate. Crucially, its reliance on ambient light means that there will be no interference with the infrared game mechanics. + +\subsubsection{Computer Vision Architecture} +The hardware of this system is comprised of a camera array consisting of three cameras. It features a high-resolution central RGB camera with two greyscale sensors either side that are dedicated to computing the stereoscopic disparity depth map. These visual streams are sequentially processed to meet both the tracking objectives described above: reliably distinguishing a human player from the background to lock onto the correct target, and calculating the target's 3D Cartesian coordinates relative to the drone's local frame. Together, these stages form the sensor pipeline (Figure \ref{fig:pipeline_diagram}). + +\begin{figure}[htbp] + \centering + + \begin{subfigure}[b]{\textwidth} + \centering + \includegraphics[width=0.6\textwidth]{figs/sensor_pipeline.pdf} + \caption{Sensor fusion architecture} + \label{fig:pipeline_diagram} + \end{subfigure} + + \vspace{0.75cm} + + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=0.7\textwidth]{figs/1_RGB.png} + \caption{Monocular RGB stream with ground truth bounding box} + \label{fig:rgb_data} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=0.7\textwidth]{figs/2_DepthMap.png} + \caption{Synchronised depth map with projected bounding box} + \label{fig:depth_data} + \end{subfigure} + + \caption{The data flow in (\subref{fig:pipeline_diagram}) alongside the corresponding RGB bounding box (\subref{fig:rgb_data}) and spatial depth mapping (\subref{fig:depth_data}).} + \label{fig:perception_system_overview} +\end{figure} + +\newpage + +To satisfy the first objective, the system must transform the raw visual data into spatial data. The central RGB sensor outputs a continuous stream of frames, which are essentially high-dimensional pixel arrays. To interpret these, an object detection model is required to ingest this raw data and output bounding boxes around valid targets. This process effectively maps visual features to 2D semantic coordinates within the image frame, ensuring the system can reliably distinguish the player from the background. + +\textbf{For this task, the YOLOv8-nano (YOLOv8n) framework was selected. It provides an extremely fast multi-object detection algorithm that uses a \gls{cnn} to detect and identify objects. \gls{yolo} evaluates the entire image in a single computational pass to predict bounding box coordinates and this approach ensures low latency of the model. Because the drone's flight controller takes actions based on the visual feed, it must receive the most up-to-date target data to ensure the control loops remain responsive. +} +The nano variant was chosen because it has the lowest parameter count out of the YOLOv8 models and this makes it the lightest and fastest model available. The streamlined nature of this architecture is well-suited to the limited computer resources available on the drone's onboard hardware. Furthermore, the maturity of the \gls{yolo} architecture, combined with its extensive Python support and documentation, facilitates the training process and provides a reliable pipeline for deploying the model within the project. + +To achieve the second objective, the system performs sensor fusion. The predicted 2D bounding box defines a region of interest (Figure \ref{fig:rgb_data}), which is projected onto the synchronised stereo disparity map (Figure \ref{fig:depth_data}). This allows the system to extract the absolute depth ($Z$) of the target by sampling depth data across the pixels within this region, effectively bridging 2D visual recognition with 3D spatial tracking. + +Note that the visualisations in Figure \ref{fig:perception_system_overview} were generated within the Unity simulation environment (detailed in Section \ref{system}), utilising Ground Truth bounding boxes. + +% \begin{figure}[H] +% \centering +% \begin{subfigure}[c]{0.48\textwidth} +% \centering +% \includegraphics[width=\textwidth]{figs/sensor_pipeline.pdf} +% \caption{Sensor fusion architecture} +% \label{fig:pipeline_diagram} +% \end{subfigure} +% \hfill +% \begin{subfigure}[c]{0.48\textwidth} +% \centering +% \includegraphics[width=0.85\textwidth]{figs/1_RGB.png} +% \caption{Monocular RGB stream with ground truth bounding box} +% \label{fig:rgb_data} + +% \vspace{0.5cm} + +% \includegraphics[width=0.85\textwidth]{figs/2_DepthMap.png} +% \caption{Synchronised depth map with projected bounding box} +% \label{fig:depth_data} +% \end{subfigure} + +% \caption{The data flow in (\subref{fig:pipeline_diagram}) alongside the corresponding RGB bounding box (\subref{fig:rgb_data}) and spatial depth mapping (\subref{fig:depth_data}).} +% \label{fig:perception_system_overview} +% \end{figure} + + +\subsubsection{Data Preprocessing} +To accelerate the training process, we utilised a pre-trained \gls{yolo} model initialised using baseline weights on the \gls{coco} dataset. Leveraging a pre-trained model provides the neural network with a foundational understanding on geometric features such as edges and spatial gradients. This drastically reduces the time required for the network to converge. However, these standard weights are insufficient for our case because the \gls{coco} dataset consists primarily of eye-level photography whereas the drone requires aerial imagery. To achieve reliable target locking from the drone's pitch angles, the model required fine-tuning on specific drone imagery. As a result, the VisDrone2019-DET dataset was selected to provide this top-down perspective. + +The VisDrone dataset contains numerous additional classes such as vehicles and bicycles. Training the network to recognise these would waste computational resources and risk introducing false positives during operation. To optimise the dataset for the laser tag environment, a preprocessing script was developed to filter the dataset. The script parsed every annotation file and discarded all bounding box data that did not correspond to Class 0 (pedestrian) or Class 1 (people). As a result, the network can allocate its full capacity to identifying human targets only. Subsequently, these two remaining classes were merged into a single class. Distinguishing between a pedestrian and a person provides no operational advantage for our system. + +% While the VisDrone dataset allows us to be able to identify humans from the air, it consists entirely of outdoor footage. To bridge the gap between daylight photography and the artificial lighting conditions of the laser tag maze, a synthetic dataset was generated within the Unity engine by randomly spawning 3D player models under varying lighting conditions, postures and camera angles. Fine-tuning the YOLO model on this synthetic dataset ensures high detection accuracy within the simulation by exposing the network to the specific textures it will encounter during operation. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/visdrone-dataset-cover.jpg} + \caption{Sample labelled image from the VisDrone dataset demonstrating the aerial perspective} + \label{fig:visdrone} +\end{figure} + +% For future physical development, this pipeline can be transitioned from synthetic data to empirical data. Rather than relying on Unity generation, the physical drone could be flown manually through the laser tag area to record video footage. Frames extracted from this footage would be labelled to capture the ambient lighting, wall geometry and physical equipment worn by the players. Performing this final fine-tuning pass essentially brings the simulation closer to the real world and guarantees that the network is calibrated to the operational environment. + +\subsubsection{Model Training and Deployment} +Following data preparation, the pre-trained YOLOv8n model was fine-tuned on the filtered VisDrone dataset. Training was conducted via Google Colab, utilising an NVIDIA T4 Tensor Core GPU. The training phase was configured using a $640 \times 640$ pixel input resolution to ensure a balance between the detail necessary for target detection and maintaining low-latency inference on the drone's onboard hardware. + +Once the network had converged, the final weights were exported to the \gls{onnx} format that allowed the model trained in Python to be imported directly into Unity. Within the simulation, the model is executed using Unity Sentis, a tensor engine used to run neural networks natively within the simulated environment. + +To quantify the model's convergence during training, loss and precision metrics were tracked across 50 epochs. As visualised in Figure \ref{fig:visdrone_training_results}, both the training and validation losses steadily decreased and plateaued towards the end of the run. This indicates that the neural network converged successfully and \textbf{learned the dataset's features without overfitting}. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/visdrone_training_results.png} + \caption{Training and validation loss metrics across 50 epochs for the VisDrone dataset.} + \label{fig:visdrone_training_results} +\end{figure} + +To determine the most effective confidence threshold for deployment, the F1-Confidence curve was evaluated (Figure \ref{fig:visdrone_f1_curve}). The F1 score represents the harmonic mean of precision and recall. The figure shows that the model reaches its peak F1 score of 0.53 at a confidence threshold of 0.272. Hence, we set the system to this specific threshold in order to achieve the best operational balance between minimising false positives (incorrectly classifying background noise as a player) and preventing false negatives (failing to detect a valid target). + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.65\linewidth]{figs/visdrone_BoxF1_curve.png} + \caption{F1 score across confidence thresholds for the validation set.} + \label{fig:visdrone_f1_curve} +\end{figure} + +While an F1 score of 0.53 and an mAP50 of 0.49 are lower than typical detection models, these lower results are likely as a result of the environment. As seen in the validation sample predictions (Figure \ref{fig:visdrone_val_preds}), the human targets occupy a few pixels in area due to the high-altitude aerial perspective. Visual inspection of the sample predictions confirms that the model has successfully adapted to consistently draw bounding boxes around these low-resolution targets and the suppressed mAP score reflects the inherent difficulty of drawing precise bounding boxes around them. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/visdrone_val_batch0_pred.jpg} + \caption{Sample bounding box predictions from the VisDrone validation set.} + \label{fig:visdrone_val_preds} +\end{figure} + +\subsubsection{Baseline Evaluation} + +To evaluate the operational viability of the VisDrone trained model against the system's design requirements, an automated orbital benchmark script was developed for the Unity simulation. The script positioned a virtual camera in a spherical coordinate system around a human target, sweeping through a series of yaw angles ($0^\circ$ to $360^\circ$) and pitch angles ($0^\circ$ to $80^\circ$). At each coordinate, the network's prediction was compared to the Ground Truth bounding box (derived from the target's vertex projections) to classify the result as a True Positive (TP), False Positive (FP), or False Negative (FN) based on standard Intersection over Union (IoU) and confidence thresholds. + +The benchmark was executed on two distinct simulation conditions: +\begin{enumerate} + \item \textbf{Daylight Conditions:} A bright outdoor environment featuring a concrete floor and a high-luminance skybox, replicating the daylight aerial photograph of the VisDrone dataset. + \item \textbf{Low-light Conditions:} A dark indoor environment featuring minimal ambient lighting, representing the laser tag arena. +\end{enumerate} + +% #A7C1EA used for camera background for daylight and #191B1D for lowlight + +\newpage + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.32\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/env_daylight.png} + \caption{Daylight Conditions} + \label{fig:env_daylight} + \end{subfigure} + \begin{subfigure}[b]{0.325\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/env_lowlight.png} + \caption{Low-light Conditions} + \label{fig:env_lowlight} + \end{subfigure} + + \caption{A visual comparison of the simulated lighting environments used during the automated orbital benchmark.} + \label{fig:orbital_benchmarks} +\end{figure} + +The following 2D graphs flatten the 3D hemispherical sweeps shown in Figure \ref{fig:orbital_benchmarks}. The polar axis represents the drone's yaw and the radial axis represents the camera's pitch. The centre point ($0^\circ$) denotes a horizontal, eye-level view while the outer edge ($80^\circ$) represents a top-down perspective. + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Light_Confidence.pdf} + \caption{Confidence score distribution} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Light_Classification.pdf} + \caption{TP / FP / FN categorisation} + \end{subfigure} + \caption{Orbital benchmark under Daylight Conditions.} + \label{fig:benchmark_daylight} +\end{figure} + +Under daylight conditions (Figure \ref{fig:benchmark_daylight}), the model demonstrates \textbf{robust} player detection. The confidence contour map indicates sustained detections across majority of the orbital grid, highlighting peak probability zones at steep pitch angles between $50^\circ$ and $80^\circ$. This spatial bias is expected given that the VisDrone training dataset consists primarily of high-altitude aerial perspectives. The classification plot confirms this trend, displaying a ring of True Positives around the outer edge. Consequently, the model performs well when looking down at the target from above. This also validates the fidelity of the environment itself since a neural network trained exclusively on real-world photographic data can successfully detect a synthetic target within Unity. Hence, we can verify that the \textbf{simulation environment has been configured correctly}. + + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Dark_Confidence.pdf} + \caption{Confidence score distribution} + \label{fig:benchmark_lowlight_confidence} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Dark_Classification.pdf} + \caption{TP / FP / FN categorisation} + \label{fig:benchmark_lowlight_classification} + \end{subfigure} + \caption{Orbital benchmark under Low-light Conditions.} + \label{fig:benchmark_lowlight} +\end{figure} + +In contrast, testing under low-light conditions (Figure \ref{fig:benchmark_lowlight}) reveals a clear limitation in the model. The confidence contour map (Figure \ref{fig:benchmark_lowlight_confidence}) shows generally low prediction certainty across the grid. The classification scatter plot (Figure \ref{fig:benchmark_lowlight_classification}) reflects this drop in performance with a high concentration of False Negatives replacing the True Positives seen in the daylight benchmark. This indicates that the model struggles to identify the target when ambient lighting is reduced. For the scope of this project, this confirms that the baseline VisDrone model is unsuitable for the target laser tag arena. To resolve this lighting gap, a synthetic dataset must be generated to train a model on the specific environment conditions it will face. + +\subsubsection{Synthetic Dataset Generation} +% maybe mention the lack of publicly available datasets of laser tag footage and hence this bolsters the requirement of a synthetic dataset + +To resolve the domain gap identified during baseline evaluation, an automated data generation pipeline was developed within the Unity simulation. The objective was to algorithmically render and annotate a dataset consisting of 5,000 frames tailored to the lighting constraints and textures of the laser tag arena. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.9\textwidth]{figs/SyntheticDatasetOverview.pdf} + \caption{Sample of the generated synthetic dataset. Note the variation in camera altitude, target pose, environmental lighting intensity, and maze textures.} + \label{fig:synthetic_overview} +\end{figure} + +To prevent the model from overfitting to specific synthetic visual patterns, domain randomisation was applied to every frame. The data generation script dynamically alters spatial, kinematic, and environmental variables prior to each capture: + +\begin{itemize} + \item \textbf{Camera Positioning:} The virtual camera was spawned at a random coordinate within a 3.0 to 8.0-metre radius of the target, with an altitude between 1.0 and 5.0 metres. + \item \textbf{Target Kinematics:} The player model was randomly rotated and given a spatial offset. To ensure a diverse dataset of physical poses, the model was also placed in a discrete animation state (e.g., aiming, sprinting, or transitioning to prone). + \item \textbf{Environmental Conditions:} To replicate the target arena, ambient lighting was minimised. The primary directional light was scaled to a relative intensity between 20\% and 60\% of standard simulated daylight. Furthermore, different materials and textures were dynamically applied to the surrounding walls and props. +\end{itemize} + +In a laser tag arena, players are rarely out in the open and are frequently occluded by cover. To address this, an occlusion system was implemented. The script utilises a prop pool containing varied 3D barricades and wall segments. For each generated frame, up to three of these structures are spawned at random cardinal coordinates around the target. This allows for the generation of partially occluded targets and hence the model can be trained to identify partial geometric features (such as an isolated head or arm) rather than relying on full body silhouettes. + +To generate the ground truth annotations, the labelling process was automated to calculate the bounding boxes. The 3D geometry of the target in its current pose is captured and a representative sample of points across the target's surface are projected onto the 2D plane of the virtual camera. + +To ensure the resulting bounding boxes only encompass visually exposed regions, a raycast is fired from the virtual camera's focal point to every sampled target vertex. If this ray intersects with an object other than the target, the specific vertex is classified as hidden and discarded. The system then calculates the minimum and maximum 2D screen coordinates of only the fully visible pixels, generating a bounding box that ignores occluded body parts. These coordinate bounds are then normalised into the standard YOLO format (centre X, centre Y, width, height) and written to a text file alongside the rendered image. + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/RaycastSceneView.png} + \caption{3D Scene Environment} + \label{fig:raycast_scene} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/RaycastGameView.png} + \caption{2D Simulated Camera Output} + \label{fig:raycast_game} + \end{subfigure} + \caption{Visualisation of the automated annotation and occlusion logic. Left (a): The 3D spatial environment demonstrating the raycasts, where red lines indicate vertices blocked by physical cover. Right (b): The corresponding 2D rendered frame, demonstrating bounding boxes that encapsulate only the unoccluded geometry.} + \label{fig:raycast_validation} +\end{figure} + +\newpage + +\subsubsection{Synthetic Model Training and Deployment} + +To quantify the performance of the synthetic data pipeline and ensure that the network had successfully learned the target features, training metres were monitored across the 50 epoch run. The resulting loss and performance curves are detailed in Figure \ref{fig:synthetic_training_results}. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\linewidth]{figs/synthetic_training_results.png} + \caption{Training and validation loss metrics across 50 epochs for the Synthetic dataset.} + \label{fig:synthetic_training_results} +\end{figure} + +\textbf{The training and validation curves indicate highly stable convergence. The training and validation losses both descend and this confirms that the model hasn't overfit to the synthetic data. +} +% maybe a comment on the 40-epoch drop but perhaps best made for the visdrone training and a brief mention here + +The performance metrics corroborate the successful convergence. The mean Average Precision at an Intersection over Union threshold of 0.50 (mAP50) plateaus at 0.96 and the mAP50-95 metric climbs to above 0.80. These exceptionally high metrics are a direct characteristic of synthetic datasets. Unlike human-annotated real-world data, which inherently suffers from subjective or loose labelling, the Unity pipeline generates mathematically perfect ground-truth coordinates. Furthermore, evaluating the network against validation data drawn from the exact same simulated distribution naturally yields higher accuracy. Ultimately, these theoretical metrics prove the network successfully extracted the features of the simulated human targets, + +Beyond theoretical convergence, we determined the operational threshold for the deployment of the synthetic model. The F1-Confidence curve was evaluated to identify this balance for the simulation environment (Figure \ref{fig:synthetic_f1_curve}). + +\newpage + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.65\linewidth]{figs/synthetic_BoxF1_curve.png} + \caption{F1 score across confidence thresholds for the validation set.} + \label{fig:synthetic_f1_curve} +\end{figure} + +The curve demonstrates that the synthetic model reaches a peak F1 score of 0.94 at a confidence threshold of 0.524. Because the synthetic pipeline generates mathematically consistent features and ground-truth coordinates, the network achieves a high peak confidence within its own domain. Consequently, the deployment inference threshold within the Unity Sentis tensor engine was configured to this 0.524 value. Setting the threshold at this peak ensures the system effectively balances the detection of valid targets against the rejection of simulated background noise. + +Finally, a visual inspection of the validation holdout set was conducted. As demonstrated in the sample validation predictions (Figure \ref{fig:synthetic_val_preds}), the model successfully adapts to the severe algorithmic occlusions and varied lighting conditions generated by the Unity pipeline. + +Unlike the baseline VisDrone model, which relied on high-altitude silhouettes, the synthetic model consistently draws precise bounding boxes around the exposed targets. The model accurately detects players with high confidence even when the player is prone or obscured by walls and props. This confirms that the randomisation techniques employed during dataset generation successfully produced a detection model tailored to the constraints of the simulated arena. + +\newpage + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/synthetic_val_batch0_pred.jpg} + \caption{Sample bounding box predictions from the Synthetic validation set.} + \label{fig:synthetic_val_preds} +\end{figure} + + +\subsubsection{Synthetic Model Evaluation and Comparison to VisDrone Model} + +To evaluate the synthetic model, we conducted a low-light orbital benchmark that is identical to the one completed for the VisDrone model. This test replicates the environmental constraints under which the VisDrone model experienced detection failure. + +The results for the synthetic model are visualised in Figure \ref{fig:benchmark_synthetic_lowlight}. The confidence score distribution (Figure \ref{fig:benchmark_synthetic_lowlight_confidence}) indicates consistent detection, maintaining confidence levels above 0.85 across the majority of yaw and pitch angles. However, a slight degradation occurs at extreme pitch angles. + +This stability is supported by the TP/FP/FN categorisation (Figure \ref{fig:benchmark_synthetic_lowlight_classification}). The synthetic model records zero False Negatives (FN) across the hemisphere and a few False Positives (FP) at a high pitch angle between $135^\circ$ and $180^\circ$ yaw. When contrasted with the VisDrone model, the synthetic model performs significantly better in low light conditions and is therefore more reliable in identifying the target under arena-specific illumination. + +\newpage + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/Synthetic_F_Dark_Confidence.pdf} + \caption{Confidence score distribution} + \label{fig:benchmark_synthetic_lowlight_confidence} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/Synthetic_F_Dark_Classification.pdf} + \caption{TP / FP / FN categorisation} + \label{fig:benchmark_synthetic_lowlight_classification} + \end{subfigure} + \caption{Orbital benchmark performance for Synthetic model under Low-light Conditions.} + \label{fig:benchmark_synthetic_lowlight} +\end{figure} + +Alongside low-light performance, the physical geometry of a laser tag maze introduces a second operational constraint of frequent target occlusion. Players actively utilise walls and barricades for cover, meaning the drone's perception system will rarely have an unobstructed view of a complete human silhouette. To quantify how effectively each model detects partially hidden targets, a sliding occlusion test was conducted. Figure \ref{fig:occlusion_test} plots the detection confidence of both models as the percentage of the obscured target area increases. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/Occlusion_Test.pdf} + \caption{Comparing the VisDrone and Synthetic Models under occlusion} + \label{fig:occlusion_test} +\end{figure} + +As shown in the detection curve (Figure \ref{fig:occlusion_test}), the VisDrone model experiences a decrease in confidence when the target is partially obscured. It falls below a 0.5 confidence threshold after 20\% occlusion, fluctuating before dropping to zero at approximately 40\% occlusion. This indicates that the baseline model, having been trained primarily on high-altitude pedestrian datasets, relies heavily on the complete humanoid silhouette to make a positive classification. + +In contrast, the synthetic model demonstrates a more stable detection decay curve. It maintains a confidence score above 0.9 up to 35\% occlusion and crosses the 0.5 threshold at approximately 68\% occlusion. This data suggests that the synthetic domain randomisation pipeline trained the neural network to classify partial human geometry. By learning to identify isolated features, such as an exposed shoulder or an extended arm, the synthetic model addresses the occlusion limitations observed in the Visdrone model, offering greater reliability for deployment in environments with physical barricades. + +\subsubsection{3D Coordinates via Sensor Fusion} +We use sensor fusion in order to bridge the gap between the 2D \gls{yolo} bounding box and the stereoscopic depth map to resolve the 3D Cartesian coordinates of the player. We begin with the geometric centroid ($x_i, y_i$) of the bounding box in pixel coordinates. Because the central RGB camera and stereo cameras are synchronised, this coordinate corresponds to a point on the depth map. + +If this centroid lies on a gap in the target's posture, a single pixel sample of the depth map may erroneously return the distance to the background wall rather than the player itself. In order to prevent this, the system samples a $N \times N$ kernel of pixels around the centroid and a median filter is applied to ensure that the output reflects the true target distance. + +Using the depth $z_c$, the system performs an inverse pinhole camera projection to obtain the physical horizontal ($x_c$) and vertical ($y_c$) distances in the camera frame. The geometry of this projection is illustrated in Figure \ref{fig:projection_side} and Figure \ref{fig:projection_3d}. + +The image plane coordinates are related to the 3D spatial coordinates via the focal length $f$: + +\begin{equation} + x_i = f \frac{x_c}{z_c}, \quad y_i = f \frac{y_c}{z_c} +\end{equation} + +and by rearranging these equations, the 3D position vector in the camera's frame ($P_c$) is obtained: + +\begin{equation} +P_c = \begin{bmatrix} x_c \\ y_c \\ z_c \end{bmatrix} = \begin{bmatrix} \frac{x_i \cdot z_c}{f} \\ \frac{y_i \cdot z_c}{f} \\ z_c \end{bmatrix} +\end{equation} + +\newpage + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/CameraProjection_SimilarTriangles.png} + \caption{Similar triangles for the y-axis projection.} + \label{fig:projection_side} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/CameraProjection.png} + \caption{3D perspective view relating the camera coordinate frame and image plane.} + \label{fig:projection_3d} + \end{subfigure} + \caption{Geometry of the perspective projection model from 3D spatial coordinates to the 2D image plane.} + \label{fig:camera_geometry} +\end{figure} + +In order to interface with Tommy's path following algorithm as well as Ritchie's high level controller, the vector $P_c$ in the camera's local coordinate frame must be converted into the global world frame $P_w$. + +This transformation is achieved using a series of rotation matrices which are defined for Pitch ($\theta$), Yaw($\psi$) and Roll ($\phi$): +\begin{equation} + \resizebox{0.85\textwidth}{!}{% + $R_x(\theta) = \begin{bmatrix} 1 & 0 & 0 \\ 0 & \cos(\theta) & -\sin(\theta) \\ 0 & \sin(\theta) & \cos(\theta) \end{bmatrix}, \quad + R_y(\psi) = \begin{bmatrix} \cos(\psi) & 0 & \sin(\psi) \\ 0 & 1 & 0 \\ -\sin(\psi) & 0 & \cos(\psi) \end{bmatrix}, \quad + R_z(\phi) = \begin{bmatrix} \cos(\phi) & -\sin(\phi) & 0 \\ \sin(\phi) & \cos(\phi) & 0 \\ 0 & 0 & 1 \end{bmatrix}$% + } +\end{equation} + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/CameraLocalToWorld.png} + \caption{The local coordinate frame of the drone's camera.} + \label{fig:camera_to_world} +\end{figure} + +To ensure compatibility with the Unity simulation environment, we adopt a left-handed coordinate system where the positive direction of rotation is defined as clockwise when looking down the axis of rotation. + +Initially we query the gimbal's encoders to obtain the real-time mechanical pitch ($\theta_g$) and roll ($\phi_g$) of the camera relative to the drone's chasis. These can be combined into the rotation matrix ($R_g$) that rotates the camera vector into alignment with the drone's body: + +\begin{equation} + R_g = R_x(\theta_g) \cdot R_z(\phi_g) +\end{equation} + +Although strictly we also need to take into account the translation vector for the physical displacement of the gimbal mount with the drone's centre of mass, this offset has been removed for simplicity. % or because it is negligible + +Next we read the drone's onboard \gls{imu} to acquire the drone's yaw ($\psi$), pitch ($\theta$), and roll ($\phi$). + +These attitudes dictate the drone's rotation matrix $R_d$: +\begin{equation} + R_d = R_y(\psi) \cdot R_x(\theta) \cdot R_z(\phi) +\end{equation} + +Finally, we can add the drone's own position vector within the maze ($D_w$), which is continuously updated, and this allows us to formulate the target's 3D coordinate in the world frame ($P_w$) as: +\begin{equation} + P_w = R_d \cdot (R_g \cdot P_c) + D_w +\end{equation} + +which can be expressed in matrix representation as: +\begin{equation} + \resizebox{0.65\textwidth}{!}{% + $P_w = \big( R_y(\psi) R_x(\theta) R_z(\phi) \big) \cdot \Big( \big( R_x(\theta_g) R_z(\phi_g) \big) \begin{bmatrix} x_c \\ y_c \\ z_c \end{bmatrix} \Big) + \begin{bmatrix} X_{d} \\ Y_{d} \\ Z_{d} \end{bmatrix}$% + } +\end{equation} + +\subsubsection{State Estimation and Predictive Tracking} +Although we are able to obtain the 3D global coordinates of the player ($P_w$) using the kinematic transformations above, the raw measurements will be inherently noisy due to stereoscopic depth jitter and \gls{yolo} bounding box fluctuations. In addition, the arena contains physical walls and objects that can cause temporary occlusions. As a result, we cannot rely solely on the raw visual data and must maintain a state estimate of the player's position. + +In order to achieve this, we implemented a Linear Kalman Filter to maintain a continuous, smoothed estimate of the player's position. The filter operates on a constant velocity model, allowing us to project the player's trajectory during periods of occlusion. + +\newpage + +The filter maintains an internal state vector ($X_k$) representing the target's 3D position and velocity: + +\begin{equation} + X_k = \begin{bmatrix} x & y & z & \dot{x} & \dot{y} & \dot{z} \end{bmatrix}^T +\end{equation} + +The measurement vector ($Z_k$) consists of the raw 3D position coordinates provided by the perception pipeline, as instantaneous velocity is unobservable from a single frame: + +\begin{equation} + Z_k = \begin{bmatrix} x_{m} & y_{m} & z_{m} \end{bmatrix}^T +\end{equation} + +The system dynamics are governed by the state transition matrix ($F$), which applies standard Newtonian kinematics over the sampling interval ($\Delta t$), and the observation matrix ($H$), which maps the 6-dimensional state space to the 3-dimensional measurement space: + +\begin{equation} + \resizebox{0.75\textwidth}{!}{% + $F = \begin{bmatrix} 1 & 0 & 0 & \Delta t & 0 & 0 \\ 0 & 1 & 0 & 0 & \Delta t & 0 \\ 0 & 0 & 1 & 0 & 0 & \Delta t \\ 0 & 0 & 0 & 1 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 \end{bmatrix}, \quad + H = \begin{bmatrix} 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 \end{bmatrix}$% + } +\end{equation} + +In the predict phase, the state estimate ($\hat{X}$) and error covariance ($P$) are projected forward in time from step $k$ to $k+1$: + +\begin{equation} + \hat{X}_{k+1|k} = F \hat{X}_{k|k} +\end{equation} +\begin{equation} + P_{k+1|k} = F P_{k|k} F^T + Q +\end{equation} + +The process noise covariance matrix ($Q$) accounts for unmodelled accelerations, such as the player dodging or sprinting. Here we adopt a Discrete White Noise Acceleration (DWNA) model. Under this piecewise constant assumption, the noise gain vector ($\Gamma$) maps a scalar acceleration jump into both position and velocity changes: + +\begin{equation} + \Gamma = \begin{bmatrix} \frac{1}{2}\Delta t^2 \\ \Delta t \end{bmatrix} +\end{equation} + +The covariance matrix for a single 1D axis is then calculated as the expectation of this vector scaled by the variance of the human's maximum expected physical acceleration ($\sigma_v^2$): + +\begin{equation} + Q = \Gamma \sigma_v^2 \Gamma^T = \sigma_v^2 \begin{bmatrix} \frac{\Delta t^4}{4} & \frac{\Delta t^3}{2} \\ \frac{\Delta t^3}{2} & \Delta t^2 \end{bmatrix} +\end{equation} + +When the perception pipeline returns a valid \gls{yolo} detection, the update phase executes. The Kalman Gain ($K_{k+1}$) is calculated using the measurement noise covariance ($R$), which is a diagonal matrix containing the empirical variances of the depth sensor and bounding box. The state is then corrected based on the residual between the actual and predicted measurement at step $k+1$: + +\begin{equation} + K_{k+1} = P_{k+1|k} H^T (H P_{k+1|k} H^T + R)^{-1} +\end{equation} +\begin{equation} + \hat{X}_{k+1|k+1} = \hat{X}_{k+1|k} + K_{k+1} (Z_{k+1} - H \hat{X}_{k+1|k}) +\end{equation} +\begin{equation} + P_{k+1|k+1} = (I - K_{k+1} H) P_{k+1|k} +\end{equation} + +\newpage + +\section{Search Mode} \label{search mode}% Tommy +\fancyhead[C]{Thomas August} +The objective of the multi-agent drone system is to find and eliminate players without getting eliminated themselves and this section focuses on the method of finding the players within the map. At the start of a laser tag game, the drones and players will each start in their home bases which as positioned at opposite edges of the map. At this stage, our system knows that players will be entering the map from their home base, but does not know the exact location of these players within the map, and hence all drones will start in the search mode. This mode will not only be used at the start of the game but also when a drone cannot see a player and has not received a backup call from another drone (detailed in Section \ref{high level control}). In both cases, the server will need to plan a trajectory for each drone and the drone should follow this trajectory while looking for players with the onboard camera. + +\subsection{Trajectory Planning} +In order for the drones to search the map effectively as a team they need to be coordinated which is why we run the planning for this mode on the central server. The planning will be split into two parts: region allocation and trajectory planning. The region allocation part will take the location of all drones in search mode as it's input and output a single closed region for each drone to search. Next, the trajectory planning part will take the regions from the first part and plan a closed loop trajectory of grid squares for each drone covering it's whole region. We chose this overall structure because assigning individual regions to each drone mitigates the risk of drone to drone collisions and reduces wasted time searching the same cells more than once, and planning a closed loop trajectory means the drone can search the region repeatedly. + +For the region allocation, we decided to use a multi-agent Breadth First Search (BFS) algorithm that completes BFS simultaneously from all drone start locations and allocates each cell to the drone that reached it first. This assumes all drones have a fixed starting location however, when a drone is in it's home base and is entering the map, there are multiple different entry points. For this case, we decided to run the above algorithm for all possible starting locations of any drones currently in the home base and choose the starting locations that give the smallest maximum region size. Since all drones behave the same in the BFS algorithm, if we have $d$ drones entering from the home base and $e$ possible entry cells, then we only have to complete $eCd$ runs of the region allocation algorithm described above. In our map demo map, we have 7 possible entry cells and 5 drones, giving $7C5 = 21$ runs needed at the start of the game when all drones are in the home base and going into search mode. The maximum number of runs needed occurs when 3 or 4 drones are entering the region and this would need $7C3 = 7C4 = 35$ runs to test all possible cases. Since this algorithm uses a basic BFS with an added check for allocation to the drone, it is a very lightweight algorithm so running it 35 times on the central server will require negligible computation and time so this does not need to be considered in detail. Additionally, due to it being a very lightweight algorithm, we will recompute the regions each time a drone enters or leaves the search mode for all remaining drones in search mode. + +For the path planning algorithm, we initially looked at just using a Depth First Search (DFS) tree walk along the allocated region, which is efficient when in tight maze like areas of the map, however in open spaces such as the middle of the map it still walks through it as if it is a maze, backtracking when in open space. To mitigate this behavior and make the search more efficient over the whole map, we decided to use a hybrid DFS and lawnmower search method where we assign any open spaces as a single item in the DFS tree and plan the path through this region using the lawnmower method. + +\subsection{Trajectory Following} +Now that we have planned a trajectory for each drone, the drones need a method of following those trajectories. As we are searching for players, we want this trajectory to be slow and smooth to give the gimble-camera system time to search the area. Since the behaviour needed is not complex, we opted to use basic PD controllers here to reduce the computational load. Since we would like to control the position of the drone using the propeller thrusts, we are unable to use a single PD controller to directly control position from the motor thrusts. Instead this is split into 3 stages: position PD controller, attitude PD controller, and mixing matrix. The position PD controller uses the position error and velocity as inputs and outputs an acceleration vector. This acceleration vector is then combined with the inverse of the drone weight vector to produce a desired thrust vector, and from this desired thrust vector along with the heading direction we compute a desired orientation to point all propellers along the desired thrust direction. The orientation error between this desired orientation and the current orientation along with the angular velocities are used in the second PD controller to output angular accelerations which can be converted to moments using the drone moment of inertia. These moments as well as the desired thrust vector projected onto the current upward direction are used as the drone body thrust and moments. Finally the mixing matrix (detailed in Section \ref{mixing matrix}) is used to convert these body thrust and moments to individual rotor thrusts. + +\newpage + +\section{Movement Mode} % Tommy +\fancyhead[C]{Thomas August} + +All of our play modes are team based meaning we need a method of coordinating the drones to work as a team against the human players. In order to make the game fair for the players we decided not to give the central server full control over every aspect of the drone team. For example, if a drone has detected a player's location, we have not allowed the central server to pass this information to all other drones meaning a player should not be faced with many drones against them at one time. To provide a compromise between full information sharing and no information sharing, we decided to introduce a protocol where a drone can call for backup if multiple players are detected within its view. The central server will then find the closest unoccupied drone and put it into this movement mode, in which it is given a target location where the other drone needs backup and the objective is to get there as quickly as possible. The information provided here is to give some context to why we produced a movement mode and what it's purpose is; further information regarding the interaction of the modes and the call for backup protocol can be found in Section \ref{high level control}. + +\subsection{Design Setup} +In order to best decide on the optimal algorithms and methods to use within this mode, we first outlined the criteria for this state to meet. The inputs will be the current grid square of the drone and the target grid square, and the outputs will be the drone thrust and moments. The drone behaviour we need from this mode is for it to reach the target location as quickly as possible with a reliable success rate. We do have the collision avoidance which would abort an unsuccessful trajectory if it is executed, however it is still optimal to ensure all modes have a high success rate to avoid the need to use collision avoidance as much as possible. This task can be split into the planning stage and the execution stage. We decided to run the planning stage on the central server, since the drone and target grid coordinates are already stored there and this will reduce the computational load on the drone. This will output a trajectory through the 2D map for the drone to follow in the execution stage. Since the execution stage involves the direct control of the drone thrust and moments, we decided to run this onboard to reduce latency, as high latency would introduce unnecessary complexity to the control algorithm. + +\subsection{Planning Stage} + +As mentioned above, the planning stage will need to compute a path through our known 2D map of the maze from the current drone location to the target location. Since the objective of this method it to reach the target location as quickly as possible, we want to plan the shortest path in order to minimise the distance travelled. To do this, we decided to use a Breadth First Search (BFS) algorithm which uses our map (detailed in Section \ref{map}) to determine which adjacent cells can be accessed from the current cell. This algorithm runs until the target location is reached, and then the shortest path is determined by starting at the target location and adding the parent node of the previous node recursively until it gets back to the current location, and then reversing the order. Since the map we have designed is 11x17 grid squares, there are 187 grid squares, so the number of possible paths is $187 \cdot 187 = 34,969$, and since this will be run on the central server, we decided so pre-compute all possible paths as storage will not be a problem on the central server and this will reduce the computation time and hence get the drone moving towards the target location quicker. In order to access it efficiently, we will use a lookup table from which the programme can request paths using the start and end coordinates. + +Now that we have the shortest 2D path through the grid squares, we need to convert this to a trajectory for the drone to follow in the 3D arena. In order to minimise the chance of collisions with the map and provide the drones with as much freedom of movement as possible, we decided to place the trajectory checkpoints in the centre of each grid square, halfway between the net and the ceiling. These checkpoints are then sent to the drone along with the command to change into movement mode. + +\subsection{Control Method} +In the other modes we have described using PD controllers to track the drone trajectories due to it having a low computational cost, however, since we would like this mode to be as quick as possible, we are willing to use more compute in order to reach the target location quicker. This led us to look at more complex control methods such as Reinforcement Learning (RL) and Model Predictive Control (MPC). When researching the methods above we came across a paper that uses MPC to train a RL policy online using supervised learning, \cite{zhang_learning_2016}, and although we did not use the method explained in this paper, their reasoning in the introduction helped decide what method was best for our application. In the introduction they stated that "MPC is an effective and reliable method ... However, applications of MPC can be computationally demanding" and "model-free RL is difficult to apply to unstable systems such as quadrotors, due to the possibility of catastrophic failure during training." From this we can see that their justification for using an RL policy trained under supervision from an MPC controller is because they aim to achieve the reliable results from MPC but with the lower computational load of RL, however, they decided not to train direcly with RL becuase in the early stages of training this would lead to catastrophic damage of their hardware. In our situation, we also aim to get reliable results while maintaining the lower computation load of RL, however, instead of using online supervised learning, we opted for offline learning on a physics simulator, which allows us to train the RL policy unsupervised without causing catastrophic damage to hardware during the early stage of training. This also allows us to train and test this policy without needing physical hardware, which speeds up the design phase. Additionally, in the paper, they mention that they passed the raw sensor data as the input to the RL policy to avoid having to estimate the state, however since we already need to estimate the state (detailed in Section \ref{state estimation}), for the Search and Collision Avoidance modes (detailed in Sections \ref{search mode} and \ref{collision avoidance mode} respectively), we decided to get the inputs for our RL policy from this estimated state instead to avoid increasing the complexity of the control problem unnecessarily. We opted for the policy to output body thrust and moments, again to avoid unnecessarily increasing the complexity, because we already need the mixing matrix (detailed in Section \ref{mixing matrix}) for the other modes. + +In conclusion, we opted to use a reinforcement learning policy trained offline on a physics simulator using Isaac Lab \cite{IsaacLab}. The inputs of our policy are be derived from the estimated state and the outputs are the thrust and moments of the drone body. + +\subsection{Environment Setup} + + + + + +\newpage + +\section{Collision Avoidance Mode} \label{collision avoidance mode} % Tommy +\fancyhead[C]{Thomas August} + +As much as we have tried to mitigate the possibility of collisions when designing the different control systems for the drones, there will inevitably still be some collisions that would occur, so we need a method of avoiding collisions in real time that are likely to occur in the near future. Our implementation of this uses constant collision detection to force the drone into collision avoidance mode when there is likely to be an imminent collision. + +\subsection{Collision Detection} +For the collision detection, we chose to monitor the distance and velocity towards the obstacle and enter collision avoidance mode when the estimated time to collision from these values is below a threshold. Since the drones will estimate their pose and velocity onboard (detailed in Section \ref{state estimation}), the distance, d, to the closest map obstacle in the direction of the velocity, v, can be calculated and used to find the estimated time to collision using the formula $t=d/v$. Since the pose, velocity and map are all stored onboard, this detection can be run onboard the drone to reduce latency and catch potential collisions quicker. For drone to drone collisions, the pose and velocity of the other drones will have to be sent through the server to other drones, so this will already introduce latency. Due to this, we chose to run the drone to drone collision detection on the server so that we do not get conflicting decisions from the two drones and a unanimous decision can be made for both drones. To determine if a drone to drone collision is imminent, the server will receive the pose and velocity of both drones and propagate the drone poses based on their velocities for time up to the collision detection time threshold and calculate the distance between the two at each time step. If the distance between the two drones is below a small threshold distance to account for noise in the data, then both drones are forced into collision avoidance mode. + +\subsection{Collision Avoidance} +For the collision avoidance method, we chose to use an Artificial Potential Field (APF) based method. Since we know the exact map and we can estimate the position of all drones in the environment, we can place repulsive potential fields perpendicular to the walls, net, and ceiling, and around all other drones, each acting as a point source. We can then sum the potential from all of these at the location of the current drone and take the gradient to find the best direction to move in. We will use the gradient of the potential field as a target velocity and use a PD controller to find the acceleration vector needed to track this velocity. This acceleration vector is then converted to a force vector using the mass of the drone and an upwards force with magnitude equal to the drone is added to this as the hover force to get a final force vector. This force vector and the velocity direction vectors are used to create a coordinate frame by taking the cross product of the two to get the third vector. The error between the current drone orientation and this desired orientation is then computed and used with the angular velocities as the input to another PD controller that outputs the desired drone moments. The desired force vector from the first PD controller is then used as the thrust combined with these moments as the output of the collision avoidance controller and is fed into the mixing matrix (detailed in Section \ref{mixing matrix}). + + + + + +\newpage + +\section{Mixing Matrix} \label{mixing matrix} % Tommy, Rishabh +\fancyhead[C]{Thomas August} + + +\newpage + + +\section{App} % Ritchie +\label{app} +\fancyhead[C]{Richard Usherwood} +\subsection{Context} +From fast-food restaurants to road cycling, apps are everywhere. Their purpose can be separated into two categories: Engagement and Functionality. + +\paragraph{Engagement} \(\) \newline +Companion apps encourage user-engagement by allowing users to track their progress through points and leaderboards, track achievements, and connect with friends. For example, popular birdwatching app "Birda" is used by users to log bird sightings. It rewards users with achievement badges when they complete objectives (for example, having logged ten different species), and integrates monthly challenges. It also connects birdwatchers through the "community" feature, allowing users to view their friends' activity and sightings by strangers in their area. + +\paragraph{Functionality} \(\) \newline +Companion apps also serve a functional purpose. Since effectively everyone in the UK owns and uses a smartphone, they can be directly implemented into the experience of an existing product. For example, popular budget UK pub chain JD Wetherspoon uses a companion app to allow patrons to order drinks and food directly to their table, without requiring them to break conversation and queue at a busy bar. + +\subsection{Overview} +When opened for the first time, the app prompts the user to create an account with a username and password. If the user has already created a login, they will instead be prompted to enter their user name and password. This is shown in Figure \ref{fig:0_Login_Screen}. When completed, the app the first of five screens that are navigated using a bottom panel: the "Profile" screen, the "Leaderboard" screen, the "Achievements and Challenges" screen, the "Community" screen, and the "Play in Person" screen . The first four screens are engagement-based, and the fifth is functionality-based. As an example, the "Leaderboard" screen is shown in Figure \ref{fig:lea-screen}. The app user can toggle between viewing a global leaderboard and a leaderboard of only their friends + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/2_1_Leaderboard_All.jpg} + \caption{Leaderboard Screen - Global Leaderboard Tab} + \label{fig:lea-glo} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/2_2_1_Leaderboard_Friends_No_Alice.jpg} + \caption{Leaderboard Screen - Friends Only Tab} + \label{fig:lea-fri} + \end{subfigure} + \caption{Leaderboard Screen} + \label{fig:lea-screen} +\end{figure} + +\subsection{Engagement} + +Apps encourage user engagement in many ways. A few are outlined below: + +\subsubsection{Progress} +Tracking progress encourages user engagement by giving users a sense of achievement and improvement over time. The app achieves this in many ways: +\begin{itemize} + \item The user's total score is displayed under their profile, allowing them easily to track progress. + \item The user can track their progress against their friends in the Leaderboard screen. + \item The user can achieve achievements are specified, and the player is rewarded with a notification when one has been completed. Added to this are monthly challenges, allowing all users satisfaction from short-term progress. +\end{itemize} +\subsubsection{Friends} +Connecting friends and integrating social features encourages user engagement by allowing users to see their friends' progress. The app achieves this in many ways: +\begin{itemize} + \item The Leaderboard screen allows players to compare themselves only against their friends (as shown in Figure \ref{fig:lea-fri}. + \item The Community screen allows players to see recent activity of their friends, as well as to send and accept/decline friend requests. +\end{itemize} +\subsubsection{Notifications and reminders} +Integrating Notifications and reminders prompts users to engage regularly with the app. Notifications are delivered to the phone's operating system notification bar for the following reasons: +\begin{itemize} + \item The user has completed an achievement/monthly challenge. + \item The user has overtaken/been overtaken by a friend in the Leaderboard. + \item The user has a new friend request. +\end{itemize} + + +% The "Profile" screen displays the player's details (Player ID, name etc.), the score details (number of games played, number of kills and deaths, total score), and the player's social details (friends, friend requests). This is shown in Figure \ref{fig:1_Profile_Screen}. + +% \begin{figure}[H] +% \centering +% \includegraphics[width=0.25\linewidth]{figs/App_Screenshots/1_Profile_Screen.jpg} +% \caption{Profile Screen} +% \label{fig:1_Profile_Screen} +% \end{figure} + + + +% The "Leaderboard" screen displays a list of players in order of their total score. The app user can toggle between viewing a global leaderboard and a leaderboard of only their friends. This is shown in Figure \ref{fig:lea-screen}. \newline + + + + + +% The "Achievements and Challenges" screen displays all achievements (lifetime goals, for example "Play ten games", "Kill fifteen drones in one game", "Be the last player alive in a death match" etc.), shown in Figure \ref{fig:ach-lif}, and monthly challenges (smaller achievements that reset and change every month), shown in Figure \ref{fig:ach-mon}. The inclusion of lifetime achievements allows for a long-term feeling of improvement, while the monthly challenges allow new players to compete with their more experienced friends. \newline + + + + + +% The "Community" screen toggles between displaying details of recent games played by the app user's friends, and displaying details of all recent games played. It also allows users to search for other players by name, or by Player ID, and to send each other friend requests. Figure \ref{fig:4_2_Receiving} shows a screen displayed when the player "Alice" has made a friend request to the player logged into the app. Figure \ref{fig:4_2_Sending} shows a screen displayed when the player logged into the app is sending a friend request to the player "Bob". This system allows players to track each other's progress, and allows players to feel connected to friends they may have made through playing the game in person. + + + +\subsubsection{Functionality} +The user experience of playing game in the centre, using the app, is outlined below. +\begin{itemize} + \item THe user signs in to the app (or create an account if this has not already been done). The Login screen is shown in Figure \ref{fig:userstory1}. + \item The app displays the Profile Screen. Using the bottom panel (shown in Figure \ref{fig:App-Panel}, the user navigates to the "Play in Person" Screen. The Profile Screen is shown in Figure \ref{fig:userstory2}. + \item The player uses the "Play in Person" screen to scan QR codes on the gun and the helmet given to you by the centre. The Play in Person screen is shown in Figure \ref{fig:userstory3}. + +\end{itemize} +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/0_Login_Screen.jpg} + \caption{Login Screen} + \label{fig:userstory1} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/1_Profile_Screen.jpg} + \caption{Profile Screen} + \label{fig:userstory2} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/5_Play_In_Person.jpg} + \caption{Play in Person Screen} + \label{fig:userstory3} + \end{subfigure} + \caption{From Left to Right: The user experience of using the app in for functionality} + \label{fig:userstory} +\end{figure} + + +This allows the server to attribute the correct number of kills and deaths (infra-red strikes on drones, encoded with ID of the gun, and infra-red strikes on helmet detector, communicated to server via WiFi) to the correct player. + +\subsection{Usability Design Choices} +In 2010, Lee et al \cite{LEE201090} identified several "Principles for General System Design", with respect to complex 3D architectural design and engineering tools. While this use-case is not identical to that of Lee et al, the principles are still relevant. The following are examples of the identified "Principles": +\subsubsection{Visibility} +Lee et al describe the use of visibility in UI design as "Making relevant information conspicuous and easily detectable to the user". This has been achieved by the large panel at the bottom of the app, visible at all times, as shown in Figure \ref{fig:App-Panel}. Furthermore, the open-source React icons encourage faster visual recognition from the user, increasing the visibility of the relevant information (in this case the purpose of each screen). +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{figs/App_Screenshots/Bottom_Panel.png} + \caption{Bottom Panel} + \label{fig:App-Panel} +\end{figure} +\subsubsection{Feedback} +Lee et al describe the use of feedback in UI design as "Response of the system to the user’s actions in order to provide information regarding the internal state of the system". As an example of this principle in the design of this app, the icon in the bottom panel corresponding to the screen currently being displayed is filled in (a variant of the React icon is displayed), and is red. When a user changes screen, the "internal state" of the app is reflected by the change of icon displayed in red. As another example, when a friend request is made, the user receiving the request sees a box with two buttons: "Accept" and "Decline", as shown in Figure \ref{fig:App-Friend_Request}. When the user selects one of these options, the box disappears. While this is not required for the functionality of the system, the change to the external state of the app (the box disappearing) reinforces instinctively to the user of a change to the internal state of the app (the friends associated with a player in the database). + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/App_Screenshots/Fried_Request_Box.png} + \caption{Box displayed when receiving a friend request} + \label{fig:App-Friend_Request} +\end{figure} +\subsubsection{Consistency} +Lee et al describe the use of consistency in UI design as "Uniformity of system semantics across similar situations". In this context, "system semantics" refers to the method the user is expected to use when interacting with the UI, as well as the use of language, technical or otherwise. As an example, the app uses a dark grey and red colour scheme, in which, across pages, red is used to mean "active/on" and dark grey is used to mean "passive/off". This is seen in the bottom panel (Figure \ref{fig:App-Panel}) and top panel in the achievements (Figure \ref{fig:ach-screen}) and community (Figure \ref{fig:com-screen}) screens, in which the screen being displayed in shown in red. It is also seen in the player profile (Figure \ref{fig:0_Login_Screen} and login (Figure \ref{fig:1_Profile_Screen} screens, in which the Login/Logout buttons are coloured red. It is shown in the box displayed when receiving a friend request (Figure \ref{fig:App-Friend_Request}) in which the "Accept" button, which changes the user's list of friends, is coloured red, and the "Decline" button, which leaves the user's list of friends as it is, is shown in dark grey. + + + +\subsection{Technical Details} +\subsubsection{Overview} +The app was created using Expo. Expo is a development framework built to create React Native apps. React Native is a framework that allows mobile apps to be built using React. Finally, React is a JavaScript library built for user interface design. +\subsubsection{Project Structure} +When the app is run, it opens a "package.json" file which sets the rest of the app in motion. From here, it exectutes index.js which imports App.js, which opens MainContainer.js. MainContainer.js serves as the app's navigation hub. MainContainer.js decides which "navigation flow" to show, based on whether the app is in state "Auth" or "Main" (whether the user is signed in or not). From here, MainContainer.js accesses each of the displayed screens, each of which has a dedicates JavaScript file in the "screens" subfolder. +\subsubsection{State Management} +The app uses a hybrid state management strategy. That is to say, not all states are stored centrally (fully global), and not all states are managed independently by an individual screen (fully local). The React Context including AuthContext (whether or not a user is logged in) and DataContext (cached API data) are stored centrally, however each screen also stores its own data, such as the the data of the user's last game (in profile screen), friend requests a user may have (in community screen) etc. \newline This hybrid style of state management has several advantages. For example, the fact that low-level data is stored in the JavaScript file corresponding to the screen it is needed in allows for good "separation of concerns", meaning that, if the project were bigger than it is now, several developers could be editing different parts of the software without interfering. Additionally, by having some data stored separately, such as API cached data, each screen can "reach in" to this file and get what it needs, rather than the same data having to be stored in many different places. +\subsubsection{API Integration} +The App uses Supabase as its backend platform, to access an PostgreSQL database. Database access is handled through a single client in "db.js" - after the app is loaded, the data is cached in datacache.js to avoid unnecessary loading times, especially when being used with poor internet connections. A screenshot of the database is included in the appendix. + + + +A specific format had to be created for this data to be stored. For example, Game Data is stored in a format (A, B, C, \dots),(D, E, F, \dots),(G, H, I, \dots). This game data is equivalent to "Players A, B, C, \dots played a game in which they got D, E, F, \dots kills and died G, H, I, \dots times, respectively". Furthermore the "score" is defined as "number of kills squared divided by number of deaths" in a game, and the friend requests are stored as CSVs. When a change to the data is made in the app (for example sending or accepting a friend request), the database is automatically through API calls. However, the database must also be updated after every game. In the real system, this would be integrated into a system that processes communications with drones and helmets, and updates the database automatically. However, for now it is handled by a script that allows the user to input the results of the game (who was playing, how many kills they got, how many times they died etc.), and updates the database accordingly. + +\newpage +\section{Safety and Risk Assessment Management} + + +A quantitative risk assessment has been completed, and is shown in Figure \ref{fig:risk-assessment}, in the appendix. The most significant initial risks (before mitigations) were the the contact between guns and players' eyes, and players running into each other. After the necessary control measures, they are still most significant residual risks, along with trips and falls. This demonstrates that there is not an undue risk associated with playing the game, since trips and falls, player-on-player collision and impact with instruments used for playing (such as laser-guns, squash raquets, etc.) are risks associated with traditional laser-tag, as well as many common sports. + +\newpage +\section{Commercialisation and Financial Modelling} +\subsection{Setup} +A discounted cash flow model was created. The model was used to track cash flow, apply a discount rate to future revenue, and to calculate the Net Present Value (NPV) of a company providing the game as a commercial enterprise. +\subsection{Numerical Estimations} +\subsubsection{Utility} +It is assumed that the first year (Year 0) will be spent producing hardware, advertising the business, and decorating the playing area (a warehouse). Year 0 is therefore assumed to generate no revenue from gameplay. As the business becomes more established, its utility (games per year) is modelled to increase up to a plateau in Year 3. The modelled increase in utility is shown in Table \ref{tab:utilityandemployees}: + +% \begin{table}[h] +% \centering +% \begin{tabular}{|c|c c c c c c|} +% \hline +% Year & \qquad 0 & \quad 1 & \quad 2 & \quad 3 & \quad 4 & \quad \dots\\ +% \hline +% Percentage of Maximum Utility & \qquad 0\% & \quad 50\% & \quad 75\% & \quad 100\% & \quad 100\% & \quad \dots \\ +% \hline +% \end{tabular} +% \caption{Utility evolution with time} +% \label{tab:utility} +% \end{table} + +As a first approximation, the maximum number of games per year was assumed to be 2000, corresponding to 10 hour-long games on Saturday and Sunday, and four hour-long games on weekdays, for 50 weeks per year. Note that this "maximum utility" refers to the value at which utility plateaus, not a fundamental limit. \newline + +The effect of a variation in utility is analysed in Section \ref{PriceAnal}. + + + +\subsubsection{Employee Costs} +The minimum equivalent number of full-time employees required was thought to be two. The number of full-time employees was assumed to increase with utility, up to a maximum of four, as shown in Table \ref{tab:utilityandemployees}: + + +\begin{table}[h] +\centering +\begin{tabular}{|c|c c c c c c|} +\hline +Year & \qquad 0 & \quad 1 & \quad 2 & \quad 3 & \quad 4 & \quad \dots\\ +\hline +Percentage of Maximum Utility & \qquad 0\% & \quad 50\% & \quad 75\% & \quad 100\% & \quad 100\% & \quad \dots \\ +\hline +Full-Time employees & \qquad 2 & \quad 2 & \quad 3 & \quad 4 & \quad 4 & \quad \dots \\ +\hline +\end{tabular} +\caption{Number of employees with time} +\label{tab:utilityandemployees} +\end{table} +% \begin{table}[h] +% \centering +% \begin{tabular}{|c|c|c|} +% \hline +% Year & Percentage of Maximum Utility & Equivalent Number of Full-Time Employees\\ +% \hline +% 0 & 0\% & 2\\ +% 1 & 50\% & 2\\ +% 2 & 75\% & 3\\ +% 3 & 100\% & 4\\ +% 4 & 100\% & 4\\ +% \vdots & \vdots & \vdots \\ +% \hline +% \end{tabular} +% \caption{Utility and Number of Employees with time} +% \label{tab:utilityandemployees} +% \end{table} + +It was also estimated that the cost of employing one full-time employee (or equivalent in part-time workers) would be £50000. This includes salaries, company computers, training, sick cover, annual bonuses etc. +\subsubsection{Warehouse Hiring} +The game is assumed to be played in a converted warehouse. The size of warehouse required for the game was thought to be comparable to that of a large school hall (circa. 5000 square feet). Including space for a reception area, a small office and a break room for staff, between 6000 and 7000 square feet was thought to be an appropriate size. The warehouse should be within a short drive of a large city. A 6800 square foot warehouse in London was identified at £2000 pcm \cite{rightmoveCheckThis}. The cost of hiring the warehouse is therefore estimated at £25000 per annum. +\subsubsection{Advertising} +The advertising budget is large, because early revenue has a disproportionate affect on NPV due to the large discount rate. It is therefore desirable to invest heavily in advertising initially, spending as little time as possible operating below maximum utility. Advertising will continue even when maximum utility has been reached. This is necessary to keep the business reaching new audiences, and if it is to advertise new features. It is assumed that advertising costs are constant throughout operation. This may be unrealistic, but produces a conservative estimate. After conversations with Global (the advertising agency responsible for Transport for London), the cost of a "small-scale advertising campaign" involving one-to-two posters in several small, outer-London underground stations and a small presence in carriage poster advertising is around £2000 per month. The cost of 1000 views for a social media advertising campaign is around £10 for Facebook, Instagram, and TikTok. So, for £500 per month, 50000 views of social media advertising can be bought. These can be localised so only users in London will be shown advertising. \newline + +Therefore, the projected required advertising budget is given by +\begin{equation} + \label{equ:advertising} + \text{Cost [£/Year]} = \left (2000\text{ £/month} + 500\text{ £/month}\right ) \times 12\text{ months/year} = £30000\text{ £/year} +\end{equation} + + + +\subsubsection{Electricity} +\paragraph{Heating} \(\) \newline +The warehouse is assumed to be heated electrically. The heating power is given by: +\begin{equation} + \dot Q=U_wA_w\Delta T+U_rA_r\Delta T+U_fA_f\Delta T +\text{ACH}\cdot \frac{\rho c_p V\Delta T}{3600} +\end{equation} +where \(U,A,\Delta T\) denote the U-Value (thermal transmittance), area and the indoor-outdoor temperature difference, and subscripts \(w,r,f\) the walls, roof and floor respectively. \(\text{ACH}, \rho, c_p, V\) denote the equivalent number of complete air changes per hour, air density, air specific heat capacity (constant pressure), and volume respectively. As a rough estimate, the warehouse is assumed to have U-Values three times greater (less well insulated) than the maximum specified for newly built houses under UK law \cite{UValueRegs}. This is summarised in Table \ref{tab:U-Values}. +\begin{table}[h] +\centering +\begin{tabular}{|c|c|c|} +\hline +&Maximum U-Value [\(W/m^2K\)]& Assumed U-Value for warehouse [\(W/m^2K\)]\\ +\hline +External Walls & 0.26 & 0.78 \\ +Roof (pitched)& 0.16 & 0.48 \\ +Floor & 0.18 & 0.54 \\ +\hline +\end{tabular} +\caption{Maximum U-Values for newly built residential properties and assumed U-Values for the warehouse} +\label{tab:U-Values} +\end{table} + +Additional assumptions are made, as shown in the appendix in section \ref{assumptions}. As shown in equation \ref{app:heating-calcs}, it is found that the total heating power required to maintain a temperature of \(20^\circ C\) is 17.6 kW. +\newline + +\paragraph{Lighting} \(\) \newline +To calculate the lighting costs, it is assumed the warehouse requires fifty 100W equivalent LEDs, each drawing 15W of power, to avoid dark shadows in the maze corners. However, since the game is played in (relative) darkness, the lights will only be required in between play sessions. Each game lasts 45 minutes, separated by 15 minute breaks, so the lights will only be "on" one quarter of the time. Therefore the effective power of the lighting is given by \(\dot Q = \frac 14 \times 50\times100W = 1.3kW\). + +\paragraph{Batteries} \(\) \newline +Batteries in drones and laptops used by employees both must be charged. Both are assumed to be charged by standard \(65W\) chargers. There are assumed to be 20 batteries in total, and it is assumed they are all charging whenever the centre is open. The effective power draw of charging batteries is estimated at \(\dot Q=20\times 65W=1.3kW\). + +Therefore the total power draw of the operational warehouse is approximated to \(17.6kW+1.3kW+1.3kW=20.2kW\) + +\paragraph{Full Electricity Cost} \(\) \newline +According to the Department for Energy Security and Net Zero's Q2 2025 Energy Prices report \cite{EnergyPrices}, the average electricity cost to non-domestic users (including Climate Change Levy) over the last three years is around 25p/kWh. This will be used to calculate an annual electricity cost. It is also assumed that the warehouse will need to be open 3000 hours per year (for 2000 hour-long games per year), to include unbooked game slots, maintenance and opening preparation time. The final electricity cost is therefore given in Equation \ref{equ:eleccost}. +\begin{equation} + \label{equ:eleccost} + \text{Electricity Cost [£/Year]}=20.2\text{kW}\times3000\text{ hours/year} \times 0.25 \text{ £/kWh}=£15150/\text{year} +\end{equation} + +To keep the estimate conservative, to allow for fluctuations in electricity price and to allow for miscellaneous costs (employees boiling a kettle, for example), this value will be rounded up to a final electricity cost of £20k/year. + +\subsubsection{Warehouse Decoration and Maintenance} +Year 0 will be used to prepare the warehouse for laser-tag. From Year 1 onward, this budget will only be spent on repairing wear-and-tear. Chaboun Construction (a London-based building services provider) estimates £50000 for a basic, 3-bedroom house renovation \cite{chabounconstructionMuchDoes}. However, much of this cost is related to the kitchen and the bathrooms, and in rewiring/replumbing. None of this applies to the warehouse, and (certainly to begin), non-premium materials will suffice. However, the warehouse is much larger than a 3-bedroom house. The price of Year 0 was therefore estimated at £30000. £10000 was selected as the budget for redecoration and maintenance. This is probably higher than strictly realistic, but accounts for the fact that a complete redecoration will be necessary every few years, and maintains a conservative estimate. + +\subsubsection{Hardware} +The drones themselves cost a little under £500 to produce, of which 10 are required. Including other hardware (laser-guns, helmets and battery chargers), the model assumes the total cost is £10000. This is conservative estimate. The hardware will get slightly damaged during operation. Some components (such as blades) are likely to need replacing often, whereas some (such as laser-guns) are likely not to require frequent replacement. For simplicity, the model assumes that a full hardware replacement is required every 500 games, after a full set is fabricated in Year 0. + +\subsubsection{Revenue} +The cost of hiring exclusive usage of a laser-tag facility is commonly around £15-£20 per person per hour. For example, LASERGAMING OXFORD charges £29.50 per person for two hours of exclusive use \cite{outdoorlaserLasergamingEXCLUSIVE}. A drone-based experience could afford to charge two to three times this fee, due to its novelty value. The game is designed to be played by three to eight people at once. The cost per game is therefore projected to be £200 per hour game per group, as a first estimate. \newline + +The effect of a variation in game price is analysed in Section \ref{PriceAnal}. + +\subsubsection{Aggregate} +Hence, the total Income \& Expenditure Table, not including tax or external financing (such as bank loans, equity etc.) is shown in Table \ref{tab:IE}. + +\begin{table}[h] +\centering +\begin{tabular}{|c| c c c c c c|} +\hline +Year & 0 & 1 & 2 & 3 & 4 & \dots \\ +\hline +Warehouse Hire & 25 & 25 & 25 & 25 & 25 & \dots \\ +Electricity & 20 & 20 & 20 & 20 & 20 & \dots \\ +Warehouse Decorating \& Maintenance & 30 & 10 & 10 & 10 & 10 & \dots \\ +Employees & 100 & 100 & 150 & 200 & 200 & \dots \\ +Advertising & 30 & 30 & 30 & 30 & 30 & \dots \\ +Hardware & 10 & 20 & 30 & 40 & 40 & \dots \\ +\hline +Revenue (Game Fees) & 0 & 200 & 300 & 400 & 400 & \dots \\ +\hline \hline +Profit & -215 & -5 & 35 & 75 & 75 & \dots \\ +\hline +\end{tabular} +\caption{Income \& Expenditure projection - all values in £k} +\label{tab:IE} +\end{table} + +It is observed that the annual non-discounted profit stabilises at £75000. + +\subsection{Initial Capital Investment} + +In Year 0, £215k of capital is required for startup costs, and will be funded through both equity (seeking investors) and bank loans. \newline Bank loans are much more "unforgiving": if the company fails to do make repayments, it must declare bankruptcy. Private investment requires no such repayments. Investors make money on their investments through share appreciation and dividends, so require no fixed repayments. Because of this, they require a higher interest rate than bank loans (discussed in section \ref{DiscountRate}). This means that relying heavily on equity financing increases effective discount rate, reducing the effect of future revenue on Net Present Value.\newline As a balance, the business seeks £100k in bank loans and £115k in equity financing. + +\subsection{Discount Rate} +\subsubsection{Overview} +The equity-only discount rate is used by investors to assess the viability of a business. It is assumed that an investor could make interest on capital, by not investing in a business, at annual interest rate (or discount rate) \(d\). So, the value of their capital \(P_0\) after \(t\) years, \(P(t)\), would be given by: + +\begin{equation} + P(t)=P_0(1+d)^t +\end{equation} had they chosen not to invest. Therefore, the "present value" \(P_0\) of money \(P(t)\) they would own \(t\) years in the future, is given by: +\begin{equation} + P_0=\frac{P(t)}{(1+d)^t} +\end{equation} so the projected returns must exceed \(\frac{P(t)}{(1+d)^t}\) if the business is to be considered a profitable investment. + +The choice of equity-only discount rate is made by investors when choosing whether or not to invest. Investing in a small start-up is riskier than investing in a large, established business, so the applied equity-only discount rate tends to be very high for start-ups (around 15-30\%). + + +\subsubsection{Modelling Discount Rate} +\label{DiscountRate} +Two common approaches to model discount rate are: Equity-Only Discount Rate, and Weighted Average Cost of Capital (WACC). +\paragraph{Equity-Only Discount Rate} \(\)\newline +Using an Equity-Only Discount Rate, the discount rate applied to future cash flows is set by investors, ignoring debt interest from the bank. Therefore the Year 0 capital injection from the bank loan \(P\) and the annual debt repayments \(A\) in subsequent years must be included in the cash flow, and the remaining balance after \(t\) years \(B_t\) on the bank loan must be considered as a liability in the terminal value (discussed in section \ref{TermValue}). These are determined by the amortisation formula, shown in equation \ref{equ:amortisation}. + +\begin{equation} + A=\frac{Pr_d}{1-(1+r_d)^{-N}}, \qquad\qquad B_t=P(1+r_d)^t-A\frac{(1+r_d)^t-1}{r_d} + \label{equ:amortisation} +\end{equation} + + + + + +% The annual repayment \(A\) on a loan of initial size \(P\) over a term \(N\) years that gathers interest at annual rate \(r_d\) is given by the amortisation formula: +% \begin{equation} +% A=\frac{Pr_d}{1-(1+r_d)^{-N}} +% \label{equ:amortisation} +% \end{equation} and the remaining balance \(B_t\) after \(t\) years is given by: + +% \begin{equation} +% B_t=P(1+r_d)^t-A\frac{(1+r_d)^t-1}{r_d} +% \end{equation} +% Using an equity-only discount rate, Additionally, the terminal value (discussed in section \ref{TermValue}) must include the remaining loan balance as a liability. + + +\paragraph{Weight Averaged Cost of Capital (WACC)} \(\) \newline +Another approach is to weight the bank loan interest rate \(r_d\) and the equity-only discount rate \(r_e\) to produce an "effective" discount rate, or WACC, used in NPV calculations. The WACC is given by: +\begin{equation} + \text{WACC}=\frac{D}{D+E}r_d+\frac{E}{D+E}r_e +\end{equation} +where \(D\) is the initial capital of the bank loan, and \(E\) is the capital investment from equity financing. + +Using WACC, it is not necessary to model the loan an the debt repayments as cash flows , or the remaining balance as a liability; these are all captured by the use of WACC. + +Therefore, for the sake of simplicity, WACC is used in this model, with rates: +\begin{equation} + r_d=15\% \qquad r_e=20\% +\end{equation} + +The effect of a variation in discount rate is analysed in Sections \ref{NPVProfile} and \ref{DPS}. + +\subsubsection{Terminal Value} +\label{TermValue} +The "left-over" value of a business after a fixed term of \(t\), the "Terminal Value", with cash flow (positive cash flow corresponding to profit) in year k, \(\text{CF}_k\), is given by: +\begin{equation} + \text{TV}_t=\frac{\text{CF}_{t+1}}{1+d}+\frac{\text{CF}_{t+2}}{(1+d)^2}+\frac{\text{CF}_{t+3}}{(1+d)^3}+\dots +\end{equation} +If cash flow can be assumed to be constant after \(t\) years, \(\text{CF}_{t+1}=\text{CF}_{t+2}=\text{CF}_{t+3}=\dots=\text{CF}\), + +\begin{equation} + \text{TV}_t=\frac{\text{CF}}{1+d}+\frac{\text{CF}}{(1+d)^2}+\frac{\text{CF}}{(1+d)^3}+\dots = \sum_{k=1}^\infty \frac{\text{CF}}{(1+d)^k} +\end{equation} +which can be rearranged to: +\begin{equation} + \text{TV}_t=\frac{\text{CF}}{d} +\end{equation} +This is the undiscounted Terminal Value; to get the present value of \(\text{TV}_t\), it must be multiplied by \(\frac1{(1+d)^t}\). +\begin{equation} + \text{TV}_{t, \text{discounted}}=\frac{\text{CF}}{d}\times \frac 1{(1+d)^t} + \label{equ:DTV} +\end{equation} + +\subsection{Tax} +\label{Tax} +Tax is modelled under UK corporation tax laws. For a given year, the taxable income revenue subtract allowable business expenses. Depending on the loan terms, interest payments are sometimes included in allowable business expenses. For simplicity and conservatism, they are not here. Iincome up to £50000 is taxed at 19\%, and annual taxable income above £250000 is taxed at 25\%. The tax rate increases linearly with annual income between £50000 and £250000 from 19\% to 25\%. Hence tax payed \(T\) on annual income \(I\) is given by: +\begin{equation} + T= + \begin{cases} + 0.19I & I\le 50000\\ + 0.25I-(250000-I)\times \frac 3{200} \quad \quad & 50000\le I \le 250000 \\ + 0.25I & I\ge 250000 + \end{cases} +\end{equation} + +NB: The marginal rate applies to total income, not just income between £50000 and £250000, like personal income tax would. + +UK corporation tax law also allows losses in one year to be carried over to the next. For example, if a business makes a loss of £20000 in Year \(n\), and makes a profit of £60000 in Year \(n+1\), its taxable income in Year \(n+1\) is £40000. Losses can be carried over indefinitely. + +\subsubsection{Net Present Value} +A running total cash flow is tabulated. This is discounted according to the year in which the money is made. The Net Present Value (NPV) at a given year is given by the discounted cumulative cash flow up to that year added to the discounted terminal value. In future years, once cash flow (including tax) stabilises, NPV remains constant. "NPV" refers to a this stabilised value. + +\paragraph{Assumptions} \(\) \newline +For simplicity, it is assumed that a constant WACC discount rate is applied over time. This assumes: +\begin{itemize} + \item The debt held with the bank is constant, and the business is only paying the interest on the loan; in reality, the loan would likely be paid off after \(N\) years,according to equation \ref{equ:amortisation} + \item Both the Equity-Only Discount Rate and the Loan Interest Rates are constant; in reality, both would decrease over time as the business becomes more established to reflect a decreased risk. + \item Only the capital investments in Year 0 need to be financed. As can be seen in Table \ref{tab:IE}, Year 1 is projected to run at a small loss, which must also be financed. This is neglected for simplicity, and is insignificant compared with other assumptions made in this model. +\end{itemize} + +\subsection{Full Model} +According to the assumptions and models, the full financial model is summarised in table \ref{tab:model} + + +\begin{table}[h] +\centering +\begin{tabular}{|c| c c c c c c c c c|} +\hline +WACC & 17.7\% &&&&&&&&\\ +\hline \hline +Year & 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & \dots \\ +\hline +Warehouse Hire & 25 & 25 & 25 & 25 & 25 & 25 & 25 & 25 & \dots \\ +Electricity & 20 & 20 & 20 & 20 & 20 & 20 & 20 & 20 & \dots \\ +Decorating \& Maintenance & 30 & 10 & 10 & 10 & 10 & 10 & 10 & 10 & \dots \\ +Employees & 100 & 100 & 150 & 200 & 200 & 200 & 200 & 200 & \dots \\ +Advertising & 30 & 30 & 30 & 30 & 30 & 30 & 30 & 30 &\dots \\ +Hardware & 10 & 20 & 30 & 40 & 40 & 40 & 40 & 40 & \dots \\ +Revenue (Game Fees) & 0 & 200 & 300 & 400 & 400 & 400 & 400 & 400 & \dots \\ + +\hline \hline +Cumulative Losses & 215 & 220 & 185 & 110 & 35 & 0 & 0 & 0 & \dots \\ +Taxable Income & 0 & 0 & 0 & 0 & 0 & 40 & 75 & 75 & \dots \\ +Tax & 0 & 0 & 0 & 0 & 0 & 7.6 & 16.125 & 16.125 & \dots \\ +\hline \hline +Cash Flow (CF) &-215&-5&35&75&75&67.4&58.875&58875&\dots \\ +Cumulative CF (CCF) &-215&-220&-185&-110&-35&32.4&91.275&150.15&\dots \\ +\hline \hline +Discount & 1 & 0.850 & 0.722 & 0.614 & 0.522 & 0.443 & 0.377 & 0.320 & \dots \\ + +\hline \hline +Discounted CCF& -215&-219&-194&-148&-109&-79.0&-56.8&-37.9& \dots \\ +\hline +\end{tabular} +\caption{Full Financial Model Summary - all values in £k} +\label{tab:model} +\end{table} + +The Discounted Cumulative Cash Flow turns positive in Year 10 (payback; section \ref{DPS}). It is found that the Net Present Value (NPV) is £68669. Hence, the business is viable under these assumptions. + +\subsection{Analyses} +Using Apps Script, Google Sheets' equivalent of Excel macros, the following analyses were performed. In general, one variable was changed and another was observed, while all others were held constant according to the assumptions stated above. +\subsubsection{NPV Profile} +\label{NPVProfile} +A common measure of a business' viability is the effect of changing the discount rate on NPV, and analysis of the NPV-Discount Rate graph that this analysis produces (shown in Figure \ref{fig:NPV-Profile}). + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/NPV Profile.png} + \caption{NPV Profile} + \label{fig:NPV-Profile} +\end{figure} + +The discount rate at which NPV is zero (Internal Rate of Return, IRR) is 22.3\%. Using WACC calculations, a discount rate of 17.7\% was projected. This shows that the business is viable even under slightly higher discount rates than predicted. Furthermore the NPV profile shows that a small reduction in discount rate produces a large increase in NPV. This is encouraging, since discount rate is likely to decrease significantly as the business becomes more established. + +\subsubsection{Discounted Payback Sensitivity} +\label{DPS} +It is also useful to investigate how payback (the time at which the cumulative discounted cash flow becomes positive) changes with discount rate (shown in Figure \ref{fig:dis-pay-sen}). + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Discounted Payback Sensitivity.png} + \caption{NPV Profile} + \label{fig:dis-pay-sen} +\end{figure} + +Payback increases with Discount Rate. However, Payback only decreses a little over the realistic values of Discount Rate, only increasing from 9 to 13 years as Discount Rate increases from 15\% to 20\%. This suggests slight errors in numerical assumptions does not hugely affect the projected business performance. + +\subsubsection{Pricing} +\label{PriceAnal} +\paragraph{Price and Demand}\(\) \newline + +To determine the optimum price per game, the relationship between utility (games per year) and the price per game is modelled. The increase of utility shown in Table \ref{tab:utilityandemployees} is assumed to be constant. + + +A linear demand-price curve was assumed: demand (maximum number of games per year, \(Q_d\)) varies with price per game, \(P\), according to the equation: +\begin{equation} + Q_d=a-bP +\end{equation} +for constants \(a, b\). +As above, it was assumed that, a price of £200 per game corresponds to a maximum of 2000 games per year, giving: +\begin{equation} + Q_d=2000+b(200-P) +\end{equation} + +The demand-price elasticity \(\varepsilon\) is defined as: +\begin{equation} + \varepsilon=\frac{dQ_d}{dP}\cdot \frac PQ +\end{equation} + +% It can be shown that the above equations combine to give: +% \begin{equation} +% Q_d=2000-\varepsilon\frac QP(200-P) +% \end{equation} +In a linear model, \(\varepsilon\) is varies. Instead, a reference value of elasticity \(\varepsilon'\) will be taken at \((Q_d=2000, P=200\)), and the gradient held constant. Hence, the demand-price curve reduces to: +\begin{equation} + Q_d=2000-10\varepsilon'(200-P) +\end{equation} +However, this model implies no limit on utility. In reality, only one game can be played at a time. This upper limit is modelled as 3000 games/year (corresponding to around 59 hour-long games per week, excluding public holidays), given a final demand-price curve of: + +\begin{equation} + Q_d=\min\{2000-10\varepsilon'(200-P), 3000\} +\end{equation} +A reference value of elasticity \(\varepsilon=-1.1\) is chosen, since it represents a moderate price-sensitivity.\newline + +The effect of a variation in reference elasticity is analysed in Section \ref{ElasticityAnal} + +\paragraph{Finding optimal price} \(\) \newline +The variation of NPV with game price was investigated. The results are shown in Figure \ref{fig:pri-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Sensitivity_Analysis_Price_Elastic_Utility.png} + \caption{Price Sensitivity} + \label{fig:pri-sen} +\end{figure} + +It is observed that, given \(\varepsilon'=-1.1\), £200 per game is the price that maximises NPV. + + +The linear left-most section of the graph corresponds to a constant utility of 3000 games per year. In this section, NPV is hugely negative. Therefore, attempting to setting the game price such that the facility is running at capacity is a very poor decision. + +NPV is only positive for prices between £160 and £240 per game (to the nearest £10). Given how narrow this range of is, this demonstrates the importance of this analysis. + +\paragraph{Utility Sensitivity}\(\) \newline +\label{UtilityAnalFixedPrice} +It was assumed that the maximum number of games per year would be 2000 when the price was £200 per game. The effect of a small error is this estimate was investigated. Price per game was held constant, maximum games per year was varied and the resulting NPV was tabulated. The results are shown in Figure \ref{fig:uti-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Sensitivity_Analysis_Utility_Fixed_Price.png} + \caption{Utility Sensitivity} + \label{fig:uti-sen} +\end{figure} + +NPV is only positive for above 1900 games per year (rounded to the nearest 50) This is very close to the estimated 2000 games per year: a high utility is critical, justifying the high advertising budget. + +\paragraph{How Optimal Price varies with elasticity} \(\) \newline +\label{ElasticityAnal} +This process was repeated for reference elasticity \(\varepsilon'\) between -0.5 (very price-insensitive) and -3 (very price-sensitive). Since the effect on NPV of changing two variables (reference elasticity and price per game) is being measured, it would be possible to create a 3D surface to demonstrate this. Since reference elasticity is only being varied in order to assess the sensitivity of the model to errors in numerical assumptions (it is not something that can be changed in order to maximise NPV), it is only useful to tabulate the optimal price per game (price that maximises NPV) and plot this against reference elasticity. This is shown in Figure \ref{fig:opt-cos-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Optimal_Cost_per_Game_vs_Elasticity.png} + \caption{Optimal Cost per game against Reference Elasticity} + \label{fig:opt-cos-sen} +\end{figure} + +Elasticity is likely to be between -0.8 and -1.5. It is observed that, over this range of reference elasticity, the optimal cost is almost constant, and very close to £200 per game. + +\subsubsection{Limitations} + +In general, one or more variables were changed, and another was observed, while all others were held constant according to the assumptions stated above. It is likely that, by completing a sweep, changing all values at once to create a multi-dimensional surface model of all financial values, optima of NPV will be found that were missed in the above analysis, either by brute force or multi-dimensional gradient descent. + +\newpage -\printbibliography{biblio} % Appendix % Essential content that interrupts the flow of the document can be placed here, e.g. technical drawings, detailed lists of equations used, etc. -\newpage \addcontentsline{toc}{section}{Appendix} + + + \section*{Appendix} +\fancyhead[C]{Group} + +\paragraph{Heating cost assumptions}\(\) \newline +\label{assumptions} +It is also assumed that, when players enters the warehouse every hour, 50\% of the air is evacuated and replaced, and no air is evacuated when the game is being played. The first assumption is likely a significant overestimate, and the second a modest underestimate, resulting in a conservative estimate.\newline + +It is further assumed that the height of the warehouse is 6 metres, and that the warehouse is square. +\begin{equation} + \dot Q=U_wA_w\Delta T+U_rA_r\Delta T+U_fA_f\Delta T +\text{ACH}\cdot \frac{\rho c_p V\Delta T}{3600} +\end{equation} +\begin{equation} + \text{Floor Area}=\text{Roof Area}=6800 \text{ft}^2=632m^2 +\end{equation} +Assume floor plan to be square, and walls to be \(6m\) tall: +\begin{equation} + \text{Wall Length}=\sqrt{632m^2}=25.1m +\end{equation} +\begin{equation} + \text{Total Wall Area}=4*25.1m*6m=603m^2 +\end{equation} +\begin{equation} + \text{Total Volume}=632m^2\times6m=3792m^3 +\end{equation} +Assuming the average daytime temperature in London is \(10 ^\circ C\), and the desired temperature is \(20^\circ C\), \(\Delta T=10^\circ C\): +\begin{equation} + \dot Q=U_wA_w\Delta T+U_rA_r\Delta T+U_fA_f\Delta T +\text{ACH}\cdot \frac{\rho c_p V\Delta T}{3600} +\end{equation} +\begin{equation} =0.78\times603\times10+0.48\times632\times10+0.54\times632\times10+0.5\cdot \frac{1.225\times1005\times3792\times10}{3600} +\end{equation} +\begin{equation} + \label{app:heating-calcs} + =17.6\text{kW} +\end{equation} +\newpage + +\begin{figure}[htbp] + \centering + \includegraphics[width=1\linewidth]{figs/High-Level/Flow2.png} + \caption{Flow Chart Describing High-Level Mode Changes} + \label{fig:FlowBig} +\end{figure} +\label{risk-assessment} +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{figs/risk-assessment} + \caption{Quantitative Risk Assessment} + \label{fig:risk-assessment} +\end{figure} + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/0_Login_Screen.jpg} + \caption{Login Screen} + \label{fig:0_Login_Screen} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/1_Profile_Screen.jpg} + \caption{Profile Screen} + \label{fig:1_Profile_Screen} + \end{subfigure} + \caption{Login and Profile Screens} + \label{fig:log-pro-screen} +\end{figure} + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/3_1_Achievements_Lifetime.jpg} + \caption{Achievements Screen - Lifetime Achievements} + \label{fig:ach-lif} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/3_2_Achievements_Monthly.jpg} + \caption{Achievements Screen - Monthly Challenges} + \label{fig:ach-mon} + \end{subfigure} + \caption{Achievements Screen} + \label{fig:ach-screen} +\end{figure} +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/4_1_Community_Friends.jpg} + \caption{Community Screen - Friends Tab} + \label{fig:com-friends} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/4_2_1_Community_Requests_Receiving.jpg} + \caption{Community Screen - receiving friend request} + \label{fig:com-rec} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.25\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/4_2_2_Community_Requests_Making.jpg} + \caption{Community Screen - sending friend request} + \label{fig:com-sen} + \end{subfigure} + \caption{Community Screen} + \label{fig:com-screen} +\end{figure} +\begin{figure}[H] + \centering + \includegraphics[width=0.25\linewidth]{figs/App_Screenshots/5_Play_In_Person.jpg} + \caption{Play in Person Screen} + \label{fig:5_PiP_Screen} +\end{figure} + +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{figs/Database_Screenshot.png} + \caption{Screenshot of SQL Database} + \label{fig:Database} +\end{figure} +\newpage +\printbibliography{biblio} -\end{document} +\end{document} \ No newline at end of file