u-blox ZED-F9PとDrogger VRSCを用いたCLAS測位
はじめに
RTK(reltime kinematic)によりセンチメートルオーダー測位を行うためには、緯度、経度、楕円体高の既知な基準局にて観測したGNSS(global navigation satellite system)信号観測データが必要になります。みちびきから放送されているCLAS(centimeter level augmentation system)情報を用いれば、日本国内に限定されるものの、この事実上の基準局(VRS: virtual reference station)データを作り出すことができます。しかしながら、CLASを利用するためには、RTK機器に加えて、現在ではまだ一般的ではないL6周波数帯の受信機、アンテナ、CLASデコーダ、CLASソフトウェアが必要になります。
2021年2月末に発売されたビズステーションのDrogger VRSC(VRS by CLAS)は、これらをパッケージ化して、そのVRS観測データを作り出すハードウェアです。これに加えて、搬送波位相の出力できるGNSS受信機、RTKLIBなどのソフトウェアがあれば、特定のRTK基準局に頼ることなくRTK測位を行えます。VRSCは、L6信号を受信できるアンテナつきで税込み54,780円と安価です。
このVRSCは、ビズステーションのRWP受信機やDG-PRO1RW(S)受信機と組み合わせて利用することが前提になっていますが、動作に必要な情報はテクニカルガイドに公表されています。ここでは、その情報をもとにして、u-blox ZED-F9PにてVRSCを利用しました。
実は、東京海洋大学の高須先生はVRSCがすでにVRSCとZED-F9Pとの接続実験をされています。私は、今になって、やっとできました。その詳細をまとめました。
機器のセットアップ
ZED-F9Pの設定
私は、VRSC本体、u-blox ZED-F9P、スプリッタ、Raspberry Pi 3、Windows 10 PC、Androidスマートフォンを用意しました。Raspberry PiとWindows 10 PCには、RTKLIB 2.4.3b34をインストールしました。Raspberry Piは有線ネットワーク接続しています。また、Windows 10 PCにはu-bloxのu-centerをインストールしています。Androidスマートフォンには、Drogger VRSCをインストールしました。Androidスマーフォンは必須ではありませんが、バージョンアップや確認のためにあると便利です。
VRSCを利用するためには、ZED-F9PのRXM-SFRBX
メッセージと、NAV-PVT
メッセージをNTRIP形式にてVRSCに送信しながら、VRSのRTCM形式での観測データを受けとらなければなりません。私は、Raspberry PiにZED-F9Pを接続し、RTKLIBのstrstrの双方向モードを用いてリモート設定しました。Raspberry Pi上にて次のスクリプトを実行しています。
#!/bin/bash
#----------
DEV=ttyF9P
PORT=2001
STR2STR=/home/pi/exec/str2str
#----------
$STR2STR \
-in serial://$DEV:230400 \
-out tcpsvr://:$PORT \
-b 1 \
> /dev/null 2>&1 &
-b
はstr2strの双方向(bi-directional)モードのオプションで、出力1番目のローカル2001番ボートからの情報を入力に与えることができます。そこでWindows PC上で動作するu-centerにて、このRaspberry Piにリモート接続します。NAV-PVT
(navigation - position, velocity, and time)を出力するためには、u-centerのView
、Configuration View
、MSG (Messages)
と進み、Message
からNAV-PVT
を探してUSBポートにチェックを入れます。
すぐに左下のSend
ボタンを押します。u-centerでは、毎回、Send
ボタンを押して設定を反映させることが重要です。
次に、Message
からRXM-SFRBX
(receiver mode - subframe extended?)を探してUSBポートにチェックを入れます。RTKLIBをお使いの方のものには、すでにチェックが入っているはずです。同様に、左下のSend
ボタンを押します。
最後に測位間隔を5秒(レート0.2 Hz)に延ばします。ZED-F9Pでは、最小測位間隔を0.2秒(レート5 Hz)にできるので、もったいない気がしますが、仕方がありません。左側のメニューのRATE (Rates)
を探し、Measurement Period [ms]
に5000
を入力して、左下のSend
ボタンを押します。
これらの設定を終えたら、左側のメニューCFG (Configuration)
のSave current configuration
ラジオボタンを選択して、左下のSend
ボタンを押します。ここまでできたら、u-centerを終了しても構いません。
VRSCの状態確認
VRSCに付属のUSBケーブルで電源供給すると、Wi-Fi SSIDVRSC
が現れます。初期パスワードは12345678
です。私は、Raspberry PiのUSBポートからVRSCに電源供給しました。残念ながら、Raspberry Pi上にシリアルポートが見えることはありませんでした。AndoidにてBluetoothデバイスの検索を行うとVRSC
が現れるのでペアリングを行い、アプリDrogger VRSC
からWi-Fiパスワードの変更や、CLASやMADOCAの生データ出力や、ファームウェア更新などを行うことができます。VRSCは、Allystar HD9310オプションCとは異なり、CLASとMADOCAを同時に受信復号ができるようです。
Raspberry PiからVRSCへの接続
Raspberry PiをVRSCのWi-Fiに接続するため、/etc/wpa_supplicant/wpa_supplicant.conf
を次のように設定しました。
country=JP
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="VRSC"
psk="12345678"
}
その後、Raspberry Piを再起動して、Wi-Fi接続を有効にします。ip li
にてwlan0デバイスに192.168.4.2のアドレスが割り当てられていることを確認します。VRSCのIPアドレスは、192.168.4.1になります。VRSCにNAV-PVT
とRXM-SFRBX
を注入しながらRTCMメッセージを受け取るために、Raspberry PiにてRTKLIB str2strを活用します。
#!/bin/bash
#------------------------------------------
IP=192.168.4.1
RPORT=2001
LPORT=9999
STR2STR=/home/pi/exec/str2str
#------------------------------------------
$STR2STR \
-in ntrip://$IP/VRSC \
-out tcpsvr://:$LPORT \
-b 1 \
> /dev/null 2>&1 &
sleep 2
$STR2STR \
-in tcpcli://localhost:$RPORT \
-out tcpcli://localhost:$LPORT \
> /dev/null 2>&1 &
# EOF
結局、3つのstr2strプロセスをバックグランドで実行しています。これで、Raspberry Piの9999番ポートにRTCMメッセージが出力されます。
Windows PC上のRTKNAVIによるRTK測位
VRSCからRTCMメッセージが出力されることを確認するために、RTKLIBのSTRSVRを利用します。
(0) InputにTCP Client
を選択して、OptにてRaspberry PiのIPアドレスとポート番号(ここでは9999)を設定します。Start
を押し、上部にある四角いボタンを押し、解読するメッセージとしてRTCM 3
を選択すると、そのRTCMメッセージを確認できます。
RTCM 1005
(座標)、RTCM 1074
GPS MSM4(観測データ)、RTCM 1094
Galileo MSM4、そして、RTCM 1114
QZSS MSM4が出力されていることがわかります。自宅にてこの実験を行っていますので、RTCM 1005
に私の自宅の座標が設定されています。
次にRTK測位を行います。RTKLIBのRTKNAVIの上部にあるI
ボタンを押して入力ストリームを設定します。ここでは、観測点として、広島市立大学のRTK基準局を選択しましたが、皆様の観測機器、またはこのZED-F9Pを利用することも当然、可能です。
Input Streamの(1) Roverとして、TypeにNTRIP Client
を選び、Optに観測したい機器の情報(Address ntrip.phys.info.hiroshima-cu.ac.jp
、Port 80
、Mouont Point OEM7
)を設定しました。一方、(2) Base Stationとして、TypeにTCP Client
、OptにはRaspberry PiのIPアドレスとポート番号を入力しました。
OptionのSetting 1は次のように設定しました。
項目 | 内容 |
---|---|
Positioning Mode | Kinematic |
Frequencies | L1+L2 |
Elevation Mask | 20 |
Ionosphere Correction | Broadcast |
Troposhere Correction | Saastamoinen |
Satellite Ephemeris | Broadcast |
Satellite | GPS, Galileo, QZSS |
これは電離層補正として2周波観測結果を利用しない設定です。全てのGPS衛星が2周波以上の放送をしているとは限らず、Iono-Free LCではそのような衛星の測位結果が無駄になるからです。他の設定は、RTKNAVIの初期値です。利用できる全ての衛星システムを選択していますが、GPSとQZSSだけ、またはGPSだけにした方がフィックスしやすいこともあります。
Setting 2は次のようにしました。
項目 | 内容 |
---|---|
Integer Ambiguity Resolution | Instanteneous |
Min Ratio to Fix Ambiguity | 2.0 |
これは、1測位データごとに整数値不確定性を解き、Fixと判断するレシオテストを通常の3から2にする設定です。早く収束させるためです。結果は次の通りです。
観測点からこの仮想基準局との基線長は約3.8 kmです。現在のタイプ12を送信するCLASでは、最大17衛星までの信号を作成できますが、常に16から17の衛星信号が作成されました。仮想的に作られた基準局なので、信号強度に意味はありませんが、全ての衛星信号強度が同じであるところが、一般のRTKではあり得ないので、興味深いです。一方、レシオ値が2から40程度の間を変動しています。通常のRTKでは、しばらく動作させるとレシオ値は最大値である999になることが多いですが、たった2 kbit/sの情報で作られた基準局信号なのでこれが限度かも知れません。VRS観測データの更新レートは1 Hzでした。
VRSCの初期値では、NAV-PVT
とRXM-SFRBX
を供給するZED-F9Pの座標が1 km動くたびに基準局座標を更新するようになっていますが、Androidアプリでこの距離を変更することも可能なようです。