If you want a hardware upgrade it's actually reasonably inexpensive to build something direct drive (which is how the real sub-30kg ones work). This gives you many advantages over the plastic gear type including a much faster response time and more accurate positioning.

Look for "gimbal motors", basically a large skinny pancake brushless motor. Combine those with a storm32, simplebgc or odrive and a magnetic encoder. A 3D printer will help.

You can also have a look at low cost suppliers of cheap UAV stuff if you want something fully integrated for you. A basic Gremsy, Viewpro or Siyi isn't that much more than your Amazon thing. Various software bugs but they can be worked around. The DJI units can sometimes be had used and some of the protocols have been RE'd already.

I'm looking forward to doing more experiments including integrating my own payloads (thermal and optical) with an off the shelf motion control system. I also have an automotive radar unit coming which may provide some interesting options for cueing without using ADS-B in some situations (with relatively close targets).

For a project I needed a low-latency RTSP stream as well. When reading a video stream with OpenCV, the default video buffer is quite big, which, when filling up, makes the video lag behind a second or two. It then becomes impossible to perform any interaction on it.

I wasn't familiar with the setting you use to overcome this: setting cv2.CAP_PROP_BUFFERSIZE to 1 on the VideoCapture. I am not sure, but you might get even lower latency by turning to OpenCV's GStreamer support. For me the trick was:

  gst = f"rtspsrc location={video_url} latency=0 buffer-mode=auto ! decodebin ! videoconvert ! appsink max-buffers=1 drop=true"
  self.video = cv2.VideoCapture(gst, cv2.CAP_GSTREAMER)

And it can be combined with a source of ADS-B data so it knows what it's looking at, displaying the info on the OSD.

> Their motors are designed for slow, dampened pans across a stage, not for tracking a jet moving at 300 knots. The mechanical and electronics latency is significant; if you simply tell the camera to “follow that plane,” by the time the motors react, the target has often moved out of the frame.

Is he able to move the motors faster than they are designed to be moved? Is this the __Control (PID + Feed-Forward Loop)__ fix?