ArduinoとWiiリモコンで動く超手抜きロボット

これまでArduinoはセンシングにばかり使っていたのでたまには他のものにも使ってみたかったわけだが、今回はその念願が叶い、自走ロボットの制御部として利用することとしてみた。

もともとは某大学で「ロボットを作ろう！」というテーマのワークショップをやることがきっかけだったのだが、いきなり自走するロボットを作ろうとしても、手元に何もお手本がないのはやりにくい。そこで海外の通販サイトでキット販売されている「Boe Bot」なるものを取り寄せてみた。サーボモータ2つとベーシックで動くマイコン、いくつかのセンサと筐体とが同梱されて15000円ほど。学生（おそらく高校生）向けの教材として売られているので、テキストが充実しており、きちんと内容の順序に従って取り組めば40時間ほどかかる（と、テキストには記載されている）ものを、ロボットの作成部分だけに省略して2時間足らずで完成させる。これのプログラムをいじって一通り遊んだ後、操縦系をArduinoに変更することとした。機材の汎用性／一般性を重視したためだ。ちなみに、元々のベーシックベースの開発言語もそこそこ使いやすいものであった。

Arduinoへの移植については、instructables.comに掲載されていたこの記事を最初は参考にした。この記事でもBoe Botがベースになっているので、移植自体はさほど困難はない。記事では超音波センサを使い、障害物をよけて自律移動するロボットを作っている（それ自体もBoe Botのオプションで販売されている）が、今回は自律移動型ではなく、リモコン操作型のものをつくることとした。これは私自身の研究側の都合である。

リモコン操作といえば、赤外線で動くものがすぐに思いつくが、赤外線のリモコンは受光部が裏を向いてしまうと反応が悪くなるので、Bluetoothで操縦することを目指すこととした。Bluetoothでリモコンといえば、手っ取り早く思いつくのがWiiリモコンである。思い返せば5年くらい前にWiiリモコンHackがネット上で話題になったのが、今の電子工作の再ブームであったり、Maker Faireだったりの源流だったのではないかとも思う。私自身、電子工作に手をつけたのはこれがきっかけだった。

Wiiリモコンは手元にたくさん数があるが、Arduinoとこれを、PCを経由させずに直接繋ぐ方法を調べてみた。方法論としては2つある。ひとつは、Sparkfunで売られている「Bluetooth Mate Gold」などのBTモジュールを使う方法、もうひとつは、同じくSparkfunで売られているUSBホストシールドにBTドングルをつけて行う方法である。前者はどういうわけかうまくいかなかったので、後者を選択する。

BTのハードウェア周りについては、ネットで探したこのページとこのページを参考にすることとした。どうやらCircuit@Homeというサイトで取り扱っているUSBホストシールドを動かすライブラリはSparkfunのUSBホストシールドと互換がないようなので、Sparkfunのシールドを改造する必要があるらしい。だいぶ前に購入していたUSBホストシールドを引っ張り出し、先のページに記載されている方法で改造を施す。リセットボタンがユルユルで意図せずリセットがかかってしまうようだったのでこれを取り除いた。シールドにBTドングルを取り付け、ひとまずBT関係はこれで完了。

サーボ関係は、USBホストシールドでデジタルの7～13ピンが使われてしまうということなので、PWMに対応した5、6番ピンにサーボを繋ぐ。Arduinoに変えたことでサーボの原点設定が変わるらしいので、サーボの可変抵抗をいじって原点調整をする。ハードウェア関係は以上で終了である。

続いてプログラム関係。先のUSBホストシールド用のライブラリは、Arduinoのバージョン1.0以降に対応していないらしいので、Arduinoのバージョンを下げて（私は0022を使った）コーディングすることとした。先のUSBホストシールド用のライブラリと、Wiiリモコン用のライブラリをArduinoのlibrary以下に配置する。サンプルコードはこれを参考にするが、キー入力などの変数名についてはヘッダファイルを参照しながら検討した。

簡単な動作プログラム自体はすぐにできたのだが、一番苦戦したのはやはりサーボの挙動に関する部分のコードである。通常のラジコンカーは、モーターで車輪の回転を制御しつつ、サーボで車輪の向きを制御するのだが、今回のロボットは左右の車輪の回転数違いで向きを制御するものである。要は内側と外側の車輪の回転数の違いで内輪差を作って方向転換をするのだが、これを固定値で決められれば簡単なのだが、アクセルの押し加減と連動して変化させなければならないのでちょっと面倒くさい。結果的には思うような制御ができるところまではいったが、果たしてこれで正解かどうかはまだわからない。加減速の具合も、単なる線形ではなく、サインカーブに準じるようにするなどした。などなどひっくるめて、WiiリモコンでArduinoのサーボを制御するプログラムを書いた。

実装してしばらくデバッグしてみた。BTの接続が時々切れて制御不能になるときがあるが、それ以外は安定した挙動を見せている。接続切れに対する対応はコード部分で対応できるかも知れない。おまけの機能として、iPhoneを固定するパーツを3Dプリンタで出力してみた。Airplayでテレビ画面にカメラ映像を映し出すことで、ロボット目線の映像を大画面で見ることができる。なんだかんだでAirplayは便利だし、応用の範囲も広いのではないかと思う。

自走型のロボットは、サーボやモーターなどの駆動部と、外部環境を認識するセンサやリモコンからの制御を受信するセンサ／通信部、これらを制御するマイコン部との3つに区分される。今回これを作ってみて思ったのは、一番手に入りにくい部品はセンサやサーボではなく、シャーシ部分のパーツであったということである。デジタルが全く関係のないところで大きなハードルがある。今回もBoe Botを使った理由のひとつに、手っ取り早くシャーシを手に入れることができるからというものがあった。ロボット研究では300[mm]角サイズのロボットを使いたいので、上物をどれくらいの大きさにするかにもよるが、シャーシの大型化とサーボの高トルク化は今後の課題だ。

MakerBot Thing-o-Matic 組み立てメモ

MakerBotのThing-o-Maticを2011年9月に購入したのだが、その後なにかと時間と余裕がなくて、組み立ての途中で放置してしまっていたのをあわてて組み上げることにした。ということで、今回はThing-o-Maticについての簡単なレポート（備忘録）を掲載してみたい。今回は組み上がりまでのレポートである。

まず購入手続きについて。本家サイトからクレジットカード決済で購入。手元に届くまで約一ヶ月と聞いていたが、実際にはそこまで時間はかからなかった。購入時に特に意識しなかったが、今回購入したのは「MK6」のものだった。これを書いている時点で「MK7」が出ているので、これから購入する際は自分が購入しようとするバージョンがいくつのものかを確認した方がいい。バージョンによって出ている情報が異なる場合がある。ちなみにABS樹脂フィラメントも同時に購入しておいた方がいいだろう。

段ボール箱にすべての部品が梱包されて届く。思っていた以上に大きな箱で届く。電子部品関係はある程度のまとまりで小袋に分けられているが、ネジとベニヤ、アクリルなどはすべてまとめられている。特にネジは数種類の長さの物を使用するのだが、それらがひとつの袋に入っているため、作業中により分ける必要があって面倒だ。ベニヤ部品の中に、ネジの長さと太さに関するイラスト付きの一覧が印刷されたものがあるのだが、私はその存在を組み立て工程の最後の最後まで気がつかなかったので、作業中は非常に不便を強いられた。部品の欠品はなかったが、ナットの数については余分を見込んではいないらしく、私の場合は最後の底面パーツの組み上げに必要なナットが足りなくなってしまったので、構造上必要のない箇所のパーツを外してそこに回す必要があった。パーツが梱包されている場所がわかりづらかったのは熱電対で、白いパラフィン紙に包まれているのだが、これは本家サイトにも注意書きがあったものの見つけづらいものであった。

組み立てに関しては、基本的には本家サイトに掲載されている方法をたどればよい。バージョンの違いで途中分岐するので要注意だ。基本的にはひたすらボルトを回す作業が待っている。レンチは親切にも各種サイズが同梱されているので購入する必要はない。レーザーカットされたベニヤの断面は黒く煤けており、作業中に手が真っ黒になる。また、可動部分のシャフトが潤滑油でヌルヌルで、これもまた手が汚れる。

組み立てで困った点はあまりなかったが、強いていえば、コンベヤに2本の軸を通してこれを台に固定する箇所の長さがジャストサイズで作られているのでギッチギチなこと、本体底面部に格納されるマザーボード部分の配線がごちゃごちゃっとして収納しづらいこと、くらいか。マザーボードに対して、１本のリボンケーブルを適当な長さに切って配線する箇所については、あまり余裕のある長さではないので長さを確かめながら切る必要があるだろう。配線は手順書にあるが、全体を一覧できる資料としてはこの図が便利であった。所要時間は合計で30時間もあれば十分ではないだろうか。本家以外に参考にしたサイトはこちら。

すべてが組み上がってからの作業がまたひと山。モーターの電圧調整は面倒だが手引きにあるとおり実施したほうがいいだろう。テスターは必須だ。Pythonをインストールしたり、ToMで実際にモデルを出力するためのソフトウェアであるReplicatorGを入れたり、マザーボードのファームウェアをアップデートするなどといった作業を機械的にこなす。ちょっと手数が多いので面倒だが、我慢してやろう。ReplicatorGをインストールし、USBでToMに接続すればいよいよ動作目前である。

WIZDOM レクチャーシリーズ - vol.2

WIZDOMのレクチャーシリーズで講演したので、その内容についてここでも簡単にまとめておく。

今回は「知識ゼロからのArduino」と謳っているが、内容のほとんどはEagleの使い方とfusion PCBでの発注方法について説明するものであった。本当であれば前回の（1）と一緒に説明する内容だったのだが、はんだごてでの作業に思いの外時間がかかったために、内容を2分割することになったわけだ。

さて今回の目的は、前回のレクチャーで作成した環境計測用センサ（温度と照度のみ）を、今度はEagleで回路図を作成してfusion PCBに発注し（て、よりはんだ付け作業を簡便化し）ようというものだ。したがって、前回作成した手はんだ基板の回路を見直すところからはじめた。

慣れないうちはいきなりEagleで回路を設計するのではなく、電気的にどことどこが等価なのかを確認しながら、まずはフリーハンドで回路図を書いてみることが必要だと思っている。その上で、Eagle上にその回路を書き写し、必要な寸法に収まるようにレイアウトを考えてゆくのが、まぁオーソドックスな手順なのではないか。

Eagleはその使い方に関する文献（文字通りの活字媒体）が無いので、こんなごくごく簡単な内容のレクチャーでも、そのハードルを下げるのに十分役立つのではないかと思われる。とにかく、ごくごく簡単な回路でいいので一度Eagleで書いてみて、基本的な操作を身につければその先はすぐに拓けることだろう。

Eagleは基本的に英語のインターフェースなのと、微妙な操作性とから、初心者にはなかなか取っつきづらいソフトウェアだと思う。そういった意味で、Adobeのイラストレータなどはショートカットも充実していてかなり使いやすい部類だと思う。イラレの操作性を期待してEagleをいじるとかなり凹むことになるだろう。

それでもひとたび手順さえ理解してしまえば、オペレーション自体のハードルはそんなに高くはなかったことにすぐ気がつくことだろう。問題は、さまざまある部品ライブラリの中から自分に必要なものを見つけられるかということと、回路設計そのものへの理解が足りているかということのほうが、より重要な問題であることに気づくはずだ（これはイラレでいえば、オペレーションへの習熟よりも作家性の方が最終的には重要ということと同じ）。作家性はオペレーションの習熟とともに育つとするならば、とにかく最初の一歩を踏み出すだめの今回のようなレクチャーは、それなりに意義があると言えるだろう。

「物語」と「論文」

ここのところ卒論修論の原稿をチェックする機会が多かったのだが、それらの面倒を見ている最中にふと気がつくことがあったので、備忘録がてらちょっと書いてみようと思う。テーマは、「物語」と「論文」の構造的な違いについて、である。

言うまでもなく「物語」と「論文」とは異なる性質のものであるが、これは単に内容の違いだけではなく、その構造自体に決定的な違いをもっており、その構造的な違いこそが「物語」と「論文」とを分ける根拠となっている。そして多くの学生がその構造的な違いに気がつかず、「論文」を書いているつもりで「物語」を書いてしまうという罠に陥っている。そこでこの文章では、この構造的違いについてまず明らかにした上で、陥りがちな罠を回避するための手立てを示してみたいと思う。

「物語」の代表として、よく知られている「桃太郎」の内容を題材に取ってみたいと思う。言うまでもなく「桃太郎」は、どんぶらこと揺られてきた桃から生まれた赤ん坊が、3匹の供を従えて鬼ヶ島に向かい、見事鬼を退治して帰還するという「物語」である。この物語において、文章は最初から最後までを貫通する一本の時間軸上で記述されるだけでなく、ひとつの出来事の後にさらなる出来事が連鎖的に繋がり、それらひとつひとつのドラマティックな内容が読者の手に汗を握らせ、先の読めないような展開に興奮したり感動を呼ぶのである（大げさ）。かなり端折っていえば、この離散的かつ直線的な連続性こそが「物語」の主たる構造といってよいだろう※1。

ではこの「桃太郎」を、「物語」としてではなく「論文」として記述しようとするとどうなるか考えてみたい。まず最初に、「この物語は、桃から生まれた少年が3匹の供を従え、鬼ヶ島に住む鬼を退治する物語である」と記述することからはじめなければならないだろう。なんだネタバレではないか、と思うかも知れないが、論文の発端はこのようにシンプルな記述でその全貌が明かされる必要がある。最後の最後まで読んでみなければ結論がわからないような論文は、これは「論文」ではなく、ハラハラドキドキの「物語」に他ならない。他にも、おじいさんとおばあさんが山や川に行くくだりについては、「おじいさんとおばあさんはそれぞれ家事を分担しており、具体的におじいさんは～おばあさんは～」と書くべきであろう。また、3匹の供を従えるくだりについては、これらを記述する前に「一人での鬼退治は心許ないので、桃太郎は旅を共にする仲間が（少なくとも3人は）必要だと考えた」とでもいうような一文を設ける必要があるだろう。犬、猿、雉が物語の展開上に一直線に順を追って登場するのではなく、「結果的に犬、猿、雉の3匹を従えることとなったのだが、その経緯は以下の通りである」とでもいうように、この先の展開を先に前倒して示してしまうのが「論文」の構造といってよいだろう。

以上より私の主張をまとめると、「物語」の構造は①その先の展開を意図的に隠す演出をおこない、②文章の流れの上に一次元的（リニア）に進行するものである。一方で、「論文」の構造はこれと対照的に、①先の展開を事前に要約して示し、②文章の流れの上に並列的（パラレル）にこれらを並べて進行させるものであるといえる。モノに喩えると、「物語」はナイフのように一直線であり、「論文」はフォークのようにある分岐から先別れするものだと言えるだろう。

このことに気がつかず、延々と一直線に「物語」を語る論文が多い。分岐点に至っても、それが初読の者にとって分岐点であることに気づかせられない書き方をしている。特に卒論ではじめて論文を書く学生ならば、このことに気がつかないまま書かれることが往々にしてあるものだ。これは論文とはどのようなものかという教育がなされないことに問題の原因があると思うのだが、その責任はそれを教える立場の我々にある。

ではこの問題を解決するためにどのような手立てが考えられるだろうか。言うまでもなく、ストーリーをダイアグラムとして表現することが第一の手立てとなるだろう。

例えば、桃太郎の内容（簡単のため一部省略）を、「物語」としてダイアグラムに表現したものは次の図の通りとなる。

（作図中）

ここでおじいさんとおばあさんの登場から鬼ヶ島から帰還するまでの話は一直線に繋がって表現される。桃太郎の物語の中には特に目立った伏線もないため、複雑な構造にはならない。複雑な構造ではないからこそ、幼少の子どもたちでも素直に楽しめる物語になっている。

では今度は、これを「論文」として表現する場合のダイアグラムを次の図に示す。

（作図中）

最初に物語の全貌を概要として示している。図中のアイコンが小さいのは、そのディテールや内容を必要最小限に削ってコンパクトにしたためである。これらは実際の本文中に詳細に述べればよい。次に背景となる部分だが、桃太郎の出自と鬼退治への動機を述べる必要がある。なぜ桃太郎は鬼ヶ島へ向かうことになったのか、その動機が述べられた後に、具体的にどうやって鬼退治をするのかという方法論が述べられねばならない。そこで先にも述べたように、単身の鬼征伐では心許ない、あるいは行きがかり上の必然として、3匹の供と連れ立つことになるのだが、先にこの事実を述べた後に、それぞれとの出会いについての詳細を述べることになる。つまり、3匹を供とした事実について述べる部分がフォークの付け根の部分となり、フォークの個々の先端はそれぞれの供との出会いに関する具体的な内容を述べる部分となる。このように、話が並列化する手前の分岐点では、読者が迷子にならないように分岐であることを明らかにし、個々の分岐について述べた後はそれらが再びひとつの話に合流するような記述も加えなければならない。桃太郎でいえば、「こうして桃太郎は3匹の供を連れ、鬼ヶ島に向けて船をこぎ出したのでした」とでもいうように。

最後に、桃太郎はみごと鬼を退治しておじいさんとおばあさんの元に帰還するわけだが、最後にまとめとしてきちんと論文全体の要旨を記述しなければならない。通常、背景部分についてはまとめでは言及しないので、具体的にどういう方法で目的を達したのか、そこで得られた考察は何であったかについて述べる。桃太郎でいえば、3匹の供と協力することで鬼を退治したということが述べられることだけでなく、金銀珊瑚といった宝を持ち帰ったことについても言及する。桃太郎の物語には、その後の桃太郎の活躍などについては触れられていないが、論文では本来、その後どのように研究が発展できるかについて述べる箇所がある。仮に桃太郎の物語を拡張するとして、桃太郎が持ち帰った金銀財宝で、鬼によって廃れた都の復旧財源とした、などとするのがよいのではないか。

（作図中）

さて、桃太郎を例にとって「物語」と「論文」との違いについて述べてみたが、「論文」にあって「物語」にないものは、シナリオの分岐点となる箇所で読者を路頭に迷わせないための「道しるべ」に他ならない。この先のシナリオがどのように分岐し、それらの分岐が再びどこでひとつに合流するのか、これを示すだけで読者の理解はかなり改善される。論文は難しいことを難しく書いたものではなくて、難しいことを誰もが理解できるように書き改められたものでなければならない。そのためには、話の展開を誰よりもよく知っている筆者自身が、その道しるべを読者に対してきちんと示してあげなければならないのである。

※1：もちろん重層的な「物語」も存在するが、ここでは簡単のため、ごくシンプルなおはなしを想定してもらいたい

*

ちなみに、論文の書き方についてのメモを研究論文をシステマティックに書く方法にまとめたので、そちらも合わせて参照してみて欲しい。