NATS.ioを中心に構築されたGoベースのロボティクスフレームワーク

Gorai ロボットプラットフォーム AI時代のために。 発音は「ゴライ」（「スティングレイ」のように） なぜGoraiか？ ロボットは分散システムです — だからそのように構築しましょう。 「単一の」ロボットでさえ、MCU、SBC、センサー、そして時にはベースステーションのネットワークです。 Goraiは、もはやそうでないと偽るのをやめます。あらゆるセンサーとアクチュエーターはNATSメッシュ上のサービス — ランタイムで発見され、名前でアドレス指定され、手作業で配線されることはありません。 信頼性の高いクラウドシステムを構築した規律 — サービスディスカバリ、ロケーション透過性、ヘルスチェック、ファンアウト、リプレイ — は、実際のロボットが必要とするものと全く同じです。 配線ではなく、ケイパビリティ。 センサーは読み取るリソース、アクチュエーターは呼び出すツールです。 メッシュ上のどのエージェントでも世界を認識し、それを変更できます — MCP（Machine Capability Protocol）のケイパビリティモデルがAIエージェントにネイティブに提供され、MCPサーバーを介さずにNATS上で直接動作します。 私たちはこれをNCP、NATSケイパビリティプロトコルと呼んでいます。 1台のロボットが複数のマシンになる。 ケイパビリティは名前でアドレス指定され、場所で指定されないため、単一の論理ロボットは、ランタイムで構成され、プラットフォームが参加・離脱するにつれて優雅に劣化する、ローバー、ドローン、センサーマスト、コンピューティングボックスにまたがることができます。 これがコンポジットロボットであり、それが全てです。 リプレイなしの自律性は伝説です。 アクションログ、状態ストリーム、リプレイは、ファーストクラスのプラットフォームの関心事 — アドオンではありません。 AI実行は歓迎されますが、決して信頼されません。安全性はエージェントではなく、ケイパビリティノードで強制されます。 エージェント互換、エージェント依存ではありません — 決定論的なステートマシンとルールベースのプランナーが同じケイパビリティを駆動します。 ソフトウェアのようにロボットを構築しましょう。 システムのように実行しましょう。 意見を述べ、実用的で、運用可能。 API、分散システム、デプロイメントで既に考えているなら、数ヶ月ではなく数日で生産的になれるでしょう。 ノーススターを読む: VISION.md。 完全なドキュメントは gorai-docs にあります。 戦略、アーキテクチャ、仕様、ハードウェア分析、20章の書籍、実装ガイド — すべて人間とAIエージェントの両方のためにインデックス化されています。 AIエージェントをそのリポジトリに向け、CLAUDE.mdとINDEX.mdを通じて100以上のドキュメントを自動的にナビゲートさせます。 Goraiとは何か（そして何ではないか） Goraiプロジェクトには2つの異なるバイナリがあり、それらを混同しないことが重要です： あなたのロボットバイナリ — Pi上で実行され、ロボットの処理を行うプログラムです。 これはあなた自身のGoモジュールです：あなたが望むコンポーネントをブランクリムポートし、gorai.Run()を呼び出すmain.goです。 組み込みのNATSサーバー、メッシュ、そして全てのコンポーネントがこの単一の静的バイナリにコンパイルされます。 それは完全に自己完結しており、ランタイムでgoraiツールから何も必要としません — それをロボットにコピーして実行します。 Gorai CLI — ワークステーションで実行する開発者およびオペレーターツールです。 本番環境のロボット上で実行されることはありません。 kubectl + ビルドラッパー + パッケージヘルパーを1つのコマンドにまとめたものと考えてください。 したがって、はい — あなたは単にあなたのロボットプロジェクトの.をgo buildし、その結果をPiにscpすることができます。 Gorai CLIは、通常のgo buildが行わない、そのバイナリ周辺のタスクを実行することでその価値を発揮します： やりたいこと Goraiコマンド 実際に行うこと デプロイ前に設定エラーをキャッチ gorai validate robot.json RDL（スキーマ、非推奨項目）を検証し、フィールドに壊れた設定を出荷しないようにします クロスコンパイルせずに高速にイテレーション gorai run robot.json ロボットバイナリが使用するのと同じランタイムをフォアグラウンドで実行します — コンパイルとコピーのループをスキップします デプロイ可能なバイナリを生成 gorai build robot.json --target linux/arm64 検証、クロスコンパイルのエルゴノミクス、バージョンスタンプ、デプロイヒントでgo buildをラップします コンポーネントを見つけて追加 gorai component search/add go getをラップし、main.goのブランクリムポートリストを編集します（Caddyモデル — 以下参照） ライブメッシュで実行中のものを確認 gorai mesh services / watch / schemas 実行中のNATSメッシュに接続し、それをイントロスペクトします — フィールドのロボットまたはフリートのためのサービスディスカバリブラウザです 最初の3つはGoツールチェーンに対する便利な機能です。 メッシュコマンドは、go buildでは本当に再現できない部分です — それらは実行中のシステムを観測およびデバッグし、ロボット（または複数）が稼働したときに頼りになるものです。 このREADMEの残りの部分では、CLIのインストール方法、ロボットの定義方法、およびビルド方法について説明します。 1時間以内にロボットを構築できます。 JSONを書き、バイナリを取得し、Linuxホスト（Raspberry Pi/Orange Pi/など）にデプロイします。 # 1. CLIをインストールします（開発者/オペレーターツール — ロボット自体ではありません） go install github.com/emergingrobotics/gorai/cmd/gorai@latest # 2. テンプレートからロボットプロジェクトを作成します git clone https://github.com/emergingrobotics/gorai-robot-template.git my-robot cd my-robot # 3. robot.jsonを編集し、検証して実行します gorai validate robot.json gorai run robot.json # 4. デプロイ用にビルドします gorai build robot.json -o robot --target linux/arm64 scp robot pi@raspberrypi:~ && ssh pi@raspberrypi ./robot コンテナなし。K8sなし。外部サービスなし — Raspberry Pi 5またはOrange Pi 5上の単一バイナリのみ。 これはシンプルなケースであり、上限ではありません：複数のバイナリを共有NATSバス（またはリーフノード）に向け、メッシュが複数のプラットフォームを1つの論理ロボットに結合します — 同じコード、書き直しなし。 ハードウェア Gorai搭載 Goraiは、海洋、地表、水中、陸上ドメインのプロシューマーアクセス可能なフィールドロボットをターゲットとしています — 自律型潜水艇、自律型水上艇、および陸上ロボット。 例えば、自律型潜水艇は、圧力ハウジング内のLinuxホスト（Raspberry Pi/Orange Pi/など）でgorai runを実行します。 コンポーネントエコシステム GoraiはコンポーネントパッケージングにCaddyモデルを使用します：あなたのロボットプロジェクトは標準的なGoモジュールであり、main.goのインポートリストがコンポーネントマニフェストです。 各コンポーネントは、registry.RegisterComponent()を呼び出すことで自己登録します。 カスタムパッケージマネージャーはありません — Goモジュールがすべてを処理します。 仕組み ロボットのmain.goは、ブランクリムポートを通じて含めるコンポーネントを宣言します： package main import ( gorai "github.com/emergingrobotics/gorai/pkg/gorai" // Goraiコアからのリモートプロキシコンポーネント _ "github.com/emergingrobotics/gorai/components/motor/remote" _ "github.com/emergingrobotics/gorai/components/camera/remote" // エコシステムからのサードパーティコンポーネント _ "github.com/someone/gorai-component-lidar/rplidar" // このリポジトリ内のカスタムコンポーネント _ "my-robot/components/ballast" ) func main() { gorai.Run() } Goのインポートリストは、package.json、requirements.txt、またはカスタムマニフェストの代わりになります。 インポートしたものがバイナリにコンパイルされるものです。 ワークフロー gorai component search lidar # エコシステムでコンポーネントを検索 gorai component add sensor/rplidar # go get + main.goへのブランクリムポートを追加 gorai build robot.json # 全てを含む単一バイナリをビルド カスタムコンポーネント カスタムコンポーネントは、プロジェクトのリポジトリ内の通常のGoパッケージです。 init()関数を持つパッケージを書き、registry.RegisterComponent()を呼び出し、main.goにブランクリムポートを追加すると、他のすべてと一緒にバイナリにコンパイルされます。 コンポーネントの共有 コンポーネントを共有することは、Goモジュールを公開することです。 パッケージを独自のレポに抽出し、GitHubにプッシュすれば、誰でもgorai component addできます。 レジストリサーバーなし、パッケージ承認プロセスなし — 標準的なGoモジュールホスティング。 なぜこれが重要か これはGoをプラットフォーム言語として選択する際の重要な利点です。 単一バイナリの話は、コンポーネントエコシステムにまで及びます：ランタイム依存関係解決なし、DLL地獄なし、デプロイ時のバージョン競合なし。 全ての依存関係は、Goツールチェーンによってビルド時に解決され、結果としてロボットにコピーする単一の静的バイナリが得られます。 非Goコンポーネント（Pythonビジョンパイプライン、C++ SLAM）は、NATSを介して通信する外部サービスとして実行されます。 それらはバイナリにコンパイルされません。 これはフェーズ2の複雑さです。完全な設計については、docs/package-dev-approach.mdを参照してください。 Goraiは誰のためか？ Goraiを使用するのは、以下の場合です： 本物の自律性（教育用おもちゃやシミュレーションではない）を望む 親しみやすいソフトウェア（数ヶ月ではなく数日で生産的になる）が必要 最新のツール（AI支援コーディング、シンプルなデプロイ）を評価する プロシューマーロボット（海洋監視、陸上車両、研究プラットフォーム）を構築している AI/MLに物理的な具現化を追加したり、1台からスケールアップしたりするソフトウェアファーストチームである