We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
現状だと現実世界の同期の部分が少し冗長な気がした。MQTTの通信にはMQTT Brokerを用意しないといけないが、エンドポイントが2つに増えるよりは1つのMQTT Brokerで管理した方が良いような気がする。
flowchart RL subgraph 状態管理 管理画面 <-->|"connect-web"| StateManager MqttBroker <-->|"connect"| StateManager StateManager <--> DB1[(state_db)] end subgraph 自動運転 TrainController <--> StateManager DiagramManager --> PathPlanner PathPlanner <--> TrainController DiagramManager <--> DB2[(diagram_db)] DiagramManager <-->|"connect-web"| 管理画面 end subgraph 映像配信 Webカメラ --> |"USB"| 配信サイト ESP-EYE -->|"mjpeg"| 配信サイト 配信サイト -->|"WebRTC"| SkyWay SkyWay -->|"WebRTC"| 管理画面 end subgraph エッジデバイス MqttBroker <-->|"MQTT"| Servo Sensor -->|"MQTT"| MqttBroker end
プロトコルはMqttで共通なので、MqttBrokerが全てのMqttの通信を担うようにして、StateManagerに対して状態の更新と、StateManaegrが受け取ったポイントの切り替えの指示などをMQTTで流すようにする。
こんな感じの構成に変更するのどうでしょうか?
The text was updated successfully, but these errors were encountered:
csenet
kienn-HCl
Successfully merging a pull request may close this issue.
現状だと現実世界の同期の部分が少し冗長な気がした。MQTTの通信にはMQTT Brokerを用意しないといけないが、エンドポイントが2つに増えるよりは1つのMQTT Brokerで管理した方が良いような気がする。
プロトコルはMqttで共通なので、MqttBrokerが全てのMqttの通信を担うようにして、StateManagerに対して状態の更新と、StateManaegrが受け取ったポイントの切り替えの指示などをMQTTで流すようにする。
こんな感じの構成に変更するのどうでしょうか?
The text was updated successfully, but these errors were encountered: