こんにちは、@muo_jpです。本エントリはAndroid Advent Calendar 2012の参加エントリです。
最近仕事ではソーシャルな会社でC#(音楽記号でない)を書いてます。最近書いたMonoのバグフィックスpatchを本流へ取り込んでもらえて喜んだりしてました。
今回は、以下のような方に向けたお話です。
- ソフトウェアの世界に居るけど出来ればハードもやりたい人(私だ)
- オームの法則ってなんだったっけ?というぐらい電気系から遠ざかってる人(私だ)
- 中学・高校であんまりまじめに物理やらなかった人(私だ)
- 自分で書いたり作ったりしたものが動いて嬉しい人(私だ)
- Cとかもう何年もまともに書いてないよ(私だ)
つまり俺得。
Maker Faire Tokyo 2012(以下MFT2012)にて、@miw0129と二人組でこんな展示をしました。
$ make box --arch=Japanese --style="kare-sansui"一緒に日本伝統の庭園様式「枯山水」で遊びましょう。 枯山水では空間に敷き詰めた白砂や小石に紋様を描き水の流れを表現します。 スマートフォンアプリに指先で描いた紋様をテーブル上の箱庭へ自動作庭します。現実の庭には場所と機材が必要ですが、箱庭なら机の上で。 やってみるとこれが結構難しい。けれどアプリならデザインも描き直しも思いのまま。大人も子供も手軽に日本古来の文化へ触れて楽しめる、そんな展示です。
二人ともソフト方面のひとでハードはほとんどやってない。けれどやりたい。ということで8月半ばからネタを考えていました。タイムライン的には大筋まとまったのが9/17、紹介文をまとめて出展申し込みをしたのが9/19未明、最初のハード材料買い出しが10/31、アプリを書き始めたのが11/3未明、出展が12/1-12/2でした。
実際に作ったのはこんな感じです。
基本、Arduinoでサーボモーターとステッピングモーターをひたすら制御してX,Y,Z軸を管理するプロッターになっています。作業分担でミスる箇所も多々ありましたが、アプリをガリガリ書いて、時折頭切り替えてハード機構考えたりモータ制御系作ったりと純粋に楽しかったです。
しかしやっぱ、ハードって大変ですね(;_;) どれぐらいハードに馴染みが無いって、モーター制御主体のネタにも関わらず千石電商の店頭へ行ってみて初めて「ステッピングモーター」なるものの存在を知り、店頭に置いてあったデータシートからなんとなく仕様を推測し、買ってみてから必死こいて調べて動かせるようにする、というぐらいでした。
ハード部分と躓いたとこはこんな感じ。
- 今回、素材は基本的に東急ハンズで入手した5mm角材と3mm/2.5mm竹棒
- 金属とか重いし樹脂とか割れたら泣くしかないし接着性考えたら木材だよね!
- 寸法うまく合わないの
- 普通のハサミで木材をぐぎぐぎ切ったりするからだね
- 多少大きめに切ってネイル用のグリッド180のファイルをかけて仕上げる悲しき職人芸
- なんか斜めってしまい涙目
- アロンアルファなんだかいい匂い
- 材料がもろくて割れたり折れたりするの
- 作る→折れる→もう一つ作る→割れる→心折れる
- 木の種類によっても強度が変わるかも
- ピンバイスと仲良しになった
- 桧なんだかいい匂い
- モーター荷重をちゃんと考えないと動かないの
- 全同時制御とか電源が死んじゃうの(今回は1軸ずつ制御で回避)
前述のように、二人ともハードに極めて不慣れなので、今回ハード機構自体は極力シンプルな作りにして、愚直な実装でゴリ押しする部分はゴリ押しし、ソフトでどうにかなる部分はどうにかしようというアプローチをしました。それでもなお想定よりも作庭機構自体の作り込み難易度が高く、また手間もかかったあたりがなかなか辛いところです。
ともかく失敗しまくりましたが、どうにか形へ仕上げたことで見えてきたものが多くあるので覚えている限り書いてみます。
= アプリからのハード制御で注意した点 =
あるサービス(体験)を実現しようと考えて、どのシステム要素にどういう処理を担わせるかというのはやはり大切。一例挙げるとこんな感じ。
- ADKを使えばほとんどの処理をJavaで書くことができる。それを利用してArduinoは純粋に物理的な制御(モーターの回転、センサー読み取り)へ注力するという実装スタイル
- その場合、秒間30回程度の処理を実現するのに、モーター数を5と想定して150のコマンドを渡しつづけることが必要。しかし、これじゃおちおちGCもしてらんない(でも制御コードは書きやすいかも)
これはアプリ/Webサービス開発で、サーバと端末ネイティブ/Webブラウザ上での処理責任をどのように分解するかというのとほぼ同じ話。
そもそもどこで処理出来るか、リアルタイム性要求有無、通信速度制約、計算量(時間/空間)、バッテリ消費量、開発と検証の容易さを勘案した上で適する場所に実装するという感じです。当然、これがちゃんと掴めないうちは本来書くべきではない場所に大量のロジックを書いてしまったり、一般的に売られている安価なICを使えば安定処理出来る場面で不安定な自作コードを突っ込んでしまったりと、頭を打つことがいっぱいあります。
が、まあそれはそれで良いんじゃないでしょうか。ソフトもそうやって勉強してきたし。ハードの場合ぶっ壊してお金がかかるケースも多々あるのである程度の注意は必要ですが、個人的には(頒布を考えない限り)ﾋﾞｸﾋﾞｸして踏み込まないよりは えいやっとやってしまえば良いと思います。それでもAndroid端末を文鎮化させるより懐は痛まないはず。
そもそもどこで処理出来るか、リアルタイム性要求有無、通信速度制約、計算量(時間/空間)、バッテリ消費量、開発と検証の容易さを勘案した上で適する場所に実装するという感じです。当然、これがちゃんと掴めないうちは本来書くべきではない場所に大量のロジックを書いてしまったり、一般的に売られている安価なICを使えば安定処理出来る場面で不安定な自作コードを突っ込んでしまったりと、頭を打つことがいっぱいあります。
が、まあそれはそれで良いんじゃないでしょうか。ソフトもそうやって勉強してきたし。ハードの場合ぶっ壊してお金がかかるケースも多々あるのである程度の注意は必要ですが、個人的には(頒布を考えない限り)ﾋﾞｸﾋﾞｸして踏み込まないよりは えいやっとやってしまえば良いと思います。それでもAndroid端末を文鎮化させるより懐は痛まないはず。
= やばいこのままだと間に合わない。そんな時のゴリ押し方法 =
これも基本的にソフトと同じで
- 経験を突っ込む
- お金を突っ込む
- 時間を突っ込む(思考または作業量)
の3択だと感じました。設計通りに作っても機構制御がうまくいかないことが判明したけれど開発経験が浅い、時間も限られてる、となればあと突っ込めるのはお金です。幸い今回利用したのは最高額パーツで1,500円程度と、ハード/ロボット作りにおいては相当安価な部類でした。このため、きちんとした機構設計を諦めてモーターを追加投入することで時間短縮を実現出来ました。ただ、これまたソフトと同じでお金突っ込んでデカい構成で逃げようとしても、結果それをドライブ出来ずに破綻するということもありそうなのでこれだけでどうにかなるものではないです。やっぱ事前にちゃんと考えを及ばせられるようにすることが大事(これもソフトと同じ。けど前提は慣れでもある)。
一方で「もう秋月も千石も閉店した。出展は明日。けどArduinoのI/Oピン数がどうあがいても1つ足りないヽ(`Д´)ﾉ」という絶望的な状況もありました。これに関してはArduino標準ライブラリ内のドライバ実装を読むことで「同種類のモーターに同じ挙動をさせるために、サーボ制御用信号線を2つのモーターで共有出来る」と結論付けて対応しました(いわゆるアナログサーボで、ID書き込み&ロングパケットでのID指定複数同時制御などは出来なかった)。
このあたりがオープンハードウェア(+開発キット群)の嬉しいところですね。困った時やチート技を発動したい時に、万一制御対象の仕様をあまり知らなかったとしても、制御コードを読むことである程度の推測を働かすことができます。
= ハードを作る上で大事そうなところ =
これも、ごく一部ですが失敗を重ねながら作ってみる中でなんとなく見えた気がします。大原則は「ユーザインタラクションを分かりやすくする」ことで
- ボタンを設けるなら数をなるべく絞る
- 一言でうまく説明出来るコンセプトに沿った作りを心がける
- 操作に慣れてきたらやりこむ要素とかあっても良いのかも(このへんはまだあんまり見えてない)
なんだ。ソフトウェアのUI/UX的なお話とかなり近いじゃん(多くのソフトUIは実在ハードのメタファだったりするから当然か)。その中で、いかにハード的な制約を取り払うか、あるいは制約自体を楽しめるように作り上げるかとかがキーっぽいなぁと思います。
= 一周やってみて「ADKって何だろう」と捉え直してみる =
勝手な思い込みかもしれませんが、ADKについて持たれている期待というのは「Android端末を更に活かせるようなハードアクセサリを作る」ものと認識しています。ADK(Accessory Development Kit)またはAOA(Android Open Accessory)という名称自体がそれを如実に表していますね。
ところでMFT2012への出展ネタを固めた翌日の9/18、八重洲某所でこんなイベントがありました。
この中で、Harpy nanoの製作者である株式会社鳥人間の久川氏がこのようなトピックを話しておられました。
「ハードを作る際に、0→1と1→100は全然違う。1台だけ出来るというのは量産出来ることを意味しない。その先の苦労のほうが長い道のりになる。」
仮にADKベースで100台-作って販売することを考えると、その受け取り手って誰だろう。考えてもみてください。特に家庭内での利用を前提にすると、いちいちUSBケーブルをつながなきゃ動作しないものなんて普通の人は見向きもしません(Android端末複数台持て余してるのはごく一部だ。起きろ)。
そうなると量産可能そうなADKプロダクトは充電出来るドックだらけか、一部の開発者クラスタ向け/イベント向けのもの/パーティーゲーム系に限定されるはずです。つまりADKってそもそも0→1のプロトタイプ作成用か、せいぜい10-max50あたりのワンオフ的な用途に留まるものでしょう。
そうなると量産可能そうなADKプロダクトは充電出来るドックだらけか、一部の開発者クラスタ向け/イベント向けのもの/パーティーゲーム系に限定されるはずです。つまりADKってそもそも0→1のプロトタイプ作成用か、せいぜい10-max50あたりのワンオフ的な用途に留まるものでしょう。
この前提を置いてADKにおけるAndroidとは何なのかを捉えてみると、
- ネット接続環境
- ユーザとのインタラクションポイント
- 画面出力 / 音声出力 / タッチ入力 / 音声入力 / その他センサー入力
- モバイルとしては爆速なCPU
- モバイルとしてはそこそこ容量のあるバッテリ(ただしADKデバイスへの給電には使えない)
- ひょっとするとGPGPUに使っても嬉しいかもしれないレベルのGPU
- Java、C、C++(場合によってはJavaScript他も)でコードを書いて走らせることの出来る環境
- 場合によってはアプリ本体やデータの更新をプッシュすることの出来る環境
となります。こう考えるとADKってAndroidに独自ハードをくっつけて何かをする、というよりは 自分の作りたいハードを構成する要素としてAndroidを加える、と捉えたほうが良い発想を出来るのではないかと思えてきます。例えば、画面入出力が不要なら Android端末はユーザの目に全く触れない場所に埋め込んでても良いんだ。セガのNAOMIがドリキャスをほぼそのまんま筐体内に抱えてたようなイメージ。Androidを中心に発想してると、どうしても端末は手に持って画面に何か出さなきゃダメなんじゃないか、と向かいがちなんですが、実はこれが不要(ADKだよ!というのをマーケ要素に使いたい場合を除く)ということを実感出来たので良かったと思います。
ちなみにもう少し現実路線を考えると、ADKで端末連携ハードの世界に入り込んで0→1の部分を実現し、プロトタイプしたサービスの量産化を考える際にはBluetooth Low Energy(BLE)を利用した通信をベースにするのが筋良さそうな感じしてます(実際使ってないので適当です。プロトタイプ向きなライブラリを整備した後は最初からBLEでも良いかも)。
ここでは挙げませんが、実際ハードについては分かってないことだらけです。回路設計まだまだ出来ないし、電源安定しなかったらとりあえずコンデンサぶっ込めばいいのん?という程度です。それでも、ハードへの最初の一歩を踏み出すサポートとして、Android/ADKは素晴らしいものだと思います(が、Arduino IDE、おめーはダメだ→注)。
= そんなかんじ。 =
さて、アプリ開発者がハードに触れて起こったことの顛末を赤裸々に書いてみました。ここで書いてることひとつひとつは、多分ハードやってる人からすると当たり前のことです。けれど、ハードを作るという経験をほんの少しだけど実際にしてみたことで、より実感を持てたのでまとめてみました。
もしもこの記事を読んでハードに興味を持った方が居たら、是非作ってみて欲しいし私にも自慢して欲しいし、もし可能ならMaker Faireは凄く良い機会だと思うので来年ぜひ出してみてください!
あの場は、必ずしも技術的なハイエンドさを追求するステージではないのです。こだわって作りたい、形にしたいという欲求のまま作って それをいろんな人に共有する場と感じました。見に来て下さる方に学ぶこといっぱいあるし、周囲の出展者の熱気も伝わってくるし、もっとやりたいという気持ちになる、そんな場所でした。
失敗も多くあり、不完全な形で皆様にご覧頂いたところなど反省する箇所は非常に多いのですが、間違いなく面白かったし再び作って出展したいと考えています。
-- 俺たちは登りはじめたばかりだからな、この果てしなく長いハード坂を(って打ち切りじゃないよ)
注: 実際やってみて感じたArduino IDEでの開発についての課題
- Arduino IDEは、とにかく酷い
- なんというかエディタとしての出来が最悪。Mac標準テキストコンポーネントで使えるEmacsキーバインドすら使えないし
- シリアルコンソール開きっぱに出来ないし
- 使った(USB)シリアルポート覚えてくれないし
- Web/アプリな人がこの先もっと興味を持つのでは、と考えるとEclipseベースのほうがはるかによさげ
- Arduino開発用のEclipseプラグインがあるっぽいのでGitHubでforkだけした
- C# + .NET Framework + Visual Studioに近いレベルのLLなハード開発環境って案外実現出来るんじゃね?なるたけちゃんとコミットしたい
0 件のコメント:
コメントを投稿