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アプリの機能に対するより深い理解に繋がればと思う。

AZ-GTiのアライメント情報はsynscanアプリ側で保持していると考えるのが合理的

# twitterで記述するには重すぎるため、ざっとですがまとめてみました。

アプリをアンインストール&再インストール、またアプリのデータを削除(アプリ管理から)してみたところ、両方の場合共その後アライメント済みの架台に接続してもアライメント情報は初期状態のまま。
また、以前2台の端末を順次一つの架台に接続するテストをした際、2台めでは1台目のアライメント情報は利用できなかった。

勿論、synscanのマニュアルには、違った架台に接続した時にはdefault modelに戻る、とあるのでその作用とも考えられる(新規導入やデータを削除したアプリは過去に接続した架台の情報を持たないので)が、もし架台側にアライメント情報があるのであれば、仕様として接続してきたアプリ全てにアライメント情報を書いてやれば良いだけのはず。
そもそも、違った架台に接続した場合にdefaultに戻る、という記述自体が、アプリ側で保持しているアライメントパラメータを誤適用しないためと考えられる。

経緯台での天体追尾に必要なパラメータは実は少なく、高度、方位、(観測地の)緯度だけあれば良い。また一度追尾を始めれば以降は通信せず自律的に追尾の継続が可能。
zeusプロジェクトの技術資料(経緯台の制御に必要な天文計算)方位軸，高度軸の追尾速度

また導入についても、赤道座標から地平座標への変換をアプリ側で行えば、当然だが架台には方位と高度のみ伝えれば良い。
zeusプロジェクトの技術資料(経緯台の制御に必要な天文計算)地平座標－赤道座標変換

kenkoにはse-at100という安価な望遠鏡があり、このse-at架台は観測地の緯度と北の方向を与えると天体の自動追尾を行うものだが、これにwifiアダプタを経由してsynscanアプリを接続するとアライメント(自動導入)が可能になる。
se-at架台が自動導入を目的としたものではないことを考えると、架台側にはアライメント情報を保持していないと考えるのが妥当ではないか。

そう考えると、AZ-GTi架台は、synscanアプリより伝えられる方位、高度情報に従って天体を導入し、(これだけは保持している必要がある)緯度情報と、(対象天体の)方位、高度情報に基づいて水平垂直方向の追尾速度を随時計算し追尾しているだけ、と考えたほうが合理的に思える。(基本的機能はse-at架台から変化していない)
アライメント情報は、synscanアプリ内で対象天体の赤緯赤経情報を修正するために用い、その修正結果を方位高度情報に変換して架台に伝えている、ということになる。

架台を駆動する直接的なレイヤであるモータコントロールプロトコルにアライメント関係のコマンドが全くないことも、この考え方を裏付けている。

また、これはマニュアルにもあるし誰もが経験していることだが、synscanアプリを停止若しくは接続が切れても、再度起動、接続すればそれまでのアライメント情報を利用した継続使用が可能になっている。
アプリからは自分が停止している間に架台の電源がoffになったかどうか知る手段がないため、ハイバネートを経ない架台の電源off/onがあった場合にも保持しているアライメント情報を破棄することは出来ない。
これが一見悪仕様のように見えるが、再接続性を維持するために必要な処理なので、架台の電源off後はアライメントのリセットを必ず行う以外に方法はない。(こういう仕組みだと考えれば現在の仕様も納得できる。)

以上、正確なところは、架台とアプリとの間の通信パケットをアナライザで直接見てやれば明らかになると思われるが、それ以外の点からはアプリ側でアライメント情報を保持していると考えたほうが合理的に思われる。

この辺り、2年ほど前にlambdaさんと色々やり取りしていたのですが、何故かすっかり忘れていました。また一部の見解をその時から修正しています。

初心者に手動経緯台を勧めるのは間違い

天文を趣味とする人に初心者にオススメの望遠鏡は? と尋ねるとほぼ間違いなく8センチ程度の屈折と手動経緯台の組み合わせを推奨される(らしい?) 屈折には当然賛成(今ならカセグレンでも良いかも)だが、手動経緯台については間違いだと思う。

手動経緯台は上中級者のサブとしてこそ価値があると思う。
手動経緯台を勧める人は、自分が初心者だった頃を忘れているのではないだろうか?

小学校低学年だった頃、星座早見を見ながら星を探したことがある。でも全くダメだった。何故なら実際の空での星座のスケール感が全く掴めていなかったから。
その後、科学館のジュニア天文クラブみたいなものに入って、プラネタリウムで星つなぎを説明してもらい、やっと実際の空で星座を探せるようになった。

これを逆に考えれば、星座のスケール感が掴めていない状態で望遠鏡を手にしても、結局主要惑星(これは形から見えているかどうか分かるから大丈夫)から次のステップには行けない、ということになる。
バックやクランク、縦列駐車等車両感覚のない人が車を運転できないのと同じで、望遠鏡を扱う上の最低限の技能、と言えるのではないか。

手動経緯台を勧めるサイトに、星の位置がわからないと自動導入は使えない(からダメ)みたいに書いてあったが、星の位置がわからないと、結局どんな望遠鏡も使えない(その力を発揮させられない)ということでは?

# 望遠鏡を買う前の段階、ということですね。

その次に問題になるのが、望遠鏡で天体を導入する際のスケール感、だと思う。
幸いにして、望遠鏡で天体を導入したのは、高校で天文部に入ってからだったので、最初の頃は先輩や既に望遠鏡を使っていた同期が導入した天体を見ることが出来た。
どう見えるかの感覚を知っていれば、それ以外の天体に対しても導入することが出来たかどうか判断することができるが、それがなければ、果たして視野中でどのようなサイズで、どのような形で見えるのか分かっていなければ、全く見当違いの場所や倍率で探し続け、結果見つけらなくて、つまらなくて望遠鏡を覗かなくなる、ということになりかねない。

他動導入(身近にいる経験者)がない状況で、自動導入は、頼れる先輩、と言える。

手動導入には他にも初心者にハードルとなる部分が多い。
極地や赤道付近を除き、通常星座は地平線から出てから没するまで角度を変える。星図を見ながら導入するにしても、その感覚が身についていない状況で経緯台を使っての導入はやはり難しいと思える。
(その意味では赤道儀のほうがある意味簡単かもしれない。)

と言うか、確かに星図を頼りに天体を導入する楽しみと言うのが存在するのは認めるが、それを全ての人に強制する必要はあるのだろうか?

天文だけを唯一の趣味として、そこを極めていこうというのならそれもまた良いかもしれない。
でも、そこまで決めていない、若しくは他に趣味のある状況で、毎日夜遅くまで望遠鏡を覗くわけにもいかず、ならば貴重なその時間には、自動導入を頼りに一つでも多くの天体をまずは眺めてみれば良いのではないか。

そこで、気に入った天体やカテゴリが見つかれば、その場所も自然と調べるようになるし、場所がわかった天体ばかり見るのなら、その時にこそ手動経緯台は本領を発揮するのではないか。

できるだけ多くのお店の食べ歩きをしたいのに、最初から店の住所と地図しか渡されないのは間違っているでしょう? 最初は誰かの運転で、若しくはナビを頼りにお店を巡ればよいわけで、お気に入りの店が見つかれば、その頃にはいちいちナビに目的地をセットしたり、誰かに運転を頼んだりすることなく、自分で地図もなく店にたどり着けるようになっているでしょう。
(天体はいくら見てもお腹いっぱいになりませんし。)

プラネタリウムソフトと連携した自動導入もしくは導入アシストは初心者向けではない、というより存在意味すら疑問。
これって、店の地図を渡して、あとは(地図の中で)自分で探してね、というのと同じ。
ナビだったら、店名だけ入れれば後は誘導してくれる。タクシーだったらその店まで連れて行ってくれる。

飛び込み営業みたいに、一軒一軒虱潰しに一般の家を回るんだったら、住宅地図も必要でしょうが、全ての恒星が観望対象になることは(ほぼ確実に)ありません。お店を回るだけだったら、住宅地図なんか不要。略図すら不要。

それじゃ場所が覚わらない、というかもしれないけれど、無理して場所を覚える必要なんてあるんでしょうか。
好きな天体だったら、そのうち星図を見て場所を覚えるだろうし、わざわざ自動導入にプラネタリウムソフトを介在させて手間を増やす意味は全くわからない。
(彗星等特殊な軌道を描く対象を追いかける場合の有用性は当然ながら否定しません。)

地図を見ながら、行きたい場所を探す、それを否定しているわけではありません。
(実際、うちの車、全部ナビは付けていません。)
それは、詳しくない場所に行く機会はそれほど多くないので、せっかくの機会には地図を見ながら、途中の景色を想像しながら現地を訪れたい、という理由であって、もし、毎日違うお得意さんを回らなくてはいけない営業さんだったら、お得意さんのリストを入力したらルートを示してくれるナビがあったら、それを使うでしょう、ということです。

自動導入でも現時点では、その全てでUI(ユーザインタフェース)は初心者向けではありません。

メシエナンバ等を入力すれば導入できるが、空を見て(この雲の様子なら)これが見えそうだな、って星座を飛び越してわかる時点で既にだいぶの経験者では?
重星のカタログもおそまつ。そもそも星座毎になっていない時点でやる気がないことが分かる。

プラネタリウムソフト(若しくは星図)と連携させて、ポイントした場所を導入する、って、行く店の名前はわかっているのに、わざわざそれを地図上で示さないとだめ、っていうこと?(これは前述)

もう一つ言うならば、何故自動導入とリンクした初心者向けのガイドブックがないのか、という疑問。

昔は、星座ガイドブックを赤いライトで照らしながら一生懸命導入して解説と見比べたものだが、今だったらスマホの画面で一発のはず。星座神話や天体のまつわる歴史については紙の書籍の方が良いようにも思えるが、対象物の情報に対しては絶対スマホ。
重星だったら離角や方位角、星雲星団だったらスケッチ(写真じゃだめ)とかがすぐに参照できれば、見ているのが正しい対象かどうかも簡単にわかる。

自分で使うため、というのが一番の目的なのは事実ですが、そんなガイドブックにつながれば、というのも開発動機には入っています。

そもそもsynscanに(誰も使ってないけど)あれほどきちんとしたapiがドキュメントも伴って公開されているのは何故か。
開発者は、色々なアプリから自動導入を使って欲しかったんだと思います。

nanacoギフト登録ツールの問題点について

 アクセスがあまりなかったので様子見だったのですが、なぜか最近ちょっと増えてきたので、これ以上放置もまずいだろう、ということで。

 実は、ベネフィット・ワンから届くメールの形式が19年6月から少し変わっています。

 先頭に'送信専用アドレスのため...'という2行が追加され、この部分が'---'2行で囲われているのですが、これは、データの直前にある行と同じです。(以前はデータの開始と終端が違う形になっていて、プログラムでの処理も想定されているような形だったのですが、今回それを知らない人が修正したのでしょう。)

 スクリプトでは、これをデータの認識に使っているため、そのままでは正常に動作しません。修正も考えたのですが現状では2つの形式に対応する必要が生じます。19年5月までのファイルの有効期限は今年の3月のため、それ以降に、変更後のファイルに(のみ)対応するような修正を考えます。

 申し訳ありませんが、それまでは19年6月以降のファイルについては、先頭の4行を削除してから利用していただけるようお願いします。

星座ガイドブックアプリ開発の経緯

星座ガイドブック(春夏編・秋冬編 藤井旭著)、ちょうと高校で天文部に入った頃に出版されたので早速購入。(高校生に1,300円はちょっと高かった)
観望会の度に、今度はこれを見よう、とやっていたものです。これほど情報が整理されたガイドブックは他になく(現在でもありませんが)まさにバイブル、でした。

でもその頃の望遠鏡は5センチ(タカハシではありましたが)。一応赤道儀ですが、目盛環もなく極軸望遠鏡もないもの。
明るい天体以外を導入するのは至難の業でした。

時は下って、大学も卒業、就職する頃。発売されたビクセンのスーパーポラリスは安価な赤道儀でありながら、極軸望遠鏡と赤経軸のモータードライブを装備、これなら導入も簡単になるだろうと購入するも、極軸合わせはまだまだ大変でした。

そして更に多くの時間が流れ、ついに自動導入経緯台が安価で入手できる時代に。
ケンコーのモデルを購入しましたが、セッティングこそかなり簡単になり、自動導入の精度も十分ながら、二重星のリストは貧弱、自分でデータを追加しようにも、なんと赤緯赤経のデータをテンキーで直接入力しなくてはならない!!

幸いにして、pcと接続してプラネタリウムソフトとの連携は可能になっており、このプラネタリウムソフトが階層状のデータをサポートしていた(星座毎に二重星のデータを持つためには絶対必要。なのに他の環境ではフラットなデータしか利用できなかった!!)ので、それを使って自動導入用のデータを作り始めたのですが、機能上どうしてもそれぞれの対象をマウスでクリックしてデータを手作業で追加する必要がありました。

それぞれの星の位置は星表などで既にデータ化されているにも関わらす、それを改めて作業しないとならない点に我慢ならなくなり、作業は中断しました。

そのタイミングで、skywatcherからAZ-GTiが発売されます。調べてみるとこの架台を駆動するアプリ(SynScan)にはちゃんとAPIが用意されていて、赤緯赤経のデータさえあれば他のプログラムから自動導入が可能になることが分かりました。
つまり、星座毎の二重星のリストと星表のオンラインデータが有れば後は簡単なプログラムでデータ作成はできるので、ユーザインタフェースの部分だけ作ればok、ということになります。
UI部分は手間がかかることが多いのでちょっと躊躇したのですが、誰もアプリを作ってくれそうにないので諦めて開発を開始しました。
androidアプリは全く初めてだったのですが、UI部分についてはandroidの場合、予め用意されている機能が多かったので、それほど困ること無く、動作するレベルのものは3ヶ月ほどで開発出来ました。

その後、ViewLIstなどの機能を付け加えたり、微動部分を開発したり(これは単機能アプリとして既に公開済みです)、星座ガイドブックのデータを書き出したり(これは個人用)して、近日公開予定です。

架台駆動ボタン代替アプリ開発の経緯

当初は加速度センサを利用して、スマフォを傾けることによって駆動することを考えた。

感覚ともズレがなく、良い感じだったが、実際には駆動時に追尾をオフにし、また駆動終了時にもとの追尾に戻さねばならず、それを明示的に操作するためには、何らかの手段を目で見て行う必要があり、基本アイデアである'見ないで操作できる'に反する事になってしまう。

ジョイスティックが利用できるとの情報があり、こちらの実装は非常に簡単だったが、WiFiとBluetoothが共存できなかったために見送り。

加速度センサと同時にアイデアとしてはあった、タッチセンサを使う方式を試す。

これだと、追尾のoff/onが画面タッチの開始、終了で行えるので、全く画面を見ずに操作が可能。
感覚的なズレもない。
片手で持ちながら画面をタッチ&スライドする必要があるので若干不安定にはなるが、通常のサイズのスマフォであればまあ問題ないレベル。

どうせSynScan(pro)はスマフォで稼働させるので、この方式なら新たなデバイス無しで実現可能。

ということで、この形式のアプリを公開することにする。
で、公開準備中にふと気づく。
画面のどこにタッチしても検出可能なのだから、これを傾けて駆動するタイプの'切っ掛け'にすれば良いではないか。

早速実装してみると十分実用になる。というかターゲットを視野の中心に持ってくる段階では、感覚的にこちらのタイプの方がピッタリする感じもある。

ということで、傾けるタイプも、タッチした指をスライドさせるタイプと合わせて公開することにする。
機能的には全く同じなので、どちらか気に入ったほうをお使い下さい。

架台駆動ボタン代替アプリリリース

架台駆動ボタン代替アプリ(TouchSlewing TiltSlewing 共にVer. 0.90)をリリースしました。
バグの御連絡等はコメントでお寄せ下さい。
対応したものについては記事としてアップします。