2021/04/01〜

....................................................................................................................................

2021/03/31

JAXA, IMPORTANT NOTICE, Rev.3 March 2021

JAXAによるMADOCAリアルタイムプロダクト配信 (参照) は本日で終了。なお、後処理プロダクトは継続して提供されると聞いている。インターネット経由のリアルタイムプロダクト配信は、今後GPAS (参照) に引き継がれるが、商用サービスなので配信料がかかる。競合と考えられる、QZSS L6, Galileo HAS, BDS PPPといった無料PPPサービス、多数の商用PPPまたはPPP-RTKサービスが、開始または予定されているので、どう差別化・事業化していくのかは、まだよく見えないが、とりあえず頑張って欲しい。

....................................................................................................................................

2021/03/27

三神, プライベートシステムとしてのCLARCSの未来, SPACセミナーFY2020, 2021年3月3日

CLARCS (CLAS-based RTK Correction System) はVRSCと同じ様なコンセプトの様だが、F9Pと組み合わせた評価結果がp.8-10に含まれている。TTFFが「数秒〜30秒程度 (CLAS受信機より短い)」とある。どういう条件で評価した結果なのか不明だが、TTFFは、PS-QZSSに合わせて、L6信号受信後FIX解を出すまでの時間の95%値で評価すべきと思う (ヒストグラムをエビデンスとして添付して)。

-------------------------------------

u-blox, u-blox acquires full ownership in Sapcorda Joint Venture, March 18, 2021

u-blox社が、PPP-RTKによる高精度補正サービス (SAPA) を提供するSapcorda社の完全所有権を取得。u-blox社の世界戦略の一環という感じ。SAPAのサービスエリアは今のところ欧州と米国だけ (参照) だが、今後日本を含めた世界中に拡大される可能性もある。

-------------------------------------

u-blox, LEA-F9T

u-blox社がL1/L2/L5帯に対応したGNSS時刻モジュールLEA-F9Tを発表。対応信号はGPS/QZSS L1CA/L2C/L5, GLONASS L1, Galileo E1/E5a/E5b, BDS B1I/B1C/B2a, SBAS L1CA。ただし”configurable L1/L2/E5b and L1/L5/E5a" とあるので、GPS/QZSS L2C, Galileo E5bと、GPS/QZSS L5, Galileo E5a, BDS B2aは排他利用になるのではないかと思われる。GLONASS L2とBDS B2Iのサポートはなくなっている。Tなので従来通り搬送波位相出力はあるがRTK機能はない。同時にZED-F9TのL1/L5バージョンであるZED-F9T-10B (参照) 、L1/L5対応アンテナANN-MB1 (参照) も発表されている。今後、ZED-F9PのL1/L5バージョンも登場するのではと予想する。フォームファクタがZEDからLEAになったので$100以下で販売してくれるとうれしいのだが。

....................................................................................................................................

2021/03/25

muRata, 6DoFジャイロ加速度コンボセンサSCHA600シリーズ自動車用途向け

村田製作所の新6軸IMU SCHA600 (産業用途向け: SCHA63T)。 ジャイロ BI: 0.9°/H (レンジ±125°/s), 1.3°/H (レンジ±300°/s)、RMSノイズ: < 0.007°/s (= ARW: < 0.042°/√H ?) (参照)。プレスリリース (参照) によると量産は2020年12月末なので、そろそろ手に入りそうだが。これ位のIMUと低価格RTKとの統合が、当面の高精度測位技術の主流と予想。といっても今のところ、\10万以下で買える統合デバイスはOpenRTK 330LI位しかないが。

-------------------------------------

OpenRTK 330LI内蔵IMUの安定度 (左: ジャイロ、右: 加速度計)。ジャイロのBIは1.3〜2°/H、ARWは0.15°/√H。IMU383ZAに比較すると少し悪いが、軸毎の特性は揃っている感じ。工場校正値を使ってF/Wで補正を行っているのかもしれない。未だRTKは正常動作しないが、RAW IMU計測値は出力できるのでそれを解析した。

....................................................................................................................................

2021/03/17

GSA, GSA publishes High Accuracy Service information update, March 16, 2021

GSAがGalileo HAS (high accuracy service) に関するinfo noteを発行。内容はあまりないが、今後のロードマップとして、phase 0 (testing and experimantation), phase 1 (initial service), phase 2 (full service) と段階的にサービス展開し、ICD発行が2021年、initial serviceが2022年、full serviceが2024年以降としている。仕様として、全世界対象のSL1 (service level 1) の補強対象はGPS (L1/L5, L2C) とGalileo (E1/E5a/E5b/E6, AltBOC)、水平精度 (95%) < 20cm、収束時間 < 300秒、データ形式は "Open format simular to Compact-SSR (CSSR)"。欧州のみ対象のSL2では補強データとして "atmospheric corrections" が追加され、収束時間 < 100 s となる。

-------------------------------------

u-blox, F9 series Galileo configuration Addressing GAL eccentricity Application Note, February 17, 2021

Galileo E14, E18 運用開始に伴うu-blox F9受信機の動作異常とその回避策。この資料によると、"satellite E14 and E18 oribrts and navigation messages do not comply with the Galileo ICD." とのこと。この原因により "E14 and E18 receiving RTCM3 corrections were being affected."。受信機の症状としては "losing the RTK solution, having NOFIX epochs and jumps / biases in the RTK (fixed) positions." とのこと。細かい原因がよく分からないが、RTCM3 MSMのphase range rateフィールドのレンジオーバで、F9内RTKエンジンの動作異常を引き起こすのであろうか。異常動作回避策としては受信機に対して特別コマンドを送って、E14, E18をdisableにする必要があるとのこと。特定衛星をdisableにするコマンドなんてF9にあったっけ ? と思ったが、どうもUBX-CFG-VALSETで未公開IDを使って値を設定する必要がある様だ。正直、衛星のenable/disable位、コマンドを公開して欲しいものだが。なお、既報 (参照) の様にGalileo E14, E18は2/18からNOT USABLEとされているので、現在は特別な対策をしなくても動作異常は起こさないはずである。

-------------------------------------

InsideGNSS, Human Engineering: Rui Hirokawa's Higher Vision, March 15, 2021

三菱 廣川氏。廣川氏は尊敬するエンジニアの一人。「趣味」の一つがOSS開発とのことで、たまにRTKLIBにPRくれたりもする。

....................................................................................................................................

2021/03/13

Aceinna OpenRTK330LI EVK (参照) が届いたので、ちょっと使ってみたのだけど、とても残念な感じ。RTKはまともに動かないし、どうやってもINS統合が有効にならない。最新F/Wを見つけたので更新しようとしたら、途中でエラーになって起動もしなくなってしまった。オリジナルのバックアップを取っていなかったので元にも戻せない。完全に詰んでしまった。AceinnaのGithub (参照) からF/Wコードをcloneして、F/Wの作り直しを色々と頑張ったのだけど、公開コードを読んでみるとひな型だけで中身がない。ちゃんと動かすためには自分でF/W書けということらしい。それにしてはまともなAPI referenceもない。ということで、今回は完全な「人柱」でした。

補足: AceinnaのForum (参照) には、リカバリイメージどこかにないの ? とは投げてみた。(3/15追記)

再補足: リカバリイメージをメールで送ってもらってST-LINKを使ったF/W (v23.01) リストアには成功。次にAceinna App Center (参照) にアップロードされているGNSS_RTK_INS v23.02へupgradeしてみた。upgrade自体は成功したが、これも正常動作しない。(3/24追記)

....................................................................................................................................

2021/03/11

両面テープ固定では、どうもフラフラして安定しないので、アルミ板でマウントを作って、ビス固定にした。連続運転していたら、いつの間にかADIS Y軸のランダムでないノイズが出なくなった。性能出すためにはIMUにもエイジングが必要なのかも。まあMEMSなので、微小だけど可動部あるしね。

-------------------------------------

InsideGNSS, Development of a Galileo High Accuracy Service (HAS) Algorithm and User Terminal Contracted, March 10, 2021

GSAが、Galileo HAS (high accuracy service) の利用者端末用基準アルゴリズムの開発契約を締結。契約先はSpaceopal (参照) 。Spaceopalは、独 DLR GfR (参照) と欧州 Telespazio (参照) のジョイントベンチャーで、2010年からGalileo運用サービスの主契約者を務めている。Spaceopalは、既にNAVCAST/IONOLABと呼ぶ、PPP用補強情報サービスを提供している。また、NAVCAST 3PRx (参照) と呼ぶPPP受信機や、NAVCAST 3PGo (参照) と呼ぶスマホアプリも開発している、とのこと。

補足: 3PRxはデータシートの写真 (参照) 見るとu-bloxのモジュールを3個載せている。仕様を見る限り、F9PかF9Pの派生モジュールっぽいが。(19:16追記)

-------------------------------------

名城大学, 「戦略的イノベーション創造プログラム (SIP) 第2期/自動運転 (システムとサービスの拡張)」「自動運転技術 (レベル3, 4) に必要な認識技術等に関する研究」自動運転 位置推定技術開発用データセットの公開, 2021/3/11

名城大学 目黒先生の研究で、東京 台場走行による取得データセットの公開。データ内容は、3D LiDAR (Velodyne HDL-32E, 10Hz)、IMU (ADI ADIS16475-2, 50Hz, CSV)、GNSS (u-blox F9P 5Hz, Trimble Alloy 10Hz /, Trimble NetR9 1Hz (base), RINEX)、Pos/Attitude reference (Applanix POS LV 220, 10Hz, CSV)。

POS LVの後処理性能に興味があるので、申し込んでみるつもり。

補足: 申し込んだらすぐに許可頂いた。ダウンロードデータサイズ run1.zip 5.45GB、run2.zip: 3.80GB、run3.zip: 2.29GB。run1.zipが解凍できないのは解凍ソフト (Lhaplus) のせい ? 4GBを超えているので64bit対応でないとダメらしい。Windowsエクスプローラで開いて、コピーすればOK。(19:43追記)

再補足: データ確認したら基準局はTrimble NetR9でした。位置から見るとどうも東京海洋大の局らしい。(22:25追記)

....................................................................................................................................

2021/03/10

ジャイロのAllan Deviation。左がAceinna IMU383ZA、右がADI ADIS16475-1。両者とも、BI (Bias Instability) は1〜2°/Hであるが、軸により差がある。ARW (Angular Random Walk) はグラフ左側のスロープを延ばして、3600秒の所を見ればよい。概ね0.1°/√H。ADISのY軸は時々ランダムでないノイズが入りARWが悪い (0.3°/√H 位)。（Typo: GRYO → GYRO)

補足: 加速度計のAllan Deviation (IMU383ZA, ADIS16475-1)。やはり、これはかなり差がある。(13:33追記)

....................................................................................................................................

2021/03/08

静止状態でのIMU性能を測る。30秒平均でバイアスを推定して、バイアスを差し引いた計測値の積分を計算。ここでバイアスには重力加速度や地球自転角速度も含まれる。左がAceinna IMU383ZA (BI: 1.3°/H, ARW: 0.08°/sqrt(H))、右がADI ADIS16475-1 (BI: 2°/H, ARW: 0.15°/sqrt(H))。30秒後の角度・速度ドリフトが、IMU383ZAが0.0021〜0.0141°と0.00007〜0.00047 gs、ADIS16475-1が0.0026〜0.0079°と0.00006〜0.00078 gs (1 gs = 9.8 m/s)。ジャイロは、両者あまり変わらない感じ。加速度計は、明らかにADISのノイズが少ないが、Y軸のドリフトが大きい (XZ軸は良い)。60km/H走行の自動車にZ軸をYaw、X軸をRollにして乗せるとする。30秒間の角度・速度ドリフトに起因する、慣性航法の水平位置誤差を概算する。進行方向: IMU383ZA 0.00014 x 9.8 x 30 / 2 = 0.021 (m), ADIS 0.00006 x 9.8 x 30 / 2 = 0.009 (m)。横方向: IMU383ZA 0.014 x pi / 180 x 500 / 2 = 0.061 (m), ADIS 0.026 x pi / 180 x 500 / 2 = 0.113 (m)。15秒ならこの約1/4なのでRTKの補償にも十分使える気がする。後は振動の影響がどの程度出るか。これは実際に走行してみないと分からない。

....................................................................................................................................

2021/03/06

移動体RTK性能評価のリファレンス用に、IMUをGNSSアンテナ直下に設置するため色々と工作。IMUはADIS16475-1 (参照, BI: 2°/H, ARW: 0.15°/sqrt(H))。問題はI/FがSPIなので、直接USBでデータをPCに取り込めないこと。ということで、Seeeduino Xiao (参照) を使ってみた。Arduino互換なので、F/WはArduino IDE (参照) で簡単に開発できるし、I/OはSPIを含めて一通り揃っている。何より小さくて安い (参照)。ADISの謎な挙動もあって、3日程苦労して、やっと、100 HzのIMUデータが取り込める様になった。F9PのPPS信号を入れて外部同期もできる。実はこの目的でAceinna IMU383ZA (参照, BI: 1.3°/H, ARW: 0.08°/sqrt(H)) を購入してしまったのだけど、外部PPS信号に同期できないことが分かって、仕方なく、ずいぶん前に買ったADISをジャンク箱から探し出した。とりあえずSeeeduino使えば、色んなデバイスを何でもUSBでPCに接続できそうである。

....................................................................................................................................

2021/03/04

何故、CLASによる測位性能が悪いか探るため、VRSCが出力する仮想基準点 (VRS) データを解析してみる。以下、VRSデータによる基線解の擬似距離及び搬送波位相残差 (左, 上)。比較のため、実基準点データ (基線長6.3km) による基線解残差 (右, 下)。ローバデータは同一 (受信機: mosaic-X5) 、解析はRTKPOSTで、ARはInstantaneous、Min Ratio to Fix Ambiguityを1に設定して強制的にAmbiguityを解いている。見てわかる様にVRSデータの搬送波位相には、実基準点データに比較して5倍以上の大きな短周期ノイズや飛びが載っていることが分かる。2年程前にCLASLIBを使って解析した際にも、同様の傾向が見られたが、未だ改善されていない様だ。CLASの場合、伝送帯域の制限があるので、このノイズを低減可能かどうかは不明だが、このままではTTFFやmiss-fix率を、実応用に足る程度まで改善するのは難しいのではないか。

Pseudorange and carrier-phase residuals of PPK solutions (2021/03/04 11:00-11:59:59 GPST, G17, L1C/A)
(left: VRS data by VRSC (CLAS), right: RRS data by ALES BL=6.3km)

補足: 左図、11:18と11:27の大きな飛びはmiss-fixに起因する可能性がある。(22:14追記)

-------------------------------------

VRSCによるTTFFの評価結果が出たので以下にまとめる。

VRSCは付属アンテナではなく、RTK受信機と同一のアンテナ (Harxon HX-CSX601A) に接続。アンテナLNA電源を周期的にOFF/ONすることにより、入力信号を遮断 (30秒)・通電 (270秒) する。24Hで全288サイクル。信号通電後からRTK受信機が最初にFix解を出力した時間をTTFFと定義して統計を取る。全Fix解のうち、水平誤差35cmまたは垂直誤差70cm以上の解をmiss-fixとし、全Fix解におけるその割合をmiss-fix率とする。miss-fix以外のFix解の水平、垂直RMS誤差を計算する。

全てのRTK受信機で、CLAS TTFF仕様 (< 60 sec, 95%, L6信号受信後, PS-QZSS-002 6.7, 参照) を満足していない。仕様を満足していない原因が、CLAS補強データ自身にあるか、VRSCにあるか、あるいはRTK受信機や設置環境にあるかは不明であるが、このTTFFとmiss-fix率では実応用にはかなり厳しいのではないか。なお、実基準点RTKによる結果についてはこの資料 p.13-14 参照。15 km程度の基線までは、多くのRTK受信機のTTFFは30秒未満で、miss-fix率もほぼ0%なので、現時点では特別な理由がない限り普通のRTKの利用を勧める。

ということで、かなり残念な結果であるが、ある程度予想はしていた。今後、公式の性能評価レポートでCLAS TTFF評価結果が公表されることを望む。

補足: まあ公式性能評価レポートで仕様を満足しない結果が公表される可能性は低いので、結局CLAS自身の性能改善を望む、ということ。(3/5追記)

-------------------------------------

ALESセンチメートル級測位サービス (参照) の問い合わせ窓口に質問していた件につき、やっと回答が来た。ALESとの契約を検討している人にとって重要な情報だと思われるので、以下に質問とALESからの回答を転載する。

[質問]

> 個人ユーザの1アカウントで配信を受けた特定基準局データをいったん受け、個人ユーザが設置したNTRIPキャス
> ターを使って、複数のRTK受信機に基準局データを再配信して、同時に複数点でRTK測位を行う様な利用方法は、
> 利用ライセンス上許されていますか ? ここで、複数のRTK受信機は利用ライセンスを受けた個人ユーザが保有・運
> 用しているもので、他ユーザが保有・運用しているものではありません。その他ライセンス上、制約条件と考えら
> れる利用方法があれば教えてください。

[ALES回答]

> お問い合わせ頂きました件ですが、1件の本ID等を利用して複数のエンドデバイスにわたって同時利用は禁止にな
> ります。
> また、利用規約でわかりずらい記載となっている部分については必要に応じて改定等で改善させていただきます。
> また、その他の利用方法での制約条件につきましては、具体的な例などございましたら、その際ご回答させていた
> だきます。

補足: 「センチメートル級測位サービス」サービス利用規約 (参照)。3/4現在、規約上は「複数のエンドデバイスにわたっての同時利用」は禁止されていない (第37条 禁止行為 に含まれていない) 様に読めるが、多分今後改訂されて、明確化されるのであろう。(12:15追記)

....................................................................................................................................

2021/03/03

VRSCのF/Wをver.1.0.56に更新し、L2Z-track, L5/E5aを有効にした状態での、VRSC (CLAS) - F9P RTK結果。VRSCのWiFiがまだたまに切れるので、切れなかった期間の連続24H分。H-RMSE 4.67cm、V-RMSE 11.06cm、Fix率 96.8%。一部miss-fixと思われる解が含まれ、CLAS仕様を満足していない。

以下、F9P以外を含めた結果。H-RMSE、V-RMSEはFix解のみ。座標基準は前に記した通り。VRSCのL2P(Y) 対応で、若干は改善したが、全般的に実用には厳しい感じ。なお、Trimble BD990, BD982はFixする様にはなったが、まだ、1/3位の期間はRTK FixedにもRTK Floatにもならない。

補足: エビデンスとして各受信機の誤差プロットのリンクを追加。(9:45追記)

....................................................................................................................................

2021/03/01

QZSS, 準天頂衛星初号機後継機の準備状況, 2021年03月01日

QZS-1Rの準備状況。打ち上げ予定は2021年度。衛星バスはQZS-2, 4と共通の様だが、L帯アンテナはヘリカルではなく、QZS-3と同じパッチ方式となる。QZS-1との信号の違いは、L1C/Aが、L1C/AとL1C/Bの切り替え方式に変更になる点と, L5S、L6Eの追加。L6Eは昨日リンクを貼った (海外向け) 高精度測位補強サービスの試行運用に使われる可能性が高い。衛星の設計寿命は15年以上なので、次世代 (があるとすると) の後継衛星打ち上げは2036年度以降となる。

....................................................................................................................................

〜2021/02/28