INDI、Indigo、ASCOMの違い

エンドユーザーにとっては3者ともオープンソースで多数の機器に対応してくれるありがたい存在です。

ブログタイトルがMacで天体と銘打っていますが、天体機器の制御に関してはWindows＋ASCOMが実は一番長かった（過去形）りします。（ASCOMはかなり情報がクローズドなのであまり知識はありませんが。。）

私自身は現在天体機器の制御はシングルボードコンピュータのみで行ってしまっています。
速度的にも不満がありませんし、消費電力が少ないので重いディープサイクルバッテリーの呪縛から離れられるのが一番の要因です。
（Macで消費電力の少ないMINIPCが登場してくれたらおそらく乗り換えます。）

上記３者を使い比べてみて、私が感じたそれぞれの特徴を記載します。

これから始める方の参考になれば幸いです。

●ASCOM
.Net FrameWorkを利用する天体機器通信制御のサーバ・ドライバによるミドルウェアになります。
通信といってもTCP/IPではなく、シリアル通信をメインにして（USBもシリアル通信です。）動作しています。

.Net FrameWorkを使用しているためWindows専用になります。
大きな特徴としてはWindows環境でネイティブに動く唯一のミドルウェアなので、海外のメーカーなどはASCOM準拠のドライバを開発していることです。

●長所
・ドライバ開発にメーカーが参与している。
・使用者が多いのでネットに情報が多い。
・多数の機器のドライバがある。

●短所
・プラネタリウムアプリやCCDアプリが独自に組み込んでいるドライバよりかなり低速（特にCCDドライバ）
・不安定、ネットワークサーバ・ドライバなのに、INDIやIndigoのようにネットワークドライバとして使用できない。（ローカル接続のみ）
・技術情報がほとんど配布先に無い（PCがどのような処理をしているのかがいまいち不明）


●INDI
ネットワーク通信（こちらはIP通信）を利用した天体機器通信制御サーバ・ドライバセット、クライアントに対してはASCOM同様ミドルウェアのような存在で接続されます。
しかし、実質専用となるKStars・Ekosでほとんどの天体機器通信制御が出来てしまうため、この環境で使用される情報が多く、実質KStars・Ekosとのセット扱いになっています。
対応したクライアントもASCOMほどではないが多数あります。

●長所
・軽量、IP通信を利用しているためローカルのみならずリモート通信制御も可能。
・ネット上に開発情報が多数。
・多数の機器のドライバがある。

●短所
・メーカー関与がほぼ無い
・そのためかドライバの管理項目にばらつきがあり、不明要素が多数ある。
・ドライバにより初期状態の安定性のばらつきが多い（そもそも動作させるための初期設定がされていないドライバが多数。）

●INDIGO
INDI環境のMac用のサーバ・ドライバ、アプリなどを開発していた担当者が、INDIのプロトコルを基に独自に新規設計した制御環境。自社サイトにINDIに対しての優位性などが記載されていますが、技術情報が明確に示されていないため詳細は不明です。（実際に使用してみるとINDI環境との差異は操作系以外は不明です。大した違いはないような。。設定などはしやすいです。）

●長所
・軽量、IP通信を利用しているためローカルのみならずリモート通信制御も可能。
・サーバ・ドライバ以外にも自社が開発した天体機器制御アプリがあるため、それらを利用すれば一通りの環境が揃う
　（天体機器制御アプリはMacのみ）
・多数の機器のドライバがある。

●短所
・メーカー関与がほぼ無い
・情報がかなり少ない（INDI以上に人柱必須）
・自社が開発したアプリ以外でサーバ・ドライバをフルに利用出来るクライアントが無い。
（INDIドライバ互換モードも使用できますが、その場合はINDIバージョン1.7に低下（現在は1.85））



どれも一長一短です。
ポイントとなるのは最も高速に利用できるローカル環境（ASCOMはローカルのみ）でのクライアント対応状況ですが、INDI、Indigo共Windowsではローカル環境でサーバ・ドライバを利用できません。（リモートドライバでしか使用できません。）

INDIの場合はローカル環境でサーバ・ドライバを使用できるのはLINUX、MACの２択。
Indigoの場合もローカル環境でサーバ・ドライバを使用できるのはLINUX、MACですが、クライアントがMacの自社アプリ以外ありませんのでMac一択になります。

このように現状ではどこかピースが欠けた状態です。

・Windows＋ASCOMは低速、不安定、しかしメーカー開発のドライバ有り。

・MacはINDI、Indigoどちらもローカル環境でサーバ・ドライバを使用可能、しかしどちらもメーカー開発のドライバ無し、Mac自体がWindowsのMINIPCに位置づけられる省電力のPCが無い。環境構築は最も楽（群を抜いて楽です。）

・LINUXはINDIでローカル環境でサーバ・ドライバを使用可能、しかしどちらもメーカー開発のドライバ無し、システムも軽量なのでシングルボードコンピュータでも利用可。但し、環境構築が面倒。

一番の解決策はWindowsでもINDIやIndogoサーバ・ドライバが動作してくれるか、Macが省電力のMINIPCを作ってくれるかのいずれかですが、現状どちらもありません。

私は現状ではシングルボードコンピュータ＋INDIを選択しています。（消去法的な選択です。MINIPCくらいの処理能力ではASCOMは低速で不安定すぎました。処理能力の高いPCは電力消費量が。。それならMacMINIにINDIかIndigoでも良くなりますが（環境構築楽ですし）、メーカー開発のドライバが無いので、動作確認など自己責任になります。（電力消費量も。。））

うーん。。天体機器制御などはニッチな領域になるので劇的な変化が見込めそうにありません。
当分この状態が続きそうです。

皆さんならどの環境を選びますか？（っていうまでもなくWindowsですかね）


追記
現在2021.5
indigoはWindows環境でAPTとステラショットが対応しています。
Linuxでindigoネイティブのクライアントはありません。

ASCOM環境を使うため覚えておくことのまとめ

以前にINDI環境について記載しましたので、ASCOM環境についても触れておこうと思います。

Windowsで天体環境を構築するために非常に重要な働きをしますが、思ったよりまとまった文献が無いようです。
これから環境を構築する方の参考用としてご活用いただけると幸いです。

・ASCOMはNetframework、DirectXを活用した天体機器のサーバ・ドライバセットである。
・Windowsのシステム機能との依存関係が高いため動作環境はWindowsに限定される。
・天体機器との通信としてCOMポートを利用する。そのため、原則としてドライバ・クライアントの対応関係は一対一になる。
・非常に多くのクライアントアプリが対応しており、ドライバ開発などにメーカーが参与している場合もある。
・ドライバのCOMポートの管理にはレジストリが使用されている。
・メインの開発・検証は32ビットで行われているため、64bitで使用する場合は制約がある。
・インストール後はサーバが常時起動しており、必要となるドライバを起動・設定して使用する。
・ドライバの設定・保存はGUIのフロントエンドで行う。
・複数のクライアントでドライバを利用する場合は、ドライバが独自に仮想シリアル機能をもつか、ASCOM独自のPOTHドライバを経由する必要がある。
・レジストリを操作するため、サーバ・ドライバを管理者として実行する必要がある。
・Windows8、10に対しては正式対応していないため、動作しない場合は互換環境で動作させる必要がある。

実質PCで天体機器を扱う環境としてデファクトスタンダードとしての地位が確立していますが、上記の通りサーバ・ドライバの設計が現在となっては古びている部分や、Windowsのシステムにかなり依存する動作環境になっているためWindows10などで使用する場合は注意が必要な部分もあります。
以下に注意点も記載しましょう。

・サーバ・ドライバが管理者として実行されているため、使用するクライアントも管理者として実行しないと正常に動作しないことがある。（トラブルを避けるのであればクライアンをを含め全て管理者として実行する環境に整えておくほうが良い）

・クライアントアプリが64ビットの場合、ドライバの対応状況によっては動作しないことがある。（クライアント・サーバ・ドライバ全て32ビットで使用する場合が一番推奨環境に近くなる。）

・原則ドライバの設定はASCOM側で行い、保存しておく必要がある。（クライアントの対応にばらつきがある。）

・Platesolvingのように複数アプリ・サーバでドライバを共用する場合はPOTHドライバ、またはマウントのドライバがマルチクライアント仕様（バーチャルCOM）に対応している必要がある。



注意が必要なのはデフォルトが32bit、Windows10正式対応がされていない、レジストリを使用するため管理者として実行されている必要がある、複数アプリでドライバを共用するためにはPOTH、またはドライバ自体がマルチクライアントに対応が必要になることでしょうか。

プラネタリウムアプリでマウントドライバをコントロールするなど一対一の関係で使用することに留めれば、簡単に使用できますが天体撮影のように複数機器をまとめて、更に場合によっては複数アプリでドライバを共用するような使い方となると、制約を避けながらの環境構築が必要となり、かなり注意が必要になります。


現状で安定した環境を作るのであれば以下の項目を実施するのが無難です。

・ASCOMサーバ・ドライバは32bit版を利用、インストール時に管理者として実行する設定にしておく。

・ASCOMサーバ・ドライバは互換モードで動作させる設定にしておく。（推奨はWindows7）

・制御を行うクライアントアプリも全て32bit版を使用、管理者として実行する設定にしておく。

・マウントドライバがマルチクライアント対応の機器を使用する。（不可能な場合はPOTHでの動作チェックを念入りに行う）

上記はあくまで原則論での内容になります。
Windowsの場合、対応するクライアントも非常に多数ありますのでクライアント側でこれらの制約を払拭している場合もありますので、試してみるまでわからないというのが現状です。
いずれにしても上記原則部分を念頭において環境構築すればトラブルが起きづらくなるかと思います。

昨年あたりからINDIGOドライバにあったTCP/IPラッパー（TCP/IP環境でASCOMサーバ・ドライバ環境を使用できるようにするラッパー）のAlpacaがアナウンスされています。

Alpacaが普及すればWindows以外の環境でもTCP/IPを通じてASCOMサーバ・ドライバを使用することができるようになるようです。
これらの規格も期待したいところですが、まずはASCOM本体でCOMポートの扱いや、Windowsの最新環境に対応することが最重要な事項になると思います。

ASCOMが誕生してから20年になります。
現在においては事実上天体機器制御環境のデファクトスタンダードになっています。
しかし、現状はWindowsの高い互換性におんぶにだっこになっている部分が散見されます。
上記記載の通り、最新OSへのフル対応や、COMポートの扱い方などが改善されればさらに使いやすい環境が整うと思います。

Alpacaを開発したりなど、積極的に開発が行われているようなので、ベースとなる機器制御の安定性や拡張性が充実するように期待したいと思います。

Alpacaサーバ・ドライバ？

以前の記事でAlpacaについて少し触れましたが、その時は本家が作るASCOMのTCP/IPラッパーなのかなといった認識でしたが、詳しく調べていくとAlpacaサーバ・ドライバなる情報が出てきました。

どうやらAlpacaは既存ASCOMドライバをTCP/IPで他の環境で使えるようにするラッパーと、Alpacaサーバ・ドライバによるTCP/IPサーバ・ドライバの総称ということらしいです。

既存のASCOMはそのまま残し、ラッパーとなるASCOM RemoteでTCI/IPを使用したマルチクライアント対応を図り、新規に開発されるAlpacaサーバ・ドライバでマルチクライアント・TCI/IP対応（ASCOMドライバ互換）を行うといったことになるようです。

書いてあることだけ読めば理想的ですが、いくつか懸念があります。

・既存のASCOMサーバ・ドライバの改善はどうなるか？
正直ASCOMのネットワーク実装（COM）が現状不具合になることが多く、ASCOM自体も正式にWindows10に対応していません。ドライバをマルチクライアントで使用するにはメーカー側がマルチクライアント対応したドライバを開発しているか、POTHHubを使用する必要があります。
昨今流行りのPlateSolvingなどを使用するとなると複数アプリの連携が必須になりますのでマルチクライアント対応ドライバか、POTHHubでの連携が必要になりますが、私の環境（使用機器）では正直まともに動いたことがありません。

既存のASCOMの開発がこのような状態で別規格を作ってしまうと混乱するようにも感じてしまいます。
既存のASCOM環境をきちんとWindows10に対応させ、全てのドライバがマルチクライアント対応、及び64ビット・32ビット両対応になれば少なくともWindowsで動かす限りは安定するはずです。
少なくともASCOMで上記部分の改善はしっかり取り組んでほしいですね。（じゃないとAlpacaRemoteで他の環境でASCOMが使えるようになったとしてもまともに動きませんので。。。）


・Alpacaサーバ・ドライバってどこで入手できるの？
発表されてからそこそこ時間が経過しましたが、本家サイトにAlpacaサーバ・ドライバのダウンロードページがありません。
ネットなどでいろいろ探してみると個人の方がAlpacaドライバを配布していたりします。

どうやら、本家ではまだサーバ・ドライバの配布状態には至っていないようでドライバ開発キットやチェッカーの配布にとどまっているようです。

現状を見てのあくまでも予想ですが、既存ASCOMドライバを残しながらラッパーを被せて他環境でも使用できるようにしながら、緩やかにAlpacaサーバ・ドライバに切り替えていく作戦なのでしょうか？
そうなると切り替わるのに非常に時間がかかりそうです。（カオス状態になる予感も。。）
AlpacaでASCOMのCOM環境から脱却という姿勢は大いに評価できますが、これだけ発表されてから時間が経過しているのにラッパーしか発表されていないというのは非常に心配な状況です。
MacユーザーやLinuxユーザーはラッパー被せてまでASCOMを使いたいとは思っていないことをしっかり認識してほしいですね。（INDIやINDIGOで不自由なく機器制御ができますので、もしAlpacaがそれらより優れていたら乗り換えたいです。）

個人的にはずるずると古い環境を引っ張るのではなく、すっぱりとAlpacaに切り替えてほしかったです。

現在EAAで使用しているマウントがドライバのバグでまともに動作しなくなってしまいましたので、この機会にAlpacaを試そうかと考えましたが、まだ残念ながら試せる環境自体がなさそうです。

ドライバは天体機器を制御する上でもっとも重要な部分になります。
アプリの方はさまざまな連携ができる環境が整ってきましたが、ドライバの不具合で連携が出来ないことが散見されます。

天体機器のドライバは他の環境では当たり前になってきているPlug & Playに対応していませんし、ASCOMのデフォルトではドライバを一つのアプリでしか利用できません。（連携のためにPothHubがありますが、前出になりますが、私の機器では正直全てまともに動いたことがありません。。マルチクライアント対応のドライバはわずかです。）

現在は消去法的にINDI環境を使用していますが、Alpacaの動向によってはユーザー（特にWindows）が安定環境を手にするのは時間がかかるかもしれません。。。（共倒れになるとかは本当に勘弁してほしいです）

個人的には小難しいことを考えなくても繋げば動くという環境が早く整ってほしいと感じています。（まだ見ぬAlpacaはそのような環境を実現できるのでしょうか、そうなることを心より願います。）

規格ばかり増えて安定環境が作れないとか本末転倒ですね。
良い方向に進みますように。。。。。


追伸
冷静に考えると、ハードメーカー発の統合環境ってとても少ないですね。（ASIAirProくらい？）
ハートメーカーがアプリまでセットで面倒見てくれれば、動作の安定性は担保されそうです。
現状だとCelestronかZWOでしょうかね。
ZWO社のASIAirProがINDI本家のStellarMateより安定していたり、使いやすいのは自社のハードへの動作チェックや操作体系を考察しているからでしょう。
天体撮影が趣味のユーザーに頼っている割には天体望遠鏡メーカーからはこのような統合環境アプリが出てきませんね。
CelestronやSkyWatcherなどの大手がこれらの開発に着手してくれれば大分環境が整うのにな。。
（そう言えば、以前ミードで出していたような記憶が。。。会社自体が体力ダウンして過去のものになってしまいましたが）

なんか、今の天体機器のドライバの状況ってUVCが登場する前のWebCamに似てるように感じます。。。（独自ドライバの安定性に依存（大体安定していない（苦笑））、OSによってはドライバ自体が無い、自己責任の汎用ドライバの乱立など。。）

天体機器のドライバもUVCのように統一規格に。。。。ならないか。。。。。。

ASCOM Alpacaの現在

Alpaca RemoteというASCOMのネットワークラッパーが配布されてから約3年。

久しぶりにどのような進展があったか本家サイトを確認してみました。

Alpaca Remote以外で本家サイトから唯一リンクされているのがAlpacaScopeというASCOM環境をSkySafariで利用するミドルウェアのみ。。

ネットをくまなく探すと個人の方、アプリケーションの開発者などが非公式でドライバを配布しています。（Cielの開発者のパドリックがミード架台のドライバを開発、ArduinoのDSCのドライバを作っていたミッシェルのDSCドライバ、ラズパイのディストリビューションAlpacaPiなど。。）

ASCOMの時のようにメーカーの参画もありません。。

発表されてからすでに3年以上経過しています。。一体なぜこのようなことになっているのでしょうか。（うすうす想像はつきますが。。。）

本家サイトの文献を見ても、開発元であるASCOM Initiativeの認識の甘さが散見されます。

ASCOMに関してはWindows環境下で天体機器を制御するプラットフォームを作るという意味で訴求がありましたが、Alpacaに関しては開発者にとって先行するINDIやINDIGOに対して差別化できるメリットが見えづらいです。（個人的にはCOM脱却は大賛成ですが）

ASCOMで培った協力関係をもとに、開発元自らがメーカーと協力してドライバを用意して移行を促すなどすればよかったのでしょうが、仕様だけ公開してあとは放置では開発者も賛同しないでしょう。

いっそのこと他ではやっていないコンシュマーに対してWebアプリでの提供とかしてくれれば大いにPRできそうですが、まずはドライバの開発が先決ですね。

このままズルズルと待ち状態が続いているとWindowsのCOM環境の互換性低下とともに制御環境の信頼性が低下しそうです。。。(ASCOMもWindows10に正式対応しないままWindows11が登場してしまいました。)

ASCOM Initiativeの今後の取り組みに期待したいと思います。