Archiduino Project - vol.26

建築系におけるArduino利用計画としての「Archiduino Project」。

このところずっと更新をサボっていたので、ちょっと手が空いてきたついでに現状報告。

Ardhiduinoは制御のフェーズへ移行段階にある。昨年の夏に投稿した某講演用の原稿にもあるが、「計測から学習を経て弁別」という流れはひととおり達成することができたように思う。続いてはアプリケーション（適用）のフェーズとなるわけだが、我々の目指すものとしては「行動のデザイン」「環境の制御（による快適の実現）」「省エネ（節エネ）」といったところとなる。いろいろやるのはまだまだこの先の話なので、とりあえず手始めに「赤外線LEDの疑似リモコン発光による家電の操作」的なことからやってみている。

結論から言えば、Arduinoでこれをちゃんとやろうとするのはかなり工夫が必要そうな雰囲気だ。ネットで探せば、先達の苦労もたくさん見つかる。

難しいところを思うところを挙げてゆく。
学習リモコンと同様に、発光そのものをコピーすることは難しくない。難しくないとはいえ、発光のタイミングを格納する配列の要素数が多くなると、より正確にはプログラムで生成したすべての配列のサイズが1KBを越えるとArduinoは処理を止めてしまう（＝フリーズしてしまう）ので、発光のタイミングを取得するのにもひと工夫（あらかじめ決められた数のタイミング格納用配列を用意するのではなく、検知したタイミングを逐次Serial.printする、など）がいる。

タイミングはコピーできたとしても、照明のON／OFF程度ならばよいものの、エアコンの制御とかだと最近は信号そのものが複雑になっており、配列を作成したところで動作するよりも先にフリーズしてしまいかねない。複数の信号を発光しようとすれば尚更だ。

いくつかの単純な発光パターンに限定して制御するとして、LEDを発光させてみたところで、LEDの発光角度が狭く、家電が発光に対して反応してくれないということもありうる。これに対処するには、LEDが焼き切れない程度に大きな電流を流して発光させたり、LEDの頭の丸い部分を水平に切り取って拡散光にさせるといった工夫で、かなりなんとかなるところもある。

単純なON／OFFとはいえども、制御するノードの側からすると、本当に制御されたのかされなかったのかということの判定には、照度や温度などのセンサの反応を見ながらでないとできない。発光しただけでは、100％の動作保証にはならないからだ。外気との温度差など、外部環境との相対的な比較を制御に取り入れる場合は、それらのデータを拾ってくる方法もセットで用意しないと制御がうまくいかない。

照明のON／OFFひとつにしても、ある閾値を下回ったところで照明をONにする制御をやっても、照明をONにしたことによって再度閾値を超えてしまうので、ここでOFFにしようとすればまた閾値を下回ってONになり･･･を延々と繰り返すことになる。

自宅の外部からネット経由で制御できるようにしようと考えたが、発光させるLEDの設置場所の自由度を上げようとすると、Ethernet Shieldを使うような有線よりも、Wifi Shieldなどを使って無線にした方が有利だ。とはいえ、現状、日本国内でArduinoにWifiを持たせるのは技適の話からしても難しい。この件はひとまず置いておいたとして、とりあえず手元にあるWifly Shieldを使ってやってみたものの、Ethernet Shieldほど反応性も安定性もよろしくない。はっきり言って実用性に欠けるレベルだった（自分の書いたコードが悪いのかもしれないが）。しかも悲しいことに、Wifly ShieldのFirmwareを更新したら尚さらおかしいことに。。。

といった具合になかなか難易度が高い。

ここでめげるつもりは毛頭ないが、現状のシステムがまだまだ完成されたものではないと痛感させられる。すでに世に出ている「IRKit」が宣伝文句通りに動くのだとしたら、そりゃあすごいなぁと思わずにいられない。

Archiduino Project - vol.25

建築系におけるArduino利用計画としての「Archiduino Project」。

ArchiduinoにつかうATmega328には、購入時にはブートローダが書き込まれていないので、最初にこれを焼くという手間が発生する。もちろんブートローダの焼かれたものも売ってはいるのだが、少々割高なので、手間でも自分で焼いた方がよい。

焼く方法にはいろいろあるが、この記事にある方法が一番簡単そうである。毎回配線をするのは手間なので、必要なパーツを実装した基板を用意することとした。Arduino側で動いているスケッチには「Optifix」という名前がつけられているので、この方法で焼かれたブートローダは俗にOptifix版と呼ばれているようだ。Optifixのスケッチ的には、焼く→IC換装→リセット→焼く→を繰り返せるようにできているのだが、毎回シリアルモニターを見ながらこれを確認するのも手間なので、LEDの点灯状況で外部からその状況がわかるようにしてある。

まぁそういうわけで、いつもながらFusionPCBで基板発注したものの、動作的には問題ないものの、一部配線にミスがあったりしたことと、結果的にはこれは一家に一台あれば良いモノなので、残った11枚の試作基板はご要望があればどなたかにお裾分けしたいなと。

「glif」的な何か

iPhoneマウンターの「glif」はクラウドファンディングのKickstarterを使って製品化に至ったものとしては割と知られているものであり、本家サイトから購入することも可能だし、少し割高だがAmazonで購入することも可能である。シンプルでデザインもよく、縦置き、横置きスタンドとしてだけでなく、1/4インチネジ用の金具もついているので一般的な三脚に固定することができる。$30の「glif plus」を購入すれば、キーホルダーに引っかけるためのパーツなども付属する。

そんな「glif」だが、これだけシンプルなものならば自宅の3Dプリンタで出力できるのではないか、となるのも無理はない。というわけで、できるだけオリジナルの寸法に合わせてモデルから起こして作ってみることとした。とはいえ、そのまま同じものを作るというのではさすがに能がないというか、権利的にもいろいろアレだと思うので、多少手を加えることにした。

Thingiverse : g-something

そもそも論ではあるが、この手のマウンターは基本的にiPhoneなり元のデバイスの外形寸法に合わせて作られているが、そのiPhoneユーザーのほとんどはケースを被せるなりして使っているユーザーがほとんどで、マウンターを使うたびにこれを外さなければならないという「手間」に苛まれることになる。その「手間」が実は非常に負担となっており、マウンターを「使わない」というところにまで人を追いやってしまうこともある。

私自身、このケースを使っているのだが、非常に薄くてデザインもよいのだが、いかんせん、一度装着したら外しづらいという問題のあるものである（使っている人にはよくわかると思うが）。そこでオリジナルに対する改変の「ひと手間」として、このケースを装着したときの寸法に合わせることとした。ケースとiPhone本体との間にうまれる隙間に噛ませる「歯」の部分を設け、一体性を高めるようにもした。

glifの良いところは1/4インチネジのねじ穴があるところでもあるのだが、素材に対して埋め込むというのは困難なので、出力されたものにこのパーツをねじ込むことで対応することとした。ちなみにこのパーツは家電量販店で210円で購入できる。使っている際にすっぽ抜けないように、本体側の穴は少々キツめにできている。出力されたものにやすりがけをしたら完成である。

Archiduino Project - vol.24

建築系におけるArduino利用計画としての「Archiduino Project」。

今回のテーマは、「Wi-Fi化」である。ワイヤレスでマルチホップな無線センサーネットワークをXBeeで実装するという話はすでにしてきたが、最終的にデータをサーバに飛ばすには、インターネットに接続してリモートサーバにデータを送らなければならない。これまではイーサネットシールドを使って有線でデータを送信するという方法をとっていた。

しかしながら、たとえイーサネットとはいえやはり無線化は必定と考え、Arduinoのインターネット接続をWi-Fiで実現するためのシールドを手配した。Seeed StudioでPCBを発注するときに、Seeed謹製の「WIFI Shield」なるもの（$60くらい。国内では千石電商でも購入可能）を一緒に発注してみた。このシールドで使われているWi-Fiモジュール（Microchip RN-131）は技適を通っていない製品なので、日本国内では本来的には使用できないが、あくまで性能評価のための試験利用ということで使ってみることとした。

このシールド（写真ではグレーのアクリルの下にある）を動かすには、Arduinoからシリアル通信でチップにコマンドを送るのだが、どうやらもともとSparkfunのWiFly Shieldで使われているライブラリをそのまま流用できるらしい。そりゃモジュールが一緒だから可能だろうて。

そういうわけで、ライブラリをインストールしてアクセスポイントにWPSで接続し、DHCPでアドレスを振ってもらってサーバにHTTPでアクセス（XBeeから受け取ったデータをGETメソッドでサーバに送信）というコードを書いた。

問題は送信速度ということになる。センサーネットワークでハブになるノードは常にサーバにデータを送信し続けなければならない。何十ものセンサーノードがぶら下がるハブノードは、毎秒数十ものデータを送信し続けることになるのだが、ここで送信に遅延が生じると、データの取りこぼしが発生してしまう。したがって、ハブノードの速さ（通信速さと処理速さ）を検証しておかなければならない。というわけで、今回は試験的に4ノードをぶら下げた場合で検証してみた。

結論としては、実用に耐えない遅さ、といわざるを得ない。秒間1～2回の処理しか捌けなかったという惨憺たる結果である。尤も、各センサーノードが3秒に1回という頻度でデータを送るという現状の設定もなかなかあり得ない話なので、仮に各ノードが1分間に1回程度データを送ればよいということにしてしまえば、このキャパからすれば、2～30のノードをぶら下げるのも可能かもしれない。

それにしても、今回の結果はちょっと残念な結果だったといわざるを得ない。もしかすると、私の書いたスケッチがヘボかったからトロいことになっているのかもしれない。これについては引き続き検証してゆく。ArduinoでWi-Fi化する方法は、大本営からWi-Fiシールドも出ていることなので、こっちも試してみたい。Wi-Fi化については今後も引き続き検討してゆく。

Archiduino Project - vol.23

建築系におけるArduino利用計画としての「Archiduino Project」。

これまでのセンサーモジュールはACアダプタから給電することとしていたのだが、今回紹介するのはUSBコネクタ（Type-Aのオス）からの給電で作動するバリエーションである。そもそもAC駆動としていたのは、Archiduinoにおけるセンサーモジュールが、基本的にはスケッチの更新もなく、一度設置したらあとは淡々とセンシングしてくれればいいだけのものであったことから、住宅などの建築内部で電源を得やすいACアダプタ駆動としたという経緯がある。これのデメリットとしては、ACアダプタの大きさとコストであった。これまでは、ACアダプタとArchiduinoとを3Dプリンタで出力したスケルトンで連結する設置方法をとっていたが、これは確かにちょっと不格好であった。その上、ACアダプタのケーブル長さを調整する加工が必要なので、これもまた一手間であった。このようないくつかの問題に対して解決策を模索することとなった。

その解決策のひとつが、今回のシリーズである。短辺32[mm]、長辺49[mm]という基板がベースとなっており、そこにセンサー類を載せたシールドがピンヘッダで連結されている。外装として3Dプリンタで出力したスケルトンを用意し、2枚のPCBでこれを挟む形で連結し、固定している。シールド側に載せられるセンサーは、昨年WIZDOMの活動で用意したモジュールの構成を再利用したので、加速度、照度、温度もしくは温湿度、人感センサである。XBeeによりArchiduino HUBにデータは随時転送され、サーバに記録される。

センサーモジュール側で動いているスケッチは、センサーから得た数値をXBeeでハブ側ノードに3秒おきに転送するというだけのものだが、ハブ側で使用しているXBeeモジュールの16ビットアドレスを設定するだけで、それ以外の設定は何一つすることはない（センサーモジュール側のID設定などもしなくてよい）という簡単設計である。センサーモジュール側の個体識別は、センサーモジュール側のXBee16ビットアドレスにより行うこととしてある。

本体側の基板は、USB給電としたので5[V]・500[mA]のレギュレータを廃止することができ、基板面にゆとりができた。3.3[V]レギュレータは、いままでのような基板に垂直に立つものではなく、表面実装型に変更してある。なるべく無駄な部品を省くこととしているので、スケッチの転送にはSparkfunなどが販売しているUSB to SerialのBreakout boardを使う必要がある。もっとも、これは以前と変わらない点ではある。

USBコネクタとした点については、住宅内で電源が確保しづらくなるのではないかという懸念もあるが、最近はスマートフォン用として販売されているUSB-AC変換アダプタがACアダプタよりも低価格で手に入るのと、延長コードの先にUSBコネクタがあるものも販売されているので、これを使えばよいということで解決した。ちなみに今回の基板が横幅32[mm]としたのは、もちろんXBeeモジュールなどの部品寸法の関係もあるが、無印良品のジョイントタップの幅とそろえたというのも、その理由のひとつである。

最後に、今回の基板はかなりアクロバティックな部品の使い方をしている。USBのオス端子は通常、基板に対して垂直に立てられないパーツであるが、ランドの形状と端子のピンの加工によってこれを可能にしている。本来は垂直に立てられるパーツを用いるべきなのだが、調べた限りにおいてはそのようなパーツは存在しないらしい。

99を100にするためのツールとしての3Dプリンタ

先日ある集まりで知人と3Dプリンタを肴に話す機会があった。その際、確かに3Dプリンタもだいぶ認知度が上がってきて、そこそこの大学なら高い安いはともかく、普通に配備されるようになってきたけれども、で結局3Dプリンタで何を作るのよ？という話になった。その場にいた人々は皆、なんらかのものづくりに関わっている人たちなので、この道具ができることの限界も、世間の人が過剰に喧伝している現実もおわかりの上での議論となった。みなさんいろいろ思うことがあるみたいだけれども、個人的には以下のような結論に納まった。つまり、「パーソナルファブリケーションは既製品に『+1』するためのものを作る程度にしかならない」ということだ。

世間で言われているほど産業構造を変えるようなインパクトにはならないと思うし、みんながみんなこれでどんどん世の中にあるもの以上の価値を作るなんて事はないと思う。我々が中学生の時に技術家庭科で木工や金工、あるいは家庭科で調理実習をしたからといって、多少の心得にはなったけれども、大半の人はそれが日常の行為にはなってはいない。知識や技術を社会で共有化・オープン化するということと、それが日常の行為になることとは別の議論だ。パーソナルファブリケーションは、あくまで既存の産業の補完用の手段としてあり、そこでの議論がマスプロダクトのデザインに対して反映される土壌となるような関係が既存産業との間に生まれるのではないかと思う。

ところで私は無印良品が好きなのだが、まぁなんというか、良くも悪くも「99点（満足まではちょっと足りない）」というような事が多い。そういう時に、ひと手間かけて自分好みに調整する（『+1』する）というときに3Dプリンタのような道具が役に立つのではないかと思う。ちょっと前に「デコクロ」（UNIQLOにデコレーションを施してオリジナルのデザインにすること）が世間で取り上げられることがあったが、これに近いのではないかと思う。少なくとも、そういう所からパーソナルファブリケーションになじんでゆく方法もあると思う。

ということで、「現状に対する不満を解消する（+1する）装置」としての3Dプリンタを使い、ケーブルクリッパーを作ってみた。ケーブルを束ねるだけなら輪ゴムでもいいのだが、輪ゴムだと定期的に切れてしまうのと、結束帯だと取り外しの自由がきかないし、ベルトだと束ねていないときプラプラするので、これに代わるものを考えた。モノは単純なABSのわっかだが、ケーブルをぐるぐるっと巻いたものをその穴に押し込むと、ケーブル自体の復元力で結束されるというもの。ケーブルの復元力を結束力に変換するというところが一応のキモのつもり。詳細はThingiverseにて。

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

*

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