Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow GUI to hook on a core running on another host #827

Open
franzlst opened this issue Apr 17, 2020 · 1 comment
Open

Allow GUI to hook on a core running on another host #827

franzlst opened this issue Apr 17, 2020 · 1 comment

Comments

@franzlst
Copy link
Member

Currently, the GUI only works with a core running on the same host as the core. However, especially for mobile robots, one wants to have the GUI to check the execution of a robot running the core. Therefore it would be beneficial to allow the GUI to communicate with a core running on another host.

It would probably be sufficient if the GUI is only used as "viewer", not as "editor", reducing the communication to the current execution state (core to GUI) and the control of the execution (GUI to core).

The host running the GUI would probably need a copy of the state machine running on the core host. The identity of the two state machines should be checked using a hash. In addition, the GUI (maybe also the core) needs a "read only" mode, preventing the state machine from being changed.

Originally created by @franzlst ([email protected]) at 2016-01-07 15:50:42+00:00 (moved from RMC internal repository)

@franzlst
Copy link
Member Author

Part of this issue is resolved implemented by rafcon_monitoring_plugin and could fully solved by its extension.

The follwoing sub-tasks can be identified:

  • integration of execution-status monitoring and execution-control interface into gtkmvc GUI
  • copy a running state-machine to client and enable to control and observe execution
  • interface to forward editor changes to core host -> this interface should be limited to one client registered as "editor" -> the feature could by implemented by remote object library like Pyro (a discussion is started about that) or by a explicit implemention of our self by using a unique rafcon-object indentifier and serialization of function arguments that are used because those could be objects, too (e.g. put them into json-string formate)

Sub-Task 1 seems to be solved by the actual implementation of the rafcon_monitoring_plugin revision 0.0.3.

Originally created by @Rbelder at 2016-04-14 10:02:44+00:00 (moved from RMC internal repository)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant