Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
⚠️ This documentation is outdated! A current version is available at openhdfpv.org
⚠️ Important Note: OpenHD does not support ANY autofocus cameras due to their impracticality on equipment with vibrations, such as drones. This restriction includes the official Raspberry Pi V3 lineup.
On the Raspberry Pi, you have the option to choose between two CSI camera modes.
The Broadcom MMAL mode is the legacy camera stack. It only works with original Raspberry Pi Foundation cameras or clones that have the security chip. While it offers better latency compared to libcamera, it has been deprecated by the Raspberry Pi Foundation in favor of libcamera. OpenHD uses Broadcom MMAL as the default option, as done in previous OpenHD releases.
The libcamera mode works with both original Raspberry Pi Foundation cameras and a wide range of other cameras. Generally, you can achieve the same or even better image quality using libcamera by selecting the appropriate CSI camera. However, it might not provide the same latency as broadcom mmal.
You can switch between Cameras using QOpenHD (V_OS_CAM_CONFIG), but it requires a reboot.
Note: Autodetection is not available for identifying whether you've connected a camera supported only by libcamera/libcamera-ardu. You must manually select the appropriate CSI camera mode in QOpenHD for OpenHD to detect your CSI camera.
Note: We use a proprietary version of the libcamera library, which ensures compatibility with arducam and normal libcamera while also providing image adjustments which are normally excluded in gstreamer-libcamera. This version is licenced to OpenHD and not Open Source.
Tip: When choosing between the camera modes, consider your latency and image quality requirements along with the compatibility of the camera you are using.
⚠️ This documentation is outdated! A current version is available at openhdfpv.org
CMOS
HDMI cameras require the MMAL Overlay.
To use an HDMI Camera, you need an HDMI-CSI Adapter. These adapters enable you to connect cameras with HDMI outputs, allowing the use of a wider variety of cameras beyond the usual Raspberry Pi camera sensor boards. Depending on the camera, this may result in improved picture quality, including support for features like WDR.
Most small/cheap Toshiba chip boards support up to 1080p25 or 1080p30 HDMI camera resolutions on most Raspberry Pi models. The Raspberry Pi Compute Module boards are technically capable of 1080p60, but the necessary driver change to support 1080p60 has not been implemented yet.
Note: If your camera only supports 1080p60 or 4k60 HDMI output, it will not work with the Toshiba boards.
A latency test was conducted by Bortek using the Auvidea B102 with a GoPro4 camera.
GoPro4
SJcam M10
Canon EOS 700D
Cameras That Do Not Work:
Samsung NX500 (1080p60, framerate too high)
Canon EOS M (1080i, interlaced output is not supported by these adapters)
AliExpress link:
This adapter is widely used for OpenHD. It's available through AliExpress and Taobao. Users in the U.S. or Europe may experience delays in obtaining them. For those regions, consider the similar geekworm board mentioned below, available on Amazon.
The adapter is compatible with both Raspberry Pi Zero and full-size Raspberry Pi models, setting it apart from other cards.
Available on Amazon in the U.S., this adapter is similar to the DCDZ adapter mentioned above. Amazon store link: Geekworm store link:
The adapter is compatible with full-size Raspberry Pi models.
More info:
The Auvidea B102 shares similar capabilities with other adapters, but it's only compatible with the Pi Zero.
More info:
Similar to other adapters, the Auvidea B101 is compatible with full-size Raspberry Pi models.
More info:
This more complex (and expensive) card supports HDMI like other adapters, as well as analog component input. However, it's unlikely that any drone-worthy camera uses component connections. The adapter includes LEDs to indicate the status of the camera connection.
A drone-specific HDMI camera with onboard recording to MicroSD, WDR support, and a weight of 60g.
Note that some cameras were shipped without HDMI output. The provided link is reported to be the correct HDMI model.
⚠️ This documentation is outdated! A current version is available at openhdfpv.org
As the Rock5 is a distinct platform and MIPI is not a plug-and-play system, we are awaiting official camera releases for compatibility. We are actively dedicating resources to introduce more camera options in the future.
Currently, the camera support is limited to:
Note 1: There currently appears to be no compatible adapter or camera with this sensor available for the Rock5.
We are working towards expanding the selection of supported cameras and adapters, and we appreciate your patience as we continue to develop and improve camera compatibility
IMX219
1
IMX415*
*
Arducam IMX462 B0333
*
1
Arducam IMX708 B0310
*
1
Good WDR
$75
Unknown
Good WDR
$75
⚠️ This documentation is outdated! A current version is available at openhdfpv.org
OpenHD supports and recommends the following cameras on the Raspberry Pi:
*This cameras use mainly raspivid which is legacy and discontinued. These cameras aren't really recommended for FPV, since V1,V2 of Raspberry cameras do not provide a good image outdoors, and the HQ camera is much bigger and more expensive then smaller versions of it. V1 sensor is also not produced anymore and V2 sensor is about to follow.
More information about CSI-HDMI can be found .
Cameras not listed here may potentionally work, but aren't tested and configured.
We only integrate Cameras which are tested and fitting to the purpose of openhd. If you want to get new cameras supported ask your camera vender to support OpenHD development with their hardware, but contact us first at developer@openhdfpv.org
While many cameras can potentially work, latency is the biggest issue. Please read the Camera pages to fully understand all variables.
When using multiple Cameras you need to choose one Camera-Subsystem, so you can not use libcamera and raspicam at the same time. This means f.e. you can not use an Veye-Camera and an Arducam camera at the same time.
When using multiple Cameras the second camera is using Software decoding and encoding, it is not recommended to use a high quality camera. It is generally made for a thermal camera or something with lower resolutions.
With the upcoming of many new camera's there is one thing we need to mention. OpenHD is not supporting ANY autofocus cameras, since they are basically not usable on equipment with vibrations (like drones), this also includes the Raspberry V3-lineup
We also want to thank our cooperation partners for providing the Team with Prototypes and want to specifically thank for helping us in developing cameras specifically to our need.
Supported Cameras *
Can be enabled and used easily (No custom scripting), in case things don't work you can ask us for help.
Recommended Cameras **
Among the available options, we highly recommend the top 3 cameras as they offer unparalleled versatility and optimization for OpenHD. These cameras stand out for their exceptional image quality, low latency, extensive feature set, and suitability for professional applications. If you are currently without a preferred camera choice, these top recommendations are guaranteed to provide unique benefits and fulfill your requirements.
⚠️ This documentation is outdated! A current version is available at
The RPI HDMI to CSI adapter provides a means of interfacing HDMI output from cameras to the Raspberry Pi platform. However, it's important to note that this adapter is not officially supported by the Raspberry Pi Foundation, and as a result, it presents certain challenges and limitations. Here's a concise rundown of these quirks:
Encoder Bitrate Control: One notable issue is the unreliable performance of the encoder bitrate control. This often results in fluctuations like overshoot and undershoot in the bit rate. To mitigate this problem, it is recommended to disable variable bitrate and instead manually set a conservative bitrate, such as 8 MBit/s for MCS3 encoding.
Resolution and Framerate Configuration: Configuring the resolution and framerate through the adapter can be problematic and may even fail in certain instances. To enhance the likelihood of successful configuration, it is advised to set the camera resolution to match exactly the resolution and framerate output by your HDMI source.
Maximum Resolution and Framerate: The Raspberry Pi hardware encoder is constrained to a maximum output of 1080p@30fps or 720p@60fps. Consequently, it's important not to select an HDMI output video signal from your camera that exceeds these limits.
Reliable Adapter Detection: For consistent and reliable detection of the HDMI to CSI adapter during boot, it is crucial to sequence the power supply. In practice, ensure that the OpenHD system is powered on after your HDMI camera. This ensures that the adapter receives a valid HDMI input signal prior to the initialization of the Air Pi system.
While the RPI HDMI to CSI adapter serves as a bridge between HDMI cameras and Raspberry Pi devices, its unofficial nature can lead to these operational quirks. Users seeking to employ this adapter should be aware of these limitations and implement the recommended workarounds for optimal results.
⚠️ This documentation is outdated! A current version is available at openhdfpv.org
OpenHD has the ability to automatically detect and utilize USB cameras that provide either raw uncompressed or pre-encoded (h264, h265, mjpeg) data streams. However, it's important to note the following potential limitations:
Fixed Encode Bitrate: Cameras with a fixed encode bitrate may not support features like variable bitrate. This could necessitate manual tuning of your connection settings.
Suboptimal Encoding Parameters: Some cameras might have encoding parameters that lead to issues such as increased latency or poor error recovery in your stream. Thoughtful adjustment of these parameters is recommended for optimal streaming performance.
RAW Format Challenges: Cameras that deliver RAW data require software-based encoding, which can impose constraints on achievable resolutions and frame rates. This limitation persists even on powerful platforms like the Raspberry Pi 4.
By being mindful of these potential challenges, users can make informed decisions about camera selection and configuration to ensure the best possible streaming experience with OpenHD.
High Quality
$37
libcamera_imx519
Arducam
low weight,small
$37
libcamera_imx477
Raspberry Pi Foundation
Normal
$25
MMAL
Raspberry Pi Foundation
Normal
$25
MMAL
Raspberry Pi Foundation
HQ
$50
MMAL
Arducam
Normal
$75
libcamera_imx477
Arducam
Low Light
$60
2
Arducam
HQ Mini fixed focus
$35
libcamera_imx519
Arducam
Low Light
$30
libcamera_imx290
Arducam
Low Light
$30
libcamera_imx327
Arducam
Ultra Low Light
$60
libcamera_imx462
VEYE
Low Light
$90
veye_cam2m
VEYE
Low
Germanium
iRay
256Ă—192
25hz
FLIR Boson 320
Germanium
FLIR
320x256
9hz/60hz
FLIR Boson 640
Germanium
FLIR
640x512
9hz/60hz
Arducam
Highest Quality
$37
libcamera_imx708
Hti-201
Chalcogenide
Raytheon
320x240
9hz
Hti-301
Germanium
iRay
384x288
25hz
2
up to 1080p@30fps
2
up to 1080p@30fps
4
up to 1080p@30fps
Arducam
Infiray T2 search
⚠️ This documentation is outdated! A current version is available at openhdfpv.org
As part of the larger OpenHD ecosystem, the OpenHD custom hardware project aims to develop a specialized camera designed to work seamlessly with the OpenHD Custom Hardware project.
The custom cameras will be optimized for use in drone racing and aerial videography applications, offering high-quality imaging capabilities and low latency transmission. They will be designed to integrate seamlessly with the OpenHD Custom Hardware system, providing a complete end-to-end solution for drone enthusiasts.
The OpenHD custom hardware project is currently in development, and prototypes are being tested and refined to ensure optimal performance and reliability. As the project progresses, the team will be working to create a final version of the cameras that meets the needs of drone racing and aerial videography enthusiasts.
If you would like to learn more about this project and stay up-to-date on its progress, be sure to visit . The team is always looking for new supporters and contributors to help bring this exciting project to life.
OpenHD supports a variety of thermal cameras, including the Hti-301, Infiray T2, and others.
Thermal cameras typically connect via USB and need to be enabled as secondary cameras.
Thermal cameras are not like ordinary cameras. It's important to review available information about each camera before making any purchase decisions.
Surprisingly, a thermal camera with a resolution of 204x156 can be notably worse than one with an 80x60 resolution. The entire thermal imaging system matters, from lens material and size to the sensor type, sensor resolution, and image post-processing by the camera.
Any weak link in the system can severely degrade the image, making it unsuitable for specific uses. Sometimes, this trade-off is acceptable to achieve a lower price point.
Additionally, remember that while a thermal camera might be useful for close-up electronics work or basic household tasks, it may not perform well for drone flight.
Thermal cameras are highly regulated items, so legal requirements can impact purchasing decisions. Depending on your location, you may need to pay a higher price, obtain licenses, or face limitations on buying certain cameras.
Regulations often center around frame rate, not resolution. This is due to the potential use of thermal cameras in weapons.
For countries part of the Wassenaar agreement, buying 30/60Hz thermal cameras is possible, although prices may be higher if imported from the United States.
Direct purchase options are available from Chinese companies like Hti Instrument on platforms like AliExpress and TaoBao. If obtaining FLIR or Seek cameras from the U.S. proves difficult, alternatives like Hti might be more accessible.
Consider what you will realistically see with a specific thermal camera in various situations.
Low-resolution thermal cameras might show a hot object in an area but not identify it. While this could work for search and rescue, situations requiring higher thermal resolution might necessitate better cameras.
Remember that thermal cameras have much lower resolutions compared to typical FPV cameras. For instance, a 1280x720 FPV camera has 48x the resolution of a 160x120 thermal camera. At greater distances, the main FPV camera might be able to see an object while the thermal camera cannot.
Also, consider the thermal "span" of the area in view. If everything has nearly the same temperature, the image could be noisy or flat. In such cases, a low NETD rating and a larger lens are necessary.
Here are brief descriptions of individual cameras mentioned earlier. Carefully read this information before purchasing any of them.
A high-quality thermal camera with 384x288 resolution, a large germanium lens, and a 25Hz frame rate. Though more expensive, its thermal performance is excellent. These cameras work as regular webcams, requiring no special driver.
A 320x256 thermal imager core with a 60Hz frame rate. Expensive but equipped with Germanium lenses. Primarily designed for integration in larger camera systems or drones. Requires an appropriate connection board. Export controlled due to the high frame rate.
The lens on a thermal camera isn't ordinary glass (which doesn't allow IR wavelengths to pass through).
Germanium lenses offer high-quality thermal images but are costly. Many lightweight thermal cameras use Silicon or Chalcogenide lenses instead.
In most cases, you can't replace a thermal camera lens unless it's designed for it. Even cameras with removable lenses often require careful handling to avoid damage.
IP cameras cannot be automatically detected, as they lack a common protocol like USB cameras. They also require custom scripting for integration and lack support for bitrate adjustments, making them quite bad for long range sytems. They also don't support adjusting the keyframe interval, which can black out your video for several seconds when having any interference.
To implement IP cameras, you can utilize the custom_unmanaged_camera.sh script, which needs to be activated through the hardware.conf configuration.
For advanced users, we have implemented "scripting support," which allows for custom camera pipelines, IP cameras, and general debugging.
Currently, there are several example pipelines available for:
OpenIPC cameras
General IP cameras
Seek Thermal cameras
This feature requires disabling auto-detection and needs manual activation in the hardware.conf configuration file.
Step 1 Before setting things in OpenHD, first configure the following things in the IP camera:
Setup static IP for the camera. Configure a H.264 rtsp stream and test it in a program like VLC.
After that, you are ready to start with OpenHD configuration.
Step 2
To configure the camera, you need to configure a script that starts the network connection to the camera and then starts the Gtreamer pipeline. Over this you also need to create a service that executes this script when the air sbc is turned on.
To configure the pipeline to the camera you need to modify the script “custom_unmanaged_camera_old.sh” in air sbc. Rename it to “custom_unmanaged_camera.sh”. After that, open the script and you will find different examples of configuration for connection to different cameras. Copy “setup_and_stream_ip_cam_siyi_h264” configuration and rename it to a different name. Now to configure “LOCALIP” and “GATEWAYIP” with the same first 3 numbers as your IP camera IP and with the last number being different in all 3 cases. Then you need to change the stream link in the Gstreamer pipeline command with the correct one of your camera. The configuration should look like this:
Step 3
At the bottom of the script, comment all the configurations and put the name of the new one you have created and save the file. Finally, open a terminal and execute the following command “sudo chmod +x PATH/custom_unmanaged_camera.sh” with the correct path to the file.
Step 4
To create the service that activates the script you must follow the next steps. Download the following file (https://github.com/OpenHD/OpenHD/blob/2.5-evo-rapha/systemd/custom_unmanaged_camera.service) that isn't included in version 2.6.0 of OpenHD. You need to copy that file in /boot/etc/systemd/system/ but you need to do it using the terminal with the command “sudo cp ORIGINPATH/custom_unmanaged_camera.service DESTINATIONPATH/etc/systemd/system/” where both “originpath” and “destinationpath” are correct paths. After that you are ready to turn on air sbc and follow next steps. Connect a monitor and a keyboard to air sbc and exit from kiosk mode using Ctrl+C. After that, activate the new service using “sudo systemctl enable custom_unmanaged_camera” command. Following that, start the service with “sudo systemctl start custom_unmanaged_camera” command and then confirm that it is active with “sudo systemctl status custom_unmanaged_camera” command. Reboot air sbc with “sudo reboot” and it should be ready.
Step 5
To configure the visualization in QOpenHD go to the menu and setup the camera as DEV=>External.
Note 1: The custom unmanaged camera service requires careful testing and doesn't provide automatic functionality right away. It is intended for advanced users and developers who understand its intricacies.
We encourage you to experiment with this feature, but please be aware that it's meant for users with a good understanding of camera pipelines and system integration.
IP-Cameras are not specifically designed for low latency, and many of them have latency upwards of 500ms+, but there are specific cameras available for purchase that have reasonable latency closer to 100-200ms. Remember this latency will be added to the "normal" latency your system has. So most IP-Camera Setups will have 300-600ms latency. It is not recommended to use an IP-Camera as primary camera. That means the main reason to choose an IP-Camera is to enable some custom features normal Cameras do not support.
