Watzhdogの紹介動画および基板設計

目覚ましメガネのWatzhdogは、実はバリエーションとしてペン型タイプも用意する予定である。以下に紹介の動画を示す。

ペン型も周囲に気が付かれず自然に使用することができる形態である。
このペン型および眼鏡型のデバイスに如何にリチウムポリマーバッテリーとジャイロセンサ、振動モータを埋め込むかが肝となる。
いろいろ考えたが、電子回路基板は縦長にするのが良さそうである。ペン型もメガネ型も縦長のスペースを確保できる。
現在設計中の基板は以下のような状態である。個々の部品が小さいため、かなり小型にできそうだが、ペンやメガネに押し込むのはやはり至難の技である。ワクワクする。
Screenshot_from_20180506_204458ちなみに電子回路の設計情報はすべて以下においてある。オープンソースハードウェアである。

| | コメント (0) | トラックバック (0)

目覚ましメガネのプロジェクト名

目覚ましメガネと呼んでいたプロジェクトの正式名称が以下の通り決定しました。


Watzhdog

読みはウォッチドッグです。
この名前は、マイコンをいじっている人にはお馴染みのウォッチドッグタイマから採りました。
ウォッチドッグタイマは、システムの応答が一定時間なくなった場合に、システムを再起動する仕組みです。
睡魔にやられ、応答がなくなった人間を再起動するためのデバイスを供給する本プロジェクトは、このウォッチドッグタイマのアナロジーであり、非常にピッタリの名前な気がしています。
ウォッチドッグの本来のスペルはWatchdogですが、このままだとgoogle検索で埋もれてしまうので、あえてスペルをczに変えています。今のところWatzhdogをググると20件しか出ない。良い。

| | コメント (0) | トラックバック (0)

目覚ましメガネの回路

目覚ましメガネの電子回路設計がだいぶ固まってきました。

ブロック図は前回の記事に書いたとおりで、定数の見直しは必要ですが、ほぼほぼ完成です。
Schematic
リチウムイオン電池の充電器やDCDCコンバータの設計データをSparkFunのGitHubからダウンロードできたのでそのまま使っています。オープンハードウェアで設計時間が大幅に短縮されました。良い時代になったものです。

| | コメント (0) | トラックバック (0)

目覚ましメガネ構想

誰にでも仕事や会議、授業中など寝てはいけない時に強烈な眠気に襲われることがあると思います。

この眠気に対抗するために私は幾多の挑戦を続けてきました。眠気覚ましとしてコーヒーやガムやエナジードリンクを使ったり、両手を上げて伸びをしたり、息を止めたり、果てはシャープペンシルで指を刺したり、辛いお菓子を頬張ったり、ストレッチしてみたり、足に力を入れてみたり、耳を引っ張ったり、できることは何でもしてみましたがどれも居眠り防止に効果がありませんでした。

私は、自分の電子工作とデジタル信号処理の技術で、この眠気の課題を解決できないかと考えました。

まず簡単に思いつくソリューションはスマートウォッチです。近年Apple Watchをはじめとするスマートウォッチが流行っています。このスマートウォッチなら居眠りを検出して、バイブレーションや音で目覚まししてくれそうです。しかし、検索してみると定期的に本体を振動させるアプリはありますが、あまり賢くありません。

ほかに検索してみたところ腕時計で、眠気を検知して振動することで寝落ちを防ぐSparkがありました。これは私がまさにほしかったものです。しかし、Kickstarterで2014年に出資を募りその後発売もされたようですが2018年現在、すでに公式サイトは無くなっており、すでに入手が難しい状況です。
あと腕時計型の難点は本を読むときや腕を机に置いているときに、居眠りを誤検知しないかどうか心配になるところです。

他には、メガネ型のデバイスがあります。有名どころとしてJINS MEMEがあります。JINS MEMEはスマホ連動が前提で単体で目覚ましとして使うことができません。また、公式アプリに目覚ましアプリっぽいものがあるのですが、画面と音声でお伝え…ということで会議中に使えない気がします。バイブするだけのアプリ作ってほしいです。

他にはAmazonで居眠り防止アラームが売っていました。安価で効果がありそうに見えますが、単に頭の傾きを計測して振動するだけです。会議中に手元のPCや資料を見たくなった時にどうするのでしょうか?あとエキゾチックな外観も気になります。
これらの事情を勘案し、私はすごい目覚ましを作ることを決意しました。
現状考えている特長は以下の通りです。

1.メガネ型で目立たず、あらゆるシーンで自然に使える
2.ジャイロセンサで角速度と加速度を計測、信号処理もしくは機械学習で居眠りを検出
3.居眠りしているユーザを振動モーターの振動で起こす

図1にシステム構成図を示します。
System_block_diagram_2
図1 システム構成図


図2はすでに完成したプロトタイプです。側面のジャイロセンサ回路を取り付けUSB経由で60Hzで角速度と加速度を読み出せるようになっています。
Prototype1
Prototype2
図2 プロトタイプの様子


近年のジャイロセンサはすごく高感度なので、体の小さな動きも検出することができます。
例えば使用予定のジャイロセンサMPU-9250では最小±250度/sのレンジを16bitの分解能で計測することができます。
図3と図4は実際にプロトタイプで計測した角速度の波形です。図3は起きているときの角速度の波形です。振幅が大きいことが分かります。図4は寝ているときの波形で脱力しているため角速度が小さくなっていまs。これらを比較すると、少なくとも振幅には大きな違いがありますが、様々な周波数の信号が混ざっており、ここから居眠りを検出するのが最大のチャレンジとなります。
Wake_3
図3 起きている時の角速度の波形


Sleep
図4 居眠りしている時の角速度の波形


果たしてうまくいくでしょうか。何かに集中してじっとしているときと、眠っているときの差はこれらの波形からわかるのでしょうか。ふふふ。

| | コメント (0) | トラックバック (0)

Architect - マイクロマウス2016出場ライントレースロボット

新型のライントレースロボットを製作し 、2016/11/19にマイクロマウス2016のロボトレース競技へ出場してきました。
ロボットの名前はArchitect(アーキテクト)と言います。名前には『カメラ画像を入力とした小型自律ロボットの新しいあり方を創造する』という意味が込められています。
20161123_112040
Architectの特徴は上部につけた魚眼カメラです。魚眼カメラは下向きに取り付けてあり、前後方向の視野が180度あるので、コースの広い範囲を一度に計測することができます。
20161123_112159
ArchitectはスティックPCとマイコンの両方を搭載しています。
スティックPCはIntelのCompute Stick STK2MV64CCで、CPUはCore m5が搭載されています。Core m5はMacbook等にも搭載されており非常にパワフルです。このCompute Stickはコース画像の撮影や二値化、輪郭抽出などの画像処理、地図作成、起動計画まで担当します。
マイコンはSTM32F411で1kHz周期のリアルタイムで速度と角速度の制御およびオドメトリ、バッテリー電圧の監視、LEDの点灯制御を担当します。
マイコンとCompute Stickの間はHDMIを通じて通信しています。正確にはHDMIの中のDDC (Display Data Channel)を使って通信しています。DDCはI2Cと互換性があります。
20161123_112259
Compute StickのOSはLinuxのUbuntu 16.04です。Ubuntuは標準でI2Cをサポートしており、非常に面白いことに、UbuntuからはDDCも他の通常のI2Cと同等に扱えることがわかりました。使い方は、特別なドライバは不要でI2CのデバイスファイルをRead/Writeするだけです。私の環境ではデバイスファイルは/dev/i2c-1でした。もちろんi2cdetectやi2csetコマンドが使えます。なおCompute Stick側が常にI2CのMaster、マイコン側がSlaveになるようです。
DDCをI2Cとして扱う時の注意点として、HDMIポートのHot Plug Detectピンをプルアップしておく必要がありました。このピンは通常は挿抜を検知するために使用されており、少なくともCompute Stickではこのピンがプルアップされていないと正常にI2Cの信号が出力されませんでした。プルアップ抵抗は仮に1kΩとしました。
I2Cの信号は5V 100kHzでした。I2Cの信号ライン(SCL, SDA)のプルアップ抵抗はCompute Stick側に内蔵されていました。
B1909a987bda3ffb9ade39bbfa18d68f
マイコン側の電源電圧は3.3Vでしたがピンに5V耐性があり直結できました。
さらにArchitectはROS Kineticに対応しています。特にカメラ画像の取得や、デバッグデータの記録用にrosbag、パラメータ調整のdynamic reconfigure等を活用しました。時間がなかったのでそれ以上の上位の制御には活用できませんでしたが、今後さまざまなROSパッケージを活用していきたいと思います。
以下に画像処理の様子を示します。
なお、Architectはアニキ氏との合作で、ハードウェアはほとんどアニキ氏に作っていただきました。非常に感謝しています。私が担当したハードウェアはCompute Stickとカメラの選定、カメラを固定する白い部品の設計だけです。
一方、ソフトウェア(マイコンのファームウェア、Ubuntu側のソフトウェア、I2Cの通信)はすべて私が担当しました。
今年のマイクロマウスにおいてArchitectは残念ながら予選敗退でしたが、来年はこの機体をさらにパワーアップさせて是非とも良い成績を残したいと思います。以下に参考までにPS3コントローラでリモートコントロールしている様子を示しますが、ハードウェア自体は非常に完成度が高くキビキビうごきます。潜在能力は非常に高いはずです。後は頭脳がよくなれば…自律走行でもビュンビュン走ることでしょう!
参考URL&製品

| | コメント (0) | トラックバック (0)

Maker Faire Tokyo 2016出展中

後処理動画手ブレ補正装置のvirtualGimbalをMaker Faire Tokyo 2016にて昨日に続き本日8/7も展示いたします。ご来場お待ちしております。

| | コメント (4) | トラックバック (0)

手ブレ補正装置の部品の選定・発注

前回の記事の自作手ブレ補正装置に関して部品を選定・発注した。発注は昇圧回路を除き送料が相対的に安かったRSコンポーネンツとした。

充電回路
BQ24075を使う。1セルのリチウムポリマー電池を充電できるICである。また機器を使用しながらの充電も可。素晴らしい。
※一般的にリチウムポリマー電池は正しく充電しないと爆発するので注意が必要である。このブログを参考にして充電回路を自作する場合は自己責任でお願いします。


昇圧回路
S7VF5を使う。リチウムポリマー電池は電圧が4.2Vから3.0Vまで変動するため、このままでは5Vが必要なRaspberry Piには使えないので一度昇圧する必要がある。SWITCH SCIENCEでユニット化されているのがあるのでそれを使う。昇圧回路は過去に自作したは良いがまともに動かなかった経験があるので、私は自作しないことにしている。


レベル変換
FXMA108を使う。Raspberry Piは5V系だが後述のAD変換やジャイロセンサは3.3V系であるため、相互をつなぐためにはレベル変換ICが必要である。8bitあるので多分信号線の本数は足りる。


6軸
9軸ジャイロセンサ
MPU-9250を使う。角速度だけでなく加速度と地磁気をそれぞれ3軸計測できるSPI接続の9軸センサである。豪華。あとでいろいろ遊べそう。


A/D変換IC
AD7477を使う。これはSPI接続で使える10bit1chのA/D変換ICである。小型なので使いやすい。信号源近くにこいつを配置すれば誘導ノイズを受けにくくなるはず。


平滑化
3.3VのリニアレギュレータであるTPS73633を使う。小さくて使いやすい。A/D変換ICやジャイロセンサといった3.3V系の素子のすぐ近くに配置。昇圧回路で生成した5Vを降圧・平滑化する役割を担う。


明日は回路図を書くか。

| | コメント (0) | トラックバック (0)

自作手ブレ補正装置構想

最近ミラーレス一眼で動画を撮ることが私の楽しみの一つになっています。ミラーレス一眼なら、レンズをF値の小さい明るいレンズに交換することで背景をぼかした柔らかい印象の動画を撮ることができるためです。

しかし、ミラーレス一眼を使って動画を撮る上で問題になるのがやはり手ブレです。
今市販されているミラーレス一眼カメラの多くは、手持ち撮影時の手ブレには対応できますが、歩きながらや走りながら録画する場合は、手ブレが大きすぎて補正しきれません。

このような背景から、動画に生じる比較的大きな手ブレを補正する様々な技術が開発されています。たとえば以下の動画のようなジンバル機構を組み合わせたブラシレスジンバルを用いると手ブレを打ち消してヌルヌルと動く動画を撮影することが出来ます。






このような装置には、大きく分けると1.電子補正方式、2.カメラの揺れを物理的に取り除く方式、の2つの方式があります。以下に両方式の画質と装置のサイズを軸に撮ったポジショニングマップを示します。

7



私には、ミラーレス一眼のレンズ資産を活かしたいけれど、何かしらの大きな装置は荷物になるため持ち運びたくない、しかも高画質でお願いしたい、という欲張りな希望があります。

既存方式について考えると、1の電子補正方式は手軽ですがスマホ用のはレンズを交換できなせん。またソフトウェアの後処理だけで手ブレを軽減してくれる動画編集ソフトはたくさんありますが計算が重く、またレンズの収差の関係か補正した動画に変な歪が出ることがあるたり補正精度に限界があるように感じます。

2のカメラの揺れを物理的に取り除く方式は装置が大きくなるため荷物をなるべく小さくしたい私のニーズを満たしてくれません。DJIのosmoのように専用設計された比較的コンパクトなブラシレスジンバルも発売されていますがやはりレンズ交換が出来ないためここでは除外します。

最近、私が注目していたのはSteadXPと呼ばれる、後付でジャイロセンサ内蔵のユニットを一眼カメラに取り付けることで、どんなカメラでも手ブレ補正機能をあとづけできる製品です。Kickstarterで大きな話題を呼びましたなお、このKickstarterのプロジェクトを見つける前に実は私も独自にジャイロセンサをあとづけして動画を後処理するという同様のアイデアを思いついていましたが、どうやら思いついた時期は同時期ですしSteadXPの方が先にWebに公開したわけですから、別に考案者を名乗るつもりはありません 笑

一瞬、SteadXPは一眼カメラのレンズ資産を活かせつつコンパクトなため、私の希望を見事に解決してくれる素晴らしい製品かと思いましたが、デジタル一眼カメラにSteadXPを取り付けるときは。HDMIケーブルやHDMI to AC変換器を通じてカメラとSteadXPを接続する必要が有るため見た目がスマートとは言えません。結婚式やパーティーに持ち込むのはちょっと気が引けます。

そこで私は、一眼カメラで動画を撮影した時の3軸角速度+3軸加速度=合計6軸の動きを記録し、その情報をソフトウェアの後処理で利用することで手ブレを補正する装置を開発することにします。

動画編集ソフトとの違いは、センサで取得したカメラの動き情報があるか否かです。
SteadXPとの違いは、カメラと装置をつなぐケーブルが存在しないことです。上図にこの装置のポジショニングを目標のポジションとして示します。

以下に構想段階ですが手ブレ補正装置のブロック図を書きます。

Photo_2


基本的には、ミラーレス一眼カメラの動画撮影にタイミングを合わせて、6軸ジャイロセンサの波形をRaspberry Piが定期的に読みだしてmicroSDカードに記録する形になります。

手ブレ補正処理自体は、microSDに記録された6軸の手ブレ波形を使ってPC上で後処理によって実現します。

ところで、市販の一眼カメラに後付でこのようなユニットを載せた時に問題になるのが、撮影された動画と、センサ波形のタイミング合わせだとおもいます。センサ波形と動画のタイミングが合っていなければ正しい手ブレ補正効果は得られないでしょう。
市販品の一眼カメラからはおそらく電気的に撮影開始のタイミングを引き出すことができないので、撮影開始と終了のタイミングを別の方法で知る必要があります。上図では?マークで表してあります。

私は、タイミング検出に関してちょっといいアイデアを思いついたので、これを実証してみようと思います。この計画は、画像処理と計算機科学、Linuxにおけるリアルタイム処理の良い勉強になりそうです。
またロボット競技のためでもなく、仕事のためでもない、自分のためのものづくりができるのでとても楽しみです。土曜日は使用するICの選定と回路の設計でもしますかね。

| | コメント (0) | トラックバック (0)

マイクロマウス2015所感とMETEORA 4の紹介

マイクロマウス2015に出場された方々および運営の方々お疲れ様でした。
私のロボトレーサ、METEORA 4は予選敗退でしたが全力を尽くしましたし、様々な人から反響を得られたので満足でした。

P2

METEORA 4はカメラ映像から白線を認識して走るロボトレーサです。認識処理は名刺サイズコンピュータのRaspberry Pi 2 Bをつかっています。
今年は昨年に比べてソフトウェアを大幅に進化させ、コースを認識する画像処理にSLAM(Simultaneous Localization And Mapping)という技術をつかいました。SLAMは近年自動運転車の制御にも用いられている、未知の環境下でロボットが自律移動するための技術でカメラなどの外界センサとオドメトリなどの内界センサからのデータから、ロボット周辺の環境地図の作成と、ロボット自身の自己位置推定を同時に実行します。
私はこのSLAM技術で、ロボトレースコースのS字カーブを連結させて直線みたいに走ったり、ルール違反にならない範囲でカーブの内側を走って走行距離を短縮したりという賢い動作をロボトレーサにさせたかったのです。
METEORA 4が使っている種類のSLAM(占有格子地図ベースのFastSLAM)では、計算の過程で少しずつ形の異なる地図を数万枚のメモリ上に記憶し、これらをカメラ映像とオドメトリの情報により常時更新する必要があるのですが、Raspberry Pi 2 BではCPUの動作速度とメモリの容量が限られているため地図は100枚だけつかいました。地図にはコースを12mm間隔で格子状に区切って白黒の濃淡を記録してあります。
以下の動画は手押しでコース上をロボットを走らせながらカメラとオドメトリの情報を録画して、あとからオフラインでSLAMをシミュレーションした様子の動画です。



ロボトレース予選では走行の途中からMETEORA 4が制御不能になりコースアウトしリタイアとなりました。 METEORA 4では地図をたった100枚だけしか持っていませんが、 SLAMでは機体の移動にともないそれぞれの地図が拡大していくため、メモリの消費量が急速に増大しどうやら処理速度が追いつかなかったようです。 
またRaspberry Pi 2 BはクアッドコアのARM Cortex-A7のCPUと1GBのRAMを搭載していますが、METEORA 4ではOpenMPで並列化し4個のコアをすべて使いきってました。
このハードウェアのままでは、これ以上計算速度を上げるのは難しそうです。次の一手を考えなくてはいけません。

| | コメント (0) | トラックバック (0)

制御方策の生成

前回の記事ではロボトレースの地図からショートカットする経路を生成しましたが今日、そこから更に制御方策(制御の計画)を立てることが出来ました。制御方策とは、状態ベクトル(x座標とy座標からなる二次元のベクトル)から、制御量(ロボットの角度θ)への射影です。すなわち制御方策とは、ロボットの自己位置から、姿勢の目標角度を決定するための対応表なのです。

下図は制御方策を可視化したものです。緑の直線が目標角度の方向を表しています。直線には赤い印で頭の方向を示してあります。

20151008_003306_cp1

一般的にこの制御方策はロボットのxとyの位置に加えロボットの姿勢θが加わった三次元になるようですが、勉強不足のためMETEORAではとりあえずこの制御方策をxとyの二次元で作りました。二次元なら三次元よりはるかにメモリの占有量も少ないし…。

このような制御方策を作ることのメリットは、ロボットの行動や計測の不確かさを考慮した制御ができることらしいです。らしい、と書いたのは私自身がまだ腑に落ちていないため、ただ確率ロボティクスの本の言葉を引用しているためです。ロボトレースの大会が終わったらさらに勉強したい。

| | コメント (0) | トラックバック (0)

«最短経路生成