現実のスマートクエスト：悪魔と投稿

多くの人が現実のクエストについて聞いたことがある - 部屋のジャンルが私たちの世界に移った脱出のゲーム。 あなたはパズルを解き、答えを得て、次の段階に進みます。 1時間以内に終了する必要があり、その結果、出口のドアが開きます。 しかし、内部にどのように配置されているかを知っている人はほとんどいません。 この記事では、これらのクエストの1つの舞台裏を見て、技術的に他のクエストと比較します。



脱出室の開発者として、私はそれらのいくつかの実装を見てきました。 通常、クエストは無関係なブロックに分割され、それらが一緒になって通過の可能性を実現します。 ただし、私たちの探求では、集中型アーキテクチャを使用しました。 これらのアプローチの長所と短所を説明し、実際にクエストを作成する「技術者」が取り組むタスクを説明します。 このトピックはインターネット上で十分に公開されていません。

標準的なアプローチ

論理的に、クエストシナリオはタスクに分割されます。 たとえば、顧客は「キーボードにコードを入力する⇒ライトが点灯する」ことを望んでいます。 したがって、ここでの技術者のタスクは、正しいパスワードを入力すると電球を点灯させるキーボードを作成することです。 Arduinoはすぐに思い浮かび、電球とキーボードを制御します。 これは通常行われます。





標準アーキテクチャ



その結果、私たちは別々のタスクを取得しますが、それらは互いに他のタスクとはまったく関係なく、一緒にクエストです。 このアプローチには重大なマイナス点があります。柔軟性の欠如です。 変更を加える必要があると、修理が長くなり、手が届きにくい場所に登ったり、大切なコンポーネントにアクセスするために壁や天井を壊したりする必要があります。 クエストの変更の原因：

• スクリプトの変更。 建設プロセスは進行中です。
• 破損。 コンポーネントは安価なので、これも頻繁に発生します
• クエストを作成する人々の要件：ビルダー、デコレーター、...

簡単な例：タスクの準備ができました。 ただし、管理対象スポットライトの色を変更する必要があります。 これを行うには、arduinがインストールされている場所に移動し、ラップトップを接続し、タスクのコードを探して変更し、ロードしてからテストします。 まあ、それが初めて動作する場合。 私の経験では、そのような一見素朴な変更が重大な結果をもたらしたまれなケースはありません。誤ってワイヤにぶつかったり、タスク全体がクラッシュしたり、コンポーネントが焼けたりします。 クエストは停止し、チームはかんしゃくを起こします。



別の例。 オペレーター（クエストを担当し、プレイヤーを受け取る担当者）が電話をかけて、何かが壊れていると言います（たとえば、コードを入力した後、ライトが点灯しない-症状）。 これを修正するには、その場所に来てラップトップを接続し、理解し始める必要があります。 結局のところ、何が壊れたのかはわかりません。電球、ワイヤー、コントローラーなどです。 可能性を除いて、いくつかのテストを実行する必要があります。 これは、特に「つまり、その後」という問題、つまり ライトが点灯することもあれば（すべて順調です）、点灯しないこともあります。





悪夢のテクニック



デバッグするときは、ラップトップで気まずいポーズを数時間立てる必要があります。 Arduinaは、私が触れたくないワイヤーの束でしっかりと固定されています。すべてが壊れます。 ほこり、汚れ、動くのが怖い。 定期的にやって来て「すでに、もうそこに人が待っている」と尋ねるオペレーターと。 そのような瞬間に、あなたは自分の活動を売春と比較し、適切なキャリア成長の可能性を考慮します。





クエストの1つでのタスクの1つの実装。 Arduinの中心にあります。



ここで最悪の状況は改ざんです。 たとえば、顧客はタスク1のキーボードがタスク2の電球に影響することを望んでいます。つまり、あるarduinoから別のarduinoにワイヤを引っ張り、両方のコードを変更する必要があります。



そのため、このようなクエストに柔軟性がないため、作成とメンテナンスが非常に困難になります。 顧客にも問題が発生します。 修理が遅れ、30分待っているプレーヤーは沸騰し始めます。

一元化されたアプローチ

この問題を解決するには？ すべてのデバイスへの迅速なアクセス、およびさまざまなコンポーネント間の関係を迅速に変更する機能を提供するにはどうすればよいですか？ すべてのデバイスをネットワークに接続し、1台のコンピューターから管理することは論理的です 。



各イベント（上記の例ではボタンを押す）は中央コンピューターによって処理され、ボタンを押すと正しいパスワードが作成されると、電球を点灯するコマンドが発行されます。 変更が必要な場合（たとえば、パスワードを変更したり、5秒ではなく3秒間ライトをオンにしたり、別の部屋のライトをオンにしたりする場合）、コンピューターのコードを変更するだけです。 壁を壊す必要はありません。







クエストではこのアーキテクチャを使用しています。 それがどのように実装されたのか、開発中にどのような困難が生じたのかを詳しく説明しようとします。

実装

まず、周辺機器のリスト：

• GPIO制御（ライト、ロック）。
• GPIOによる情報（ボタン、センサー）
• LED RGBスポットライト
• 速度を変更し、ランタイムにテキストを追加する機能により、ビデオを同期的に表示するモニター（ビデオウォール）
• イメージのドアのぞき穴
• IRレシーバー
• 壁にある大きなキーボード、手のひらで触れる必要があるボタン
• RFIDセンサー
• マトリックスキーボード
• テキスト付きLEDディスプレイ
• 機械式ソビエト時計用ステッピングモーター

これらはすべて6つの部屋にスムーズに散らばっています。



すぐに言います：顧客は、最低価格のマッチとドングリからクエストを集める目標を設定しました。 したがって、コンポーネントはそれに応じて選択されました（たとえば、avitoを搭載したコンピューター）。 状況が複雑になるため、最も適切なテクノロジーを使用できませんでした。 たとえば、最もホットな瞬間に、フォトレジストの魔法を持っている人は辞めました。そのため、プロトタイピングにボードを使用する必要がありました（Arduino）。 要するに、彼らは何から何ができる限りベストを集めました。



制御デバイスとして、Debianを搭載した通常のPCが使用されます。 クエスト全体を制御するデーモンを実行します。 ネットワークはイーサネットとUDPプロトコルを使用します。 イーサネットは、コンピューターと周辺機器（avr）の両方で十分にサポートされています。 UDPは簡単に実装できるため、MKにはUDPをサポートする優れたライブラリがあります。





サーバークエスト。 1台のコンピューター（左下）がすべてを制御し、残りはビデオを表示するために必要です。



さまざまな周辺機器は、ネットワークに接続する必要がある3種類のデバイスをもたらします。 これはArduino Mega、Raspberry Pi、および通常のDebianコンピューターです。 最後の2つは問題を提起しませんが、最初の1つはやめるべきです。

AVR

C ++（avr-g ++コンパイラ）がプログラミング言語として選択され、CMakeがアセンブリユーティリティとして選択されました。 Arduino IDEとは異なり、これによりビルドプロセスを自動化し、柔軟性を高めることができました。 たとえば、クエストタスクの実装に必要なタイマーと割り込みにアクセスできますが、デフォルトではArduinoコードでビジーです。



イーサネットモジュールとして、安価なMicrochip ENC28J60（〜250r）が選択されました。 ライブラリはEtherCardです。 pinModeなどのarduinoスタイルの関数を指します。 ライブラリを書き換える代わりに、必要な機能の実装をArduinoコードから取得して、Arduinoコアの「ミニバージョン」を取得しました。 CMakeを使用すると、「ミニコア」をプロジェクトに簡単に接続できます。



ライブラリには多くのメソッドがありますが、そのうちのいくつかだけが必要です。UDPパケットを送信し、UDPパケットを受信するようにコールバックを設定します。 ビッグデータはネットワークに送られないため、データは常に1つのパッケージに格納されると考えています。



コントローラのファームウェアを変更したり、リモートで再起動したりできない場合、システムは意味をなしません。 前と同じように、壁を破ってラップトップを接続する必要があります。 この問題はavr-etherbootプロジェクトを使用して解決し、Mega 2560で動作するようにわずかに変更しました。次のように動作します。ファームウェア付きの.hexファイルは中央コンピューターに保存され、TFTP経由でアクセスできます。 Avr-etherbootは、ISPを介して各コントローラーにフラッシュされるブートローダーを生成します。 それはISPです USB-UARTファームウェアはArduinoブートローダーによって実装されますが、すでに存在しない場合があります。 コントローラがロードを開始すると、ブートローダーが起動し、ネットワークに接続して、TFTPを介してファームウェアをダウンロードします（ブートローダーは少し異なるため、各コントローラーは独自にダウンロードします）。 次に、ファームウェアは各MKで機能します。 記述されたスクリプトを使用すると、クエストの各MKに対してブートローダーを生成し、1つのコマンドでそれをフラッシュできます。



しかし、ファームウェアにエラーがあり、交換する必要がある場合はどうでしょうか？ すべてのMKを再起動する方法は？ これを行うには、リレーを使用します（クエストには約50個あるため、 8チャンネルのリレーを使用します ）。1つを除くすべてのArduinの電源が通過します。 後者はこのリレーを制御し、USB経由で中央コンピューターからフラッシュされます。





簡単に見えませんが、スクリプトを作成すると、必要に応じて1つのコマンドですべてのデバイスを再フラッシュできます。



おもしろいですが重要な発言：私たちは「プロダクション」でデバッグボードを使用しているため、常に信頼性について考える必要があります。 問題が断線した場合、コードのデバッグに1時間もかかりませんでした。 したがって、周辺とMK、ENCとMK、および電源の接続は、ワイヤと端子台PLSおよびBLSを使用して行われます。 経験上、クリンパなしでそれらを常にクランプできるとは限らないため、1つの選択肢が残っています-はんだ付け。 クエストの内訳のほとんどは、ゲームをキャンセルする必要があるため、コードやロジックの問題ではなく、抜け落ちた配線です。

中央コンピューター

そのため、プレイヤーの行動を知覚したり、自分で何かをしたりできる周辺機器があります。 クエストシナリオもあります。 これは単なるアクションのシーケンスではなく、オプションが使用可能であると言う価値があります。 たとえば、最初に部屋Aを通過し、次に部屋Bを通過できますが、その逆も可能です。 また、「独立して」動作するタスクもあります。たとえば、ボタンを何度でも押すと、悪名高いライトが点灯します。これは、実行する手順に関係なく、いつでも実行できます。 これを実装する最も簡単な方法は何ですか？



いくつかのプロセスを使用します。 各プロセスは、周辺機器への完全なアクセス権を持ちます。 また、プロセスは相互作用します。 別々のプロセスで、独立したタスクとイベントの期待値を取り出します（たとえば、正しいパスワードがキーボードに入力されます）。 イベントが発生すると、プロセスは必要に応じて応答します。



主なシナリオは別のプロセスです。 イベントは各部屋を通過することを期待し、アクションを実行するための周辺コマンドも提供します。



これらはすべてC ++および標準ライブラリ（unistd.h、sys / *）に実装されています。 プロセス間の相互作用は、名前のないパイプを使用して行われます。 複数のプロセスが1つのUDPソケットから複数のプロセスを読み取ることができるように、リスニングプロセスの数に応じて分岐パイプが使用されます。 特定のデバイスから受信したパケットは、これらすべてのパイプに送信され、リスニングプロセスはすでにそのパイプから読み取っています。



さらに、TCPサーバーがねじ込まれているため、クエストの管理、イベントの作成、ログの表示が可能です。 それを介して周辺機器と直接通信することが可能であり、デバッグ時に非常に便利です。 ポートを解放して周辺機器にアクセスするために、クエストデーモンを「消す」必要はありません。 TCPサーバーを使用すると、クエストのWebインターフェイスを作成でき、タブレットからクエストを制御できます。





他のコンポーネントのコンテキストでのデーモンスキーマ



例。 クエストを1つのタスクで構成します。キーボードでコードを入力する必要があります。 その後、ライトが点灯し、出口のドアが開きます。 このアーキテクチャでは、次のように機能します。

1. プロセス1、スクリプトは「クエストの開始」イベントを待機します（呼び出しのブロック）
2. オペレーターがWebインターフェースのボタンを押します。 これにより、チェーンに沿って対応するイベントが作成され、スクリプトは引き続き機能します
3. スクリプトはプロセス2「タスク1」を開始し、イベント「タスク1が通過しました」を待ちます
4. タスク1はプロセス3「正しいパスワードの検索」を開始し、それに対応するイベントを待ちます
5. プレーヤーはパスワードを入力します。 各プレスはプロセス3で処理されます。入力シーケンスで正しいパスワードが見つかると、プロセス3はイベント「タスク1.入力された正しいパスワード」を生成します。
6. プロセス2のブロッキングコールは終了し、プロセス2は「電球」コマンドを発行します。 それは周辺に送信されます。 プロセス2は、イベント「タスク1完了」を生成します
7. プロセス1のブロッキングコールは終了し、プロセス1はコマンド「フロントドアを開く」を発行します。 クエスト完了

上記の例の図



そのような例では、複雑なアーキテクチャは不要に見えますが、多くのタスクがある場合、周辺は異なるタイプであり、スクリプトは構築中と探索中の両方で変化します。



Quest Webインターフェイス







デバッグの便宜上、すべてのイベントはシステムログに記録されます。





問題についてもう少し考えてみると、次の考えが浮かびます。悪魔の低レベル（周辺との通信）と高レベル（クエストイベント）の部分を分離する必要があります。 たとえば、TCP経由。 これにより、高レベルの言語を使用して、顧客からのスクリプトをコードに変換することが可能になります。 作成と保守が簡単かつ高速になります。 このアイデアは、クエストが既に機能していたときに思いついたため、まだ実装されていません。

タスク

アーキテクチャが考え直されたとき、周辺機器を接続してタスクをテストするだけです。 開発プロセスと結果は次のとおりです。





開発ビデオ：





合計デバイス：

• 6 x PC
• 2 x Raspberry Pi
• 5 x Arduino Mega + ENC28J60
• 40リレー

一般的なコメント：

おわりに

そのため、建設中に余分な作業をすることなく、非常に簡単に変更できるクエストを取得しました。 また、Webベースの管理や簡単なエラー追跡などの便利な機能も備えています。 リモートサポートが可能になりました。 場所には外部IPがあります。



打ち上げ以降に発生したすべての故障は、「鉄」の問題によるものです（コンピューターが死んだ、ワイヤーが外れた、など）。 短時間でリモートコントロールを使用すると、正確に壊れたものを判別できます。 ほとんどはリモートで修復でき、オペレーターに何をすべきかを伝えます。 顧客からのクエストへの変更も「自宅から」行われます。



それに比べて、一元化されたアーキテクチャは技術的に複雑なクエストに適しているのは明らかですが、非常に単純なものには通常のクエストも適しています。







誰かがコードを必要とする場合、公開リポジトリを作成します。 メインは閉じられています スクリプトやその他の秘密のものが含まれています。



ご清聴ありがとうございました！



UPD： Arduino Mega 2560用のavr-etherbootコード