Meridianはオープンソースになれるのか？

Meridian計画。
ボードとデモスクリプトがギリ動くという段階になったので、至らないところがありつつも初回頒布を実施してみました。
ほりぽんさんに内容を説明する機会をいただけたので、他の方も加えてDiscordにてMeridianの概要を解説させていただきました。
お集まりいただきましたみなさん、ありがとうございました。
ここからようやくスタートという感じです。ささやかなスタートではありますが、なんとか年内にリリースをできた、ということにしたいと思います。自己肯定感大事。
Meridianは位置付け的にはアルファ版といったところですが、とにかく基板が自宅から外に出たというのは大きな一歩です。

汎用中間プロトコルというヒューマノイド研究開発の理想郷がぼんやりと見えはじめています。でも実際に使われないことには意味がありません。
オープンソースのプロジェクトは、みんなで機能を追加したり性能をブラッシュアップしていけるインタラクションに意義があると思います。可読性が高く、拡張しやすいことが大事です。見ちゃいらんないよ、ここはこうだろ！と改善しやすいことが大事です。ただコードを公開するだけで終わってはもったいないですよね。

ドリルの穴理論の間違い

ドリルの穴理論と呼ばれているマーケティングの考え方があります。
セオドア・レビット博士が「人々が欲しいのは1/4インチ・ドリルではない。彼らは1/4インチの穴が欲しいのだ」と著書の中で書いたことが起源らしいです。
よく聞く話ですが、この考え方にはかねてより疑問を感じていました。
穴だけあればOKという人も中にはいるでしょう。
でも世の中にはそういう人ばかりではありません。
自らドリルを選び、買い、操り、そして穴を開けるというプロセス自体に楽しみを感じ、そこに価値をおく人が一定数いるのです。
そしてロボット開発という酔狂な趣味を持つ人は、だいたいそういう人ばかりです。
なので穴、つまり出来上がったシステムだけを提示されても、そういう人にとっては全く面白くないわけです。システムを作ること自体が面白くてやっているのに、なんで人が作ったものを使わせられなきゃいかんのだ？と。お節介でしかないわけです。

じゃあどうすれば

Meridianに該当する仕組みは今ちょうど世の中に足りないピースだと思います。なのでそこを何人かが個別に掘っている、もしくは掘ろうとしている状態なのだと推測します。昨日のミーティングでも、いろいろなニーズや、各自の取り組みなどについて伺うことができました。興味の対象が互いに補完しあえそうな関係にあるということも見えてきました。
まずは近い人から、互いに同意できる部分やすり合わせで共有できる部分を増やしていければと思います。そこからじわじわと単なる俺フォーマットから脱却した汎用フォーマットという理想系を見出していきたいと思います。

今後開発を進めるにあたり、以下の留意点を意識できればと思います。

留意点１：開発リソース

ロボットの開発はあらゆる方面に時間がかかります。そしてこれは実感なのですが、ロボット開発の興味領域は、個人の中でも刻々と変わっていきます。制御に凝ったり、外装に凝ったり、機構に凝ったり、インタラクションやUIに凝ったり、VRに凝ったり、センシングに凝ったり、ROS連携に凝ったり・・・
開発途上のMeridianを導入することも少なからず開発リソースを消費しますので、個人それぞれの開発テーマを圧迫せぬよう、今まさにちょうどそこの開発をしたいと思っていた！という方とすり合わせ、共同開発していければと考えています。そして他の方でも、興味が湧いた時にはいつでもふらっと参加できる、そういう状態にできればと思っています。

留意点２：ソフト・ハードの継続性と学習コスト

ハードはなるべくメジャーで入手性の良いもの、汎用性の高いもので構成します。そうすることでデータからでもハードを組み立てられる再現性、継続性を担保します。
ソフトウェアについても最大限メジャーなフリーソフトを利用します。
ソフト・ハードの継続性を担保することで、この仕組みの導入を一過性のものではなく、使いがいのある一般性の高いものにできると思います。

留意点３：疎結合性・ゆるさ

プログラムはファイル単位、関数単位で管理できるようにし、開発が進めやすいようにできればと思っています。
Meridianの実態は単なる配列なので、開発を疎結合するには向いていると思いますが、コアの部分のディテールについては、開発ポリシーのようなものを今後決めていく必要があるかもしれません。

留意点４：拡張性・ゆるさ

個々がやりたい開発を手助けこそすれ妨げにならぬよう、ハードの役割を決めすぎない、ということも大事かと思います。
一方で、ある程度の決め事を作ることで、開発リソースの共有はしやすくなります。ということで、みなさんと一緒に作りながら、コマンドの予約領域などを決めていければと思います。

留意点５:合理性と汎用性・ゆるさ

スクリプトの非効率な部分はどんどん効率的なものに差し替えていけるフレキシビリティを持たせたいと思います。
また、いただく意見を増やしていくことでなるべく合理的な着地を目指せれば思います。真に合理的なフォーマットは、誰が作っても自然とそういう感じに落ち着くだろうなというものになるだろうと考えています。

留意点６:便利さとゆるさの共存

機能や設定項目の多さは使いやすさとのバーターになります。設定項目は少ないほど扱いやすく、多いほど使いにくくなっていきます。
そこでフォーマットのデフォルト状態はなるべくそのままの状態で使いやすく、わかりやすく。でもやりたいことが増えた場合にも大抵のことには対応できる、そんな両立が許される柔軟性を持たせたいと思っています。
油断すると風呂敷がどんどん広がっていつまでたっても使えない、開発が終わらない…という状況になりかねないので、理想型よりも実用しやすいものの優先度を高め、地に足をつけていきたいと思います。
まずは既存の使い慣れたシステムと交換しやすい環境を整えていきたいと思います。

留意点７:ニーズを聴く会と開発の会

こちらは風呂敷を広げる方向にはなってしまいますが、開発サイドで集まる会とは別に、ロボットを作られている方の率直な希望をいろいろ聞いていく会を別途設けるというのもよいなと思っています。すぐには機能として実装できなくても、プロトコルの中に領域を予約しておくことはできます。

これからやること

まずは複数のFUTABAサーボを使えるようにしていこうと思います。
その次に、モーションシークエンスを再生する仕組みと、ごく簡易的な最低限のモーション作成プログラムを作る予定です。

次の記事：

前の記事：

目次：