An Architecture for a hardware-software system II

This is our solution at Tonbo Imaging to the question I put up here.

Very broadly, I'll break our solution into:

1. The various components and gluing them together
A whole lot of Managers that handle various aspects of the software, the Views, a CommandParser, and MessageResponse Queue, all glued together by an internal RxBus - asynchronously sending messages from various threads to one another.

2. Device Capabilities + Autogen UI
Each camera broadcasts its capabilities, a json file containing a list of commands it can take. Each command contains its parameters, their datatypes and the list/range of values they can take. A lot of the UI is autogenerated from this.

3. Versioning
This was fairly tricky and we're still not 100% sure we're happy with what we have. We have to take care of the versioning between various components:
- camera OS ⇌ camera software
- camera software ⇌ clients
- camera software ⇌ web

4. Camera-Graphics-Display-Streaming 
I'll add the graphics library I made to this list. The above points do not highlight how the camera, display, rendering, and streaming are a subsystem of their own and how neatly we're able to make it work for us. In (1) I've simply overlooked this entire bit as one box in an ocean of other boxes. Read more about this on my website.

Comments

Popular posts from this blog

Firebase Auth | The Debug vs Release Signature Problem

One Year at Tonbo Imaging

[Breaking News] AI takes over universe to calculate Pi