Windows MiniPCでヘッドレスリモート制御に挑戦（リベンジ？）

昨日が散々な結果だったので本日も一階のベランダに機材を設置してWindows MiniPCでヘッドレスリモート制御に挑戦しました。

一階のベランダは木に囲まれているため視野が狭いですが、Lanケーブルを引っ張れるのでこのようなテストには最適です。
以前Windowsで天体撮影していたときはノートブックを機材に接続し、準備などが整ったらVNCでリモートしていましたが、今回は電源を入れたらすぐにヘッドレストリモートです。




昨日色々セットアップを調整したので、とりあえずヘッドレスリモート接続は問題ありません。
架台はSynScanPROアプリとASCOMで制御します。
最初、緯度経度がいくら設定しても反映されず悩みましたが管理者モードでアプリを立ち上げてみたら無事接続されました。




ASCOMでCielとSharpCapに接続します。新しいデバイスHubモードでマウントは無事共有できました。




しかし残念なことに自作Moonlite互換フォーカサーのASCOMドライバは認識されません。
こちらはサイトからCOMに直接接続するアプリで制御しました。（これは後日の課題です）




SharpCapでもCielでもマウントが制御できるようになったのは以前に比べて大きな進展ですね。
デバイスHubはPothHubよりは良さそうです。
（しかし、作業途中で接続が切れる状態が出てしまいました。。。）
Solverも試してみましたが、残念ながら成功しません。。。（これも後日の課題です。）




そうこうしているうちに、曇ってきてしまい本日のテストは強制終了になりました。。

一日だけのテストなので雑感程度ですが、ASCOMのデバイスHubは以前のPothHubよりは良さそうです。
しかし、接続しているにも関わらず途中で動作しなくなることがありました。
こうなるとPCの再起動しかありません。

一番悩ましいのはPlateSolverですね。
ASTAPとASPSを両方試しましたがどちらも成功しません。
もう少し露出を長くしたり、ゲインを上げたりして星の数を増やす状態にしないと駄目なのかもしれません。

私はEAAでの観望がメインになりそうなのでWindowsを使うとしたらSharpCapを中心としたシステムになります。
このアプリはライブスタック機能は右に出るものが無い存在ですが、ASCOMを使用した連携などを行うと不安定になることが多いように感じます。

今回も数回クラッシュしましたが、やはり連携操作を行っているときに発症しました。

但し、以前と異なりマウントドライバは連動しましたのでSolverさえ成功すればなんとかなりそうです。
（不安定なのが気になりますが。。）

このMiniPCはCeleron3445、メモリは8GBですが、Windowsで制御するとなると最低でもこのくらいのスペックがあったほうが無難ですね。

しかし、PlateSolverが鬼門ですね。。。
これが実用的に使えるようにならないと遠隔リモートは厳しいです。。

まあ、今回のチェックで一通りは試しましたので、あとはぼちぼちチェックしてみようと思います。


追伸
調べたところ自作moonite互換フォーカサーはASCOMドライバでは動作しないようですね。
ftdiチップセットが使われていないとCOMが認識されない仕様みたいですね。

あと、ヘッドレストリモートで運用しようと思うと非常に困るのが”ようこそ”（ロック画面）です。
今回はベランダで家のLANに接続されていたので問題ありませんでしたが、私はマイクロソフトアカウントでWindowsにアクセスしていますので、ネットにつながらないとPINコードが使えなくなる可能性が高いです。
VNC用のアカウントを作って確認すると、メインアカウントで認証ボタンを押さないとアクセスできません。。。。
ネット接続がなくてもPINコードでアクセス出来れば良いですが、そうでないといつもの広場で使うにはちょっときついかも。。

と、いうことで以下の設定でロック画面が表示されないように設定しました。
検索窓に　gpedit.msc　と入力→表示される書類を開く→[ 管理用テンプレート ] → [ コントロールパネル ]→[ 個人設定 ] →[ ロック画面を表示しない ] をダブルクリック→有効に設定すれば、ヘッドレスリモートの大敵のロック画面を非表示に出来ます。

しかし、この状態でもログイン画面が出てしまいます。（しつこい。。。。）
検索窓に　netplwiz　と入力→コマンドを実行→使用するユーザー名を選択→上部にある　ユーザーがコンピュータを使用するにはユーザー名とパスワードが必要のチェックボックスを外す。

これでようやく電源オンでデスクトップが表示されます。

Windows MiniPCでヘッドレスリモート制御に挑戦→轟沈

当地は極寒でしたが、天気はほどほどでしたので一昨日くらいからセットアップしたMiniPCをテストしました。



このPCも筐体が小さいので楽勝だと思っていたのですが、さすがにラズパイのようなセットアップは無理でした。
干渉しないように紐でくくりつけて部屋に戻ります。（数分の作業でしたが凍りつきそう。。）
鏡筒へのセットは後日しっかり考えないといけません。

考えたらWindowsを使用していた頃はノートパソコンやネットブックだったので今回のようなヘッドレスリモートはしていませんでした。
リモートデスクトップ類もRealVNC、Windowsリモートデスクトップ、NoMachineと3種類も入れてあるので問題ないかと考えていましたが・・・・

のっけからトラブルの嵐です。。。。
リモートでデスクトップにアクセスできません。。。。。

結局この日はWindowsのリモート環境のトラブルを洗い出すだけで終了してしまいました。。

ネットなどで調べながらセットしましたが、驚くほど情報が少なかったので備忘録として記載しておきます。

●VNCサーバに関して
Linux同様RealVNCをインストールしましたが動作しませんでした。
TightVNCサーバは問題ありませんでしたので、WindowsでVNCでのリモート環境だとTightVNCサーバがおすすめです。
（そういえば以前もTightVNCサーバを使用していました。。）

●Windowsでのボンジュール名の扱いに関して
以前は有線、固定アドレスで運用していましたが今回はボンジュールをインストールしてあるので簡単にアクセスできるだろうと考えていましたが、Windowsの設定でボンジュール名を確認できる場所がありません。。。。
ネットで調べてもMacの情報ばかりで、Windowsでのボンジュール名の扱いを記載したサイトがほとんどありません。。。
（なんでMacが開発した技術に関してはいつもこうなるんでしょうかね。。）

結論を書くとWindowsの場合はコンピュータが勝手につけたコンピュータ名がボンジュール名として使用されるようです。
わかりづらい名前なので変更しましょう。



エクスプローラー→PCを右クリック→プロパティを選択





1.設定の変更をクリック
2.変更ボタンをクリック
3.名前をわかりやすいものに変更
4.OKボタンで確定

Windowsが勝手につけた名前は大文字の上、ハイフンで区切られて乱数が割り当てられるのでネットワーク系のアドレスとしてはとても不向きなものです。
なるべくご自身が覚えやすい簡単な名称に変更しましょう。
この操作を行うと、再起動させられますがこれで　無線でも有線でもDHCPのままコンピュータ名.localでアクセスできるようになります。


●NoMachineとWindowsリモートデスクトップで接続する場合のユーザー名、パスワード
ボンジュールで接続できないので悪戦苦闘した際、NoMachineは非常に優秀でした。
なんとIPアドレスやボンジュール名がわからなくてもネットワークに接続されたマシンが一覧で表示されてくれます。（素晴らしいですね）
しかし、ここでも行く手を阻む要素が。。。

Windowsに接続するためのユーザー名とパスワードです。
NoMachineはローカルユーザー名とそのパスワードが必要です。
Windowsリモートデスクトップに関してはマイクロソフトアドレスのパスワードが必要です。（いつも使っているPINは利用できません。。）
しかも、IPアドレスか、ボンジュール名のアドレスも必要です。

Windows10になってからローカルユーザー名を登録した記憶がありません。。。
どこにあるのかあれこれ探したところ、こんなところに。。。。




エクスプローラー→Cドライブ→ユーザー→自身のユーザーフォルダの名前

これもWindowsが勝手につけているようです。

このフォルダ名をユーザー名の場所に入れ、同じく探すのにとても苦労したローカル名のパスワードを入力すれば無事デスクトップが表示されます。

天体用リモート制御で使うことを考えるのであれば、ラズパイなどのSBC同様ヘッドレストリモートで操作したり、環境を作っておいたほうが良いですね。。。

ネットワーク絡みの部分に関してはWindowsはUnix系とは本当に管理の仕方が異なるので注意が必要です。
今日は星を見る予定だったのに、三夜連続のPCいじりで終わりました。。
（ひさびさに根を詰めて設定したので、うかつにも何度かWindowsお得意の設定変更→再起動の強要→そのままシステム更新のコンボ技にもハマりました（苦笑）。制御のほうでも一悶着ありそうな予感満載です。）

四年目の浮気？（INDI vs ASCOM）

変なタイトルで恐縮ですが、以前記事で記載したEAA用のMiniPCをもう一度作り直し（SSD容量アップ、結局再度環境つくり直し）
UBUNTU（20.04）とWindows10両環境で天体機器を制御できるように再構築しました。


（写真は地味な作業風景。。。）

Windows側にはASCOM、PlateSolvingはASTAP、ASAP、PlateSolve2の3種類、機器制御はCielSkaycharts、CCDCiel、APT、N.I.N.A、SharpCap、ASIStudio、ステラリウムなどと画像処理系のアプリ一式（スタッキング系など）を組み込みました。

UBUNTU側はこのブログではおなじみのINDIサーバ・ドライバ、Kstars、CielSkaycharts、CCDCiel、ASIStudio、ステラリウム、Ser2Netなどこれまたいつも使っている環境を一式組み込み直しました。

どちらの環境もリモートで操作できるようリモートデスクトップ環境もガッチリ整えました。

4年ほど前に長らく使用していたWindows環境からLinux環境に移行しましたが（まあ、ちょこちょこ使うこともありましたが）、今回はINDIのマウントドライバ不具合が長期化しているので、現在だとどちらが安定して使用できるかを試してみようかと考えての行動です。
（天体用のWindowsマシンがだいぶ古くなってしまったのも一因）

INDIは最近開発者が混乱しているのか、バグが増えてきましたし、SharpCapのような高機能なライブスタッキングアプリが登場しません。（Ekosでできるようになると告知されてから早1年経過します）。

かたや、Windows勢は以前はASCOMを使用すると安定性に欠け、いくつかの機器は動作しなくなるなど手を焼きましたが、単体のアプリでは新しいものも少し出てきましたし、魅力的なものが多くあります。（統合制御系は動かなくて苦しみましたが。。。）

以前よりも事務作業などでWindowsに触れる機会も多くなりましたし、そこそこ快適に動くMiniPCも廉価に購入できます。
SSDを2台入れてデュアルブートにしておけば、どちらの環境を試すこともできますので、今後の制御環境を占う意味もふくめてのセットアップです。
SDDの容量を増やしたため、結局両環境をフルに作り直しましたので地味に時間がかかりました。。。

結果はどうなりますことやら。。
（両環境とも不具合だらけとかは勘弁してほしいですね。。。。）