Unsolved How to implement Non-queued, opportunistic SIGNAL/SLOT
-
I am working to develop a tracking algorithm. Its grabs video frames, encodes and sends a MJPEG video stream, runs a tracking algorithm on the frames, and directs a gimbal to follow the object of interest.
I pass the tracking information from the algorithm to the class that directs the gimbal (Which is in another thread) using a signal/slot. I want the tracking algorithm to always process video frames at 60Hz. The gimbal can only receive commands at ~15Hz. The encoder/MJPEG server keeps up pretty well while the system is not overly stressed. The problem is that the signal/slot starts queuing the track information it cannot process immediately, the memory footprint starts to grow, the other signals/slots in my code seem to stop operating, and the wheels just generally come off.
I would like to be able to emit a signal from the tracking algorithm with the track information. If the gimbal class can immediately process the tracking information it does. If it is still busy processing the last track information received, the new track info is dropped.
I tried connecting the SIGNAL/SLOT using Qt::DirectConnection and then implementing a mutex that would return if the gimbal class was still busy with the last information. The mutex looks like this:
if(!pidMutex.tryLock()) { qInfo() << "Could not lock PID"; return; }
But "Could not lock PID" is never printed. So I don't think this approach is working. Is there another way to try to do what I'm doing?
-
hi @black_spot1984
can this help ? -
@black_spot1984 said in How to implement Non-queued, opportunistic SIGNAL/SLOT:
I want the tracking algorithm to always process video frames at 60Hz. The gimbal can only receive commands at ~15Hz.
Can you average the last 4 or 5 sets of tracking info and send that to the gimbal? 60/4 = 15. You would need to somehow monitor the queuing of the signals/slots and average more tracking info as a throttle. Or just find a number of averagers that never causes it to fill up and use that.
-
Hi,
In addition to what @fcarney suggested, you could also use a queue to store your tracking info and if it starts to grow too big, drop the too old data.
-
I would restructure the process more towards a ready-read framework.
Basically the flow would be:- the gimbal sends a signal to the tracking algorithm that it is ready to process a track
- the next track that come through will be sent by the tracking algorithm via signal-slot to the gimbal
- the tracking algorithm will then discard all tracks until it receives another signal from gimbal
- once gimbal finishes processing a track sends the signal notifying that it is ready for more
- repeat
Hope it is clear enough
-
Thank you all for your suggestions I'm still learning a lot here!
@VRonin, this seemed like the most straightforward way to solve the problem. I am going to use this method to solve this problem.