こんにちは、SWチームの Junya です。
LOVOT は様々な技術要素が組み合わさって作り上げられていますが、 LOVOT がどのように開発されているか、 なかなかイメージしにくいのではないかと思います。
その中でも特にイメージのしにくい、LOVOTの基盤部分の開発について、 Lovot Framework チーム (以下LFチーム)の皆さんにインタビューしました。
前編・中編・後編の3部構成でお送りするので、お楽しみください！
Lovot Framework チームってなに？
司会
さっそくですが、本日はよろしくお願いします。 今日は、LFチームってどういうチームなのか、普段どういう仕事をしているのかなど、ざっくばらんに聞かせてください。
それでは簡単に自己紹介をお願いします。
ato
id:atotto です。LOVOT 3.0 では、クラウドサービスの開発からすこし離れ、LOVOTのアップデートインフラ構築や、LOVOT自体のアップデート、データ配信基盤、セキュアブート対応などに関わりました。Goでサービスを書き続けています。
h1sakawa
GROOVE Xに入社して3年目になります。LOVOT 3.0では、BIOS/UEFI、Linux Kernel、ドライバ開発、デバイスは内部ストレージや目の映像出力などを担当しています。
bucchi
以前、半年働いて感じたGROOVE Xの面白いところという記事を書いた bucchi です。 あれから時間が経ち、GROOVE Xに入社して2年が過ぎました。
LOVOT 3.0では、OSビルド、Linux Kernel、ドライバの開発や、ファームウェアとの通信部分などの開発を担当しています。
司会
LFチームってどのようなことをしているチームなのでしょうか？
ato
LFチームっていうと定義が曖昧で、結局いろんなところを担っているのですが、 LOVOT 内で動作している Linux OS のシステムづくりとか、 いろんなデバイスと上位SWとを繋ぐためのセンサー配信の仕組みづくりとか、 そういったところがメインとして挙げられると思います。
司会
センサーやOS以外に、アップデートの部分も開発していますよね。
ato
本当はアップデートは別のチームとして立ち上げたいな、と思っています。
というのも、OSという意味ではLFも関係しているのですが、 アップデートとしては OS だけではなくて、クラウド側の配信の仕組みもあるんですよね。
司会
アップデートは、OSとクラウドまでつながってますもんね。
ato
そうですね。LFチームでは Linux カーネルのメンテナンス、OSの作成から始まって、 OS アップデートまで、ぼやっと繋がっているので、きれいな境界はないですね。
LOVOTOS の話
司会
まずは LOVOTOS （LOVOT のOS）の話からはじめましょうか。 OS をアップデートするってことは、OS 自体の作成も必要じゃないですか。
bucchi
OS の作成とか、アップデートを全部込みで言うと、 LOVOTOS っていうディストリビューションを開発して配信している感じです。
司会
たしかにそうですね。 Ubuntu と同じレイヤーではなさそうだけど、どういう位置づけでしょうか？
ato
Debian→Ubuntu→Kubuntuみたいな、カスタマイズされていく流れで言うと、 Ubuntuから派生した、 Ubuntu ベースの LOVOTOS っていうイメージかな。
司会
ちなみに皆さんは、LOVOTOS以外でディストリビューションやカスタムOSを作ったことはありますか？
bucchi
私は、ディストリビューションっていうと違うかもですけど、 GROOVE Xに入る前も組み込み Linux の仕事をしてきたので、色々と製品向けのOSは作ってきました。
司会
だいたいどういうところから始まるんですか、そういうOS作りって。
bucchi
会社や製品によりますが、商用ディストリビューションを買ってきて載せる場合は、 その商用ディストリビューションをベースに、製品ボードに載ってる SoC 用の kernel をポーティングして作る感じですね。
SoC のチップベンダーから kernel が提供されるのですが、製品の用途に合わせてみると、 たいていの場合、製品レベルに達していなかったり、機能が足りないことが多いんですよね。
なので、それを商用ディストリビューションの kernel にポーティングしながら製品レベルの品質に仕上げていき、 BSP（Board Support Package）と呼ばれる、自社ボード用にドライバ等を合わせこんだ、小さな Linux みたいなものを作って、 それに製品で使うOSSパッケージを追加してOSを作る、といったことが多いです。
LOVOT では商用ディストリビューションは使わずに Ubuntu を使っていますが、大体は同じ流れです。
司会
LOVOT 3.0の開発でいうと、NVIDIA から kernel が提供されるということでしょうか？
bucchi
はい。そうですね。
LOVOT 3.0 では NVIDIA 社の Jetson Orin NX を使ってまして、NVIDIA から提供されている Jetson Linux を使っています。
組み込み系の Linux では珍しく、ベンダー提供の kernel やドライバがかなりしっかりしていて、 商用レベルで使えるぐらいの品質だったので、 BSP開発っていう大げさな感じではなく、軽くポーティングしてるくらいの感じですね。
ansible
司会
なるほど。それから、GROOVE Xでは ansible を使っていますよね。
bucchi
はい。 Ubuntu のパッケージと Jetson Linux のパッケージを組み合わせてベースのものを作って、 ansibleで必要な修正を加えています。
ato
今の構成管理は必要なファイル配置してることが多いから、ansibleじゃなくても良さそうなところまで来てますね。
bucchi
そうですね。確かにがっつり構成管理をしているわけではないので、ansibleの良さはあんまり生きてないかもしれないです。 OSをビルドするたびに1から生成し直しているので、冪等性とか関係ないですし。 ファイル配置とかがうまくできるツールがあれば、そっちでもいいかも。
話がちょっと逸れちゃいますけど、ansible は intel 系のホストで arm 用の OS を変更しようとすると、QEMU 上で動かすので遅いんですよね。
司会
そうなんですね。
bucchi
ものすごく遅いんですよ。QEMU上 で Python 使って、apt install とかをするので、めちゃくちゃ遅くって。 なので、他の仕組みがあったらそちらの方が良いかも知れません。
OSビルド
司会
ansibleは、Jenkins 上で chroot して実行してる感じですよね？ そこに Jetson 用のSWとかを組み込んでる感じでしょうか？
bucchi
そうですね、Jenkins上で動かしています。
Jetson用のSWは全部debパッケージになっているので、Jetson を意識する必要はなく、 普通のdebパッケージのインストールの形で、構成できるようになっています。
司会
Ubuntuのコアみたいなものに、Jetson用のdebパッケージを入れてあげれば、Jetson対応できちゃうってことですね。
bucchi
そうですね。このあたりのOSの構築方法は、LOVOT 1.0/2.0 用の LOVOTOS のビルド方法を踏襲しています。
司会
その後はどうするのでしょうか？
bucchi
LOVOT関連のパッケージも含めて必要なパッケージを一通りインストールして root filesystem ができたら、 ext4 のイメージ(Linuxのファイルシステムのイメージ)を作ります。
root filesystem を各パーティションごとのディレクトリに分けて、それぞれのext4のイメージを作っています。
インストーラーの作成
司会
それが出来上がったら、暗号化して配信するんでしたっけ？
bucchi
OSアップデートっていう意味だとそうなんですが、それとは別にインストーラーも作る必要があります。 アップデートができる前に機体にインストールする用途だけでなく、 生産フェーズで、機体にOSを書き込む際にも使います。
ext4のイメージを作るところまでは先ほど説明した通りで、 それを実際にJetson上で書き込むところは、NVIDIAから提供されているツールをカスタマイズして使っています。
そのツールを使ってパーテーションを切ったり、ext4に分けたイメージを特定のパーテーションに書き込んだりしています。
司会
インストーラーとは、USBインストーラーのことでしょうか？ （GROOVE Xでは、オフラインのお客様向けに、USBのインストーラーを提供することがあります）
bucchi
USB経由ではあるんですが、USBメモリーから起動して書いてるわけではなくて、Jetson独自の仕組みでUSBブートしています。
ざっくり言えば、USBブートを使ってブートローダのイメージやLinux kernelを流し込んで Linuxを起動して、USBをネットワークデバイスとして見せて、ホストPC側のファイルをNFSをマウントして書き込む、みたいな感じです。
その一連の仕組みはNVIDIAから提供されているツールの機能で、書き込むデータの部分だけカスタマイズしています。
司会
OSが整ってからのアップデートはOTA (Over the Airの略: ネットワーク経由でアップデートすること)で出来るけど、はじめの段階ではこういう仕組みが必要なんですね。
bucchi
そうですね。 開発初期や生産時にUSBブートしてインストールする仕組みを利用しています。
司会
そうすると、LOVOTOS のインストールの手段は3つあるわけですね。 お客様先でのアップデートと、オフラインのお客様向けのUSBアップデートと、生産や初期開発のためのUSBブートの仕組み。
bucchi
そうですね。OSを書き込む手段としてはその3つになります。
アップデートの話
ato
JetsonでもUSBアップデートやOTAのような仕組みは提供されてたりするのかな?
bucchi
アップデートの仕組みは提供されていますね。
そのうちのブートローダーのアップデートしか LOVOT 3.0 では使っていないですけどね。 システム自体アップデートする機能も提供されているんですが、諸事情があって使っていないですね。
まだ LOVOT 3.0 の開発初期のときはJetson Linux でアップデートがサポートされていなかったんですよ。
あと、Jetson Linux のアップデートの仕組みでは、LOVOTみたいにファームウェアアップデートを挟み込むとか、 通知を目にアニメーションで表示するとか、そういったところはカスタマイズしにくいので、 初代のLOVOTで十分仕組みが作られていた、既存の仕組みを踏襲した方が良さそうだって判断しました。
ato
LOVOT 3.0 の開発時点では、Jetson のアップデートの仕組みは提供されてなかったので、自社で作ったって感じですね。
司会
たしかに、アップデートするときに、アップデートの目になったりしますもんね。
アップデートはどうやって LOVOT に反映するんですか？
bucchi
ざっくりいうと、通常のシステムとアップデートのシステムがあって、 それを切り替えてアップデートを実行しています。
多分アップデートがあるどの製品もそういう構成になっていると思いますが、 自分自身は書き換えられないから、別のシステムで起動させてから 通常のシステム側を書き換えるていますね。
2面化するこの方式は大体どの製品のアップデートでも似ていると思いますね。
長くなってきたので、前編はここまで。
GROOVE X では仲間を絶賛募集中です！
LFチームでは、組み込みLinuxだけでなく、サーバの構成管理やサービス(デーモン)の開発経験、 Goを使ったバックエンド開発などのスキルを持っている方を探しています。
一緒に LOVOT を作りませんか？
recruit.jobcan.jp recruit.jobcan.jp
次回、「Lovot Frameworkチーム座談会（中編）：ハードウェアとの連携」に続きます。
お楽しみに〜！
