These are commercial systems that have been fully or partially integrated into the application. Hardware from this list can usually be set up with a couple of mouse clicks.
If your system is not yet directly supported or you have built your own gear, it's still most likely possible to connect your cameras with the application.
It will just take a little more configuration.
The following list contains all the different types of cameras that you can use:
- Digital CCTV cameras
Supported transmission protocols: RTSP, HTTP(S)
Supported compression algorithms: H264, H265 (upon request)
- HD Analog cameras
The output of High definition analog cameras can be converted to HDMI using video converter adapters (TVI/CVI/AHD to HDMI) There are different products like this. Depending on your hardware, one tends to work better than the other. Once you have an HDMI signal, it can be captured using an HDMI capture device. Most of these capture devices register themselves as windows cameras, which is what you'll need.
- CVBS Analog cameras
Some basic, older inspection cameras only have a composite connector to output video. We have had pretty good results (relatively speaking) with Elgato video capture devices
- Windows compatible capture devices If your camera supports H264 compression and is available in windows, it will most likely work.
- Import video files
Most camera systems are also able to capture video data on an sd-card or some other external storage. These files can be imported into the application and the inspection data can afterwards be added. CAM-I currently supports the import of following file formats:
Sometimes also called tractors. These machines need to provide information such as distance traveled, pitch, roll,...
Sometimes the application can also control them, up to a level of degree.
It is possible to define data maps for crawlers that send out binary data, where each packet contains all the required data. With such a data map, you can say which value can be found at which position in the byte stream and how it should be read (little/big endian, nr of bytes) without having to write any code or change the application.
The following communication protocols are supported:
- Serial port
- TCP based
The following types of sensor are currently supported by the application. The values for these sensors are usually provided by the crawler, but can also be from another peripheral that is connected to the system.
Sonar images are great to see something underneath the waterline. They allow you to see where the edge is or if there are objects on the bottom.
With lidar, you get really fast, perfect distance measurements above the water level. These can be used to perform measurements and get a depth-view of the entire inspection.
Accelerometers measure acceleration across the x, y and z axis. This doesn't just allow you to verify that your device began or stopped moving, but also when the crawler hits something or falls on it.
Roll and pitch are probably the most common sensors on crawlers. They will provide a warning if the system goes over certain thresholds. With the yaw value, it's also possible to recreate the traversed path.
When the crawler is able to report the travel distance, the system can calculate it's speed.
Some crawlers have pressurized parts. It can be vital for the system health to keep this in check.
- Battery level
If the crawler runs on a battery, it's best to know when to go back to base.
The system can use the built-in location system of the OS, when available or a USB-based GPS module. Currently, the following protocol is supported: NMEA 0183, 2.3
Tested hardware: 4Tracer pi module
- laser range
Measure the distance to the wall using a laser. This can either be a stand-alone sensor that reports the distance by itself (usually through the datapacket sent by the crawler). Or the measurement can be performed by tracking 2 laser dots on the image using visual analysis.