diff --git a/Blender Drone.png b/Blender Drone.png new file mode 100644 index 0000000..b1fc5da Binary files /dev/null and b/Blender Drone.png differ diff --git a/GroupC-Supporting-Statement.pdf b/GroupC-Supporting-Statement.pdf new file mode 100644 index 0000000..642a05f Binary files /dev/null and b/GroupC-Supporting-Statement.pdf differ diff --git a/Hardware/Blade Guard Simulation.png b/Hardware/Blade Guard Simulation.png new file mode 100644 index 0000000..df6cf3f Binary files /dev/null and b/Hardware/Blade Guard Simulation.png differ diff --git a/Hardware/Blade.png b/Hardware/Blade.png new file mode 100644 index 0000000..b91aa15 Binary files /dev/null and b/Hardware/Blade.png differ diff --git a/Hardware/Blueprint for Gimbal (without motor and servos).png b/Hardware/Blueprint for Gimbal (without motor and servos).png new file mode 100644 index 0000000..2110563 Binary files /dev/null and b/Hardware/Blueprint for Gimbal (without motor and servos).png differ diff --git a/Hardware/Complete Assembly.png b/Hardware/Complete Assembly.png new file mode 100644 index 0000000..f1bf650 Binary files /dev/null and b/Hardware/Complete Assembly.png differ diff --git a/Hardware/Explaining 3 Part in Assembly.png b/Hardware/Explaining 3 Part in Assembly.png new file mode 100644 index 0000000..a4ca9fd Binary files /dev/null and b/Hardware/Explaining 3 Part in Assembly.png differ diff --git a/Hardware/Exploded Gimbal View.png b/Hardware/Exploded Gimbal View.png new file mode 100644 index 0000000..39364d1 Binary files /dev/null and b/Hardware/Exploded Gimbal View.png differ diff --git a/Hardware/Final Model (un assembled).png b/Hardware/Final Model (un assembled).png new file mode 100644 index 0000000..2a0d031 Binary files /dev/null and b/Hardware/Final Model (un assembled).png differ diff --git a/Hardware/HolyBro.png b/Hardware/HolyBro.png new file mode 100644 index 0000000..c651d5d Binary files /dev/null and b/Hardware/HolyBro.png differ diff --git a/Hardware/Main Body.png b/Hardware/Main Body.png new file mode 100644 index 0000000..50cd733 Binary files /dev/null and b/Hardware/Main Body.png differ diff --git a/Hardware/Model 1.png b/Hardware/Model 1.png new file mode 100644 index 0000000..ff5061c Binary files /dev/null and b/Hardware/Model 1.png differ diff --git a/Hardware/Model 2.png b/Hardware/Model 2.png new file mode 100644 index 0000000..febe2a0 Binary files /dev/null and b/Hardware/Model 2.png differ diff --git a/Hardware/Model 3.png b/Hardware/Model 3.png new file mode 100644 index 0000000..6b0e927 Binary files /dev/null and b/Hardware/Model 3.png differ diff --git a/Hardware/Oak D Lite Camera.jpg b/Hardware/Oak D Lite Camera.jpg new file mode 100644 index 0000000..866cde0 Binary files /dev/null and b/Hardware/Oak D Lite Camera.jpg differ diff --git a/Hardware/PDB 300A Webiste CAD.png b/Hardware/PDB 300A Webiste CAD.png new file mode 100644 index 0000000..82c397e Binary files /dev/null and b/Hardware/PDB 300A Webiste CAD.png differ diff --git a/Hardware/Player Hardware.png b/Hardware/Player Hardware.png new file mode 100644 index 0000000..f64c430 Binary files /dev/null and b/Hardware/Player Hardware.png differ diff --git a/Hardware/Raspberry Pi 4 Model B.png b/Hardware/Raspberry Pi 4 Model B.png new file mode 100644 index 0000000..84de425 Binary files /dev/null and b/Hardware/Raspberry Pi 4 Model B.png differ diff --git a/Hardware/Rotor Arm Simulation Test Image.png b/Hardware/Rotor Arm Simulation Test Image.png new file mode 100644 index 0000000..88857ba Binary files /dev/null and b/Hardware/Rotor Arm Simulation Test Image.png differ diff --git a/Hardware/Sparkfun IMU.png b/Hardware/Sparkfun IMU.png new file mode 100644 index 0000000..f6b0835 Binary files /dev/null and b/Hardware/Sparkfun IMU.png differ diff --git a/Hardware/Step Down Voltage Regulator.jpg b/Hardware/Step Down Voltage Regulator.jpg new file mode 100644 index 0000000..c309dbc Binary files /dev/null and b/Hardware/Step Down Voltage Regulator.jpg differ diff --git a/Hardware/VL53L1X.png b/Hardware/VL53L1X.png new file mode 100644 index 0000000..4359656 Binary files /dev/null and b/Hardware/VL53L1X.png differ diff --git a/Hardware/VL53L5CX.png b/Hardware/VL53L5CX.png new file mode 100644 index 0000000..cc4fcaa Binary files /dev/null and b/Hardware/VL53L5CX.png differ diff --git a/Imported Unity Drone.png b/Imported Unity Drone.png new file mode 100644 index 0000000..c6afa9c Binary files /dev/null and b/Imported Unity Drone.png differ diff --git a/Power System Map.png b/Power System Map.png new file mode 100644 index 0000000..c3a6d3d Binary files /dev/null and b/Power System Map.png differ diff --git a/biblio.bib b/biblio.bib index 9271a6e..b3b8f78 100644 --- a/biblio.bib +++ b/biblio.bib @@ -1,6 +1,550 @@ +@misc{deloitte2026leisure_report, + author = {Fenech, Céline and Walton, Bryn}, + title = {{Leisure sector quarterly update: A look back at Q4 2025}}, + howpublished = {\url{https://www.deloitte.com/uk/en/Industries/consumer/research/consumer-tracker/leisure-sector.html}}, + year = {2026}, + month = {February}, + note = {Deloitte LLP [Accessed 14-05-2026]} +} +@misc{arrowsmith2026leisure, + author = {Arrowsmith, Sam}, + title = {{Spotlight: UK Leisure 2026}}, + howpublished = {\url{https://www.savills.co.uk/research_articles/229130/382466-0}}, + year = {2026}, + month = {March}, + note = {Savills plc. [Accessed 14-05-2026]} +} +@article{underactuated, + author = {Emran, Bara and Najjaran, Homayoun}, + year = {2018}, + month = {10}, + pages = {}, + title = {A review of quadrotor: An underactuated mechanical system}, + volume = {46}, + journal = {Annual Reviews in Control}, + doi = {10.1016/j.arcontrol.2018.10.009} +} +@misc{slamtec_rplidar_a1, + author = {{Slamtec}}, + title = {{RPLIDAR A1}}, + howpublished = {\url{https://www.slamtec.com/en/lidar/a1}}, + year = {2026}, + note = {[Accessed 18-05-2026]} +} +@misc{orbbec_astra_mini_pro, + author = {{Orbbec}}, + title = {{Astra Mini Pro Structured Light Camera}}, + howpublished = {\url{https://www.orbbec.com/products/structured-light-camera/astra-mini-pro/}}, + year = {2026}, + note = {[Accessed 18-05-2026]} +} +@misc{raspberrypi_ai_camera, + author = {{Raspberry Pi}}, + title = {{Raspberry Pi AI Camera}}, + howpublished = {\url{https://www.raspberrypi.com/products/ai-camera/}}, + year = {2026}, + note = {[Accessed 18-05-2026]} +} +@misc{dji2026transmission, + author = {{DJI}}, + title = {{DJI} Transmission - Specifications}, + howpublished = {\url{https://www.dji.com/uk/transmission/specs}}, + year = {2026}, + note = {[Accessed 19-05-2026]} +} +@misc{dji2026mini5pro, + author = {{DJI}}, + title = {{DJI} Mini 5 Pro - Specifications}, + howpublished = {\url{https://www.dji.com/uk/mini-5-pro/specs}}, + year = {2026}, + note = {[Accessed 19-05-2026]} +} +@misc{parkcameras2026mini5pro, + author = {{Park Cameras}}, + title = {{DJI} Mini 5 Pro Drone}, + howpublished = {\url{https://www.parkcameras.com/shop/dji-mini-5-pro-drone_9703416a}}, + year = {2026}, + note = {[Accessed 19-05-2026]} +} +@misc{ultralytics_yolov8, + author = {Jocher, Glenn and Chaurasia, Ayush and Qiu, Jing}, + title = {{Ultralytics YOLOv8}}, + howpublished = {\url{https://docs.ultralytics.com/models/yolov8}}, + year = {2023}, + note = {[Accessed 19-05-2026]} +} +@inproceedings{Lin2014MicrosoftCC, + title={Microsoft COCO: Common Objects in Context}, + author={Lin, Tsung-Yi and Maire, Michael and Belongie, Serge J. and Hays, James and Perona, Pietro and Ramanan, Deva and Doll{\'a}r, Piotr and Zitnick, C. Lawrence}, + booktitle={European Conference on Computer Vision}, + year={2014}, + url={https://api.semanticscholar.org/CorpusID:14113767} +} + +@article{Zhu2020DetectionAT, + title={Detection and Tracking Meet Drones Challenge}, + author={Zhu, Pengfei and Wen, Longyin and Du, Dawei and Bian, Xiao and Fan, Heng and Hu, Qinghua and Ling, Haibin}, + journal={IEEE Transactions on Pattern Analysis and Machine Intelligence}, + year={2021}, + volume={44}, + number={11}, + pages={7380-7399}, + doi={10.1109/TPAMI.2021.3119563} +} +@misc{unity_sentis, + author = {{Unity Technologies}}, + title = {{Unity Sentis Manual}}, + howpublished = {\url{https://docs.unity3d.com/Packages/com.unity.ai.inference@2.6/manual/index.html}}, + year = {2024}, + note = {[Accessed 19-05-2026]} +} +@misc{reid_kalman, + author = {Reid, Ian}, + title = {Estimation {II}: The {Kalman} Filter}, + howpublished = {\url{https://www.robots.ox.ac.uk/~ian/Teaching/Estimation/LectureNotes2.pdf}}, + year = {2001}, + note = {Lecture Notes, University of Oxford. [Accessed 19-05-2026]} +} +@inbook{barshalom2001kinematic, + author = {Bar-Shalom, Yaakov and Li, X. Rong and Kirubarajan, Thiagalingam}, + publisher = {John Wiley \& Sons, Ltd}, + isbn = {9780471221272}, + title = {Estimation for Kinematic Models}, + booktitle = {Estimation with Applications to Tracking and Navigation}, + chapter = {6}, + pages = {267--299}, + doi = {10.1002/0471221279.ch6}, + year = {2001} +} @article{achiam2023gpt, title={Gpt-4 technical report}, author={Achiam, Josh and Adler, Steven and Agarwal, Sandhini and Ahmad, Lama and Akkaya, Ilge and Aleman, Florencia Leoni and Almeida, Diogo and Altenschmidt, Janko and Altman, Sam and Anadkat, Shyamal and others}, journal={arXiv preprint arXiv:2303.08774}, year={2023} } +@misc{rightmoveCheckThis, + author = {{R}ightmove}, + title = {{W}arehouse to lease in {A}lbion {P}arade}, + howpublished = {\url{https://www.rightmove.co.uk/properties/148534730\#/?channel=COM\_LET}}, + year = {2026}, + note = {[Accessed 27-04-2026]}, + journal = {N/A} +} +@misc{outdoorlaserLasergamingEXCLUSIVE, + author = {{L}asergaming {O}xford}, + title = {{L}asergaming 2hr {E}{X}{C}{L}{U}{S}{I}{V}{E} {G}roup {S}ession}, + 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 = {{65Drones}}, + title = {{FVT LittleBee-Spring DShot BLHeli\_S 40A ESC}}, + howpublished = {\url{https://www.65drones.com/products/fvt-littlebee-spring-30ax4-dshot-blheli_s-bb2-30a-2-4s-4-in-1-esc-with-5v-12v-bec-support-d-shot}}, + year = {2026}, + note = {[Accessed 11-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 = {{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 = {{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 = {{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 = {{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{mg90s_servo, + author = {{Sussex Model Centre}}, + title = {{MG90S Micro with Metal Output Gear Servo}}, + howpublished = {\url{https://sussex-model-centre.co.uk/products/mg90s-micro-with-metal-output-gear-servo}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{gbm2208_gimbal_motor, + author = {{Unmanned Tech}}, + title = {{GBM2208-80 Brushless Gimbal Motor}}, + howpublished = {\url{https://www.unmannedtechshop.co.uk/products/gbm2208-80-brushless-gimbal-motor-gopro-size-camera}}, + year = {2026}, + note = {[Accessed 11-05-2026]}, +} + +@misc{oakd_lite_specs, + author = {{Luxonis}}, + title = {{OAK-D Lite}}, + howpublished = {\url{https://shop.luxonis.com/products/oak-d-lite-1}}, + year = {2026}, + 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} +} + +@misc{IsaacLabQuadcopter, + author = {}, + title = {Isaac Lab Quadcopter Environment}, + howpublished = {\url{https://github.com/isaac-sim/IsaacLab/blob/main/source/isaaclab_tasks/isaaclab_tasks/direct/quadcopter/quadcopter_env.py}}, + year = {c2022-2026}, + note = {[Accessed 12-05-2026]}, + journal = {N/A} +} + +@misc{liu2018viconmavlinksoftwaretoolindoor, + title={Viconmavlink: A software tool for indoor positioning using a motion capture system}, + author={Bo Liu and Normand Paquin}, + year={2018}, + eprint={1811.11878}, + archivePrefix={arXiv}, + primaryClass={cs.RO}, + url={https://arxiv.org/abs/1811.11878}, +} + +@misc{Prime13Optitrack, + author = {}, + title = {Primeˣ 13 - Pricing | Optitrack.com}, + howpublished = {\url{https://optitrack.com/cameras/primex-13/buy}}, + year = {c2026}, + note = {[Accessed 13-05-2026]}, + journal = {N/A} +} + +@article{aprilTagStateEstimation, +author = {Pandey, Shruti and Verma, Chirag and Trivedi, Eshan and Mehendale, Ninad}, +year = {2024}, +month = {01}, +pages = {}, +title = {AprilTag-Based Self-Localization for Drones in Indoor Environments}, +journal = {SSRN Electronic Journal}, +doi = {10.2139/ssrn.4815151} +} + +@article{RBPF, +title = {Fast and accurate SLAM with Rao–Blackwellized particle filters}, +journal = {Robotics and Autonomous Systems}, +volume = {55}, +number = {1}, +pages = {30-38}, +year = {2007}, +note = {Simultaneous Localisation and Map Building}, +issn = {0921-8890}, +doi = {https://doi.org/10.1016/j.robot.2006.06.007}, +url = {https://www.sciencedirect.com/science/article/pii/S092188900600145X}, +author = {Giorgio Grisetti and Gian Diego Tipaldi and Cyrill Stachniss and Wolfram Burgard and Daniele Nardi}, +keywords = {SLAM, Rao–Blackwellized particle filter, Grid map, Informed proposal}, +abstract = {Rao–Blackwellized particle filters have become a popular tool to solve the simultaneous localization and mapping problem. This technique applies a particle filter in which each particle carries an individual map of the environment. Accordingly, a key issue is to reduce the number of particles and/or to make use of compact map representations. This paper presents an approximative but highly efficient approach to mapping with Rao–Blackwellized particle filters. Moreover, it provides a compact map model. A key advantage is that the individual particles can share large parts of the model of the environment. Furthermore, they are able to reuse an already computed proposal distribution. Both techniques substantially speed up the overall filtering process and reduce the memory requirements. Experimental results obtained with mobile robots in large-scale indoor environments and based on published standard datasets illustrate the advantages of our methods over previous mapping approaches using Rao–Blackwellized particle filters.} +} + +@book{HLT, + author = {A.M. Howatson and P.G.Lund and J.D.Todd}, + title = {Engineering Data \& Tables 4th Edition}, + publisher = {Department of Engineering Science University of Oxford}, + year = {2023 (First published 2009)}, + address = {Oxford} +} + +@ARTICLE{4608934, + author={Mahony, Robert and Hamel, Tarek and Pflimlin, Jean-Michel}, + journal={IEEE Transactions on Automatic Control}, + title={Nonlinear Complementary Filters on the Special Orthogonal Group}, + year={2008}, + volume={53}, + number={5}, + pages={1203-1218}, + keywords={Passive filters;Costs;Measurement units;Noise level;Time varying systems;Additive noise;Filtering;Kinematics;Position measurement;Angular velocity;Attitude estimates;complementary filter;nonlinear observer;special orthogonal group}, + doi={10.1109/TAC.2008.923738} + } + +@misc{EquityDiscountRate, + author = {David Skok}, + title = {{H}ow to calculate the {D}iscount {R}ate to use in a {D}iscounted {C}ash {F}low ({D}{C}{F}) {A}nalysis - {F}or {E}ntrepreneurs --- forentrepreneurs.com}, + howpublished = {\url{https://www.forentrepreneurs.com/discount-rate-for-dcf/}}, + year = {}, + note = {[Accessed 17-05-2026]}, +} + +@misc{CostOfDebt, + author = {}, + title = {{I}nterest {R}ates and {V}enture {D}ebt: {W}hat to {K}now - {P}hoenix {S}trategy {G}roup --- phoenixstrategy.group}, + howpublished = {\url{https://www.phoenixstrategy.group/blog/interest-rates-venture-debt-what-to-know}}, + year = {}, + note = {[Accessed 17-05-2026]}, +} +@misc{theguardianAdultsGreat, + author = {Mark Sweney}, + title = {{A}dults in {G}reat {B}ritain --- theguardian.com}, + howpublished = {\url{https://www.theguardian.com/media/2025/jun/25/adults-great-britain-time-mobiles-watching-tv-screen-ipa-survey}}, + year = {2025}, + note = {[Accessed 17-05-2026]}, +} +@misc{LaserTagHistory, + author = {}, + title = {{H}istory of {L}aser{T}ag}, + howpublished = {\url{https://web.archive.org/web/20071011163339/http://lasertag.org/general/history.html}}, + year = {}, + note = {[Accessed 17-05-2026]}, +} +@misc{trutneeLaserTag, + author = {}, + title = {{L}aser {T}ag: {F}acts and {R}ecords --- trutnee.com}, + howpublished = {\url{https://www.trutnee.com/facts}}, + year = {}, + note = {[Accessed 17-05-2026]}, +} + +@misc{quaternionDerivative, + title={Quaternion kinematics for the error-state Kalman filter}, + author={Joan Solà}, + year={2017}, + eprint={1711.02508}, + archivePrefix={arXiv}, + primaryClass={cs.RO}, + url={https://arxiv.org/abs/1711.02508}, +} + +@misc{CrazyflieDatasheet, + author = {}, + title = {Datasheet Crazyflie 2.1 brushless - Rev 3 --- bitcraze.io}, + howpublished = {\url{https://www.bitcraze.io/documentation/hardware/crazyflie_2_1_brushless/crazyflie_2_1_brushless-datasheet.pdf}}, + year = {}, + note = {[Accessed 20-05-2026]}, +} \ No newline at end of file diff --git a/figs/1_RGB.png b/figs/1_RGB.png new file mode 100644 index 0000000..8dd9173 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..1f5ad33 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..0dba2bf Binary files /dev/null and b/figs/CrouchDeformation_Plot.pdf differ diff --git a/figs/CrouchDeformation_Plot.png b/figs/CrouchDeformation_Plot.png new file mode 100644 index 0000000..2adb1db Binary files /dev/null and b/figs/CrouchDeformation_Plot.png 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/DepthEstimationTests.png b/figs/DepthEstimationTests.png new file mode 100644 index 0000000..3eb7631 Binary files /dev/null and b/figs/DepthEstimationTests.png differ diff --git a/figs/Finance/Cropped/Discounted Payback Sensitivity Cropped.png b/figs/Finance/Cropped/Discounted Payback Sensitivity Cropped.png new file mode 100644 index 0000000..bc8f8ab Binary files /dev/null and b/figs/Finance/Cropped/Discounted Payback Sensitivity Cropped.png differ diff --git a/figs/Finance/Cropped/NPV Profile Cropped.png b/figs/Finance/Cropped/NPV Profile Cropped.png new file mode 100644 index 0000000..6f3d9ac Binary files /dev/null and b/figs/Finance/Cropped/NPV Profile Cropped.png differ diff --git a/figs/Finance/Cropped/Optimal_Cost_per_Game_vs_Ref_Elasticity_Cropped.png b/figs/Finance/Cropped/Optimal_Cost_per_Game_vs_Ref_Elasticity_Cropped.png new file mode 100644 index 0000000..2ee24de Binary files /dev/null and b/figs/Finance/Cropped/Optimal_Cost_per_Game_vs_Ref_Elasticity_Cropped.png differ diff --git a/figs/Finance/Cropped/Sensitivity_Analysis_Price_Elastic_Utility_Cropped.png b/figs/Finance/Cropped/Sensitivity_Analysis_Price_Elastic_Utility_Cropped.png new file mode 100644 index 0000000..f94b488 Binary files /dev/null and b/figs/Finance/Cropped/Sensitivity_Analysis_Price_Elastic_Utility_Cropped.png differ diff --git a/figs/Finance/Cropped/Sensitivity_Analysis_Price_Fixed_Utility_Cropped.png b/figs/Finance/Cropped/Sensitivity_Analysis_Price_Fixed_Utility_Cropped.png new file mode 100644 index 0000000..4316d06 Binary files /dev/null and b/figs/Finance/Cropped/Sensitivity_Analysis_Price_Fixed_Utility_Cropped.png differ diff --git a/figs/Finance/Cropped/Sensitivity_Analysis_Utility_Fixed_Price_Cropped.png b/figs/Finance/Cropped/Sensitivity_Analysis_Utility_Fixed_Price_Cropped.png new file mode 100644 index 0000000..78ee6c9 Binary files /dev/null and b/figs/Finance/Cropped/Sensitivity_Analysis_Utility_Fixed_Price_Cropped.png 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 Editted.png b/figs/Finance/NPV Profile Editted.png new file mode 100644 index 0000000..06fb699 Binary files /dev/null and b/figs/Finance/NPV Profile Editted.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/Flow-Chard-Even-Bigger-Text.png b/figs/High-Level/Flow-Chard-Even-Bigger-Text.png new file mode 100644 index 0000000..071683d Binary files /dev/null and b/figs/High-Level/Flow-Chard-Even-Bigger-Text.png differ diff --git a/figs/High-Level/Flow-Chart-Complete-Bigger-Text.png b/figs/High-Level/Flow-Chart-Complete-Bigger-Text.png new file mode 100644 index 0000000..89a5cc5 Binary files /dev/null and b/figs/High-Level/Flow-Chart-Complete-Bigger-Text.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/FlowChart0.png b/figs/High-Level/FlowChart0.png new file mode 100644 index 0000000..c079f55 Binary files /dev/null and b/figs/High-Level/FlowChart0.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/SearchMode17.png b/figs/High-Level/SearchMode17.png new file mode 100644 index 0000000..ae9ce5c Binary files /dev/null and b/figs/High-Level/SearchMode17.png differ diff --git a/figs/High-Level/SearchMode18.png b/figs/High-Level/SearchMode18.png new file mode 100644 index 0000000..2976b79 Binary files /dev/null and b/figs/High-Level/SearchMode18.png differ diff --git a/figs/High-Level/SearchMode19.png b/figs/High-Level/SearchMode19.png new file mode 100644 index 0000000..73cb5f1 Binary files /dev/null and b/figs/High-Level/SearchMode19.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/ShootMode19.png b/figs/High-Level/ShootMode19.png new file mode 100644 index 0000000..c08cef8 Binary files /dev/null and b/figs/High-Level/ShootMode19.png differ diff --git a/figs/High-Level/StateFlow2.png b/figs/High-Level/StateFlow2.png new file mode 100644 index 0000000..c2fe39f Binary files /dev/null and b/figs/High-Level/StateFlow2.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/High-Level/TrackMode19.png b/figs/High-Level/TrackMode19.png new file mode 100644 index 0000000..87d8cc8 Binary files /dev/null and b/figs/High-Level/TrackMode19.png differ diff --git a/figs/House of Quality.png b/figs/House of Quality.png new file mode 100644 index 0000000..c013ab9 Binary files /dev/null and b/figs/House of Quality.png differ diff --git a/figs/IsaacLabMap.png b/figs/IsaacLabMap.png new file mode 100644 index 0000000..7167262 Binary files /dev/null and b/figs/IsaacLabMap.png differ diff --git a/figs/Last Known Position.png b/figs/Last Known Position.png new file mode 100644 index 0000000..c570b90 Binary files /dev/null and b/figs/Last Known Position.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/LinearTranslation_Plot.png b/figs/LinearTranslation_Plot.png new file mode 100644 index 0000000..e46903c Binary files /dev/null and b/figs/LinearTranslation_Plot.png 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/Occlusion_Test.png b/figs/Occlusion_Test.png new file mode 100644 index 0000000..ccb2b40 Binary files /dev/null and b/figs/Occlusion_Test.png differ diff --git a/figs/Player State Estimation.png b/figs/Player State Estimation.png new file mode 100644 index 0000000..45e5cd1 Binary files /dev/null and b/figs/Player State Estimation.png differ diff --git a/figs/RL_policy_demo.png b/figs/RL_policy_demo.png new file mode 100644 index 0000000..fa0ad6f Binary files /dev/null and b/figs/RL_policy_demo.png 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/Safety Net Editted.png b/figs/Safety Net Editted.png new file mode 100644 index 0000000..e840b0b Binary files /dev/null and b/figs/Safety Net Editted.png differ diff --git a/figs/Safety Net.png b/figs/Safety Net.png new file mode 100644 index 0000000..9a16c8d Binary files /dev/null and b/figs/Safety Net.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/SyntheticDatasetOverview.png b/figs/SyntheticDatasetOverview.png new file mode 100644 index 0000000..f588f93 Binary files /dev/null and b/figs/SyntheticDatasetOverview.png 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_Classification.png b/figs/Synthetic_F_Dark_Classification.png new file mode 100644 index 0000000..3ba2011 Binary files /dev/null and b/figs/Synthetic_F_Dark_Classification.png 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/Synthetic_F_Dark_Confidence.png b/figs/Synthetic_F_Dark_Confidence.png new file mode 100644 index 0000000..2ad2bb0 Binary files /dev/null and b/figs/Synthetic_F_Dark_Confidence.png 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_Classification.png b/figs/VisDrone_F_Dark_Classification.png new file mode 100644 index 0000000..f9d44ea Binary files /dev/null and b/figs/VisDrone_F_Dark_Classification.png 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_Dark_Confidence.png b/figs/VisDrone_F_Dark_Confidence.png new file mode 100644 index 0000000..b5b11d5 Binary files /dev/null and b/figs/VisDrone_F_Dark_Confidence.png 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_Classification.png b/figs/VisDrone_F_Light_Classification.png new file mode 100644 index 0000000..136d7e4 Binary files /dev/null and b/figs/VisDrone_F_Light_Classification.png 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/VisDrone_F_Light_Confidence.png b/figs/VisDrone_F_Light_Confidence.png new file mode 100644 index 0000000..ff3b003 Binary files /dev/null and b/figs/VisDrone_F_Light_Confidence.png differ diff --git a/figs/YawRotation_Plot.pdf b/figs/YawRotation_Plot.pdf new file mode 100644 index 0000000..e083b54 Binary files /dev/null and b/figs/YawRotation_Plot.pdf differ diff --git a/figs/YawRotation_Plot.png b/figs/YawRotation_Plot.png new file mode 100644 index 0000000..2f90209 Binary files /dev/null and b/figs/YawRotation_Plot.png 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..b063d12 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..013c4cb 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..66c0580 100644 --- a/main.tex +++ b/main.tex @@ -1,99 +1,3184 @@ \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{dirtytalk} +\usepackage{multicol} +\usepackage{caption} +\captionsetup[table]{labelfont=bf, textfont=it} +\captionsetup[figure]{labelfont=bf, textfont=it} +\usepackage{subcaption} +\captionsetup[subfigure]{labelformat=parens} +\usepackage{xurl} +% \usepackage[hidelinks]{hyperref} +\Urlmuskip=0mu plus 1mu +\usepackage[table]{xcolor} +\usepackage[colorlinks=true, linkcolor=black, citecolor=black, hidelinks]{hyperref} +\usepackage{pdfpages} + +\usepackage[table]{xcolor} +\definecolor{swotS}{RGB}{226,237,143} +\definecolor{swotW}{RGB}{247,193,139} +\definecolor{swotO}{RGB}{173,208,187} +\definecolor{swotT}{RGB}{192,165,184} +\usepackage[raster]{tcolorbox} + + +\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{20 May 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} +\fancyhead[C]{Group} \section*{Abstract} +% Laser tag remains a popular and commercially successful game within the UK leisure industry, but its core mechanics have seen minimal innovation since its introduction in 1984 despite growing consumer demand for highly interactive leisure experiences. This report details the design and simulation of a novel iteration of the game in which human players compete against a multiagent autonomous drone system. + +% The concept is centred on drones designed from scratch to their required specifications, reinforcement learning ADD GLOSSARY LINK DON'T LEAVE THIS IN THE FINAL REPORT to control the drones' movement, a high-level control policy designed to create an engaging and enjoyable player experience and a companion app to encourage user engagement. + + +% Sustainability, ethics and safety concerns are considered, and the technical performance of the project is demonstrated through simulation analysis. The commercial viability is demonstrated through financial modelling, yielding a business with Net Present Value (\gls{npv}) of around £69,000. This proves the potential of the concept to revolutionise the laser tag industry. +Laser tag remains a popular and commercially successful game within the UK leisure industry, but its core mechanics have seen minimal innovation since its introduction in 1984 despite growing consumer demand for highly interactive leisure experiences. This report details the design and simulation of a novel iteration of the game in which human players compete against a multiagent autonomous drone system. +To ensure safe operation within a confined arena, the system utilises a custom modular quadrotor airframe physically segregated from players by industrial netting. Player detection and predictive 3D tracking rely on passive stereoscopic vision, a YOLOv8 nano model trained on synthetic Unity data, and a Linear Kalman Filter. A central server governs coordination over wireless networking, dynamically transitioning drones through distinct operational modes. +Subsystem navigation integrates \acrfull{bfs} for area scanning, \acrfull{rl} policies trained in Isaac Lab for flight control, and Artificial Potential Fields for collision avoidance. +Sustainability, ethics, and safety concerns are considered, and the technical performance of the project is demonstrated through simulation analysis. Commercial viability is supported by a companion app designed to encourage user engagement and validated through financial modelling yielding a business with a \acrfull{npv} of approximately £69,000. This establishes the concept as a viable and innovative evolution to the laser tag industry. -\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} +\newacronym{tv}{TV}{Terminal Value} +\newacronym{irr}{IRR}{Internal Rate of Return} +\newacronym{esc}{ESC}{Electronic Speed Controller} +\newacronym{abs}{ABS}{Acrylonitrile Butadiene Styrene} +\newacronym{pdb}{PDB}{Power Distribution Board} +\newacronym{swot}{SWOT}{Strengths, Weaknesses, Opportunities, and Threats} +\newacronym{ip}{IP}{Intellectual Property} +\newacronym{cad}{CAD}{Computer-Aided Design} +\newacronym{bfs}{BFS}{Breadth First Search} +\newacronym{pd}{PD}{Proportional-Derivative} +\newacronym{mpc}{MPC}{Model Predictive Control} +\newacronym{rl}{RL}{Reinforcement Learning} +\newacronym{aam}{AAM}{Actuator Allocation Matrix} +\newacronym{tof}{ToF}{Time of Flight} +\newacronym{dor}{DOR}{Data Output Rate} +\newacronym{pf}{PF}{Particle Filter} +\newacronym{ekf}{EKF}{Extended Kalman Filter} +\newacronym{rbpf}{RBPF}{Rao-Blackwellized Particle Filter} +\newacronym{kf}{KF}{Kalman Filter} +\newacronym{map}{MAP}{Maximum A Posteriori} +\newacronym{dfs}{DFS}{Depth First Search} +\newacronym{elu}{ELU}{Exponential Linear Unit} +\newacronym{apf}{APF}{Artificial Potential Field} +\newacronym{ui}{UI}{User Interface} +\newacronym{ml}{ML}{Machine Learning} +\newacronym{pwm}{PWM}{Pulse-Width Modulation} +\newacronym{gpio}{GPIO}{General Purpose Input/Output} +\newacronym{usb}{USB}{Universal Serial Bus} +\newacronym{led}{LED}{Light-Emitting Diode} \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]{Rishabh Luthra} +The UK leisure market is currently defined by a distinct consumer trend: a frugality in routine choices paired with a willingness to invest in high-value experiences~\cite{arrowsmith2026leisure, deloitte2026leisure_report}. This shift drives a growing demand for immersive environments that offer real-time interactivity and integrate the strategic depth of video games into the physical world. + +Since its introduction in 1984~\cite{LaserTagHistory}, the core mechanics of laser tag have remained largely unchanged. An estimated 76 million games are played every year~\cite{trutneeLaserTag}. This suggests that innovation within the laser tag industry has significant demand and commercial potential. + +To meet this demand, we present a novel laser tag game in which human players cooperate to compete against a team of autonomous drones. From a user perspective, the system aims to provide an engaging, safe, and highly interactive experience defined by specific gameplay modes and dynamic objectives (Section \ref{gameplay}). To complete these objectives, players navigate through a purpose-built indoor maze constructed from 5-metre high walls (Section \ref{map}). The project is governed by strict physical safety boundaries to ensure a low-risk environment; the arena features a dividing net that separates the drones flying overhead from the human players below. Designed with a 1200 J energy absorption capacity, this industrial netting provides a safety factor of 5.1 against a 4 kg drone flying at full thrust downwards. As a result, this mitigates the risk of human-drone collisions without diminishing game immersion. + +From a drone perspective, the primary goal is to achieve autonomy and coordinated teamwork within a confined environment. Since off-the-shelf platforms lack the necessary flexibility, payload integration, and component protection for such close-proximity indoor operations, a custom modular quadrotor airframe was developed (Section \ref{hardware}). The \gls{abs} 3D-printed chassis features integrated blade guards to ensure operational continuity during minor wall collisions. To satisfy a 2:1 thrust-to-weight ratio for a 4kg maximum takeoff mass, the propulsion system utilises BrotherHobby Avenger 2806.5 1300KV brushless motors paired with 8x4x3 polycarbonate propellers, driven by a 4S 5000 mAh Lithium Polymer battery to sustain approximately 10 minutes of active flight endurance. Dedicated player hardware, including sensor-equipped helmets and vests, then integrate into this ecosystem (Section \ref{player_hardware}). + +For multi-agent coordination, the system relies on an IEEE 802.11ac Wi-Fi communications framework (Section \ref{network}) linking the onboard drone hardware to a central server. The server manages the high-level game logic, evaluating the global state to transition individual drones dynamically through specific operational modes such as Search, Track, Shoot, and Movement (Section \ref{high level control}). + +To inform these high-level decisions, each drone is equipped with an OAK-D Lite passive stereoscopic camera mounted on a custom 3-axis tracking gimbal, which kinematically decouples the camera from the drone’s flight attitude to maintain continuous target lock. Visual data is ingested by a YOLOv8-nano (YOLOv8n) convolutional neural network (Section \ref{visual_perception}). To overcome the domain gap caused by the arena's low-light conditions and frequent target occlusions, this model was trained on a synthetic dataset created within Unity. Because active visual sensors would interfere with the game's \gls{ir} mechanics, and monocular depth estimation fails when a human target alters their posture, target depth is extracted passively via stereoscopic horizontal pixel disparity. This raw spatial data is smoothed using a Linear Kalman Filter, operating on a Discrete White Noise Acceleration (DWNA) model, to provide continuous, predictive 3D state estimations of the players. + +These estimated player coordinates update the central server's global state, which in turn dictates the high-level navigational objectives assigned to each drone. Search mode utilises a hybrid \gls{bfs} region-allocation and lawnmower trajectory algorithm to systematically scan the arena (Section \ref{search mode}). When rapid transit is required, flight control is handed over to a \gls{rl} policy trained offline in the Isaac Lab physics simulator, outputting body thrust and moment commands (Section \ref{movement mode}). Furthermore, an Artificial Potential Field (APF) controller handles real-time collision avoidance by computing repulsive gradients from walls and other agents, converting them into evasive manoeuvres (Section \ref{collision avoidance mode}). + +In addition to the technical deployment, user retention is driven by a companion mobile application that tracks performance metrics, leaderboards, and achievements to foster community engagement (Section \ref{app}). The technical development is supported by an evaluation of broader engineering considerations. These are validated by a quantitative risk assessment (Section \ref{risk-assessment}) and a financial model (Section \ref{commercialisation}), which confirms the commercial feasibility of the enterprise by projecting a \acrfull{npv} of £68,669 at an optimal price of £200 per game. Finally, the report assesses triple-bottom-line sustainability (Section \ref{sustainability}) and outlines a technology strategy using a House of Quality and \acrfull{swot} analysis (Section \ref{technology_strategy}). +\newpage -\begin{figure} +\section{Proposed Gameplay for Drone-Based Laser Tag} % Ritchie +\label{gameplay} +\fancyhead[C]{Richard Usherwood} +\begin{figure}[htbp] \centering - \includegraphics[width=0.5\linewidth]{example-image-duck} - \caption{An awesome image of a duck.} - \label{fig:enter-label} + \captionsetup{justification=centering} + \includegraphics[width=0.7\textwidth]{figs/Safety Net Editted.png} + \caption{A simulation of a player and a drone in the play arena \\ (Video demonstration: \url{https://youtu.be/nP8p0LBId1U})} + \label{fig:gameplay} \end{figure} +\subsection{Overview} +Players are equipped with laser guns (\gls{ir} emitters that transmit encoded data), and helmets and vests, both containing \gls{ir} sensors. The drones are equipped with \gls{ir} sensors as well as turrets which emit \gls{ir} radiation (see Section \ref{Turret}). When not flying, they are dormant in a standby location in which employees can replace their batteries. If a player is hit, they must navigate to a designated \say{timeout area} of the maze, where they are safe from drones, and wait for 10 seconds. The drones, guns, helmets and vests connect via Wi-Fi to a central server, so, when hit, the player's gun is disabled until their timeout ends (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 3 m height for safety, to be detailed in Section \ref{risk-assessment}). The players play cooperatively, against the drones.\newline + +\noindent Two game modes have been designed: \say{Wave Mode} and \say{Objective Mode}. These are summarised in the following sections. +\subsection{Wave Mode} +In \say{Wave Mode}, the players \say{fight} a number of drones, released in an order designed to be both challenging and engaging. When hit, the drones return to their standby location, where they will remain. If all of the players time out simultaneously, 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 in difficulty. Each level will be given a difficulty rating. This allows a team to end a game with a clear metric of their performance: the difficulty rating of the hardest wave completed. This will also allow a team to track their improvement. In future, this will be displayed in the companion app, allowing players to compare scores with friends. -\fancyhead[C]{Student2 author of section} -\subsection{An awesome image} +\subsection{Objective Mode} +In \say{Objective Mode}, the players must navigate the maze to complete objectives, such as \say{Hold this button for 5 seconds}, or \say{Shoot this target on the wall}, which are communicated via speakers. They must complete all objectives within a time limit to pass the level. The other mechanics of the game are the same as in \say{Wave Mode}, other than that the drones return after a short timeout when hit. If they complete all objectives, they win. If they win, they will be encouraged to attempt a harder level. Just as in \say{Wave Mode}, the levels will be designed and play-tested to be both challenging and engaging; a catalogue of levels marked with a numerical difficulty can be selected in-app.\newline -\lipsum[1-2] +\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 abilities. However, the difficulty of the level needs 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, their top speed could be capped, or artificial inaccuracy could be added to their shooting.\newline +\noindent 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, once the arena has been built. +\newpage -\subsection{An awesome table} +%%%%%%%%%----End of System Proposed Gameplay------%%%%%%%%% -\begin{table}[h] +\section{Game Arena Map Design} \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, so we need to design a map for this arena which is accessible to both players and drones and allows the two to interact safely 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 consistency 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 to contain the arena, we want to utilise the space as much as possible, so 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 its wall matrix are shown below. + +\begin{figure}[htbp] \centering - \begin{tabular}{@{}lll@{}} - \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 + \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} + +\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 is high enough to be out of reach from players allowing them to move around freely as if it were 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{Net Material} +We plan to use industrial safety nets to separate the players from the drones as these are tested and reliable. SafetyNet365, a custom safety net manufacturer, produces 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, and we chose the largest mesh size of to minimise the area blocked by the net. This net will be referred to as net A \cite{testedSafetyNet}. As seen in Table \ref{SafetyNetSpecs} below, this has an energy absorption of 4.8kJ. The kinetic energy at impact of our 4kg drone falling the maximum distance of 2m with maximum thrust downwards and a thrust to weight ratio of 2 would be 235J, assuming $g =9.81\mathrm{ms}^{-1}$. 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. Assuming that the energy absorption of the net is proportional to the maximum energy stored in a single thread, 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 $E_a = k F$, where $E_a$ 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 obtain a lower bound of the energy absorption. This net will be referred to as net B \cite{thinSafetyNet}. Using the values in Table \ref{SafetyNetSpecs} below, we can estimate the energy absorption of net B, $E_{a,B}$, from that of net A, $E_{a,A}$, using the formula $E_{a,B} = E_{a,A} \cdot F_B/F_A$, giving $E_{a,B} = 375\mathrm{J}$. 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 $E_{a,C} = E_{a,A} \cdot F_C/F_A = 1200\mathrm{J}$, giving us a safety factor of 5.1 which is well above the proposed minimum of 3. + +\begin{table}[htbp] + \centering + \caption{Safety net specifications} + \label{SafetyNetSpecs} + \begin{tabular}{|c| c c c|} + \hline + \textbf{} & \textbf{Net A} & \textbf{Net B} & \textbf{Net C}\\ + \hline + Material Diameter [mm] & 5 & 1.5 & 0.5\\ + \hline + Mesh Size [mm] & 100x100 & 100x100 & 100x100 \\ + \hline + Max Tensile Strength [N] & 3200 & 250& 800 \\ + \hline + Breaking Elongation [\%] & 15 & 15 & 15 \\ + \hline + Energy Absorption [J] & 4800 & 375 & 1200 \\ + \hline + Energy Absorption Safety Factor & 20.4 & 1.6 & 5.1 \\ + \hline \end{tabular} - \caption{An awesome table, by GPT-4o mini \cite{achiam2023gpt}.} - \label{tab:my_label} \end{table} -\lipsum[1-6] +\newpage -\subsection{An awesome Acronym} +%%%%%%%%%----End of Map Design------%%%%%%%%% -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. +\section{Drone Hardware and Electronics Design} % Rickie +\label{hardware} +\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 multiagent laser tag system. Various options may offer good flight performance and easy maintenance, but are generally optimised for less intense activities and outdoor environments, and therefore provide limited flexibility for integrating custom sensing, laser tag hardware, and protective structures. -\printbibliography{biblio} +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 for more freedom to choose components, organise the internal layout, and include additional features necessary to the gameplay. + +\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 game-play +\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 game-play and safety. + \item \textbf{Visibility and challenge: } The drone had to be large and visible enough for players to clearly recognise the target during game-play, 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 game-play quality. + \item \textbf{Supporting game systems and battery: } The drone needs to carry additional hardware required for game-play, such as \gls{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 multiagent 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 \gls{cad} modelling, component data sheets, and estimated performance values through online data and programme 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 behaviour, and measured sensor performance, were simplified or left for future work. + +\subsubsection{Summarised Table for Design Criteria} + +In summary, the key design criteria are consolidated in Table~\ref{tab:starter_design_criteria}. + +\begin{table}[htbp] +\centering +\caption{Summarised starter design criteria for the drone platform} +\label{tab:starter_design_criteria} +\begin{tabular}{|c|c|} +\hline +\textbf{Design Parameter} & \textbf{Target / Requirement} \\ +\hline +Operating environment & Indoor arena with close proximity to players, walls, and obstacles \\ +\hline +Operational role & Stable and manoeuvrable aerial platform for indoor game-play \\ +\hline +Configuration & Compact quadrotor platform \\ +\hline +Maximum mass & $\leq 4.0$ kg \\ +\hline +Maximum width & $\leq 600$ mm \\ +\hline +Target cost per unit & \pounds300--\pounds500 \\ +\hline +Target game duration & 45 min \\ +\hline +Target drone endurance & 8-10 min before recharge \\ +\hline +Visibility requirement & Large enough to be clearly visible for indoor game-play \\ +\hline +Internal space requirement & Sufficient internal volume for onboard electronics \\ +\hline +Safety requirement & Safe operation, protected parts \\ +\hline +Maintainability requirement & Easy maintenance with cheap replaceable damaged parts \\ +\hline +Structural requirement & Airframe must support normal flight loads and minor impact conditions \\ +\hline +Game-play requirement & Agile enough to act as a believable and challenging in-game opponent \\ +\hline +\end{tabular} +\end{table} + +\subsection{UAV Electronics Design} +\label{sec:electronics_design} + +\subsubsection{Propulsion System} +\label{sec: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. + +The Avenger 2806.5 was selected because it provided a strong thrust margin without requiring an excessively large motor. As shown in Table~\ref{tab:motor_specifications}), each motor 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. + +\begin{table}[h] +\centering +\caption[Motor specifications]{Motor specifications\footnotemark} +\label{tab:motor_specifications} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Parameter} & \textbf{Value} & \textbf{Design relevance} \\ +\hline +Selected motor & BrotherHobby Avenger 2806.5 1300KV & Main propulsion motor \\ +\hline +Motor type & Brushless & Suitable for propulsion \\ +\hline +KV rating & 1300KV & Suitable for operation \\ +\hline +Mass & 41 g & 4 motors contribute 164g \\ +\hline +Cell compatibility & 4--6S LiPo & required battery range\\ +\hline +Bolt & M3, 19 mm $\times$ 19 mm & Defines mounting interface \\ +\hline +Wire specification & 18 AWG, 20 cm & \gls{esc} and wiring \\ +\hline +Target thrust per motor & $\approx 19.6$ N & 4 motors provides 78.5 N \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data adapted from the BrotherHobby Avenger 2806.5 manufacturer specification \cite{brotherhobby_avenger28065}} + +\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 (summarised in Table~\ref{tab:propeller_specifications}) was used as a reference for dimensions and mass, which formed the basis for certain assumptions related to the rotor-arm design. + +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. + +\begin{table}[htbp] +\centering +\caption[8$\times$4$\times$3 propeller specifications]{8$\times$4$\times$3 propeller specifications\footnotemark} +\label{tab:propeller_specifications} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Parameter} & \textbf{Reference Value} & \textbf{Design Relevance} \\ +\hline +Propeller geometry & 8$\times$4$\times$3 & Defines propeller geometry \\ +\hline +Diameter & 8 inch & Sets swept area \\ +\hline +Pitch & 4 inch & Moderate pitch suitable for thrust operation \\ +\hline +Blade count & 3 blades & Higher thrust capability \\ +\hline +Reference material & Polycarbonate & Lightweight propeller material \\ +\hline +Reference mass & 13 g & 4 propellers contribute 52 g \\ +\hline +Rotation requirement & 2 CW + 2 CCW & Balanced quadrotor operation \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data from an HQProp 8$\times$4$\times$3 propeller dataset\cite{hqprop_8x4x3}} + +\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: + + + +\begin{equation} +T = C_T \rho n^2 D^4 +\end{equation} + + +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: + +\begin{equation} +n = \sqrt{\frac{T}{C_T \rho D^4}}. +\end{equation} + +The ideal no-load speed of the motor can be estimated from the motor \(K_V\) rating: + +\begin{equation} +RPM_0= K_V V +\end{equation} + +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: + +\begin{equation} +RPM_{\text{loaded}} = \eta_{\text{rpm}} RPM_0, +\end{equation} + + +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} +\begin{tabular}{|c|c|} +\hline +\textbf{Loaded RPM Factor, \(\eta_{\text{rpm}}\)} & \textbf{Loaded RPM} \\ +\hline +0.75 & 14,430 rpm \\ +0.80 & 15,392 rpm \\ +0.85 & 16,354 rpm \\ +0.90 & 17,316 rpm \\ +\hline +\end{tabular} +\end{table} + +As there was no given exact thrust coefficients, we tested using a range of realistic values. + +\begin{table}[htbp] +\centering +\caption{Estimated thrust per motor for different loaded RPM factors and thrust coefficients} +\label{tab:motor_prop_validity_check} +\begin{tabular}{|c|c|c|c|c|} +\hline +\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\)} \\ +\hline +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 \\ +\hline +\end{tabular} +\end{table} + +From Tables~\ref{tab:loaded_rpm_factors} and~\ref{tab:motor_prop_validity_check}, 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 \gls{esc} behaviour and battery voltage sag. + +However, the target max value is not the same as minimum thrust required for flight. Given the total max 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 manoeuvring, disturbance rejection, and stable control. However, this proves that the 2:1 thrust-to-weight ratio gives a large and safe tolerance. + +\paragraph{\gls{esc} Selection} + +The \gls{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 \gls{esc} per motor. The selected \gls{esc} was the LittleBee Spring 40A. As shown in the Table~\ref{tab:esc_specifications}, the available LittleBee Spring 40A specifications list \(2-6~\text{S}\) LiPo input, \(40~\text{A}\) continuous current, with compact dimensions. + +This \gls{esc} was chosen since it matched the propulsion system requirements. However, as the \gls{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. + +\begin{table}[htbp] +\centering +\caption[\gls{esc} specifications]{\gls{esc} specifications\footnotemark} +\label{tab:esc_specifications} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Parameter} & \textbf{Manufacturer / Supplier Specification} & \textbf{Design Relevance} \\ +\hline +Selected \gls{esc} & LittleBee Spring 40A & Speed controller for motor \\ +\hline +Input voltage & 2--6S LiPo & Compatible with power range \\ +\hline +Continuous current & 40 A & Provides current capacity \\ +\hline +Size & 35 mm $\times$ 17 mm & Compact \\ +\hline +Weight & 12 g with wires & Low mass \\ +\hline +Supported protocols & OneShot, MultiShot, DShot & Suitable for throttle control \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data from available supplier specifications \cite{littlebee_spring_40a}} + +\subsubsection{Power System} +\label{sec: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 \gls{esc}s 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 \gls{esc}s 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 a nominal voltage of \(14.8~\text{V}\), matching the motor and \gls{esc} requirements more appropriately while maintaining a target capacity for approximately 10 minutes of drone operation before recharge. + +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 \gls{esc}-motor configuration while the \(5000~\text{mAh}\) also provided the target with \(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. +\begin{table}[htbp] +\centering +\caption[4S 5000 mAh LiPo Battery specifications]{4S 5000 mAh LiPo Battery specifications\footnotemark} +\label{tab:battery_specifications} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Parameter} & \textbf{Representative Specification} & \textbf{Design Relevance} \\ +\hline +Battery type & LiPo battery pack & Suitable for high-current drone propulsion \\ +\hline +Cell count & 4S / 4 cells & Matches propulsion requirements \\ +\hline +Nominal voltage & 14.8 V & Used for calculations \\ +\hline +Capacity & 5000 mAh / 5 Ah & Supports the target endurance \\ +\hline +Representative mass range & 390--589 g & Gives a range for mass \\ +\hline +Representative dimensions & 32 $\times$ 42 $\times$ 132 mm & realistic size \\ +\hline +Battery count & 1 pack per drone & Simplifies packaging and recharge \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data adapted from commercially viable sources\cite{tattu_bashing_4s_5000mah, gensace_4s_5000mah}} + +\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 + +\begin{equation} +E=VC +\end{equation} +\[E= 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 +\begin{equation} +P_{\text{avg,max}} = \frac{E_{\text{usable}}}{t} +\end{equation} +\[ +P_{\text{avg,max}} = \frac{59.2}{0.167} \approx 355~\text{W}. +\] + +The corresponding current draw is +\begin{equation} +I_{\text{avg}} = \frac{P_{\text{avg,max}}}{V} +\end{equation} +\[ +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 \gls{esc}s safely and with enough current margin. Since each motor is driven by a separate \gls{esc}, a \gls{pdb} should be able to supply the combined current demand of all propulsion channels. + +Given the \gls{esc}s are rated \(40~\text{A}\) each, the combined theoretical maximum \gls{esc} demand is: $4\times40=160\text{A}$. We require a high-current \gls{pdb}, which was chosen to be the Holybro Power Distribution Board 300A. Shown in Table~\ref{tab:pdb_specifications}, 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 \gls{esc} demand. + +\begin{table}[htbp] +\centering +\caption[\gls{pdb} specifications]{\gls{pdb} specifications\footnotemark} +\label{tab:pdb_specifications} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Parameter} & \textbf{Manufacturer / Supplier Specification} & \textbf{Design Relevance} \\ +\hline +Selected PDB & Holybro Power Distribution Board 300A & Main PDB \\ +\hline +Continuous current rating & 300 A & Margin above theoretical maximum \\ +\hline +Burst current rating & 1000 A & Tolerance for spikes \\ +\hline +PCB design & 10 oz copper & Safe method of wiring \\ +\hline +Connector options & XT90 and XT30 options available & Main connection route \\ +\hline +Mounting holes & M3 mounting holes & Main attachment to drone hull \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data from the Holybro PDB 300A specification \cite{holybro_pdb_300a}} + +It should be noted that the \gls{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 these components. + +\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. + +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. As shown in Table~\ref{tab:voltage_regulator_specifications}, 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. + +\begin{table}[htbp] +\centering +\caption[5 V step-down regulator specifications]{5 V step-down regulator specifications\footnotemark} +\label{tab:voltage_regulator_specifications} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Parameter} & \textbf{Manufacturer Specification} & \textbf{Design Relevance} \\ +\hline +Regulator & Pololu D24V90F5 & 5 V step-down regulator \\ +\hline +Regulator type & Step-down / buck regulator & steps down the higher 4S battery voltage \\ +\hline +Input voltage range & 5--38 V & Compatible with the 14.8 V 4S LiPo battery \\ +\hline +Output voltage & Fixed 5 V & Suitable for the 5 V electronics \\ +\hline +Efficiency & 80--95\% & Reduces power loss and heating \\ +\hline +Size & 40.6 mm $\times$ 20.3 mm $\times$ 7.6 mm & Sizeable for integration into drone \\ +\hline +Weight & Approximately 4.8 g & Low mass contribution \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data from Pololu D24V90F5 manufacturer \cite{pololu_d24v90f5}} + +\paragraph{Power-system Summary} + +The final power system is as shown in Fig.~\ref{fig:Power_Systems}, it is 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 \gls{esc}s 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{figure}[htbp] + \centering + \includegraphics[width=0.75\textwidth]{Power System Map.png} + \caption{General Power Systems Layout} + \label{fig:Power_Systems} +\end{figure} + +\subsubsection{Onboard Computing and Communication} +\label{sec: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 their respective onboard tasks, 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 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. + +Two main Raspberry Pi single-board computers were considered, the Raspberry Pi 4 Model B and the Raspberry Pi 5 - comparison is 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} (shown in Fig.~\ref{fig: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, \gls{gpio}, \gls{usb}, and camera interfaces, while being easier to power and package inside the drone. + +\begin{table}[htbp] +\centering +\caption[Comparison of Raspberry Pi single-board computer]{Comparison of Raspberry Pi single-board computer\footnotemark} +\label{tab:raspberrypi_comparison} +\begin{tabularx}{\textwidth}{|p{3cm}|X|X|} +\hline +\textbf{Parameter} & \textbf{Raspberry Pi 4 Model B} & \textbf{Raspberry Pi 5} \\ +\hline +Processor & Broadcom BCM2711 quad-core Cortex-A72 64-bit SoC & Broadcom BCM2712 quad-core Cortex-A76 64-bit SoC \\ +\hline +Clock speed & 1.8 GHz & 2.4 GHz \\ +\hline +Relative performance & sufficient for deployed models & Approximately 2--3$\times$ CPU performance relative to Raspberry Pi 4 \\ +\hline +Memory options & 1 GB, 2 GB, 4 GB, or 8 GB LPDDR4 & 1 GB, 2 GB, 4 GB, 8 GB, or 16 GB LPDDR4X \\ +\hline +Wireless LAN & 2.4 GHz and 5.0 GHz IEEE 802.11ac Wi-Fi & Dual-band 802.11ac Wi-Fi \\ +\hline +Bluetooth & Bluetooth 5.0, BLE & Bluetooth 5.0, BLE \\ +\hline +\gls{gpio} & Raspberry Pi standard 40-pin GPIO header & Raspberry Pi standard 40-pin \gls{gpio} header \\ +\hline +Camera interface & 2-lane MIPI CSI camera port & 2 $\times$ 4-lane MIPI camera/display transceivers \\ +\hline +\gls{usb} & 2 $\times$ USB 3.0, 2 $\times$ USB 2.0 & 2 $\times$ USB 3.0, 2 $\times$ \gls{usb} 2.0 \\ +\hline +Approximate cost & From \pounds35, depending on RAM option & From \pounds45, depending on RAM option \\ + +\hline +\end{tabularx} +\end{table} + +\footnotetext{Data from official Raspberry Pi \cite{raspberrypi4_specs, raspberrypi5_specs}} + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\textwidth]{Hardware/Raspberry Pi 4 Model B.png} + \caption{Raspberry Pi 4 Model B} + \label{fig:Raspberry Pi 4 Model B} +\end{figure} + +\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 Section~\ref{network}. + +\paragraph{Interface with Sensors and Control Hardware} + +Drone electronics will connect to the onboard computer via the \gls{gpio}, serial, \gls{usb}, and camera-related interfaces. The camera would connect to the Raspberry Pi through \gls{usb}, allowing the Raspberry Pi to receive camera, depth, and other processed visual data from the camera module. Sensors such as the \gls{imu} and \gls{tof} would connect through standard buses which allows the Raspberry Pi to read data during flight operations. The \gls{ir} receivers would connect to \gls{gpio} pins while the \gls{ir} emitter would be controlled through a \gls{gpio} output signal. The gimbal/turret servos would be driven using \gls{pwm} control signals, allowing onboard system to aim the camera and \gls{ir} emitter simultaneously. \gls{esc}s would receive power directly from the battery via the \gls{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} \label{sensorArray} + +\paragraph{Camera} + +The camera selected by the visual perception work-stream was the OAK-D Lite (shown in Fig.~\ref{fig:Camera}) 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 \gls{usb} hence the drone body must be designed to ensure both the \gls{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 \gls{ir} emitter inside a gimbal/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 Section~\ref{Sensor Selection}. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.4\textwidth]{Hardware/Oak D Lite Camera.jpg} + \caption{Oak D Lite Camera \cite{oakd_lite_specs}} + \label{fig:Camera} +\end{figure} + +\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 stabilisation, height referencing, and obstacle awareness during indoor operations: the \gls{imu} measured body motion, the \gls{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 \gls{tof} sensor was considered more appropriate for indoor environment, where the ceiling height can be known in advance. + +The SparkFun ICM-20948 \gls{imu} (shown in Fig.~\ref{fig: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 \gls{tof} sensors are included based on the requirements from the control development work. These sensors provide compact distance measurements for the pre-trained \gls{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. + +A Consolidated summarisation of the flight-control sensors are shown in Table~\ref{tab:flight_control_sensors} below. + +\begin{table}[htbp] +\centering +\caption{Flight-control sensors \cite{sparkfun_icm20948, st_vl53l1x, st_vl53l5cx}} +\label{tab:flight_control_sensors} +\begin{tabularx}{\textwidth}{|p{3cm}|X|X|X|} +\hline +\textbf{Sensor} & \textbf{Role} & \textbf{Placement / Orientation} & \textbf{Key Specification} \\ +\hline +SparkFun ICM-20948 \gls{imu} & Measures drone motion and orientation/state & Housed inside hull, near the centre & 9-axis \gls{imu}: 3-axis accelerometer, 3-axis gyroscope, 3-axis magnetometer; I\textsuperscript{2}C/SPI support \\ +\hline +VL53L1X \gls{tof} sensor & Provides vertical distance reference & Mounted pointing upwards & \gls{tof} ranging up to approximately 4 m; up to 50 Hz ranging frequency \\ +\hline +VL53L5CX \gls{tof} sensors & Provides side obstacle awareness and short-range distance sensing & Mounted facing outwards on multiple sides of the drone & 8$\times$8 multizone \gls{tof} sensing; up to 4 m range; \\ +\hline +\end{tabularx} +\end{table} + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.3\textwidth]{Hardware/Sparkfun IMU.png} + \caption{SparkFun \gls{imu}} + \label{fig:IMU} +\end{figure} + +\paragraph{\gls{ir} Tagging System} + +For game-specific components, the drone is required to have an \gls{ir} tagging system capable of tagging players and detecting when it has been tagged. Universally, the physical hardware for general laser-tag gameplay uses \gls{ir} rather than visible lasers. This is due to safety and regulatory reasons: laser products usage is 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 \gls{ir} 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 \gls{ir} components are physically installed into the overall drone design. + +\textbf{\gls{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{\gls{ir} receiver} - These \gls{ir} sensors should be distributed around the drone hull where they should be exposed enough to detect incoming \gls{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. + +\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 modelling and assembly designs were 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} \label{drone dimensions} + +The early concepts tested out basic airframe layouts. The first concept followed a compact quadrotor arrangement (shown in Fig.~\ref{fig:Model1}), 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 \gls{cad} assembly, internal packaging became the main issue. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.6\textwidth]{Hardware/Model 1.png} + \caption{Preliminary Model} + \label{fig:Model1} +\end{figure} + +Further concepts continued to investigate symmetrical quadrotor layouts with increased body volume. One version (shown in Fig.~\ref{fig:Model 2}) 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. + +This led to a complete change in direction for the final design (shown in Fig.~\ref{fig:ModelFinal}): a modular mirrored layout, where the rotor arms are separate from the main body and secured using linkage parts and bolts. With a size of 580x420x260mm, the body, arms, linkages, and mounts are to be manufactured separately to ensure easy assembly. 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. -% 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} -\end{document} +\begin{figure}[htbp] + \centering + \includegraphics[width=0.6\textwidth]{Hardware/Model 2.png} + \caption{Model 2} + \label{fig:Model 2} +\end{figure} + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.6\textwidth]{Hardware/Final Model (un assembled).png} + \caption{Final Un-assembled Drone \gls{cad}} + \label{fig:ModelFinal} +\end{figure} + +\subsubsection{Main Body Design} + +The main body is composed of three main parts (shown in Fig.~\ref{fig:Main Body}): the top hull, the bottom hull, and the electronics basket. + +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. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\textwidth]{Hardware/Main Body.png} + \caption{Exploded View of Main Body - Top Hull(top), Electronic Basket(mid), Bottom Hull (bottom)} + \label{fig:Main Body} +\end{figure} + +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. + +The values in Table~\ref{tab:main_body_mass_estimate} were estimated from the Fusion 360 CAD model using assigned \gls{abs} material properties. Given Fusion 360 gives a solid \gls{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{Estimated printed mass of central body} +\label{tab:main_body_mass_estimate} +\begin{tabular}{|c|c|c|c|} +\hline +\textbf{Component} & \textbf{Solid \gls{cad} Mass(g)} & \textbf{Infill Assumption} & \textbf{Estimated Printed Mass(g)} \\ +\hline +Top hull & 764.457 & 20\% & 152.9 \\ +Bottom hull + landing gear & 1163.830 & 25\% & 291.0 \\ +Electronics basket & 604.322 & 30\% & 181.3 \\ +\hline +\textbf{Total main body assembly} & \textbf{2532.609 g} & -- & \textbf{625.1 g} \\ +\hline +\end{tabular} +\end{table} + +\begin{table}[htbp] +\centering +\caption{Maximum \gls{cad} dimensions of the main body components} +\label{tab:main_body_dimensions} +\begin{tabular}{|c|c|c|c|} +\hline +\textbf{Component} & \textbf{X (mm)} & \textbf{Y (mm)} & \textbf{Z (mm)} \\ +\hline +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 \\ +\hline +\end{tabular} +\end{table} + +Table~\ref{tab:main_body_dimensions} shows the max \gls{cad} dimensions of the main body components, all of which are shown to be within 600mm in size as required. + +\subsubsection{Rotor Arm and Motor Mount Design} + +The rotor-arm assembly (shown in Fig.~\ref{fig:Rotor}) 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. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.75\textwidth]{Hardware/Blade.png} + \caption{Rotor-arm Design} + \label{fig:Rotor} +\end{figure} + +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 Section~\ref{sec: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 compared to the rest of the body. + +The values in Table~\ref{tab:rotor_arm_mass_estimate} were estimated from the Fusion 360 \gls{cad} model using the properties assigned of \gls{abs} material. Just like the main body, the Fusion 360 reports the solid-body \gls{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{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{tabular}{|c|c|c|c|} +\toprule +\textbf{Component} & \textbf{Solid \gls{cad} Mass(g)} & \textbf{Infill Assumption} & \textbf{Estimated Printed Mass(g)} \\ +\hline +Rear blade guard & 91.2 & 35\% & 31.9 \\ +Front blade guard & 86.3 & 35\% & 30.2 \\ +Rear rotor arm & 129.1 & 60\% & 77.5 \\ +Rear upper linkage & 3.8 & 80\% & 3.0 \\ +Rear lower linkage & 3.8 & 80\% & 3.0 \\ +Front rotor arm & 171.5 & 60\% & 102.9 \\ +Front upper linkage & 3.7 & 80\% & 3.0 \\ +Front lower linkage & 3.7 & 80\% & 3.0 \\ +\hline +\textbf{Total one-side assembly} & \textbf{493.1} & -- & \textbf{254.5} \\ +\hline +\end{tabular} +\end{table} + +\subsubsection{Turret/Gimbal Design} +\label{Turret} +The design of the gimbal turret (shown in Fig.~\ref{fig:Gimbal}) included requirements of the visual learning process, where the camera was required to roll, pitch and yaw - its range of motion is demonstrated via this \href{https://drive.google.com/file/d/16lPV_-VS57LZUX7-dhvgIS6Q2sYhDQis/view?usp=sharing}{video}. The design took inspiration from traditional industrial two-axis gimbals, but with an additional yaw axis that provided 3-axis movement. The camera and \gls{ir} emitter needed to remain aligned to ensure aiming and tagging were performed in the same direction. The OAK D Lite camera was used as a reference in designing the dimensions of the gimbal. (The complete gimbal assembly is shown in Fig.~\ref{fig:Gimbal2}) + +Mechanically, the gimbal has full $360^{\circ}$ range for both yaw and pitch - but would be advised not to go beyond $360^{\circ}$ during operation in order to prevent wire entanglement. The roll motion only allows $\pm50^{\circ}$ range of motion. The gimbal is mounted through the central opening in the bottom hull. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.75\textwidth]{Hardware/Blueprint for Gimbal (without motor and servos).png} + \caption{Gimbal Design (without motor and servos)} + \label{fig:Gimbal} +\end{figure} + +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} 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 \gls{ir} emitter to tilt 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 \gls{ir} emitter. As the camera and \gls{ir} emitter are mounted on the same final axis, the visual tracking direction and \gls{ir} tagging direction remain aligned. + +Together, the yaw servo, pitch motor, and roll motor allow the turret to achieve 3-axis movement. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.70\textwidth]{Hardware/Exploded Gimbal View.png} + \caption{Gimbal Exploded View} + \label{fig:Gimbal2} +\end{figure} + +\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{tabular}{|c|c|c|c|} +\hline +\textbf{Component} & \textbf{Solid \gls{cad} Mass(g)} & \textbf{Infill Assumption} & \textbf{Estimated Printed Mass(g)} \\ +\hline +Gimbal installation plate & 21.58 & 50\% & 10.8 \\ +Square axial component & 12.23 & 70\% & 8.6 \\ +Gimbal pitch axis component & 6.65 & 70\% & 4.7 \\ +Gimbal roll axis component & 5.21 & 70\% & 3.6 \\ +Coupler & 20.89 & 80\% & 16.7 \\ +\hline +\textbf{Total gimbal assembly} & \textbf{66.55} & -- & \textbf{44.4} \\ +\hline +\end{tabular} +\end{table} + +Table~\ref{tab:gimbal_mass_estimate} shows the mass of the solid body from Fusion 360 using assigned \gls{abs} material properties. Estimations were made, shown in Table~\ref{tab:gimbal_mass_estimate}, using infill assumptions for each component which reduced the final mass from 66.55g to 44.4g - excluding the camera, \gls{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 brushless 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. + +The MG90S is suitable for the yaw stage as it fits within the turret base region inside the electronic basket. The operating speed is sufficient for controlled left-right aiming at 0.10 s/60$^\circ$ at 4.8 V or 0.08 s/60$^\circ$ at 6 V. The gimbal motors are used for pitch and roll control as they are generally designed for smoother movement. They are specified for payloads in 100-200g range which fits the weight requirements for the OAK-D Lite (61g) along with the \gls{ir} emitter and gimbal parts. The suggested GBM2208 dimensions are approximately 28 x 22 mm which fits the clearance for the motor mount locations. Actuator specifications are summarised in Table~\ref{tab:gimbal_actuator_specs}. + +\begin{table}[htbp] +\centering +\caption[Suggested actuator specifications for the gimbal turret]{Suggested actuator specifications for the gimbal turret\footnotemark} +\label{tab:gimbal_actuator_specs} +\renewcommand{\arraystretch}{1.15} +\begin{tabular}{|c|c|c|} +\hline +\textbf{Axis} & \textbf{Suggested Actuator} & \textbf{Size(mm)/ Weight(g)}\\ +\hline +Yaw & MG90S servo & 22.8 $\times$ 12.2 $\times$ 28.5 / 13.4 \\ + +Pitch & Quanum/GBM2208 brushless gimbal motor & 28 $\times$ 22 / 43 \\ + +Roll & Quanum/GBM2208 brushless gimbal motor & 28 $\times$ 22 / 43 \\ +\hline +\end{tabular} +\end{table} + +\footnotetext{Data adapted from supplier specifications\cite{mg90s_servo, gbm2208_gimbal_motor}.} + +\subsubsection{Overall Airframe Configuration - Assembly} + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.75\textwidth]{Hardware/Complete Assembly.png} + \caption{Complete Assembly} + \label{fig:Complete Assembly} +\end{figure} + +The final airframe configuration (shown in Fig.~\ref{fig:Complete Assembly}) brings the separate subsystem assemblies together into a single integrated drone assembly, shown in Fig.~\ref{fig:Complete Assembly}. The design uses a modular central body with detachable rotor-arm, integrated with propeller protection and helicopter-based landing gears, along with a centrally mounted 3-axis gimbal turret. This layout suits the electronics, propulsion, sensors, camera, and \gls{ir}-tagging system while keeping key parts accessible for maintenance. Rather than one-piece shell, all parts are designed to be separate yet connected, replaceable, and cheap making it practical for manufacture and repair. + +\paragraph{Component Layout} + +The drone parts are designed with reference to the chosen internal electronics. Most of the components will be housed in the electronics basket - including the Raspberry Pi, \gls{esc}s, voltage regulator, \gls{imu} sensor, battery, and wiring. The OAK-D Lite camera and \gls{ir} emitter will be mounted externally on the gimbal turret, with their wiring routed back into the central body opening. The motor and propellers will be mounted in the motor arms. + +\subsection{Preliminary Engineering Evaluation} +\label{sec:Engineering Evaluation} + +\paragraph{Context} A preliminary design evaluation was conducted to assess how realistic the final hardware design was. Since the drone was developed through \gls{cad} modelling and component research, the evaluation focuses on whether the proposed airframe is practical and suitable for manufacture. The main areas considered here are structural behaviour and feasibility of modular assembly. Electronic components and power choices were already assessed through calculations in the section ~\ref{sec:electronics_design} - such as the propulsion feasibility check in section ~\ref{sec:propulsion_system}, battery endurance in section ~\ref{sec:power_system} and other certain power-distribution analysis. + +\subsubsection{Structural Assessment of Critical Components} + +The structural assessment focused on two components most exposed to loading and collision impact: the motor-body joints and the blade guards. As the project did not develop a physical prototype, the evaluation was carried out using \gls{cad}-based structural simulations rather than physical testing. + + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.9\textwidth]{Hardware/Rotor Arm Simulation Test Image.png} + \caption{Rotor Arm Simulation Test} + \label{fig:Rotor Arm Sim} +\end{figure} + +\paragraph{Rotor Arm Simulation} +The first simulation assessed the joint between the rotor arm and the electronics basket, as this connection transfers the motor thrust load back into the main body. This area was important as any failure would affect propulsion support and the integrity of the overall airframe. A static load represents the thrust force acting through the motor and rotor arm - the applied load was above 20N, which is close to the estimated maximum thrust per motor used in the propulsion analysis. + +The simulation showed that the highest stress occurred near the handle area of the electronic basket, which was expected because this is where the rotor-arm load is transferred into the central structure. Most of the rotor arm remained in the lower-stress blue/green region - which suggests that the rotor arm geometry was not the limiting factor. The minimum safety factor was approximately 2.23, as shown in Fig. ~\ref{fig:Rotor Arm Sim}, meaning the component remained above the failure threshold for the load case. + +This result showed that the structure was reasonable. However, this should still be treated as a preliminary \gls{cad}-based result, noting the fact it does not account for vibration, fatigue, manufacturing defects and loose bolts. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.9\textwidth]{Hardware/Blade Guard Simulation.png} + \caption{Blade Guard Simulation test} + \label{fig:BladeGaurdSim} +\end{figure} + +\paragraph{Blade Guard Impact Simulation} + +The blade guard was assessed as it was one of the most exposed parts of the drone and is likely to be the primary contact point during minor collisions with walls and obstacles. A 20 N direct front impact was applied in a static structural simulation. + +The simulation showed that the highest stress occurred near the connection between guard and arm, making this the weakest region of the blade guard design. The minimum safety factor was 1.099 as shown in Fig. ~\ref{fig:BladeGaurdSim}, slightly above 1, meaning the structure passes the load case but only by a small margin (less than 10\%) which suggests that the current design is acceptable as an early simulation result. + +The assessment was limited to a static simulation, A dynamic impact simulation would have been more realistic in a collision case but the tools were not available without paid access. As a result, the safety factor should be treated as an initial indicator. + +\subsubsection{Feasibility of the Final Design} + +The final drone design can be considered feasible in the perspective of a \gls{cad}/simulation led concept. The selected electronics are consistent with the design requirements. The airframe provides a dedicated area for internal components and wiring while ensuring the body remains modular, detachable and easy to manufacture and assemble. + +The final design of the drone hardware is acceptable within the scope of the project. However, the design is not recommended to serve as a final validated prototype as many of the main areas still require proper validation with real-world testing. The main limitations are the lack of physical testing which is vital if we wish to commercialise the product through physical implementation. + +\subsubsection{Simulation Representation of Drone Hardware} + +The final \gls{cad} model was simplified for use in Unity. Given the full Fusion 360 assembly contained many unnecessary mechanical detail for real-time simulation, a low-poly version was created in Blender and imported into Unity as a game asset. The simplified model preserved the main visible features such as the drone body and propellers, while small details such as bolt holes and linkages were removed. These were deemed unnecessary as Unity's built-in collision mechanisms and physics engine mainly uses approximated cuboid or spherical boundaries defined by the developer, and developing a custom solid-boundary model would require additional setup time without adding much value. (A model of the simplified drone is shown in Fig.~\ref{fig:BlenderDrone}) + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.50\textwidth]{Blender Drone.png} + \caption{Blender Drone} + \label{fig:BlenderDrone} +\end{figure} + + +\subsection{Player Hardware Design} +\label{player_hardware} + +The player hardware shows how human players would interact with the multiagent laser tag system. These components were not developed in great detail compared to the drone hardware, and therefore we will only focus on illustrative models to represent their general way of operation, as shown in Fig.~\ref{fig:Player Vest and Helmet}. + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.70\textwidth]{Hardware/Player Hardware.png} + \caption{Player Vest and Helmet} + \label{fig:Player Vest and Helmet} +\end{figure} + +\paragraph{Vest} + +The vest is used as the main hit-detection surface for the player. The intended design is to have \gls{ir} receiver modules positioned throughout the vest in high density so the drone can target. The receivers would be distributed across the front, back, and sides of the vest so that hits can be detected from multiple directions during game-play. The vest should be lightweight but also ideally provide some protection against potential physical impacts such as player collisions. A compartment acting as an electronics box may house all required electronics including micro-controller, wiring, and wireless modules. A small display or \gls{led} indicator area can be included to show simple feedback such as team status and player status. + +\paragraph{Helmet} + +The helmet provides an upper-body hit detection area and improved \gls{ir} coverage around the player. Similar to the vest, \gls{ir} receivers will be positioned around the helmet surface so the signals can be detected. Again, a compartment will house all the required electronics and circuitry for the hit-detection and status updates. The helmet also acts as an additional protective element, alongside the overhead net, against falling drones and other collisions. + +\paragraph{Laser Tagging Device} + +The equipment for tagging used by players is proposed to be a handheld \gls{ir} tagging device. Its purpose would be to allow players to tag drones with a trigger. The device would likely contain a compartment with all required electronics just as the other player hardware. As stated before, all tagging systems will be using \gls{ir} rather than actual lasers for safety and regulatory reasons. + +%%%%%%%%%----------------end of Hardware---------------%%%%%%%%% + +\newpage + + \section{Drone State Estimation} \label{drone state estimation} % Tommy +\fancyhead[C]{Thomas August} % + +Our drones fly autonomously and hence need to know their state, including position, $\mathbf{p}$, orientation, $\mathbf{q}$, velocity, $\mathbf{v}$, angular velocity, $\boldsymbol{\omega}$, and acceleration, $\mathbf{a}$, in order to control their movement through the map. +%The output rate of this state estimator should be at least 50Hz in order to be compatible with all of our control algorithms. + +\subsection{Chosen Method} +In order to determine the best method for estimating the state of our drones, we first conducted some research in the field to determine what the common methods were. From this research, we found three main methods: offboard optical motion capture, cameras with AprilTags, and onboard sensor fusion with a state estimator. + +\paragraph{Optical Motion Capture} This method is the standard for measuring ground truth robot states and has millimeter accuracy \cite{liu2018viconmavlinksoftwaretoolindoor}. However, there are a number of issues with this method for our application. Firstly, with our maze based map design, we would need many of these cameras to cover the whole map. Assuming we need one for each grid cell, 187 would be needed for our whole map. Optitrack is a company that sells these optical motion capture cameras, and their cheapest standard camera is the Prime x 13 \cite{Prime13Optitrack} which they sell for \$2,499, meaning the total cost for just the cameras would be \$467,313, which is well above our budget. Additionally, these cameras transmit a large amount of infrared (IR) light at a similar frequency to that used by our laser guns and hence would cause a lot of interference with our shot detection system. These cameras also only have a limited field of view, so if we mounted them on the ceiling, there would be blind spots near the ceiling between them where the drone is outside the field of view of all cameras, and hence its state can not be estimated. For these reasons, we decided not to use this method. + +\paragraph{Cameras with AprilTags} Another method for estimating the state of the drones is to use cameras to detect their position relative to AprilTags. This can either be done with AprilTags on the drone and cameras around the map or AprilTags around the map and cameras on the drone. The former option would produce higher latency due to the cameras and state estimation processing being offboard, so the latter option is preferred. Pandey et al. \cite{aprilTagStateEstimation} conducted a study on the effectiveness of the latter method and found that the system had an AprilTag detection rate of 95\% in bright light conditions, however this dropped to 80\% in low light conditions, so in the dark conditions of our arena the detection rate would likely be even lower than this. Additionally, this method would require very accurate placement of many AprilTags around the arena, increasing the difficulty and time required to setup the arena. Due to these reasons, we decided not to use this method either. + +\paragraph{Onboard Sensor Fusion} This method uses a combination of onboard sensors to estimate and track the drone's state within the arena. Due to this method being fully onboard, it will have low latency and no special arena setup, and hence is the simplest of these three options which is why we chose this method. This method is very broad, so we next needed to choose the sensors and state estimator. + +\subsection{Sensor Array} +For the sensors, we chose to use an \gls{imu} with \gls{tof} sensors. We chose these because the \gls{imu} provides accurate angular velocity and acceleration data which can be used to infer the motion of the drone and the \gls{tof} sensors provide map geometry data to correct for drift in the \gls{imu} estimations. In this situation, it is common to use an \gls{imu}, however, there are many different sensors that can provide the map geometry data. We also considered using cameras and \gls{lidar} instead of the \gls{tof} sensors, however, the cameras will likely have poor performance in our dark lighting conditions, and \gls{lidar} sensors would be heavy and bulky, so we chose \gls{tof} sensors as a compromise between weight and accuracy. + +\subsection{Sensor Measurements} +\paragraph{\gls{imu}} Our chosen \gls{imu}, the SparkFun ICM-20948 \gls{imu} \cite{sparkfun_icm20948}, includes a 3-axis accelerometer, a 3-axis gyroscope, and a 3-axis magnetometer. Due to our arena being in a warehouse, there will likely be significant distortion of the earths magnetic field, and hence we will use the \gls{imu} in mode 6, Accel + Gyro Mode, which saves power by turning the magnetometer off. This means that our \gls{imu} will output 3-axis angular velocity from the gyroscope, and 3-axis acceleration from the accelerometer. Additionally, the gyroscope and accelerometer each have their own operational modes, and we have chosen to run them both in low noise mode with the digital low pass filter activated (GYRO\_FCHOICE=1 and ACCEL\_FCHOICE=1). We will tune configuration of the digital low pass filter cut-off frequencies (GYRO\_DLPFCFG and ACCEL\_DLPFCFG) experimentally to achieve the optimal noise and response trade-off. These modes both have a base \gls{dor} of 1.125kHz, however, to reduce computational load, we set the sample rate division parameters to 1 (GYRO\_SMPLRT\_DIV=1 and ACCEL\_SMPLRT\_DIV=1) in order to reduce the \gls{dor} to 562.5Hz using Eq.\ref{equ:EstSMPLRT_DIV} below. This allows us to reduce the computational load while still keeping the \gls{dor} much higher than our state estimation \gls{dor} of 50Hz. + +\begin{equation} \label{equ:EstSMPLRT_DIV} + \mathrm{DOR} = \frac{1125}{1 + \mathrm{SMPLRT\_DIV}} +\end{equation} + +\paragraph{\gls{tof}} +Our drone is equipped with two different types of \gls{tof} sensors. As mentioned in Section \ref{sensorArray}, we will have a single VL53L1X \gls{tof} sensor \cite{st_vl53l1x} mounted on the top of the drone pointing upwards, and four VL53L5CX \gls{tof} sensors \cite{st_vl53l5cx} mounted on each side of the drone pointing horizontally outwards. The vertical \gls{tof} sensor is a single beam sensor, however the horizontal sensors produce multizone distance measurements which can be configured in two modes: 8x8 15Hz and 4x4 30Hz. Since our map geometry is simple, the 4x4 array of 16 measurements will be enough to reliably estimate the position of the surrounding walls, and hence we chose the 4x4 30Hz mode, providing a higher measurement rate. The single beam \gls{tof} sensors can output readings up to 50Hz, however, we will reduce this to 30Hz to synchronise all \gls{tof} sensors. + +\subsection{Acceleration Modelling} \label{StateEstimatorAccelModel} + +It is a common approximation for drone attitude estimation systems to assume that the accelerometer measurement is dominated by gravity and hence use the normalised reading as an approximation for the world z axis expressed in the body frame, as is done by Mahony et al. \cite{4608934}. In our system, specifically the movement mode, there may be large accelerations causing this assumption to break down. To avoid errors from this assumption and allow us to extract information about both the orientation and acceleration of the drone from the accelerometer reading, we decided to use a model based approach to predicting the acceleration. + +Our model uses the motor commands and estimated velocity to compute the thrust acceleration, $\mathbf{a}_{T,k}$, and drag acceleration, $\mathbf{a}_{D,k}$, in the body frame. These are then transformed into the world frame using the estimated orientation quaternion, $\mathbf{q}_k$, and combined with the acceleration due to gravity, $g$, to obtain an estimate for the body acceleration in the world frame, $\mathbf{a}_{m,k}$, as +\begin{equation} \label{equ:EstAccelModel} + \mathbf{a}_{m,k} = \mathbf{R}(\mathbf{q}_k)(\mathbf{a}_{T,k} + \mathbf{a}_{D,k}) + \begin{bmatrix} + 0 & 0 & -g + \end{bmatrix}^\top +\end{equation} +where $\mathbf{R}(\mathbf{q}_k)$ is the rotation matrix associated with quaternion $\mathbf{q}_k$, and $k$ is the discrete time step. + +Since the motor angular velocity, $\omega_{\mathrm{motor},k,i}$, cannot be measured directly, the thrust generated by each motor, $T_{k,i}$, is estimated using the \gls{esc} control command, $c_{k,i}$. Assuming that the motor angular velocity is proportional to the \gls{esc} command, $\omega_{motor,k,i} \propto c_{k,i}$, and that the thrust is proportional to the square of the motor angular velocity, $T_{k,i} \propto \omega_{motor,k,i}^2$, the thrust produced by each motor can be modelled as +\begin{equation} \label{equ:ActuatorThrustModel} + T_{k,i} = k_{T,k,i} \, c_{k,i}^{2} +\end{equation} +where $k_{T,k,i}$ is the thrust coefficient associated with the $i^{\mathrm{th}}$ motor-propeller pair. The total thrust is then the sum of the motor thrusts, however the thrust coefficients should be almost identical, so we factor them out of the sum, giving the total thrust as +\begin{equation} + T_{k} = \sum_i^4 T_{k,i} = \sum_i^4k_{T,k,i} \, c_{k,i}^{2} = k_{T,k} \sum_i^4 \, c_{k,i}^{2} = k_{T,k}\mathbf{c}_{k} \cdot \mathbf{c}_{k} +\end{equation} +The thrust coefficient, $k_{T,k}$, is estimated online, with a pre-computed estimate used to initialise the estimator, in order to compensate for inaccuracy in our pre-calculation and time-varying propeller dynamics, such as thrust reductions due to battery depletion or motor heating. Finally, we calculate the acceleration from this thrust using the mass of the drone, $m$, which will be measured before deployment. +\begin{equation} \label{equ:EstThrustAccel} + \mathbf{a}_{T,k} = \frac{1}{m} \begin{bmatrix} 0 & 0 & T_k \end{bmatrix}^\top = \frac{k_{T,k}}{m}\mathbf{c}_{k} \cdot \mathbf{c}_{k} \begin{bmatrix} 0 & 0 & 1 \end{bmatrix}^\top +\end{equation} +To estimate the acceleration due to drag in the body frame, $\mathbf{a}_{D,k}$, the velocity is first expressed in the body frame, $\mathbf{v}_{b,k}$, by transforming the world frame velocity, $\mathbf{v}_k$, using the orientation quaternion, $\mathbf{q}_k$. Assuming the drag acceleration is proportional to the square of the velocity in each body axis direction and acts opposite to the direction of motion, the drag acceleration can be modelled as +\begin{equation} \label{equ:EstDragAccel} +\mathbf{a}_{D,k} += +-\mathbf{k}_{D,k} +\odot +|\mathbf{v}_{b,k}| +\odot +\mathbf{v}_{b,k}, +\quad +\text{where} +\ \ \ +\mathbf{v}_{b,k} = \mathbf{R}^\top(\mathbf{q}_k)\mathbf{v}_k. +\end{equation} +where $\mathbf{k}_{D,k}$ denotes the drag coefficients which are estimated online to compensate for uncertainties in the initial values. Ideally we would use a wind tunnel to estimate the initialisation values, however this would be costly, so instead we will roughly estimate these values and and analyse their converged values during a controlled system test. + +\subsection{State Parameters} + +Our state estimator now needs to estimate the parameters needed for control as well as the acceleration model parameters, however, the gyroscope and accelerometer may each have a bias, $\mathbf{b}_g$ and $\mathbf{b}_a$ respectively, which would cause significant drift in the position, orientation and velocity, if not accounted for, because our only way of obtaining these values from the \gls{imu} data is to integrate the angular velocity and acceleration. To account for this we will include the biases in the state as well, because these may change slightly over time. Considering everything mentioned above, the full state of our estimator is: $[\mathbf{p}, \mathbf{q}, \mathbf{v}, \boldsymbol{\omega}, \mathbf{a}, \mathbf{b_g}, \mathbf{b_a}, \mathbf{k_D}, k_{T}]$. All parameters except $k_{T}$ in the state are 3 parameter vectors\footnote{The orientation will be represented as a unit quaternion which has 4 values, but the unit condition reduces this to 3 degrees of freedom.}, so we have 25 parameters to estimate. + +\subsection{Estimation Method} + +We initially considered two different estimators, \gls{pf} and an \gls{ekf}\footnote{We specifically looked at using an \gls{ekf} rather than a regular \gls{kf} because some of our system dynamics, such as the acceleration model, involve non-linear components that cannot be accurately estimated by a regular \gls{kf}.}. + +The \gls{pf} would facilitate a multi-modal belief of the state which is specifically necessary for the position and yaw, because the belief of these parameters will mostly come from the \gls{tof} sensor readings which can produce similar readings for multiple locations on our map due to its simplicity. Although it is not ideal to have a multi-modal belief, it is important to have the ability to maintain this while the estimate is converging to avoid rejecting the true state early on. Using a \gls{pf} to estimate such a large number of parameters, however, is not feasible as it necessitates distributing the particles across all 25 parameter dimensions which would require a large number of particles and a large computational cost to cover even a small range of the parameters. + +The \gls{ekf} would facilitate tracking all 25 parameters with a much lower computational cost as it stores only the mean and covariance matrix of the state and updates this using a few recursive matrix equations. It would also be much more efficient at estimating the approximately Gaussian parameters such as the biases, thrust scale factor, and drag coefficients, however, it would struggle to maintain a good estimate of anything multi-modal such as the position and yaw, as mentioned previously, and it would be sensitive to the initialisation conditions, causing a problem if the state is lost. + +Having considered these methods, it is clear that both have their advantages, however, the disadvantages of each make them infeasible or impracticable, as a result, we looked to other methods. Grisetti et al. \cite{RBPF} suggest using a \gls{rbpf} applied to a simultaneous location and mapping problem, which we can easily alter to solve our localisation and state estimation problem. The \gls{rbpf} method allows us to decompose this state estimation problem into two coupled sub-problems which can each be solved by different methods. This allows us to use a \gls{pf} to estimate the possibly multi-modal position and yaw while using an \gls{ekf} within each particle to estimate the rest of the state, providing us with the benefits of using a particle filter without the need for excessive particles while estimating the approximately Gaussian parameters much more efficiently. + +\subsection{Rao-Blackwellized Particle Filter Setup} + +\paragraph{Overview} The \gls{pf} will use \gls{tof} sensor data to compare with raycasts from the pose of each particle to determine the particle weights at 30Hz, the measurement frequency of the \gls{tof} sensors. These particles will each contain the position, yaw, weight and an \gls{ekf} to estimate all other parameters. They will then be resampled, if the resampling condition is met, by copying the high weighted particles and removing some of the low weighted particles, as detailed below. When copying particles the \gls{ekf} contained within each particle is also copied over. The \gls{imu} measurements occur at a much higher frequency of 562.5Hz and these will be used by the \gls{ekf} to propagate the particles between \gls{pf} updates. An \gls{ekf} consists of two steps, prediction and update. Our \gls{ekf} will use the gyroscope measurements and the acceleration model detailed above for prediction and use the accelerometer measurements for the update. + +\paragraph{Initialisation} Since we know that the drones can only enter the arena from their home base, and we will know exactly what grid square they are entering through, we can initialise the particles to have a Gaussian spread around the centre of that grid square for position and a Gaussian spread around the forwards heading direction for the yaw. Initialising particles in this way exploits our prior knowledge of the drones location and reduces the chance of converging on the wrong mode. If for some reason our prior is wrong, this could lead to immediately rejecting the true state, so we will superimpose a sparse uniform distribution of particles onto this to avoid locking the state into a single mode immediately. For the \gls{ekf} states, we will initialise the position and yaw to that of the particle which owns it and initialise all other states to the same values for all particles. These values will be tuned to minimise conversion time. If for some reason the state is lost during flight, we will initialise particles with a uniform distribution as there will be no prior knowledge of the drones state at that point, and we will initialise the \gls{ekf} state in the same way just mentioned. + +\subsubsection{Particle Filter Update} +The particle filter will update whenever new \gls{tof} readings are received by ray casting from the pose of all particles to produce virtual readings, $\hat{\mathbf{z}}_i = r(\mathbf{p}_i,\mathbf{q}_i)$, where $r(\mathbf{p},\mathbf{q})$ is the ray casting algorithm, and calculating new particle weights, $w_i$, based on their similarity to the actual readings, $\mathbf{z}$, using the Gaussian likelihood equation, Eq. \ref{equ:EstPFWeight}, below, where $\mathbf{R}(\mathbf{z})$ is a diagonal matrix which is a function of $\mathbf{z}$ to represent the variance of the \gls{tof} readings. +\begin{equation}\label{equ:EstPFWeight} + w_i = \exp(-\frac{1}{2}\mathbf{r}_i^\top \mathbf{R}^{-1}(\mathbf{z}) \mathbf{r}_i) \mathrm{\ \ \ where \ \ \ } \mathbf{r}_i = \mathbf{z} - \mathbf{z}_i +\end{equation} +These weights are then normalised by dividing by the sum of all weights. +In order to reduce the computational load and avoid quickly reducing particle diversity and possibly converging on the wrong mode, we chose to not resample the particles at every update, but instead resample when a condition is met. To determine when resampling is necessary, we will monitor the effective sample size, $N_{eff}$, using Eq.\ref{equ:EstPFEffectiveSamples} below and we will resample when this value falls below half of the total number of particles, $N$. +\begin{equation}\label{equ:EstPFEffectiveSamples} + N_{eff} = \frac{1}{\sum_i w_i^2} +\end{equation} +To resample the particles, we partition the range $[0,1]$ into segments of length equal to the weight of each particle, for example, the first particle would span the range $[0,w_1]$. Next, a random number from 0 to 1 is generated and the particle whose segment contains that value is copied to make the new particle and this is repeated N times to sample a full set of new particles. All particle weights are then set uniform again, $w_i = 1/N$, because the belief is now represented by the number of particles at each location rather than the weight of individual particles. This means there may now be identical particles, however these will diverge due to the random nature of the \gls{ekf} allowing exploration from the mode. The particle which had the highest weight before resampling is flagged as the \gls{map} estimate and the output of the state estimator will be the mean state of all children of this particle. In the extremely rare case that this particle has no children, we will fall back to the children of the particle which had the second highest weight before resampling and so on. + +\subsubsection{Extended Kalman Filter Update} +The \gls{ekf} will update whenever new \gls{imu} data is received. We will use the model and recursive update in Eq.\ref{equ:EstEKFStateTransition}-\ref{equ:EstEKFUpdateMeasurementCov} below, adapted from the regular KF equations on pg 210 of the Engineering Tables and Data 4th Edition \cite{HLT} with matrices $\mathbf{A}$ and $\mathbf{B}$ replaced by non-linear function $f$ and matrix $\mathbf{C}$ replaced by non-linear function $h$. +\begin{align} + \mathbf{x}_{k+1} & = f(\mathbf{x}_k,\mathbf{u}_k) + \mathbf{w}_k \label{equ:EstEKFStateTransition} \\ + \mathbf{y}_k & = h(\mathbf{x}_k) + \mathbf{v}_k \label{equ:EstEKFMeasurements} +\end{align} +\vspace{-1.5cm} +\begin{align} + \mathrm{Dynamics\ Jacobian: \ } \mathbf{F}_{k} & = \left. \frac{\partial f}{\partial \mathbf{x}} \right|_{\hat{\mathbf{x}}_{k|k}, \mathbf{u}_k}\label{equ:EstEKFDynamicsJacobian} \\ + \mathrm{Measurement\ Jacobian: \ } \mathbf{H}_k & = \left. \frac{\partial h}{\partial \mathbf{x}} \right|_{\hat{\mathbf{x}}_{k|k-1}} \label{equ:EstEKFMeasurementJacobian} +\end{align} +\vspace{-1.5cm} +\begin{align} + \mathrm{Process\ Noise\ Covariance: \ } \mathbf{Q} = \mathrm{E}[\mathbf{w}_k \mathbf{w}_k^\top] \label{equ:EstEKFProcessNoiseCov} \\ + \mathrm{Measurement\ Noise\ Covariance: \ } \mathbf{R} = \mathrm{E}[\mathbf{v}_k \mathbf{v}_k^\top] \label{equ:EstEKFMeasurementNoiseCov} +\end{align} +\vspace{-1.5cm} +\begin{align} + \hat{\mathbf{x}}_{k|k-1} & = f(\hat{\mathbf{x}}_{k-1|k-1},\mathbf{u}_{k-1}) \label{equ:EstEKFUpdatePredictionState} \\ + \mathbf{P}_{k|k-1} & = \mathbf{F}_{k-1} \mathbf{P}_{k-1|k-1} \mathbf{F}_{k-1}^\top + \mathbf{Q} \label{equ:EstEKFUpdatePredictionCov} \\ + \mathbf{S}_k & = \mathbf{H}_k \mathbf{P}_{k|k-1} \mathbf{H}_k^\top + \mathbf{R} \label{equ:EstEKFUpdateMeasurementS} \\ + \mathbf{K}_k & = \mathbf{P}_{k|k-1} \mathbf{H}_k^\top \mathbf{S}_k^{-1} \label{equ:EstEKFUpdateMeasurementK} \\ + \mathbf{r}_k & = \mathbf{y}_k - h(\hat{\mathbf{x}}_{k|k-1}) \label{equ:EstEKFUpdateMeasurementResidual} \\ + \hat{\mathbf{x}}_{k|k} & = \hat{\mathbf{x}}_{k|k-1} + \mathbf{K}_k \mathbf{r}_k \label{equ:EstEKFUpdateMeasurementState} \\ + \mathbf{P}_{k|k} & = (\mathbf{I} - \mathbf{K}_k \mathbf{H}_k) \mathbf{P}_{k|k-1} \label{equ:EstEKFUpdateMeasurementCov} +\end{align} + +To use these equations, we need to define all parameters in the model, Eq. \ref{equ:EstEKFStateTransition} and \ref{equ:EstEKFMeasurements}. Process noise covariance, $\mathbf{Q}$, and measurement noise covariance, $\mathbf{R}$, will be estimated experimentally before deployment and are assumed constant. The state, $\mathbf{x}_k$, input, $\mathbf{u}_k$, and measurement, $\mathbf{y}_k$, vectors are defined below in Eq.\ref{equ:EstEKFStateVector}, \ref{equ:EstEKFInputVector}, and \ref{equ:EstEKFMeasurementVector} respectively, where $\boldsymbol{\omega}_{r,k}$ is the gyroscope reading, $\mathbf{c}_k$ is the motor \gls{esc} commands, and $\mathbf{a}_{r,k}$ is the accelerometer reading. Functions $f$ and $h$ are defined below in Eq.\ref{equ:EstEKFf} and \ref{equ:EstEKFh}. In function f we: assume acceleration is constant over the sampling period, $\Delta t$, to update position and velocity, use the quaternion derivative defined by Sol\'{a} (pg 46) \cite{quaternionDerivative}, Eq.\ref{equ:EstSolaQuatDerivative}, to update the quaternion orientation, subtract the bias from the gyroscope reading to update the angular velocity, use the model equations, Eq.\ref{equ:EstAccelModel}-\ref{equ:EstDragAccel}, to update the acceleration using the state and inputs, and keep the remaining parameters unchanged and allow them to evolve through a random walk. In function h, we transform the estimated acceleration into the body frame and combine this with the upwards gravity vector and the accelerometer bias to produce the expected measurement. + +\begin{align} + \mathbf{x}_k & = \begin{bmatrix}\mathbf{p}_k^\top, \mathbf{q}_k^\top, \mathbf{v}_k^\top, \boldsymbol{\omega}_k^\top, \mathbf{a}_k^\top, \mathbf{b}_{g,k}^\top, \mathbf{b}_{a,k}^\top, \mathbf{k}_{D,k}^\top, k_{T,k}^\top\end{bmatrix}^\top \label{equ:EstEKFStateVector} \\ + \mathbf{u}_k & = \begin{bmatrix} \boldsymbol{\omega}_{r,k}^\top, \mathbf{c}_k^\top\end{bmatrix}^\top \label{equ:EstEKFInputVector} \\ + \mathbf{y}_k & = \mathbf{a}_{r,k} \label{equ:EstEKFMeasurementVector} +\end{align} + +\begin{equation} \label{equ:EstEKFf} + f(\mathbf{x}_k,\mathbf{u}_k) = \begin{bmatrix} + \mathbf{p}_k + \mathbf{v}_k \Delta t + \frac{1}{2} \mathbf{a}_k \Delta t ^2 \\ + \mathbf{q}_k + \frac{1}{2}\boldsymbol{\Omega}(\boldsymbol{\omega_{r,k}})\mathbf{q}_k \\ + \mathbf{v}_k + \mathbf{a}_k \Delta t \\ + \boldsymbol{\omega}_{r,k} - \mathbf{b}_{g,k}\\ + \mathbf{a}_{m,k} \\ + \mathbf{b}_{g,k} \\ + \mathbf{b}_{a,k} \\ + \mathbf{k}_{D,k} \\ + k_{T,k} + \end{bmatrix} +\end{equation} +where $\mathbf{a}_{m,k}$ is the model predicted acceleration calculated using Eq.\ref{equ:EstAccelModel}-\ref{equ:EstDragAccel} and $\boldsymbol{\Omega}(\boldsymbol{\omega})$ is defined in Eq.\ref{equ:EstSolaQuatDerivative}. + +\begin{equation}\label{equ:EstEKFh} + h(\mathbf{x}_k) = \mathbf{R}^\top(\mathbf{q}_k)\mathbf{a}_k + [0 \ 0 \ g]^\top + \mathbf{b}_{a,k} +\end{equation} + +\begin{equation}\label{equ:EstSolaQuatDerivative} + \dot{\mathbf{q}} = \frac{1}{2} \boldsymbol{\Omega}(\boldsymbol{\omega})\mathbf{q} + \quad + \text{where} + \ \ \ + \boldsymbol{\Omega}(\boldsymbol{\omega}) = \begin{bmatrix} + 0 & -\omega_x & -\omega_y & -\omega_z \\ + \omega_x & 0 & \omega_z & -\omega_y \\ + \omega_y & -\omega_z & 0 & \omega_x \\ + \omega_z & \omega_y & -\omega_x & 0\\ + \end{bmatrix} +\end{equation} + + + + + + +\newpage + +\section{Network and Communications} +\label{network} +\fancyhead[C]{Richard Usherwood} +\subsection{Overview} +% Define N&C? +Network and communications are not strictly necessary for a single wave of the game. Without them, each drone would act according to 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. Advantages of this approach include: +\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 point of failure 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. Advantages of this approach include: +\begin{itemize} + \item Reduced Complexity: coordinating the movement of many drones is much easier when all information is available centrally. + \item Hardware Costs: if the central high-level decision making is performed in a central server, rather than locally on the processer of each drone, not only will a lower-powered processor be needed in the drone, but a smaller battery will be needed to power it, so less powerful motors will be required to lift the battery, and so on, decreasing hardware costs. +\end{itemize} +Considering the pros and cons listed above, it was decided that a central server was the most appropriate option to perform high-level decision making. Different methods of handling communications between the drones and the server are discussed below. + +\subsection{Bluetooth} +Bluetooth is a short-range wireless communication system, designed for low-power device-to-device communication. It uses 79 channels, 1MHz apart, from 2.402 to 2.480 GHz. Data is encoded by changes in frequency. Classic Bluetooth uses Frequency Hopping Spread Spectrum (FHSS), switching between frequency channels to reduce interference, with Gaussian Frequency Shift Keying (GFSK) modulation. In a connection, one device acts as a \say{main}, and up to seven devices act as \say{followers}. Time-Division-Duplexing is used to avoid collisions. Time is divided into 625 \(\mu\)s divisions. The main communicates in even slots, and the followers communicate in odd slots. + +\(\)\newline A Bluetooth connection uses very little power. However, it has a lower bitrate than a Wi-Fi connection (1-3 Mbps). It also has a shorter intended range than a Wi-Fi connection. Furthermore, the maximum number of seven followers connected to a single main would pose a problem since it will be necessary for up to 10 drones to be connected to the server at a time, requiring an additional main, to manage communication for some drones. This would be possible, but inconvenient and less robust. + +\subsection{Wi-Fi} +Wi-Fi is a medium-range wireless communication system, designed for fast and reliable server-to-device communication. It typically operates at \(\textasciitilde\)2.4 GHz, \(\textasciitilde\)5 GHz or \(\textasciitilde\)6 GHz, transferring data over multiple (up to 60) non-overlapping channels of bandwidth 20 MHz, modulated using Orthogonal Frequency Division Multiplexing (OFDM). + +\(\) \newline A Wi-Fi connection typically has a lower latency than a Bluetooth connection. It also has a much higher maximum bitrate, however the required data rate is small enough that this will not be important. Wi-Fi is generally more reliable than Bluetooth, especially 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 higher bandwidth connections between many devices. + +\(\)\newline For these reasons, Wi-Fi was 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, which has Wi-Fi capability (discussed in section~\ref{comms}). + +\newpage +\section{High Level Control} \label{high level control} % Ritchie +\fancyhead[C]{Richard Usherwood} % Ritchie +\subsection{Context} +The objective of the High Level Control Protocol is to define algorithms that 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 by splitting the drones' behaviour into several \say{modes}, in which some information storage and computation is performed in the server, and transmitted to the drones via Wi-Fi, and some information storage and computing is performed onboard the drone. + + +\subsection{Drone Modes} +A set of drone \say{modes} or \say{states}, describing the drone's high-level behaviour, has been defined. They are: +\begin{multicols}{2} +\begin{itemize} + \item Dormant Mode + \item Search Mode + \item Movement Mode + \item Track Mode + \item Shoot Mode + \item Collision Avoidance Mode +\end{itemize} +\end{multicols} +\noindent An overview of the purpose 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. This mode is activated when a round end, or when the drone is powered on. +\subsubsection{Search Mode} +This is the initial mode of a drone entering a game. In this mode, the drone explores 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 Fig.~\ref{fig:FlowSearch}. +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/High-Level/SearchMode19.png} + \caption{Flow Chart Describing Mode Changes, centred on Search Mode} + \label{fig:FlowSearch} +\end{figure} +\subsubsection{Track Mode} +The drone enters this mode when it has seen a human player who is not within shooting range. 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 Fig. \ref{fig:FlowTrack}. +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/High-Level/TrackMode19.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 a player is within its shooting range. 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 Fig. \ref{fig:FlowShoot}. +\begin{figure}[htbp] + \centering + \includegraphics[width=0.5\linewidth]{figs/High-Level/ShootMode19.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 \say{called for help}. A \say{call for help} is generated when a drone detects that more than one player is within its shooting range. This mode can only be reached from Search Mode. +\subsubsection{Collision Avoidance Mode} +This mode is triggered either when the drone detects it is about to collide into a wall, the ceiling or the safety net, 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 Fig. \ref{fig:FlowSearch}, \ref{fig:FlowTrack} and \ref{fig:FlowShoot} are sections of a larger flowchart describing the state change logic of the drones, included 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 decision boxes: \say{Am I about to crash?} and \say{Has the wave ended?}. + + +\newpage +\fancyhead[C]{Rishabh Luthra} +\section{Visual Perception and Player Tracking} % Rishabh +\label{visual_perception} +\subsection{Context} + +The fundamental objective of the autonomous multiagent system is to compete actively against human players in a dynamic environment. To play the game effectively, the drones require a reliable way to identify and track opponents whilst navigating through the maze. 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 locate the targets continuously, 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} + +\subsection{Sensor Selection} % Rishabh +\label{Sensor Selection} +% 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 [done] +% - add distance measurements into inline equations [not needed] +% - check acronyms like rgb +% - section on Unity simulation environment (map generation, why Unity is beneficial, reference synthetic data generation) [not needed] +% - 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 \cite{underactuated}; 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. The gimbal hardware is detailed in Section \ref{Turret}. + +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~\cite{slamtec_rplidar_a1, orbbec_astra_mini_pro, oakd_lite_specs, raspberrypi_ai_camera}} + \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 \gls{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 \gls{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 weighs 24~g and draws less than 1.5~W. 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_\text{prior}$) is constant. The distance $Z$ is then calculated using the focal length ($f$) and the pixel area of the bounding box ($A_\text{px}$): +\begin{equation} + Z = f \cdot \sqrt{\frac{A_\text{prior}}{A_\text{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_\text{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 \gls{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 whilst 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_\text{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 \gls{ir} 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 1920$\times$1080 resolution, with a 60$^\circ$ \gls{fov}, a focal length of 935.31~px, and a stereo baseline of 0.075~m. We used a cuboid measuring 0.5~m wide, 1.8~m tall, and 0.2~m deep to represent an average player. The objective was to observe how both camera architectures respond to changes in the target across three scenarios. + +\newpage + +\begin{figure}[htbp] + \centering + \includegraphics[width=0.65\linewidth]{figs/DepthEstimationTests.png} + \caption{Overview of the experimental setup comparing monocular and stereo depth estimation under geometric transformations.} + \label{fig:depth_estimation_test} +\end{figure} + + +\textbf{(i) Linear Movement} + +We began with a baseline calibration and translated the target linearly from 5~m to 15~m along the Z-axis. Within this scenario, the target's physical dimensions and orientation remained fixed. As demonstrated in Fig. \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.4\linewidth]{figs/LinearTranslation_Plot.png} + \caption{Comparison of monocular and stereo depth estimation against physical ground truth during linear translation from 5~m to 15~m.} + \label{fig:linear_translation} +\end{figure} + +\textbf{(ii) 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 simulated 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.1~m centroid, the physical ground truth, which is represented by the closest physical surface, shifts from 5.0~m down to 4.85~m. + +As illustrated in Fig. \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~m centre of mass and as the rotation reaches 90$^\circ$, the camera's view is restricted to the 0.2~m side profile and this causes the stereo centroid calculation to fall to the 4.85~m 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.85\linewidth]{figs/YawRotation_Plot.png} + \caption{Comparison of depth estimation models during target yaw rotation from 0$^\circ$ to 90$^\circ$ at a nominal 5~m depth.} + \label{fig:yaw_rotation} +\end{figure} + +\textbf{(iii) 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 Fig. \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 highly resistant 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.85\linewidth]{figs/CrouchDeformation_Plot.png} + \caption{Comparison of depth estimation models during crouching at a constant physical depth.} + \label{fig:crouch_deformation} +\end{figure} + +Consequently, the passive stereoscopic system is selected. While the monocular camera presents a favourable \gls{swapc} profile, its area-based depth estimation cannot reliably distinguish between changes in target posture, orientation, or physical depth. The passive stereo system resolves this via horizontal pixel disparity ($d$), providing a stable depth estimate without \gls{ir} interference. + + +\subsection{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 (Fig. \ref{fig:pipeline_diagram}). + +\begin{figure}[htbp] + \centering + + \begin{subfigure}[b]{\textwidth} + \centering + \includegraphics[width=0.65\textwidth]{figs/sensor_pipeline.pdf} + \caption{} + \label{fig:pipeline_diagram} + \end{subfigure} + + \vspace{0.75cm} + + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=0.8\textwidth]{figs/1_RGB.png} + \caption{} + \label{fig:rgb_data} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=0.8\textwidth]{figs/2_DepthMap.png} + \caption{} + \label{fig:depth_data} + \end{subfigure} + + \caption{Perception system overview showing: (\subref{fig:pipeline_diagram}) the sensor fusion architecture data flow, (\subref{fig:rgb_data}) the monocular RGB stream with a ground truth bounding box, and (\subref{fig:depth_data}) the synchronised depth map with a projected bounding box.} + \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. + +For this task, the YOLOv8-nano (YOLOv8n) architecture~\cite{ultralytics_yolov8} was selected. As the variant with the lowest parameter count, its streamlined size is explicitly suited for deployment on the drone's limited onboard hardware. \gls{yolo} ensures low-latency detection by evaluating the image in a single computational pass, which is required to keep the flight control loops responsive. Furthermore, the architecture's maturity, combined with its extensive Python support and documentation, provides a reliable and efficient pipeline for training, single-class fine-tuning, and deployment. + +To achieve the second objective, the system performs sensor fusion. The predicted 2D bounding box defines a region of interest (Fig. \ref{fig:rgb_data}), which is projected onto the synchronised stereo disparity map (Fig. \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 Fig. \ref{fig:perception_system_overview} were generated within the Unity simulation environment, 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} + + +\subsection{Data Preprocessing} +To accelerate the training process, we utilised a pre-trained \gls{yolo} model initialised using baseline weights on the \gls{coco} dataset~\cite{Lin2014MicrosoftCC}. 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~\cite{Zhu2020DetectionAT} 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. + +\subsection{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~\cite{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 Fig. \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 learned the dataset's features with no obvious 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 (Fig. \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.249. 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 sample labelled image (Fig. \ref{fig:visdrone}), the human targets occupy only a few pixels in area due to the high-altitude aerial perspective. However, 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 this task. Table \ref{tab:visdrone_baseline} summarises the training results for the VisDrone baseline model. + +% \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} + +\begin{table}[htbp] + \centering + \caption{Baseline YOLOv8n Training and Evaluation Metrics} + \label{tab:visdrone_baseline} + \begin{tabular}{@{}llc@{}} + \toprule + \textbf{Category} & \textbf{Parameter / Metric} & \textbf{Value} \\ + \midrule + \textbf{Dataset Parameters} & Dataset Source & VisDrone2019-DET~\cite{Zhu2020DetectionAT} \\ + & Target Classes Filtered & Person, Pedestrian \\ + & Training Set Size & 6,471 images \\ + & Validation Set Size & 548 images \\ + & Input Image Resolution & 640 $\times$ 640 pixels \\ + \midrule + \textbf{Training Conditions} & Base Model & YOLOv8-nano \\ + & Total Epochs & 50 (Early Stopping Patience: 10) \\ + & Batch Size & 32 \\ + & Optimiser & AdamW \\ + & Initial Learning Rate & 0.000714 \\ + & Hardware / GPU & NVIDIA Tesla T4 (15~GB VRAM) \\ + \midrule + \textbf{Validation Results} & Precision (P) & 0.636 \\ + & Recall (R) & 0.450 \\ + & Mean Average Precision (mAP@50) & 0.492 \\ + & Mean Average Precision (mAP@50-95) & 0.190 \\ + & Average Inference Time & 2.9~ms \\ + \bottomrule + \end{tabular} +\end{table} + +\subsection{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{} + \label{fig:env_daylight} + \end{subfigure} + \begin{subfigure}[b]{0.325\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/env_lowlight.png} + \caption{} + \label{fig:env_lowlight} + \end{subfigure} + + \caption{Visual comparison of the simulated lighting environments used during the automated orbital benchmark, illustrating (\subref{fig:env_daylight}) daylight conditions and (\subref{fig:env_lowlight}) low-light conditions.} + \label{fig:orbital_benchmarks} +\end{figure} + +The following 2D graphs flatten the 3D hemispherical sweeps shown in Fig. \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.png} + \caption{} + \label{fig:daylight_confidence} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Light_Classification.png} + \caption{} + \label{fig:daylight_classification} + \end{subfigure} + + \caption{Orbital benchmark under daylight conditions showing (\subref{fig:daylight_confidence}) the confidence score distribution and (\subref{fig:daylight_classification}) the TP / FP / FN categorisation.} + \label{fig:benchmark_daylight} +\end{figure} + +Under daylight conditions (Fig. \ref{fig:benchmark_daylight}), the model demonstrates consistent 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 suggests that the lighting and geometric properties of the Unity simulation are sufficiently realistic for baseline evaluation, as a network trained on real-world data successfully detected the synthetic target. + + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Dark_Confidence.png} + \caption{} + \label{fig:benchmark_lowlight_confidence} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/VisDrone_F_Dark_Classification.png} + \caption{} + \label{fig:benchmark_lowlight_classification} + \end{subfigure} + + \caption{Orbital benchmark under low-light conditions showing (\subref{fig:benchmark_lowlight_confidence}) the confidence score distribution and (\subref{fig:benchmark_lowlight_classification}) the TP / FP / FN categorisation.} + \label{fig:benchmark_lowlight} +\end{figure} + +In contrast, testing under low-light conditions (Fig. \ref{fig:benchmark_lowlight}) reveals a clear limitation in the model. The confidence contour map (Fig. \ref{fig:benchmark_lowlight_confidence}) shows generally low prediction certainty across the grid. The classification scatter plot (Fig. \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. + +\subsection{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.png} + \caption{Sample of the generated synthetic dataset. Panels (a)–(f) illustrate variations 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{} + \label{fig:raycast_scene} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/RaycastGameView.png} + \caption{} + \label{fig:raycast_game} + \end{subfigure} + \caption{Visualisation of the automated annotation and occlusion logic. (a) The 3D spatial environment demonstrating the raycasts, where red lines indicate vertices blocked by physical cover. (b) The corresponding 2D rendered frame, demonstrating bounding boxes that encapsulate only the unoccluded geometry.} + \label{fig:raycast_validation} +\end{figure} + +\newpage + +\subsection{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 metrics were monitored across the 50 epoch run. The resulting loss and performance curves are detailed in Fig. \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} +% maybe a comment on the 40-epoch drop but perhaps best made for the visdrone training and a brief mention here + +The simultaneous descent of both training and validation losses suggests stable convergence and indicates no obvious overfitting to the synthetic data. 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 (Fig. \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.95 at a confidence threshold of 0.508. 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.508 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 (Fig. \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} + + +\subsection{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 Fig. \ref{fig:benchmark_synthetic_lowlight}. The confidence score distribution (Fig. \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 (Fig. \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.png} + \caption{} + \label{fig:benchmark_synthetic_lowlight_confidence} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/Synthetic_F_Dark_Classification.png} + \caption{} + \label{fig:benchmark_synthetic_lowlight_classification} + \end{subfigure} + + \caption{Orbital benchmark performance for the synthetic model under low-light conditions showing (\subref{fig:benchmark_synthetic_lowlight_confidence}) the confidence score distribution and (\subref{fig:benchmark_synthetic_lowlight_classification}) the TP / FP / FN categorisation.} + \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. Fig. \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.65\linewidth]{figs/Occlusion_Test.png} + \caption{Comparing the VisDrone and Synthetic Models under occlusion.} + \label{fig:occlusion_test} +\end{figure} + +As shown in the detection curve (Fig. \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. + +\subsection{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 aligns with negative space within 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 Fig. \ref{fig:projection_side} and Fig. \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} + +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/CameraProjection_SimilarTriangles.png} + \caption{} + \label{fig:projection_side} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/CameraProjection.png} + \caption{} + \label{fig:projection_3d} + \end{subfigure} + + \caption{Geometry of the perspective projection model from 3D spatial coordinates to the 2D image plane, illustrating (\subref{fig:projection_side}) similar triangles for the y-axis projection and (\subref{fig:projection_3d}) a 3D perspective view relating the camera coordinate frame and image plane.} + \label{fig:camera_geometry} +\end{figure} + +In order to interface with the high-level logic (Section \ref{high level control}) as well as the motion planning and flight control architecture (Section \ref{motionPlanning}), 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.65\linewidth]{figs/CameraLocalToWorld.png} + \caption{The local coordinate frame of the drone's camera.} + \label{fig:camera_to_world} +\end{figure} + +\newpage + +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 yaw ($\psi_g$), pitch ($\theta_g$) and roll ($\phi_g$) of the camera relative to the drone's chassis. 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_y(\psi_g) \cdot R_x(\theta_g) \cdot R_z(\phi_g). +\end{equation} + +For the scope of this simulation, the translation vector between the gimbal mount and the drone's centre of mass is assumed negligible and set to zero. + +Next we read the drone's onboard \gls{imu} to acquire the drone's yaw ($\psi_d$), pitch ($\theta_d$), and roll ($\phi_d$). + +These attitudes dictate the drone's rotation matrix $R_d$: +\begin{equation} + R_d = R_y(\psi_d) \cdot R_x(\theta_d) \cdot R_z(\phi_d). +\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_d) R_x(\theta_d) R_z(\phi_d) \big) \cdot \left( \big(R_y(\psi_g) R_x(\theta_g) R_z(\phi_g) \big) \begin{bmatrix} x_c \\ y_c \\ z_c \end{bmatrix} \right) + \begin{bmatrix} X_{d} \\ Y_{d} \\ Z_{d} \end{bmatrix}.$% + } +\end{equation} + +\subsection{Player 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~\cite{reid_kalman} 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. + +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} + +% \begin{align} +% \hat{X}_{k+1|k} &= F \hat{X}_{k|k} \\ +% P_{k+1|k} &= F P_{k|k} F^T + Q +% \end{align} + +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~\cite{barshalom2001kinematic}. 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} + +\subsubsection{Occlusion Handling and Timeout Logic} + +In the arena, walls and barricades frequently occlude the target, causing the \gls{yolo} model to drop the measurement vector ($Z_k$). During total occlusion, the filter skips the update phase and relies on the constant velocity predict phase ($\hat{X}_{k+1|k}$). As visualised in Fig. \ref{fig:kalman_prediction}, this projects the target's trajectory behind cover, allowing the drone to anticipate where the player will re-emerge. + +However, a purely kinematic prediction becomes invalid if the player stops moving to hide behind cover. To prevent the tracking algorithm from projecting the target indefinitely, a timeout threshold ($t_\text{timeout}$) is implemented. If the duration of the occlusion exceeds $t_\text{timeout}$, the filter halts the constant velocity assumption. The velocity states are zeroed, and the position state reverts to the last verified Cartesian coordinate before line-of-sight was lost (Fig. \ref{fig:last_known_position}). This ensures the camera remains directed at the location where the system last had high confidence of the player's exact position. + +\newpage + +\begin{figure}[t!] + \centering + \includegraphics[width=0.7\linewidth]{figs/Player State Estimation.png} + \caption{Kalman filter trajectory prediction during target occlusion (Video demonstration: \url{https://youtu.be/AjJI64mWM_Y}). The blue trail indicates raw observations, while the yellow line demonstrates the filter's internal state estimate projecting behind cover.} + \label{fig:kalman_prediction} + + \vspace{0.25cm} + + \includegraphics[width=0.7\linewidth]{figs/Last Known Position.png} + \caption{Timeout mechanism execution (Video demonstration: \url{https://youtu.be/zGCds-d2954}). After prolonged occlusion, the state estimate halts the kinematic prediction and reverts to the last verified position (shown in orange).} + \label{fig:last_known_position} +\end{figure} + +\subsection{Limitations and Future Work} +An evaluation of the current perception system highlights key design limitations to be addressed in future iterations: + +\begin{itemize} + \setlength{\itemsep}{0pt} + \setlength{\parskip}{0pt} + \item \textbf{Sim-to-Real Domain Gap:} The YOLOv8n model relies on idealised simulation graphics. Real-world deployment will introduce unmodelled sensor noise, motion blur, and variable lighting conditions. Future work must address this by integrating high-fidelity ray-traced rendering into the automated synthetic pipeline or transitioning to an empirical dataset collected from a physical arena. + \item \textbf{Computational Resource Allocation:} Running real-time object detection, stereoscopic disparity mapping, and kinematic transformations concurrently creates a high processor load. Future development requires profiling processing latency on the target companion computer to ensure it does not bottleneck the flight control loop frequency. +\end{itemize} + +\subsection{Conclusion} +This section presented a three-stage visual perception pipeline designed to provide relative 3D spatial data within the broader multiagent drone system. Selecting a passive stereo camera establishes a method for tracking target depth independent of posture while avoiding infrared interference with the laser tag scoring mechanics. Tracking vulnerabilities under low-light or occluded conditions were mitigated by implementing an automated synthetic data generation pipeline to train the object detection model. Fusing 2D bounding boxes with stereoscopic depth via a Linear Kalman Filter provides smoothed 3D coordinates and trajectory prediction during temporary occlusions. The simulation results indicate that the pipeline delivers a workable spatial tracking interface suitable for integration with the high-level logic and flight controller. + + +\newpage +\section{Motion Planning and Flight Control Architecture} +\label{motionPlanning} +\fancyhead[C]{Thomas August} + +In this section we detail the motion planning and flight control algorithms of each operational mode (detailed in Section~\ref{high level control}). Each mode utilises a flight control algorithm that outputs body thrust and moments which are converted to motor commands using the \gls{aam} detailed at the end of this section. + +\subsection{Search Mode} \label{search mode}% Tommy + +The search mode uses a centralised off-board flight planner and an onboard flight controller. We opted for a centralised flight planner which is run on the server to efficiently coordinate all drones in search mode. This planner has two stages, region allocation and trajectory planning, detailed in the sections below. The planner recomputes whenever the number of drones in search mode changes to maintain full map coverage. The onboard flight controller uses our cascaded \gls{pd} controller (detailed in Section~\ref{cascadedPDController}). The desired position is selected as the point located a fixed distance ahead of the drone's current projected position along the trajectory path, while the desired heading direction is defined towards this target position. While traversing the planned trajectory, the camera-gimbal system will rotate, looking for players. + +\subsubsection{Region Allocation} +The region allocation process uses a simultaneous multiagent \gls{bfs} algorithm that propagates from the current grid cell location of each drone. Each grid cell is assigned to the drone whose \gls{bfs} reaches it first. This creates a single closed region for each drone, avoiding possible collisions and multiple searches of the same area. + +This algorithm requires the current location of every drone, however, when a drone is in the home base, it does not have a current location in the map, instead there are multiple possible entry cells. Since this algorithm is computationally lightweight, the planner computes every possible combination of entry cells for the drones currently located in the home base, then selects the combination that minimises the maximum region size. + +Because all drones are treated identically by the algorithm, if $d$ drones are entering from the home base and there are $e$ possible entry cells, the number of combinations is $^eC_d$. In our map there are seven possible entry cells, therefore the maximum number of combinations occurs when either three or four drones are entering simultaneously, giving $^7C_3 = ^7C_4 = 35$ possible combinations. + +\subsubsection{Trajectory Planning} +For the trajectory planning algorithm, we initially considered using a \gls{dfs} tree traversal over the allocated region. This approach performs well in confined, maze-like areas of the map, however, in open areas, such as the centre of the map, the algorithm still traverses the map as though it were maze-like, resulting in unnecessary backtracking. +To address this limitation and improve performance across the entire map, we adopted a hybrid \gls{dfs}-lawnmower approach. In this method, open regions are represented as single nodes within the \gls{dfs} tree, while traversal within those regions is planned separately using a lawnmower search pattern. This preserves the performance of \gls{dfs} in constrained spaces while enabling more efficient traversal of open areas. + + +% \subsubsection{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. + +% \subsubsection{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 gimbal-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. + +\subsection{Track and Shoot Modes} +The track and shoot modes both utilise the same flight control system to track the detected player. In both modes, the player tracking system (detailed in Section~\ref{visual_perception}) provides an estimate of the player position. The controller then commands the drone to maintain a position directly above the player using the cascaded \gls{pd} controller described in Section~\ref{cascadedPDController}. + +The desired position is defined as the player's estimated $x$-$y$ position with a fixed altitude of $4\,\mathrm{m}$, while the desired heading direction is chosen to face the player within the $x$-$y$ plane. When the horizontal separation between the drone and player falls below a small threshold, the previously defined heading vector is maintained to avoid instability caused by rapid heading changes at small relative distances. + +\subsection{Movement Mode} % Tommy +\label{movement mode} +\fancyhead[C]{Thomas August} + +This movement mode is designed to plan and execute a trajectory from the current grid cell to the target grid cell as quickly as possible in order to provide backup to another drone. + +\subsubsection{Overview} +The high level controller will provide a target grid cell upon switching the drone to movement mode. The motion planner is required to plan cell-base path from the current grid cell to the target grid cell and convert this to a 3D trajectory. The flight controller is then required to follow this trajectory as quickly as possible, while maintaining a high success rate to minimise trajectories being aborted by the collision avoidance mode (detailed in Section~\ref{collision avoidance mode} below). + +% 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. + +\subsubsection{Trajectory Planning} + +The first stage of the motion planner computes a cell-based path from the current grid cell to the target grid cell using our map (detailed in Section~\ref{map}). Since the objective of this mode is to reach the target location as quickly as possible, this must be the shortest path to minimise the distance travelled. This is computed with a \gls{bfs} algorithm which explores all accessible cells with increasing distance from the start cell, using our map to determine which adjacent cells are accessible. Once the target cell is visited, the search terminates. The shortest path is then determined by starting at the target cell and iteratively adding the parent cell to the path, before inverting the order. Since the map we have designed is 11x17 grid cells, there are 187 grid cells in total, meaning the number of possible paths is 187x187 = 34,969. In order to reduce computation time, we will run this motion planner on the server. The server will have a large amount of storage, meaning we can further decrease computation time by pre-computing all possible paths. To easily access these pre-computed paths, we will use a lookup table from which the programme can request paths using the start and end coordinates at runtime. + +The second stage of the motion planner converts this cell-based path to a 3D trajectory. 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, and at a height halfway between the net and the ceiling. These checkpoints are then sent to the drone along with the command to change into movement mode. + +\subsubsection{Control Method} +In the other modes, the flight controller uses our cascaded \gls{pd} controller to track the trajectory due its low computational cost. However, in this mode, we prioritise reaching the target location as quickly as possible and therefore are willing to use a more computationally expensive approach. + +This led us to consider more complex control methods such as \gls{rl} and \gls{mpc}. During our investigation of these methods, we identified a paper that uses \gls{mpc} to train a \gls{rl} policy online via supervised learning \cite{zhang_learning_2016}. Although we chose not to adopt the method proposed here, the motivation presented in the introduction provided valuable insight that guided us to choosing \gls{rl} as our approach for this application. Zhang et al. discuss that \gls{mpc} \say{is an effective and reliable method}, however, \say{applications of \gls{mpc} can be computationally demanding}. They also mention that \say{the final neural +network policy is computationally much less expensive than +\gls{mpc}}, and hence if a \gls{rl} policy is trained well, it can obtain similar results to that of \gls{mpc} at a lower computational cost. In this paper they also mention another benefit of their method being that \say{Reinforcement learning can in +principle forego the need for explicit state estimation and +acquire a policy that directly maps sensor readings to actions}, however, since we already have a state estimator for our other flight controllers, we opted to use this state as our input, removing unnecessary complexity from this policy. Finally, their reasoning for using supervised learning is that \say{model-free \gls{rl} is difficult to apply to unstable systems such as quadrotors, due to the possibility of catastrophic failure during training.} However, we opted to train our \gls{rl} policy offline using a physics simulator, removing the risk of damaging hardware during training. + +% 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 \say{MPC is an effective and reliable method ... However, applications of MPC can be computationally demanding} and \say{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 directly with RL because 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{drone 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. + +\subsubsection{Environment Development} \label{RLEnvDevelopment} +Throughout the development process, we changed the environment setup multiple times in order to increase the complexity iteratively and ensure each prototype was working before moving to the next stage. Isaac Lab comes with a quadcopter demonstration environment \cite{IsaacLabQuadcopter}, in which the drone attempts to reach and hover at a goal position using body thrust and moment actions. We first read through this document to understand how they set the environment up. This demonstration environment is created using the direct workflow, however it is our preference to use the manager based workflow as it breaks down the code into manager terms, meaning it is more manageable and readable for larger projects. Due to this, we first converted the demonstration environment to a manager based environment. Next, we adapted this environment to reach consecutive position goals by resampling the position goal once within a threshold distance of the current position goal. Following this, we heavily adapted this environment to sample random trajectories as the command by choosing an initial starting checkpoint and random horizontal direction and then creating the second checkpoint at one grid spacing along this direction. The next checkpoints were generated by choosing a random direction from left, straight, and right each with random probabilities. This environment allowed us to test and develop the \gls{rl} policy without implementing the trajectory planning stage. Finally, we adapted this environment to use a known map and spawn the drone at a random location within the map, then choose a random target grid square. Next, we implemented the trajectory planner, described above, which uses the \gls{bfs} algorithm to plan the shortest path through the map and then converting this path into a 3D trajectory. Once we had this final environment, we further tuned the environment parameters, detailed in the sections below, to produce the optimal results. + +\subsubsection{Scene} +The general scene was just setup with a flat ground plane, however, we created custom code that uses our map wall matrix (detailed in Section \ref{map}) to determine the location of the walls and loads them and the floor into the environment as collision cuboids, as shown in Fig. \ref{fig:IsaacLabMap}. These collision cuboids are not used for collisions as our termination conditions, detailed below, will reset the environment before the drones hit the wall, so these are turned off during training to reduce computation time and used only for visualisation when playing the environment for demonstration purposes. + +\begin{figure}[htbp] + \centering + + \includegraphics[width=0.5\textwidth]{figs/IsaacLabMap.png} + + \caption{Our chosen map generated in Isaac Lab} + \label{fig:IsaacLabMap} +\end{figure} + +\subsubsection{Command} \label{RLCommand} +As mentioned before in Section \ref{RLEnvDevelopment}, the trajectories are generated by sampling a random grid square and planning the shortest path from the current grid square to that grid square using the \gls{bfs} algorithm and then converting the grid path to a 3D trajectory by placing the checkpoints in the middle of the grid squares and halfway between the net and the ceiling. We also implemented a maximum trajectory length parameter that limits the trajectories to a maximum length, by truncating the remaining checkpoints. This means the final checkpoint is now different so this is not used during deployment but it is useful during training (detailed in Section \ref{RLCurriculum}). The command then outputs the current checkpoint position (the position that the drone is currently trying to reach) and the direction from the current to the next checkpoint, both in the body frame of the drone, to the observations. This means the policy only has information about the current and next checkpoint at any time. Every time step the command checks if the current checkpoint has been achieved, and if it has, the command observations are updated so that current and next checkpoint are shifted along the trajectory by one. Initially, we attempted to determine checkpoint completion by checking if the drone was closer than a threshold distance to the current checkpoint, however, this forces the drone to pass through all checkpoints, whereas the shortest path would cut the corners of the trajectory. To allow the policy to learn this faster behaviour, we opted to determine checkpoint completion by checking if the drone has crossed the plane which passes through the current checkpoint and is perpendicular to the line connecting the previous and next checkpoints. + +\subsubsection{Actions} +The output of the policy is the actions and we chose to use the same actions as in the Isaac Lab quadcopter demonstration environment, where the output is a thrust in the drones upwards direction and moments about all axes of the drone. To ensure the actions are achievable in reality, we clamped the raw actions, the output from the neural network, to the range $[-1, 1]$ and then mapped this range to $[0,T_{\mathrm{max}}]$ for the thrust and $[-M_{\mathrm{max}},M_{\mathrm{max}}]$ for the moments, where $T_{\mathrm{max}}$ and $M_{\mathrm{max}}$ are the maximum achievable thrust and moment respectively. In the simulator we applied these thrust and moments directly to the drone body, however, during deployment they will be passed to the \gls{aam} (detailed in Section \ref{mixing matrix}) to calculate the motor commands. + +\subsubsection{Observations} +The input to the policy is the observations and we chose to use the same observations as in the Isaac Lab quadcopter demonstration environment, where the inputs are the drone linear and angular velocities, the projected gravity vector, and the command observations, all in the body frame of the drone. These can all be calculated from the estimated state (detailed in Section \ref{drone state estimation}). + +\subsubsection{Events} +Events are changes that affect the environment during an episode. In our environment, we define a single event that occurs when the drone is reset after termination (to be detailed in subsection). This event resets the drone position and yaw to a random, collision-free, location within the map. To avoid spawning the drone inside a wall, a random grid cell is first selected, and then a bounded random offset is applied from the centre of that cell in both the x and y directions, ensuring all possible positions remain within the cell boundaries. A random height is then sampled within the allowed vertical range between the net and the ceiling, and a random yaw is selected. Roll and pitch are set to zero resulting in a fully specified pose. + +\subsubsection{Rewards} +The rewards of a reinforcement learning policy shape the learnt behaviour, and hence a lot of development went into carefully selecting the following reward structure: + +\paragraph{Checkpoint Progress} To encourage movement towards the current checkpoint, we introduced a reward proportional to the change in the projected distance along the vector from the previous to the current checkpoints, such that moving towards the current checkpoint gives a positive reward and moving away gives a negative reward. + +\paragraph{Checkpoint Passed} To give the policy an indication that passing the checkpoints is the desired behaviour, we implemented a single reward whenever the drone achieves a checkpoint, providing large sparse rewards for achieving these milestones that will lead to the final target location. + +\paragraph{Final Checkpoint Distance} Once the policy reaches the target location, the desired behaviour is for the drone to hover at the final checkpoint. To promote this behaviour, we implemented a reward that is zero unless on the final checkpoint, where it increases as the distance to the checkpoint decreases, as defined in Eq.\ref{equ:RL_tanh_reward}. + +\begin{equation} + \label{equ:RL_tanh_reward} + \mathrm{Reward} = 1 - \tanh(\mathrm{distance/std}) +\end{equation} +where $\mathrm{std}$ is a constant. + +\paragraph{Termination Penalty} To avoid the drone crashing, we implemented a sparse negative reward that is applied whenever the environment terminates due to the drone flying out of bounds (detailed in Section \ref{RLTerminations}). + +\paragraph{Proximity to Wall Penalty} To reduce the chance of the drone crashing, the termination penalty is not enough as it learns that crashing is bad but does not learn when a crash is likely to happen. This reward informs the drone that flying close to the walls is dangerous behaviour that may result in a crash by imposing a negative reward that increases in magnitude as the distance to the closest wall decreases. This reward is calculated using Eq. \ref{equ:RL_tanh_reward}, where the distance is the distance to the closest wall. + +\paragraph{Distance from Path Penalty} This reward was also designed to reduce the likelihood of collisions. A negative reward is applied proportional to the shortest distance between the drone and the line segment connecting the previous and current checkpoints. Since the checkpoints are positioned along the centre of the corridor, this indirectly discourages the drone from flying close to the walls. + +\paragraph{Time Penalty} The primary objective of this mode is to enable the drone to travel to the target location as quickly as possible. To promote rapid trajectory traversal, we implemented a constant negative reward applied at each time step until the drone is within a threshold distance of the final checkpoint. This encourages the policy to reach the final checkpoint in the minimum possible time. + +\paragraph{Linear and Angular Velocity Penalties} Although the primary objective is to reach the final checkpoint as quickly as possible, we also aim to reduce the likelihood of collisions. Therefore, we apply negative rewards proportional to the magnitudes of the linear and angular velocities to discourage excessively high velocities that may lead to collisions. + +\subsubsection{Terminations} \label{RLTerminations} +The termination conditions determine when an episode should be reset. Our environment employs two termination conditions: + +\paragraph{Timeout} The environment is reset after a fixed time interval by the timeout termination condition. This prevents the drone from hovering indefinitely. Since the objective of the policy is for the drone to hover at the final checkpoint once it has been reached, a separate success termination was not implemented. Instead, this timeout termination resets the environment regardless of whether the final checkpoint has been reached. For this termination, no penalty is applied. + +\paragraph{Out of Bounds} To prevent the drone crashing into the map, we use an out of bounds termination condition. This condition resets the environment with a penalty whenever the drone flies out of its allowed region. We opted to use an allowed region rather than direct collision detection for termination, as this allows us to change the size and terminate when the drone is near the wall rather than upon contact, reducing the risk of collisions during deployment. The allowed region is defined as a cuboid box around the current and previous checkpoints. This cuboid box is defined by upper and lower z limits and a buffer distance from the walls to define the x-y limits. Since the position of the drone corresponds to it's centre of mass, the buffer distance must be at least half the diagonal width of the drone, and the z limits must be below the ceiling and above the net. The above definition of the allowed region is a conservative boundary such that the drone will not collide with the map in any orientation, provided it's position remains within the region. This also assumes that both the previous and current checkpoints are surrounded by walls, however, when the current checkpoint is reached, the region will update with the checkpoints, ensuring the trajectory is never obstructed. + +\subsubsection{Curriculum} \label{RLCurriculum} +The longest path between two grid cells on our map spans 35 cells, making it difficult for the policy to learn successful traversal of the whole trajectory with no prior knowledge. A common approach for tackling such complex tasks in reinforcement learning is to simplify the problem during the early stages of training, allowing the policy to learn the fundamental behaviours and interact receive final rewards before attempting the full task. This is achieved using a curriculum, which modifies the environment throughout training to increase the complexity gradually. + +We implemented a curriculum that progressively increases the maximum trajectory length. After an initial training period, the maximum allowable path length is increased by one at fixed intervals until a predefined limit is reached. This enables the policy to successfully complete short trajectories, where the final checkpoint reward is easier to obtain, and learn both the trajectory traversal and final hovering early on. Since the policy can only observe the next two checkpoints, further increasing the trajectory length does not increase the difficulty much, and the policy can quickly learn longer trajectories with this prior knowledge. + +\subsubsection{Environment Parameters} +For deployment on our drone, the policy would ideally be trained using our drone model. However, due to technical issues that prevented our drone model from being loaded into Isaac Lab, we instead used the Crazyflie drone model used in the Isaac Lab quadcopter demonstration environment \cite{IsaacLabQuadcopter}. This serves as a proof of concept to demonstrate that the \gls{rl} policy is capable of producing the fast responses required for this mode. + +As training and evaluation were not performed using our exact drone model, we introduced several control measures to ensure the training environment was as representative as possible. The Isaac Lab demonstration environment uses a 1.9 thrust-to-weight ratio which is comparable to that of our drone which is 2, and hence this is already representative. The width of the Crazyflie drone \cite{CrazyflieDatasheet} is 80mm, whereas that of our drone is 420mm, (detailed in Section~\ref{drone dimensions}), as such, our drone is approximately 5 times larger than the Crazyflie drone. To compensate for this, we reduced the grid cell dimensions by in the Isaac lab policy by 5 times such that the grid cells are 0.4m square rather than 2m square. The diagonal length of the Crazyflie drone is 110mm, so the out of bounds buffer must be at least 55mm, however we set this to 80mm to ensure there is a minimum separation between the drone and wall of 25mm. Since the Isaac Lab environment is scaled down, this corresponds to 125mm in our full scale environment. We also placed the z limits of the bounds region 80mm above the net and below the ceiling. + +Having compensated for the size disparity, we set the remaining parameters accordingly. For the curriculum, we set the starting number of checkpoints to 3 and the initial training period to 400 steps and the interval steps to 30. The predefined limit for the maximum trajectory length was set to 50, however the longest path between two cells in our map spans 35 cells, and hence this was the limiting factor. For the rewards, we set $\mathrm{std}$ in Eq.\ref{equ:RL_tanh_reward} to 0.1m, for both the final checkpoint distance reward and proximity to wall penalty, and we set the threshold distance for the time penalty to 0.1m. The remaining parameters we set were the timeout termination interval of 15s, and the policy frequency of 50Hz. Finally, the policy was trained using an actor-critic architecture, where both networks consisted of two hidden layers of 64 units each and \gls{elu} activation. + +% For the policy that is deployed on our drone, we would have to train the policy using our drone model. Unfortunately, we were not able to load our drone model into Isaac Lab, due to technical issues, so instead we used the Crazyflie drone model, used in the Isaac Lab quadcopter demonstration environment, to train this policy as a proof of concept, to show that this RL policy can provide the fast results required for this mode. As we are not using the same drone to train the policy, we put the following control measures in place to make the environment as close as possible to training our drone in our map. + +\subsubsection{Reward Weighting} + +Using the environment setup detailed in the sections above, we then refined the policy by tuning the reward weightings. This process involved approximately setting these values based on previous experience setting up the other environments and intuition, before fine tuning them by analysing the learned behaviour. Table \ref{RLRewards} below details the reward weightings for our final trained policy. + +\begin{table}[htbp] + \centering + \caption{Final \gls{rl} policy rewards} + \label{RLRewards} + \begin{tabular}{|c|c|} + \hline + \textbf{Reward} & \textbf{Weight}\\ + \hline + Checkpoint Progress & 1.5 \\ + \hline + Checkpoint Passed & 20.0 \\ + \hline + Final Checkpoint Distance & 5.0 \\ + \hline + Termination Penalty & -100.0 \\ + \hline + Proximity to Wall Penalty & -0.1 \\ + \hline + Distance from Path Penalty & -0.1 \\ + \hline + Time Penalty & -0.3 \\ + \hline + Linear Velocity Penalty & -0.01 \\ + \hline + Angular Velocity Penalty & -0.01 \\ + \hline + \end{tabular} +\end{table} + +\subsubsection{Testing and Evaluation} +In order to evaluate and compare policies, we created a test script which runs the policy while recording data about each episode. This script records the outcome (success if the final checkpoint is reached), the time taken to reach the final checkpoint (if successful), and the number of checkpoints. From this data we can calculate the success rate of the policy, the average time taken per checkpoint across all successful episodes, and the maximum time taken for any trajectory in our map. The script also allows us to define the number of episodes to record, set the random seed, and save the recorded data to a .csv file to aid with analysis. + +We evaluated the final policy using 5 random seeds, with 20,000 episodes per seed, for a total of 100,000 episodes to produce the results in Table \ref{RLResults}. + +\begin{table}[htbp] + \centering + \caption{Final \gls{rl} policy results} + \label{RLResults} + \begin{tabular}{|c|ccc|} + \hline + \textbf{Seed} & \textbf{Success Rate} & \textbf{Avg Time per Checkpoint [s]} & \textbf{Max Time Taken [s]}\\ + \hline + 1 & 0.967 & 0.368 & 13.70 \\ + \hline + 2 & 0.971 & 0.368 & 13.66 \\ + \hline + 3 & 0.969 & 0.367 & 13.64 \\ + \hline + 4 & 0.968 & 0.368 & 13.50 \\ + \hline + 5 & 0.970 & 0.368 & 13.58 \\ + \hline + Average & 0.969 & 0.368 & 13.62 \\ + \hline + \end{tabular} +\end{table} + +As seen above, the final policy has a success rate of around 97\%, meaning it does not reach the goal 3\% of the time. This is most likely all from out of bounds terminations rather than the episode timing out without the final checkpoint being reached, so this policy will crash $3\%$ of the time. This is an acceptable level because our collision avoidance mode should prevent these collisions occurring. The average time per checkpoint is 0.368s. If we assume this would also be the case for deployment on our drone, then we can approximate the average speed by dividing the grid cell length by this time, producing $2/0.368 = 5.43 \mathrm{ms}^{-1}$. Finally the maximum time taken to get between any two grid cells in our map averaged at 13.62s over all 5 random seeds. These results show that the policy can quickly and safely traverse the map as intended. + +\begin{figure}[htbp] + \centering + + \includegraphics[width=0.95\textwidth]{figs/RL_policy_demo.png} + + \caption[Isaac Lab \gls{rl} policy execution (Video demonstration: \url{https://youtu.be/1mnYx0IYGyg})] {Isaac Lab RL policy execution (Video demonstration\footnotemark: \url{https://youtu.be/1mnYx0IYGyg})} + \label{fig:RLPolicy} +\end{figure} + +\footnotetext{Policy execution is at half speed due to rendering constraints, play the demonstration at 2x speed for real time playback} + +\subsection{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 that are likely to occur in the near future in real time . 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. + +\subsubsection{Collision Detection} +For the collision detection method, we chose to monitor the distance and velocity towards the obstacle and enter collision avoidance mode when the estimated time to collision, calculated from these values, is below the collision time threshold. + +\paragraph{Map Collisions} Since the drones will estimate their state onboard (detailed in Section \ref{drone state estimation}), the map collision detection is run onboard to reduce latency. The distance, $d$, to the closest map obstacle in the direction of the velocity, $v$, is calculated, which are then both used to estimate the time until collision using the formula $t=d/v$. If the time until collision is below the collision time threshold for map collisions, the drone is immediately forced into collision avoidance mode. + +\paragraph{Drone to Drone Collisions} The state of other drones is not stored onboard, hence communication through the server is required for drone to drone collision detection. To avoid the latency of sending drone states through the server to other drones, the drone to drone collision detection is run on the server. To detect these collisions, the velocity of each drone is used to propagate the pose in small time steps up to the collision detection time. At each time step, the distance between the drones is computed, and if this is below a safety threshold distance, both drones are immediately forced into collision avoidance mode. The threshold distance is used to account for errors in the pose and changes in dynamics, and the collision time threshold for drone to drone collisions should be larger than that of map collisions to account for the added latency of server to drone communication. + +\subsubsection{Collision Avoidance} +Our collision avoidance system uses an \gls{apf} to apply an artificial force to the drone. This artificial potential field, $U$ is generated by placing repulsive sources on all map surfaces, including the walls, ceiling, and safety net, and all the other drone locations, provided by the server. An artificial force, $\mathbf{F}_{\mathrm{art}}$, is then applied to the drone in the direction of the negative gradient of the potential field at the position, $\mathbf{p}$ of the drone. +\begin{equation} + \mathbf{F}_{\mathrm{art}} = - \nabla U(\mathbf{p}) +\end{equation} +The acceleration due to this artificial force, $\mathbf{a}_{\mathrm{art}}$ is tracked using a similar cascaded \gls{pd} controller to that detailed in Section\ref{cascadedPDController}, but with the first \gls{pd} controller adjusted to follow this artificial acceleration rather than track a position +\begin{equation} + \mathbf{a}_{des} = \mathbf{K}_a \mathbf{a}_{\mathrm{art}} - \mathbf{K}_d v = - \mathbf{K}_U \nabla U(\mathbf{p}) - \mathbf{K}_d v +\end{equation} +This desired acceleration is then used in the same way as in Section \ref{cascadedPDController}, with the heading direction in the same direction as the artificial force, unless this force is below a threshold value, at which point the last defined heading direction is maintained. + +\subsection{Cascaded \gls{pd} Controller} \label{cascadedPDController} +This controller is used by multiple states as it is a computationally lightweight method for following position and heading direction commands. The controller is comprised of two \gls{pd} controllers. The first produces a desired acceleration, $\mathbf{a}_{\mathrm{des}}$, for tracking a desired position, $\mathbf{p}_{\mathrm{des}}$, using the position, $\mathbf{p}$, and velocity, $\mathbf{v}$: +\begin{equation} + \mathbf{a}_{\mathrm{des}} = \mathbf{K}_p (\mathbf{p}_{\mathrm{des}} - \mathbf{p}) - \mathbf{K}_v \mathbf{v} +\end{equation} +This desired acceleration is then combined with the upwards acceleration due to gravity and the mass to produce the desired, $\mathbf{F}_{\mathrm{des}}$, as +\begin{equation} + \mathbf{F}_{\mathrm{des}} = m \left(\mathbf{a}_{\mathrm{des}} + \begin{bmatrix} + 0 &0&g + \end{bmatrix}^\top \right) +\end{equation} +This desired force and the desired heading direction, $\mathbf{h}_{\mathrm{des}}$, are used to define the desired Euler orientation, $\boldsymbol{\theta}_{des}$. The second \gls{pd} controller then produces the desired moments, $\mathbf{M}_{\mathrm{des}}$, for tracking this desired orientation, using the Euler orientation, $\boldsymbol{\theta}$, and angular velocity, $\boldsymbol{\omega}$: +\begin{equation} + \mathbf{M}_{\mathrm{des}} = \mathbf{K}_{\theta}(\boldsymbol{\theta}_{des} - \boldsymbol{\theta}) - \mathbf{K}_{\omega} \boldsymbol{\omega} +\end{equation} +Finally, the desired thrust is the magnitude of the desired force: +\begin{equation} + T_{\mathrm{des}} = |\mathbf{F}_{\mathrm{des}}| +\end{equation} + +\newpage +\subsection{Actuator Allocation Matrix} \label{mixing matrix} % Tommy +\fancyhead[C]{Thomas August} + +An \gls{aam} is used to convert body thrust and moments to actuator commands using the geometry of the quadcopter and dynamics of the actuators. Suppose we have four actuators, $i$, at horizontal positions $(x_i,y_i)$ relative to the centre of mass, producing thrust, $T_i$. We can derive the body thrust and moments using the quadcopter geometry as +\begin{equation} + \begin{aligned} + T &= T_1 + T_2 + T_3 + T_4 \\ + M_{\mathrm{roll}} &= x_1 T_1 + x_2 T_2 + x_3 T_3 + x_4 T_4 \\ + M_{\mathrm{pitch}} &= - y_1 T_1 - y_2 T_2 - y_3 T_3 - y_4 T_4 \\ + M_{\mathrm{yaw}} &= k_a T_1 - k_a T_2 + k_a T_3 - k_a T_4 + \end{aligned} + \quad + \Longleftrightarrow + \quad + \begin{bmatrix} + T \\ + M_{\mathrm{roll}} \\ + M_{\mathrm{pitch}} \\ + M_{\mathrm{yaw}} + \end{bmatrix} + = + \begin{bmatrix} + 1 & 1 & 1 & 1 \\ + x_1 & x_2 & x_3 & x_4 \\ + - y_1 & - y_2 & - y_3 & - y_4 \\ + k_a & -k_a & k_a & -k_a + \end{bmatrix} + \begin{bmatrix} + T_1 \\ T_2 \\ T_3 \\ T_4 + \end{bmatrix} +\end{equation} +where $k_a$ is the thrust-to-yaw proportionality constant that relates the aerodynamic drag moment, $M_{\mathrm{aero,i}}$ to the motor thrust $M_{\mathrm{aero,i}} = k_a T_i$. The sign in front of $k_a$ alternates in the yaw equation above due to the actuators spinning in opposite directions such that the yaw moment is zero when all motors produce the same thrust. + +If we defined the matrix above as $\mathbf{B}$, then, using the same actuator thrust model used in the state estimator acceleration model (Eq.\ref{equ:ActuatorThrustModel}, Section~\ref{StateEstimatorAccelModel}), the relationship between body thrust and moments and actuator commands is +\begin{equation} + \begin{bmatrix} + T_k & + M_{\mathrm{roll},k} & + M_{\mathrm{pitch},k} & + M_{\mathrm{yaw},k} + \end{bmatrix} ^\top = \mathbf{B} k_{T} \mathbf{c}_k +\end{equation} +where $K_{T}$ is the pre-calculated thrust coefficient used to initialise the state estimator, and $\mathbf{c}_k$ is the motor commands. +Inverting the above equation produces the desired conversion from body thrust and moments to actuator commands +\begin{equation} + \mathbf{c}_k = \frac{1}{k_{T}} + \mathbf{B}^{-1} + \begin{bmatrix} + T_k & + M_{\mathrm{roll},k} & + M_{\mathrm{pitch},k} & + M_{\mathrm{yaw},k} + \end{bmatrix} ^\top +\end{equation} +such that the \gls{aam}, $\mathbf{A}$, is +\begin{equation} + \mathbf{A} = \frac{1}{k_{T}} \mathbf{B}^{-1} +\end{equation} +which is pre-calculated using the measured horizontal positions, $(x_i,y_i)$, the experimentally determined thrust-to-yaw proportionality constant, $k_a$, and thrust coefficient, $k_T$. + +\newpage + + +\section{Companion App Design} % Ritchie +\label{app} +\fancyhead[C]{Richard Usherwood} +\subsection{Context} +From fast-food restaurants to road cycling, apps are everywhere. As reported in the Guardian, the average UK adult year old spends over three hours on their phone every day~\cite{theguardianAdultsGreat} using apps, making apps a useful method of reaching consumers. Their purpose can be separated into two categories: Engagement and Functionality. % Add reference to make it sound better + +\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, the popular birdwatching app \say{Birda} allows users to log bird sightings. It rewards users with achievement badges when they complete objectives (for example, logging ten different species), and integrates monthly challenges. It also connects birdwatchers through the \say{community} feature, allowing users to view their friends' activity and local sightings. + +\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 existing products. For example, the 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 sign in using a username and password. When completed, the app displays the first of five screens that are navigated using a bottom panel: the \say{Profile} screen, the \say{Leaderboard} screen, the \say{Achievements and Challenges} screen, the \say{Community} screen, and the \say{Play in Person} screen. As an example, the \say{Leaderboard} screen is shown in Fig. \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} + \hspace{1cm} + \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 Achievements are implemented, and players are rewarded with a notification when one has been completed. Added to this are monthly challenges, giving 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 Fig.~\ref{fig:lea-screen}(\subref{fig:lea-fri}). + \item The Community screen allows players to see their friends' recent activity, 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 received a friend request. +\end{itemize} + + +\subsection{Functionality} +The user experience of playing the 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 Fig.~\ref{fig:userstory}(\subref{fig:userstory1}). + \item The app displays the Profile Screen, shown in Fig.~\ref{fig:userstory}(\subref{fig:userstory2}). Using the bottom panel, shown in Fig.~\ref{fig:App-Panel}, the user navigates to the \say{Play in Person} Screen. + \item The player uses the \say{Play in Person} screen to scan QR codes on the gun and the helmet given to them by the centre, shown in Fig.~\ref{fig:userstory}(\subref{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} + \hspace{0.5cm} + \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} + \hspace{0.5cm} + \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 for gameplay} + \label{fig:userstory} +\end{figure} +This allows the server to attribute the correct number of kills and deaths (\gls{ir} strikes on drones, encoded with ID of the gun, and \gls{ir} strikes on the helmet and vest detectors, communicated to server via Wi-Fi) to the correct player. + +\subsection{Usability Design Choices} +In 2010, Lee et al \cite{LEE201090} identified several \say{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 these principles: +\subsubsection{Visibility} +Lee et al describe the use of visibility in \gls{ui} design as \say{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 Fig. \ref{fig:App-Panel}. Furthermore, the open-source React icons encourage faster visual recognition by the user, improving 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 \gls{ui} design as \say{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 current screen is filled in and coloured red, shown in Fig.~\ref{fig:App-Panel}. When the user changes screen, the \say{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: \say{Accept} and \say{Decline}, as shown in Fig. \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) instinctively conveyes to the user 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 \gls{ui} design as \say{Uniformity of system semantics across similar situations}. In this context, \say{system semantics} refers to the method the user is expected to use when interacting with the \gls{ui}. As an example, the app uses a dark grey and red colour scheme. Throughout the app, red is used to mean \say{active/on} and dark grey is used to mean \say{passive/off}. This is seen in the bottom panel (Fig. \ref{fig:App-Panel}) and top panel in the achievements (Fig.~\ref{fig:RemainingAppSS}(\subref{fig:RemainingAppSS-ach-lif}, \subref{fig:RemainingAppSS-ach-mon})) and community (Fig.~\ref{fig:RemainingAppSS}(\subref{fig:RemainingAppSS-com-fri}, \subref{fig:RemainingAppSS-com-sen})) screens, in which the screen being displayed in shown in red. It is also seen in the login (Fig.~\ref{fig:userstory}(\subref{fig:userstory1})) and player profile (Fig.~\ref{fig:userstory}(\subref{fig:userstory2})) screens, in which the Login/Logout buttons are coloured red. It is shown in the box displayed when receiving a friend request (Fig. \ref{fig:App-Friend_Request}) in which the \say{Accept} button, which changes the user's list of friends, is coloured red, and the \say{Decline} button, which leaves the user's list of friends as it is, is shown in dark grey. +\begin{figure}[htbp] + \centering + \begin{subfigure}[b]{0.24\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/3_1_Achievements_Lifetime.jpg} + \caption{Achievements Screen - Lifetime Achievements} + \label{fig:RemainingAppSS-ach-lif} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.24\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/3_2_Achievements_Monthly.jpg} + \caption{Achievements Screen - Monthly Challenges} + \label{fig:RemainingAppSS-ach-mon} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.24\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/4_1_Community_Friends.jpg} + \caption{Community Screen - Friends Tab} + \label{fig:RemainingAppSS-com-fri} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.24\textwidth} + \centering + \includegraphics[width=\textwidth]{figs/App_Screenshots/4_2_2_Community_Requests_Making.jpg} + \caption{Community Screen - sending friend request} + \label{fig:RemainingAppSS-com-sen} + \end{subfigure} + \caption{App Screenshots} + \label{fig:RemainingAppSS} +\end{figure} + + +\subsection{Technical Details} +\subsubsection{Overview} +The app was created using Expo, a development environment used to create React Native apps. React Native is a framework that allows mobile apps to be built using React, which is a JavaScript library designed for user interface design. +\subsubsection{Project Structure} +When the app is run, it opens a \say{package.json} file which sets the rest of the app in motion. From here, it exectutes index.js, importing App.js, which opens MainContainer.js. MainContainer.js serves as the app's navigation hub. MainContainer.js decides which \say{navigation flow} to show, based on whether the app is in state \say{Auth} or \say{Main} (whether or not the user is signed in). From here, MainContainer.js accesses the displayed screens, each of which has a dedicated JavaScript file in the \say{screens} subfolder. +\subsubsection{State Management} +The app uses a hybrid state management strategy, meaning that 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 data of the user's last game (in profile screen) and friend requests a user may have (in community screen) etc. 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 \say{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 centrally, such as API cached data, each screen can \say{reach in} to this file and get what it needs, rather than the same data being stored in many different places. +\subsubsection{API Integration} +The App uses Supabase as its backend platform, to access a PostgreSQL database. Database access is handled through a single client in \say{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. + +\(\)\newline 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 \say{Players A, B, C, ... played a game in which they got D, E, F, ... kills and died G, H, I, ... times, respectively}. Furthermore the \say{score} is defined as \say{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 updated through API calls. Additionally, 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 a \say{super 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{Risk Assessment and Safety Management} +\label{risk-assessment} + +A quantitative risk assessment has been completed, and is shown in Table \ref{tab:risk-assessment}. Likelihood and Severity were both scored out of 5, and their product, \say{Risk Value} was analysed. The most significant initial risks were the contact between guns and players' eyes, and player collisions. After control measures, they are still the most significant residual risks, along with trips and falls. These risks are similar to those associated with traditional laser tag and common sports, and are no more significant. This shows that the level of risk associated with playing the game is acceptable. + + +\begin{table}[h] +\centering +\caption{Quantitative Risk Assessment (L=Likelihood, S=Severity, RV=Risk Value)} +\begin{tabular}{|c|c|p{4cm}|p{0.5cm}|p{0.5cm}|p{0.6cm}|p{5cm}|p{0.55cm}|p{0.55cm}|p{0.6cm}|} +\hline +\multicolumn{3}{|c|}{\cellcolor{gray! 30}} & +\multicolumn{3}{c|}{\cellcolor{gray! 30}\textbf{Initial Risk}}& +\multicolumn{1}{c|}{\cellcolor{gray! 30}} & +\multicolumn{3}{c|}{\cellcolor{gray! 30}\textbf{Residual Risk}}\\ +\hline +\cellcolor{gray! 30}\textbf{\#}&\cellcolor{gray! 30}\textbf{Hazard}&\cellcolor{gray! 30}\textbf{Risk}&\cellcolor{gray! 30}\textbf{L[5]}&\cellcolor{gray! 30}\textbf{S[5]}&\cellcolor{gray! 30}\textbf{RV}&\cellcolor{gray! 30}\textbf{Control Measures}&\cellcolor{gray! 30}\textbf{L[5]}&\cellcolor{gray! 30}\textbf{S[5]}&\cellcolor{gray! 30}\textbf{RV}\\ +\hline +\cellcolor{gray! 30}\textbf{1}&Drones&Drone fails and falls on player’s head&3&4&\cellcolor{orange! 90}12&Net separates drones from players; players wear helmets&1&3&\cellcolor{green! 100}3\\ +\hline +\cellcolor{gray! 30}\textbf{2}&Walls&Players run into walls in the dark&5&2&\cellcolor{orange! 90} 10&Players wear helmets; reflective tape placed on wall edges&2&1&\cellcolor{green! 100} 2\\ +\hline +\cellcolor{gray! 30}\textbf{3}&Drones&Drone fails and blade shards fall of player’s head/in eyes&2&3&\cellcolor{yellow! 100}6&Net separates drones from players; players wear helmets; players wear eye protection&2&1&\cellcolor{green! 90}2\\ +\hline +\cellcolor{gray! 30}\textbf{4}&N/A&Heart/asthma attack from exercise&1&5&\cellcolor{yellow! 100}5&Players are barred from playing if they have serious pre-existing health conditions; employees are trained in first aid and will call first responders&1&3&\cellcolor{green! 100}3\\ +\hline +\cellcolor{gray! 30}\textbf{5}&N/A&Trips and Falls&4&3&\cellcolor{orange! 90}12&First aid kits are distributed; employees are trained in first aid - players must wear appropriate footwear&3&2&\cellcolor{yellow! 100}6\\ +\hline +\cellcolor{gray! 30}\textbf{6}&N/A&Fire&2&5&\cellcolor{orange! 90}10&Sprinkler systems are installed; employees are familiar with evacuation plans; no smoking laws are enforced&1&3&\cellcolor{green! 100}3\\ +\hline +\cellcolor{gray! 30}\textbf{7}&Guns&Contact with Eyes&4&4&\cellcolor{red! 85}16&Players wear eye protection; guns marked with reflective tape&3&2&\cellcolor{yellow! 100}6\\ +\hline +\cellcolor{gray! 30}\textbf{8}&N/A&Players run into each other in the dark&5&3&\cellcolor{red! 85}15&Players wear helmets; vests are marked with reflective tape&4&2&\cellcolor{yellow! 100} 8\\ +\hline +\cellcolor{gray! 30}\textbf{9}&Battery&Explosion/Fire&2&5&\cellcolor{orange! 90}10&Battery is charged according to guidelines and are regularly inspected by qualified persons&1&5&\cellcolor{green! 100}5\\ +\hline +\end{tabular} +\label{tab:risk-assessment} +\end{table} + + +% \begin{figure}[H] +% \centering +% \includegraphics[width=0.75\linewidth]{figs/risk-assessment} +% \caption{Quantitative Risk Assessment} +% \label{fig:risk-assessment} +% \end{figure} + +\newpage +\section{Commercialisation and Financial Modelling} +\label{commercialisation} +\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 calculate the \gls{npv} of a company providing the game as a commercial enterprise. +\subsection{Numerical Estimations} \label{num-est} +\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}. 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 \say{maximum utility} refers to the value at which utility plateaus, not a fundamental limit, which is referred to as a \say{utility capacity} (discussed in section \ref{PriceAnal}). 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 +\caption{Number of employees with time} +\begin{tabular}{|c|c c c c c|} +\hline +Year & \qquad 0 & \quad 1 & \quad 2 & \quad 3 & \quad 4 \\ +\hline +Percentage of Maximum Utility & \qquad 0\% & \quad 50\% & \quad 75\% & \quad 100\% & \quad 100\% \\ +\hline +Full-Time employees & \qquad 2 & \quad 2 & \quad 3 & \quad 4 & \quad 4 \\ +\hline +\end{tabular} +\label{tab:utilityandemployees} +\end{table} +\noindent It was 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 effect on \gls{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 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 \say{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 \cite{mediaperformancePaidSocial}. 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 + +\noindent Therefore, the projected required advertising budget is given by Eq. \ref{equ:advertising}. +\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} +Electricity costs account for heating, lighting and charging of batteries. Details are given in the following sections. + +\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. The warehouse is assumed to have U-Values three times greater 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 +\caption{U-Values} +\begin{tabular}{|c|c|c|} +\hline +&Max. U-Value for newly built house [\(\text{W/m}^2\text K\)]& Assumed U-Value for warehouse [\(\text{W/m}^2\text K\)]\\ +\hline +External Walls & 0.26 & 0.78 \\ +Roof (pitched)& 0.16 & 0.48 \\ +Floor & 0.18 & 0.54 \\ +\hline +\end{tabular} +\label{tab:U-Values} +\end{table} \newline +\noindent Assuming the air changes completely every two hour-long games (ACH=0.5), the height of the warehouse is 6 m, and the footprint is square: + \begin{align} + &\text{Total Wall Area}=4 \times \sqrt{632}\text{ m} \times 6\text{ m}=603\text{ m}^2 \\ + &\text{Floor Area}=\text{Roof Area}=6800 \text{ ft}^2=632\text{ m}^2 \\ + &\text{Total Volume}=632\text{ m}^2 \times 6\text{ m}=3792\text{ m}^3 + \end{align} +\noindent Assuming average daytime temperature is 10\(^\circ\)C, and the desired temperature is 20\(^\circ\)C, \(\Delta T=\)10\(^\circ\)C: +\begin{equation} +\dot Q_\text{heating}=0.78\times603\times10+0.48\times632\times10+0.54\times632\times10+0.5\cdot \frac{1.225\times1005\times3792\times10}{3600}=17.6\text{ kW} +\end{equation} + + +\paragraph{Lighting} \(\) \newline +To calculate the lighting costs, it is assumed the warehouse requires fifty 100~W equivalent LEDs, each drawing 15~W 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 turned on one quarter of the time. Therefore the effective power of the lighting is given by \(\dot Q_\text{lighting} = \frac 14 \times 50\times100\text{ W} = 1.3\text{ kW}\). + +\paragraph{Batteries} \(\) \newline +Batteries in drones and laptops used by employees both must be charged. Both are assumed to be charged by standard 65 W 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_\text{batteries}=20\times 65\text{ W}=1.3\text{ kW}\). + +\paragraph{Total Power} \(\) \newline +Under the assumptions outlined above, the total power draw of the operational warehouse is approximated to \(17.6\text{ kW}+1.3\text{ kW}+1.3\text{ kW}=20.2\text{ kW}\). + +\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 Eq. \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} + +\noindent 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. 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 +\caption{Income \& Expenditure projection - all values in £k} +\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} +\label{tab:IE} +\end{table} + +\noindent 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 + +\noindent Bank loans are much more \say{unforgiving}: if the company fails to make repayments, it must declare bankruptcy. Private investment requires no such repayments. Investors make money on their investments through share appreciation and dividends instead. 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 + +\noindent 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 \say{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} +A numerical value of discount rate, \(d\), must be chosen. Two common approaches to model discount rate are: Equity-Only Discount Rate, and \gls{wacc}. +\paragraph{Equity-Only Discount Rate} \(\)\newline +Using an Equity-Only Discount Rate, the discount rate \(r_e\) applied to future cash flows is set by investors. For a small, high-risk start-up, \(r_e=20\%\) aligns with the estimates of business advisors~\cite{EquityDiscountRate}. This ignores debt interest from the bank, so 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 Eq. \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 \say{effective} discount rate, or \gls{wacc}, used in \gls{npv} calculations. The \gls{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 \gls{wacc}, it is not necessary to model the loan and debt repayments as cash flows, or the remaining balance as a liability; these are all captured by the use of \gls{wacc}. According to venture finance consultancy Phoenix Strategy, a realistic value of the cost of debt is \(r_d\approx 8\textendash 15\%\)~\cite{CostOfDebt}.\newline + +\noindent Therefore, for the sake of simplicity, and conservatism, \gls{wacc} is used in this model, with rates: +\begin{equation} + r_d=15\% \qquad r_e=20\% +\end{equation} + +\noindent The effect of a variation in discount rate is analysed in Sections \ref{NPVProfile} and \ref{DPS}. + +\subsubsection{Terminal Value (TV)} +\label{TermValue} +The \gls{tv} of a business describes its \say{left-over} value, after a given period of time. After \(t\) years, with annual cash flow (positive cash flow corresponding to profit) in year k, \(\text{CF}_k\), \gls{tv} 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 \gls{tv}; 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. Income 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 paid \(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} + +\noindent 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 £20,000 in Year \(n\), and makes a profit of £60,000 in Year \(n+1\), its taxable income in Year \(n+1\) is £40,000. Losses can be carried over indefinitely. + +\subsection{Net Present Value} +A running total cash flow is tabulated. This is discounted according to the year in which the money is made. The \gls{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, \gls{npv} remains constant. In the following sections, \say{\gls{npv}} refers to this stabilised value. + +\paragraph{Assumptions} \(\) \newline +For simplicity, it is assumed that a constant \gls{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 Eq. \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} + +% Increase box height? +\begin{table}[h] +\centering +\caption{Full Financial Model Summary - all values in £k} +\begin{tabular}{|c| c c c c c c c c c|} +\hline +\gls{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} +\label{tab:model} +\end{table} + +\noindent The Discounted Cumulative Cash Flow turns positive in Year 10 (payback is discussed in section \ref{DPS}).\newline + + +\noindent It is found that the \gls{npv} is £68669. Hence, the business is viable under these assumptions. + +\subsection{Analyses} \label{anal} +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{\gls{npv} Profile} +\label{NPVProfile} +A common measure of a business' viability is the effect of a variation in the discount rate on \gls{npv}, and analysis of the \gls{npv}-Discount Rate graph that this analysis produces, as shown in Fig. \ref{fig:NPV-Profile}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Cropped/NPV Profile Cropped.png} + \caption{\gls{npv} Profile} + \label{fig:NPV-Profile} +\end{figure} + +\noindent The discount rate at which \gls{npv} is zero is 22.3\%. This is known as the \gls{irr}. Using \gls{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 \gls{npv} profile shows that a small reduction in discount rate produces a large increase in \gls{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, as shown in Fig. \ref{fig:dis-pay-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Cropped/Discounted Payback Sensitivity Cropped.png} + \caption{Discounted Payback Sensitivity} + \label{fig:dis-pay-sen} +\end{figure} + +\noindent Payback increases with Discount Rate. However, Payback only decreases 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 do 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. \newline + + +\noindent 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} + +\noindent 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} +\noindent In a linear model, \(\varepsilon\) is not constant. Therefore, 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, or \say{utility capacity}. In reality, only one game can be played at a time. The capacity 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. The effect of a variation in reference elasticity is analysed in Section \ref{ElasticityAnal} + +\paragraph{Finding optimal price} \(\) \newline +The variation of \gls{npv} with game price was investigated. The results are shown in Fig. \ref{fig:pri-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Cropped/Sensitivity_Analysis_Price_Elastic_Utility_Cropped.png} + \caption{Price Sensitivity Analysis (Reference Elasticity = -1.1)} + \label{fig:pri-sen} +\end{figure} + +\noindent It is observed that, given \(\varepsilon'=-1.1\), a game price of £200 per game maximises \gls{npv}. \newline + + +\noindent The linear left-most section of the graph corresponds to a constant utility of 3000 games per year. In this section, \gls{npv} is hugely negative. Therefore, attempting to setting the game price such that the facility is running at capacity is a very poor decision. \newline + +\noindent \gls{npv} is only positive for prices between £160 and £240 per game (to the nearest £10). This is a very narrow range, demonstrating the importance of this analysis. + +\paragraph{Utility Sensitivity}\label{UtilityAnalFixedPrice} \(\) \newline +\noindent 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 in this estimate was investigated. Price per game was held constant, maximum games per year was varied and the resulting \gls{npv} was tabulated. The results are shown in Fig. \ref{fig:uti-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Cropped/Sensitivity_Analysis_Utility_Fixed_Price_Cropped.png} + \caption{Utility Sensitivity Analysis (Fixed Price)} + \label{fig:uti-sen} +\end{figure} + +\noindent \gls{npv} is only positive for a maximum utility above 1900 games per year (rounded to the nearest 50). This is very close to the estimated 2000 games per year, indicating that high utility is critical. This justifies the high advertising budget. + +\paragraph{Variation of Optimal Price with elasticity} \label{ElasticityAnal}\(\) \newline +This process was repeated for reference elasticity \(\varepsilon'\) between -0.5 (very price-insensitive) and -3 (very price-sensitive). Since the effect on \gls{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 \gls{npv}), it is only useful to tabulate the optimal price per game (price that maximises \gls{npv}) and plot this against reference elasticity, as shown in Fig. \ref{fig:opt-cos-sen}. + +\begin{figure}[H] + \centering + \includegraphics[width=0.6\linewidth]{figs/Finance/Cropped/Optimal_Cost_per_Game_vs_Ref_Elasticity_Cropped.png} + \caption{Optimal Cost per game against Reference Elasticity} + \label{fig:opt-cos-sen} +\end{figure} + +\noindent 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} +The discount rate was assumed to be constant with time, which is unrealistic. This was done for the sake of simplicity, as well as conservatism. Furthermore, the analysis was conducted by changing one or more variables and observing another, while all others were held constant. By changing all variables at once to create a multi-dimensional surface, optima of \gls{npv} may be found that were missed in the above analysis, either by brute force or multi-dimensional gradient descent. + +\subsection{Conclusions} +Under the conservative assumptions laid out above, the value of a theoretical business offering a drone-based laser tag experience was found to be approximately £69,000. From the analyses carried out in Section \ref{anal}, it was found that: +\begin{itemize} + \item £200 per game is the optimal price to charge per game (per group). + \item The viability of the business depends greatly on early revenue and on small changes to custom, justifying a large advertising budget. + \item £69,000 is likely an underestimate, since the value of the business will significantly increase with time as discount rate decreases. +\end{itemize} +\noindent This suggests that is it possible to offer drone-based laser tag as a commercially viable service. + +\newpage + +%%%%%%%%%%%%%%%%-----------End of Commercialisation----%%%%%%%%%%%%%%% + +\section{Sustainability} %Rickie +\label{sustainability} +\fancyhead[C]{Shing Hei Rickie Chan} + +As the system is intended for repeated commercial use, sustainability is considered, as impacts come not only from initial jump-start stages but also from operation and maintenance. This section assesses these trade-offs through the triple bottom line: environmental, social and economic impact. + +\paragraph{Environmental Impact} + +The drones are electrically powered, so they produce no direct emissions during flight inside the arena. However, the main environmental impact comes from manufacturing, charging, and eventually disposing of the drone itself, and all components within. The batteries likely have the shortest service life as they degrade with repeated charge cycles and would need replacement periodically. Other components may last longer if protected from impact and overheating. To reduce unnecessary waste, the drone uses a modular airframe with detachable parts, allowing damaged or worn parts to be replaced individually. However, the material choice still has limitations, as \gls{abs} is not biodegradable. + +\paragraph{Social Impact} + +The main social impact of the project is its ability to provide entertainment while maintaining safety. The game design uses \gls{ir} tagging rather than physical projectiles or laser systems. The drones are separated from players by overhead net, while blade guards, collision avoidance, helmets and vest provide an additional layer of protection. This ensures the system is acceptable for use in a commercial arena, where players of many different backgrounds and ages come to enjoy the game. The cooperative modes and companion app encourages teamwork and repeat engagement, although this may depend on careful supervision during game-play. + +\paragraph{Economic Impact} + +The economic impact is considered through the commercial model, which tests whether the system could operate viably after accounting all aspects of the overall system design. The report estimates the drone cost under \pounds500 each, with full hardware replacement assumed over 500 games. At a projected price of \pounds200 per group, the model suggests that annual non-discounted profit could stabilise at around \pounds75000. This supports the economic side, but only if usage is high and replacement costs are strictly controlled. + +\paragraph{Limitations} + +The system should not be considered fully sustainable. Issues such as waste and replacement of electronic components, general consumptions of arena management, and usage of non-biodegradable \gls{abs} material mean that the system cannot be considered impact-free. +\newpage +%%%%%%%%%%%%%%%----------End of Sustainability--------------%%%%%%%%%%%%%%% +\section{Technology Strategy} +\label{technology_strategy} +\fancyhead[C]{Rishabh Luthra} + +\subsection{House of Quality} +\begin{figure}[htbp] + \centering + \includegraphics[width=0.7\textwidth]{figs/House of Quality.png} + \caption{House of Quality} + \label{fig:hoq} +\end{figure} + +To translate customer requirements into measurable engineering specifications, a House of Quality matrix was developed. This methodology maps core user desires directly onto system capabilities to prioritise technical development. To ground these targets in reality, the matrix benchmarks the proposed design against two distinct alternatives. Traditional indoor laser tag serves as the commercial competing product, establishing baseline expectations for user experience and affordability. Conversely, the DJI Mini 5 Pro~\cite{dji2026mini5pro, dji2026transmission, parkcameras2026mini5pro} acts as the technical competing product, defining the state-of-the-art standards required for drone mass, flight endurance, and processing capabilities. + +\newpage +\fancyhead[C]{Thomas August} +\subsection{SWOT Analysis} +We conducted a \gls{swot} analysis in order to evaluate the internal capabilities of the project against its external commercial environment. Internal factors assess our product design, deployment processes, and \gls{ip}, while external factors isolate market conditions, regulatory frameworks, and competitive pressures. This strategic planning framework establishes a baseline to exploit our distinctive competencies and address structural weaknesses. + +\begin{figure}[htbp] +\centering +\begin{minipage}{\textwidth} +\begin{tcbraster}[raster columns=2, raster row skip=1mm, boxrule=0mm, arc=0mm] +\begin{tcolorbox}[equal height group=A, size=fbox, colback=swotS!60, colframe=swotS!80!black, title=\textsc{Strengths}] +\textbf{Business} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item High-value interactive experience +\item Financially viable business model +\item Strict safety risk mitigation +\end{enumerate} +\tcblower +\textbf{Product} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item Modular 3D-printed airframe +\item Synthetic data vision training +\item \gls{rl} movement policy +\end{enumerate} +\end{tcolorbox} +\begin{tcolorbox}[equal height group=A, size=fbox, colback=swotW!60, colframe=swotW!80!black, title=\textsc{Weaknesses}] +\textbf{Business} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item High initial capital requirement +\item Unverified user adoption rates +\item Single venue limits scaling +\end{enumerate} +\tcblower +\textbf{Product} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item Sim-to-real domain gap +\item Unvalidated physical hardware durability +\item Ten-minute flight endurance limit +\end{enumerate} +\end{tcolorbox} +\begin{tcolorbox}[equal height group=B, size=fbox, colback=swotO!60, colframe=swotO!80!black, title=\textsc{Opportunities}] +\textbf{Business} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item Expansion into competitive esports +\item Hardware and arena franchising +\item Licensing tracking software IP +\end{enumerate} +\tcblower +\textbf{Product} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item \gls{rl} policy refinement +\item Battery upgrades +\item Computer vision learning +\end{enumerate} +\end{tcolorbox} +\begin{tcolorbox}[equal height group=B, size=fbox, colback=swotT!60, colframe=swotT!80!black, title=\textsc{Threats}] +\textbf{Business} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item Fluctuating real estate costs +\item Established leisure market competitors +\item Evolving autonomous drone regulations +\end{enumerate} +\tcblower +\textbf{Product} \vspace{-1em} +\begin{enumerate} +\setlength{\itemsep}{3pt} +\setlength{\parskip}{0pt} +\item High physical maintenance costs +\item Network interference in arenas +\item VR laser tag substitution +\end{enumerate} +\end{tcolorbox} +\end{tcbraster} +\end{minipage} +\caption{SWOT analysis} +\label{fig:swot_analysis} +\end{figure} + +The analysis shows that our core technical strengths, specifically the modular airframe and simulation-trained software, constitute distinctive competencies that deliver high value. While the simulation-to-real domain gap remains a structural weakness, it can be mitigated through empirical refinement. Externally, the high initial capital requirement is a typical financial symptom that can be offset by long-term franchising and licensing opportunities. However, commercial viability remains sensitive to external threats, particularly evolving autonomous drone regulations and technological substitutions such as virtual reality (VR) laser tag. + +\newpage + + + +% Appendix +% Essential content that interrupts the flow of the document can be placed here, e.g. technical drawings, detailed lists of equations used, etc. +\addcontentsline{toc}{section}{Appendix} +\section*{Appendix} +\fancyhead[C]{Group} + +% \paragraph{Heating cost assumptions}\label{assumptions}\(\) \newline +% \noindent Assume a complete air change every two hour-long games (\(\text{ACH}=0.5\)), a warehouse height of \(6\text{ m}\), and a square footprint. +% \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{Total Wall Area}=4\times\sqrt{632\text{ m}^2}\times6\text{ m}=603\text{ m}^2 +% \end{equation} +% \begin{equation} +% \text{Floor Area}=\text{Roof Area}=6800 \text{ ft}^2=632\text{ m}^2\qquad \text{Total Volume}=632\text{ m}^2\times6\text{ m}=3792\text{ m}^3 +% \end{equation} + + + +% \begin{equation} +% \text{Total Volume}=632\text{ m}^2\times6\text{ m}=3792\text{ m}^3 +% \end{equation} + + +% \noindent Assume average daytime temperature 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}=17.6\text{ kW} +% \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} + + + + +\begin{figure}[htbp] + \centering + \includegraphics[width=1\linewidth]{figs/High-Level/StateFlow2.png} + \caption{Flow Chart Describing High-Level Mode Changes} + \label{fig:FlowBig} +\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 +\fancyhead[C]{Group} +\printbibliography{biblio} + +\includepdf[pages=-]{GroupC-Supporting-Statement.pdf} +\end{document} \ No newline at end of file