NB there's a confusing feature, where stage.move will
fail after the task has been cancelled, because it is cancellable.
For now, we can work around it by passing `block_cancellation` but
this may want to be solved more generally in LabThings
Autofocus timing is pretty critical. I've introduced the ability
to abort moves, which introduces ~50ms timing jitter. This
commit reverts the tming-critical move in autofocus to the old behaviour.
I've only reverted the move that really matters - this means
that if you start a massive sweep by accident, you can still
abort it when it's moving down to the start of the sweep.
This may not be in the codebase forever, but it's a very useful
sanity check to have during development.
The current implementation is clearly not a performance or
security risk.
Retrieving metadata pre-action risks stale metadata being
returned if DirectThingClients are used. I've switched to
the safer callable dependency, which is guaranteed to be fresh.
Previously, we raised an exception (and thus HTTP error
code) if the CSM matrix was requested and not yet set.
Now, we just return None, and I've added a (not-network-exposed)
function that will raise an HTTPException if it's missing.
It's helpful to raise an exception if we access the calibration
before it's been set - but thing state should not raise exceptions,
just return an empty dict if the data is not there yet.
Currently only has fast_autofocus, and there
may be some work to do on timing, but it works :)
Getting timestamps from the camera rather than
time.time() would be ideal, but it would take some thought to tie that up with
the encoder.
I'm using a low-res stream, as it seems impossible to
turn the bitrate control of the MJPEG stream off,
at least within the picamera2 API.
