coord_e

## 概要 今日のソフトウェア開発においてDockerイメージを作成する機会は非常に多くなっている。Dockerイメージのサイズを小さくすることは、開発のサイクルを短縮する良い機会となる。 Dockerイメージから実行に必要のないファイルを省くために、一般的には静的リンクが行われている。静的リンクによって実行可能ファイルが環境に依存せず実行できるようになり、安全に `alpine` などの軽量なベースイメージの上に（マルチステージビルドを用いるなどして）配置することができる。 さて、静的リンクが簡単に可能な状況もあれば、そうでない状況もある。また、そもそもDockerイメージを作成する際にソースコードが利用可能でない場合もある。しかしそういった場合にも、実行に必要なファイルだけをうまく集めれば、静的リンクせずとも小さなDockerイメージを作ることができる。私が作成した `magicpak` は静的リンクが困難な状況においても最小限のファイルを含んだDockerイメージを作成することを可能にするCLIツールである。 [](https://github.com/coord-e/magicpak) ブログ記事: [magicpak: 静的リンクなしで小さなDockerイメージを作る](https://coordination.hatenablog.com/entry/2020/04/15/014847) ## 機能 - **シンプル**. Dockerイメージをビルドする際のワークフローは変わらず、`Dockerfile` に数行手を加えるだけで作業が完了する。 - **多機能**. `magicpak` がDockerイメージを縮小するための面倒ごとを全て引き受けるので、本来のロジックに集中することができる。 - **動的解析**. `--dynamic` フラグで、動的リンクされたライブラリファイル以外の依存ファイルも発見することができる。これは他の類似ソフトウェアには見られない機能だ。 - **柔軟性**. いくつかのフラグを通して出力を完全に制御することができる。これは `magicpak` の自動解析が依存性を発見するのに不十分だった際にも、手動でフラグを足すことで十分に対処可能だということだ。 ## 着眼点 `magicpak` は対象の実行可能ファイルの実行時の依存ファイルを解析して集めるツールだ。実行時の依存ファイルを集めるために、`magicpak` は次の二つのアプローチを実装している: - **静的解析**. ELFを解析して動的リンクされたライブラリを集める - **動的解析**. その他の依存ファイルを、システムコールのトレースによって集める 前者の静的解析は、実行可能ファイルの依存性の大半は動的リンクされたライブラリファイルだという仮説に基づいている。実際、これは静的リンクによる方法と同等の効果が期待できるし、大半のユースケースはこれでカバーできる。 後者の動的解析は、さらにアグレッシブな解析を試みる。実行可能ファイルの中には、実行時に動的ライブラリ以外のファイルに依存しているものがある。例えばコンパイラのランタイムシステムのリソースファイルなどを起動直前に読み込んでいる場合があり、そういったものは前者の静的解析では発見できない。動的解析のアプローチでは、実際に対象の実行可能ファイルを実行し、実行時にアクセスしたファイルをシステムコールをトレースすることによって集めている。 これら二つの自動解析を実装することで、`magicpak` は幅広いユースケースに対応している。

## 背景 ヒューマノイドロボットを個人で製作し、その製作手法を公開している人はとても少ない。また、ヒューマノイドロボットを製作したいが、技術情報の不足から製作を断念する人が多く見受けられる。ヒューマノイドロボット製作のハードルが高い原因としては、第一にロボット本体を製作することが非常に高度な技術を要すること、そして第二に、ヒューマノイドロボットの制御が難しいことが挙げられる。私と山名は、独自のヒューマノイドロボットの製作過程をブログやWebページで公開したり、プログラムや3Dモデル、制御基板の設計情報などをGitHubで公開したりすることで、前者の問題の解決に努めてきた。しかし、後者の問題については未だ解決策がない状況が続いていた。 ## 概要 そこで本プロジェクトでは、ロボット製作者にその制御の難しさを感じさせないようにするための取り組みを行った。サーボモータで構成された様々なロボットに対して思い通りの動作を生成するための支援フレームワーク（Reficere, BlendMotion, flom, trainer, servoarray）を作成し、自ら使用すると同時にその取り組みを社会に認知させ実際にロボット制作者を支援するために展示会（Maker Faire Tokyo 2018及びWorld Maker Faire New York 2018）への出展等の広報活動をした。私は本プロジェクトのソフトウェア寄りの部分を担当した。 本プロジェクトで開発したフレームワーク“MonoMotion”は大きく分けて以下の 3 つの部分に分割され る。括弧内はそれぞれのソフトウェアの名前である。 1. ロボットモデルを作る（Reficere） 2. モーションを作る（BlendMotion, flom） 3. 実機で動かす（trainer, servoarray） このうち私が開発したのは BlendMotion, flow, trainer, servoarray である。 ### ロボットのモーションを作る 人間がロボットの動作を作成するためのインターフェースとして、BlendMotion というソフトウェアを開発した。これはBlenderという3GCGソフトウェアのアドオンである。3D世界で動きを作成するのに最適なUIを考えた際に、3DCGのアニメーション作成のUIがもっとも近いだろうと考えてBlenderを選択した。  さらに、モーションを作成した後にそれを保存する手段として、ファイルフォーマット兼ライブラリの flom を実装した。 flom ライブラリはプロジェクトの根幹となるものであり、バグの混入が広範囲に影響を与える可能性があった。それを防ぐために Property-based testing を採用し、堅実なテストケース作りを心がけた。flom は本フレームワークを構成する複数のソフトウェアから利用されるため、複数言語へのバインディングが記述しやすいC++で実装した。Pythonで実装したBlendMotionでは、flomのPythonバインディングを利用している。 ### モーションをロボットの実機で動かす BlendMotion で作成したモーションは物理シミュレーションをして作成したものではないため、そのまま 実機で動かしても思い通りになるとは限らない。そこで、シミュレーション上で学習を行い、モーションを 自動で多少修正することを行う。これを Derivative-free optimization により自動で行うソフトウェア”Trainer”を開発した。  また、学習によって修正されたモーションを実機で動かすためのソフトウェア、 flom-runner を開発した。モーションは flom に出力されているため、これは flom のモーションを実機で再生するソフトウェアと言える。さらに、ロボット間のサーボモータードライバの違いを吸収するため に、サーボモーター抽象化ライブラリ servoarray を開発し、flom-runner で使用した。 これらを使用することで、最終的に BlendMotion で作ったモーションを学習によって最適化し、実機で思い通りに動かすという目標が達成されたことになる。  ## 成果 本フレームワークにより、ホビーユーザ層に存在していたロボット制御への障壁を緩和できた。ロボットのプログラミングに触れたことのない中学生の後輩に試しに使ってもらったところ、約40分でロボットに目的の動作をさせることができた。これは本プロジェクトを開始する前の2人がロボットを動かすまでに約9ヶ月かかっていたことを考えると大きな進歩であると考えている。 このプロジェクトの成果により、[私は 2018 年度未踏スーパークリエータに認定された](https://www.ipa.go.jp/files/000074100.pdf)。