RTK基準局の座標について考えていたら深みにハマった件

先日、令和8年熊本地震の前後で電子基準点データー提供サービスからダウンロードしたRINEXデーター記載の基準点座標が1mmも変わっていない件と、国土地理院サイトのQ&Aには「正確な値は日々の座標値等を見る様に」となっている事を書きました。
という事で、ちゃんと日々の座標値データを見たところ、色々と分からなくなって深みにハマってしまった記録です。

なお私は測量や地球物理の専門家ではないので、下記に書いている事はRTK基準局への影響を調べていたら気になった事を素人が書いているに過ぎません(何か判断をする場合はちゃんとした人に聞いてくださいね)。

その前に何を気にしているのか

自宅のRTK基準局のアンテナ位置を正確に知るため、3月の時点では自宅受信機で取ったログと電子基準点データー提供サービスからダウンロードした補正値(RINEXデータ)とをRTKPOSTを使って後付け解析しました。 その時RTKPOSTの設定としてBase stationという項目があり、電子基準点熊本の座標を設定する必要があるのですが、この時はRINEXヘッダーから取る様に設定したのです。

実際にはここに何を設定するのが正しいのかを気にしています。
ここに設定する座標が1mずれていたら解析結果もほぼ1mずれるのです。

国土地理院サイトの日々の座標値を見てみる。

という事で国土地理院の日々の座標値ページから電子基準点950465(熊本)のデータをダウンロードしました。そして緯度、経度、高度をグラフ化すると・・・

地震のあった7月28日を境に緯度がはっきり変化しているのが分かります。ざっと0.000001°なので距離に換算すると10cm程度。

そこで地震前の一週間(2026/7/19~7/25)と地震後の一週間(2026/8/1~8/7)の平均値を比べると・・・やや西よりの北方向に10cm程移動していますね。高度については1mm程しか変わっていない様です。
(なお距離への変換は簡易的に行っています。実際には微妙に楕円体の地球を周囲4万Kmの完全な球体として算出。)

950465(熊本)緯度(度)経度(度)高度
7/19~7/25平均32.84210106130.7648065692.086
8/1~8/7平均32.84210198130.7648064392.087
0.00000092-0.000000130.001
差を距離に換算(mm)102.667-11.8691.082

因みに被害が大きかった八代市千丁の電子基準点データを見ると、北にも東にも60cm以上変化しています。合成すると北東方向に87.46cm。 更に高さ方向にも30cm程沈んでいるのでこれも含めると93.19cm変化している様です。
怖いです。

950093(千丁)緯度(度)経度(度)高度
7/19~7/25平均32.54640605130.6456020040.289
8/1~8/7平均32.54641160130.6456086239.967
0.000005550.00000662-0.322
距離(mm)616.984619.907-321.786

という事で、電子基準点熊本のRINEXヘッダ内の座標値は殆ど変化していませんが実際には10cm程度動いているっぽいです。
年のため最新の電子基準点のRINEXデータ、前回取りましたがもう一度9/3時点のを取ってみたところ、やはり最大でも1mmしか変わっていません。(こちらはECEF座標系で単位はmなのでそのまま読めます。)

XYZ
2026/03/18-3502497.82964062727.08233439309.0632
2026/08/11-3502497.83014062727.08263439309.0622
2026/09/03-3502497.83014062727.08263439309.0620

ではRINEXヘッダの座標と日々の座標値の間でどれくらい差があるか

9/3のRINEXヘッダの座標を緯度経度高度に変換(国土地理院のこちらの式使用)すると32.84209962° / 130.7647963° / 92.263mとなりました。
これを先ほどの日々の座標値と比べると・・・1m以上違います。

950465(熊本)緯度(度)経度(度)高度
日々の座標値 8/1~8/7平均32.84210198130.7648064392.087
2026/09/03 RINEX32.84209962130.7647936392.263
差(mm)-262.716-1195.3180.176

うーん。RINEXヘッダ内の基準点座標は’APPROX POSITION ’という事ですし、やはりアテにしてはいけないんでしょうね。
だとしたら日々の座標値の最新値をセットするのが正しいのでしょうか?
でもそれって毎日少しづつ変っていくんですよね。

もう一つ気になるのが「基準点測量成果」

こちらは公共測量や地図作成の際に用いる基準点の座標だそうです。
国土地理院のFAQによると公共測量には日々の座標値ではなくこの測量成果を使うように書かれています)

日々の座標値は文字通り日々変わっていくのに対し、こちらは一旦基準点として座標を決めたら当分は変わらない基準点として扱うそうです。

但し大地震等で大きく変動した場合には新たに決め直すとの事で、正に今回の令和8年熊本地震の影響で8月13日に再設定されています。→https://service.gsi.go.jp/kijunten/app/map/
これ先日の投稿で下記アナウンスがあると書きました。これを書いた時点では良く分かっていなかったのですが、この事だったんですね。
令和8年熊本地震に伴う基準点成果の公表停止について

という事で「基準点測量成果」の座標を見たところ地震後の日々の座標値とくらべても約73cm程ずれています。最新の日々の座標値とほぼ同じ値になるのかと思っていたのですが違う様です(どうやって決めているのでしょう?)。
(なお「基準点成果閲覧サービス」のページに「無断使用は測量法により罰せられる」的な事が書かれているので念のため具体的な座標値は書いていませんが、気になる方は直接見てください)

という事で候補は3つ

電子基準点の座標としてRTKPOSTに入力する値の候補は3つになりました。

・電子基準点データ提供サービスからダウンロードしたRINEXファイルヘッダの値
日々の座標値の最新値
電子基準点測量成果

RINEXファイルヘッダについてはそもそもが’APPROX POSITION’という事なので、これを使うのは良くなさそうです。
日々の座標値を使うのが一番正確そうですが、これは日々変わっていきます(まあ普段はそんなに大きくは変わらないけど)。
電子基準点測量成果を使うと基本は固定ですが現実の値とは異なります。

どれを使うのがベストか、ググってもハッキリ書いたものが見つからないので2人のAIさんに尋ねたところ、どちらも第一候補は「日々の座標値」と答えました。
これ自分的にも一番しっくりきます。そもそもその座標値こそがGNSSで扱う本来の位置で、測量成果の方は人間が取り扱う都合で決めているだけですもんね。
それにもし後から電子基準点測量成果に合わせた座標で測位したくなった場合はその時点で補正すれば良さそうですし。
なお最初から公共測量に使うつもりなら電子基準点測量成果を使うのが良さそうです(が、そういう人はこんなページではなくちゃんとした資料を見られると思いますけど)。
他の一般公開されている基準局はどうやっているのでしょう?

自分なりの結論(どなたか詳しい方、コメントください)

なんか、地震で変動した影響から始まり、それ以前の自宅RTK基準局の座標を出すための基準座標をどうするかでハマってしまいましたが、自分の用途では日々の座標値の最新値でRTKPOSTを動かすのが良さそうです。
と言いつつ、実際のところ現状の(RINEXヘッダー座標で計算した)ままでも、基準局とRoverの位置関係は家の屋根と庭の距離なので相対的な差はなく殆ど気分の問題です。
それにもし日々の座標値から計算し直したら芝刈りwaypointファイルも全部修正する必要があるので、もうこのまま進めても良さそうな気がしています(変更するなら早い方が良いのですが)。

芝刈りロボットへの道 ~試作版の車体製作3~

前回は芝刈りモーターを取付けて実際に芝生を刈り取れる事が確認できました。
今回は電源回りを整理していきます。

これまでの配線

自動走行ローバーに後付けで芝刈りモーターを追加したので、走行系と芝刈り系が完全に分離しており、芝刈りモーターは単にスイッチでON/OFFするだけでした。

構想

・走行系と芝刈り系のバッテリーを共通にしたいので、小型刈払い機(草かるぞう)に元々付いていた18Vバッテリー1個で両方に供給する。
・草刈るぞうバッテリーはマキタ18Vと接点共通なのでマキタバッテリーも使用可となる!
・バッテリー電圧をPixhawkから測定する為に、抵抗で分圧してAD入力端子に入れる。
・バッテリー電流検出機構も後付けできる様にしておく。
・芝刈りモーターのON/OFFをフライトコントローラーから制御する。

あとついでに・・
・方位取得精度を上げたいので外付け磁気コンパスを取付ける。
・重心が後ろ気味なので前輪(駆動輪)がスリップしがち問題への対策。

となると必要な電圧は、芝刈りモーターに18V走行モーターに12VPixhawk他に5V の計3種類となります。

でも考えたのですが走行用モーターは18VをPWMの上限67%に制限してやれば、わざわざDCDCで12Vに下げなくても良さそうですね。
但し前回使用したモータードライバーIC(TB6612FNG)は扱える最大電圧が15Vなので耐圧不足です。定格18Vバッテリーの充電直後は21V程度あるので、少なくともそれ以上の耐圧があるドライバーが必要です。 そこで秋月電子で探すとTB67H450FNGというのがあり、これだと最大定格が50Vでした。 またこのICをモジュール化したAE-TB67H450というのも売られているので、これのモジュールを使ってみましょう。

芝刈りモーターをパワーMOSでPWM制御するのも含め、前回同様のArduino NANOを使って計3個のモーターを制御するESCを作ろうと思います。

回路検討

前回のTB6612FNGとTB67H450FNGとでは制御信号の仕様が異なっています。
TB6612FNGでは動作状態を制御するIN1,IN2とは別にPWM端子があり、1CHあたりデジタル出力2本+PWM1本で制御していました(あと全体を止めるSTBYにもデジタル出力1本)。


一方TB67H450FNGではIN1,IN2に直接PWMを入力する事になります。

という事はモーター2個を制御するにはPWMが4端子必要ですね。
元々ArduinoNANOは最大6本のPWM出力が可能ですが・・・

実はモーター駆動用PWMの周波数は可聴域以上に上げていたので前回はTimer1だけ周波数を上げて、これに繋がるD9,D10端子を使っていました。
今回更に2本の端子を使うとすると、Timer0又はTimer2に接続されているD5,D6,D3,D11の内から選ぶことになりますが、Timer0はシステム内でmillis()等に使われており、Timer2はtone()等に使われているので周波数を変えてしまうと他に影響が出るのです。

こうなると周波数を変えても他に影響しないPWM端子が足りませんね。
ArduinoNANOに拘らずSTM32F103とかに変更すればいいんですけど、できれば前回のプログラムを流用したいのです。
また芝刈りモーターをパワーMOSで駆動するならゲートに3.3Vだと少し心許なく、かといってゲートドライバーを追加するのは面倒という理由もあります。

そこでArduinoNANOとTB67H450FNGの間に下の様なロジック回路を入れてみました。

ArduinoNANOから出すのはPWM値と方向信号です。TB67H450FNGではIN1,2の一方がPWMで他方がHになり、方向信号でIN1,2を切替えます。
実はこの回路で試すと大体は動作しながらも、時々モーターが回転しないことがありました。どうやら起動の瞬間に過電流検出か何かの状態に陥っている気がします。TB67H450FNG異常解除にはIN1,2両方をLにする必要があるのですが上の回路だとこれができないんですよね。

という事で苦しまぎれですが、更にANDゲートを追加しました。
起動直後はGPIOからSTBY端子をLにしておく事で異常を解除できます(と言うか過電流にならなくなる筈)。
ANDゲートは74HC08を使いたかったのですが手持ちが無かったので74LS08を使いました。実際にはこのままだと電源投入の瞬間(マイコンが動き出すまでの間)はSTBY端子がHなのでモーターが一瞬(クッと)反応しており、できればSTBY端子をプルダウンしたいところです。が、LSだと結構小さな値の抵抗になるので現状プルダウンしていません(マイコンが動き出せば直ぐにSTBY状態になるので大丈夫だとは思いますが)。

芝刈りモーター制御

芝刈りモーターは逆転する必要がないのでパワーMOS-FET 1個でPWM制御します。
実際にはほぼフル回転で使うのでPWM周波数にはこだわらずD11端子を490Hzのまま使っています。サーボ信号入力が1000~1400msは停止、1600~2000mSで回転とし、回転開始/停止時はArduinoNANOのプログラムで等加減速制御としました。

芝刈りモーターを起動するとArduinoがリブートしてしまう問題発生

RC送信機から芝刈りモーターをONにするとArduinoがリブートする現象が発生したので
ゲート抵抗を1KΩとしました。1KΩは結構大きい気がしますが当初の100Ωだと効果が無かったのです。本当は100Ωと1KΩの間の丁度良さそうなところを調べるべきでしょうけど、1KΩでもゲート容量をざっと1000pFとするとCR時間は1μSなので、PWM周波数490Hzの周期は約2mSもあり影響は少ないと思います。

という事で現状の回路図

今の所こんな回路図です。
バッテリー電圧検出は18KΩと3KΩで分圧。電流検出回路はまだ実装していません。

基板の写真・・・
最後に追加したAND回路はユニバーサル基板を空中配線しています。
左下のスペースに電流検出回路を取り付ける予定(今は太線で直結状態)。

バッテリーはAmazonで¥999で売っていたマキタ18V用コネクタ(ソケットと呼ぶのかな?)で接続します。

ついでに磁気コンパスを外付けしたい

前回走らせたとき、Missionplannerに表示される車体アイコンが走行方向に対して微妙に角度がずれた状態で直進しているのが気になりました(ドリフトしながら直進している様に見える)。  また特定の場所にくると次のウェイポイントに向かう角度が定まらず時間がかかったり止まってしまったり。。。
コンパスをキャリブレーションしてもまだ怪しい感じなので外付けコンパスを追加してなるべく地面やモーターから遠い位置に取り付けたいと思います。

使った磁気コンパスはQMC5883LというAliexpressで300円程で買った基板で、かつての定番HMC5883Lに似ているけど微妙に違うセンサーです(HMC5883Lは廃版になっているらしい)。

QMC5883LモジュールはI2CでPixhawkに接続するだけでMissiponplannerを開いたら認識されていました。 設定画面でこちらのセンサーの優先順位を上げてキャリブレーションをやり直したのですが、暫く使っていると磁気コンパスの不一致的なエラーが出てきたので内臓コンパスは止めました。

もう一つついでに全体の重心を前に移動。

これまで時々車輪が空回りしていました。たぶん重心が後ろ気味だった為に前輪(駆動輪)の荷重が小さかったのが原因と考えて、少しでも前に荷重をかける為にGPSアンテナとその支柱を前に移動しました。
外付け磁気コンパスはGPSアンテナから離したかったので車体後部に載せますが、軽くするため塩ビパイプで支柱を作りました。

これでスリップによるスタックはほぼなくなりましたね!!

という事で現状のブロック図

では実際に芝生を刈ってみます。
一気にやるのは不安なので2分割した経路をつくって・・・

航空写真とRTKで取った座標は微妙にずれていて、実際の経路は写真に対し少し右側になります。

動作前の庭の状態は1週間程前に手作業で刈っており、奥の方はまた雑草が伸び始めています(手前側は何度か試走したので刈れている)。

刈り込み前

刈り込みの様子を動画で・・・

刈り込み終了後

刈り込み後

向きを変える時にしばらく考え込むとか、刈り込みラインとラインの間に少し残るとか、まだ問題はありますが何とか動き始めました。
何より猛暑の中を自分で歩き回らなくて済むのがいいです。

この後は・・・

現時点で最低限の自動刈り込みは出来たのですが、実行する為にPC側でMissionplannerを動かしたりRC送信機でスタートを掛けたり(ヤバくなったら止める目的もあるけど)と色々手間がかかります。
安全性も含めてもうちょっと簡単に稼働できる様にしたいのですが、それにはArdupilotだけだと厳しくなってきたのでコンパニオンコンピューターを積み、そっちで色々プログラムしたいです。
と言っても経路は固定なのでROS2を動かすほどでもなく、ラズパイ上のpythonで制御するのがいいかなと思っています。
これにはRaspberry pi ZERO2Wあたりが小型で積みやすいのですが、今なぜかどこも品薄なんですよね。秋月電子では11月入荷予定となっているしAliexpressだと1万円以上の値段で売られています。 という事で手持ちにあったRaspberry pi3でやってみて、ZERO2Wが手に入る様になったらその時点で考えようと思います。

令和8年熊本地震のRTK基準局への影響

先日の7月28日に大きな地震が発生しましたが、自分や家族は無事です。
10年前(2016年)の地震では屋根の瓦が落ちて修理が必要だったり雨漏りしたりと色々ありましたが今回はそこまでの被害はありませんでした。

自宅のRTK基準アンテナの座標が気になる

なのでこうして呑気にブログを書いていられるのですが、ひとつ気になっている事があります。
それが先日稼働させたRTK基準局の座標は影響ないのか?」です。
これまた呑気な話題ですみません。

報道を見ていると断層が数10センチとか1m以上ずれたという話を聞きます。
Cmレベルの測位をするのに基準が大きくずれたら影響しそうですよね。

国土地理院の電子基準点

以前自宅のアンテナ座標を調べた時国土地理院の電子基準点のデーターを貰いましたが、地震後に公式サイトを見ると下の様に基準点成果の公表停止とのアナウンスがありました。
令和8年熊本地震に伴う基準点成果の公表停止について

そして地震後間もない頃にデーター提供サービスの地図を見ると赤色表示の基準点も見られましたが、今見ると全部緑色になっているのは復旧したって事なんでしょうかね?

※2026-09-07追記
これを書いた時点では良く分かっていませんでしたが、「基準点成果」というのは公共測量等に使う基準点としての座標で、この公表を一旦停止したという事みたいです。
8月14日に改訂版が公開されています。

電子基準点の位置は変わっていなんですかね?
熊本局のデータをダウンロードしてRINEX形式のファイルヘッダを見ると下の様な行があります。これECEFという地球重心を原点とする座標で電子基準点の位置を示しており、単位がmなので、3月のデーターと比べて最大でも1mmしか違いがない様に見えます。

今回(8月11日):
-3502497.8301 4062727.0826 3439309.0622 APPROX POSITION XYZ

前回(3月21日):
-3502497.8297 4062727.0823 3439309.0632 APPROX POSITION XYZ

※但し国土地理院サイトのQ&Aにはこういう記載があり、正確な値は日々の座標値等を見る様にと書かれているので正確にはそちらを見るべきでしょうけど。

※2026-09-07追記
日々の座標値を見て色々とハマった件を投稿しました。
https://www.hoihoido.com/blog/rtk_and_rover_4/

とにかく再測定してみた。

前回同様、自宅アンテナの座標を調べてみます。
2~3時間データーを取り、電子基準点熊本局のデーターをダウンロードして座標を求めたところ下の様なプロットで、FIX時の座標を平均すると・・・
前回と比べて緯度:-22.1mm経度:+5.3mm高度:-10.6mmでした。


まあ誤差範囲でしょうし、少なくとも自分の用途では問題ないです。

芝刈りロボットへの道 ~試作版の車体製作2~

前回の続きです。
車体に芝刈り用モーターと回転刃を取付けます。

まず現状の車体はこれ。

そして先日購入した小型刈払い機「草刈るぞう」をバラしてモーターより下の部分を取付けていきます。

ニシムタで¥3999だった「草かるぞう」くん

芝刈りモーターと回転刃物の取り付け

まず「草かるぞう」の蓋を開けるとモーター部分はこんな構造になっていました。
モーターの中にファンが見えているので、ここから空気を排出するのだと思いますが、吸気はどこからするのでしょう?

モーター上下に吸い込み口らしき穴がありますが下側(刃を付ける側)はプラスチックの筐体でほぼ塞がれています。コイルはファンよりも下ですが、上側から吸うだけで冷えるのかな?

とにかく取り付け方法を考えましょう。
モーターを車体裏側に固定する為、鉄板や平棒を切ったり溶接したりしてこんなブラケットを作りました。

そしてモーターを取り付けて・・・

なお、この「草刈るぞう」には刃物としてプラスチック刃、ステンレス刃、チップソーの3種類が付いています。

刃物3種を重ねたところ

どれが最適か分からないのでまずはステンレス刃を取付けてみます。
固定用のプラスチックパーツと金属パーツで刃物を挟み込む構造です。
(※ここのネジは逆ねじになっています)

ここで車体の裏側に取り付ける為に位置を合わせてみたところ、後輪に当たることが判明。
前進している時は良いのですが、後退時はキャスターが刃物に近い側を向くので当たってしまいます。

キャスター部分だけ後ろにずらす事も考えましたが、結局本体の合板をサイズアップして新たに切り出し、全部の部品を乗せ換えました。
これで刃物も当たらなくなり搭載完了。

芝刈り用バッテリー

芝刈り機構のバッテリーは当面「草刈るぞう」付属のバッテリーパックを使用します。
また最終的にはPixHawkからの信号でモーターを制御したいですが、とりあえず適当なスイッチを載せて手動でON/OFFします。
でも丁度良さそうなスイッチが手持ちになかったんですよね。。。そこでスイッチ代わりに使ったのがこれ、サーキットブレーカー。(こんな用途につかって大丈夫なんですかね?まあ20Aも流せるはずだし。)

ところでこの草刈るぞう君のバッテリー、マキタ18Vバッテリーと接続部分が互換である事に気づきました。これは何かと都合が良いです。

左が草刈るぞう、右がマキタ(互換品)。

いよいよ芝を刈ってみる

という事で芝刈りを試せるところまで来たので早速やってみます。
庭はもう芝生というよりも雑草が伸びすぎていて結構厳しそうですけど。

やってみると・・・それなりに刈れていますね。

車体が走った軌跡がはっきり分かります。


ところがモーターの軸周りに長めの草が絡みついていました。

刃物取付用プラスチック部品を取り外すとこんなに巻き付いています。

これは何か対策が必要ですね。ある程度予想していた事ではあるのですが。

なお「草刈るぞう」のオリジナルの構造ではこういうカバーの中にモーターが入っています。このカバーと刃物取付用プラスチックとで草の侵入を防いでいる様です。

ではこれに似たカバーを作って側面をガードしてみましょう。
Fusion360でこんなのを描いて・・・

3Dプリントして取り付けました。

これでかなり良くなりましたね。

という事で・・・

草が伸び切ったところは無理ですが、一度刈り取ってしまい、伸びた分だけ頻繁に刈る様にすれば大丈夫だと見込んでいます。

あとは電源回りをマキタ系バッテリーに一本化したりPixHawkから芝刈りモーターを制御したり、そのあたりを作っていきます。
その後ですが、自動走行のパラメーター調整や、現状だと手放しで芝を刈らせるのはまだ不安があるので、諸々の安全対策をしていこうと思っています。

スマホ変更2026

2週間程前にスマホを変更しました。
割とどうでもいい話題なのですがブログに書いておくと後々調べやすいのでここに書きます。

機種はAQUOS sense9で、シャープ製。
これまで使っていたのはXPERIA AceⅡという新品で2万円もしなかった機種です。特に速度が必要なゲームをする訳ではないので機能的な問題は無かったのですが、だんだんと動作が遅くなってきました。
もっと前の機種の様に、「電話がかかってきているのにスマホが遅すぎて電話に出られない」という程ではありませんが、既にアプリを立ち上げるのに数秒から数十秒を要するという状態になっており、カメラアプリを起動して写真を撮ろうとすると大抵はシャッターチャンスが過ぎ去っていました。

前の機種は丁度5年間使ったことになります。こんな安物の機種を5年間使う人は少数派だろうと思いますが、何故もっと早く更新しなかったのかと言うと、セコイ、面倒くさいという事実の他に、最近の機種はサイズが大きい物しかないという問題があります。

買い替える度にサイズが大きくなっており、もっと丁度いいサイズのが出ないかなと思っている内にどんどん時間が過ぎていったのです。ですが遂に諦めて選択肢の中で一番小さいのを購入しました。でも前のと比べると写真の通り。
左が今回購入物、右が今まで使っていた物。

新しいのを使ったところ動作は快適ですが、やはり大判なので持ち運びが不便なのです。

芝刈りロボットへの道 ~試作版の車体製作~

熊本は梅雨も明け、今年も地獄の暑さが続いております。
庭では芝生も雑草もすくすく育っており、何とか楽して芝生を刈りたいという理由でモチベーションも高まり、芝刈りロボットの製作を進めています。
(でも完成する頃には涼しくなっていそうだなぁ。来シーズンには役に立つのか?)

という事で、今回は芝刈りの前段階としてArdupilotを試作ローバーに載せて制御するテストを進めます。

全体の回路はこんな感じ。

フライトコントローラーであるPixHawkを中心に、GPS受信機モーター、ESCDroneBridgeを載せているのはこれまでの投稿に書いた通りです。
そこにRC受信機、安全スイッチを載せ、電源は3セルリポおよび以前製作したMP1584のDCDCコンバーターを載せています。

バッテリーは3セルなので定格11.1V。これをモーター電源(定格12V)とし、更にDCDCコンバーターで5Vに落としてPixHawkに供給します。
バッテリー容量は今の所600mAhですが、芝刈りモーターを回す段階になったらもっと容量の大きなものに変更する予定です。

車体(試作版)を作る

塗装合板を適当なサイズに切ったものをベースにして各部品を載せていき・・・


前輪(駆動輪)は合板を丸く切った板に3Dプリントしたハブをねじ止めしてモーターに取り付けます。合板だけだとスリップしたので(当たり前ですよね)初期の頃3Dプリンターで使っていたタイミングベルト(5mmピッチ)をボンドG17で貼り付けました。

その後、コイツも滑るので止めました。

後輪はキャスターです。もうちょい径が大きい方が良さそうですが、まずはお手軽なヤツで。。。

後輪はキャスター1個(方向変えれるやつ)

電気的なパーツはテープでベタベタ貼って搭載。
モーターの影響か、PixHawkの磁気コンパスが異常値を出したので段ボール等で高さを稼いでいます。またGPSアンテナも低いとRTKがFIXし難かったので角材の上に載せました。

走行テスト。

何度か走らせたところ、駆動輪にタイミングベルトを貼り付けた事でスリップは減ってはいるのですが、それでも時々滑って進めなくなります。
そこでクローラー(キャタピラ)の使用を考えたのですが手ごろな価格で入手できるものが見当たらないんですよね。 何とか自作できないか(蝶番をつないだりとか)考えましたがいい方法が思い浮かびません。

という事で駆動輪の径を大きくし、幅も30mmに広げた車輪を3Dプリントして幅広のタイミングベルトを貼り付けて試します。

これはFusionで描いた図

これでかなり走破性は上がりましたね!!
なんか赤色のホイールがイイ感じでもあります。電装回りはまだテープだらけですが。

改良版駆動輪を取り付けたところ

MissionPlannerでウェイポイントを設定して自動で走らせる

庭にウェイポイントを設定して走らせたところ、初期設定のままだと結構大回りになってしまいました。
そこでMissionPlannerのシミュレーションモードで走らせたところ、これでも大回りをします。
シミュレーションの段階で思った動作をしなけりゃ実車でもまず無理ですよね。

シミュレーション上で自動走行した軌跡。だいぶ大回り。

という事でここからはシミュレーションモードで確かめながらArdupilotのパラメーターを色々と変更していきます。

パラメータ調整

結果ですが、Ardupilotのパラメーターの内、関係しそうな下記を変更しました。

WP_RADIUS
これはウェイポイントにどこまで近づけば到達したと判断するかというパラメーターなので、デフォルトの3mだと芝刈り目的では遠すぎます。
折角RTKで測位しているので、ここは0.1mに変更しました。

WP_PIVOT_ANGLE
進行方向と目標方向の差が指定した角度を超えていたら車体をその場旋回させる設定らしいです。車体の構造が左右の回転差で向きを変えるskid式なのですが、これがデフォルトの0だとその場旋回してくれないそうです(少しはやっているように見えるのが謎ですが)。
5度より大きな値をセットしないと無効という事なので6度に設定。

WP_SPEED
ウェイポイントに向かう時の速度設定。
0.5m/Sに設定しました。もう少し遅くても良いかもしません。
(実はこれは前の段階で設定していた)

CRUISE_SPEEDCRUISE_THROTTLE
目標の速度とその速度を出すのに必要なスロットルの初期値。
ローバーはCROUISE_SPEEDの巡行速度を目指してまずスロットルをCRUISE_THROTTLEの値に設定し、その後CROUISE_SPEEDに合う様に微調整するそうです。
0.5m/S、50%としました。
なおウェイポイントを巡回する時はWP_SPEEDの設定値が優先だそうです。その場合のスロットルはどうやって決めるのかという疑問があるので、まずはWP_SPEEDとCRUISE_SPEEDを同じ値にしておきました。

ATC_DECEL_MAX
減速の制限値。デフォルトの0にしておけば加速の制限値と同じになるそうですが、シミュレーターでは何故か行き過ぎる現象が出たので2m/SSに変更しました(実車では改めて試す必要がありそう)。

PSC_POS_P
経路外れ時の補正強度。(多分PはPIDのP)
シミュレーター上ではかなり大きめの値にしないと最短ラインから外れ気味だったのでデフォルト0.2に対し1.0に変更しました。これも実車では再調整が必要そうですね。

他にも調整すべき箇所がありそうですが、これでだいぶマシになりました。

上記パラメーターを変更してマシになった走行の様子。。。

芝刈り機構検討

実車でのパラメーターはまだ調整中ですが、並行して芝刈り機構の搭載を検討しています。
当初はリサイクルショップで電動芝刈り機を買ってくる事を考えていましたが中々手頃なものが見つかりません。

そして行き着いたのがこれ。アルミスの「草かるぞう」という名前の小型電動刈払機です。
(最初「アルテミス」かと思ったら「アルミス」でした)
これ近所のホームセンター「ニシムタ」のセールで3999円で売ってた物です。
Amazonとかで見るよりかなり格安で、この値段ならヘタに中古の電動芝刈り機を買ったりパーツを揃えて自作するよりも安くつきそうです。

という事で、新品の「草かるぞう」を買ってきました。バラす前に少し草を刈ってみたところ結構便利です。
このまま使いたくもなりましたが結局バラしてしまいました。

中身はDCモーターが入っていて、電気的にはバッテリーとの間にスイッチがあるだけです。

次回はこれを車体に取り付けていこうと思っています。

芝刈りロボットへの道 ~DCモーター用ESC~

前回まででRTK環境ホストPC⇔フライトコントローラー間の通信ができたので、次は適当な車体を作って庭を走らせてみたいです。
と言うか、ツギハギだらけな車体ですが、もう試しています。


駆動方式は、左右の駆動輪をそれぞれギヤードモーターで回転させ前進/後退を行い、左右の回転差で旋回する「スキッド式」と呼ばれる方式です。

ギヤードモーターはだいぶ前にAliexpressで買って放置していたものが2個あり、12V駆動のDCモーターで回転数は60rpm(1秒に1回転)です。

そして意外にちょうど良いのが見つからないのがESCでした。
DCモーター用のESCでラジコン用に売られているものは電圧が7.2V程度を前提に作られており、12Vで使えるものが見当たりません。
という事でESCを作ってみました。

2CH DCモーター用ESCの回路

Arduino NANOと秋月電子のモータードライバ基板AE-TB6612FNGを使うシンプルな回路です。
AE-TB6612FNGは東芝製TB6612FNGを扱いやすい様にDIPピッチの基板に載せたもので、TB6612FNGは最大13.5V/1.2A(ピーク3.2A)のDCモータードライバーを2CH分搭載したICです。
最大1.2Aですが、今回のモーターは定格350mAなので大丈夫でしょう。

回路図は下図の通り。
A-SIGIN,B-SIGINからサーボ信号を取りこんで、MOT-A,Bに接続した2個のモーターを駆動できます。
サーボ信号は昔ながらの方式で、パルス幅1.5mSを中心として±0.5mS変化するヤツです。

キャリブレーション

サーボ信号のパルス幅を読んでモータードライバに駆動方向およびPWMを送るのはArduinoの関数を使えば簡単でしたが、面倒なのはキャリブレーションです。
Dshotと違って昔ながらのサーボ信号だと最大値/最小値が割と適当なのでキャリブレーションが必要です。
市販のESCに良くある、電源投入時に入力信号が最大値になっていたらキャリブレーションモードに入る方式としました。

キャリブレーションは次の様に動作します。

  • 電源投入100mS後の入力信号が1.9mS以上になっていたらキャリブレーションモードに入る。
  • キャリブレーションモードへは各CH個別に入る(CH1のみ、CH2のみ、CH1,2両方等)。
  • キャリブレーションモード中の最大パルス幅を最大値として記録する。
  • キャリブレーションモード中の最小パルス幅を最小値として記録する。
  • 入力信号が1.4mS~1.6mSの間をニュートラルと判断し、この状態が3秒続いた時の値をニュートラル値として記録する。
  • キャリブレーションモードに入っている全てのCHがニュートラルを3秒以上保っていたらキャリブレーションを終了する。
  • キャリブレーションの結果はEEPROMに記録し、次回以降起動時にキャリブレーションモードではなかった場合、この値を読み出して使用する。

ブザー

ArduinoのD3端子に接続した圧電ブザーは次の様に鳴ります。

  • CH1がCALMODEに入った/抜けた時・・・440Hzを1秒
  • CH2がCALMODEに入った/抜けた時・・・880Hzを1秒
  • 各CH最大値/最小値を検出した時・・・・1319Hzを0.2秒
  • 実動作モードに入ったとき・・・・・・・1760Hzを細かく10回繰り返し

プログラム

今回使ったArduinoのスケッチはこれです。

DCESC.zip

製作

手っ取り早く動かしたかったのでユニバーサル基板に載せました。

という事で、走りました。

カブ系エンジン用自動進角CDI ~その5~ 設定ツールアップデート

久々にCDIをいじくりました。
基板化したのとATmega328PBというATmega328Pの後継マイコンを試す、およびUSB-シリアル変換を載せてType-Cコネクタを装備するのが目的だったのですが・・

設定ツールがなぜかダウンしてしまう現象に見舞われました。以前のArduino NANO版でもダウンします。
正常に動作していた頃からの変更点というと、Windowsを10から11に上げた事が絡んでるのかなぁ?

症状

設定ツールとCDIをUSBで接続し、[UP]や[DOWN]等のボタンを押すとツールが閉じてしまいます。
このプログラムはVisualC#で書いておりデバッガーで調べると、シリアルポート(USB-Serial変換IC経由)を読む動作をSystem.IO.Ports.SerialPortReadLine()で実行する時に変な例外が発生していました。
色々試すとReadLine()の直前に1mSの待ち時間を入れると正常動作するんですよね。
何か微妙なタイミングが絡んでいそうです。

修正

とりあえずは1mS待ちの対策でもいいのですが後々不安ですよね。AIさんに尋ねるとReadLine()命令はこういうタイミングの問題に遭いがちという事で、ReadExisting()を使って取り込んだデータをバッファに溜めながら処理していく方法をお勧めされました(AIかしこい!)。

仰せの通りに変更したところ問題なく動作しています。
やっぱりWindows11になった時に微妙にタイミングが変ったりしたのかなぁ?

改訂版公開

という事で、現在上手く動いているのを公開します。

CDI-Configurator1.0.1.zip

改訂版の証としてタイトルバーにバージョン名”Ver.1.0.1.0″を表示しました。


Drone-Bridge for ESP32を使ってみる。

前回RTK基準局を稼働させたので、いよいよ草刈りロボットを検討していきます。
まだまだ道は遠いですが。。。

第一段階としてArdupilotで動作するローバーを作って庭を走らせてみようと思います。これにはPC上で動くGCS(Missionplanner)とフライトコントローラー(PixHawk)との間を何らかの方法で無線接続する必要があります。

色々と方法はあると思いますが、比較的安価なESP32でできないかと調べたらDrone-Bridge for ESP32というのに行き当たりました。

ドキュメントによるとDrone-Bridge for ESP32はGCSとフライトコントローラー間をシリアルブリッジ、無線LAN、ESP-NOW等で接続できる様です。
また動作できるマイコンはESP32,ESP32-C3,ESP32-C5,ESP32-C6が使えるそうなので、手元にあるマイコンボードで直ぐに試す事が出来そうです。

インストールでハマる。

では手始めに手元にあったESP32 Devkit基板に書き込んでみましょう。
ESP32 Devkit基板はこんなのです。(いつだか3枚959円で買った微妙に怪しい基板)。

Drone-Bridge ESP32のドキュメントによるとブラウザーで動作するフラッシュツールを使うと手軽に書き込めるようです。→ https://drone-bridge.com/flasher/
PCとESP32基板間をUSBケーブルで接続してこのURLにアクセスすると下のフラシュツールが現れたので・・・

書込みを試したのですが「Not connected.」と言ってきます。

BOOT-RESETボタンを順番通り押したり、ブラウザーをChrome/Edge両方試したり、基板もPCも交換したけれど変化ありませんでした。

ならばバイナリーをダウンロードしてESPtoolで書き込みをと考えましたが、バイナリーのダウンロード先が見つからないのです。
フラッシュツールは内部でダウンロードしている筈なのでどこかにはあると思うのですが・・・

あきらめてビルドする。

という事でビルドする方が早かろうという考えに至りました。
で、やってみたのですが、こちらも下記の様に色々ありました。

  • ESP-IDFv6.0(この時点の最新)でビルド
    Ninjanpm等が入っていないエラー、日本語パス名が悪さしているらしきエラーが発生。これらは順に解決していったのですが、最後にprotocomm_security1′ undeclaredというエラーが発生。。
    このエラーはChat-GPTさんによると古いESP-IDFのAPIを使っているためで、ESP-IDFをVer4番代に下げろと。。。
  • ESP-IDFv4.4.6でビルド
    →今度はVer5.3以上でやれというメッセージを含むエラー。
  • ESP-IDFv5.5でビルド
    →すんなり完了。

という事で上手くいったビルド手順を整理すると・・・

https://dl.espressif.com/dl/eim/からeim-gui-windows-x64.exeをダウンロードして実行。
インストーラーが開くのでメッセージに従って進んで行き、ターゲットチップ選択ページでESP32に加えて後で試したいESP32-C3を選択。

バージョンのところでV5.5.4を選択。

あとは大体基本通りにインストール。
インストールが完了するとデスクトップにESP-IDF 5.5 PowerShellのアイコンが出来ているのでダブルクリックするとターミナルが現れ、この中で作業すれば一通りの環境が設定済になっています。

ターミナル内で適当なディレクトリ(パスに日本語が無い方が無難)に移動して、まずGithubからソース一式を取ってきます(gitはインストール済みの前提)。

> git clone https://github.com/DroneBridge/ESP32

取ってきたディレクトリの下にあるDroneBridge/ESP32に移動して・・・

> cd DroneBridge/ESP32

ビルドを実行!!

> idf.py build

これでビルドが始まりますが、結構時間がかかりました(PCが古いからか・・・?)。
ビルドが完了したらPCESP32 Devkit基板とをUSBでつないで下記コマンドで書き込みます(COM番号はそれぞれの環境での番号)。
この時、ESP32マイコンが持っているMACアドレスが表示されるので控えておくと後で役立つかもしれません

idf.py -p COM4 flash

設定

書き込みが完了したらリブートするとWi-Fiアクセスポイントモードで立上がります。
つまりPCのWi-Fi設定を開くとDroneBridge for ESP32という名前のWi-Fiアクセスポイントができているので、ここに接続して設定を行うのです。
まず上記アクセスポイントを選択し、パスワード:dronebridgeでWi-Fi接続します(このときWindowsであればインターネットに未接続的なメッセージが出るけど気にせず先に進みます)。
そしてブラウザーでhttp://dronebridge.local又は192.168.2.1に接続すると下の設定画面が現れます。

私の場合、当面は自宅のWi-Fiに接続するので下記の設定に変更しました。

  • ESP32 Mode → Wi-Fi Clinent Mode
  • SSID → 自宅環境のSSIDに設定。
  • Password → 自宅環境のパスワードに設定。
  • UART TX GPIO → 18
  • UART RX GPIO → 19
  • UART RTS GPIO → 22
  • UART CTS GPIO → 23
  • UART baud → 115200

UART信号のGPIO番号は使っているチップ(ESP32,ESP32-C3…)によって制限があります。上記設定は動作していますが、他のGPIOピンを使う場合は公式サイトの説明を読む方が良いです。

再起動後、自宅Wi-Fiに接続するIPアドレスとか・・・

以上の設定が終わったら[SAVE SETTINGS & REBOOT]ボタンを押せばリブートします。動作モードをWi-Fi Client Modeに変更したので既に自宅のWi-Fiに接続している筈なのですが、上記の方法だとDHCPからIPアドレスを割り振ってもらうので何番になるかが分かりません。私の場合はDHCPサーバーのログを見てIPアドレスを調べましたが、書込時に表示されたMACアドレスに対するIPアドレスをDHCPサーバー側で固定する方が良いかもしれません。
もしDHCPサーバーを弄れない場合は地道にpingを投げる等して調べる必要があります。
なおDroneBridge設定画面の[Advanced Wi-Fi Settings]をクリックすると(DHCPを使わず)IPアドレス固定の設定がでてくるので、ここで設定してしまうという手もあります。

DroneBridgeのIPアドレスが分かったらブラウザーで指定して開くと先程の設定画面が(変更を反映した状態で)表示されます。

フライトコントローラーと接続する

DroneBridgeとフライトコントローラー(PixHawkのTELEM1コネクタ)との接続には下記の配線でケーブルを作りました。

PixHawk ESP32(Devkit)
1pin(VCC) V5
2pin(TX) RX(GPIO19)
3pin(RX) TX(GPIO18)
4pin(CTS) RTS(GPIO22)
5pin(RTS) CTS(GPIO23)
6pin(GND) GND

動作確認の為ブレッドボードを使って接続してみます。

ところで私の使っているPixHawkはAliexpress等で比較的安く売られているPixHawk2.4.8と書かれた物ですが、コネクタの型がPixHawkの公式マニュアルにるJST-GHと違ってMolex-PicoBladeでした。
GH買って挿せなかったのでPicoBladeを買い直したのは私です。

MissionPlannerと接続する

ここまでくるとMissonPlannerからDroneBridgeを経由してフライトコントローラーに接続できます。
下図の様にポート選択欄をUDPCIに、通信レートを115200bpsに設定して[接続]ボタンを押します。

すると接続先のIPアドレスを聞いてくるので上で調べた(又は設定した)アドレスを入力し、次にポート番号を聞いてくるので14550(これは固定)を入力して[OK]を押すと接続できます。

ESP32-C3版

Devkit基板+ブレッドボードのままだと引っ掛けて壊しそうなのでちゃんとした形で作り直したいです。
DroneBridgeはESP32-C3もサポート対象になっているので、昨年ラジコンミニ四駆を作った時の基板を流用して実装してみます。

ミニ四駆用RC受信機

この基板は単三電池2本で動作させるため、サーボ電圧用に一旦5Vに昇圧していましたが、このDCDCコンバータは実装せず直接5Vを供給します。またモータードライバーやピンヘッダも不要となります。

これら不要な部品を除外して実装し、電線を引き出してコネクターを取付けました。

Devkit&ブレッドボード式よりもだいぶスッキリした。

配線は次の通りです。

PixHawk ESP32-C3(RCミニ四駆受信機改)
1pin(VCC) 5Vライン
2pin(TX) RX(GPIO0)
3pin(RX) TX(GPIO1)
4pin(CTS) RTS(GPIO21)
5pin(RTS) CTS(GPIO3)
6pin(GND) GND

ハードウェアが出来たのでファームをビルドして書き込みます。

まずESP32-C3用にビルドして・・・

> idf.py set-target esp32c3 build

書き込む為のPCとの接続ですが、ESP32-C3の場合はUSBを直接接続できます(USB-シリアル変換IC不要)。
このあたりの詳細は以前「ミニ四駆をラジコン化 ~その4~ 回路とプログラム」の投稿に書きました。

接続が出来たら下記コマンドで書込みます(COM番号はそれぞれの環境での番号)。

 idf.py -p COM5 flash

ESP32-C3版の設定

ESP-32 Devkit版と同じ様にして接続し、下記設定しました。

  • ESP32 Mode → Wi-Fi Clinent Mode
  • SSID → 自宅の環境に設定。
  • Password → 自宅の環境に設定。
  • UART TX GPIO → 1
  • UART RX GPIO → 0
  • UART RTS GPIO → 21
  • UART CTS GPIO → 3
  • UART baud → 115200

という事で・・・

ESP32-C3にしてコンパクトになりました。製作費も安い(というか全て手持ち部品)ですしね。。。

H3ロケット6号機・・天気は良かったのに熊本から見えず。

本日H3ロケット6号機の打ち上げがありました。
今日も天気が良かったので前回(12月22日のH3ロケット8号機)の様に、熊本からもロケットロードが見える事を期待して職場から見てみましたが。。。

H3F8の時ほどでは無いですが今日も天気は良いです

見えませんねぇ。
今回のH3ロケットは30形態という事で、液体燃料ロケット3基に対しSRB(固体ロケットブースター)は無しという構成です。
H3の液体燃料は水素と酸素なので、ほぼ水蒸気だけが排出されるのだと思います。なので懸念はしていましたが、後で配信の打ち上げシーンを見ても殆ど航跡が見えずに上昇していました。

種子島-熊本間は280Km程あり流石にロケット本体は見えず、煙が見えて初めて確認ができる程度です。 今までの打上げで煙が見えていたのはSRBのおかげだったのですね。

という事で、30形態だと熊本から見るのは厳しいという事が分かりました。

なお、以前の夜間の打上げでは赤くて明るい光が昇っていくのが見えましたが、30形態の夜間だとどうなんでしょうね(やっぱりSRBが無いと夜間でも厳しい気がする・・・)。

なお打上げは成功して衛星放出まで完了したそうです。良かったですねぇ。