u-centerでの設定 (NEO-M8P-2)

ちょっとu-centerの設定方法という相談があったので、ちょっと思い出してみました。

まずは、u-centerを最新版へ。 昨年はv20でしたが、いまみるとv22なんですねぇ。

v20を惜しみなくアンインストールし、u-bloxのWebからダウンロードしてインストール。

さっそくM8P-2にusbとアンテナを接続し、teratermで認識しているポートを確認。

今回は、COM3でした。

ためしにOKを押して少し様子を見ると、

接続はされている。 文字化けしているが、この辺りはアスキーコードの若い番号も来てしまうので、

御愛嬌といったところです。 ポートが正しいことと、読めていることを無事に確認。

こんなことをしているうちにダウンロードが終了し、u-centerのインストールへ。

インストールとともに、u-centerが起動されたので、tera termを終了してu-centerに

まずは、受信機のコネクションでCOM3を設定。

Packet Consoleボタンを押して

まずは、通信を確認。 位置は把握できていないようですが、衛星はある程度捕まえているので、

ちょっと先に進む。 ここは、テストするには環境が悪く、一部しかダメなんですよね。。。。

こんな感じです。

位置測位を開始していないところが気になるが、どんどん設定に進んでしまいましょう。・

[View]-[Configuration View]-[MSG]

ここで必要とするMSGを定義します。 ここにはいくつかの流派はあるので、自分の思い通りに。。

私は以下の設定。

出力はUSBとシリアルの両方としています。 (一応、、、) UART-2は今回はないので、設定しようとしてもSendした段階で消されてしまいます。

Robot Carで使用するNMEA MessageはGxRMCなんですが、U-Centerで感度やほかいろいろ見るときもあるので、最初はGxGGA,GxVTG、GxGLLも出力するようにしています。 (本番走行前で余裕があったときは、これらを外しています。)

 なので、こんな感じ。 都度、Sendを忘れないように。 一応2-3回チェックしたほうが良いです。

設定したつもりが変わっていないということはよくあること。 気にしない。

そのほかのNMEA Messageは以下の感じで出力しないようにしておく。

ゆっくりした制御なら出力しなくてもよいのですが、できるだけ余分な処理はトラブルの元なの潔く削除。

いつも限界で設定しておくと、トラブったときに、何が、何に関係していたかということがわかるので、それはそれでよしとします。

これが終わったらポートの設定。

左側よりPRTを選択して、UARTとUSBにUBX,NMEA,RTCM3を送受信できるように設定します。

速度は葉や右方が良いので、115200です。 USBで通信するのであれば関係ない。

下記はUART-1の設定だが、UART-2,USBも同じ設定に。 、と、UART-2が設定できなかったので、UART2は無視。

そして、保存します。 (一応保存されるような気もするが)

Packet Consoleを見てみるとGxRMCも出始めました。 よしよしです。

さて、次は、これをどのくらいの周期で出すかという設定です。

毎秒取れればOkという人は不要ですが、早くデータ収集したいという人は、Rateというメニューで設定します。 保存を忘れずに。 この通りにデータが来ると保証されているわけではないです。

サンプルプログラム公開

GPS・QZSSロボットカーコンテスト2020で使用した測位とWaypoint算出に関するソースコードを参考用にUpします。
本ソースコードは「測位航法学会特製 F9P搭載受信機」にも対応しているはずです。

最適ではないのですが、参考になる方もいるかと思い公開に踏み切りました。 もちろん無保証なのと、これによる問題障害については一切責任は負えないので、そのあたりを理解してみてもらえば幸いです。 また、本業が忙しく、コメント・質問などに、答えられない場合があります。


2019年大会はFix率が悪く、走行テストが難航し2回目の走行をキャンセルせざるを得なかったのですが、今年は参考までに以下の対策を講じてみた。 (どれが効果的かというのは感触です。)

-F9PのFarmwareのUpgrade
これはかなり効果があったと思います。
-QZSSの無効化
これも効果があったように感じますが、FarmのUpdate後にL1Sに関する記事を読みL1Sを無効化して再登録。 Fix率は下がらないことを確認した。 L1Sの無効化が聞いたのかFarmware Updateが効いたのかは不明。
-アンテナ背面の銅箔テープによるマルチパス防止
これは気持ちの問題だった気がする。
-ntrip Serverとのアクセス手法
これは効果大だった。制御周期も早いので、制御の合間に数文字程度を読み取って制御側の処理をやっていたが、メッセージ終了までは制御は行わず一気に処理を行った。
-F9P更新周期
F9Pはカタログスペック上20Hzとなっており、51ms(50msが定義できなかった)で動作させた。Logを見るとデータが変更しないときもあるが、最速で見るれ可能性が高いと想定し使ったが、Fixしたのは1-2度のみですぐに設定を戻した。(100mS~300ms)

そのほか2019年では悩んでいたBluetooth通信であったが、ESP32 DevkitをV4にすることで同じソースコードで動作した。試しにV2に戻すと動作しない。 昨年はこれでだいぶん時間を食ってしまったが。 ただ、PC側は毎回削除し、登録している。 この辺はかなり改善の余地がある。 また、Bluetoothを使っていると、たまに処理が止まったり遅くなったりすることがある。情報取得時以外はPC側から接続しないで使っていた。

—–
本ソースコードは無保証の条件で、無償提供し、個人・商用を問わず利用は自由です。ただし、内部で使用されているライブラリなどは、そのライセンス条項に従ってください。

Sample.zip

—–