RotorHazard is an open-source FPV drone race timing software and hardware project, which provides a multi-node radio frequency race timing system for FPV drone racing with event management as well as many other facilities.

RotorHazard is a non-commercial open-source project, devised and written by volunteers. The project is listed on Github, where users can access Hardware designs, PCB layouts and comprehensive Software for FPV Drone Racing and Race Management and more.

The RotorHazard system comprises of Nodes (which detect the RF signals), Node-Managers (which collect and time the data), the RotorHazard Server (software to manage the entire system and provide an easy-to-use web-based user interface), as well as various optional components such LED boards, Audio etc.

There are many possible Hardware configurations within RotorHazard for collecting the race times, but all are based on "nodes" that detect the passing of the transmitted video signals from each FPV racing drone. The advantage of this approach is that, apart from the FPV Video Transmitter, no additional hardware is required on the drone itself.

The nodes detect the RF signal strength of the passing drones and the node-manager collects and timestamps the information, to be used by the RotorHazard server.

The RotorHazard server is a Python-based software suite, that manages the whole system and provides information for race directors, pilots and spectators alike through a unique and user-friendly web-based user interface. The system can incorporate one Server or more, with secondary servers acting as mirrors.

RotorHazard can be equally suited to single-user practice sessions, small group races and large organised race events.

In its simplest form, a single node can be connected via USB or WiFi to a RotorHazard server that runs on any device that can run Python code, such as a Raspberry Pi or a Laptop (Windows, Apple OS and Linux are all supported), where users can get an audio call out of times or view the results on any web browser (eg smartphone). Equally, RotorHazard can handle highly complex hardware setups, involving a start/finish timer, numerous split timers (eg on each gate), a central server and several mirror servers, LED panels, Audio out, WiFi and 4G/5G routers etc etc.

Interfaces and Plugins can be developed, for example for Drop gates and similar starting gate latches, or for Video Streams / OBS.

The RotorHazard node hardware uses RX5808 type receiver modules (nodes) to trigger lap times. The nodes detect the 5.8GHz RF transmission signal strength levels from each drone. The RX5808 Video Receiver modules (VRXs) provide the system with a stream of RSSI numbers.

RotorHazard supports multiple nodes (currently up to 16).

The hardware then includes a node-manager (eg an MPU board) to collect and timestamp the RSSI levels from the nodes and identify the signal peaks, which indicate actual drone passes. Various sophisticated techniques are used to identify peaks, including Topological Data Analysis (Persistent Homology), Filters etc. The system provides options for Auto-Calibration, Self-Calibration and Manual Calibration, user-selectable from the Server Interface / Webpage.

For the Hardware, users can choose from a variety of low-cost MPU boards as node-managers. The node-managers can be Arduino boards, such as Nano 328 boards, STM32 boards (such as Blue Bill), ESP32/8266/M5Stack boards and the like. Equally, RotorHazard has interfaces for node hardware from other similar systems, including ImmersionRC's LapRF and Puck, Chorus32 and Delta5. Also, the RotorHazard server itself has the ability to provide Software-based nodes, for example for testing purposes.

Some node manager boards (such as STM32 Blue Bill and ESP32) can control several nodes at once, or just one node at a time (eg Arduino Nano 328). Moreover, node managers can get a single node to switch between frequencies rapidly, thus providing the ability to time several quads with a single node.

Physically, the interface between the nodes (VRXs) and the node-manager (MPU board) is hard-wired (see PCB Options below).

The node manager (MPU board) listens on a specified frequency on the nodes (VRXs) and communicates times to a central RotorHazard server (usually a Raspberry Pi). The RotorHazard server's front-end interface, which any device on the same network can connect to via web browser, offers race organizer management and pilot/spectator information.

There are various options for interfacing the node-manager with the RotorHazard server and ancillary Hardware (LEDs, Audio etc), such as I2C, Serial Bus, USB, Ethernet, Bluetooth etc.

RotorHazard provides several PCB designs which users can get printed (eg by JCL-PCB, PCBWay etc), or purchase ready-printed (eg on eBay). Currently, the list includes:

• 4-way Arduino Nano (two combined make a 8-node system)
• 6-way STM32
• 4-way STM32 (two combined make a 8-node system)

The Node Manager firmware can be found in the repository folder src/nodes.

The firmware will run on a range of MPU platforms, including Arduino Nano, STM32 BPill and ESP32.

The firmware is designed to be compiled using an IDE, such as Arduino IDE or PlatformIO (Visual Studio Code).

The firmware needs to be uploaded to the node managers (eg Arduino Nano, STM BPill etc), using the IDE normally.

The RotorHazard server runs on Python code. Any computer that can run Python with the libraries and dependencies will work. The most popular configuration is for the RotorHazard server to run on a Raspberry Pi 3, although Pi 4 and Pi Zeros are acceptable as server host devices. Equally, the RotorHazard server code can run on a Laptop/Desktop, under Windows, Mac OS-X and Linux.

Just clone the Rotorhazard github source files onto the server computer, complete the installation process (especially bash install.sh) and run the server code as a Python module (eg python -m rh.server).

RotorHazard has the ability to connect to a wide range of optional Hardware add-ons, including LEDs, Audio etc. The setup is configured in the config.json file in the Rotorhazard server's code folder.

Interfaces and Plugins can be developed, for example for Drop gates and similar starting gate latches, or for Video Streams / OBS.

The RotorHazard node VRXs have no antennas connected, which means they will pick up RF transmissions from all directions. For this reason, careful consideration is need for RF shielding of the nodes and positioning of the Node Box/Boxes.

The aim of RF shielding is to exclude unwanted RF transmissions, for example from quads flying around the course, apart from when the quads fly through the timer gate itself.

There are numerous options for RF shielding. An open metal box or canister (eg a Paint Can) works well.

Also, the Node Box/Boxes can be lined with metal foil on all sides apart from the VRX opening. Sticky-backed Copper foil or Aluminum Foil can be used for the lining.

Designs for Horn-shaped housings are also possible, also lined with metal foil.

Documentation for RotorHazard may be found here (as well as at README.md )

If you encounter a bug, please report it using the Issues page on GitHub. When reporting issues, using the "Download Logs" button and including the generated '.zip' file is highly recommended (see below).

The Server Log may be displayed via the "View Server Log" item in the drop-down menu. Clicking on the "Select Text" button will select all the displayed log text, which may then be copied and pasted. Clicking on the "Download Logs" button will create and download a '.zip' archive file containing all available log files and the current configuration and database files.

For instructions on how to build and operate the current version of RotorHazard, follow the [Documentation] in this Wiki

See the RotorHazard Build Resources page for information on race-timer circuit boards and 3D-printable cases.

An easy-to-build single-node version of RotorHazard may also be constructed; see doc/USB Nodes.md for more info.

Note: The 'main' branch in the GitHub repository will usually contain the latest development code, which may not be stable.

RotorHazard is compatible with the hardware specifications of the Delta5 Race Timer. Install the software on existing hardware per the setup instructions, ensuring that you complete a re-flash of the Arduinos.

*** NOTE: At present the RH-OTA tool is not aligned with this version of RotorHazard ***

Paweł Fabiszewski developed a tool that can install or upgrade the server, flash the proper code to the nodes, and even help with network and Raspberry Pi setup tasks. Some wiring is required for node flashing.
Full description and tutorial
Project GitHub Repository

*** NOTE: At present the pre-built SD-card image does not contain this version of RotorHazard, but the image can be used and then upgraded afterwards (see Upgrade Notes above) ***

Dean Fourie covers hardware purchasing, PCB population, and software setup in this very detailed multi-page article. Dean also mantains pre-built SD-card image files for the latest stable and beta releases and makes them available for download.
https://deanfourie.me/delta5-lap-timer/

Klaus Michael Schneider provides a video walkthrough of the Marshal page, explaining post-race recalibration and lap recovery.
https://www.youtube.com/watch?v=xLMa-gRObHI

The AcroBaix Team has produced a series of videos in Spanish covering the timer, calibration, marshaling, and other relevant topics.
https://www.youtube.com/channel/UCLn014XZdAuH_ZFa6KC9ksw

ET maintains information about the RotorHazard project, covering technical details and build notes.
http://www.etheli.com/rotorhazard