Project Motivations
The introduction of digital radios to the RC community brought accessibility and freedom from interference. Before digital radio was the norm a frequency manager was necessary to allocate a channel to a single user as people using the same frequency would end up trying to control the same plane, boat or car. This is the current state of FPV or First person View which uses analog frequency to send video from a drone or plane down to a user that is piloting it. The analog frequencies have no interference management so if another drone is using the same frequency as you are your video feed will show the data with the greatest power which basically blows you out of the sky. This is extremely important to know during a FPV drone race as you could easily end someones chances at winning just by plugging your drone in at the wrong time and they will most likely get angry with you…
This is the motivation behind this project, unlike the radio control analogy, video contains much more data. The control link has a very narrow bandwidth and contains a small amount of information which can easily be digitized without any loss in performance. Video on the other hand needs a very wide bandwidth due to its high data content ie bits per second. There are digital systems for transmitting video but they require the video to be encoded which unfortunately takes time. Why is time important? Well time between the something happening and getting displayed on a screen is called latency or lag. As any gammer will tell you lag is the bane of their existence because it inhibits the ability to accurately control something. The latency in the video stream inhibits the pilots ability to react and control the drone in real time. Therefore even a few tens of milliseconds delay can cause you to crash.
Starting Architecture
An automatic frequency manager would use digital tokens to allocate frequencies to a drone pilot, the drone could then configure its video transmitter and the pilots goggles to be set to that frequency. When the race is over the token is revoked and the drone can no longer transmit on that frequency. This is not a new system but an adaptation to a simple resource management system that is used almost ubiquitously. The novelty come in how we get this to work on the tiny drones that races are currently using. I am investigating wifi enables single board computers and smaller chips such as the ESP8266 and the ESP32 to provide the interface to control the drone’s video transmitter and to read information from the flight controller. A small device will also be attached to the video goggles to configure its frequency as well.
The back end of this system will focus around a server that can be run on the race manager’s computer and interact with the current software suite that is used to manage MULTI-GP races.
This is just the basic overview of the architecture, more posts showing the progress I have made so far coming soon!
