"In bee_track each trigger and camera has an 'index' (number attribute) -- what is this and what is it used for?"
This is a good question! The 'index' values are my desperate attempt to match up which photo is associated with which trigger.
In trigger.py the value in self.index.value is saved as metadata in the self.record list's newest item [link]. This index value is incremented.
In camera.py, the self.record should be the same as the list in the trigger object, as the constructor for the camera takes the list as an argument. Whether I've done something that's not thread safe...?
Example from core.py of the camera being created with the record list being passed:
camera = AravisCamera(message_queue, trigger.record, cam_trigger, cam_id=cam_id)
Anyway, in camera.py we look through the list, finding the item with an index that equals the internal camera 'index':
for r in self.record:
if r['index'] == self.index.value:
rec = r
break
if rec is None:
print("WARNING: Failed to find associated photo record")
photo_object = {'index': self.index.value, 'record': rec}
The camera's internal index counts how many photos (including failed ones) have come in (increments here).
The idea is that, hopefully, the number of triggers and number of images coming in match!
This was obviously too optimistic, and for whatever reason this seems to slip... maybe sometimes the camera just doesn't trigger for some reason - or an image is just completely lost due to buffer overflows...
So what I do is I assume that all the images that have been triggered have been read by the time that the /start API call is triggered, and at that point I force the indices to match [code link].
There has got to be a less harrowing way to do all this, maybe there's metadata in the image from the camera I could make use of?! (I think there might be a clock onboard the camera?? this might also help solve the problem of the time 'jitter').
"In bee_track each trigger and camera has an 'index' (number attribute) -- what is this and what is it used for?"
This is a good question! The 'index' values are my desperate attempt to match up which photo is associated with which trigger.
In trigger.py the value in self.index.value is saved as metadata in the self.record list's newest item [link]. This index value is incremented.
In camera.py, the self.record should be the same as the list in the trigger object, as the constructor for the camera takes the list as an argument. Whether I've done something that's not thread safe...?
Example from core.py of the camera being created with the record list being passed:
camera = AravisCamera(message_queue, trigger.record, cam_trigger, cam_id=cam_id)Anyway, in camera.py we look through the list, finding the item with an index that equals the internal camera 'index':
for r in self.record:
if r['index'] == self.index.value:
rec = r
break
if rec is None:
print("WARNING: Failed to find associated photo record")
The camera's internal index counts how many photos (including failed ones) have come in (increments here).
The idea is that, hopefully, the number of triggers and number of images coming in match!
This was obviously too optimistic, and for whatever reason this seems to slip... maybe sometimes the camera just doesn't trigger for some reason - or an image is just completely lost due to buffer overflows...
So what I do is I assume that all the images that have been triggered have been read by the time that the /start API call is triggered, and at that point I force the indices to match [code link].
There has got to be a less harrowing way to do all this, maybe there's metadata in the image from the camera I could make use of?! (I think there might be a clock onboard the camera?? this might also help solve the problem of the time 'jitter').