ディー・クルー・テクノロジーズ Blog

bookmark_borderUVをセンサで計測してみよう!⑦ ~外で実際に動作を確認してみよう ~実験編

なかなか実験の日程の調整ができず、実験日は2024/9/26(木)。夏?のぎりぎりになってしまいました。

作成したUVセンサを傘につけ実験

気象庁の計測値でみると、こんな感じです。

12時から20分ほど、会社近くの日産スタジアムに行くまでの見晴らしがよいところで実験しました。

ただ当日は晴れではあったのですが、太陽の周辺に雲がありまた風もあったのでなかなか同環境での実験ができませんでした。秋晴れ! という日にも実験してみたいですね。

気象庁での紫外線情報をリファレンスにオフセットをかける予定でしたが、実際に外にでて試しに測定してみたところセンサ値の紫外線情報にかなり差があり、今回はオフセットなしにして紫外線対策グッズでどうセンサ値が変わるかを確認したいと思います。

やっぱりリファレンスになるデバイスほしいですねー。

試した日傘(私物)はこの2つ

同環境での実験が難しかったので、試したのは2種の日傘だけになってしまいました。

①裏地が黒の日傘

②麻生地の日傘

麻生地のほうはデザインが気に入っておりましてかれこれ3年以上は使用しています。なので紫外線対策という面では効果が薄くなっている自覚はしています。。。デザインが好きなので買い替える予定はありませんが(^^)

では実験結果です。

実験結果

①裏地が黒で99.9%カットと保証がされていた日傘UVインデックス値の結果

②麻生地の日傘のUVインデックス値の結果

日傘(内)は、日傘(外)のUVインデックス値より大きく下がることが確認できました! しっかり紫外線防止効果があることが分かります。

また、お気に入りの麻生地の日傘も外に比べ約90%近く下がっているのは、個人的に大満足です。また快晴のときにまたいろいろなパターンで実験してみたいですね。

最後に、IoTの設計開発についてご相談したいことがございましたら、遠慮なくこちらのフォームにてお伝えください。

秋も紫外線はまだまだ強い日がありますから、日傘を使いつつ気を付けて過ごそうと思います。いつか、来年の夏の暑い晴れた日に実験再チャレンジしてご報告したいです! ではでは!

bookmark_borderUVをセンサで計測してみよう!⑥ ~外で実際に動作を確認してみよう ~準備編Ⅲ

組み立てたLeafonyをケースに入れよう

組み立てたLeafonyを目立たないようケースに入れて外で実験できるようにしたいと思います。ケースに入れなくても実験はできますが、都会は人の目も多いですし、持ち歩いて怪しまれないように。

って、よっぽどあやしいわ これ

さて、普段の業務だとケースというと”タカチケース”を購入して加工しているのですが、

 「今回はスピード重視で簡単に加工できる」

 「失敗してもすぐやり直せる」 をテーマに掲げて行います!

なぜって、いくら10月で30℃超えの気候とはいえ、ゆっくりしてると冬になってしまうので。

というわけで、何をするかは、ガジェット好きな皆様はもうお分かりですね。

私の大好きな100円ショップ ダイソー様で物色ですルンルン

ダイソーで発見した”便利ケース”

おなじみの収納ケースのエリア、衛生用品、キッチン用品…うろうろしたところ良さそうなものがありました!!

これです

お弁当を毎日作るお母さんお父さんの味方、マヨネーズケース!!

推しポイントは、3つ。

  • カッターで簡単に加工ができます。
  • サイズもスポっときれいには入りませんが少し押し込めば入りそうなところ。
  • しかも、蓋もあるのでここにUVセンサーを固定するのもできそう。

(この創造力を掻き立てるSPECが尊い…)

これに組み立てたLeafonyを入れて実験できるように少し加工していこうと思います!!
で、できあがったのがこちら!!

透明な蓋にセンサー用の穴をあけ、マスキングテープで固定にしました。

さらにさらに、傘にぶら下げるといったことができるように手持ちのチェーンをつけてみました。

え?「マスキングテープ、素敵に貼れませんか」ですって?

(想定よりうまく固定できなかったので試行錯誤しちゃったんですよね。。アハハ。。)

ままま、すごい手作り感満載ですが、これも味ですよアジ! <゜)))彡
準備は完了!! 実際に外で実験してきましょう!!

bookmark_borderUVをセンサで計測してみよう!⑤ ~外で実際に動作を確認してみよう ~準備編Ⅱ

ついにセンサー情報をBLEで飛ばし、無線化しますよ~

動作結果イメージ

今回は、こんな風にUVインデックスが出てくるようにしたいですね。

スマホアプリ画面

ハードウェア

使用するLeafonyのリーフが1枚、追加になります。

AC02 BLE Sugar

Al01 4-Sensors

AP01 AVR MCU

AZ01 USB

AV01 CR2032

AZ01 USBは、ソフトウェア書き込み時のみ使用し、動作時には外します。AV01 CR2032は前回同様、ねじ止めとして使用します。

leafの積み重ね方

重ね方は、こんな感じです。

ソフトウェア書き込み時ソフトウェア書き込み後
上から順に
29pin header, USB, AVR MCU, BLE Sugar, CR2032の順につなげてねじ止めします。
上から順に
29pin header, 4-Sensors, AVR MCU, BLE Sugar, CR2032の順につなげてねじ止めします。

書き込み時に4-Sensorsのリーフを抜いた理由としては付属のネジだと物理的に長さが足りなかったからです。なお、今回、センサーからのデータを取得するのに29pin headerのリーフを使用しました。

このAX018にした理由としては

  • 3.3V出力ピンがあること
  • ピンヘッダーがすでにあるので、リーフに追加で半田しないで使用できること

というメリットがあったからです。

もともとピンヘッダーが付属しているGrove&5Vのリーフを考えていて、高さも取らないし丁度いいかーと考えていたのですが、改めて仕様書みたとき”5V”出力じゃん”というのに気づきまして今回は3.3V出力ピンがあるAX018になりました…

さらにピンヘッダーがすでにあるので、リーフに追加で半田しないで使用できること。これは大きいです。同じく29pin のリーフだとAX02 29 pinもあるのですが、こちらはセンサからの線を直接半田することになるので、ほかのセンサーや実験に使用しづらくなるためAX018にしました。

ヘッダー分の高さを取らないのでいいのですが、ぶっちゃけきれいに半田を取る自信がなく。。。

リスクヘッジも実力よ..

ソフトウェア

前回、Leafonyを動かしてみようで使用したソフトウェアをベースに実装していきます。

まず、記事 # UVをセンサで計測してみよう ~センサを実際に動かしてみる~で実装したプログラムから蛍光ペンで示した箇所の処理をベースのプロジェクトに追加します。

Arduino側のプログラム動作手順概要:

(以下引用)  >

  1. 初期設定
    • PCとのHardwareSerial通信を開始
    • センサのイネーブルピンにHigh出力
    • 1secのタイマを開始
  2. タイムアウト時にセンサの出力ピンからアナログ値を取得
  3. 取得した値を電圧値に変換
  4. 電圧値からUVインデックス値に変換してシリアルで表示

追加した箇所は、こうなります。

変更箇所➡変更後
センサのイネーブルピンにHigh出力setupPort() 関数内に追加
・センサの出力ピンからアナログ値を取得
・取得した値を電圧値に変換
・電圧値からUVインデックス値に変換
loopSensor() 関数内に追加

これで定期的にUVインデックス値を求めることができるようになりました。(注) 基本的には上記の処理をベースのプロジェクトに追加すればよいのですが、以下の点は修正が必要です。

また、以下の設定変更も必要です。

  • アナログ値を電圧値に変換する際のリファレンス電圧を5Vから3.3Vにする
  • センサーとの接続ピンをベースのプログラムで使用していないピンに変更する
ピン変更箇所➡ピン変更後
センサ値の入力ピン      A0  A3
センサへのイネーブル出力ピン D7  D5

UVインデックスの定期無線送信設定

最後に定期的に取得したUVインデックスを無線で送信できるようにします。

ベースのソースコードを読むとbt_sensData() 関数内において無線で送信するデータを設定しているようです。そこで、そのうちもともと照度データを設定している箇所をUVインデックス値に差し替えします。

合わせて小数点以下の値も表示したいのでdstorfの引数の値も変更します。

これでソフトウェアの実装は完了です。

今までに作成したコードのコピペと少ない修正で無線化のプログラムができました!! 

動作結果

UVをセンサで計測してみよう ~センサを実際に動かしてみる~のときと同じようにUV LEDネイルライトで実験してみました。動作するかな。。。

スマホアプリ画面

照度の欄にUVインデックス値が表示されていますね!!

無事無線化できました!!

次は組み立てたLeafonyを手ごろなケースに入れたいと思います! ケースに入れればこれで準備編も終了です!実計測までもう少しです!!

bookmark_borderUVをセンサで計測してみよう!④ ~外で実際に動作を確認してみよう ~準備編Ⅰ~

こんにちは。あたふた仕事に追われていたら、10月になっていました💦
相変わらず外は30℃超える日もあってアチチ。。秋っぽい高い青空が待ち遠しい~

## センサ値を無線で飛ばそう

さて、前回は、PCでセンサ値を表示することができましたが、実際に外で実験する場合、PCを持ち歩かないといけないというのは大変なので無線化して、スマートフォンで確認できるようにしたい!と申しておりました。 (PC持ち歩いてしたら不審な行動に見られそうですし。。)

それを今回やります! ↓前回の記事はこちらから。

無線化するにあたっていろいろな方法がありますが、今回はArduinoと互換性がある”Leafony”を使用してBLEでセンサ値を飛ばしてスマートフォンに表示したいと思います。

Leafonyを選択した理由としては、前回でArduinoを使用してUVインデックスを求めた時のコードをそのまま使用できる点で便利!!という点と、基板サイズが一円玉サイズと小さいので外で実験したとき怪しまれづらいかなーという思いで。(^^)

Leafonyの一円玉との比較

## Leafonyを動かしてみよう

Leafonyが動作することをまず確認してみようと思います。

Leafonyの公式HPにあるクイックスタートの”BLEで環境センシング”を試してみます。

Basic Kit スタートガイド | Leafony

## ハードウェア

今回使用するリーフはこれら5つです。AV01はleafを重ねて”ねじ止め”するだけに使い、電源はAZ01 USBから供給します。

AC02 BLE Sugar

Al01 4-Sensors

AP01 AVR MCU

AZ01 USB

AV01 CR2032

上から順に ①4-Sensors, ②USB, ③AVR MCU, ④BLE Sugar, ⑤CR2032の順につなげてねじ止めします。

## ソフトウェア

Sample-Sketches/4-Sensors_BLE at master · Leafony/Sample-Sketches · GitHub

を使用。

但し、使用したライブラリがこのサンプルのバージョンとあっていないか、違うライブラリを使用したのか以下の点をサンプルから変更しました。

変更前➡ 変更後
#include <HTS221.h>#include <Arduino_HTS221.h>
#include <ST7032.h>#include <LCD_ST7032.h>
ST7032 lcd;LCD_ST7032 lcd;
lcd.begin(8, 2);   lcd.begin();
lcd.setContrast(30); lcd.setcontrast(30);
smeHumidity.begin();HTS.begin();
dataTemp = (float)smeHumidity.readTemperature(); dataTemp = (float)HTS.readTemperature();
dataHumid = (float)smeHumidity.readHumidity(); dataHumid = (float)HTS.readHumidity();

## 動作結果

Andoridスマホのブラウザからセンサ値がきちんと表示されました!

Leafonyが正常に動作することを確認できましたので、次はとうとう今回の本題、UVインデックスの値を無線で飛ばして確認できるようにしたいと思います!

bookmark_borderUVをセンサで計測してみよう!③ ~センサを実際に動かしてみる

では、さっそくセンサを動かしてみましょう!

## ハードウェア

  • ML8511使用紫外線センサーモジュール(ML8511)

ML8511使用紫外線センサーモジュール: オプトエレクトロニクス 秋月電子通商-電子部品・ネット通販 (akizukidenshi.com)

久しぶりの半田付けで少しドキドキしました(苦笑)

余裕のフリ…

感覚忘れないように定期的にしないとダメですね。頑張ります!

  • Arduino Leonardo

こちらは、以前のテーマ↓で使用したデバイスを流用しています。

  • USBケーブル(Micro USB Type-B 2.0)
  • Windows 11 PC 

そして、手軽に紫外線を照射する装置も必要です。

  • UV LED ネイルライト

これは、センサが紫外線に反応することを確認するために使用しました! 確認のために窓際や外に行くのも面倒なので、手元で確認できるものないかなーと探してみたところ、3COINSで発見!! 

私も大好きなぷっくりツヤっとしたジェルネイルを硬化させるために爪に当てて使用するものです。これで税別300円とは今回使用するセンサよりもさらにリーズナブルです!

3COINSさん流石ですね。。

UVLEDネイルライト/and us | 3COINS(スリーコインズ)レディース | PAL CLOSET(パルクローゼット) – パルグループ公式ファッション通販サイト

## ハードウェア接続

以下の図のように実際に接続しました。

以上でプログラム実装前の前準備が完了です。

## プログラム実装

今回使用するセンサからはUV光強度に比例したアナログ電圧が出力されます。

なので、定期的にアナログ値を取得して電圧値に変化する処理を実装すればセンサの値は取得できそうですね。ただ電圧値だけでは紫外線が強いのかわかりづらいので、電圧値からUVインデックスを求めてPCに表示するプログラムを実装したいと思います。

計算方法ですが、アプリケーションノートML8511_UV.pdf (sparkfun.com)

に詳細に記載されていましたので、この方法で求めていきたいと思います。

Arduino側のプログラム動作手順概要:

  1. 初期設定
    • PCとのHardwareSerial通信を開始
    • センサのイネーブルピンにHigh出力
    • 1secのタイマを開始
  2. タイムアウト時にセンサの出力ピンからアナログ値を取得
  3. 取得した値を電圧値に変換
  4. 電圧値からUVインデックス値に変換してシリアルで表示

Arduinoのツールに”Serial Plotter”というものがあり、シリアル出力した値をグラフ化してくれます。

簡単に状態変化をリアルタイムで確認できるので、かなり便利でした。

## センサ動作結果

UVライトのON/OFFとUVセンサのリアルタイムの状態変化が分かるSerial Plotterのグラフを一緒に動画にしてみました。

ML8511によるUVLEDネイルライトの紫外線計測結果をSerial Plotterのグラフ表示

動画8秒あたりから、UVライトONするとすぐセンサは反応してくれています!! 👏

UVを照射するとUVインデックス約2.5~3のあたり、弱い➡中程度のあたりでグラフ表示されますね。

今回より出力が高いUV LEDネイルライトだと数値が変わるのか興味があります。今回は室内というのもあり補正をしてないのですが、アプリケーションノートによると環境によってUVインデックスからの補正が必要なようで、条件によって誤差がありそうです。

よくよく調べてみるとSerial Plotterのグラフは複数データの表示もできるようです。ただY軸の範囲は自動で変更されるようなので、値の範囲が異なる数字を表示するときは注意が必要そうです。

おっと、UVインデックスのリファレンスとなるデバイスを用意していないです。あーリファレンスをどうしよう。。。

あ!そうだ気象庁情報です!!

気象庁で紫外線情報(分布図)を出しているのです。ピンポイントではありませんが、実験している場所付近の値をリファレンスにすればある程度は使えそうに思います!

気象庁| 紫外線情報(分布図) (jma.go.jp)

ちなみに気象庁紫外線情報のUVインデックスは11+が最高ではなく、さらに12や13+があるのですが、日本でしばしば12や13といった値が観測されるため、気象庁では実情に合わせて13+まで表示するそうです。恐るべし日本の夏!

さて、センサが動くことは確認できたので、次は外で実験する前にUVインデックスを無線で飛ばして確認できるように改造したいと思います!

外出先でPC+Arduinoを常に一緒に持ち歩いて計測するのも大変なので(トホホ)

それではまた!

bookmark_borderUVをセンサで計測してみよう!②~UVセンサとは?

今日も猛暑日予想です💦

こんにちは。UV計測ガジェットを作るシリーズの2回目です。

紫外線を計測できるお手頃なモジュールはいろいろありますが、今回は

ML8511使用紫外線センサーモジュール: オプトエレクトロニクス 秋月電子通商-電子部品・ネット通販 (akizukidenshi.com)
このセンサーモジュールを使用します。約10mm角のコンパクトでとっても使いやすそうな形状です。

## ML8511のセンサ特性

このML8511はUV-AおよびUV-Bに対する光センサで、センサ値はアナログ値で出力されます。

280nm-400nmの紫外線領域をしっかり計測してくれます(スペック表より)

## UV-A,UV-Bの定義

ちなみに、前回の記事でお肌に影響のある紫外線の波長にはUV-AとUV-Bの2種類あると触れましたが、定義がいくつかあるようで、気象庁ではこういう分け方をしています。

  • UV-B 280-315nm(ナノメートル)
  • UV-A 315-400nm

ちなみにML8511はUV-AとUV-B両方が合わさった値が出力されます。せっかくなのでそれぞれの値も知りたかったところですが、まあ今回はUV対策グッズの効果をみるのが目的ですので全く問題ないですので、このセンサで評価していこうと思いますm(__)m

## UV対策グッズの効果の評価指標

ML8511が計測したセンサ値をわかりやすく表示するために指標があると便利ですね。WHOが提示した紫外線の人体への影響度合いに関する指標として”UVインデックス”というものがありますので、センサ値からこのUVインデックスを求めて、UV対策グッズを使用した場合どう表示が変わるのか確認する装置を作っていきましょう。

ML8511から出力されるセンサ値は電圧値が出力されるので、電圧値からこのUVインデックスを求めることになるのですが、今回のテーマはここの作り方に気を付ける必要がありそうです。

### UVインデックス (環境省紫外線環境保健マニュアル)

(引用) UVインデックスとは、日常生活で使いやすい数値(影響度合いの一つの目安)とするため、地上に達する紫外線の波長毎の強さと、人体への影響度(紅斑作用スペクトル)を掛け合わせた数値を、使いやすい数値(0~11+)に指標化したものです。(引用ここまで)

WHOの基準を基に、UVインデックスに応じた対策が定義されていますが、12段階あるインデックス値を、環境省はさらにシンプルに5段階に分け対策指標化していますね。

次回は、実際にセンサーを使ってUV計測を行います!

bookmark_borderUVをセンサで計測してみよう!① ~UVとは?

お盆もとうに過ぎ、もうすぐ衣替えの季節というのに、燦々と輝く太陽の光はいまだ真夏の様。

会社帰りに好きなブランドのウィンドウショッピングしてると、どの店ももう秋物の新作ばかり並べています。めちゃくちゃ欲しいけど、暑さが和らぐ気配もみじんもなく、一体いつ着られるようになるかしらと、購入には二の足三の足?踏んでます。

あら私、今日はUV対策のお話をしたかったのですが、話が秋物選びに飛んでしまいました笑 

皆さんはUV対策としてどんなことをされていますか?

ちなみに私は、日焼け止めに日傘、帽子、手袋ってとこでしょうか。

最近は男女、大人も子供も関係なく日傘を差しているのをよく街でみますね。数年前まではここまで日傘人口をみなかったように個人的には感じてます。

実際私も日ごろ日傘には大変お世話になっています。最近はゲリラ豪雨も頻繁なので晴雨兼用の日傘を常に持ち歩いています。(便利ですね)

そこで今回は、日傘などのUV対策グッズで実際どれくらいのUVカットになっているのか、ガジェットを作って確認してみよう!と思います。

※今回の検証はあくまで個人的興味です。試した製品のUVカット効果を検証し賛否することが目的ではありませんのであしからずご了解ください。

以下、蛇足:

このブログを書くにあたって紫外線にしらべていたところ、環境省の紫外線環境保健マニュアルに日焼け止めについて記載されていて、詳しくて素晴らしかったのでご紹介しますね。

https://www.env.go.jp/content/900410650.pdf 紫外線環境保健マニュアル2020(環境省HP)

まず、紫外線に種類が3つあり、お肌に大敵なのはそのうち2つで、「UV-A」と「UV-B」と呼びます。

  • UV-A:降り注ぐ量は多いが、お肌への影響は比較的小さい。ただし長く当たりすぎるとNGのタイプ。
  • UV-B:降り注ぐ量は少ないが、お肌への影響が大きいので、短期間でも当たりたくないタイプ。

そして、日焼け止め。これも「紫外線吸収剤」「紫外線散乱剤」の2種類あるんです。これも知らなかったです。

紫外線防止剤の種類とその特徴 (出典) 紫外線環境保健マニュアル2020

さらに、日焼け止めクリーム等に記載されている紫外線を防ぐ強さを示すSPFPAという指標。これもなんとなく「数字が大きいのがより防いでくれるものさ」といった程度の印象で使っていました。実際は、SPFがUV-Bに対する指標。PAがUV-Aに対する指標なのでした。

紫外線防止用化粧品と紫外線防止効果 (出典) 紫外線環境保健マニュアル2020

普段私が通勤で日焼け止めとして使用しているファンデーションはSPF 50のPA+++なので、炎天下のレジャー向きでした💦 平日は外に出るのは通勤とランチのみ、というような生活だと過剰防御かもしれませんね。

本論からどんどんずれますが💦マニュアルにあった日焼け止めの塗り方も目から鱗だったので載せておきます。皆さん、ファンデは丁寧に塗って、しっかり紫外線を防ぎましょうね!

(出典) 紫外線環境保健マニュアル2020

さてさて次回は、センサモジュールの準備についてご紹介します。

bookmark_borderハイルドライバー方式の振動子をツイータに搭載。D-CLUEオリジナル ハイレゾスピーカを展示

ハイルドライバー式スピーカセット
シリンダー型ハイレゾスピーカ。中央はメディア再生用アンプ。

今や音楽視聴はデジタルが当たり前という時代ですが、逆にアナログレコードが再ブームで非常に良く売れているという話をよく耳にします。その理由はいろいろあるようですが、1つには、デジタル音源でカットしている超音波領域が再生でき、これが心地よいと思う人が増えたこともあるようです。

これは、近年登場したハイレゾオーディオの特長とも共通します。

今回は、そんなハイレゾ音源が再生でき、当時国産スピーカーでは存在していなかったハイルドライバー(AMT(Air Motion Transformer)とも言います)方式を採用した弊社オリジナルスピーカーセットについてD-CLUEエンジニアの渡辺さんにお伺いしました。

渡辺さんは回路設計エンジニアでありながら、趣味でもうすぐ50年になるオーディオに関する幅広い知見がある方で、オーディオ機器や電子楽器の開発者に対して様々な知見を提供してこられました。

ハイルドライバー方式(Heil Driver)で独自開発

D-CLUEが2017年に開発したこのスピーカーは、弊社に参画する前の当時の渡辺さんが、当時国内メーカが採用していなかったハイルドライバー方式として独自開発していたツイータを、D-CLUEが当時の自治体ベンチャー補助金を得ながら、共同でスピーカーに仕立てたものです。

DCT渡辺さん

D-CLUEオリジナル ハイレゾスピーカーの特長

音量や生産効率を重視した当時主流のコーン型を採用したスピ―カーと違いハイルドライバー方式を採用した本スピーカには以下のような特長があります。

  • 一般的なスピーカーにみられるお椀のような振動子(音の発生源)とちがい、薄くて軽いフィルムを蛇腹状にした特殊な振動子をマウントしています。
  • 打楽器の音抜けが良く、中高域の立ち上がりも素早い。例えばバイオリンのような弦楽器や鳥のさえずりなど繊細かつリアルな音源をくっきりと鮮明に再現します。
  • 平面波という、中高音域の音が均一遠くまで同じように出せるという特長があります。均一で減衰の少ない再生音が、演奏の奥行き感と臨場感をもたらし、可聴位置を選ばない360度立体音場再生を可能にします。

ハイレゾはさらに心身をリラックスさせる効果もあるそうで、大学研究機関と一緒に当社のスピーカーを使って検証実験も行われたそうです。

ツイータ部。スリット内に蛇腹状のハイルドライバー型振動子が見える

大手オーディオメーカー視聴会での評価

「先ず音を聞くと打楽器のリアルさに誰もが一番気が付くと思います」と語ってくれた渡辺さん。

私も実際に楽器演奏のハイレゾ音源を聞いてみました。ドラム音がクリアに耳に入ってきますし、弦楽器は力強く伸びがあります。打楽器・高音域が得意という渡辺さんの言う通りでした。雨上がりの山の自然音源に変えてみると、木の葉から滴る水滴のパラパラという音は打楽器のような粒立ち。小鳥の声は本当に頭上でさえずっているようで、音の素人の私でも強いリアル感、臨場感を感じました。

実際に当時の音響メーカー何社かに対し、実機のプレゼンテーションを行ったそうです。その担当者さん達の評価についても教えてくれました。

  •  バイオリンの音色の立ち上がりが良い。
  •  打楽器の音(と仕上がり)が素晴らしいです。
  •  ギターの高音が良く、スピーカー素材のカラレーションが良い。
  •  現在主流となっているツイーターの金属的な音がしない。
  •  素材の泣きのような音が一切しない。癖がなく素直に音が出ている
  •  スピーカーの素材感を感じさせない、自然な音がする。
  •  再生音の情報量がとても多い。

私も聞いてみて納得しましたが、その当時のオーディオのプロの方々の客観的な評価も素晴らしかったのですね。

仕様概要

本スピーカーの仕様概要をまとめました。

形式:2WAY シリンダー型バスレフ
中高音域:コンパクト型ハイルドライバー
低音域 :8cmコーン型ウーファー
出力音圧レベル:85dB/W (1m)
周波数帯域:70Hz~50KHz(-10dB)
クロスオーバー周波数:2KHz

弊社展示ルームにてリスニング可能

このほど渡辺さんに実機を調整いただいたあと、現在弊社の展示ルームに設置。再生デモをお楽しみいただけるようにしました。弊社にお越しの際はぜひお試しください。

 

bookmark_border駐車場の空きを教えるエッジAIを作る (その3~データセットの課題解決) 

こんにちは。

オープンソースを活用しながら、低コストでエッジ デバイスやさらに小さなIoT デバイスで使用できる小さな AI モデルを作成する、駐車場AI R&D チャレンジの3回目です。

作成したPOCには大きく3つの課題がありました。どのような対策を施し克服したのかご紹介します。

データ注釈の課題克服

まず、時間のかかるプロセスである、データ注釈(アノテーション)の課題解決です。

利用可能なオープンソースの注釈ツールはいくつかありますが、今回のPOCの目的「AI モデルのトレーニングに使用される”ビットマップ マスク イメージを生成する”」こと。この 要件に一致するものはありませんでしたので、私はPython で OpenCV API を使用し自ら注釈モデルを作成しました。

製作した注釈モデルアプリケーション

このアプリケーション製作は慣れていれば非常に簡単です。アプリケーションは 2 つのウィンドウで構成されています。 左側が入力画像、右側が出力マスクです。

ユーザーの作業は基本的に、

「車の位置にある左側の画像をクリック」する、

たったこれだけです。 これにより、右側のマスクが自動的に更新されます。

ちなみに同じ場所をもう一度クリックすると削除できます。キーコントロールで画像を保存、次の画像を選択、ポイント設定という流れでザクザクと設定を進められます。 (すべての画像が同じディレクトリにあると想定ですが)

簡単とはいえども、画像数が多いと当然ながら非常に時間がかかります。もっと楽をしたいので私は、手動で1,000 枚の画像に注釈を付けた後で、その注釈付きの画像を活用して注釈付けAIのトレーニングと AI モデルを作成しました。

このトレーニング済みの AI モデルを使用して、残りの画像に注釈を付け作業を簡略化できました。

そもそもの元画像にミスが多かったせいで、手動で手直しも発生しましたが、とはいえゼロから画像に注釈を付けるよりもはるかに高速で処理できました。

AIモデルの課題克服

次に、注釈モデルアプリの中のAIモデルですが、IoT環境で使うため、プログラムサイズの軽量化が必要です。

注釈モデルアプリの処理の流れ

私の製作した注釈モデルアプリのAI モデル(上図中央)は以下の 2 つの部分で構成されています。

  • 前工程:事前学習された Mobilenet バックボーン (モデルの一部のみ)
  • 後工程:カスタム FCNN (完全畳み込みネットワーク)

学習データ セットが小さかったため、私はこのアプローチを採用しました。 本AI モデルでは、小さなカスタム FCNN セクションのみがトレーニングされますので効率的です。 前工程のMobilenet は事前にトレーニングされているため、画像内の多くの低レベルの特徴を検出できます。後工程の カスタム FCNN のほうは、前工程のMobilenetの検出後画像をさらにフィルタリングし、車のみが検出できるようにしました。この結果私の製作した AI モデルのプログラムサイズは、float32 パラメーターでは約 6 メガバイトでしたが、(パフォーマンスは 1 パーセント (0.3%) ほど低下したものの)量子化 (int8) によって 4 分の 1 (2.5 メガバイト)にまで縮小できました。

データの増強とデータセットの制限の克服

次に、データセットの問題です。

前回2回目のブログで私は、駐車場画像のデータセットに偏りがあると、駐車場監視AIモデルの学習がうまく進まないこと、駐車場においては主に7つのデータセットの課題があるとお伝えしました。

そこで私は駐車場データの増強やデータセットの制限を克服するために、以下のようなアプローチを試みました。

1. データサンプリング

データ分析において、データセットの中から有意な情報を得るため、データの一部を抽出することをサンプリングと言います。また、ヒストグラムの棒のことを英語ではbinビン)と言いますが、ある抽出データがどのビンに属するのかの定義を決めていきます。

まず、駐車場の画像データを、ビン(bin)に配置します。

駐車場の場合は駐車台数がキーになります。たとえば、車が 0 台の画像用のビンが 1 つ、車が 1 台しかない画像用のビンが 1 つなどと決めていきます。駐車場AIデータのトレーニング中は、これらのビンに配置した画像をランダムに選択しAIに答えさせていきます。

さて、昼と夕方では明るさが違うので、AIにより賢くなってもらうには、これらの状態でのサンプリングも必要になります。そこで私はビンをさらに 駐車台数 ✖ 画像の明るさレベル (平均)、明るい、中間、暗いへと分けました。
こうして(影や車の色の違い <明るい白から黒まで>も存在するため、これだけですべての問題が解決するわけではありませんが)様々な明るさ✖台数の駐車場データを設けることで、トレーニング データをより均等に分散させて、トレーニング中のバイアスを減らすことがAIにより賢くなってもらうために必要です。

2. ランダム化によるデータ増強

特定の駐車台数、特定の明るさのデータが十分にない区間も存在します。こうしたトレーニングデータのバイアスを補い均質化する技術としてランダムパッチがあります。

画像の一部分にランダムなパッチを当てて、ふたをします。こうすると、画像内の車の数が変化しますので、違う台数条件のデータを学習させることができます。

ランダム化には他にも方法がありますが、今回のデータの課題の特性を見ながら、ランダムな明るさの変化と、ランダムなコントラスト変更 (ぼかし、シャープ化)も必要と感じ実施しました。

3. ミラーリング

データ増強の方法にミラーリングというものがあります。画像をランダムな角度に水平方向に反転させ、鏡映しのような画像をつくるのですが、私は今回これも用いてみました。

結果

AIモデルのトレーニングには、過学習(オーバーフィッティング)を減らし、バランスの良い学習でAI モデルの堅牢性を向上させる必要がありますが、以上のアプローチの実施後、現時点のデータセットでのAIモデルの認識パフォーマンスは 99% 以上をマークすることができました。

今後の展開

今回のAI モデルは、FCNN (完全な畳み込みネットワーク) と組み合わせた MobileNet バックボーンを使用しましたが、プログラムサイズがまだかなり大きくて、約 2.5 メガバイトでした。 (ただしARM M7 Cortex で MobileNet モデルを実行することは可能です)

プログラムサイズに関しては、Mobilenet バックボーンの削除+完全にカスタム化された AI モデルの作成を行うこと、そしてNeural Architecture Search(NAS)を使ってニューラルネットワークの構造自体を最適化すれば1 メガバイト未満のモデルも構築できると想定しています。

それより重い課題は主な課題はトレーニング データです。 現在のデータセットはおそらく小さすぎて、AI モデルをゼロからトレーニングできません。費用と時間がそれなりにかけて、より多くのデータを収集していく方法は当然ありますが、予算や時間が限られる研究者も大勢いると思います。

だからこそ、私はより高度な AI モデルを使用してトレーニングデータを合成する方法で解決できる可能性に期待しています。大規模なジェネレーティブ AI モデルがトレーニング用データを合成し、その合成データを、今度はIoT やエッジ デバイスで動作する AI モデルのトレーニングに使用するプロセスです。

”合成データは AI データの未来である”

大きなAIがエッジAIのトレーニングをサポートすることが当たり前の世界に1歩でも近づけていきたい。私はこのように強く思っています。

次は、他のエッジAI開発事例についても、お話しできればと思います。

bookmark_border駐車場の空きを教えるエッジAIを作る
(その2~AIモデルおよびデータセットの課題) 

エッジ デバイスやさらに小さなIoT デバイスで使用できる小さな AI モデルを作成する、駐車場AI R&D チャレンジの2回目です。オープンソースを活用しながら低コストでの開発をしています。

今回はそうしたエッヂAI開発でありがちな、乗り越えなければならない課題をお話します。

AI モデルのサイズとパフォーマンス

オープンソースのオブジェクト検出 AI モデルはたくさんあります。 なかでも有名なのはYolo(You only look once) です。 こうしたオープンソースの検出モデルは、多くの研究データ セットで高いスコアを達成する素晴らしいものです。

人や車を検出する、オープンソースのオブジェクト検出AI

ただ、小さなオブジェクトやオブジェクトが密集しているケースなどでは、検出パフォーマンスが低下する傾向があります。加えて、CPUを集中的に使用し、GPU をサポートしないようなエッジ デバイスやIoTデバイスでは、画像のフレーム レートは遅くなるので、さらにパフォーマンスに影響を与えます。

Yoloモデルのサイズは、数百メガバイトから 5 ~ 10 メガバイトまでさまざまあるのですが、 最適化されたモデルが小さいほど、パフォーマンスが低下しますので、今回のエッジAI開発のような、メモリの小さな環境ではかなり厳しい想定はありました。

とはいえ、今回の目的はそうした環境下でも「画像内の 1 つ以上のオブジェクトタイプを検出できる AI モデルを作成すること」です。

もしCPU のみのエッジ デバイスで 5 以上のフレーム レートで機能するAIモデルが実現できれば、さらに難度の高いAI/IoT デバイスでもAIモデルが実行できる可能性がありますのでやる価値はあります。

私は今回のAI モデルのサイズの目標を、エッジ デバイスの場合は 2 Mb 以下、さらに小さなAI/IoT デバイスの場合は 400kB 以下と置いて開発をすすめました。

データセットの注釈(アノテーション)

オリジナルデータ→ アノテーション記録 → イメージマスク出力(AI学習後)

AIモデルの実行環境と同じくらい重要なのが、データセットの注釈(アノテーション)です。

有料のアノテーション済の学習データ(教師データ)は便利ですがご存じの通り高価ですので、今回は無料で扱えるKaggleのデータベースを使うことにしました。

Kaggleのデータセットのデータは4000ほどありましたが、アノテーションが付いておりません。

付けなければなりませんが、人によるアノテーションはお察しの通り途方もない作業で、開発者が自ら行うのは無理があります。そこで、前述の著名な物体検出 AI モデルの「 Yolo」 で車を認識させアノテーションを自動設定しようと試みました。

 ところが、これがうまくいかないのです。

私の感覚ですと、どうもこの「Yolo」はおおまかに1画像に移っている車の数の20%~40%程度しか車を認識しませんでした。

 なぜか。

どうやら映像内で並んでいる車のサイズが小さすぎて、前述した「小さなオブジェクトやオブジェクトが密集しているケース」に相当してしまいYoloが認識できないのが原因のようでした。

結論として今回Yoloが使えないことが分かったので、もう自作しかないと思った私は、映像内の車の位置を記録するアプリケーションをカスタム製作することにしました。

詳細はまた機会があればご紹介しますが、このアプリがうまく各車の位置をアノテーション記録してくれたので、AIモデル学習、その後のAIモデルのイメージ マスク出力までできるようになりました。

データセットのバランス

データ セットの課題はもう1つあります。それはデータセットのバランスです。

データセットのバランスとは、極端に似たデータばっかりセット内に存在するとか、逆にあまり存在しないデータがあるといった不均衡、不均一なデータであることで、そのままAIが学習するとAIモデルの性能評価に偏りが生じる可能性があります。

今回の駐車場のデータセットでもいろいろとありましたが、まとめるとこんな感じです。

  1. 気象条件による明るさの変動
  2. 影による画像の明るさの変化
  3. 明るい日差しの中で白い車
  4. 暗い場所の黒い車
  5. 植物の問題
  6. データセット大きな偏り
  7. 一部の車種の形状

以下簡単にご説明いたします。

1.気象条件による明るさの変動

これは、霧がかかった冬の日から、明るい夏の日までさまざまな状態があります。こうした季節や気象の変化で駐車場の映像の明るさも刻々と変化します。この変動はAIモデル学習に影響を与えます。

2.影による画像の明るさの変化

また、1日の時間帯の条件も難しい時があります。朝から夕方までの太陽の位置で周囲の明るさ自体が変わります。また特に朝夕などで太陽の位置が傾いているときの映像データですと、出来る影が車の周囲に発生をして、これが邪魔をしてAIモデルが車を見分けにくくなることがあります。

日なたと日かげのある条件

3.明るい日差しの中で白い車

たとえば、明るい朝の日差しの中に白い車があるような状況です。こうなると周囲の明るさに車が埋没するので、カメラ センサーが飽和状態になり、車の特徴が見分けにくくなります。

明るいと白い車が飽和しがち

4.暗い場所の黒い車

これは前述の逆パターンで、薄暗くなった夕方になって駐車場へやってきた黒い車は、車とその周囲の明るさが似ていてAIが認識しにくい、という問題を引き起こします。

夕方の黒い車

5.樹木の問題

これもよく問題になります。この駐車場データの右下にある車は、その前にある木々の枝が茂っており、部分的に遮られています。落葉樹ですと冬には葉がありませんが、夏には葉がもっと茂るので、認識率もさらに変わってくることになります。

(右下)木の葉が多い茂っている

6.データセットの大きな偏り

この重要度は前述しましたが、駐車場の映像でのデータセットの偏りとは、なんだかわかりますか?

実は「駐車台数」です。

実際に学習用に入手できた駐車場画像は0~3台ほどが停車しているものが大半で、Kaggleでは4台~というものがほとんどなかったのです。ですので、このまま学習をすすめると、学習に大きな偏りが生じる、という問題を発生させます。

7.一部の車種の形状

こちらも前述いたしましたが、車の形状が大きく違う場合、認識率が落ちることがあります。たとえば、RVやセダンなどが多い国の映像を中心に学習していると、たまに停めに来る大型トラックなどを車と認識しない、ということが起きます。

以上、オープンソースを活用しながら低コストでエッジAI開発をするときの、AI モデルのサイズとパフォーマンス、そして駐車場データセットの課題についてまとめてみました。

いかがでしょうか。皆様の開発の参考になると嬉しいです。

次回は、これらの課題克服のポイントなどについてお伝えしようと思います。