Maker Faire Kyoto 2021お気に入り作品【3/31記事目】

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

Makerの皆さんならば、一度はMaker Faireに出展することを目指したことがあるのではないでしょうか。私もそんなことを夢見る人間の一人で、学生最後の出展機会だと思い初応募をしました。応募内容はこの記事にある物理フリックキーボードと、群ロボットを用いた作品の予定でした。まあ落選したのですが。

さらに残念なことに、昨今のCOVIT-19の蔓延防止を目的に、致し方なく現地開催が中止される事になりましたね。現地開催が中止になった代わりに、昨年度と同様にtwitterでの作品投稿イベントとなりました。

私は最近、電子工作界隈の有名人を知り、twitterで活動を追い始めたこともあり、「実際に有名人に会えるチャンスだ!」と待ち構えていましたが叶わず残念です。。。 ですが、オフラインでも作品紹介は見ていて非常に楽しいものでした!!!

今回は#MFKyotoの作品紹介の中でも、個人的に気に入った作品を感想付きでまとめたいと思っています。


お気に入り作品集

カテゴリは覚えられておりません。すみません。

ぬいぐるみをコントローラにするという観点がまず気に入っております。子供の頃は色んなものの仕組み気になり、遊びながら分解したりして構造を考えたものです。身近なものに情報機器が入っていると、物事を推測するスキルが付きそうですし、子供ならではの発想力がぐんぐん伸びそうです。

あと、磁石を用いたぬいぐるみ変形の取得方法についても、私は初めて見る応用方法で面白いと思いました。よくある変形の取得手法は、depthカメラを用いて外部から形状を取得する方法であったり、圧力センサを内蔵させる方法が多いと思います。それに対して磁石を用いた方法では、画像処理の複雑な処理をすること無く、圧力センサよりも折れて故障するなどの頻度が少なそうです。また複数のセンサ / 磁石を用いることで、複雑な形状を比較的簡単に推測できそうにも感じられます。
なにか関連研究とかがありそうなのでそのうち勉強してみたい。


ただ楽しいからモノづくりをしているという動機だけではなく、息子さんのために何とか問題を解決したいという強い意思・熱意をが作品から感じられました。また知育おもちゃを改造していたからこそ、既存製品の良さとデジタルを生かして質の高いモノをスピード開発でき、沢山の選択肢を生み出せているのだと感じました。私はエンジニアとしても研究者としても見習わなけねばなりません。

好奇心をくすぐるためにどんな特徴が大事なのかについて、ワンタップで簡単に使える入力機能と、動きや音・視覚的フィードバック機能があることが重要そうだと作品から伝わってきました。こういった項目は「仕掛け学」的にも似たところがありますし、単純に使い勝手の良い直感的なサービス作成にも応用できそうな知識に思えます。


こういうロボット、可愛くていいですよね。メカメカしさを残しつつも、生き物感もありずっと見ていられそうです。重心移動のための部分は、他のロボットではあまり見ない方式な気がします。でもそこに脳(マイコン)が載っていることで、フラフラ感も生き物のように見えてくるんですよね。 恐竜みたいでワクワクします。


ずっと見ていられる系の動画です。私は編み物をしたことがありませんが、編み物がこんな立体形状まで作れることすら初めて知りました!3D形状の自動生成系の作品はどれ革命的で面白いです。
ほどいて使う場面は正直思いつきませんでしたが、通常の3Dプリンタとは異なり、ある完成品から追加で新しい部品を取り付けるようなことも簡単にできそうで(?)、モノづくりの新たな手法になりうるように思えます。


やっぱり犬は可愛いですね。これ系の犬系ロボットで「petoi bittle」という製品もありますが、私はこの「MakerDog」のほうが滑っている姿がキュートで愛着を感じます。滑るたびに口がパカパカ開くところも素敵。
しかし、これだけコンパクトにマイコンも電池も入り切るというのはすごいですね。サーボ数は9個だけなんでしょうか。M5atomはGPIOが6本しか無いようですが内部はどうなっているでしょう。

小林竜太さんはお若いながらも、非常に大量の作品を発信しているので脱帽します。あんなに大規模な開発を、どうしてこんなスピーディーにできるのか。私も負けずに開発を頑張りたいです。// そのためにはブログを辞めなければ。。。


2年前のMaker Faire Kyotoでこの作品を見つけて、コンパクトに機能が凝縮されている様に目が離せなくなった記憶があります。精度向上はもちろん、2色印刷まで可能になっていたり、カメラからのコピー印刷までできるとは、どんどん機能が追加されているようです。何かを極めるとはこういうことなんだろうなと思いながら、浮気がちな自分を戒めるばかりです。

CNCの設計図があるなら、お金を出して購入し自作してみたい。


最近の子供はスマートスピーカが身近な存在になり、Google homeやAlexaを列記とした個人と認識することがあるらしいです。流石にスピーカーだけに対しては生き物とは感じられないなぁと、自分の想像力の限界を感じていました。
でもこの作品は生き物だと言われても、頭の形によく似ているのでつい納得してしまいそうです。

木材の内部ってどうやって削ったんでしょうか。フルカラーに光っているということは、WS2812のようなフルカラーLEDのアレイを使っているんだと思いますが、これを埋め込むのって結構大変そうだなと思います。顔氷上を作るのも大変そう。。。


アニメの食虫植物とか、宇宙植物ってこんな感じで表現されますよね。茎の部分に、曲がる構造がついているわけではないのに、頭の上下と土台の回転で茎がダイナミックに動いているような感覚を得られるのが面白いです。花弁の動きについても、加速度を調節することで感情的な表現が現れているように思えます。
ラバン動作理論とか、Flagellaの機構とかを応用してみると、より面白くて表現豊かな作品ができあがりそうで、将来がとても楽しみです。


かなり小型にトランスフォーム!するようで、ロマンを感じます。タイヤが付いているので、片付けるときの持ち運びも軽くできそうです。後輪のところにものが置けそうなことや、タイヤカバー?が将来的に足置きになったり思想で、乗り心地も悪くなさそうです。
開発段階から実用における法律的なことをしっかりと考えていそうで、しっかりされているなぁと思いました。

僕はロボコン時代にモータードライバを燃やし続けた結果、デカ目の開発をするのが嫌いになってしまいましたが、こうやって人が乗れるくらいの作品を作れることは憧れを感じます。


自分の発信作品

Maker Faireに落選していたので開発に本腰を入れずに間に合わなかったので、私は2020年度に製作した作品を投稿してみました。


おわりに

お気に入りの作品を勝手にまとめましたが、コメントの間違いや不快に思われたことがある方は気軽にお申し付けください。すぐに修正・削除させていただきます。

こうして他人の作品を見ていると、私は生き物関連の作品が好きなようです。伊達に生き物感に焦点を当てて研究してるわけじゃないですな。あと、将来的により面白く応用されそうだと思えた作品が好きみたいですね。自分が注目している点が理解できました。

来年こそは現地開催されて、それに出展できることを願います。

運営の皆さん、楽しいイベントを毎年ありがとうございます!
お疲れさまでした :)

【ESP32, ATMEGA382】swarm robotics勉強用基板を作成したよ :)【2/31記事目】

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

以前、小型擬似オムニホイールロボットと称して、5x5 cmサイズのxy方向に自由移動できるロボットを作成していました。 実はこのロボットは移動のテスト用で、最終的には「群ロボット」を目指したプロトタイプだったのです。

ume-boshi.hatenablog.jp

今回は、その「群ロボット」の勉強を目的とした基板を開発中だという話です。

目的

群ロボットを勉強するために、基礎的な機能を持ったロボットを試作することが今回の目的です。それにあたり、すでに開発済みの「IoT開発基板を拡張して実装する」こと、足回りを単体でも動かせるように「モジュール化する」こと、今後の他の開発用に「初使用のICをテストする」ことを考慮して設計しました。

仕様

必須機能

群ロボットでは「移動」でき、「近距離通信」でき、「個々を判別」できる必要があると私は考えました。そのうち移動手段については、ほとんどの既存の群ロボットでは2輪駆動が採用されておます。それに対し私のでは、小型でもxy方向自由に動ける特性を備えられたらなと考えています。
それ以外に考慮が必要そうなことは、ユニット数が増えるにつれてプログラムの書き込みが面倒になったり、各個体の状態を直感的に理解できるUIで無いと開発が困難になることですかね。

したがって要件を実現するために、下記の5つの機能を必須としたいと思います。

  • 高自由度の移動が実現できる
  • ユニット同士で近距離通信が可能
  • まとめて書き込みできる → ESP32のOTA + Arduino IDEのconsole + shell script組む
  • 視覚的に状態を理解できる
  • HW的に、基板側でもDIPスイッチで個体番号を設定可能

十分機能

十分機能としては、後々の拡張性を考慮することです。群ロボットの表現の幅を広げることと、移動精度が悪いときに対処できるようにしたいと考えています。

  • 追加実装用に、ちょっとしたアクチュエータ(サーボ2つ)を動作させられる
  • エンコーダでの移動距離読み取りに対応する

検証機能

その他に機能検証を目的に、下記のICについて回路を構築してみます。

  • BNO085の動作確認(ちょい高めの9軸センサ)
  • Type-CとCP2104でのプログラム書き込み実験
  • 外部電源からMCP73855T-Iを用いたLiPoの充電


実現方法

上記の仕様で、回路+基板を適当に作ってみました。まだ動作確認をしていないものばかりなので、正確な回路ではない可能性が高いです!
ちなみに、これから紹介する基板は、順に一番下から重ねていくイメージです。またバッテリーの保存場所を考慮し忘れたのだ。

1. GroveコネクタでI2C通信するだけで動作できる足回り

必須機能を達成するため、移動関連機能をメインとするモジュールを作成しました。他の用途にも応用できるモジュールにするために、別回路からI2Cで制御 + 別電源で動作するようにします。そのために、モジュール内にマイコンATMEGA382)を搭載させます。一応SPI通信にも対応。
またモータ動作部では、ノイズを軽減するために電源分離を行うようにします。自由度の高い移動を実現するために4つの小型モータを使用し、小型擬似オムニホイール的に移動します。その他には、2個の2相エンコーダを読み込めるようにしました。

ちょっとしたこだわりとしては、モータの取付箇所はケーブルが短くても済むように四隅にコネクタを用意したことです。

f:id:ume-boshi:20210502065601j:plain
雑回路。ATMEGA382を用いるのは初めてなので、全く動作しないかも。。。

f:id:ume-boshi:20210502075023p:plain
斜めにICを置くやつをやってみたかったんですよ。

2. 群ロボット用のモジュールを作成

これは既存のIoT開発基板の拡張として使用可能にします。IoT開発基板はESP32を搭載しているので、OTAでの書き込みができます。実装機能は、隣接する4方向に対する赤外線送受信器と、個体番号指定用DIPスイッチ、状態確認用のフルカラーLED(WS2812B)、サーボ接続用ピンです。

f:id:ume-boshi:20210502071843j:plain
横着して1つのシートにまとめようとしたら、ごちゃごちゃです。

f:id:ume-boshi:20210502075047p:plain
赤外線通信用の部品は4隅にしかありません。大丈夫かな。

3. ベース基板の更新に挑戦

既存のIoT開発基板のベース部分を用いる話をしていましたが、初使用のICについて動作確認をするために更新を試みます。今までと同様、ESP32を用いて制御します。
新バージョンのベース基板では、Type-CとCP2104による書き込み機能の内蔵化、MCP73855によるLiPoバッテリー(3.7v)の充電機能の検証、9軸センサであるBMO085の動作チェックを行います。そしてほぼ確実に動かないと予想しています。
まあ、BNO085さえ動作してくれれば、普段の移動体開発の精度向上のために役立ってくれそうです。

f:id:ume-boshi:20210502072740p:plain
頼むから動作してくれ~~~

f:id:ume-boshi:20210502075106p:plain
ギチギチ!


おわりに

一応、inventHubのリンクを貼っておきます。 inventhub.io

この基板については別のやつを開発できてから、発注しようと考えてます。部品は先に購入していたのですが、間違って京都の実家に送ってしまう失態。。。緊急事態宣言で取りに行けへんやん。。。

まだまだ実装でやり残しているところは沢山あり、今後は下記のことについて記事にしていくかと思います。

  • モータ取り付け用の3Dモデルの生成
  • 赤外線通信のテストしてない
  • shellで自動的に全ユニットへプログラムを書き込み
  • 実際に群ロボットとして動作
  • 最終目標の実装(内緒)

それではまた。

【React】SNSでの議論をマシにするサービス開発 ~第2弾(フロント編)~【1/31記事目】

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

今回は「SNS上の議論をマシにできないか」と思い、開発し始めたサービスのフロントエンド編で、 ↓ の記事の続きになります。

ume-boshi.hatenablog.jp

ume-boshi.hatenablog.jp

とはいっても私にweb系の専門知識はなく、淡々と開発していただけなので、あまり技術的な話はできなさそうです。


現在の動作イメージ

まずは最終的な動作イメージを先に載せておきます。 youtu.be

画面遷移

動画でも見られますが、画像でも説明しておきます。

まず、ホーム画面を作成しました。とはいっても、カード作成に向かうボタンしか機能はしていません。。。 そのうち #ハッシュタグ一覧 や、タグごとに記入項目を調節できるような機能も実装するかもしれません。

f:id:ume-boshi:20210501062946j:plain
ホーム画面。まだカード作成面しか実装していない

ホーム画面で「カードを作成」ボタンをクリックすると、カード生成画面に移行します。
この画面では、初期状態で{text入力 + プルダウンメニューによる入力エリア}と、「カード生成」ボタンで構成されています。入力エリアに情報をある程度入力すると、カード生成できるようになります。このときの必須入力項目は、「ハッシュタグ」「立場」「背景1」の3項目になります。

f:id:ume-boshi:20210501062726j:plain
カード作成画面の初期状態

「カード生成」を行うと、サーバ側で生成された画像が下側に表示されます。この内容を見て、入力内容に問題がないかを判断してもらい、ローカルに画像をダウンロードしてもらいます。一度カードを生成した後でも、入力内容を更新して画像出力し直すことが可能なので、自分の望むカードが比較的簡単に作れます!

f:id:ume-boshi:20210501062730j:plain
カード生成後の画面。下のボタンをクリックするとDLできる。

最終的にDLしたカードをtwitterに貼り付けて、本文中で意見を述べるという感じで使用する想定です。

f:id:ume-boshi:20210501064136j:plain
現状ではSNS上に手動でupする必要がある。


実装について

前回はGo言語を用いて、バックエンド側を実装しました。具体的にはPOSTで送信したjson形式のクエリに基づいて、画像を生成してresponseするような機能を持たせました。

今回はそのクエリを送るためのフロントエンド実装をメインに行なっています。

動作環境

詳細な実装内容は下記のようになっています。

バックエンド側
- 動作場所:Heroku
- 実装言語:go言語(1.15.5)
- 変更箇所:port番号(記事での説明は省略します)
※Herokuにdeployしただけです。

フロントエンド側
- OS:Windows10
- 実装言語:javascript
- フレームワーク:react, gatsby
- 動作場所:localhost
- 動作検証ブラウザ:Chrome, Vivaldi
※reactやgatsbyを使用していますが、その本領は全く活かせていない気がします。今度しっかり勉強したい。。。

現在、システムは下図のような構成で動作・通信しています。

f:id:ume-boshi:20210501062506p:plain
現状のシステム構成図

REST APIサーバからの画像取得について

サーバから画像を取得する方法について、私の環境で正常に動作したものを掲載します。

//★1
let query = {
    Hashtag: this.state.hashtag,
    ︙

};

fetch("https://hogehoge/createImage", {
    method: "POST",
    headers: {
//★2
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: JSON.stringify(query)  //★1
})
.then(response => {
    if (!response.ok) {
        throw new Error('Network response was not ok');
    }
//★3
    return response.blob();  // returnがないと正常に動作しない
    })
.then(myBlob => {
//★4
    const path = window.webkitURL.createObjectURL(myBlob)
    this.setState({ imageSrc: path, showFlag: true });
    console.log(myBlob);
})
.catch(error => {
    console.error('There has been a problem with your fetch operation:', error);
});
︙

render() {
    return <>
     ︙

      <img
          src={this.state.imageSrc}   {/* ★4 */}
          alt="created twitter card"
          style={{ width: 720, display: `block`, marginBottom: `1.45rem`, marginLeft: `auto`, marginRight: `auto` }}
      />
      ︙

★1:サーバに送る用のクエリを作成します。これは入力エリアの内容を、this.state.hogehogeと呼んで読み込んでいます。
そしてそれをJSON.stringify(query)することで、json形式のデータで送信できるようにしました 。


★2:通常、json形式のデータを送信する場合、"application/json"を使用するはずです。しかし"application/json"でPOST送信する場合に、謎の現象が生じます。というのも、POST requestが送られる前に、OPTION requestなるものが送信されてしまいます。
これをpreflight requestと呼ぶらしく、simple requestsではない場合に送られるそうです。つまりapplication/jsonは高度な送信手法とみなされ、追加情報を先に送ってしまうらしい。そんなもん素人が知るかよ。。。

var.blog.jp

また、CORSの問題についてもこの書き方でおよそ解決した覚えがあります。"application/json"でrequestした場合、fetchの際にブラウザでCORSエラーが生じていました。CORSエラーが生じる場合、" 'mode' : 'no-cors' "をすると表面上は解決するのですが、no-corsモードでrequestを送信している場合は"opaque"という無意味なresponseが送られてきました。

この"opaque"なcontent-typeのレスポンスは、OPTION requestが送られる際にフロントで得られるのですが、システム的には想定外のresponseでした。それに対し、"application/x-www-form-urlencoded"を用いると、OPTION requestが送信されないためCORSエラーも生じないで想定通りの動作を実現できました。

私はこのエラーが他の部分が原因であり、画像が読み込めていないと勘違いしていたため、このopaqueなresponseにはかなり悩まされました。 とにかく、CORSに関するエラーが生じた際は、適当に"no-cors"で乗り切るよりも、根本的な問題を解決することが吉な気がします。


★3:fetchで画像を受け取ってURLを生成する方法は、ネットに結構上がっているのですが、そのどれもが私の環境では想定動作をしませんでした。fetchで画像を得るにはPromise関数というJSの構文を使っているらしいのですが、その".then"の値のやり取り方法が理解できていませんでした。
Promise関数では、returnを使う場合と使わない場合があり、使う場合はその返り値を次の.thenの開始地点とできるみたいです。つまり★3の箇所では、responseの内容を一度blob形式(ファイル管理によく使われるらしい)に変換し、それを次の.thenで使用しています。

ここでreturnしなかった場合、myBlobの内容はundefineな状態になり画像をうまく読み込めません。 returnをした場合は、正常にblobが読み込めるため、ようやくcreateObjectURLができるようになります。


★4:Blob形式のデータを基に、そのデータにアクセスするためのURLを生成しています。この際"window.URL.createObjectURL"という関数も広く使用されているらしいのですが、これはchromeでは正常に動作しない場合があるそうです。

ここで生成できたURLは、this.setState({ })で保存して、それをrender()内のタグのsrcに突っ込んであげることで表示できました。


おわりに

このサービスに関する次の記事は、「セキュリティ編」になります。そのときには準完成形としては紹介するかも。投稿は来月かな?

今回の開発を通して、web系に関する非同期処理であったりhttpの通信仕様に至るまで全く理解できていないことを痛感しました。意外に日本語の情報は少なく頼りにならず、海外サイトにばかり頼っていました。正直、多くのwebエンジニアが詰まること無く進められていた(記事数が多くなかったので)と考えると、今後自分がまともにやっていけるか不安でしかないです。

まあ、今後も少しずつ、着実に勉強をしていきたいなと思いました。 では、また明日もよろしくおねがいします~

ブログ1ヶ月連投計画 【死ぬまでにしたいこと】

こんにちは。

皆さん、「死ぬまでにしたいこと100」って考えたことはありますか?
最近、私は就活などを通して、将来を見据えた時に色々とやりたいことがあるなと感じていたため、先日列挙してみたことがありました。その条件は

①基本的に、お金だけで解決できることでない
②本当にやりたいことである(ありがちなバンジーとかは嫌)
③自分の為にもなることをメインとする

この条件で考えた結果、死ぬまでにしたいことは70個ほどしか思いつきませんでした。
まあ70個全部をこなすだけでも、死ぬまでにできるかわからない状態です。ロックスターとして27歳で死んでしまうなら、あと4年も残ってない。。。

ということで、そのうちの1項目である「ブログ1ヶ月連投」を5月期間で計画しています。self advent-calendar。暇な学生のうちにしておこうと思った次第。



1ヶ月連投計画は下記のスケジュールで行おうと思っています。

f:id:ume-boshi:20210430010906j:plain
かなり厳しそうである。

本計画の条件は、下記の3つにしたいと思います。

  • 5月31日23:59時点で、合計31記事を投稿完了済み
  • 記事の順序が前後 / 変更されても問題なし
  • 記事として成り立っているならば、あとから追加・編集も可能
  • ピンチの場合、2日までの遅延はおKにしておこうか。



できればGW中に全部の記事を書き終えてしまいたいです。まあ、開発が全然間に合っていないため不可能なのですがね。

では、明日からよろしくおねがいします :)

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

こんにちは。

最近、個人開発をさぼり気味で、思うように開発が進んでいません。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は大きく違いますね。フラックスクリーナー後の状態が綺麗すぎて、ピンボケしているんじゃないかと何度も見返しました。生まれてこの方、フラックスクリーナーをしたことが無かったので、逆に違和感を感じる綺麗さであり、ちゃんとはんだ付けできているか不安になるレベルです。。。

まとめ

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

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

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

ではまた。