GPSロボットカーの作り方 (QZSS)
(ちょっと効果的だったあがき1)
怪しいのはSPI。でもSPIの機器はちょっと考えてみたのだが、手元にはなさそう。
そこで、考えたのが、とりあえず自分で折り返してPi側の健全性を確認する。
まずは、SPI関連のモジュールを確認した。
参考にさせてもらったのは下記のページ。
https://tomosoft.jp/design/?p=5428
これで、動作確認をしてみると、Piのみで配線を折り返してLoopbackを実施すると問題ない。試しにLoopBackの配線を外した結果と。HATを接続した場合は同じ結果となる。
ここまで、証拠を突きつければおのずと、HATの単品故障と断定した。
SPI機器の動作がうまくいかないときにはおすすめである。
(無駄なあがき1)
ソース( dual_chan_pkt_fwd.cpp )を見てみると、、、
”Unrecognized transceiver” が出るときは、プログラム終了？ まぁ、認識できないんだからそうあるべきだが、この”Success”は SPI デバイスからの戻り値が予想外ということだった。
この手のトラブルは日常茶飯事なので、さっそく幾つが戻ってくるかをDebugメッセージを追加。 すると、”0”が戻ってきていた。
SPIが調子悪いと思いつつ、Pin配置やほかのプログラムも確認。 まぁ問題はなさそう。
(無駄なあがき2)
そういえば、このPiでSPIを使ったことがない。 手持ちにあるほかのRaspberry Piを持ってきて、やっても結果は変わらず。 結局もとのPi Zeroで継続調査することとした。
試行錯誤すること1日 、気が付いたら赤いLEDがついている。 「？？？」 よく見たら電源のLEDである。 電源不足だったというオチでした。
そこで、容量の大きい電源に入れ替え、再実験。 それでも結果は同じ。
”Unrecognized transceiver” が出る。
電源に気が付いたのは良いが、これまでのは無駄なあがきだった。。。
HAT(DRAGINO LoRa GPS HAT -JP)とRaspberry Piの接続方法については、多くの事例があるので、それらを参考にしてほしい。
ここでは、それらでトラブった内容について記載する。
Raspberry Piはこれまで使っていたものを再利用していたので、とりあえずパッケージの更新だけはしておいた。 かなり時間はかかるが保険のようなもの。ただし、これによって動作しなくなる可能性もある。 我が家では数台のPiとSDカードがあり、いくつかの実験の残痕を都度世代のバックアップとしても使っている。
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
特に、今回作業後に実施したのはSPIの有効化。 これは忘れないように実施する必要がある。
$ ls -l /dev/spi*
でファイルが出てくればOk。
その後、一度Shutdownして電源を落としてHATとPiを接続し、再起動。
その後、今回Piの中にいてDeviceからくる電文を受信し、Broketへ橋渡しする機能であるdual_chan_pkt_fwdを入手する。
$ mkdir dual_chan_pkt_fwd
$ wget https://github.com/bokse001/dual_chan_pkt_fwd/archive/master.zip
$ unzip master.zip
$ mv dual_chan_pkt_fwd-master dual_chan_pkt_fwd
便利な世の中になったもんだと思いつつも、日本向けと使用する周波数の設定を行う。
これも、沢山Webで紹介が出ているので、それに従ってもらえればよい。
$ cd dual_chan_pkt_fwd
$ vi global_config.json
$ vi dual_chan_pkt_fwd.cpp
多くの方は、ここですぐにmake installを実施しているが、なんとなくmakeだけで実行。
すると、多くのワーニングが、、、、 ざっと下記の感じ。
エンコーディングらしきメッセージもたくさんあったので、エンコーディングを再度設定して見直したが、大きな改善は見られない。 実行形式もできているので、今回は無視し、先に進めることとした。 一応Webで同現象の人を探したのですが、見つけられなかった。
そこで、実行してみると、何か表示が足りない。
もしや修正したところかと思い、再度元のソースから、最低限だけの修正を実施して、実行。 でも結果は変わらず。 その時のメッセージが下記。
pi@raspberrypi:~/dual_chan_pkt_fwd $ ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.jp.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
team katy (iot@space.mars.jp)
Dual channel pkt forwarder
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
Transceiver version 0x00
Unrecognized transceiver: Permission denied
pi@raspberrypi:~/dual_chan_pkt_fwd $ sudo ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.jp.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
XXXXX XXXXX(XXXXXXXXXXXXXX) ←ここは自主規制で隠しました。
Dual channel pkt forwarder
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
Transceiver version 0x00
Unrecognized transceiver: Success
pi@raspberrypi:~/dual_chan_pkt_fwd $
Unrecognized transceiver？ 認識できない？
Success？ 成功？？？？
これが、泥沼の始まりだったとは。。。
まずBrokerであるMosquittoを動かす。
単純にコマンドを入力するだけ。(エラーが出たらPATH設定の可能性が高い？)
この状態で、別のコマンドプロンプトからトピックをtopic_ABCでClient(購読)を立ち上げておく
mosquitto_sub -d -t toopic_ABC
これは、受信者(購読者)を一人立ち上げたということである。 この受信者はtopic_ABCというタイトルについての情報を得る。
さらに別のコマンドプロンプトでtpoic_ABCに123.456を発行する。
mosquitto_pub -d -t topic_ABC -m “123.456”
すると少し待っていると、Client側で123.456が受信できる。
今回は同じPCを利用してテストしたが、ネットワークを使用して実施する場合はIPアドレスとポート番号を指定する。 (mosquittoでのデフォルトポート番号は1883)
mosquitto_sub -d -h 192.168.56.42 -p 1883 -t topic_ABC
mosquitto_pub -d -h 192.168.56.42 -p 1883 -t topic_ABC -m “123.456″
MQTTを体験するために、機材を用いないでWindows10のPC１台で実験してみた。
MQTTの電文データも見てみると非常的に興味のある内容であったが、それは機会あるときに投稿するとして、今回はMosquittoを実験台として使用した。
MQTT（Message Queuing Telemetry Transport）とは、通信速度、通信量を重視しないケースにおいてTCP/IP通信を実現する軽量なプロトコルである。
MQTTはBrokerというデータをIoT機器から受信配布する機能があるモデルを使用しているのが特徴であり、UserはそのBrokerにデータを取りに行く(or もらう) ことになる。 DeviceであるIoT機器側はPublish(発行/送信)という形で情報を提供しPC（購読/受信)という方式となる。
ここで使用されるデータにはトピックという識別子に紐づいている。
MQTTプロトコルを実験するために必要な要素として重要な位置づけを占めるもの(?)はBrokerである。 自宅環境でテストするのであれば、PCに入れればよいし、Internet上にあるフリーのBrokerを利用することも可能である。 Mosquittoというのは今回使用したBrokerソフトである。
https://mosquitto.org/download/
私のWindows10は64bit Buildなのでそれに合わせた。
mosquitto-1.6.9-install-windows-x64.exe
をダウンロードし実行した。また、これを実行するためにはOpenSSLが必要なので、これもインストールする。
http://slproweb.com/products/Win32OpenSSL.html
いくつが選択があるが、私は「Win64 OpenSSL v1.1.1g」を選択した。
(アンチウィルスソフトが警告が出ていたが)
今回は、一通り実験することになるのだが、時間が無尽蔵にあるわけではないので実験の順番というものは非常に大事である。 もちろん時間切れで挫折する可能性もあるので、全体を抑えつつ、悩みそうで興味があるところに時間をかけてみる。 これはロボット大会における
準備した機材は以下の通り。 入手した場所ではないが、Webで見つけられた場所を記載する。 まずはWebをみて、皆が使用しているものを採択した。
実験するホストとしてはWindows10を使用した。
Deviceとして
“DRAGINO 高周波回路 開発キット ATMega328P LoRa Mini Dev Development Board for LoRa Mini”
https://jp.rs-online.com/web/p/radio-frequency-development-kits/1883151/
注意しなくてはならないのは日本規格を通ったもの。ほかのGatewayで安いものは周波数帯が日本規格でなかったりするので要注意。
センサとして”DHT11″
https://jp.rs-online.com/web/p/sensor-development-kits/1743237/
LoRa WAN Gatewayとして”DRAGINO LoRa GPS HAT -JP”
https://jp.rs-online.com/web/p/products/1875121
ここも周波数帯は十分に注意すること。
Gateway用の機器として”Raspberry Pi Zero WH”
https://www.switch-science.com/catalog/3200/
GatewayはRaspberry Piにスタックして搭載されるために、40Pinコネクタのものが必要である。 (ピンヘッドありのものを購入する必要がある)
普通にRaspberry Pi 3 Model Bに接続するのが普通であろう。
下に赤白に見えるものがケースに入ったRaspberry Pi Zeroである。
これはCPU処理能力は少し劣るものの、小型で無線もついているのでちょっとした実験には大変重宝している。
Pi ZeroとしてはPCのUSB電源供給で十分に動作するが、HAT(Gatewayのボード)を取り付けると、Pi自体は動作するが、HATのPWR LEDが点灯しないので、別電源を準備したほうが良い。 ここでは、5V 3Aと表示のある電源を使用している。
その後、HATの故障を判断したが、可能性の一つとして電圧の不安定な状態で動作させたことが可能性として考えられるが、調査はしていない。 似たような原因でESP32を複数個がお蔵になり復旧されるタイミングを待っているが、このHATもお蔵に入ってしまった。 別途トラブルシューティングを投稿予定。
また、無料のサービスに登録するために有効なメールアドレスが必要である。新たに二つのサービスに登録した。費用は掛からない。
まず、時間としても無尽蔵にあるわけではないので、一つのことに入り込まないように全体としてのゴールイメージを書いてみた。 試してみるにあたり、ゴールを設定していろいろと絵をかいてみた。 まずは、ゴールを書いてみて、そこからいろいろと調査、実験をしながら進めていくと、結構あいまいな知識であったことがよくわかるのと、現実(時間と重要度)が見えてきてどうしてもゴールを動かしたくなってくる。 趣味ごとなので、これで良しとする。
最初のイメージは下記の通り。
大きな間違いとして、すでにLPWN であるLoRa WANのネットワーク網は無料でお試しで、簡単にできるかと想像していた。 これは大きな間違いであった。
調べた結果、下記のゴール設定となった。 これも、まだ書き換えることになるかもしれない。(まだ、間違っている部分もある。)
センサーから説明すると、ここで温度センサと湿度センサを実験として使用した。ここは良く使い慣れたArduinoを素材とし、それにLoRaのWireless Moduleがついたものを用いている。
まず、Nodeと呼ばれるものの役目だが、正確にはDeviceといったほうがよさそうである。ただ、一つのDeviceには複数のセンサデータなどを含めることができる。
上図のNode(Device)の役目は、
-センサからデータを収集
-MQTTというプロトコルに合わせこむ
-LoRa網を経由させてLoRa Gatewayにデータを送る
となる。
LoRa Gatewayの役目は、LoRa網に来たDeviceからデータをInternet上にあるBrokerに転送することである。
Brokerの役目は、Deviceから来たデータを配信する役目を担う。
IoT ServiceはBrokerと連携してデータの蓄積、集計、HMI(表示器)などの役目をする。
MQTTはプロトコルとしてPublisher/Subscriberモデルでメッセージングを行います。
メッセージの発信者(出版者)をPublisher、メッセージの受信者(購読者)をSubscriber、メッセージの仲介をするのがBrokerです。出版者が不安定だったり購読者が多いケースなど利点もたくさんあるのですが、欠点もある手法なので注意は必要となる。
感想として、MQTTは、使用目的が簡易な機器のデータ通信に特化しており、ある程度割り切りの使い方をすることで、HTTPなどと比べても非常に小さなプロトコルである。
思いもよらず、まとまった時間が取れたために、前々から興味のあったIoTなるものを実験してみることとした。これまで、LPWANなど思想はJT65に近く、低消費電力や長距離通信という目的に可能性をおおきに感じることができる。記事などを見る機会は多かったが、今回試してみたので、ここにメモとして記載しておく。
ここで使用しているGPSモジュールはubloxのNEO-M8Nである。
データシートを見ると、「NMEA 0183, version 4.0 (V2.3 or V4.1 configurable)」と記載がある。NMEAの電文を利用するだけで、緯度、経度、進行方向、対地速度などは利用できる。ただし、ある程度の移動速度が出ていないと進行方向が出てこないので、自車の方位は地磁気コンパスなどを用いるほうがよいであろう。
地磁気コンパスについても、そのうち記載できれば良いと思っている。
詳細は「NMEA 0183 フォーマット」として検索していただければよい。
参考までに、持っているNEO-M8Nのファームウェアのバージョンは2.01であった。u-bloxのホームページには3.01のファームウェアも公開されており、アップデートすることは可能である。ただ、やみくもにアップグレードするのも注意する必要がある。3.01では機能アップもされていることながら、生データが出力しなくなっている。ファームウェアのイメージがあれば、2.01、3.01を行ったり来たりできるので大丈夫である。