記事一覧

なるほど!I2C

 「I2C」
 マイコン間の通信方法としてフィリップス社が提唱した機器内通信規格です。PICマイコンにも搭載されております。

 今までは使う機会がありませんでしたが、RaspberryPiを使うなら周辺機器との接続にコレは便利だと思うようになってきた。

 ただ、PICのマニュアルを読むとSPIとレジスタや機能がダブっているためにややこしい。
 今まで使わなかった理由の一つでもありますが、次の記事を読んで理解できた。

 「電子工作室 I2Cのスレーブモードの使い方」

 PICの使い方を学習・検討するならこのサイトは欠かせません。

 解説とソースを読んだらアラ簡単。わかればCで書くより簡単だったりして。
 本家マニュアルにあるレジスタ関連の情報と照らし合わせながら整理すればいけそうです。

 RaspberryPiをアタマにして何かを組むには欠かせない手段になりそうです。
 実はここまで敷居が低いのかと驚いていたり・・・。

 RaspberryPiにキーボードやエンコーダを付けられればと思うこともしばしばですが、USB経由でHIDを使うのもアリですが、I2Cでちょいとデータを渡すのが簡単でいいような気がしてきました。
 9軸センサBMX055のお蔭でRaspberryPi側のI2Cの使い方は鍛えられましたので、PIC側のファームウェアを作れたらかなりいいですね。

9軸センサ・・・06軸

 加速度センサによる位置推定は不可能と判断。超音波も面白いけど開発に必要な時間が見えない。
 これ以上使える時間はないので他の方法を模索する。

 依頼主のところで相談していたのですが、そこの社長の一言でブレイクスルーする。
 今回の製品は釣り糸で本体を吊り下げる機構になっていますが、釣り糸をプーリーに巻き付けてロータリーエンコーダでプーリーの回転量をセンシングして釣り糸の送り量を出すことにしました。ある意味、一番簡単な方法なのにナゼ検討しなかったのか・・・。
 これならスクローラーの機構と大差ありませんので経験済みの機構です。

 エンコーダーはA相B相の2相パルス式を使います。
 A相とB相は1/4ずれているので、分解能を4倍にできるし回転方向も出せます。
 処理の方法は比較的簡単です。A相かB相が変化したことで割込みを発生させ、A相B相を2ビットのステップデータに見立て、一つ前の状態からの変化から回転方向を判断し、カウンタをインクリメント/デクリメントします。例外処理として、パルスの変化を検知してもA相B相の値が前と同じなら回転していないとします。パルスの変化を検知してから処理が行われるまでに回転戻りが想定されるからです。境界線で止まっている時にもありえることなので重要です。これを明示的にやらないとグレーゾーンでおかしなことになりかねません。

 ちょっと頑張りましょう。

9軸センサ・・・05軸

 加速度センサで位置推定をすることはかなり難しい。
 それっぽいところまできましたが必要な精度が出せない。最近になって書いてあることを理解できるようになったネット情報にも不可能に近いことだとある。光干渉方式の加速度センサならある程度の精度が期待できるが、サイズ的にも電力的にも処理量的にも無理な感じ。これではダメだ。
 困った・・・

 と、ふと思いつく。

 超音波で距離測定を使ったらどうか!?
 短距離であれば比較的簡単でそれなりの精度が出る方法らしい。やったことはないけれど。

 幸い、今回の製品はパイプの中を撮影することを求められておりまして、wifiも開放空間ではありえない距離を通信しています。60m以上でも全く問題無かったみたいです。対象物が導波管になってくれたのです。
 昔の船とかで使われていた伝声管のイメージでしょうか。作りによるけど200~300m伝えられることもあるとか。ラピュタでおなじみですね。
 超音波は電波と音声の間にある波です。
 ならば期待できるじゃないかと。

 もちろん普通の反射計測は不可能です。なぜなら、管の末端は作業の都合で開放にしないといけないからです。これでは反射波を得ることは不可能。
 ならば、末端に「こだま」を返す装置を入れればいい。音波(ピンガー)を受けたら一定時間後にピンガーを返す装置です。こだま君とでも呼称しましょう。
 音は摂氏0度で331.5m/s、気温が1度上がる毎に伝播速度が0.6m/s増すらしい。湿度にも影響を受けるけど水蒸気で無ければ極わずか。完全な温度管理が出来なくても、求められているのは誤差10cm程度ですから、気温から想定される管内温度で計算しても許容範囲に収まると期待。
 こだま君による遅れ時間が十分に一定であれば、計算においてはその時間分を差し引き、温度による伝播速度から距離を計算することが可能。
 ・・・理屈だけど、加速度センサによる位置推定に比べたら圧倒的に高い精度が期待できる。

 加速度での位置推定においては経験と思慮の浅い方のネットレポートに惑わされましたが、超音波による距離測定は玉成している技術。
 何よりも、ノイズまみれの加速度データから2重積分で位置を推定するのに比べて累積誤差が少ない。
 求められる長さの管内を伝わる超音波を十分なゲインとして受信できるかが肝ですが、妄想抜きに期待感は高い。

雷様の来襲

 久々に劇場で本番中に停電。
 しかも2回続けて。

 高層がピカピカしている雷雲があるから怪しいなぁと思っていたのですが案の定。

 UPSが欲しくなりました。

9軸センサ・・・04軸

 9軸センサ(BMX055)の使い方がボチボチわかってきました。

 初期設定値は、秋月さんのサンプルを鵜呑みにせず、用途と要件をよく考えないとダメでした。
 加速度センサのレンジを±2Gから±4Gにし、ジャイロセンサのレンジを125deg/sから500deg/sにしたところ、かなり素直になりました。これまで難儀していた原因の半分はこれだったようです。

 次にGitHubからもらってきたMadgwickフィルタ。
 これが無ければPythonで9軸センサは使えないと思えるほどありがたいライブラリですが、Readmeにもソースのコメントにも詳細な解説がありません。「ソースを読めば使い方くらいわかるでしょ♪」と言わんばかり。9軸センサを使おうと考えるような人なら(同様のライブラリが書けないまでも)ソースから使い方を読み取れるのが普通なのかもしれませんが、私は理解するのにかなりの時間を要しました。
 そんなレベルなんでインスタンス宣言をした後にベクトル座標を再初期化する方法がソースを読んでもわからない。最終的には勘で見つけましたが、最低限の解説は欲しいなぁと思ったり。この初期化で精度が格段に良くなったのでよかったですけど。
 
 加速度値をセンサー座標系から空間座標系に変換する方法もようやく理解。オイラー角と回転行列の相互変換のことです。
 正しくは、オイラー角と回転行列を使うと何から何が得られるのか、そこで使う公式とPythonへの実装方法がわかっただけ。そもそもの理屈は相変わらず理解不能。
 ネットにあるこの手のネタの解説は、大前提としての目的と大枠の説明をすっ飛ばしていきなり公式の説明が始まり結論も曖昧で終わることが多い。そもそもを知らない人にとっては何がナニやらです。どうやら解決策だということは薄々感じていたけど理解が難しい。つか、前置きの説明が不要な人には公式の説明すら不要なのでは?何のためにネットにネタを挙げているんだ??と思ったり。
 たまたま見かけた大学生の修士論文のお陰で基本的な意味が理解できましたが、学校で学ぶ数学と同じで、目的と効能抜きにいきなり数式の扱いから始めるから理解でずに嫌いになる人が多いのではないかと思ったりもしました。

 あとは、加速度センサにはヒステリンスみたいな特性があるということです。センサにかかる加速度の増減が対称でもセンサから得られる値の増減は対称ではない。
 重力加速度で片側に寄った状態を静止状態(平均値や中央値)とみなしますが、これだと増減の特性が対称でなくても不思議はない。現在これと格闘中。

GPD Pocket のバッテリー・・・7個

 現地照明でした。
 トラブル無ければ暇なポジション。自分の手配要員の飯の心配とミスがあれば頭を下げるのが役回り(俗に言う現地チーフ)。ツアーチームに気を使うけどトラブルが無ければ何もない。平穏無事に現場が進行するので暇、暇、ヒマ。。。
 役回りにストレスはありませんが、眠気と戦うのはかなり辛い(笑)
 聖人ではありませんので死語にもなりつつあるネットサーフィンをしたりYoutubeを観たりして・・・・とにかく、何かあったら即対応できるように待ち構えるのが仕事なので仕方ありませn。

 そんな時、GPD Pocket でYoutubeを観まくっていましたが5時間使えました。

 残り時間の表示は奇妙でしたけどね。
 純正のバッテリー特性とは違うので仕方ないのでしょう。
 5時間は使えたのでいいのだけどね。

apache2がログで溢れた

 未だにウェブカメラの製作と格闘しているワケですが、ナニもしていないのにディスクの空き容量がどんどん減っていく。尋常じゃない。
 原因を探ったところ、なんとウェブサーバー(apache2)のアクセスログが物凄い勢いで蓄積されていました。エラーログは取りたいけど正常なアクセスログは余程のメンテ時以外不要。

 つわけで、正常なアクセスログを一切残さないことにする。

 RaspberryPi buster での設定です。

$ sudo nano /etc/apache2/sites-enabled/000-default.conf

コメント化 → # CustomLog ${APACHE_LOG_DIR}/access.log combined
下に加筆 → CustomLog /dev/null common env=0

 ※ /dev/null は一種のゴミ箱と考えてもいいでしょうか。実体が無いデバイスを示し、ここを記録先とするとOSがデータを受け取るだけで終わるのでデータを捨てるのと同じ結果になるのです。日常的な発想だと記録する記録しないって動作を分岐しそうなものですが、慣れると合理的な考え方だなと思います。送り込んだ瞬間にデータが蒸発するので普及しているOSのゴミ箱とは根本的な意味が違うので注意ですが。

 これで正常なアクセスログを残さなくなり、異様なディスク消費が無くなりました。
 動作温度まで下がりました。

シンプルな調光器・・・増産する

 トライダックが15個欲しいというオーダー。
 電源が壁コンだから以前作った15Aのカフディマーでいいのだけどそんな数ねーよ。12個作って足りなくなるなんて思ってなかった。
 今時トライダックは機材レンタルさんでもレアアイテムだから数揃わないし、中身は簡単だから借りるより作った方が安い。単価が高いケース以外、基板を含む中身の部品は30個分仕入れておいたので不足分を組む。ケースの切削加工は手間かかって面倒だけどね。
 なんとか間に合って良かったと祝杯中(笑)

 秋月さんの調光器キットを丸パクリしてますが、PSEの壁があって販売はしてませんからご勘弁を。

GPD Pocket のバッテリー・・・6個

 バッテリーの残り時間表示は適正とは言い難い状態ですが、バッテリー稼働でYoutubeを連続再生して5時間くらいいけます。
 グラフィックに弱いようで、映像再生ではバッテリーの減りが早いパソコンです。まぁ、いいんでないの。

GPD Pocket のバッテリー・・・5個

 充放電を数回したところバッテリーコントローラーが学習してくれたようです。100%で6時間少々の残り時間を表示するようになりました。これが実勢値かまだ分かりませんが、バッテリーの定格容量が減ったことに対し自然な時間数です。

ページ移動

過去ログ