Articol disponibil numai în limba engleză
The VifuLens is an interface designed with the aim to provide remote control for B4-mount broadcast lenses and PT(Z) head, using VISCA commands sent over a TCP network. It comprises of a microcomputer connected to the LAN, an analog interface that connects directly to the zoom, focus and iris (ZFI) connectors of the lenses and a RS-232 serial port that connects to the pan and tilt head (PT(Z)). While originally designed for Fujinon broadcast lenses and PTZOptics broadcast pan & tilt head combination, it can be adapted to other scenarios as well.
I started developing this hardware interface and its related software within a specific project I worked on, where a system consisting of several Micro Studio Camera 4K cameras, MTF B4 lens adapters, ZA17x7.6BERD lenses and PT-BRDCSTR-P PTZ heads had to be installed. The interface turned out to be a necessity, because the PTZ head controller model, which was specifically requested for that project, has been originally designed to connect to remote lens control of compact camcorders, not to independent B4-mount broadcast lenses type which usually equips ENG or EFP cameras.
Although the PT-BRDCSTR-P proved to be an excellent product in terms of sturdiness and movement precision, it has no provisions – at least not in the version I played with – to set an absolute positioning value for zoom, because its electrical zoom interface is designed to provide relative levels voltage output, just enough for zoom in / zoom stop / zoom out. Zoom status reading (lens position feedback) is not implemented and also focus and iris status reading back of own previously given positions did not seem to be implemented either – something that was explicitly required within my specific project.
Note: in principle, driving the lenses via a serial connection (on digital series lenses providing a serial communication feature) would have been a better solution*, but because I didn't know right from the start the exact model of the lenses, combined with the very short time I had at my disposal to get the job done on that specific project, I thought it was unrealistic to come to an end right on time – so that's why I opted for an analog lenses driving solution, which is also somewhat more universally compatible.
* In this case, “better” means fewer wired connections to the lenses and just a little bit more accurate ZFI positioning.
The VifuLens hardware interface includes own DAC and ADC converters and analog voltage level shift circuits for each of the ZFI controls. The voltage level shift circuits translates the 0V-2.047V range of the local DAC converters to the 2.5V-7.5V range as required for lens control – and vice versa, from 2.5V-7.5V range of the lens status into the 0V-2.047V range for feedback reading with the local ADC converters. As for the precision when storing and then recalling ZFI positions, the inherent dispersion related to analog component tolerances is insignificant for human perception.
To be noted that, while each of the ZFI control has and can use its own ADC hardware converter, in current software implementation it is only the zoom that actually uses the ADC feedback – while focus and iris controls just read back the “direct drive” value as passed to their respective DACs.
The hardware interface is built on top of a Raspberry Pi 2 Model B v1.2 Industrial. I deliberately chose Pi 2 instead of Pi 3, for good reasons: Pi 3 dissipates a lot more heat and also exposes some sharing trouble – though solvable – on the UART port, all which is disadvantageous for this project.
Note: Raspberry Pi 2 has no native Wi-Fi interface; if wireless connection is really necessary or perhaps advantageous for a given configuration, the lack of the embedded Wi-Fi interface can be easily overcome by using a USB Wi-Fi dongle with the Raspberry Pi 2.
The software running the interface is written in Python. All ZFI commands are processed locally, whereas all pan and tilt commands are sent to the PT(Z) head “as is”. ZFI presets are stored locally on the micro SD card, while the PT(Z) presets are stored natively within the pan and tilt head. Up to 255 presets can be stored, which is far more than the usual range as specified under the standard CAM_Memory VISCA control commands category.
The zoom control accepts two operating command modes: a “Standard” mode for full speed zoom movement and a “Variable” mode that tries to emulate the “seesaw” mechanical control lever of the real lenses. For variable mode, there are 8 steps of progressive speed control for each zoom direction, a number which is specified during the CAM_Zoom Tele(Variable) and CAM_Zoom Wide(Variable) VISCA control commands. All these movement speeds are in turn dependent on the zoom maximum speed control knob, located on the lenses servo.
Absolute zoom positioning was not directly possible due to the relative nature of the “seesaw” command as required by the electrical interface of the lenses servo in analog drive mode, therefore I implemented a software digital comparator that keeps in sync the physical zoom position as read via the ADC converter with the CAM_Zoom Direct VISCA control command position; otherwise, when absolute zoom positioning is not required (e.g. during “normal” zoom in / zoom stop / zoom out commands), the comparator gets deactivated.
The circuit schematic diagram can be seen here . Although fully functional, the circuit is at its first incarnation and may receive further improvements. For example, I may add an additional electronic switch circuit for the focus and iris command to the lenses, so that the remote control on these can be deactivated programmatically. At the moment, only the zoom provides such a switch circuit.
I designed the actual PCB using the Sprint Layout program, which for me is still the easiest method to create printed circuit boards. However, I assume that the printed circuit board can be designed based on – for example – the project that I created using the KiCad program just for drawing the diagram.
The software that runs on Raspberry Pi is available below for download. It should run under Python v3.5 and requires the Adafruit_Python_ADS1x15 library that must be installed under Python 3.
Note: current software version is 1.7 (click here for versions history)
The folowing VISCA control commands are implemented:
|command set||command||command packet||comments|
|CAM_Zoom||Stop||8x 01 04 07 00 FF|
|Tele (Standard)||8x 01 04 07 02 FF|
|Wide (Standard)||8x 01 04 07 03 FF|
|Tele (Variable)||8x 01 04 07 2p FF||p: speed parameter, 0 (Slow) to 7 (Fast)|
|Wide (Variable)||8x 01 04 07 3p FF|
|Direct||8x 01 04 47 0p 0q 0r 0s FF||pqrs: zoom data, 0x0000 (Wide) to 0x0FFF (Tele)|
|CAM_Focus||Stop||8x 01 04 08 00 FF|
|Far (Standard)||8x 01 04 08 02 FF|
|Near (Standard)||8x 01 04 08 03 FF|
|Far (Variable)||8x 01 04 08 2p FF||p: speed parameter, 0 (Low) to 7 (High)|
|Near (Variable)||8x 01 04 08 3p FF|
|Direct||8x 01 04 48 0p 0q 0r 0s FF||pqrs: focus data, 0x0000 (Close) to 0x0FFF (Infinity)|
|Infinity||8x 01 04 18 02 FF||forced infinity|
|CAM_Iris||Reset||8x 01 04 0B 00 FF||defaults to f5.6 approx.|
|Up||8x 01 04 0B 02 FF||single step iris opening|
|Down||8x 01 04 0B 03 FF||single step iris closing|
|Direct||8x 01 04 4B 00 00 0p 0q FF||pq: iris data, 0x00 (fully closed) to 0x11 (fully open),
in 17 steps equivalent to c, f28, f22, f19, f16, ...,
..., f2.8, f2.4, f2.0, f1.8 approx.
|CAM_Memory||Clear||8x 01 04 3F 00 pq FF||pq: maximum 255 presets, from 0x00 to 0xFE|
|Set||8x 01 04 3F 01 pq FF|
|Recall||8x 01 04 3F 02 pq FF|
|Note: for VISCA over IP, camera address “x” is locked to 1.|
|command set||command packet||inquiry packet||comments|
|CAM_ZoomPosInq||8x 09 04 47 FF||y0 50 0p 0q 0r 0s FF||pqrs: zoom position|
|CAM_FocusPosInq||8x 09 04 48 FF||y0 50 0p 0q 0r 0s FF||pqrs: focus position|
|CAM_IrisPosInq||8x 09 04 4B FF||y0 50 00 00 0p 0q FF||pq: iris position|
|Note: for VISCA over IP, camera address “x” is locked to 1 and camera address “y” is locked to 9.|
Any other VISCA command not mentioned above is passed directly to the PT(Z) head through the RS-232 serial port (9600 8N1).
The software uses a built-in TCP socket server that listens to port number 5678. The port number can be changed with parameter SERVER_PORT (currently on line 36 of the vifulens.py file).
At power-up, the software tries to load preset 0 in order to set initial ZFI position values – and the same should normally go for the PTZ head on its own. If preset 0 is not found as in case it was never saved or prior deleted, then the power-up position values for ZFI are set by parameters TEMP_ZOOM_DAC, TEMP_FOCUS_DAC and TEMP_IRIS_INDX (currently on lines 110, 111 and 112 of the vifulens.py file.
No default enclosure is provided, yet. The VifuLens circuit board requires 5V power supply with minimum 2.5A capability and provides its own DC connector. The Raspberry Pi does not require a separate power supply. To be noted that the hardware includes a few operational amplifiers that requires 12V power supply, which is taken from the lenses servo through the Hirose conectors (the required current for the op amps is negligible).
One way to control the VifiLens interface – and so the camera system – is by using a hardware joystick controller, equipped with serial communication interface. That was the situation in my case, so I had to develop a serial to IP conversion program – and that is RSIP, a RS to IP software companion for VifuLens.
The RSIP software is written in Python and can serve up to 2 joystick controllers – which in VISCA terms that means control for up to 7+7 cameras. Right from the start I designed it to run either on Raspberry Pi or on Beaglebone Black.
The Raspberry Pi has only one UART on it, while Beaglebone has four; however, all their UARTs are just at internal logic levels, which means a suitable hardware interface must be used with either of their UARTs in order to be able to use standard RS-232 connections. Because that means another hardware hassle and because the Raspberry Pi has only one native UART anyway (while I needed to control 10 cameras), I used two commercial serial to USB adapters.
(under construction / working on)
(under construction / coming soon)