7月最終の土日はライセンスフリー無線の運用イベント、SV（Summer Vacation）！自分はいつもどこかしらの山に登って運用するのが恒例になっています。昨年は木曽駒ヶ岳にテント泊で行く予定だったのですが悪天候のためおなじみ浜松市の竜頭山からに切り替え。今年はリベンジだ！・・・と思っていたのですが、SVが近づいてきてもどうにもテンションが上がらない。理由は、頂上山荘のテント場は早いもの勝ちらしいので、確実にテントの場所を確保するには朝イチのとてつもない大行列に並んでバスとロープウェイを乗り継がないといけないこと、それに加えて以前痛めてしまった膝に不安が残ることなど。

膝痛の回避は山に登って膝回りの筋肉を鍛えるしかないらしいので、普段からウェイトを背負って近場の山を歩いています。加えて日々の筋トレでもダンベル抱えてブルガリアンスクワットやワイドスクワットをやってますが、なかなか改善が見られない。そこで、急遽日帰りで行けるところに変更となりました。石鎚山も狙えて混雑回避できるところということで今回は北八ヶ岳の縞枯山に決定！

前日は松本市で友人（無線関係ではない）と会ったあと、炭水化物を目一杯詰め込んで登山口へ。松本市内では突然の雷と土砂降りに見舞われましたが間一髪車に乗ったあとで濡れずに済みました。34℃ほどあった気温が雨とともにみるみる下がり25℃に。気化熱ってすごい。

3:30起床、身支度をしながら夜明けを待ち、空がわずかに白み始めた4:20に登山開始。気温は12℃。さすがにこんな時間から登る人はおらず一番乗りです。

誰もいない真っ暗な山道を歩くのは本当に怖い。大石峠のあたりで「ワァァァァァン」というものすごい羽音が聞こえてきたときにはハチの大群でも襲ってきたのかと肝を冷やしました。どうやらあたり一帯でアブかなにかが飛んでいるようですが、あまりの音量と範囲の広さにドキドキでした。高山に行くと必ずと言っていいほど遭遇するのが大きなハエくらいのサイズのアブみたいな虫。顔の前や身体の周りでずーーーっとホバリングしてますが、アイツはいったい何がしたいんだろうか？

1時間ほどで茶臼山の山頂へ到着。見事な雲海が広がっていました。

市民ラジオで御嶽山移動のマツモトTK304局と交信。富士山頂でオールナイト運用されているとうきょうSS44局にもご挨拶すべく富士山レピータにアクセスを試みるがNG。残念ながら赤岳に阻まれているようです。

茶臼山から見た縞枯山。文字通り縞状に木が立ち枯れているのが分かるでしょうか？

茶臼山を早々に後にし、登り返して縞枯山へ。

登山口から1時間50分ほどで縞枯山山頂に到着しました。山頂はほんとにここ？ってくらい何もない。ただの獣道です。

あとから他の人に教わって初めてテープの表示に気づきました。

天気は快晴、全くの完全無風という最高の無線日和！

八ヶ岳の主峰、赤岳から南ア、中ア、御嶽山、そして北アまで雲海に浮かんでいます。

市民ラジオは違法の被りがなく、運用中はEsも発生しなかったようで存分にグランドウェーブの交信が楽しめました。ただ、時折ロシア局（？）が強烈に被ってくるのはまいった。スタンバイピーがピョロピョロ鳴ってました。そのせいで遠方から呼んでくださったのにどうしても聞き取りきれずロストしてしまった方が多数。。。耳悪くて申し訳ありません。

CQが落ち着いてチャンネルを回すとZX9局がフクオカAB182局と100mWチャレンジしている！残念ながらこちらではAB182局の声は聞こえず。コンディションが下がったのか、場所が悪いのか、リグが悪いのか。100mWチャレンジの前はもっと強く聞こえていたそうなので、その時にこちらでも聞ければよかったのだけどタイミング悪かったなぁ。石鎚山狙うならやはりポータブル機担いでアルプスか富士山行かないと厳しいかな。八ヶ岳も谷間を縫っていけそうな気がするんですが。

8:00からロープウェイが動き始めるので混雑する前に下山。苔が生えた岩が濡れていて超スリッピーで疲れました。

1時間半ほどで駐車場着。気温は25℃。涼しくて快適です。下界におりたくないなー。日帰り装備、しかも無線機はハンディ機と特小各1台という超軽量装備、加えてZAMSTのサポーターを装着しているにも関わらず下山では膝痛が。。。もうテント泊は厳しいかなぁ。

温泉で汗を流したあとはテンホウに行くかそれとも蕎麦を食べるか迷いましたが、天ぷら蕎麦が食べたくて蕎麦屋へ。ところが行く先行く先全て駐車場が満車。5〜6件回った末、もう諦めてコインパーキングに入れて徒歩で蕎麦屋へ。ところがタッチの差で天ぷら売り切れ。。。仕方なく肉そばにしたら肉よりはるかにネギがモリモリで大ダメージをくらいながらの帰宅となりました。

＜交信ログ＞ 間違い等ありましたらお知らせください

市民ラジオ　ICB-870T　茶臼山から

0524　マツモトTK304局　57/59　御嶽山

市民ラジオ　ICB-870T　縞枯山から

0611 　カナガワZX9局　58/58　南アルプス仙丈ヶ岳

0615　ながのCW47局　52/53　群馬県渋峠

0622　カナガワCU64局　52/52　山梨県南都留郡鳴沢村

0626　みやぎFS43局　53/52　茨城県筑波山子授け地蔵

0627　すわOL38局　55/55　長野県高ボッチ

0629　ナガノAA601局　57/57　長野県高ボッチ

0634　サイタマST165局　55/55　茨城県筑波山子授け地蔵

0636　ニイガタAZ21局　53/55　長野県飯山市大神楽展望台

0639　トチギAA997局　58/58　山梨県山梨市北奥千丈岳

0641　ツバメTK113局　51/51

0645　アイチAC556局　51/51　愛知県知多郡南知多町

0647　ぐんま5424局　59/59　物見岩（岐阜県恵那市？）

0648　トチギTH927局　53/55　栃木県大田原市

0649　イバラキAB399局　53/55　茨城県常陸太田市

0651　サカイYU927局　53/53　三重県伊勢市大湊

0705　ニイガタAA462局　51/52　新潟県佐渡市ドンデン山

0718　フクシマSP302局　52/52　立山連峰

0806　ナガノNP159局　56/57　長野県駒ヶ根市

0809　ナガノBN6局　55/59　長野県伊那市鳩吹公園

0811　グンマTK429局　55/54　群馬県みどり市

0813　ニイガタMS763局　51/51　新潟県佐渡市白雲台

0816　ニイガタYS112局　41/53

0820　つくばKB927局　58/59　茨城県筑波山

0825　グンマCB17局　59/59　長野県佐久穂町麦草峠

0827　おおさと59局　58/59　群馬県赤城山

0830　ツクバA3局　56/56　茨城県つくば市宝篋山

0833　ニイガタHR660局　54/55　群馬県横手山

0835　イバラキVX7局　51/53　栃木県栃木市渡良瀬遊水地

特定小電力無線　ALINCO DJ-P221L　縞枯山から

0736　マツモトTK304局　M5/M5　御嶽山

0744　ナガノAA601局　M5/M5　長野県高ボッチ

0749　すわOL38局　M5/M5　長野県高ボッチ

0753　カナガワZX9　M5/M5　南アルプス仙丈ヶ岳

0803 　ナガノ KH314 局　 M5/M5 　長野県高ボッチ

前回の記事 をXにポストしたところ、多くの方々からアドバイスをいただきました。ありがとうございます。

おかげさまで目的地に近づくと直線距離表示がバグるのはArduinoの計算桁数が不足しているために値が丸められてしまっているのが原因っぽいということが分かりました。たしかに目的地までの距離が近くなるとacos(x)のxの値が限りなく1に近づくので相当な小数点以下の桁数が必要になります。double型にしておけば良いというわけでもないんですね。（Arduinoの場合、double型にしても計算精度はfloatと変わらないそうです）

ハードウェアを計算能力の高いラズパイpicoWに

さて、じゃあどうする？ということでラズパイpico Wを入手。これなら計算能力は充分ある上、Arduino IDEでスケッチをそのまま書き込んで使えるらしい。

初期設定を済ませ、早速書き込み！さあどうだ！？

・・・

・・・・・・

・・・・・・・・・

待てど暮らせどOLEDには一向に距離表示が出てこない。いったんGPSはおいといてOLED単独で動作確認 → 問題なし。GPS単独で通信確認 → 衛星から情報を受信しているものの、一部しか受信（復調？）できておらず、NMEAセンテンスとして成り立っていない。。。シリアル通信は一応できているし、モジュールの受信状態を示すLEDも点滅しているのになんでじゃー

Arduinoに戻る

いったんは心が折れかけたものの、どうしても諦めきれずに調べていると、地球上の２点間の距離を計算する方法が他にもいくつか見つかりました。

１）ハーバーサインの公式

計算式だけでなくC言語のコード例もあったので実装してみましたがうまく動作せず。自分には勉強不足で理解できないところも多々あったので断念。

２）geographicLibというC言語のライブラリ

ナノメートルオーダーという凄まじい計算精度を持つらしい。これがライブラリにあるなんてありがたい！と実装しようとしたのですが、コンパイルが上手くいかず断念。

３）Hubenyの公式

三角関数（sin、cosのみ）を用いた公式なのでやりやすい。式を見る限り、日本国内の緯度経度なら桁数が少なくても計算が破綻するようなことはなさそう。そしてこの手法は無線家にはお馴染み、あの カシミール3D でも使われている手法らしい。ということでコレを実装してみました。

Hubenyの公式を実装

指数の計算等、慣れていないところでミスらないよう回りくどい書き方をしているので非常にダサいと思いますが、以下のように書いてみました。

    double Rx = 6378.137;          // km

    double Ry = 6356.752314;   // km

    double x1 = gps.location.lng() * (M_PI/180);  // 現在地の経度

    double y1 = gps.location.lat() * (M_PI/180);   // 現在地の緯度

    double x2 = 135.00000 * (M_PI/180);             // 目的地の経度

    double y2 = 35.00000   * (M_PI/180);             // 目的地の緯度

    double E = sqrt(((Rx * Rx)-(Ry * Ry))/(Rx * Rx));

    double Dx = x1 - x2;

    double Dy = y1 - y2;

    double P = (y1 + y2)/2;

    double W = sqrt(1-((E * E)*sin(P*(M_PI/180)) * sin(P*(M_PI/180))));

    double N = Rx / W;

    double M = Rx * ((1 - (E * E)) / (pow(W,3)));

    double kyori = sqrt(((Dy*M)*(Dy*M))+(Dx*N*cos(P*(M_PI/180)))*(Dx*N*cos(P*(M_PI/180))));  // 目的地までの直線距離

さて結果は如何に？

おぉぉぉぉ！距離が近くても破綻せずちゃんと表示してる！

試しに近所に目的地を設定してクルマで走ってみると、ちゃんと近づいていく様子が分かる。最後、 数メートル単位まで減っていった ときはシビれました。

よっしゃこれで完成！・・・と思ったのですが、目的地を日本各地に設定してみると場所によっては18%もの誤差。これはいくらなんでも大きすぎる。

目的地までの距離と誤差をプロットしてみるとこんな感じ。この他にも緯度・経度と誤差とか、現在地の座標に対し目的地がプラス側なのかマイナス側なのかとか、いろんな見方をしてみましたが規則性は見出せませんでした。この誤差も桁数まるめの影響なのかなぁ。

三平方の定理

ダメもとで三平方の定理も試してみることにしました。本来は地球の曲率も考慮した距離にしないといけないのですが無視します。地球内部を突っ切って最短で２点間を結ぶ直線の距離になります。地表をなぞった場合と地中を突っ切った場合とで誤差は出ますが、前述のHubenyの公式で発生した 18%の誤差よりはマシ なんじゃないだろうかということで。

三平方の定理を使うにはもう一つ課題があります。それは 緯度経度が直交座標ではない ということ。地球は球体（正確には楕円体）なので、経度１度あたりの距離が北にいくほど短くなります。例えば北海道（北緯45度）では経度1度あたりの距離はおよそ79km、沖縄（北緯24度）ではおよそ102kmです。これを直交座標として扱ってしまうと誤差がかなり大きくなります。

そこで、赤道直下（北緯0度）における経度1度あたりの距離：111.321kmに cos（緯度）を掛けることで緯度に応じた距離を算出する補正 をしてみました。赤道直下ならcos(0°)=1なので111.321km、北極点ならcos(90°)=1なので0kmという具合です。

    double x1 = gps.location.lng();  // 現在地の経度

    double y1 = gps.location.lat();   // 現在地の緯度

    double x2 = 135.00000;             // 目的地の経度

    double y2 = 35.00000;              // 目的地の緯度

    double Dx = x1 - x2;                   //経度の差分（度）

    double Dxkyori = Dx * 110;         //経度の差分（km）

    double Dy = y1 - y2;                   //緯度の差分（度）

    double Dykyori = Dy * cos(((y1 + y2) / 2) * M_PI / 180) * 111.321;  //緯度の差分（km）

    double kyori = sqrt((Dxkyori * Dxkyori) + (Dykyori * Dykyori));      //目的地までの距離

Dykyoriの項で補正を行なっています。目的地と現在地の2地点の緯度の平均値を用いて補正しているので、２点の距離が離れるほど誤差は大きくなります。

さあどうだ！？

Hubenyより誤差が大きい。。。

こちらも誤差の大小に規則性は見出せませんでした。シンプルな計算なので桁数少なくてもなんとかなるかと思ったのですが。

暫定仕様

とりあえず ” 目的地に近づくと表示がバグる ” という最大の欠点は解消できたので一応は使えそうです。誤差が残っているのが気持ち悪いですが、そもそもルートの残距離ではなく直線距離を表示という時点で実用性は無い遊びアイテムなので、暫定仕様としてあちこち遠出するときに使ってみようと思います。気が向いたら誤差改善やラズパイのリベンジをしたいと思います。

ゴールデンウィークに初めて作ってみてバグが発覚してから１ヶ月以上。だいぶ苦しみましたが、おかげでほんの少しだけスキルが上がったように思います。アドバイスをいただいた皆さん、ありがとうございました！