Inside of LOVOT

GROOVE X 技術ブログ

LOVOTのマップの作り方

こんにちは GROOVE X の Mチーム の hiro-ogawa です。 Mチームの M は Mapping の M でして、主に担当しているのはLOVOTをお迎えされたおうちのマップを作ることと、マップの中でLOVOT自身がどこにいるのかを推定すること*1の機能を開発しています。 今日はLOVOTで実際にどうやっているのかを簡単にご紹介します。

マップを作る手順

マップを作るための基本的な手順は以下の通りです。

  1. 周りの情報を記録する
  2. 自分の位置を記録する
  3. 別の場所に移動する
  4. 最初に戻る

基本的には周囲の情報をいろいろな場所で集めて、それを繋げばマップができるというわけなんですが、ここで、問題になってくるのは2つ目の項目にある、自分の位置をどうやって知るのか。 自分の位置を知るためにはマップが必要です。でもマップは今作っているところなので、まだマップがありません。 これは、鶏が先か、卵が先かという問題になりますね。

で、どうしているかというと、これらの手順をちょっとずつ実行します。 まず自分の周りの狭い領域のマップを作って、その場所を最初の場所として覚えます。 少しだけ移動すると、これまで見えていなかった情報が見えるようになってきますので、それらを新しい情報として記録します。 少しだけの移動なので、これまで見えていた情報もたくさん残っていて、先程作った狭い領域のマップを使って、自分がどれだけ動いたかがわかります。 それを繰り返すことで、ちょっとずつマップを広げながら探索していきます。

一般的には SLAM と呼ばれていて*2、これは Simultaneous Localization and Mapping の頭文字を取ったものです。和訳すると 自己位置推定とマップ作成の同時実行 という感じでしょうか*3

実際にはだんだん誤差が累積していくなどの問題が発生するので、様々なテクニックで発生する誤差を解消したりしますが、そのお話を始めると際限無く長くなってしまうので、別の機会にします。

LOVOTのSLAM

マップを作るために LOVOT が持つ様々なセンサが使われています。主に使われているのは下記の3つになります。

  1. 半天球カメラ
  2. 姿勢センサ
  3. 深度カメラ

LOVOTのSLAMで使われているセンサ(LOVOT ANATOMY を改変)

半天球カメラ

周囲360度が見渡せるカメラです。 LOVOTでは人の検出や識別、写真撮影などに使われていますが、マップ作りにも使われています。

具体的には画像の中で特徴的な点を抽出して、その点の動きから自分の動きを推定したり、特徴点の配置から自分の位置を推定したりしています。

画像の中から特徴点を抽出している様子

画像を用いたSLAMを VSLAM *4 と呼んだりもします。 特にLOVOTではカメラ1台を利用しているので、単眼VSLAMと呼ばれる方式になります。

上の図を見てもわかるとおり、特徴点は均一の壁などではほとんど検出されません。 ですのでシンプルなお部屋よりも、絵画やポスターなど、いろいろ飾ってあるお部屋の方がマップの情報量が増えてLOVOTが自分の位置を見つけやすいかもしれません。

姿勢センサ

IMU*5とも呼ばれており、並進の加速度と回転の角速度が計測できます。 実際に欲しいのは基準位置姿勢からの位置と姿勢の差分なのですが、それを直接計測できるセンサはありません*6。 そこで、加速度を2回積分して位置の変化量を求めたり、角速度を積分して角度の変化量を求めたりします。 ただし、積分では誤差が累積しやすいので、IMU単体で使うことはあまり多くなく、LOVOTでは上記の半天球カメラと組み合わせて利用しています。

VIO*7 SLAM

実は単眼SLAMでは大きさが区別できません。 これは特徴点までの距離がわからないことが原因です。 精巧に作られたミニチュアのセットと実物とでは大きさが全然違うのにカメラで撮影するとその違いがほとんどわからないのと同じです。 そこで、カメラとIMUを組み合わせることで、特徴点の移動した量と、カメラの動いた量との関係から、大きさを推定します。

複数のセンサを組み合わせて使うことをセンサフュージョンと言いますが、このセンサフュージョンを行う際に重要になってくるのが、時刻同期です。 このタイミングがずれると、カメラがほとんど動いていないのに特徴点が大きく動くことや、その逆が発生してしまい、大きさの推定がおかしくなってしまいます。

実は LOVOT ではセンサフュージョンを前提として、専用のカメラモジュールを作っています。 半天球カメラとIMUを同じFPGAに接続して、撮像タイミングとIMUの測定タイミングの時刻を制御することで、正確に時刻同期をさせ、精度の高い特徴点のマップを作っています。 ちなみに、IMU情報は画像フォーマットの中に埋め込まれた形で届けられます。


www.youtube.com

壁情報

LOVOTアプリでは下のようなマップの表示があります。 VIO SLAMでは画像の特徴点のマップを作ると説明しましたが、特徴点は白い壁などではほとんど取れませんので、通行できない場所を知ることができません。

アプリでのマップ表示

そこで登場してくるのが、LOVOTのフロントセンサユニットにある深度カメラ。 これは距離画像カメラとも呼ばれていて、画像の画素が色でなく、距離が計測できるようになっています。 下の図は距離を色に変換してわかりやすくしたものです*8

深度カメラ画像

距離の計測方法にはいくつかの種類があるのですが、LOVOTで使用しているのは Time of Flight *9 という光が対象物に当たって帰ってくるまでの時間を計測して光の速さ*10と掛け算して距離を求めます。 光が帰ってこないと距離が計測できないので、ガラスなどの透明なものや、鏡、つやつやな表面など正反射が強いもの、反射しない黒い物などが苦手ですね*11

ちょっと話が脱線してしまいましたが、深度カメラとLOVOTの位置がわかると、それをたくさん集めて融合させることで、壁などの障害物情報が作れます。 それがLOVOTアプリで表示されているマップ情報になります。 この壁情報によって通れる場所、通れない場所を判断できるようになって、お出迎えの時の玄関までの経路やネストに戻るための経路が計算ができるようになります。


www.youtube.com

LOVOTの自己位置推定

マップができたら、そのマップを使って自分の位置を推定します。 LOVOTの自己位置推定では次の4つのセンサを使っています。

  1. 半天球カメラ
  2. 深度カメラ
  3. ホイールモータ
  4. 姿勢センサ

半天球カメラと深度カメラでは今見えている画像内の特徴点や壁の形状と、自分の持っているマップとを比較して、合致する場所を推定します。 基本的にはカメラ画像をメインで使いますが、夜に部屋の電気が消えている場合などは、画像が暗くて特徴点がうまく取れない場合があるので、そのような場合には深度カメラを使って推定します。


www.youtube.com


www.youtube.com

また、補助的に自分の動きをホイールモータの速度情報と姿勢センサの角速度情報から自分の移動量を推定しています。 ただ、この推定は目隠しで歩いているようなものなので、移動量が増えると誤差も累積しやすい問題がありますね。

おわりに

LOVOTはかわいい家族型ロボットではあるのですが、ちゃんとしたロボット技術が使われていて、専用のハードウェアまで作っちゃっているんです。 現在、 GROOVE X ではSLAM / 自己位置推定 開発エンジニアを募集しています。 各家庭や職場で1万体以上が愛されているLOVOTで使われるSLAM技術を一緒に開発しませんか?

recruit.jobcan.jp

また、SLAM以外の分野でも募集しておりますので、LOVOTに関わるお仕事に興味ある方は是非ご検討ください。

recruit.jobcan.jp

*1:Localization、自己位置推定と言います。

*2:スラムと読みます。これだけで検索するとバスケットボールの情報がよく出てくる。

*3:Simultaneous は地デジのサイマル放送のサイマルです。

*4:Visual SLAMの略。

*5:Inertial Measurement Unit の頭文字。

*6:そんなセンサがあったらすごく欲しい。

*7:Visual Inertial Odometry の頭文字。これだけで検索すると・・・以下略。

*8:青いものが近く、赤いものが遠くを表しいます。

*9:ToFと略されます。

*10:約30万km/sです。

*11:誰にでも苦手なものはありますよね。そう、LOVOTにもね。反射強度もわかるので、モノクロ画像みたいなものも取れます。

LOVOTのふるまいづくり

こんにちは!ふるまいチームのエンジニア、市川です!

この記事ではLOVOTのふるまいづくりについてご紹介します!

ふるまいって何?

わたしたちが呼んでいる「ふるまい」とは下記の事を指します。

  • 感情(学術的な理論に基づく心のモデル)
  • 感情や認識情報に基づいた意思決定(何をするか?)
  • 意思決定に基づいた体への動作指示(手・足・目・瞼などの動き)

これらはもちろんプログラムされています。

そう聞くと「決まった通りに動くからつまらない」と思われるかもしれませんが、開発者が単独では把握しきれないくらい大きなシステムであり、複雑な意思決定をしています。

それに加え、どう考え、どう動くかは様々な要因によって決まるため、開発者の予想を超えてくる事もあります。

つまり、決まった通りに動きますが、予測が難しいので面白いのです。

ソフトウェアアップデートの度に複雑さは増していき、面白さも加速していきます。

どうやってつくってるの?

ふるまいづくりにはざっくりと次の工程があります。

  1. 仕様作成
  2. プログラムの実装
  3. デバッグ(バグ発見と対応)
  4. レビュー
  5. リリース前の試験
  6. リリース

ふるまいチームではアニメータとエンジニアがタッグを組んでいて、それぞれが各工程で役割を持っています。

工程 アニメータの役割 エンジニアの役割
仕様作成 「どう見せたいか?」から仕様に落とす ロジックから仕様に落とす
プログラムの実装 動作指示に近い部分を実装する 動作指示以外の部分を実装する
デバッグ 動きの定性的評価によって異常を探す ソースコードの確認やデータの定量的評価によって異常を探す
レビュー 動きに関するレビュー プログラムの書き方やアルゴリズムに関するレビュー
リリース前の試験 定性的な試験 定量的な試験

(あくまでもイメージであり、各人の得意不得意にあわせて役割が変わります)

仕様作成の際、アニメータはどのようなふるまいを作りたいかを頭に描きます。

例えば絵が得意なアニメータは、頭の中にあるふるまいを絵に起こし、説明文を添えてエンジニアに説明します。

実際、下記のような絵を頂きました(一部を切り取っています)。

エンジニアはこれを見て、アニメータと議論しながら論理的に仕様を整理していきます。

その後、動作指示に関する部分はアニメータが、意思決定などの部分はエンジニアがプログラミングします。

そしてデバッグ、レビュー、試験に関しては、アニメータが定性的な目で、エンジニアは定量的な目で評価します。

基本的には人の主観に依存しないように定量的に評価したいところですが、 動きが良いかどうかのような定量的に評価しがたい部分について、アニメータの職人的な目が重要になります。

最後に

ここまで読んで頂きありがとうございます!

LOVOTはまだまだ未完成のロボットです。

センサーが多数搭載されており、できることが沢山ある可能性の塊です。

そんなわくわくするLOVOTを一緒につくりませんか?仲間を募集しています。

recruit.jobcan.jp

LOVOT を支えるクラウドサービス

この記事は、Groove Xアドベントカレンダー2022 3日目の記事です。

こんばんは、GROOVE Xの junya です。
今回は LOVOT を支えるクラウドサービスについてご紹介します。

クラウドサービスの役割

生き物らしく振る舞えるよう、LOVOTの行動に関わる処理(画像認識・音声認識・意思決定など)はすべてLOVOTの内部で動いていて、実はLOVOT はクラウドが無くても動作するのですが、LOVOT をインターネットに繋ぐと、

  • スマホアプリとの連携(一部操作は Bluetooth でも可能)
  • バックアップ
  • 機体の診断
  • アップデート

といったことが出来るようになります。

クラウドのシステム構成

サービスのクラウド側の構成は以下の通りです。

GCPKubernetes クラスタ (GKE) 上に Go で書かれた十数個のアプリケーションがあり、「デバイス」「スマホアプリ」「オペレーター」「外部システム」の4種類のクライアント向けに API を提供しています。

サービス・クライアント間の通信

Kubernetes クラスタ上のサービス間は gRPC で通信し、外部のクライアントに対しては、grpc-gateway を用いて gRPC を REST に変換して API を提供しています。protobuf で API を定義することで、型の恩恵を受けられて開発しやすいです。

その他に、 Cloud Pub/Sub によってイベントを非同期で連携したり、機体とクラウドの間は MQTT で常時接続しています。

クライアント認証

スマホアプリや管理画面は Firebase で認証し、機体は秘密鍵をベースとした公開鍵認証で認証しています。Cloud KMS を用いて認証局も自前で実装しました。

メトリクス情報

機体のメトリクス情報は VictoriaMetrics に蓄積し、ハードウェアの診断や故障予測、サービスの改善に活かしています。

当初は Prometheus を利用していたのですが、スケーラビリティの問題から Victoria Metrics に移行しました。 なお、メトリクス情報のアップロードはユーザ設定でオプトアウト可能で、個人情報にあたる情報は収集していません。

開発プロセス

コードは github で管理し、CircleCI のパイプラインでテストやデプロイのパイプラインを組んでます。 master にマージすると、テストをしてから staging 環境にサービスがデプロイされ、社内の LOVOT やアプリから使われるようになります。 それを週1回くらいのペースで、本番環境にもデプロイしています。

なお、オーナーさん向けのスマホアプリを別にすると、クライアントのフロントエンドは主に React で実装し、App Engine にデプロイしています。

クラウドサービスで利用している技術スタック

まとめると、クラウドで利用している技術スタックはこんな感じです。

  • マネージドサービス
    • GKE Autopilot, AppEngine, Cloud Functions, Cloud Run, Pub/Sub, Cloud Storage, Datastore, Firestore, Spanner, IAP, Cloud Endpoints など
  • 言語
  • 通信
    • gRPC, Protocol Buffer, grpc-gateway, PKI (公開鍵認証基盤), Firebase Authentication, JWT
  • 開発ツール

昨秋に期間限定カフェPARK+(東京 渋谷)で行われたハロウィンオーナーイベント

ロボット開発と言うと、馴染みがない方も多いかと思いますが、クラウド開発はモダンなアーキテクチャを踏襲しているつもりです。
絶賛仲間を募集中なので、ご興味ある方は是非、採用ページも覗いてみて下さい!

recruit.jobcan.jp

LOVOTのOSのつくりかた

こんにちは LOVOT の OS を作っているチームのひとり id:atotto です。

LOVOT の OS について、簡単ですがお話させていただきます。

LOVOTとNest(LOVOT ANATOMY より一部抜粋)

早速ですが、かわいらしい LOVOT には、x86系のCPU(メインコンピュータ)、そして、ARM系のCPU(サブコンピュータ)の2つが搭載されています。これだけでも OS の管理が難しいのですが、LOVOT の製品には Nest (巣: 充電ステーション)の x86系のCPU(エッジコンピュータ)もあり、合計 3つの独立した OS が存在しています。(詳しいspecはこちら

複雑ですね。この複雑さに立ち向かうために、私達が工夫していることをご紹介したいと思います。

名前をつける

みなさん、自分たちの OS に名前をつけていますか? 私達は、 LOVOT の製品に使っている OS を LOVOTOS (らぼとす) という愛称で呼んでいます。

また、LOVOT(メインコンピュータ、サブコンピュータ)、Nest(エッジコンピュータ)の各コンピュータボードにそれぞれ tom、jerry、spike という名前をつけています。これらのボードの OS として tom、jerry、spike の 3つOSをリリース管理しています。

開発上、名前をつけるのはとても大事だと思いますので、愛着の湧く名前をつけましょう!

ansible と debian パッケージ

OS が 3つあるということは、これらの構成管理は単純に考えると 3倍になる、ということです。この OS の構成管理のために、ansible を活用しています。 今となっては ansible も枯れた仕組みの1つではありますが、基本的な構成を管理する上でとても役に立っています。 2022/12 現在、 ubuntu をベースに開発しています(2019/12 のリリース当初は debian ベースでした)。ubuntu の rootfs に対し、 ansible で etc 配下の設定や、開発上必要な設定などを施しています。私達が開発しているLOVOTに関連するサービスは debian パッケージとして管理しています。それらの debian パッケージを更にインストールし、 カーネルへ署名を施し、LOVOTOS の OSイメージが完成します。

3つの OS 、それぞれ役割は異なるものの、共通して管理したいもの、個別のものと管理できるのが良いところです。

参考イメージ: LOVOT の成長を支えるソフトウェアとクラウドサービス開発/SORACOM Tech Days 2021 資料より抜粋

debianリポジトリ aptly の活用

先述したとおり、 LOVOT のサービス群は、 debian パッケージで管理しています。この debian パッケージの管理のために aptly という debian リポジトリの管理ツールを活用しています。

https://www.aptly.info/

aptly の詳細は公式ページを参照していただきたいのですが、概要説明としては、独自パッケージのリポジトリや、ミラーリング、そしてスナップショットをコマンドライン上で操作できるツールです。aptly自身で debian リポジトリをHTTPサーバでホストすることもできます。

利用目的としては、

  • リリース時の OS で使ったパッケージを固定する(OSSのパッケージ、LOVOTのパッケージを含む)
  • OSビルド時のリポジトリへのアクセス速度を効率化する
  • リポジトリ運用コストを下げる

といったところです。

リリース時の OS で使ったパッケージを固定するために、リリース前に ubuntu の公式リポジトリのスナップショットや、LOVOTOS で利用する debian パッケージのスナップショットを作ることで、リリース時の OS を何度でも同じ内容でビルドできるようにしています。

毎晩 OS をビルドすることもあり、debian パッケージのリポジトリをビルドに近いところで管理することで効率化、また、低コストで運用しています。debian のパッケージリポジトリには、外部のサービスが多数ありますが、自分たちのフローにあわせられるツールがあるのは便利です。

daily ビルドと snapshot ビルド

LOVOTOS には大きく分けて2つ種類があります。

ひとつは、 daily ビルド。これは、最新の開発したコードベースでビルドされた OS で、unstable(不安定版)として毎日リリースしています。社内で特定の機体で利用し、不具合をすぐに見つけられるような運用で進めています。

もうひとつは、snapshot ビルド。これは、特定のリリース予定時期にあわせ、パッケージリポジトリを aptly でロックした状態でビルドされたOSです。この OS は、ソフトウェアのQA を通すために成果物を固定し、QAで不具合があった場合に hotfix という形で、特定のパッケージの更新のみ実施する、といった運用で進めています。これにより、修正差分の管理が容易になっています。

OS の配信

最後に出来上がった LOVOTOS はユーザのもとへ配信します。配信の仕組みは GROOVE X 独自のシステムとして構築しています。簡単にですが流れをご紹介します。

  1. OSビルドインフラで OSイメージを作成、 OSイメージを暗号化する
  2. 暗号化された OSイメージを、 Google Cloud CDN へ配置する
  3. ダウンロード先となるCDNのURLを署名付きURLで発行する
  4. ダウンロードURLをLOVOT/Nestへ通知する
  5. LOVOT/Nestが暗号化された OSイメージをダウンロードし、 OS イメージを復号化する
  6. LOVOT/Nestがディスクにイメージを展開し、アップデートする

このインフラもLOVOTリリース当初(2019/12)から運用開始し、これまで(2022/12 現在)述べ20回以上、ユーザのもとへOSを配信してきました。

最後に

このような複雑なシステムのロボットを、これほど頻繁にOSアップデートしている会社はそんなに多くないのではないかな、と個人的には感じています。OSを維持したまま部分的な更新を配信する(パッチアップデートについては本稿では割愛)こともありますが、OSSも含め、システム全体をアップデートしていくことで、LOVOTの成長を支えています。

かなり端折ったご紹介となってしまいましたが、今後どこかで詳細な話を記事にできたらと思います(もちろん、joinしていただくと話が早いです!!)。

最後までありがとうございました。また、この仕組みを一緒に開発したメンバに感謝いたします。 id:atotto

様々な専門家と協調しながら、色んな開発に関われるのがロボット開発の魅力

この記事は、Groove Xアドベントカレンダー2022 1日目の記事です。

こんにちは、GROOVE Xの junya です。

先日、AWSの長崎のイベントに参加したところ、色んな人から「技術ブログ書くといいよ」とオススメされたので、この機会にGROOVE Xでもアドベントカレンダーをやることにしました。

GROOVE Xでは LOVOT という家族型ロボットを開発しているのですが、エンジニアでもロボットの開発に馴染みが無い方は多いと思うので、初回の今回は「ロボット開発ではこういうことやってるよ」ってところを簡単にお伝えします。ソフトウェア領域だけでも、ざっと以下のような部分を開発しています。

LOVOT の内部実装

  • 基盤となるOSイメージの開発
  • 各種マイコンFirmware開発
  • 画像認識や音声認識、タッチ認識、SLAMの開発
  • 意志決定エンジン・ふるまいの開発
  • 外部と連携するモジュール開発

周辺システム

LOVOTの基盤OSはUbuntuで、主に利用している言語は Go や PythonクラウドKubernetes (GKE)、システム間の通信には gRPC, HTTP, MQTT をよく利用しています。意外とウェブ系のエンジニアにも親和性のある技術スタックではないでしょうか。

開発者(エンジニアやデザイナー)のバックグラウンドも様々で、ダンサー、プロミュージシャン、アニメーター、ゲーム開発者、SIer出身者、おもちゃメーカー出身者、趣味でロボットを作っている人など、色んな種類の専門家が集まっています。どんな領域のことでも聞けば誰かが相談に乗ってくれるような状態で、色んな種類の開発に携われるのがロボット開発の魅力です。

自分は創業当初から7年間 LOVOT の開発に携わってきましたが、画像認識、ふるまい開発、クラウド開発など様々な領域に触れることが出来ました。逆に言えば、どんな種類の専門性でも活かしやすい環境と言えます。

明日からの投稿で様々な領域の開発の魅力を伝えていきます。

引き続き、よろしくお願い致しますー。

落合陽一さんと日本フィルの「遍在する音楽会」に参加したLOVOTたち

GROOVE Xでの開発にご興味を持ちましたら こちらからご応募ください〜。