研究室開設のおしらせ

研究室、はじめました。

https://blog.entalab.org/

ドメイン変更のお知らせ

DynがDynamic DNSサービスを全有料化するという話に伴って、今更ながら独自ドメインを取得することにしました。

entasan.org

よろしくお願いします。

シチュエーション・インフォメーション・エモーション

最近つとめて頭に入れておこうと思っているのが、この3つの「ション」である。

元はといえば、ネットで見つけた記事に端を発する。その記事では「シチュエーション」を「情況」と訳し、確かSNSなどに上がってくるのはインフォメーションではなくてシチュエーションのほうだよね、みたいな内容だったと思う。インフォメーション（情報）を共有するんじゃなくて、シチュエーション（情況・場）を共有する風潮にあるんじゃないか、みたいな話だったと思う。その話を読んだときにほほうなるほどなと思ったことは確かだ。その上、もうちょっと自分なりに話を広げてみたいなと思うようなところもあった。それで「エモーション」を追加してみたらどうかという話になるわけである。

そもそも、シチュエーション（情況）とインフォメーション（情報）という2つのくくりは、それが「ふたつ」というだけでなにか物足りないと感じさせる。直感的には3つくらいのくくりにした方がよさそうだし、理屈っぽくいえば、シチュエーションとインフォメーションとの違いは情報の抽象度のようなものの高さに他なるまいと思ったことから、やはりこれも上か下かというよりも、上中下の三段にした方が収まりがよいだろう。

また、「～ション」という英語の響き、あるいは「情～」という日本語の語呂の良さがここにはある。情報の抽象度を3段階として、しかも「～ション」や「情～」となる良さそうな言葉はないかと考え始めたわけだ。こういうときは大辞林か類語新辞典をひくに限るのだが、答えは案外すぐに見つかった。

そもそも、「情～」ではじまることばで情報の抽象度が低いもの、つまり、人間の大脳辺縁系あたりにダイレクトに作用するようなものといえば、「情動」とか「情緒」しか思いつかない。これは訳すまでもなく「エモーション」である。図ったかのように実に語呂のよい組み合わせとなった。意味も含めて整理すると、以下のようになるだろう。

• シチュエーション：情況、場。ようす。その場の現象そのものを指すため、きわめて客観性が高く、主観的な要因は廃されるレベル。有象無象。
• インフォメーション：情報。しらせ。情況を何らかの主観によって「意味」へと昇華させたもの。意味は観測するものによって異なり、理性で処理される。
• エモーション：情動、情緒。（心の）うごき。より人間の生物としての本能に近いところで処理されるもので、生理的な作用をもたらすレベル。

センシングによって観測しているものは、温度や湿度、照度などであるから、これらはせいぜいシチュエーション（情況）でしかない。現象そのものの記録であり、はっきり言って人間のアタマでは処理しきれない。処理しきれないというか、処理する以前のもののことである。ビッグなデータそのものである。したがって、これを人間のアタマで理解できるものにする必要があるわけで、その方法論としては、単純には統計解析であり、今風にいえばマイニングなりの方法が求められる。この段階ではせいぜい「こういう傾向がありますよ」とか「～と～の関係はこうですよ」とか、もっと単純には「平均気温が○度ですよ」といったことでしかない。ある主観が持つ「知りたいこと」に対応する答えを、シチュエーションから掬い上げたのがこの段階である。

ここから先は、これをもうちょっと人間の深い部分、つまり本能とか無意識と呼ばれるようなところで感応できるような、より直接的に人間に訴えかけるレベルで作用するもののことになる。アタマで考えて「そうした方がいいと思う」というのではなく、もっと直感的に「なぜだかそうしたくなる（ということさえ気づかないレベルでそうしたくなる）」というところの話となる。これがエモーションだ。

シチュエーションとかインフォメーションの部分の話はすでに研究でもやってきているけれども、最後のエモーションの部分はなかなか手がつけられていないのが現実ではある。今のところ、快適とか不快といった感情へ訴えるといった環境工学的なアプローチでやれないかと考えているところではあるが、果たしてそれが妥当なのかどうか、確信が持てずにいる。そういった仕掛けをどうやってあざやかにつくってのけるかといったところに、まだ着想が持てないでいる。

といったことを分析の合間の手持ちぶさたに書き残しておく。

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]角サイズのロボットを使いたいので、上物をどれくらいの大きさにするかにもよるが、シャーシの大型化とサーボの高トルク化は今後の課題だ。