Two Raspberry Pis, two supported WiFi adapters, one Pi cam (Or CSI-HDMI adapter), and 2 good quality (preferably industrial micro SD cards).
Please read the rest of the documentation and do your homework when you make your purchases! Only specific WiFi cards will work due to the unique system requirements. Good results are only achieved with proper power supply and wiring!
On a Raspberry Pi, 100ms “glass to glass”. Although most setups are in the 125ms range.
The easiest way to reduce latency is to use OpenHD on a "potent" X86 Laptop, it'll reduce the latency a lot. (This was tested on a "hp omen en1179ng" )
On a Jetson Nano as Air-SBC you can expect to lower the latency, but no official numbers are published yet.
The lowest latency can be achieved on our custom hardware combined with a X86-Ground. There are no official numbers yet, but you can expect to cut your latency in half, which makes OpenHD repsonsive enough to fly on race/freestyle-setups. It's not released yet, but you can follow our progress on the OpenHD Hardware Patreon page.
It depends. 1-3KM is easy to achieve, even with low power WiFi cards and the antennas that come with them.
Carefully chosen WiFi cards, antennas, and optionally an antenna tracker should put 20km+ within reach. The current record is 75km on 5.8GHz frequency with a 30dbi gain panel antenna.
YouTube video of 60km flight
YouTube video of 75km flight
OpenHD is optimized to regain the connection fast and without interaction, the time it needs to reconnect is very low (can be counted in ms).
OpenHD does not generate a solid blue screen when interference is encountered. When experiencing a loss of signal, you will see progressive artifacts and pixilation, finally the image freezes. The telemetry and/or RC link is more robust and will often continue to operate well beyond the loss of the video stream.
OpenHD generally operates in 5.8GHZ, but can also use the 2.4GHZ band (depending on your setup), which should allow you to choose a band your RC transmitter isn't using. You can also send RC control commands through OpenHD itself and thus avoid using 2 different transmitters. There are tradeoffs however. Control latency might be slightly higher than a dedicated RC system and there are currently some limitations on the channel count (16channels maximum).
If you're planning a long range flight and want to have the "best" setup for range, we advise you to use the OpenHD control link, since even with carefully seperated frequencies the range can be affected by any radio signal due to the increased noise floor.
A computer on a single circuit board. In this case running a derivative of Linux. Don't worry, you do not need to know anything about the software side. We have that covered!
No, just one adapter for ground and one for air. You can optionally use 2 WiFi adapters on the ground side for diversity, which improves signal reception.
In OpenHD > 2.2 most of the code has been rewritten. This means that we're much less hardware bound and support for new SBCs could be added in the future. Officially we currently differentiate between air and ground.
Ground:
The most optimized Platform on the ground is the Raspberry Pi, but if you have quite capable hardware, x86 will give you even better latency than the Pi.
Not every USB-port is able to supply the Wifi-Adapter with enough power. Please ensure enough power is supplied to the WiFi adapter before flying. The standard 500mA isn't enough. Also, if you do any PowerMods, we're not responsible for any potential damage.
Older computers or SBCs may not be fast enough to run OpenHD.
Air:
The lowest latency platform is our custom hardware. The second best latency will be achieved with on Jetson Nano (which as limited camera support). The most flexible platform will be the Pi, but it can only encode h.264 video, which will result in increased latency.
Officially we can not support every platform, but we optimized OpenHD to be enable being ported to different SBCs.
Most SBC's have very limited camera support (since cameras need to be specifically adapted to the ISP) and doesn't make sense using as Air, which is a shame.
You can also run the groundstation (including QOpenHD) on different platforms, but since every SBC handles decoding/compositing/rendering differently, we can't really optimize everything and the workload for our devteam is limited. Therefore we only officially support Pi and x86 on the ground.
Only a few WiFi adapters are able to work the way OpenHD needs them to, which limits the selection of WiFi adapters you can use. We use a custom kernel, which requires drivers for each new card. Basic requierements are monitor mode and packet injection. If the card is stable in both modes and the injection rate is high enough, we can potentionally integrate it.
The built-in WiFi chip on the Raspberry Pi does not work the way OpenHD needs it to for video broadcast, however it can still be used for hotspot purposes, which allows you to connect Android and other devices to the ground station over normal WiFi in order to receive the video signal.
Jetson Nano does not have an included WiFi-card, so it can't be used to create a hotspot. You can use usb-tethering or ethernet though.
There are many possible causes of interference.
You might be experiencing interference from normal WiFi devices nearby. If that is the case, try another frequency or change your physical location. In most cases if you are outside in a suitable location for flying, there are not many normal WiFi devices around.
If you have a long CSI camera cable attached, it may be generating or receiving interference. You can test this by wrapping it in copper foil or getting a shorter cable. The kind of interference you will see in this case is very specific, it will look like perfectly straight vertical lines.
The AirPi and GroundPi may also be too close to each other, if you are testing on the ground. This can cause the receiving WiFi card to be overloaded.
It is generally necessary to solder power wires and even the USB data wires directly to the WiFi adapters and Raspberry Pi. The Raspberry Pi's USB ports are not capable of supplying enough power to power hungry WiFi cards. In some cases the USB connectors can briefly disconnect during flight, which might lead to total video loss. If you are still seeing interference or even video freezes, this should be the next thing for you to address.
In OpenHD 2.3 you can get low power warnings when your BEC is not able to supply enough power. Please change it to a more powerful one. In addition to that, carefully check and wire the WiFi cards correctly in order to avoid power issues.
Two WiFi adapters on the Ground are supported.
eBay
Amazon
banggood.com
AliExpress
TaoBao (chinese marketplace)
Due to the global chip shortage it is currently not that easy to buy all the required hardware. Try to use rpilocator or buy used hardware.
Keep in mind that OpenHD 2.3 dropped support for Pi-Zero, Pi1 and Pi2 (lower than 1.2).
OpenHD uses normal WiFi hardware, which is perfectly legal to buy and use.
OpenHD can be disruptive to nearby WiFi networks due to the continuous broadcast though. OpenHD starts at 25mW transmit power, which is allowed in every part of the world. It can be configured to use power levels and frequencies which might not be legal in your location, so please check your local regulations before use.
You are responsible for your use of the system, but please ask us for advice if you are concerned about a particular setting or use case.
Yes, you can receive the video with any GroundPi that is configured to the same frequency as your AirPi.
In future releases we'll add a "BindMode" which will only allow people with a passphrase to view your video.
A way to improve the reliability and quality of video reception.
Diversity is currently not enabled in 2.2, but will be added in later versions.
If you connect 2 or more WiFi adapters to the GroundPi, whichever adapter is currently receiving the best signal will be used. This is entirely automatic and occurs in realtime. You do not have to change any settings or monitor anything.
Some OpenHD users connect different kinds of antennas to the 2+ WiFi adapters, such as a directional antenna and a normal omnidirectional antenna. This allows for automatic switching from long range to short range, so that you don't have to keep your directional antenna pointed towards the UAV when it is nearby.
FEC is a way to add redundancy to the video stream.
Since the latency must be kept to a minimum, there is no opportunity to retransmit parts of the video that were distorted by interference. Instead, the system will process the video in a way that allows for some of the data to be lost in transmission, without affecting the received video on the GroundPi.
There is a cost to using FEC. The radio bandwidth is a little bit higher (or viewed another way, the maximum video bitrate/quality is a little bit lower). However it is mandatory for safe flight. Without FEC, the video would be very easily distorted.
In OpenHD 2.2 we started to highly focus on latency. The first releases will have a pretty average latency, but currently we're saving every ms we can. With 2.3 we returned to the same latency, which ez-wifibroadcast had, which was significantly lower than previous OpenHD releases. Thanks to the use of h.265 video encoding (not available on Raspberry Pi) and custom hardware we are able to reduce the latency even more.
See Telemetry and OSD
We reduced the RC protocols down to only MAVlink, since nearly every FC firmware supports MAVLink.
We reduced the telemetry protocols down to only MAVlink, since nearly every FC firmware supports MAVLink telemetry.
This is a shorter way to refer to which SBC is transmitting video from the UAV and which SBC is transmitting RC and/or uplink telemetry. Both are using the same OS images.
Circular antennas are known to be very effective in suppressing signal reflections (multi-pathing), which degrades the quality of analogue transmission.
Digital systems are not affected by multi-pathing though (and often can take advantage of it). Circular antennas are not as important as they would be with an analog video system.
However, circular antennas still have some advantages compared to linear antennas:
They work independent of angle to each other, almost no polarization losses.
Typically circular antennas have a lower gain, and thus higher opening angle than linear antennas.
Less susceptible to signal blocking from nearby solid objects.
Use the system! There are a lot of different features, settings and possible hardware combinations, it can be very difficult to test everything each time we release an update. As a result, we depend on users to tell us when something is wrong or if something should be improved.
If you have any development experiences and time, we're always open to new developers which want to help improve and extend our codebase.
We also frequently need translators who can read/write both english and another languages, as the system supports translation in the OSD.
And of course if you have an idea for something you would like to see us add or change, let us know in Github issues, on the Forum, Discord or on Telegram.
If you want to support the project financially, you can do so via OpenCollective.
The easiest way to flash OpenHD images is to use our ImageWriter, just select the Image in the drop down and click flash.
In the advanced tabs there are the images for X86 and Jetson devices.
With 2.3-evo we removed the complex config files. Everything is set up in QOpenhd or the ImageWriter.
OpenHD is setup to automatically setup and connect. On the Air you just get a Command Prompt and no interaction is needed. On the Ground QOpenHD will start automatically and give you a GUI. If not you may have made an error while flashing, please remember selecting GROUND while writing your SDCard.
In general the image writer writes the image, mounts it and writes a file (air.txt) or (ground.txt) into the folder openhd. You just need to do this manually without the ImageWriter. In the future there may be a lot more functionality coming, which then just needs to be done manually.
You need to enable the hotspot in the QOpenHD settings first, it is disabled by default.
With 2.3-evo we extended the camera support a lot, but to do this we needed to add a way to handle all the new cameras. Autodetection isn't that easy anymore. As default all MMAL cameras are selected, but you can select the right Overlay for your camera in AIR_tmp. The overlays are listed in our camera-tabs in this wiki.
Not all cameras are usable, that's why we do not support each and every camera, you can try if it is compatible with one of our overlays, if not it isn't compatible. In general we do not recommend (or actively) support Autofocus cameras, since they are highly susceptible to vibration which can even damage your camera.
On this page we're documenting, the most appearing "bugs/issues" and how to fix them, also we're adding a little troubleshooting information, which will help to understand and document the issue you're having.
In the newer Realtek drivers the LED isn't controllable anymore, meaning we can not turn it on to show that the device is working.
Since we can not control it, blinking or not even turning on the LED is no indicator of the device or software is malfunctioning.
In evo we do not have any display-stats or indicator that the software is running. It'll show up a regular Terminal for debugging. OpenHD is setup to automatically setup and connect. On the Air you just get a Command Prompt and no interaction is needed.
If you want to see if openhd is running, you can type in "systemctl status openhd", this will show some stats.
OpenHD is setup to automatically setup and connect. On the Ground you should get QOpenHD (our OSD). If it didn't you may have made an error while flashing, please remember selecting GROUND while writing your SDCard.
With OpenHD evo we stopped support on some platforms, all ARMv6 devices are not supported anymore.
If you did not connect a camera or didn't select the correct overlay a test-picture is shown. Select the right overlay and check if your csi-cable is connected correctly.
Since Libcamerasrc doesn't have any support for settings, yet you can't change picture settings like exposure,rotation,.. in it. When they become available we're integrating them.
We don't have extended i2c settings for veye cameras, since veye didn't integrate them in standard v4l2 controls.
Right now we do not have Battery monitoring on the ground, but this is currently in the works.
If you need special drivers and need to use KMS as the display driver, we can not support that, since low latency modes are only available on FKMS.
Make sure all your devices are powered via seperate BEC's and you have a keyboard available
You can check the status of openhd with "systemctl status openhd"
For better debugging please download the journal from our webinterface and provide it when contacting us in our Telegram Chat.