tripleR 開発日誌

tripleRのプログラム開発に関するあれこれ

skywatcherモータードライブ経緯台とsynscanアプリの組み合わせによるアライメントと自動追尾の仕組み

ケンコーにse-atという架台がある。10センチf4.5のニュートンと組み合わされたse-at100として、以前はamazonのセールで2万程度でよく売られていた。最初に北に向けて北極星(緯度方向)に鏡筒を向けると、以降向けた天体を自動追尾するというのが特徴だったが、この架台はskywatcher(synta)製だった。

モータードライブ付きの経緯台において、北の方向と高度の基準、それと観測地の緯度を情報として与えれば、以降は架台単体で導入した天体を自動追尾することが出来るのは、zeusプロジェクト技術資料における方位軸、高度軸の追尾速度に記述されているとおりで、この機能はse-at架台以来の全てのskywatcher製のモータードライブ経緯台に共通する特徴となっている。


そして、この、北の方向と高度の基準を架台にセットすることがアライメントにおける基本と言える。
(se-at架台は大雑把な人力アライメントを行っていた、ということ)

synscanアプリがアライメントで行っているのは、基本的にはまずこのこと、すなわち、北の方向と高度の基準を定めて架台にセットすることである。

それ以外については、詳細を説明するような資料は存在しないが、例えば、架台の水平が取れていない場合の補正や、架台の水平軸と垂直軸の直交性のズレの補正を行うような仕組みがあるようである。
ここで重要なのは、それらの補正は、あくまで導入時の位置補正であって追尾時には影響を与えない、ということである。
追尾は、アプリとは無関係に、架台側が北の方向と高度の基準情報だけを元にして行っている。
仮にアプリのアライメントで水平の補正が行われたとしても、それが影響するのは導入時だけで、追尾時には何の意味も持たない。

なので、もしきちんと追尾させたいのであれば、アライメントでもっとも重要なのは、どのアライメント方法を取るにせよ、架台部の水平を正確に出しておくことだと言える。

そして、繰り返しになるが、架台の北の方向と高度の基準はアライメント時に決定され、架台側に伝えられる。

なので、電源投入時の架台、鏡筒の向きはアライメント結果には無関係である。
但し、アライメント開始時の鏡筒の北向き、水平の度合いはアライメント星の初期導入精度に関係するので、ある程度正確に合わせておいた方がアライメントが楽になる。
(最初の対象を手動で導入するブライトスターアライメントを除く。それ以外の場合、なぜかアライメント開始時の北向き、水平の指示は2スターアライメントの場合のみ表示される。)
これは手動でもモータ駆動でもどちらでも構わない。

そして設置場所が前回と変わっている場合には、アライメントの最初にリセットを行う。
これも全てのアライメント方法について当てはまる。

同様に、終了時には基本的にどの位置で電源をオフにしても良い。
但し、高度軸のクランプを持たないse-gt,az-go2両架台については、次回鏡筒セット時の安全性を考え、鏡筒を水平にしてから電源をオフにしたほうが良いと思われる。
その設置場所で再度望遠鏡を使う場合にはハイバネートの機能を使えば良い。
ホームポジションは常設や、しばらく天候待ちをする場合に、カレントポジションについては、恐らく電池交換のための電源オフを想定していると考えられる。

架台の自立追尾については、アプリとの接続が切れても、またアプリを終了させても、見ている天体の追尾を続けることから自明のことと考えていたが、自立追尾ではなくアプリ側で追尾に関するパラメータの指示を常に出している、という考え方があることが分かった。
もしそうであれば、(速度計算式から)接続が切れた場合の追尾精度が一気に落ちるはずなので違うと考えたが、これを映像等を使用して具体的に説明する方法がない。
状況に対する合理的な説明の観点から説明を試みたが、アライメントの具体的な補正方法等がブラックボックスである状況では、実際には色々な解釈が可能になる。

そこで、諦めて、実際にアプリと架台との間の通信内容をパケットキャプチャを利用して取得してみた。
架台側で操作をせずに追尾している状況において、アプリから架台への通信は、架台の位置情報を求める'inquire position'(水平軸、高度軸を交互に 具体的にはhexで'3a 6a 31(or 32) 0d')だけであり、架台側からの返信はそれに対する位置情報の通知のみであった。
(詳細はskywatcher_motor_control_command_set.pdfを参照のこと)

この情報はアプリ上での架台の情報表示に用いるためと考えられ、またこのことより、やはり架台側が自律的に追尾を行っていることが確認できた。

パケットキャプチャのアプリケーションについては、android版もいくつか存在するが、信頼性の観点からwindows上のwiresharkを用い、また最近のネットワークがスイッチングハブ中心で、ネットワーク上の他のデバイスへのパケットを見ることが困難なことから、synscan(pro)についてもwindows版を用いて動作確認を行った。

処理方法が説明されておらずブラックボックスとなっているような機能の解析には、様々な立場から動作を矛盾なく説明できるような仮説を立て、実際に見ることが出来る情報からどの仮説がより実際の動作に適合するかをの検証をすることが必要になる。この検証が、skywatcherのモータードライブ経緯台とsynscanアプリの機能に対するより深い理解に繋がればと思う。