Integer arguments for pan/tilt/zoom is preferable for tracking from my plugin. Since the moving speed is not proportional, I'm making a table to convert.
I'm currently using doubles because it was convenient for choosing relative speed. Each camera could have a different range of valid speed values. By using a double I can define "1.0" to mean fastest speed available and then let the PTZDevice instance rescale it to what the camera can do. It could be switched to int, but would need to define a scale for what those values mean.
If I got a bit more sophisticated, the pan/tilt values could be mapped to deg/s. The cameras I'm using (Sony) document that information, but I doubt all cameras do. Would that be useful in the face tracker? I imagine you'd also need to know the lens FOV angle and current zoom ratio to make proper use of it.
Another change is removing `bind`, which I believe is unnecessary for UDP-client. If two or more cameras use the same UDP-port, I didn't try it but I guess it will conflict to receive data.
I need the bind to receive UDP responses from the camera. Sending was no problem, but receiving required the bind. Also, since I've got multiple cameras I need to receive traffic from multiple cameras and send it to the correct device. The current code is very inefficient if there are lots of cameras because received packets are broadcast to *all* cameras using the same socket, but I plan to rewrite that code soon.
Other changes are just removing global variables just in case it conflicts. Your code is well organized that it is easy for me to modify.
Current approach is partially working with VISCA-over-IP but it would conflict if both plugins try to access the same UART port.
Yes, UART will be a problem. I think if we want to support both manual camera control and driving from the facetrack plugin then we need an event/command protocol defined. Having two instances of a PTZDevice for the same camera won't work well in the long term. We'll need to either merge the plugins or have a protocol between them.
I think so, too. The polling is not the best way. I'm not so familiar with frontend and not sure any event can be defined by plugin developers. Maybe also need to define the destination. Using the signal of Qt might work. Because I'm not so good at Qt, one of the difficulties would be making it thread-safe.
From what I've read today Qt signals/slots are thread safe by default. If a signal is sent from a different thread than the receiver then Qt will default to queuing the signal in the receiver's event queue. However, that requires an object that inherits from QObject that can emit a signal from inside the facetracking thread. When the signal is emitted, Qt should notice the different thread and use a queued connection. The following was a helpful read:
wiki.qt.io