Sync mechanism should be the responsibility of the camera module

[Akustav]

https://github.com/ut-robotics/picr21-team-shaq/blob/8ae20e5501d61d2b16a69e7d05405c0ee861823d/src/Detection.py#L76-L86

Frames should be provided by the camera module. Sync mechanisms should also come from there.

https://github.com/ut-robotics/picr21-team-shaq/blob/8ae20e5501d61d2b16a69e7d05405c0ee861823d/src/vision.py#L48

This line waits until a new frame is produced by the camera. Maybe it not smart to have every module thread running haywire and instead have a chain of operations being executed consecutively.

[Tsapu]

For now the main module just reads vision.masks at full speed (I moved all processing into vision.py). I actually don't know how can you make things running on separate threads procedural, but as for sync I believe it's inconsequential in the large scheme of things, the way it's set up now.

[ReikoR]

For syncing you could have boolean variable (called has_new_frames for example) that is set to True after self.pipe.wait_for_frames() and False after some method is called that returns frames.

But better option is probably to get rid of most or all of the current threads. They should not be needed, since things (getting frame, processing frame, calculating movement, sending speeds) need to run sequentially.

Threads might be useful for image processing if there are things that can be done in parallel to improve to processing speed. Processing different colors in parallel might be useful.

[Tsapu]

I think the current thread setup is fine. Camera produces image masks and the main thread just reads them as fast as possible for whatever operation is needed so no information is lost and I don't see the need to throttle the main line.

The thread originally noted in this issue doesn't exist anymore.

[ReikoR]

It might work fine, but if the main thread runs faster than the camera framerate, then it processes frames multiple times, which is unnecessary.

[Tsapu]

Framerate drops three times with has_new_frames waiting