UI Architecture Question

[mbremer]

Hi everyone,

We're architecting a new project that is capturing images from a number of cameras and analyzing each using an ML model. There also will be a UI to display the status of the system.

The planned architecture will have a top-level controller launch a user interface actor and multiple vision controllers (depending on how many cameras we have). The vision controller will then launch an acquisition actor and an analysis actor and handle messages between the two (telling acquisition when to acquire, passing the image from acquire to analysis, and receiving the results from analysis).

I want the ability to support different types of acquisition and analysis actor types (different types of camera, simulation, so the acquisition and analysis actors owned by the vision controller will be abstract classes with the specific implementations defined in the launcher and passed to the vision controller.

Simple diagram of the above:

So, when thinking about the user interface, we're going to have different UIs based on what specific acquisition and analysis actors get launched.

One way to handle this would be to pass the relevant data from these actors (would need some way to make them generic or have the types defined at run time) to the UI actor, which would then need to know about what types of actors they are to display properly. This feels wrong since the UI needs to know what's going on in another part of the tree and the vision controller also needs to know which specific actors are running.

My next thought was to have each specific actor own their UI. Create a helper loop in each actor to control the UI, and pass the sub-panel up to the vision controller, who will combine the sub-panels from both actors into a different sub-panel and pass it up to the controller. The controller will then pass the sub-panels from all the vision controllers to the UI actor, who will display them. This way no one outside of the low level actors needs to know what the UI actually is, just that there is one to display. This feels better but I still have an uneasy feeling since it seems that those actors are not responsible for too much.

Does anyone have any thoughts on this? Is there a better way that I'm not seeing?

[Taggart]

I like your second thought. 

If you implement the UIs as children ie You have a  Line Scan Analysis Module and a LineScan Analysis with UI then they are kind of seperate a little bit and you can run it headless if you would like.

My initial thought was to use some sort of abstract factory to produce an analysis or acquisition and the corresponding UI. That would be more aligned with your first option. The question then is how do you get messages back and forth. You could break the actor tree. Not sure that is a great idea.

[drjdpowell]

I use a different framework than the AF, but I routinely use the pattern of a UI that is composed, using subpanels, from front panels provided by the actors themselves.  So I think doing this with the AF is fine.

BTW, I have recently working on an image analysis project; I have my analysis types be children of an ordinary class, with an "Analyze Image" function, rather than be different types of actor.  I change analyses on-the-fly by sending messages containing new analysis types to perform.  

[Oli_Wachno]

You might consider using MGI Panel Actors, or at least evaluate them. They can save a lot of work.

http://sine.ni.com/nips/cds/view/p/lang/de/nid/217049

wish I had known them back then ...

[mbremer]

Thanks everyone, glad to get some confirmation on the path we're going down.

I've seen the MGI panel actor before, but never given it a test. Might have to change that now.

[BertMcMahan]

I'll second the MGI Panel Actors recommendation- they are great and save quite a bit of time.

[auspex]

My reply to another topic may help: https://forums.ni.com/t5/Actor-Framework-Discussions/quot-Synchronous-quot-receiving-asynchronous-me...