Hi, I’m working on integrating a Nextvision camera with my setup (arducopter 4.5.1.) and I have it all working, but there is a considerable lag on the gimbal control, much larger then on the video itself. I have pitch and yaw of the gimbal control assigned to two springed wheels on my RC and I’d say that there is a lag of up to 1s between my physical input (moving the wheel) and actual movement of the camera.
I do not think that this is due to radio connection lag, as the lag on the video itself is present, but considerably smaller (approx. 1/4 s.).
I started experimenting with the stream rates, particularly, the SR2_RC_CHAN (the gimbal is using telem2 output). This parameter requires an AP reboot. So after setting this param to 10Hz instead of 1, and rebooting, there is a significant improvement in the gimbal control, but it only lasts about 10 seconds. After this time the lag is back on. I reboot via Mission Planner → Actions → Preflight Reboot Shutdown. All this time, before, durin, and after the reboot, everything else is ON, and the video stream is present throughout all this time.
When I refresh the parameters, the SR2_RC_CHAN is back to 1.
I do not have anything else in the system - this happens during bench tests. The only things I am using is: Chinowing T30 RC with V21 Air module radio, TRIP2 camera controller, camera itself and a Cube Orange.
So there are no other peripheries that might “request” a parameter change from the autopilot. So strange! I doubt that the TRIP itself is forcing the parameter change, as the documentation of the device clearly states, that the proper stream rates should be adjusted manually by the user.
Can anyone shed some light on the issue? Maybe someone had some similar experiences?