机上の空論主義者

-♰- 有言不実行の自身をブログ名で戒めろ -♰-

【千羽鶴】祈りなき千羽鶴折りの精神統一が導く集合体鶴形成理論【くそ記事】

こんにちは。ume-boshiです。

まだこんな未熟で半人前なヤツがいたのかと驚かれるでしょうが、24歳になった今年、人生で初めて千羽鶴を折り終えることができました。
本来、日本人ならば中学卒業時点で1000枚は達成し、社会人に至るまでに1万枚は軽く超えているという話を多くの友達から聞かされてきました。

僕は帰国子女で日本文化とは疎遠な時期があったため、そのルールを知らずに社会人を迎えてしまいました。未経験者の僕は、本来ならば成人式に参加してはならなかったようで、トム・ブラウンの布川から、「ダメーっ!」と突っ込みを食らったとしても反撃する余地がないのです。

そこで新社会人になったことをキッカケに、「千羽鶴すら折れない自分は、社会の荒波に耐える忍耐力など持ち合わせない。これでは社会人としては地を這うナメクジになってしまう。。。!」と思い、いてもたってもいられず千羽鶴の作成に取り組み始めました。


千羽鶴を折る途中過程

この動画だけで、いかに僕が人生の苦難から逃避してきたかが伝わってしまうのでしょう。24歳にてこの不器用さ。醜態を晒すようですが、自分への戒めとしてこのブログに残す決意をしました。

youtu.be
※ 50枚分30倍でお届けしています。途中から撮影しているので、50枚あたり1時間半ほどかかることが伝わるかと思います。

とはいえ素人ながらも、1枚1枚の鶴を折るたびに自身のネガティブな感情が徐々に昇華されていき、精神統一できる境地に一時的に至ることもできました。
なるほど、こうして人々は悟りを開いていくのか。そう気づいた瞬間でした。


完成品

では、拙い完成品をお見せしましょう。

もちろんですが、折り鶴は厳密にカウントしております。警察の特殊部隊であるOrizuru Saba YOmi Dame Assault Team(通称 : OSYODAT)に、過不足があった鶴の数だけ指関節を削ぎ落されるのは勘弁ですからね。

1セルあたり10個 x (10x10セル) = 1000枚

流石は千羽鶴、こうして見てると達成感が込みあがるものですね。感動のあまり、あの「激落ち第23代将軍シュワット・セスキーがノーコードとNFTをメタバースでIoTすることに成功した」という吉報を聞いた時と同じだけ、涙を流してしまったことは恥ずかしいので内緒です。

ちなみに千羽鶴を折る際には、ポジティブな祈りを込めていません。見てわかる通り、過去の怠惰な自分への怒り(赤)、呪い(黒)、謝罪(潔白)を 示すために、1:3:16 の比率で配色しています。





さて、完成品の後処理は、日本の高校生が脳細胞の凝縮と知能向上をはかる儀式にのっとりたいと思います。

まずは折り鶴を袋にぎゅうぎゅう詰めにして…

赤は50枚、黒は150枚、白は800枚

まとめてベットの下に置いて寝る。

これが普段の保管方法です。我が家には千羽鶴を蔓延らせるほどの領域が無いのです。


日本のGDPが他国と比べて2.8倍も高いのは、この儀式を繰り返していたからに他なりません。調べていて驚いたのですが、この儀式によって日本人の脳稼働率は 347.1% も大幅に向上するという統計結果が、奈良人造脳形成帝国大学院大学の研究から明らかになっているようです。すごい。
これで僕も活躍できる人材に近づけるのかもしれませんね。




おわりに(まじめ)

ここまで内容の無い記事を書いたのはたぶん初めてですが、いろいろと忙しくて疲れていたので仕方がありません。おわかりの通り、以上の内容はほぼフィクションです。
そしてここからはノンフィクションで書いていきます。

真面目な制作背景

僕は昔から暇さえあれば、ルーズリーフを正方形にちぎっては鶴を折り、ちぎっては鶴を折りを繰り返していました。友達がいなかった中学時代は、授業中はいかに小さな折り鶴を折れるかチャレンジし続け、高校時代は友達がいても折り続けていました。大学時代は、講義中において最前席を陣取って、ノートを取るか、寝るか、ロボ研の運営資料を作るか、折り鶴を折っていました。研究室時代も、集中が切れたり難題にぶち当たったり病んだりしたときには、お菓子の包装紙でひたすら折り鶴を生産していました。

なのに「千羽鶴」という形で集めたことは無かったのです。

そんな日常的に折り鶴を折ってきたバックグラウンドから、千羽鶴を1人で折ることが「死ぬまでにしたい100のこと」の1項目に入ってきた次第です。この制作は12月ぐらいから始めて、今年の2月末には折り終えていました。とはいえあまりに日常的な作業だったので、アニメの一気見時やラジオ・ゲーム実況を聞きながら、特に苦しむこともなく終了してしまったのです。記事にできるネタも思いつかず放置してました。


鶴を折ることの魅力

なぜ鶴を折り続けていたかというと、思考力・集中力を高めたいという潜在的な意識があったためです。僕は体を常に動かしたり、皮膚を引っかいたり(アトピー)していないと落ち着かない性格でして、それを我慢していると思考力がダダ下がりする傾向にあります。ただ、変に体を動かしてると周りから奇妙な目で見られたり、体がボロボロになることは想像に容易いでしょう。
とはいえ学校の成績などは、話を聞いて頭で解釈しさえすれば自ずと上がっていくものですから、我慢のために思考力を無駄に使いたくはない。

そこで折り鶴が活きてくるのです。

繊細な指の動きを必要とするにもかかわらず、脳をほぼ使わなくても完成させられるのが折り鶴です。体は動かし続けて、耳と脳は話を聞く姿勢にスタンバイされる状態。最強の精神統一状態が生み出せていると僕は考えています。事実、講義中に折り鶴を折っているだけで、通っていたFラン大学で成績優秀者として表彰されてしまったほどに、高い集中力・思考力を生み出せるのです。
つまり、僕が折り鶴に心惹かれるのは、最強の勉強法として厚い信頼を抱いているからなのです。


記事中のノンフィクションなところ

そういえば軽めの帰国子女だったり、このブログに作品を掲載することは公開処刑的な意味合いがあることは事実です。あと今回の製作では、千羽鶴を何かの応援のために折ったわけでなく、祈りがこもっていないのも事実です。
配色からわかる通り、別の派生目的が存在しています。派生作品については現在ちょっとずつ進めているので、近々紹介できる日が来そうです。記事タイトルの "集合体鶴形成理論" と、某合体系お笑い芸人から推測できることとは…?

NAISTを修了しての振り返りと、NAISTでの活動の特徴考察

こんにちは。
恐ろしいことに、明日から社会人です。なんか頑張ります。

f:id:ume-boshi:20220331195609j:plain:w450
霧立ちこめしNAIST刑務所

そう、私の大学院生活ももう終了(修了)しました。2年間、奈良先端科学技術大学院大学で生活をしていたわけですが、ただ目の前のタスクを片づけていたら終わってしまったという印象です。博士前期課程の学生なんて皆同様に、ただ「忙しかった」と結論付けられるでしょうけど。ただ感想を述べるだけではつまらないので、自身のNAISTでの生活を振り返りつつ、活動の印象についてまとめていけたらと思います。




そもそもどんな大学院生活を送ったか

まず、修士2年間でどのような生活を送ったかをまとめていきます。大したことを書いていないので、時間が無い人は本章を読み飛ばして下さい ;)

修士1年 前半

M1前半は、授業・修士研究テーマ決め・学部時代の論文執筆・就職活動をする必要がありました。活動量が一番多く、肉体的に疲れたのはこの時期だと思います。

NAISTに入って最初に待ち受けているのは、当然のごとく授業です。NAISTでは英語で授業が進められ、その内容は学部時代に情報系学科の成績上位だった私にとっても難しいものでした。さらに、M1前半にすべての授業単位を取得することができ、それに挑戦した私は課題の多さに睡眠を削ることになります。特に、コロナ禍の始まりに入学したため、授業の出席点や筆記テストは1つもなく、課題の提出により成績評価されたため、その量は例年とは比べ物になりません。

学部4年の半年近くを利用して大学院受験し、研究室を変えているため研究活動を疎かにすると「苦労してNAISTまで入学した意味があったのか?」という疑問に苛まれることになります。これは大学院2年間を通して常に付きまとう問題でした。ともかく、1年目は研究テーマを確立・安定化して、同期よりも少しでも進めたいという思いがありました。そのため、研究テーマ決めや論文調査にも力を入れて、常に気を張っていなければなりません。アイデア出しが好きな私には、この時間は苦しくもなんともなかったのですが、それらに慣れていない同期は大変苦労していたことを覚えています。

上記2つの研究活動に加え、同時並行して学部時代の研究論文を3本も執筆していました。これは大学院受験の影響で卒業研究が後ろ倒しになったこと、単純に自分自身で論文を書き上げたかったこと、また、技術雑誌からの寄稿依頼という名誉なことだったために取り組みました。卒論の短縮 + 作業分担などはしていたため、死ぬことは無かったのですが、NAISTでの活動に追加して好きでやっていたことなので、忙しくても文句は言えず歯を食いしばりながら堪え抜いたことが記憶に残っています。

最後の就職活動ですが、上記のことがある中で時間を費やせなかったことは想像に難しくないでしょう。私は就活として逆求人イベントへの参加と、5社程度のインターンシップへ応募したことくらいで終了しました。幸いながら、学部時代からの成果が認められて書類選考には優位に働き、人より苦労は少なかったです。無事にソフトバンクの4週間の現地インターンに通過し、コロナで中止になり、どこのインターンシップにも参加しない人になりました。


修士1年 後半

M1後半は、修士研究と研究テーマ変更・就職活動・個人開発をしていました。個人開発が出てきたということで、少し余裕が出てきたわけですね。しかし、修士2年間を通して、最も精神的に疲弊した時期でした。

修士研究は、遠回り遠回りしながら実装を進めていました。1つひとつ自力での実装することをこだわっていたため、研究には本質的に重要ではない箇所に時間をかけて、先生に「要らぬ」と言われ、途中まで作りかけたものを幾度も手放していました。挙句、研究テーマと同じような実装をしているアプリケーションを見つけてしまい、研究テーマを1から再検討した次第です。結果、M1の研究は、力を入れて活動していたものの、無に帰したのでした。あるある。

研究テーマが無に帰して精神的に参っている中、病みイベントと名高い就職活動も進めなければなりません。私はソフトバンクの早期選考を最終面接で落とされ、6社のお祈りメールを乗り越えて、7社目でようやく内定を頂きました。書類選考にはすべて通っていたので、面接で落とされすぎて自分自身のコミュ力や経歴を疑いましたね。開発歴などに強烈な自身があったため、絶対に嘘をつかない方針を貫いていました。しかし、SPI試験を複数人で不正しながら問いたり、嘘をつきながら内定をもらう人を見ながら、何が正しいか疑い悩み病んでいました。

個人開発はFFKBであったり、webサービスも実装したり、新しい基板の設計もこの時期にしていました。なんだかんだ余裕があったと言えます。研究活動でくすぶっていた分、その他では活躍しようと意地でも働いていたのでしょうか。

ume-boshi.hatenablog.jp


修士2年 前半

M2前半は、修士研究・学会発表準備・個人開発・ブログ1か月連投チャレンジ・親知らず3本同時抜歯などをしていました。

M2前半では、研究活動が軌道に乗ってきたこともあり、そちらの被験者実験を主軸にバリバリと実装を進められました。投稿する学会と被験者実験内容が決まっただけで、ずいぶん事を運びやすくなるものです。活動しやすさから、肉体的にも精神的にも余裕がありました。実験もしていない状態で、論文執筆を無理な締め切りで応募しても、無理をすれば何とかなる。

研究は軌道に乗っていましたので、就職したらできないことをを今年度中に挑戦しようと、ブログ1か月連投チャレンジと抜歯(全身麻酔のため1週間入院)をしていました。本ブログは一応、技術ブログですので、1か月連投しようと思うと必然的に個人開発や専門知識獲得をすることになり、躍進の1か月も過ごしたとも言えます。ただ、記事連投チャレンジ中に祖母が亡くなり、不慣れなイベントが続いたりスケジュールが狂ったりと、ブログを書く意欲をここで無くしてしまいました…
ともかく、研究も個人開発も進められ、文武両道?できた期間でした。

ume-boshi.hatenablog.jp ume-boshi.hatenablog.jp ume-boshi.hatenablog.jp


修士2年 後半

M2後半は、修士研究・個人開発・次年度準備をしていました。普通に、当然のごとく忙しかったです。

国内学会後に様々なやる気を失ってダラダラ生活していたら、いつの間にか研究活動がマズい状態に突入しました。その上、次にどんな被験者実験をすれば良いかは私の研究において最大の難題であり、修論をどうまとめ上げるかを含めて検討しなければなりませんでした。その後は実験設計を短期間で行い、実験用システムの実装をほぼバグが無い状態に仕上げることに注力。さらに、被験者実験を採用したことで大量の被験者実験をし、期間も2週間以内で密にタスクをこなしました。そして取得データの分析と修論執筆、修論発表を着々と進める日々。。。いつの間にか、M2後半が終わっていました。

実験データを集めたりデータ分析を進めると同時に、忙しさを忘れて気まぐれで応募したQiita Advent Calendarの記事を書き上げるために四苦八苦しました(なぜ4記事も応募してしまったんだ…)。各ネタもないのに、自分で計画を忙しくして馬鹿の極みです。 ume-boshi.hatenablog.jp ume-boshi.hatenablog.jp

修論発表が終わってからは、すぐに内定先の手続き・引越し準備・実家の部屋を引き払い・車の売却・研究の引継ぎと、大忙しの日々を過ごしました。


つまりどんな生活だったか

振り返ってみると、他大学院進学後に遊び惚けることは困難でした。

  • M1前半は、肉体的疲労が強く、人によっては環境変化で病む人も出てくるでしょう。
  • M1後半は、精神的疲労が強く、時間的な余裕が少しだけできます。
  • M2前半は、研究テーマさえ確立されていれば、肉体・精神・時間的に余裕があります。色々ガッツリ進められるでしょう。
  • M2後半は、時間的余裕が無くなり、研究活動に肉体的・精神的にも披露する期間といえるでしょう。どれだけコツコツ進められる人でも等しく忙しいと思います。

自身の研究内容は、まとまった結果が出るまで学会発表がしづらく、どうも研究で満足できる発表成果は残せませんでした。その分、娯楽として個人開発にも力を入れたとも言えます。もし、国際学会やジャーナルへの投稿を目標として研究活動をより真面目に行うのであれば、休んでいる暇はほとんどなく、QoLも極めて低下していたでしょう。




他大学院進学の印象

これまで、個人的にNAISTでの活動を振り返り、その特徴について述べてきましたが、一個人の生活内容には需要が無いと思います(なぜ書いた)。

なのでもう少し一般的な目線で、NAISTでの活動の特徴や印象をまとめていこうと思います。

研究スケジュールについて

〇 モチベーションが高い人が多いため、常に若干焦りながら活動可能

様々な大学からの優秀近い学生がNAISTには集まってきているようで、研究活動を真面目に行っている人は当然多いです。全員が大学院受験していることからも、当たり前の態度だとわかりますね。さらに技術的に優れた人が多く、モチベーションと相まって定期的にちゃんと進捗を出してきます。私が焦って負けじと研究を進めようと思っても、隣の芝生は青く見えるようで、周りも焦って研究を加速していきます。

同期だけでなく、先輩も後輩もすごい人ばかりなので、焦りを抱き続けるのは簡単です。まともな人であれば、この環境では自然と研究成果が生まれてくるでしょう。

〇 研究時間のやりくりが容易

研究室にも依りますが、情報系ではコアタイムが無い研究室が多い印象です。私は完全に昼夜転回型の生活習慣でしたが、深夜に大学に行っても誰か居たり、深夜に大学から帰るときには大量の研究室で電気がついているのが見えます。これは、徹夜するほど忙しいのではなく、スケジュール的に自由が利く研究室が多い証拠でもあると思います。

私が個人開発やブログ1か月連投チャレンジをしたり、適当な時期に入院できたりしたので、やる気に波がある人でも長期的には上手く活動できる環境です。

〇 学内でのバイトが多くあり小遣い稼ぎ可能

学内バイトは他大学でもあるでしょうが、NAISTではその頻度が多いと思われます。というのも、よくある授業TAやRA(Research Assistant)、共同研究の補助に加えて、サマー/スプリングセミナーやインターンシップでバイト代がもらえます。これは、NAISTに入学する前の学生さんが、研究室に仮配属して雰囲気や研究対象などを知れる仕組みなのですが、長いときには1か月くらい来訪があるのです。また、オープンキャンパスや学外イベント補助などの活動でもバイト代がもらえたりします。

がっつりバイトできない環境下では、こういった小遣い稼ぎはありがたいものです。

× 授業課題の多さや就活の必要性から、研究時間が少ない

一般的に、他大学院への進学をすると授業課題については、どれだけ努力すれば単位が取れるかの基準が変わるため手抜きできない上に、院進≒上位の学歴 であることで、課題の難易度や量が増えるでしょう。就職活動では、進学後の研究テーマや成果が安定していない中で、他の研究が変わっていない学生たちと戦わなければなりません。まとまった研究成果を就職活動でアピールしづらい傾向があり、開発経験が深く豊富に無い人は就職活動で苦労すること間違いなしです。

わざわざNAISTに進学したくせに、研究活動に時間を費やしきれないのは無意味で致命的な問題です。修士卒で就職するのであれば、研究活動に満足な時間をかけられない可能性があることを必ず覚悟しましょう。

× テーマ決めが遅いと、残せる研究成果が小規模化

大学院受験して専門分野をずらすということから、新しく修論研究テーマを検討するための知識量が不足し、右往左往しがちです。私の同期は、M1のときに決めた研究内容が、修論内容に直結していたのは8人中3人だけでした。研究テーマの決定が遅れれば研究期間が短くなり、成果も小規模化します。自分で研究内容を決めない場合はもっと安定して進められますが、それはそれで面白くない。




生活の印象について

〇 娯楽が研究寄りになり、成果としても消化可能

NAISTの研究は、専門外の分野を傍から見ても面白いです。研究内容を派生して、色々試しているだけでも楽しいですし、研究チックにも変えられます。個人開発が好きな人であれば、自身の専門性と研究室の専門性を少し絡めるだけでも、自然と娯楽が研究化可能です。実際、私が趣味で作ったFFKBや群ロボットは、やる気が持続して入ればHCIやロボティクスの分野で研究化しようと思っていました。この ↓ 記事の内容も、修論研究のちょっとした派生です。

ume-boshi.hatenablog.jp

分野に依るのかもしれませんが、一応 "先端" 的な技術から派生させるので、少ない苦労で新しい研究が生まれやすいのでしょうかね。

〇 金銭感覚がバグるほどの研究費

NAISTの研究費利用の審査がザルなのか、新しい機器をバンバン購入してくれます。1台100万円近いデバイスを突然4台買ったり、45万円くらいの某ARグラスを学生1人ずつに行き渡るように大量に保持していたり、謎に光熱費がかかりまくる施設で1人が研究するためだけに毎月数十万支払ったりと、とてつもない懐の広さを目の当たりにしてきました。ちなみに、世代によっては、大学からMacBook Airが貸与されたりもしました。
今年度に限っては、研究室の環境改善費用として各研究室に200万円が支給され、空気清浄機やyogiboや昇降机などが大量導入されたりしました。

先端恐怖症になってもおかしくない。

〇 国際交流した意欲が湧く

NAISTは外国籍の留学生が多く、日本人:留学生=7:3くらいの比率でいます。単純に言語が違うだけならいいですが、多言語を扱える人がほとんどで、技術水準も高く、休みなく永久に研究を続けています。比較的、中国国籍の方が多いのですが、必ずと言っていいほど英語か日本語を話せて、そのどちらかでミーティングに参加できるほどです。その人たちが寮生活していることも相まって、日本で時々観光する以外は毎日研究室に来て活動しているのです。これは日本の大学で日本人よりも留学生の方が成果を残しうるという恐ろしい現象を生んでいる気がします。

ともかく、留学生の水準が高さに感化されて努力しなければと思うとともに、文化交流を図りたいなぁと意欲が湧いたものです。コミュ障なのであまり話せませんでしたが…

× 娯楽施設が少なく交通の便が悪く、研究と娯楽のメリハリが付けづらい

娯楽と言えば、カラオケとかボーリング場、ラウワンとかを想像するかもしれないですが、そもそもまともに外食できる場が徒歩圏内にありません。大学の学食は、自称グルメの同期からはマズいと評されており、外食先は決まって車で10分ほどのラーメン程度です。外食するためには、誰か車所持者が犠牲となって研究活動を止めて運転手になる必要があります(まじウザかった)。運転手のスケジュールと気分が合わなければ、外食の話も当然無しになります。
その結果、最終的に行き着く先は、事前にお弁当を買っておいてそれを研究室で食べるスタイルです。これでは研究と娯楽のメリハリもへったくれもありません。

個人的には、NAISTの学食で売っている幕の内弁当はおいしいのですが、舌が肥えた人には耐えられないのでしょうね。




まとめ

さて、ここまで長々と語ってきましたが、NAISTは研究組織として優れていることが伝われば幸いです。ただしその長所も、日本の就活システムと2年間という時間的制限、精神的負荷などの問題で、うまく活用しきれないことがあることも知らなければなりません。

これからNAISTや他大学院進学を検討する方は、就職活動や研究速度、自身の趣味などのどこに重点を置くかを綿密に想像しておきましょう。苦労して大学院進学したのに、何も為せない無駄な期間とならないことを願っています。



それでは。

f:id:ume-boshi:20220331195113j:plain:h450
NAISTよ、なんだかんだ楽しかったぞ。ありがとう。

「人造先生はチョークを投げるのか」システムを作った

こんにちは!

今回は、「身の回りの困りごとを楽しく解決!【PR】Works Human Intelligence Advent Calendar 2021」の19日目の記事です。このAdvent Calenderでは、「実際に身の周りに起きた困りごとを技術で「楽しく」解決した話」について募集しており、僕もアイデアを解消するいい機会だと思い予約しました。とはいっても、当初予定していた社内雑談用ツールを実装するのはやめて、もう少し面白そうなものを作ってみました。


概要

今回対象とした「身の回りに起きた困りごと」は、オンラインの勉強動画で集中力が全然持たない問題です。昨年、リモート授業onlyだった大学院生活を送りましたが、先生の目が光っていない状況だとものすごく眠たくなるんですよねぇ。集中力も持たないし。

それは既に社会人の皆さんでも、Udemyなどのオンライン学習ツールを用いている方は共感していただけるのではないでしょうか。Udemyなどでも、多少は教師の顔表情が見えたりはします。ただ突然、「ここテストに出るよ」と重要な点を述べたり、悪い学生に対して癇癪を起したりはしないので低刺激なわけですね。

ということで今回は、家にも物理的な先生を用意しよう!というアプローチで解決を図ってみたいと思います!



実装内容

①人造先生の錬成

まずは物理的な先生がいなければ話にもなりません。適当な人形があればそれでいいのですが、手短に存在しなかったので針金で人造先生を錬成しました。人生初の針金工作であり、バランスよく形状を生成することは困難を極めましたが、何重かにワイヤを張り巡らせてネジネジすることで、十分な強度でそれっぽいものが作れました。

手には綿棒を無理やりくっつけており、これが指示棒となって我々への指導をわかりやすくしてくれているわけですね。学生が効率よく学べるためのたゆまぬ工夫、素晴らしい指導者です。

f:id:ume-boshi:20211219033751j:plain:w450
私が針金人造先生だ


②教員のランダムな移動

我々学生は、教鞭のために熱意がある姿勢を持つ先生に惹かれる傾向があるはず。ということで次に、積極的に重要箇所を指すように,先生には教壇の上で移動してもらいます。

そのために、ただのラジコン的な移動体に先生を乗せ、その左右移動を制御していきます。移動速度や制御タイミングは、ある特定の値から一様乱数を用いて適当にランダムにしています。移動用ロボットは、ESP32を用いた自作基板のを利用しています。開発環境はArduino IDEです。ただ、それだけでは先生が授業をボイコットして、どこか遠くまでダッシュで逃げてしまうため、移動の限界を設けました。

f:id:ume-boshi:20211219035529p:plain
左右に移動する先生のシステム

この ↑ 写真の、オレンジで囲ったものが左右に移動するロボットであり、緑の銀色マーカに囲われた範囲のみを移動できるようになっています。

移動ロボットは、↓ 過去に紹介したものを利用しています。

ume-boshi.hatenablog.jp


左右の限界位置の検出には、ライントレーサなどにも使われるようなフォトリフレクタを用いるために、高反射性の素材が望まれます。そのために、今回は人造先生一押し!うまいチュウのイチゴ味の包装紙裏側を用いました。(我が家にはアルミホイルが無いのです)

f:id:ume-boshi:20211219041205j:plain:w450
うまいチュウおいしいです。



そして,左右に移動するだけの動画は ↓ になります。もう少し移動量が少なくてもよかったかもね。

youtu.be


③1/f ゆらぎを用いた振り向きの実装

さて、ただ左右に移動するだけの先生は、ただ説明に焦っているだけの先生でしかありません。これからはもっと生徒と向き合ってもらわなければなりません。生徒の理解度も配慮できてこそ、本当にすぐれた教師といえるでしょう。ということで、サーボを用いて先生をYaw角方向に回転させていきます。

サーボを動作させるための回路は、下図の通りです。サーボ(SG92)の定格は4.8Vなので、ESP32の駆動電圧が3.3Vと異なるため、25番ピンからPWM信号をトランジスタのベースに流して制御してあげます。

f:id:ume-boshi:20211219051837p:plain:w250
サーボ用回路

より人間らしい動きとするために、自然界に存在する1/f ゆらぎに基づくランダム性を付加しました。1/f ゆらぎの実装には、間欠カオス法というものを利用すれば簡易的にできるみたいです。これについては、↓ の記事を参考にしました。

satotoshio.net



さて、この1/f ゆらぎを間欠カオス法で求める場合、0 ~ 1の浮動小数点で導出されます。これを0 ~ 90に適応して、サーボに適用してあげただけです。そしてそのサーボをいい感じに設置してあげれば完了です。

youtu.be

一気に人間らしさが出てきましたよ。針金ならではの振動がいい味を出していますな。




完成品

youtu.be

一度、あまりの熱弁が裏目に、教壇を超えた指導に走ってしまいましたが、これも人造先生ならではの良さとはいえるのではないでしょうか。人造先生の熱弁によって新猫論の講義を真剣に聞くことができ、中生代後期白亜紀トリケラトプスも大歓喜、バジル君も驚きのあまり口をあんぐりですね。




おわりに

このシステムを今後発展させるつもりはないですが、寝ている人に叱責をしたり、肩をポンポンたたいてきたり、「○○、ここの答えは何だと思う?(威圧)」と声をかけたりするように、使用者との相互作用を増やしていくことで、より現実の授業のような感覚を各家庭に届けられるかもしれませんね。
(Works Human Intelligence様。プレゼント用にルンバが欲しいです、よろしくお願いします!)


こういう、短期で実装する系の開発記事は久しぶりに書いた気がしますが、結構気楽にネタを含められて楽しかったです。来年度、社会人になってからはこういう突発的な記事が増えるかもしれませんね。

それでは ;)




付録:プログラム

#include <ESP32Servo.h>

/*モータ制御用ピン * 8の定義省略*/
#define Photo 35
#define BACK 0
#define FRONT 1

/* pwm definition 一部省略*/
#define LEDC_CHANNEL_0 0
#define LEDC_TIMER_10_BIT 10
#define LEDC_BASE_FREQ 5000
#define uS_TO_S_FACTOR 1000000  /* Conversion factor for micro seconds to seconds */

float animParam = 0.1;
float mInterval = 1.0;
float animInterval = 1.0;
long startTime = 0;
long startMTime = 0;
float speed;
Servo humanServo;


void setup() {  
  Serial.begin(115200);
  /* speaker pwm init */
  ledcSetup(LEDC_CHANNEL_1, LEDC_BASE_FREQ, LEDC_TIMER_10_BIT);
  ledcAttachPin(BLIN2, LEDC_CHANNEL_1);
  /*その他PWMピンの定義は省略*/

  int minUs = 500;
  int maxUs = 2400;
  humanServo.setPeriodHertz(50);
  humanServo.attach(25,minUs,maxUs);
  pinMode(Photo,INPUT);

  /*初期状態はモータを止める*/
  ledcWrite(LEDC_CHANNEL_0,0);
  ledcWrite(LEDC_CHANNEL_1,0);
  ledcWrite(LEDC_CHANNEL_2,0);
  ledcWrite(LEDC_CHANNEL_3,0);

  animParam = 0.1;
  startTime = millis();
  speed = 0;
}


void loop() {
  /*だいたい1000 ms ごとに先生をサーボで回転*/
  if(millis()-startTime > 1000*animInterval){
    /*間欠カオス法による 1/f ゆらぎ*/
    if(animParam> 0.5) animParam = animParam + 2*animParam*animParam;
    else  animParam = animParam - 2*(1.0-animParam)*(1.0-animParam);
    if(animParam < 0.1 || animParam > 0.9){
      animParam = random(10, 90) / 100.0;
    }

    humanServo.write(int(90 * animParam));
    delay(10);

 animInterval = random(5, 15)/10.0//次にいつ回転させるか 
    startTime = millis();
  }

  /*だいたい1000 ms ごとに先生の移動速度を決定*/
  if(millis()-startMTime > 1000*mInterval){
    speed = random(-10, 10)/10.0;
    Serial.println(200*speed);

    // 前後どっちかのモータしか回転してません
    actMotorFB(FRONT, 200*speed, 200*speed);
    actMotorFB(BACK , 200*speed, 200*speed);
    
    mInterval = random(5, 15)/10.0;
    startMTime = millis();
  }

  /*左右の移動制限に達したときに,移動方向と反対に制御する*/
  int val = analogRead(Photo);
  if(val>3100){ 
    Serial.print(val);
    Serial.print("  ");
    Serial.println(speed);
    if(speed > 0){
      actMotorFB(FRONT, -300, -300); 
      actMotorFB(BACK , -300, -300);
    }else{
      actMotorFB(FRONT, 300, 300);
      actMotorFB(BACK , 300, 300);
    }
    delay(400);
    actMotorFB(FRONT, 0, 0);
    actMotorFB(BACK , 0, 0);
  }
}


//モータの制御用.
void actMotorFB(int ForB,int speedL,int speedR){ 
  int R1,R2,L1,L2;
  if(ForB == FRONT){
    R1=LEDC_CHANNEL_2; R2=LEDC_CHANNEL_3;  
    L1=LEDC_CHANNEL_0; L2=LEDC_CHANNEL_1;  
  }else{
    R1=LEDC_CHANNEL_6; R2=LEDC_CHANNEL_7;  
    L1=LEDC_CHANNEL_4; L2=LEDC_CHANNEL_5;  
  }

  if(speedL >= 0){
    ledcWrite(L1,speedL);
    ledcWrite(L2,0);
  }else{
    ledcWrite(L1,0);
    ledcWrite(L2,-speedL);  
  }

  if(speedR >= 0){
    ledcWrite(R1,speedR);
    ledcWrite(R2,0);
  }else{
    ledcWrite(R1,0);
    ledcWrite(R2,-speedR);    
  }
}

VR中の入力手法について調査してみた【31/31記事目】

こんにちは。ついに今回で1か月ブログ連投チャレンジの最終回ですね。

VR / AR中の入力手法はまだまだ研究段階で、「高速」に「誤入力」なく入力出来、「学習コスト」が低く使える実用段階の入力手法はほとんどありません。未だに、何もない空間に表示されたキーボードを指でタップする方法か、音声認識か、Bluetoothキーボードを使用する場合がほとんどではないでしょうか。。。

音声入力はまだ納得できますが、他の手法はスマートじゃないですよね。VR中だと、物理的なキーボードは、位置をトラッキングしていないと場所が分からなくなるので、現実的じゃありません。指でポチポチタップするのは、入力速度がバリ遅で、誤入力が半端ないので正直使い物になりません。

私は過去の作品である「FFKB」をVR空間に持ち込んでみたいと考えており、VR中の入力手法の既存研究については興味があります。そこで大雑把に調査し、まとめてみようと考えました。

ume-boshi.hatenablog.jp


概要

現在の研究として、入力手法は大きく3つに分かれており、「既存のコントローラのボタンを活かした方法」、「既存のVRコントローラのトラッキングを活かした方法」、「自身の体をインタフェースとする方法」があると私は考えます。既存のコントローラとは、HTC VIVE コントローラやPlayStationシリーズのDual Shockなどが考えられます。

1つ目はコントローラの2つのジョイスティック(タッチパッド)が利用されます。
2つ目はコントローラの位置・姿勢を取得して、タップしたり、ポインティングしたり、振ったりして入力します。
3つ目はコントローラを持たなくても入力できる方法です。例えば、自分の手の平をタップしたり、物理的なキーボードを操作するように机をタップする方法などがあります。

それでは、1つずつ研究例とともに見ていきたいと思います。


既存のコントローラのボタンを活かした方法

片手持ち VR コントローラのための日本語入力 UI の提案

f:id:ume-boshi:20210531232520p:plain
3手法が提案されている

1つのコントローラにおける、円形状のタッチパッドを活かした日本語入力方法です。タッチパッドを3*3格子の9分割にして、スマホのようにフリック入力する「Pointing and Flick法」と、9分割しにて母音はコントローラをひねることで表現する「Pointing and Rotation法」、外側の領域に時計状に子音を並べて、内側に4つの母音(い~お)を並べる「Dial and Touch法」の3つが提案されています。
2つ目はトラッキングとのハイブリッドですね。

このうち、日常的なスマホ使いと類似しているPF法が最も入力速度・精度が良かったらしいです。直感通りの結果ですね。日本人にフリック入力式が根付いている証拠でもありそうです。

JoyFlick: フリック入力に基づくゲームパッド向けかな文字入力手法

f:id:ume-boshi:20210531232529p:plain:w200
ジョイコンを活かした入力

WISS2020で発表されていた日本語入力手法です。これはNintendo Switchのプロコンにおける、ジョイスティック2つとBボタン、トリガー2つを利用しています。子音は右スティックで「あ~わ」までを選択可能で、左スティックが「あ~お」の母音を担当しています。子音を入力した後に、左のジョイスティックで母音を入力するようです。FFKBの入力方法と似ていますね。

50音キーボードと比較して同じ入力速度に到達したらしいです。50音キーボードってあんまり使わないのでイメージが付きづらいですね。


既存のVRコントローラのトラッキングを活かした方法

VR での画面占有を考慮した文字入力高速化の研究

f:id:ume-boshi:20210531232533p:plain
振るという発想が直感的で好み

インタラクション2021で発表されていた、日本入力手法に関する論文です。これは1つのHTC VIVEコントローラのタッチパッドとコントローラの姿勢情報を用いて入力を実現します。提案手法は外側に時計状に子音が配置・内側に時計状に母音(あ~おの5字)が配置されている「Dual Dial法」と、時計状に配置された子音を選択してからコントローラを上下左右に振る「Dial and Direction法」の2つがありました。

後者のDial and Direction法は見た感じ直感的な操作間だと思えましたが、入力速度・誤字の両者においてDual Dial法に劣ったらしいです。個人的には、魔法を唱えるときみたいな感じに楽しく入力できそうだと思い、お気に入りだったのですが。。。

Drum Keys

youtu.be

GoogleのDaydream Labsが提案する入力方法です。wiiリモコンのようなコントローラをドラムのスティックのように振り、キーをたたくようにして入力します。ちまちまポインタでキーを選択するよりは、ドラムのようにテンポよく体を動かして入力するほうが入力制度は上がりそうな気もしますね。

ただ、入力時の疲労感がたまりやすい問題と、空を叩くことによるフィードバックの無さは入力体験を下げる大きな原因となりそうです。


自身の体をインタフェースとする方法

VR環境におけるフリック入力形式インタフェースの開発

f:id:ume-boshi:20210531232524p:plain
コントローラなしでフリック入力可能

VR環境で、コントローラを持たずにフリック(日本語)入力する方法もあるようです。奥行きを活かして、ある一定位置よりも奥に指を持っていくと子音キーが選択でき、キーを長押しすると母音が出てスマホらしいフリック入力が実現できるらしい。ハンドトラッキングにはLeap Motionを使っているので、どのご家庭でも使える代物ですね。

被験者実験の結果によると、入力速度は上がったものの、誤入力率が爆上がりしたそうです。Hapticなフィードバックが得られないとそうなりますよね。あと、腕を上げたままにして、さらに指を立てたままにするのはかなり疲れそうです。

PinchType: Text Entry for Virtual and Augmented Reality Using Comfortable Thumb to Fingertip Pinches

youtu.be

facebookが提案する、コントローラを使用しない英語入力手法です。両手それぞれの、親指とそれ以外のある指で輪っかを作ることによって、1つずつ文字を入力します。これの面白いところは、輪っかを作る指がそれぞれ唯一のアルファベットと対応しておらず、AIによる推論で入力文字を後から推定することです。
例えば右手の親指 + 人差し指は「YUHJNM」の6つのアルファベットである可能性があります。「HAPPY」と入力したければ、「右親人」→「左親子」→「右親子」→「右親子」→「右親人」の順番で輪っかを作っていき、予測変換にHAPPYが出力されるという感じです。

これが珍しく感じるのは、英語には予測変換が存在しなかったからでしょうか。Oculus Questの開発元であるfacebookが公開していると、説得力がぜんぜん違いますね。とにかく一度は使ってみたいものです。

Decoding Surface Touch Typing from Hand-Tracking

youtu.be

これまたfacebookの入力手法ですね。1つ前の論文の半年後に公開されたものです。これは物理的なキーボードを押下するのと同じような動作で、キーボードなしで入力できます。PinchTypeと同様に、キー入力位置から予測変換する方式で、動画を見た感じでは日常使いしているキー入力に負けない入力速度を誇りそうです。

ただ動画ではOculus Quest2のハンドトラッキングを使用しておらず、Opti Trackという別の機器を用いる必要がありそうです。まあ、今までと入力感が全く変わらず、高速に入力できるのですから、全然問題なく実用化されそうですが。


おわりに

3つ目の「自身の体を利用する方法」は、Leap MotionやOculus Quest2などでハンドトラッキングが非常に身近な技術になってきたからなのでしょうか。今後、コントローラを用いる時代は廃れていくのかもしれませんね。

今回調べてみて驚いたことは、物理的な新しいコントローラを開発する研究が見当たらないことです。いちいちコントローラから自作する馬鹿はいないんでしょうか。邪道を突き進めume-boshiよ :)



それでは本記事まで、1か月間ブログ連投チャレンジにお付き合いいただきありがとうございました!死ぬまでにしたいことの1つ目を消化することが出来ました :)

// 最終日が肉体的にボロボロ過ぎたので、本記事は推敲+追記をバンバン加えていきたいと思います。。。

BaseStationの位置を4つのPhotoDiodeからキャリブレーションする方法【23/31記事目】

こんばんは。

先日のBaseStationからセンサ座標を推定する方法に引き続き、今回はBaseStationの位置・姿勢を推定する方法についてです。

ume-boshi.hatenablog.jp

ume-boshi.hatenablog.jp


前提条件

まず、BaseStationは原点にあると仮定して計算を進める。このBaseStationの座標については、センサを原点として考えたときの座標を後に算出可能である。

BaseStationからの赤外線を受光するPhotoDiodeは4個以上あり、それらの位置と距離関係は既知のものとする。例えば、正方形の拡張頂点に4つのPhotoDiodeを配置するといった感じ。そして、それぞれのセンサがある位置をp0 ~ p3と定義する。

f:id:ume-boshi:20210523213407p:plain
前提条件



この際、BaseStationの赤外線信号を読み取ることで、方向ベクトルv0 ~ v3までが分かるが、距離k0 ~ k3は未知数であり、一番初めに求めたい要素である。


計算手法

前提条件より、センサの位置がすでに分かっているので、それをr01, r02, ... , r23として6つの定数が判明している。このr01などは、それぞれ |p0-p1| のようにベクトルの差によって表される。これをもとに、r012 を展開して行くと、r01などをk0 ~ k1で表せるようになる。

f:id:ume-boshi:20210523213412p:plain
センサ間の距離(既知)を用いてk0 ~ k3の関係を暴く準備


r01 ~ r23まで6つの定数について k0 ~ k3を用いて表現することができたので、6つの方程式からk0 ~ k3を求めていく。この際、r01 ~ r23までの値と、v0 ~ v3までの値は定数として既知の情報である。
未知数の数に比べて式の数が多く、なおかつ実測値には誤差が含まれているため、解が一意に収束することはない。そのため、k0 ~ k3に適当な値を代入していき、方程式の誤差が最小になるものを探す必要がある。4重ループで0~1000くらいの値を突っ込んでもいいし、より効率的な手法を知っているならそれでもいい。Pythonのsympyライブラリにおけるnsolveという関数を用いると、考えなくても解くことができる。

※この計算では極力誤差を減らすため、v0 ~ v3の値は200点平均を取っておくことが推奨されている。

f:id:ume-boshi:20210523213418p:plain
変数に値を適当に代入していくことで、k0 ~ k3までの最適解を求める


k0 ~ k3が求まると、ようやくBaseStationから見たPの座標が計算できる。下画像のように、k02 ~ k32から求める方法では、④の計算方法と同じような感じで、P=(x, y, z)とおいて方程式を解いていく。

f:id:ume-boshi:20210523213424p:plain
最後にPのベクトルを求めて終了


そのほかに考えられる手法として、p0を原点とした座標系を考えて、P=-p0の位置にあると捉えることができる。また、p0 ~ p3までの重心を原点ととらえる場合は、 p'0=(-d/2, d/2, 0), ... というようにベクトルを表現しなおして、⑤の方程式を求める方法である。多分、-(p0 + p1)/2 がPの位置ベクトルになると思う。

f:id:ume-boshi:20210523221345p:plain
適当な値を代入する方法?

未踏IT人材の開発物が面白い【20/31記事目】

こんにちは。

皆さん「未踏IT人材発掘・育成プロジェクト」をご存じですか? 情報系で研究をしていない方は、あまり知らないかもしれませんね。
この未踏IT人材発掘・育成プロジェクトは、日本のNPO法人であるIPA情報処理推進機構)が取り仕切っている、

ITを駆使してイノベーションを創出することのできる独創的なアイディアと技術を有するとともに、これらを活用する優れた能力を持つ、突出した人材を発掘・育成することを目的

とした事業のことです。簡単に言うと、若いIT人材のやりたいことを資金補助して、好き放題やらせてあげることですかね。 これが採択された学生は、個人的にはTop conferenceに論文を出せることと同等なぐらい天才の印象があります。


というわけで、今回は過去3年分の作品を見て、気に入った開発物を個人用にまとめようと思います。

2018年度

Functagraph 3Dプリントするオブジェクトの動きを3Dプリンタ上で表現するためのソフトウェアプラグイン

https://www.ipa.go.jp/files/000073247.pdf

3Dプリンタを用いて印刷するだけでなく、印刷したものを3Dプリンタ上で動かしてしまおうというものです。印刷後にサポート材を外さず、動くものを一度で出力することができるようにソフトウェアを作成したとのこと。3Dプリンタの先端部分も自動的に変更可能になっていて、組み立てまで可能だとか。

Deep Glyph 文字形状を自動生成するWebフォント制作支援ソフトウェア

https://www.ipa.go.jp/files/000073265.pdf

日本語のフォントを新しく作る場合、英語の場合に比べて大量の文字についてデザインする必要があります。Deep Glyphを使用すると、いくつかのサンプル書体をデザインするだけで、すべての文字のベクタを生成できるようです。

私も死ぬまでに1度はフォントを自作してみたいなと思っていたのですが、これがあればすぐに実現できてしまいそうですね。


2019年度

Ambre 電気の様子が手に取るようにわかる回路学習ツールの開発

https://www.ipa.go.jp/files/000081813.pdf

電子工作コンテストのGUGENで見たことがあったので、これが未踏の開発物だったと知って驚きました。本来視覚的に見ることができない電気の特性を可視化できることは、直感的な理解に繋がるので素晴らしいです。配線を握ると抵抗が変化したり、電流量によって配線が振動するというのは発想が面白いですね。

これを使った子供たちが電子工作に発展していき、Makerが増えると楽しい世界になりそうです。

monorith 先行研究をインタラクティブに要約するシステムの開発

https://www.ipa.go.jp/files/000081770.pdf

私事ですが、論文調査することがとても苦手です。Margin Noteというpdf管理アプリを用いていても、論文の収集は自力で行わなければならず苦しい思いをしています。monorithは幅広い関心に基づいた検索に特化しているとのことで、例えば「群ロボット」について基礎知識のない0から学ぶ際でも、マインドマップ形式で全貌を表示してもらえることで、勉強効率がかなり向上しそうです。


2020年度

高速な自動立体造形を実現する手軽で安価なカット加工機の開発

https://www.ipa.go.jp/jinzai/mitou/2020/gaiyou_fj-2.html

安価で軽量な発砲スチロールカッターです。家庭に導入するにはレーザーカッターは大規模すぎるので、発泡スチロールレベルの手軽なものが手に入れられる時代に早くなって欲しいものです。スマホから撮影した画像を印刷できるようで、小学生でも使えるような手軽さにこだわりを感じます。単純に欲しいです。


LiCo シェーダライブコーディング・アーカイブシステムの作成

https://www.ipa.go.jp/files/000090538.pdf

私はライブコーディングという言葉を聞いたことしかなく、オタクがvimでプログラミングをしているのを、別のオタクが喜んで眺めることなのかと思っていました。どうやら本当はプログラミングで音楽やらをリアルタイムに演奏・表現することのようですね。オタクに変わりはなさそうですが。

この開発物はそのシェーダ(映像)バージョンの様です。音や映像でリアルタイムに変化を楽しめると言うのは、プログラミングにハマるきっかけにもなりそう。あと、映画の幾何学模様などがシェーダで作られていることを知り、普通に驚きました。身に着けてみたい技術ですね。


Kineto 時間を操作する映像型ノートの開発

https://www.ipa.go.jp/files/000090477.pdf

録画された授業映像に対してメモを残すことができるシステムです。映像時間とクラスメイトのメモ内容が関連付けられており、映像を停止・早送りしたとしても他人のメモを見ることができるようです。ニコ動の授業版みたいな感じですかね。
黒板を写す必要もなく授業に集中でき、声で発言する必要が無いため自分の意見を述べることに抵抗感がなくなり、クラスメイトの考えも良くわかるという、素晴らしいシステムです。近未来の子供は本当に楽しそうな授業が受けられそうで羨ましいものです。


おわりに

未踏IT人材開発・育成の開発物は面白いものばかりです。3年分ほぼすべての概要を見ましたが、技術レベルも高く着目点も世の中に役立つもので、多くの人が憧れる存在なことが良く理解できました。

私も同じように世の中を変えるデバイス等を作っていきたいものだと、モチベーションが上がりました。

それでは。

2つのBase Stationからセンサの座標を推定する計算方法【19/31記事目】

こんにちは。

昨日紹介した、Base Stationの赤外線信号を受信したうえで、どう計算すればセンサ座標を推定できるかについて説明していきたいと思います。

ume-boshi.hatenablog.jp


Rayの方向ベクトルについて

前回の記事で、sweepの赤外線を受光するタイミングを見ることで、xy軸方向のベクトルがわかるとお話ししました。sweepは、1フェーズの開始から 1222 ~ 6777(us)の間に受光できる赤外線平面です。また、sweepの回転速度は120π(rad/s)となっています。中心となるタイミングの4000(us)との時間差を基に、x, y方向それぞれへの角度を取得することが可能です。

f:id:ume-boshi:20210519224126p:plain
Sweepを受光した角度を取得する方法

ここで取得できた角度は、ある平面上にあるベクトルであり、このベクトルを基にx,y軸それぞれのsweepに関して法線ベクトルを求めます。そしてできた2つの法線ベクトルに直行するベクトルが、2平面が交差する直線を示します。そしてこれが求めたい方向ベクトルです。法線ベクトル同士を外積するだけで求まります。

f:id:ume-boshi:20210519224746p:plain
2つの法線ベクトルの外積が、求めたい方向ベクトルである。


2つの方向ベクトルの交点と距離について

1つのBase Stationからは、トラッキング対象までの方向ベクトルしか分からず、距離が分かりません。そのため、まだ物体の位置は計算できません。2つのBase Stationからの対象までの方向ベクトルについて、交点を求めることでようやく座標を推定できます。

ここで注意しなければならないのは、2つの方向ベクトルは厳密には交差しないことです!そのため、最も近づくと思われる距離をs, tと媒介変数としておいて、連立方程式を求める必要があります。

f:id:ume-boshi:20210519225456p:plain
2つの方向ベクトルの交点を求め、センサの座標を推定する。


おわりに

昔から線形代数が苦手で、この手の計算は先人がいなければ難しいものですね。。。
この計算式を見ると、Base Stationは絶対に2つ無いとならなさそうに見えます。ただ、これはフォトダイオードのセンサ1つで計算するための式であり、VIVE trackerのように大量のフォトダイオードを持っている場合は、1つのBase Stationでも賄えるのかもしれません。センサ同士の絶対距離が分かっていますからね。

「Base Stationの回転行列をどう求めるんだ!」という人は、今度そのうち書く記事の方を参照していただければと思います。

参考文献

https://hivetracker.github.io/files/AH18-HiveTracker.pdf

github.com

Base Stationが発する赤外線信号について【18/31記事目】

こんにちは。

最近、VIVEから新しいトラッカーが発売されましたね。研究室で購入したものを見ると、シャープな形状となり小型化したことが見て取れます。そんなVIVE trackerですが、amazonによると1つ買うだけでも17000円以上もかかるんですね。また、VIVE trackerを使用するにはBase Stationという赤外線を発するデバイスも使用する必要があります(17000円)。

【国内正規品】 HTC VIVE Tracker (3.0)

【国内正規品】 HTC VIVE Tracker (3.0)

  • 発売日: 2021/03/15
  • メディア: Video Game

【国内正規品】 HTC VIVE ベースステーション

【国内正規品】 HTC VIVE ベースステーション

  • 発売日: 2017/12/11
  • メディア: Video Game

とてもじゃないですが両方を買うのは割高ですよね。Base Stationは必須ですが、tracker側は複数個必要な場面もある上に、正直オーバースペックなので自作することで格安化できると考えられます!


私がVIVE trackerに注目している理由は、↓ この物理フリック入力キーボードをVR空間中でも応用できるようにしたいからです。

ume-boshi.hatenablog.jp

3月あたりから実装しつつ勉強もしてきたので、その知識を記事にしていこうと思います。 その中でも今回は、VIVE trackerが位置検出するため利用している、Base Stationから発される赤外線信号について説明したいと思います。


概要

VIVE trackerは、Base Stationから発される赤外線信号を受信し、その時間的なパターンから自己位置を算出しています。この方式をOutside-in方式と呼び、Base Stationのように外部から信号を発するプロジェクタを用います。トラッキング対象はプロジェクタの光をセンシングし、その情報だけでバイスのみで自己位置が算出できます。自分だけで位置がわかるので、わざわざトラッキング対象をカメラで位置推定して、無線で位置を教えてあげる必要はありません。

全然身近じゃない技術とお思いかもしれませんが、おそらくあのWiiリモコンも似たような方式を採用しています。リモコンの先端部に赤外線透過フィルタとカメラが内蔵されており、謎のバーから発信される赤外線を読んでいたわけですね。パルスが発されているかは未調査なので、Outside-in方式かは断定できませんが。。。

// Outside-in方式の対象にあたるInside-out方式では、トラッキング対象がカメラを持って外部環境を取得し、SLAMして位置を推測します。こちらのほうが皆さんにとって直感的な技術かもしれませんね。

f:id:ume-boshi:20210518021407p:plain
Outside-in方式とInside-out方式のイメージ


Base Stationが発する信号

Base Stationは現在Version.2まで発売されているはずですが、今回は比較的簡単な仕組みのVersion.1のほうを取り扱おうと思います。Base Station(v1)は2種類の信号を発します。1つはBlinkという一定時間間隔ごとの点滅で、もう1つはSweepというレイの走査です。赤外線は850nmの波長らしいです。

Blinkは信号の開始タイミングを示しており、これを時間基準としてsweepの信号が送られます。sweepはx軸とy軸の2方向に走査する信号で、異なる座標においてこのsweepの光が届くタイミングが変化します。

Base Stationの中身は ↓ のようなイメージになっています。

f:id:ume-boshi:20210518000712p:plain
BaseStation内部の赤外線LEDの配置

左上の9つの赤外線LEDでBlink信号を発し、下 / 右にある赤外線LEDがそれぞれx軸 / y軸方向に回転しながら光を発しています。下 / 右にあるLEDは直進性が高く、回転角度に合った領域にしか光が届きません。光 = 超早い(約30万km/s)ことと、 回転 = 超遅い(120π rad/s)ことで、座標によって光が届くタイミングが異なっています。

↓ の動画がイメージしやすいです。人間には波長と速度の問題で見ることができませんが、こうやって可視化されるとイメージが湧きやすいですね。 youtu.be


Base Stationが発する信号の詳細

2つのBase Stationの同期

Base Stationは2つ1組で使われることが想定されているようで、MasterとSlaveの2つのBase Stationが同期して信号を発します。Slaveが無い場合もあり得ますが、基本的にはMasterが開始の信号を 65 ~135 (us)程度で発信し、開始の 400 (us)後にSlaveが同様の時間で信号を発します。初めの2信号分は同期をとるためのもので、「どのBase Stationがこの周期を担うか」や「どの軸でsweepを行なうか」などの情報を含んでいます。2信号の同期が行なわれた後、どちらかのBase Stationのうち、xy軸どちらかのsweepが行なわれます。
つまり3つの信号が1つのフェーズで動作しています。

図示すると ↓ のような感じになります。

f:id:ume-boshi:20210518001841p:plain
2つのBase Stationが同期し、3つの信号が1フェーズで動作している


赤外線ダイオードで受光すると ↓ のような信号が取得できます。 github.com


同期信号が持つ情報

2信号の同期信号は周期ごとにHighの長さが異なっており、およそ65 ~ 135(us)の範囲で変化します。この表 ↓ がわかりやすいので引用させていただきます。

f:id:ume-boshi:20210518012026p:plain:w650
Highの長さによって示す情報が異なる

Highの時間によって8つのパターンに信号を分類できます。つまり3bit分の情報が読み取れるということです。3bitは「axis」「skip」「data」の3種類で、それぞれ「sweepの軸方向」「本周期でsweepするか」「OOTX形式のデータ1bit分」を示しています。位置計算をするうえで常に取得すべきなのは「axis」と「skip」の情報で、「data」の情報は初期設定時くらいにしか使いません。Base Station同士の位置関係を知るためには、dataを読み取りOOTX形式でdecodeする必要がありますが、それ以上に必要な情報はあまりないはずです(故障検知ぐらいかな?)。

この3bitは、Highの時間から次の式で導出できます。

f:id:ume-boshi:20210518015250p:plain:w300
3bitを求める式


おわりに

Base Stationから発される赤外線信号がどんなものかわかったので、sweepの取得タイミングを基にどのように座標を算出できるかについて明日は説明できればと考えています。数学は得意でないため、わかりやすく説明できるか不安ですが。。。

それでは。

参考文献

github.com

github.com

群ロボットの位置取得方法【10/31記事目】

こんにちは :)

群ロボットでは、集合したり隊列移動したり、分離・結合をしたりする目的を達成するために、位置情報の取得は1つの重要な要素となると考えられます。 そのため、今回は既存の群ロボットで使われている位置推定技術に、どのようなものがあるのか調査してまとめてみました。

f:id:ume-boshi:20210510221628p:plain
今回取り上げた手法一覧


分散処理にも使えそう

近接センサ

最も群ロボットらしい手法だと思います。近隣にあるユニットとの距離をセンシングして相対的な位置を取得します。使用するセンサは赤外線測距センサや、超音波測距センサ、ToFセンサなどが用いられている模様。この手法を用いる場合は相対位置しかわからないため、Kilobotという群ロボットでは距離を一定に保ちながらメッシュを構成していきます。メッシュ的に管理して、メッシュ外側にあるユニットだけが動く制限を設けることで、位置構成が複雑に変化することなく変形が可能なようです。

youtu.be

群ロボットのシミュレーションでも、この手法が採用されていることが多い気がします。
// この論文の"2.2.1. Collective Localization"の項目がアルゴリズムの参考になりそうです。(この論文によると、kilobotは初期状態として4つの位置関係がわかっているユニットがあるそうです。相対位置と呼んでよいのだろうか。)

カメラ

処理が重そうだとは思いますが、カメラを搭載している群ロボットも少なくないです。S-BOTやmROBerTOなどの位置取得方法は多分これ。ただ、論文をパッと見てもどんな処理が行われているか見当たらないので違うのかもしれません。。。少なくとも小型の群ロボットではvisual SLAMとかではなく、近くにユニットがあるか程度のことしか検出していないんじゃないかなぁ。

mROBerTOという群ロボットには大量のセンサが搭載されています。その中でも主なセンシングモジュールはカメラと近接センサだと論文中で述べられています。
論文:http://asblab.mie.utoronto.ca/sites/default/files/mROBerTO_iros2016%20final.pdf

youtu.be

S-BOTや、生物のフェロモンの仕組みを応用した群ロボットにもカメラが搭載されています。

outside-inな手法

ここ2ヶ月、VIVE trackerの位置取得方法について個人的に勉強しており、この手法を群ロボットに応用できそうだと考えていたのですが、実際に利用されていました。

VIVE trackerでも使われているoutside-inな手法では、外部からプロジェクターを用いて一定のパターンで赤外線を点滅させ、そのパターンを各ロボット側に取り付けられたPhotoDiodeで受光することで位置が取得できます。ロボット側で受光できる時間的パターンは座標によって異なるため、その時間を分析してあげることで位置を算出することが可能です。

オープンソースの群ロボットであるzooidsやその派生は、この手法を用いているようです。プロジェクタにはDLPLCR4500EVMというのを用いているらしい。
// ちなみにVIVE trackerはBaseStationがプロジェクタの役割を果たしています。

github.com

youtu.be

特殊なマット

これは我らが日本のSONYが販売するToioで使われている方式です。特殊なパターンが描かれている専用マットを、toioの裏側にある光学センサで読み取ります。マット上の絶対位置が取得でき、各ユニットごとの位置関係が容易に取得できます。

toio.io

自分で買うお金がないので、toioの紹介動画を見ながら絶対座標を取得できている理由を考えてみたのですが、正直わかりませんでした。ただ、toioから赤外線光が発されているようには見えず、マットに不可視マーカが描かれているわけでは無さそうです。その他分かるのは、真っ白な専用マットでも絶対位置を取得できているため、色のパターンだけで見ているわけではないということです。
パターンマッチングを用いると計算量が莫大になるので、O(n)ぐらいで算出できるSONYの謎技術があるんでしょうね。

GPS

広範囲に移動する群ロボットで採用されているようです。例えば、空中/水中ドローンを用いたのはGPSで位置取得しています。まさに地球における「絶対座標」が取得できるため、既存のマップデータなどと組み合わせて大規模なサービスを作り上げられそうですよね。

biomachineslab.com

群ロボットは開発のしやすさのためか小型化が進んでいますが、実用する際にはGPSで位置取得するような大型のロボットに真っ先に応用されるはずです。 なのでGPSは群ロボットの主流じゃないと侮ってはいけなさそう。


中央集中制御がメインそう

群ロボット自身がセンサを用いて位置を取得するのではなく、別のデバイス(サーバ)から位置情報を取得する仕組みの方法です。この場合、中央集中制御であろうと分散制御であろうとサーバを持つ必要があるため、中央制御のほうが合理的そうです。

ARマーカ

各ロボットの上部にARマーカを張り付け、それを天井に取り付けたカメラで読み取る手法です。室内で絶対座標を取りたいのであれば、これが一番手っ取り早く実装できそうです。上部からカメラで撮影して群ロボット以外のPCが位置を取得するため、中央集中制御が適していそうと判断しました。 サッカー系のロボコンであるロボカップでも、この手法が使われているはずです。

gigazine.net

ShapeBotsという群ロボットでは、ArUcoマーカを底面に貼り付けて、机の裏からカメラ撮影しているみたいです。おしゃれ。

youtu.be

OptiTrack

ほとんど見たことがないですが、モーショントラッキングの世界で有名なOptiTrackで位置取得する方法があります。
OptiTrackとは、トラッキングしたい対象物に赤外線を反射するマーカをいくつか取り付け、それを(超高級な)赤外線カメラで撮影して位置取得する方法です。位置取得には2台以上の専用カメラが必要になり、100万円近くは軽く超えるんじゃないでしょうか。。。専用カメラには赤外線光が(パルスで?)発されており、トラッキングしたいモノに取り付けたマーカがその光を反射します。マーカは、スニーカーとかについているような再帰性反射する素材でできています。 位置取得をするためには、事前にキャリブレーションされた複数台のカメラを用意し、対称点に向かうRayとカメラ姿勢を基に座標を算出しているようです。

mocap.jp

この方式を用いる場合、サーバが赤外線カメラの情報を用いて位置を算出するため、ロボット制御もサーバで行うような中央集中制御の採用が理にかなっていると判断しました。 もし分散制御をする場合でも近接ユニットとの通信においては、位置取得のために赤外線プロジェクタがノイズとなりかねないので赤外線通信が使えず、BluetoothWiFiによる手法に限られそうです。


Teraflop swarmという群ロボットでは、マーカの配置パターンがユニットごとに異なっているため、個体を256個まで識別できるみたいです。通信手法については書かれていないので、中央集中制御なのかは不明。。。

論文:https://onlinelibrary.wiley.com/doi/10.1002/aisy.201900031

youtu.be


おわりに

手法が多すぎて迷うかもしれませんが、個人開発で使える手法は限られています。OptiTrackを用いる場合は100万円近くするし、Toioの絶対座標の算出手法は企業秘密になっているし、室内開発でGPSを使っても誤差がひどそうで使えません(ちょっとセンサが高いし)。さらに、Outside-in方式は実装方法がネットにあまり上がっていないので、難しいでしょう。
したがって、個人開発では距離センサか、カメラでのSLAM、ARマーカを用いた手法に落ち着きそうです。

群ロボットを勉強している途中の人間なので、もし間違っていましたら気兼ねなくご指摘お願いします!

群ロボットの基礎知識や分類、通信周りを勉強したので、絵付きでまとめてみた【4/31記事目】

こんにちは。本記事は、1ヶ月間ブログ連投チャレンジの4日目の記事です。

今私の中で、群ロボット勉強計画が進行中です。群ロボットは複数のユニットが強調して作業を行えるように、ロボット同士で通信して情報共有しなけねばなりません。なので群ロボットでは通信方法が1つの肝となると私は思っています。例えば、近距離のみで通信できる方式を用いた場合、実際の「動物の群れ」的な構図を実現できそうです。それに対し、各ユニットがサーバを介して長距離でも確実に通信できる場合、文明的なツールにより誰とでも対話できる「現代社会」のような目的特化の構図も実現できそうです。

ということで今回は、既存の群ロボットがどのような通信方式を採用しているかメインに調べてみました。そのついでに、基礎的な群ロボットの知識をも勉強し、個人的な想像イメージ付きでまとめてみました。勉強を始めたばかりなので、間違っていることがあればご指摘いただけますと幸いです!

群ロボットの分類や基礎知識

ユニット同士の関係

ユニット同士の関係としては、3種類に分けられます。// 調べてもほぼ動画が出てこなかったので、古い分類法なのかもしれないです。

f:id:ume-boshi:20210504034800p:plain
latticeとchainの違いを私には判別できません。。。

  • lattice-based - 移動可能なロボットが立方体や正八面体などの格子型をしたパターンで接続し・変形する方式です。基本的に制御は、個々のユニットが並列に分散処理するらしい。
    // GUGEN2020に投稿されていた作品にこれがあった気がする。現在HPがメンテ中で探せなかった。

こんなやつ ↓

www.youtube.com

  • chain-based - ロボット同士が物理的に接続して、蛇型や木構造を持つものです。基本的に、ユニットが動作する構造はシリアルです(←1接点ずつ動く的な?理解できなかった)。空間的な汎用性が高くなり、任意の点や方向に到達しやすいらしい。
    // 普通のヘビ型ロボットなどよりはパワーで劣るらしい。

↓ みたいな群ロボットだと思っています。多分。。。

www.youtube.com

  • mobile-based - 環境を利用して移動できるユニットを持ち、複雑なchainやlatticeを形成することや、個々に離れて移動もできる。 → 仮想的な巨大ネットワークを形成できるらしい。
    // ベイマックスのmicrobotとかもこれに当たるのかなぁ。

こんなやつ ↓

youtu.be


制御場所

システムで目的を達成するためにどの個体が考えるかについては、2つの手法があります。

f:id:ume-boshi:20210504034912p:plain
中央集中制御と分散制御ではMasterの有無が異なる。

  • 中央集中制御 - 全ユニットの情報や、目的の進行具合をすべて管理するMasterが存在する方式です。数が多くなるにつれて、管理が大変になったり、距離の離れたユニットとの通信が遅延するようになるそうです。まあ、1000個単位になるとですが。重大な問題点としては、Masterが死ぬとシステム全体が死んでしまうことです。
    // 目的は達成しやすそうだけれど、群ロボットとしての意味はあまりない気がします。

  • 分散制御方式 - 個々のユニットが独立に考えて、近傍同士のユニットと相互作用しながら制御する方式です。自然と分散処理が行なえたり、個数の変化に強かったりするようです。全体の状況を常に把握することが難しかったり、人間が理解し難い制御法になったりといろいろと面倒くさそう。
    //こっちのほうがロマンのある制御法ですよね :)

環境認識用のセンサ

障害物が移動するなど、環境が変化するような場合は周囲環境を取得する必要があります。そのため、赤外線近接センサやLRF(レーザでのToF)、超音波測距センサ、ソナー、カメラなどが使われています。そのうち赤外線近接センサは、近くに壁がある場合に反応するやつです。小型で搭載しやすいため最もよく使用されているそう。これ以外を使う場合、値段と精度の兼ね合いで使用するものは変わりそうです。絶対距離を測りたい場合はLRFを使用し、精度が低いが安価な超音波測距センサも選択肢にのぼるでしょう。周囲環境で、障害位置やユニットとの関係、自身のおおまかな移動距離を取得したい場合はカメラを使います。カメラは前方を移すものもあれば、ロボットの天井部に取り付けた曲面型ミラーと組み合わせて、360度周囲を取得する手法もあります(道路のカーブミラーみたいな)。

移動方法

タイヤ型、キャタピラ型、脚使用型、ハイブリッドなものがあるようです(英訳が思いつかなかったので割と個人命名)。

f:id:ume-boshi:20210504034957p:plain
脚使用型のは見たことがありません。

  • タイヤ型 - 2つのタイヤをDCモータ/サーボモータで動かすものや、3つのモータで全方位移動できるもの、4輪駆動のものがあるそうです。タイヤ型は障害物を乗り越えることに弱い欠点があり、エネルギー効率の良さやパワーが出る利点があります。

  • キャタピラ型 - 帯型のタイヤ?を用いて、移動するロバストなもの。地形の変化について強いです。

  • 脚使用型 - 組み立てが複雑で、制御が難しい。そのため、非常にゆっくり移動することになり、着地時のインパクトも問題になります。問題児ですな。


通信手法(物理層

サイズ・コスト・環境などによっていくつかの選択肢が使われている。そのうち、主に中央集中制御と分散制御の分類で違いがあるっぽい。

手法としては近年使えるものが増え、Bluetoothwifi、stigmergy、赤外線通信やvisual communicationなどがあります。stigmergyとは、「環境に残された情報に対する反応」という意味らしく、蟻が移動時に残すフェロモンのような感じです。他にも、有線でSerial通信するものや、XBee系の通信規格を採用しているものもあります。

プロトコルについてはいまいち調べきれていないので言及できません。。。

Bluetooth(BLEを含む)

最もコスパが良い手法らしい。個体ごとに異なるIDが必要になります。BLEはBluetoothのうち低消費電力な規格で、赤外線通信などよりは長距離で通信できるため、今後広く使われそうな予感がしますね。Bluetoothでもメッシュネットワークを構築できるらしく、群ロボットにも採用できそう。

採用ロボット例

Wi-Fi

Wi-Fiは中型のロボットで、大量のデータを送信する際に使われます。放射線?に弱い。ESP32が結構安くで売っているので、今後はこの手法が広まっていきそうだと予想しています。ESP32のWi-Fiでもメッシュネットワークは構築できるんですね。知らなかった。

採用ロボット例

visual communication

異なる色のLEDによって状態やらを表現し、上部に取り付けたカメラでそれらの色を読み取ります。エコで簡単に導入できる手法ですが、太陽光や他の光源に弱い特徴があります。調べてる限りではほとんど採用されていなさそう。でも、360度周囲の映像を取得する方法は好きです。

f:id:ume-boshi:20210504035126p:plain
制御しにくそうだけどロマンを感じるのでやってみたい。

採用ロボット例

赤外線通信

私が調べている限りでは、一番多くの群ロボットで採用されているように感じました。近距離でのみ通信可能な特徴を活かし、一定距離を保ちながらメシュネットワークを構築して制御するmobile-baseの群ロボットで多く採用されています。赤外線を用いたものは、全方位に赤外線の信号を送信するものばかりです。receiverは1つしか無いものもあれば、送信機と同じ数を搭載しているものもあります。

f:id:ume-boshi:20210504035202p:plain
赤外線通信するにも種類があります。私はkilobotが好きなので載せときました。

採用ロボット例

ZigBee, XBee

Bluetoothと似た規格という印象しかないです。XBeeZigBeeは、Bluetoothよりも消費電力が抑えられるようです。まあ、最近はBLEが普通に使えるので、安く済ませたいとか、汎用性を重視しない場合はZigBeeを使えばいいんだと思います。(参考サイト

採用ロボット例

UART、CAN通信

chain-base方式の群ロボットで使われています。物理的にユニットが接続されているから、無線よりもCAN通信のほうが通信エラーが少ない特徴があるのかな?

採用ロボット例


おわりに

流石に1つの研究分野に関して、広く知識を身に着けようと思うとかなり骨が折れました。実は一番知りたかったプロトコルの部分について、どの資料でもあまり詳しく載っていなかったので、別で再度調査が必要そうです。。。


かなり参考にした文献


<追記>
S-BOTのリンクについて、怪しめのサイトに飛ぶようになっていました。確認不足があり、読者の皆様には大変ご迷惑をおかけしました。申し訳ございません。


ホコリやフラックスで汚れている基板を綺麗できるアイテムを実験調査した。

こんにちは。

最近、個人開発をさぼり気味で、思うように開発が進んでいません。next versionの基板を設計しようと、昔の基板をあさったりすることが多いのですが、どうも気になることが。

というのも、ケースに入れずに放置していた基板はホコリをかぶってしまい、目障りな感じなのです。息で吹き飛ばしたり、指でこそげ落とそうと試みたのですが、フラックスが残っているせいなのか綺麗になりませんでした。
フラックスが残っていると、ノイズ源にもなるみたいです(今回初めて知りましたが)。

一度気になりだすと落ち着かないもので、基板の掃除について実際に色々なアイテムを使用して調査することにしました。


試したアイテム

今回、基板のホコリを除去するために4つのアイテムを購入し、効果を見てみました。

f:id:ume-boshi:20210420203025p:plain
基板を絶対に綺麗にするマン

モデルクリーニングブラシ 静電気防止タイプ 74078

モデルクリーニングブラシ 静電気防止タイプ 74078

  • 発売日: 2016/12/03
  • メディア: おもちゃ&ホビー


手始めにメガネで試す

私は皮膚が弱いので、おでこの皮膚が剥がれ落ちて眼鏡に付着してすぐに汚れます。そこでホコリ取りの実力を測るために、手短なメガネでアプローチをかけてみました。

メガネにフラックスクリーナーは意味がないので対象外にしております。
// そしてブラシ処理後の写真を撮り忘れる失態…

f:id:ume-boshi:20210420203044p:plain
汚いですね

スライムでのホコリ取りは効果絶大でした。しかし、若干油を含んでいるようで、指で擦ったときのような脂が付着してしまいました。また、強めに張り付いた汚れに対してはスライムは無力でした。
ブラシではスライム以上のホコリを取れませんでした。しかし、細かい溝の汚れにはアプローチを仕掛けやすかったです。
最後にクロスでは、油汚れも完ぺきに綺麗にふき取ることが出来ました。メガネ拭きよりも上質な布なので、当然と言えば当然ですね。


本題の基板を掃除

それでは本題の基板を掃除していきます。対象となるのは、この記事で用いていた基板におけるピン密集地帯です。

ume-boshi.hatenablog.jp

掃除の手順は、「スライム」→「ブラシ」→「クロスでの乾拭き」→「フラックスクリーナー + ティッシュ」→「フラックスクリーナー + クロス」です。が、案の定、ブラシの効果が薄く撮影を忘れてしまいました。

f:id:ume-boshi:20210420203109p:plain
狭い領域に溜まった汚れを取り除ける

スライム・ブラシでのホコリ取りは、細かな屑にはほとんど効果がありませんでした。理由としては、フラックスの残液が屑をネバっとホールドし、取り除けなかったのだと考えられます。
クロスでのホコリ取りは、細かな屑も除去することができました。クロスは生地が丈夫なので、強めにこそげ取ることが可能なようです。ホコリを取るだけならこれでいいかな。

フラックスクリーナーを用いた掃除結果については次の感じです。
ティッシュでは、無謀でした。ティッシュは引っかかってゴミと化すわ、汚れは落ちないわ、指は痛いわ。。。散々な結果となりました。
クロスで拭きとった場合、かなり綺麗にフラックスを除去することができました。茶ばんだ箇所がほぼ無くなっていますね。ただ、2.54mmピッチの隙間部分(右下3ピン)を除去するのは難しいようです。また、分厚く残ったフラックス残液は、除去しきれませんでした。爪でこそげ取れ :)





より古い別の基板でも試してみたところ、↓ の写真のような結果となりました。

f:id:ume-boshi:20210420203135p:plain
フラックスを除去すると綺麗すぎて逆に不安になった。

全体的に掃除をして綺麗には出来たのですが、光が反射する場面じゃないと変化があまりわかりません。

近くで見た場合のBeforeとAfterは大きく違いますね。フラックスクリーナー後の状態が綺麗すぎて、ピンボケしているんじゃないかと何度も見返しました。生まれてこの方、フラックスクリーナーをしたことが無かったので、逆に違和感を感じる綺麗さであり、ちゃんとはんだ付けできているか不安になるレベルです。。。

まとめ

それぞれのアイテムについて、下記の様な特徴と使用場面が対応していそうです。

  • スライム:めちゃくちゃ楽にホコリ除去できる。
    基板以外でのホコリ取り。油汚れがついても目立たない箇所。
  • ブラシ:きめ細かな毛先で細かな溝でも、ささっと楽しい。
    基板以外でのホコリ取り。油汚れが気になる箇所。
  • クロス:ホコリもフラックスも一番綺麗にでき、コスパもよく応用が利く。
    万能なホコリ取り。汚れやすい消耗品なので、省スペースで汚れが少ない箇所。
  • フラックスクリーナー:フラックス絶対許さないマン。
    基板全般。フラックスがある箇所全般。

個人的なベストプラクティスは、 ホコリを取るだけならばクロスを用いて慎重にふき取ること。
フラックスを除去するならば、フラックスクリーナーとクロスでふき取ることが良いと思われます。クロスは汚れるのが勿体ないので、綿棒で代用することもできます(ほつれた繊維が付く問題有り)。

ではまた。