Enhanced Tracking Feature Discussion

Proposed by SebastienFricker

Hi Kenneth,

I had a discussion with Angel, and I think that this point is close on my side. I think I will need 1-2 week to support this interface. So as soon as available, I can start the implementation. Also, if there is a need for your developments, I can start the earlier, simply let me know.

I generate the version 0.2.0 of xmotion, which permits to configure motion remotely. In the next days I will work on the viewing of live picture (and after on a GUI for tuning motion). The function should permits to the actual picture and also to send tild and pan commands. I don’t have any motorized camera, do you know anybody which would test this function?

I have an other point: I would like to use a camera with incorporated zoom and so use the tracking function of motion. The actual implementation has actually some limitations and I would like to modify the code to be more adapted.

Limitations:

1. A lot of cameras can be driven using the serial interface. The only problem is that the protocol is in most of the cases proprietary.
2. The tracking algorithm is mosly dependant of the environment. So It is generally necessary to program specific strategies. Fro example: For my camera with zoom, I would like that the camera zoom to the point where the motion is detected. If nothings happened, I would like that the camera goes into the wide angle position.

Due to the fact that this operations doesn’t request a lot of CPU. I think that we can use a pipe mechanism to implement it. So motion will generate 2 processes and send and receive the commands using the standard IO.

1. Camera Control Process: The process receive the commands via the standard input. The API for the command could be the actual one for the Serial Stepper Motor, and we can extend it later.
2. Camera Stragegy Process: The process receive the informations about the captured pictures via the standard input and write on the standard output tracking commands.

Configuration:

We would need 2 new configuration entries which specify the command line for the Camera Control Process and Camera Strategy Process.

What do you think about this proposal?

Finally, I would like to know how I can work on the motion code. Would I have access to the CVS or should I generate patches?

---

Good initiative. Let us refine it and try to see where we want to go and agree what is in Motion and what is not.

Motion supports few cameras today. The Logitech Sphere/Orbit is supported most because it is a common camera and you cannot control the camera by external programs while Motion is using the video device. Video4Linux1 does not allow more than one connection to the device so tracking has to be performed by Motion. This is why we implemented the manual pan/tilt interface for Motion.

Cameras controlled by a serial interface do not need to be controlled this way.

A more generic interface that allows Motion to control any pan/tilt/zoom camera is a good idea.

Implementing a feature where you manually control the PTZ through Motion makes little sense in itself. The external program can simply access the serial port directly. But if the auto tracking control output is implemented and we already have the manual tracking API for the Orbit/sphere - there is not reason not to also let the manual commands work with the external interface.

Today the tracking feature in Motion does not work very well. It is simply not good at tracking Motion. It points the camera to the wrong location all the time. So this should be addressed first to make any point to implementing the more interface code.

-- KennethLavrsen - 03 Dec 2004