SSブログ

ミリ波レーダーを使った動体検知システム(4/5)

前回の記事ではレーダー子機と受信親機とをWiFiで通信してレーダーデータの送信を行いましたが、今回はMONO TWELITE(中距離ナローバンド無線IEEE802.15.4(2.4GHz))というデバイスを子機と親機に搭載してデータ送信をするシステムを紹介します。
MONO TWELITEを用いることで 子機はWiFi環境になくてもデータ送信ができ、電源さえあれば設置できるようになります。

図1にMONO TWELITEを使った時のシステム構成を、図2にはレーダー基板を搭載した子機の構成を示します。
親機は、「Raspi3&3.5"Monitor一体型ユニットの製作」で作ったユニットを使いましたが、基本的にはRaspberry pi3BとMONO TWELITEを接続すれば通信ができます。
<2021.07.30追記> 「ミリ波レーダーを使った動体検知システム(5)」で改良版を紹介してます。

図1 MONO TWELITEを使ったシステム構成
図1_レーダーシステム構成V2.0.png

図2 MONO TWELITEを搭載した子機の構成
図2_レーダーシステム子機構成V2.0.jpg

Raspberry pi とMONO TWELITEとの接続回路図、TWELITEとRaspberry piの設定に関してはこちらを参照してください。

Raspberry piは電源立ち上げ後自動的にプログラムが起動するよう設定します。
(子機とMONO TWELITEを使って通信するような状況というのは WiFiが繋がらず子機の立ち上げをVNC viewerで行うことができない環境であると想定されます。また子機にモニターをつなげるのも面倒なことですので、電源を入れたら自動的にプログラムの起動をするような設定が必要になります。)

また 子機を再起動(強制的な電源のOFF->ON)したい場合に 親機からコマンドを送ってそれができるようにしました。
コマンドは子機のRaspberry piで処理を行うのではなく、TWELITEのプログラムを変更してTWELITEのDigital Outoutから電源リセットをかけるようにしてあります。
回路図はこちらを参照願います。
改造したTWELITEプログラムはこちらからダウンロード出来ます。
TWELITEプログラムの改造内容などはこちらを参照願います。

(UDP通信時にも子機のRaspberry pi経由で電源OFF->ONができないかということも検討しましたが、双方向のUDP通信を行うとスレッド1, 2それぞれのループ処理が遅くなってだめでした。Raspberry piがリセットを必要とする状況ではコマンドも受信できないと思うのであまり有用な方法でないと考え、諦めました。)


ソフトウェア
プログラムのダウンロードは以下からできます。
- mmWaveRadar2.1_pkg(tar.gz) 電源リセット対応版(2020.03.05)
- mmWaveRadar2.1_pkg(zip)  電源リセット対応版(2020.03.05)
- mmWaveRadar2.0_pkg(tar.gz)
- mmWaveRadar2.0_pkg(zip)
<2022.09.09 追記>
レーダー設定処理中にエラーが検出されることがります。
概要と対策はこちらを参照願います。<追記終>

プログラムの処理フローと関数呼び出し関係はこちらを参照してください。
設定方法・使用方法はこちらを参照してください。

TWELITEの送信頻度とその影響について
子機からレーダースキャン毎(0.1秒間隔)にデータを送ったところ、子機を止めてもしばらくの間(5秒以上あったと思います)親機はパケット受信をしていました。これは送信が多すぎてバッファーには常に未送信パケットが溜まっているためで、これでは最新状態が親機ではすぐに反映されないことになります。
パケット送信回数を減らしたところ、0.2秒に1パケット程度でないと子機を止めても親機の受信は即座には止まりませんでした。
そこで何回かのレーダースキャンの検出データをまとめて1回で送信するようにしました。
デフォルトはレーダースキャン2回につき1回の送信をしています。まだ反応が遅いようでしたら設定を変えてみてください。ただ 検出点数が多過ぎると1パケットでは送信できずにいくつかのパケットに分割することが必要になって逆効果になることもあります。

この設定は固定物体検出の時間や表示残像時間のに影響がありますので注意してください。
MONO通信モード以外ではレーダーのデータ送信が0.1秒間隔で行われることを前提にしてありますが、MONO通信モードでは、2回のレーダーフレーム分のデータを送るときは約0.2秒間隔送信(=0.1x2)、4回のレーダーフレーム分を送るのであれば 0.4秒間隔送信(=0.1x4) となります。
固定物体検出の時間や表示残像時間これをカウントして行ってますので、この事を考慮して設定値を決めてください。(パケット通信はエラーなどもあるので 時間には多少ばらつきがあります。)
RecordViewer.py でも再生の時間が影響を受けます。
デフォールト設定は 0.1秒間隔で再生表示を行っていますが、MONO通信モードの通信間隔が 0.2秒であれば2倍速で再生されます。
この場合 RecordViewer.py 内の FRAME_DUR の値を通信間隔の値にすればほぼ元通りの時間で再生されます。

MONOパケット用検出点データの変換について
初めは検出点位置座標を小数で扱っていましたが、これだとx,y座標それぞれ4バイトあり、パケットにするにはその16進表記をアスキーコードにするので更に2倍ということで、結局1点あたり16バイト使います。
1パケットは80バイト以下にするので、検出位置データ分としては64バイトで4点分しか送れませんでした。
そこで、グラフ上の座標データで送ることにしました。
グラフ座標は xが -100から +100、 yが0 から 200ですので、数値的には それぞれ1バイトです。ただ変換の都合で xには100を足して負にはならないようにしました。(親機側で -100します。)
これで1点当たり数値上2バイト、パケット上4バイトになり、1パケット当たり最大16点の位置データを送れるようになりました
(TWELITEでバイナリ形式のデータを送ることができれば更に倍の検出点データを送れるのですが、私の知識ではどうしてもPythonでTWELITE用のバイト列処理がうまくできませんでした。
C言語でモジュールを作ればうまく行くのかもしれませんが、今回は諦めてアスキー形式の送信にすることにしました。)


<追記> 2020.03.06
今回の記事まででとりあえず個人的に必要とするシステムの機能・性能は満たすようになったので、今回でミリ波レーダーに関する記事は最終にしたいと思います。
未だ改善したい点はあるのですが、ちょっと高度な知識やプログラミングが必要となりそうなので時間があればいつかチャレンジしてみたいと思ってます。
その内容としては、これまでの製作でレーダーの設定値を変えていろいろ試すことができる環境が作れましたので、まずはレーダー設定データの最適化の検討があります。
また レーダーの出力データはRange/Doppler heatmap 等も可能なようなので、これらを使って改良ができるかも検討の余地があります。
そして、一つの物体に対して検出点がいくつも出る(ゴースト?)のをできるだけ絞り込んだ検出点表示にしたいです。


===== 関連記事 =====
ミリ波レーダーを使った動体検知システム(1/5)
ミリ波レーダーを使った動体検知システム(2/5)
ミリ波レーダーを使った動体検知システム(3/5)
ミリ波レーダーを使った動体検知システム(5/5)
ポータブルミリ波レーダーの製作


>> ブログ記事一覧へ
nice!(0) 
共通テーマ:趣味・カルチャー

nice! 0