Salon de Astronomy（星空を楽しむ部屋）

どうやらドライバなどの大幅な更新をしているようです。
これだけ大幅な変更は久しぶりかもしれません。
開発者もかなり覚悟を決めて取り組んでいるのでしょう。

●KStars v3.5.2の変更点

・Load＆SlewのAlignmentモジュールに手動回転ダイアログを追加。これで、電動ローテーターを持たないユーザーもｌカメラを手動で調整して、目的のフレーム方向を調整可能。

・Ekos Polar AlignmentAssistantの大幅な改善
1.空のどこを指しても極軸調整が可能。
2.ユーザーインターフェイスの変更。
Ekosに三角形が表示され、選択した星（円で囲まれている）を黄色の線の上に移動して高度を調整し、次に紫色の線の上に移動して方位角を調整。その際、「PAエラーの更新」がチェックされていると、システムは残りの極軸合わせエラーを推定可能に。

・フォーカスモジュールの改善（メモリ制御など）


●INDIライブラリv1.8.9

・不足しているexecを追加
・ホームポジションに役立つメッセージを追加
・最高のホームレートとサイド
・ USBとDewのラベルを追加（＃1355）
・スターアドベンチャーのエントリを追加
・構成にモーターレートと電流を追加保存
・CEM26とGEM28を追加。CEM40およびGEM45ドライバーをiOptronv3コマンドに移行し、パーク制限を削除。修正＃1354
・CelestronGPSガイダースケールの最終修正（＃1353）
・DDW状態変更修正パート2（＃1351）
・Paramountのマウント側に予備サポートを追加（未テスト）
・DDWシャッター状態の修正（＃1349）
・有用なマクロをindimacros.hに分離（＃1348）
・Pegasusにマイクロもサポートを追加
・DDWドライバーの状態変更の処理の修正（＃1346）
・PyIndi​​が欠落しているシンボルをフェイルオーバーする問題を修正（＃1347）
・DDWドライバーの更新（＃1344）
・DDW通信ウォッチドッグの回避（＃1342）
・Driver for Digital Dome Works（DDW）from Technical Innovations（＃1341）
・SkyWAtcher Alt-Azの更新
・AZEQ6のサポートを追加
・rishi-garrodV2のAutoDewを修正し、V2のAggessivenessを追加。いくつかの点灯を修正…（＃1340）
・シリアル接続にnullポインターチェックを追加（＃1335）
・WeatherInterfaceにsaveConfigItemsを追加し、それを継承するクラスで利用
・コードを簡素化し、より適切な変数名の使用
・d33pskyIntegra85ドライバーの健全性チェックと改善されたユーザーメッセージ。（＃1334）
・ celestronGPSガイドレートスケーリングの修正（＃1331）
・DefaultDevice-D-Pointerの実装（＃1327）
・Trackingのオン/オフを切り替え機能の追加（＃1326）
・リファクタリング-ウィジェットデコレータ（＃1324）
・遅延計算のためのIliaPlatone indicom.cアップデート（＃1328）
・フレームベースのV4Lスタッキングループパフォーマンスを向上させるためのレイジーストップキャプチャ（＃1325）
・ジョイスティックコントローラーにスヌープデバイスを追加（＃1323）
・出力ポートの操作に関する問題の修正（＃1322）
・一部のクライアントとのデッドロックを防ぐための一時的な対策。（それでも長期的なソリューションが必要）
・リファクタリング-ファイル間の依存関係が少ない/ mallocが少ない（＃1318）
・リファクタリング/ INDI :: BaseDevice-D-Pointerの実装（＃1320）
・Sesto Senso 2：モータープリセットの問題の回避（＃1319）
・libindiv1.8.9開発サイクルの開始74615e62021-01-11 JasemMutlaq
・複数で使用する場合のプロパティとメッセージの保護スレッド。（これは以前は正常に機能していましたが、条件によってはデータが破損する可能性があります）
・Indidriver / refactoring（＃1313）
・Senso 2：モーター設定（＃1315）

今まではほとんどメイン開発者のジェセムが修正を行っていましたが、今回は協力スタッフと共に大幅な修正・変更をおこなっているようです。

真摯にブラッシュアップに取り組んでいるようで好感が持てますが、上記を見るに明らかに大改修のファーストステップといった雰囲気です。

私は、現状バグを回避で問題なく使用出来ていますのでフォーラムで様子を見てからアップデートを検討します。
（さすがに大幅すぎて怖いです。。。）

以前記事として記載しましたが、Windows版のKStarsはV3.5からStellaSolverが内蔵されています。

ASCOMのPOTHに苦しんでいる方、高速なPlateSolvingを利用したい方はお試しください。
ダウンロードはこちら

VirtualVox用のVHDファイルと設定用のVBOXファイルのセットです。
（AstRPiのようにハード固定ではないので環境により上手く動作しない可能性があります。起動エラーが出る場合は強制終了（仮想環境のウインドウを閉じる）して、仮想環境を再度起動時、リカバリーモードで起動してみてください。それでも起動しない場合は動作しない可能性が高いです。）
ダウンロード後解凍してください。

用意するものは以下
・64ビット版のVirtualVox
・Windows版のKStars

使い方は簡単です。
VirtualBoxを起動



メニュー：仮想マシン→追加　を選択




上記VBOXファイルを選択




1.読み込まれた仮想マシンを選択
2.起動ボタンをクリック

設定などは行ってありますので上手くいけばこれで使えます。（私は若干設定が必要でした。あれこれ操作したので詳細は忘れましたが使えるようになりました。このファイルは自己責任でご利用ください。）



システムが立ち上がったら、VirtualBoxで使用するシリアル機器を登録（上図赤枠のアイコンで行います。）

Linux部分を使用するのはこれだけです。
（後はシステムを終了するときに右上のアイコンを選ぶだけ。）

その後Webブラウザを立ち上げて　localhost:8624　にアクセスしてINDIWebマネージャーを起動します。
カメラドライバをシミュレーションドライバに設定し、後はご自身が使用されている機器のドライバを選択してドライバを起動します。
このあたりの流れは上記の過去記事をご参照ください。

これで超高速なStellaSolverとシリアル機器をKStarsで連動操作出来る環境が整います。

StellaSolverはSextractorとAstrometry.netを活用したPlateSolving環境です。
非常に高速で安定しているので、私自身がWindowsでもこの環境を使用したかったのですが、この機能を使用するためにはINDIサーバ・ドライバが必要になります。（残念ながらINDIサーバ・ドライバまでは移植されませんでした）

そのためだけににLinuxマシンを使うというのが面倒だと感じ、Windowsで手軽にINDIサーバ・ドライバを利用する方法がないかといろいろ考えました。

CygWinを利用する方法や、Windowsネイティブの拡張環境で利用できるWSLなどを検討しましたが、CygWinに関してはソースからでないとサーバ・ドライバを利用できない、WSLはリポジトリで簡単に環境を作れるけれど外部機器の制御（USBやシリアル）が不十分などなんとも使いづらい状態でした。

色々検証したところ、上記VirtualVoxを利用すれば、USBをダイレクトに使用するカメラドライバ以外は問題なく動作することがわかりました。

INDI環境さえ動作すればカメラ部分はシミュレーションドライバで流用出来ますし、Windowsで最も泣かされるCOMドライバ（ASCOMなど）の連携部分がINDIでまかなえますのでKStarsを用いて自動導入、オートフォーカス、StellaSolverによるPlateSolvingの連携が実現できます。（PlateSolvingのインデックスファイルはAllSkyPlateSolverなどと共用できます。）

カメラ部分のみSharpCapなどのキャプチャソフトを利用すれば良いのでキャプチャアプリの安定性も向上しますし、ASCOMの32ビット縛りからも開放されます。（StellaSolver以外に不安定なCOMから開放されるのも実はうれしい要素です。）

VirtualVoxでのエミュレーション環境での動作も制御するドライバがマウントやフォーカサーなどのCOM（シリアルUSB変換）部分のみであればINDI環境の軽量さと相まって全く問題ありませんでした。

配布するファイルも動作保証できるものではありませんので、ASCOMのPOTHに苦しんでいたり、PlateSolvingの速度や成功率に不満がある方はお試し要素の一つとしてご利用ください。（おまけ機能としてWindowsでホットスポット作成すればスマホのSlySafariとも連携できるようにしてあります。ポート番号は4030です。）

追記
新しいカーネルが配布されたようで起動後、UPGRADEを促す表示がされますが、キャンセルしてください。
（新しいカーネルにするとブラックアウトします。）

先月かなりいろいろなチェックを行う中で、痛切に感じたことがタイトルの制御と処理環境についてです。

現在ではどちらもPCを使用する状況が多いですが、制御と処理は分けて考えたほうが問題解決が容易になるように感じています。

制御に当たる部分は以下になります。
・マウント
・フォーカサー
・カメラ
・オートガイダー
・フィルターローテーター
この他にもドームやGPS、温度センサーなどさまざまです。

いずれも外部機器のリアルタイム制御になります。
カメラを除いて実は殆どの場合シリアル制御（現状ではシリアルUSB変換が主）です。
上記の機器が正常に動作するか否かはドライバとOSの機能（特にシリアル制御のコントロール機能）に依存します。

対して処理に関しては、ライブスタッキングなどリアルタイム処理を除いては全て後処理、殆どは画像や映像の処理になりますのでPC内部での演算になります。
どのような処理が可能なのかは、アプリの機能に依存します。

いろいろなOSで環境を作りチェックすると痛感しますが、現状ではOSによって得意分野が明確に異なります。。

OSのことを書くと宗派論争になりがちなので（なぜなんでしょうね？）細かくは記載しませんが、同じOSであっても、制御部分と処理部分では要求される要素が全く異なりますので分けて考えたほうが幸せになることができます。

個人的に注意が必要なのは制御部分だと考えています。
この部分が上手く動作しないと撮影が出来ませんし、マウントやカメラ、フォーカサーなどの制御が出来なくなります。
特にマウントについては動作が不安定であったり、暴走などすると他の機器の破損にも繋がります。
制御部分に関しては映像や画像部分を除いてはマシンスペックが必要になる部分はありません。
いちばん重要なので安定して全ての機器が制御出来ることです。

処理部分に関しては自分が望む処理機能が快適に使用できれば良いので、マシンスペックと自身が望む処理が可能なアプリの有無で決まってきます。

天体用PCと一括りに扱うのではなく、制御用、処理用と物理的にマシンを分けても良いでしょうし、特定のOSにこだわりがなければ得意分野に合わせてOSを切り替えるのも一案です。

遠征などでPCの不具合などは不快な思いしか残りません。

制御部分に関しては特に安定第一を心がけて環境をまとめましょう。
（後処理部分の機能は個人的には制御用マシンには不要と考えています。）