オヤジのINDI環境の不具合

【2019-1201 追記の2】

GPV他を見ると、星が見えるのは日没後の短い時間のようなので、大急ぎで家の南側(北極星は見えない)にUSB3.0セルフパワー5m2本を繋いで、三脚+AZGTI+カメラレンズ(Zoom:100mmに設定)でテスト

  • ベアボーンPC Desk Mini 110/B/BB(Pentium G4560/16GB/SSD:128GB)に新規インストール(ワーニング出まくりだったので、サッパリ入れ替えた)
  • Ubuntu-18.04.3LTS-amd64.isoを入れ直して、INDI LibからkStars他インストール。updateも無事完了
  • 大慌てでテスト開始、アレアレ白雲が出始めて40分で、月は見えるけど星は殆ど見えない。
    その前に、一発、Solveやったらまだ少しずれているけどプレアデスが中央付近に入った。
  • OS+INDIを入れ直してしまったので、何が原因だったか不明。
    こういう手順じゃ駄目だよな。大いに反省。
    でも、テストするに堪えない位、ワーニング出まくりで、エイヤ!で入れ直してしまった。
  • タックさんに教えて貰った情報
    >Turn on “Resource Limited Mode” in FITS options.
    OptionをOnは、設定しました。
    後で、これを外せば、切り分け出来ると思います。
  • これで、明夜、再度、東の観測場所でテストです。(笑)

【2019-1201 追記】

I’m constantly getting KStars crash after a few images are captured with Ekos. I cannot debug it due to the following error:

見つけた。ここを頼りに・・・・

不具合の状況は、以下の通り。

INDI でSD115S

皆さん、問題無くINDI最新環境を利用されている。
これは、オヤジのハード・ソフト環境だけで発生しているのだと思う。

不具合を検証・テスト環境だけど、ガイドモジュールや、アライメントモジュールを操作中、カメラモジュールで星空のモニターを起動すると起きる、又は、この逆で発生するので、

  • テストするには、実の星環境が必要。
    と、言うことは、晴の夜空が必要なので、結構、テスト出来る機会がそがれる。(汗)
  • 東の観測場所では、庭の中と言えども遠くて難しい。
  • そんな訳で、PC部屋の壁には、過去に直径8cmの丸い穴が貫通しているので、ここにUSB延長ケーブルなりLAN(クロス)ケーブルなり通せるので、ここで、環境を作ろう。
    悪天候なら、10秒で、三脚・AZ-GTi・鏡筒と言うかカメラを退避できる。
  • ハード的には、
    • SkyNew社のM2S・M3S
    •  ベアボーンPC Desk Mini 110/B/BB
    • ASUS Vivo Book
    • ASUS ZENBook
      全て、同じ症状になるので、最初は、ディスプレーもキーボードもマウスも接続してあるベアボーンPC Desk Mini 110/B/BBを、我家最速PCの隣に置こう。
  • 雨でも降らない限り、防水カバーを掛けて、三脚・AZ-GTi・鏡筒は、出しっ放しで良いな。(笑)

接続は、system_logなども収集したいので、先ず、Localhostでテスト。
USB3.0+セルフパワー5mケーブルを2本延長すると、南側庭の中にセットできる。もちろん、セルフパワーケーブル付属のACアダプターを、2か所付ける。

昨夜から、海外の掲示板などを徘徊してるけど、特段、重要情報が見つからないのが辛い。(笑)

オヤジ について

昔、柔道4段、剣道3段をいただいた切り、何も貢献できてません。 最近は、天体観測・ロードバイク・DIYに明け暮れてます。 Line、FBは、嫌いなのでやりません。 残された人生を、素直に楽しく生きたいと考えてる60代のオヤジです。 Kanagawa pref. Japan
カテゴリー: INDI, 日記 パーマリンク

25 Responses to オヤジのINDI環境の不具合

  1. タック のコメント:

    オヤジさんが見つけられたLogは下記のもの(2年前ですが)ですか? だとすると遅いマシン上で発生するタイミングエラーのようですね。
    https://www.indilib.org/forum/general/2281-kstars-crashes-during-session.html

    この手の問題は厄介ですね。M3S上でも起こるんでしょうか? 

    Radek Kaczorek さんは Show Equatorial Gridlines on Setup tab in Ekos the KStars を選択するとこの問題が再現する言ってらっしゃるようですが、オヤジさんはGridline の表示を選択していらっしゃいますか?

    私のThinkPad X230 は 2013年製 の古いものですが仕様的は i7-3520M@2.9GHz, RAM 16GB, SDD 500GBという比較的高速なものなのでこの問題に遭遇したことはありませんが、タイミングの問題ならそのうちに遭遇してもおかしくありませんね。 

  2. タック のコメント:

    オヤジさん、 2019年9月にもう一つPostがあって、

    Turn on “Resource Limited Mode” in FITS options. と書かれているようにこのOptionをOnにすると正常に稼働するとGuillem さんは述べていますね。
    これもMemoryの使用率に関係するようですね。

    いづれにしても晴れないと実験できませんね。

    • オヤジ のコメント:

      ありがとうございます。
      これは、気が付きませんでした。
      GPVだと、今夜2時間位星が見えると嬉しいのですが。(笑)

  3. オヤジ のコメント:

    log、確かに2年以上前の物でした。(汗)
    色々、crashで検索すると出てきますね。
    2カ月前位から、遊びでも良いので、アライメントモジュールと同時に立ち上げてみれば良かったですね。
    確か、ASTAPを最初に使った辺りでは、何もcrashは起きなかったのですけど。
    ①ASRock Intel H110搭載 ベアボーンPC Desk Mini 110/B/BB
    Pentium G4560,16GB、SSD500GB
    ②ASUS ZENBOOK BX310UA-FC1001T(8GB SSD250GB)
    ASUS VivoBook(Win10home) 4GB eMMC64GB
    他、色々あるのですが、全く同じ症状です。(笑)
    今夜、少しテストできそうな夜空なので、すでにUSBケーブルを引っ張りました。
    それに、1台だけ、インストールパッケージを変えてみました。
    これで、2台3台の比較すると、何か出て来るかもですね。
    >Gridline の表示を選択
    この画面で、導入できたか確認しているので、グリッド表示にしてます。
    グリッドって、そう言えば使わないことは、無かったような。
    今夜は、居間の隣のPC部屋なので、ノンビリテストしてみます。
    何時も、情報、ありがとうございます。

  4. T-Studio のコメント:

    どのような使い方をされているのでしょうか。
    アライメントモジュール(Solver)でSolveしながら、同時にキャプチャも行うということですか?

    モジュール自体は機材の構成分すべてたちあがっていますよね。
    Solverの解析が終了してからキャプチャーモジュールでキャプチャしても問題でますか?

    • T-Studio のコメント:

      どのようにお使いになりたいのかをいただければこちらでもちぇっくしてみますよ。

      • オヤジ のコメント:

        >どのような使い方をされているのでしょうか。
        作業手順ですが、オヤジの使い方と言うか、常時、カメラモジュールのloopingで、鏡筒が動いて星が流れるのを確認したいんですよね。(笑)
        ですので、loopingしながら、ガイドモジュールを開いて、gotoした星の最後の導入でsolveしてます。
        長焦点鏡筒の時の癖といいますか、鏡筒が動いた・止まってるを確認したいのですよ。
        今、上に追記して画面コピーも張り付けました。
        上手く行ったようです。
        何時も、申し訳ないです。

        • T-Studio のコメント:

          オヤジ様
          その使い方だと、ガイドカメラ、撮影カメラの2台で両方のカメラがループ状態にあるということでしょうか?
          Solverを使用するときは撮影カメラのループは外さないと2つのモジュールで一つのカメラを同時に別の操作を行うことになってしまいます。
          Solverを使用するときはキャプチャモジュールのループは止めて使用(と、いうかソフト側で排他処理してほしい項目ですが)でお試しください。
          (違っていたらごめんなさい)

          • T-Studio のコメント:

            追記ですが、アライメントモジュールでの操作の場合はオプションボタンにあるダウンサンプリングを2〜4に設定してピクセル数を少なくしたほうが圧倒的に処理が早くなります。(Astrometry.netの場合)
            ビニングも行うと感度も稼げるので露出秒数をへらすことができます。(更にピクセル数が減ります。)
            ASTAPを使用する場合は縦のピクセル数が1000〜3000以内にする必要があるようです。
            (ビニングやダウンサンプリングで調整)
            両者で設定の方向が異なりますが、ピクセル数の多い天体カメラをご使用の場合はASTAPのほうが処理が速いようです。

            上記の通りキャプチャモジュールとアライメントモジュールでは設定が異なることになります。(片方は撮影用、片方はSolver用)
            なので、排他的に使用する必要があると思いますよ。

          • オヤジ のコメント:

            久しぶりに、大ボケ、かましましたね。
            前に、撮影カメラで、ルーピングしながらsolveができるんだ!と感心していたんですよ。(汗)
            だから、キャプチャーで、一枚撮りの時はCrashしなかったんですかね。(笑)
            段々、自分のやった事が可笑しくて可笑しくて。
            よく解りました。
            でも、今夜は、両立したんですよね。
            solveが成功したら、一枚撮りで確認。
            この手順でやります。
            ありがとうございました。

          • オヤジ のコメント:

            >ダウンサンプリングを2〜4に設定
            明日は、解析の速さとかも実感したいと思います。
            楽しみです。

        • T-Studio のコメント:

          オヤジ様
          そのような操作ができてしまうのがバグとも言えます。
          ドライバ自体はデフォルトでAscomのPothHub状態なので複数のアプリで同時に立ち上げできますが、一つのドライバで制御するのは一つのソフトのみです。
          (同時に立ち上げて切り替えて使うことは可能です。)

          Ekosは複数の機能が異なるアプリの集合体として捉えると手順を組みやすいかと思いますよ。

          • オヤジ のコメント:

            先ほど、タックさんへのコメントも、勉強になりました。
            商品開発でも、作者が意図しない使い方をして怪我をしたとか。
            怪我をしたのが「おばかなオヤジ」でした。
            この事件(爆)は、印象深いので、もう誤った操作はしないと言うか、改善した作業手順を身に着けたいと思ってます。
            Windowsで多発したUSB認識不安定、あれから解放されて、もう、他には移れません。最終形のシステムになってきました。
            5年掛かりましたが、これからは、星の勉強+撮影の本来の天体趣味の世界に成れそうです。
            ご親切に、沢山の事を教えていただきました。
            引き続きよろしくお願いします。

          • T-Studio のコメント:

            オヤジ様

            私も過去にPark機能にやられました。(苦笑
            そういった不具合部分の回避も必要ですね。
            (私が一番欲しい機能は すべての制御をストップ ボタンです。(笑))

            • オヤジ のコメント:

              solveして、キャプチャーモジュールで、一枚撮影。
              出来ていたのですよ。(笑)
              まあ、今夜、solveの挙動最終確認ができたら、次は、PHD2はヤヤコシイので、ガイドモジュールでガイド出来れば簡素化されてベスト。
              これを、何とか年内にマスターしたいです。

        • T-Studio のコメント:

          オヤジ様

          オヤジ様の環境ならASTAPの方が高速に動作するかもしれません。(上記縦1000〜3000ピクセルにダウンサプルやビニングで調整する必要がありますが。。)

          Astrometry.netのローカルサーバは画像のピクセル数が少ないほうが高速に処理します。

          私のEAA環境(NanoPiM4,ZWOASI120MC)ではAstrometry.netだと解析に4秒かかりません。
          しかしASTAPはピクセル数不足なのかエラーが多いです。

          • オヤジ のコメント:

            ASTAPは、時々、成功していたので、どちらかと言うとASTAPを使うことが多かったです。
            >上記縦1000〜3000ピクセルにダウンサプルやビニングで調整する必要がありますが。
            これは、ガイドモジュールのoptionsのASTAPの「Down Sample 」で調整するのだと思います。
            星が見えそうな天気が数日続くので、楽しみです。

            • T-Studio のコメント:

              オヤジ様
              ASI120MCだと最大のピクセル数でも縦1000に届かないんですよ(960)最大だと成功率が上がりますが、ダウンロードなどに時間がかかるのでAstrometry.netと大差ない状態になります。(Astrometry.netではASI120MCでもビニング2☓2、ダウンサンプル2を併用できます。)

              オヤジ様のカメラならビニングが一番効果を感じやすいかもしれません。(画像の転送量が減るので)

              • オヤジ のコメント:

                ありがとうございます。
                保有してる冷却CMOSカメラは、ビニング4×4設定できますね。
                追伸です
                昨夜の、どたばたテストで解析の範囲30度を、1度目のsolveに成功した後、10度にしてみました。
                早かったです。夢のような処理機能です。実感しました。

  5. タック のコメント:

    オヤジさん、T-Studio さん、おはようございます。

    確かに2年前のLogにもMulti-thread環境下でFITSファイルの排他制御がうまくできていないのでクラッシュするとも読み取れますね。さすがT-Studio さんは鋭い!

    ちなみに私の頭脳は Single-thread なので、SolverによるAlignmentが完了した後撮影という順番なのでsequential 処理です。よってクラッシュには遭遇していない模様です。

    • オヤジ のコメント:

      タックさん
      何時も、為になる情報ありがとうございます。
      実は、INDIを知った当初(今年の5月頃)最初は、mountの制御が出来るか、そこから入りました。
      ですが、日周運動に入ってくれなくて、ジワジワ鏡筒が動いていて、冷却カメラに挿していたUSB3.0ケーブルが架台にブツかってコネクター部分が90度折れ曲がり。
      PARK機能にも驚いたのですが、T-Studioさんに詳細をお聞きしたり。
      そんな訳で、ニワトリ中は、別立てで、主カメラで鏡筒の動きを追っかけないと不安でした。
      そんな流れで、誤った手順でINDIを使っていたようです。
      solveで真ん中でも、少しずれていても、入っていれば、キャプチャーモジュールに移動して、ターゲットを真ん中に入れたり、脇役の星との構図を考えたりと、出来る訳ですもんね。
      1つのカメラ(主カメラ)で、2つの動作を行わせる・・・・今のソフトウェア―技術を使えば出来るのかな!!!と言う疑問は、頭の片隅に有ったのですが。(笑)
      胸のつかえが取れました。
      早速INDI web server 用のケーブル作りをしてます。
      一歩前へ。です(笑)

    • T-Studio のコメント:

      タック様
      むしろこのようなインターフェイス上の対策不足がINDIやEkosで注意するところです。
      フルオートで制御できますが、設定などしっかりしていないとフルオートで機器を壊す可能性もあります。
      そうならないようにするにはユーザー側でフルマニュアルで設定の確認や調整をする必要があります。
      (それができてしまえば完全に安定します。)

      3年ほど前に大幅な機能追加されたときにStellarMateが発売されましたが、個人的には上記の理由で時期尚早だと感じました。

      • タック のコメント:

        オヤジさん、 T-Studio さん、

        (ちょっと目を離したすきにたくさんPostされていたので、どこに返信してしてよいのやら・・・)

        必要なDevice(Resource) を登録して、UIからそのResourceを利用して機能を実現するというDesignは、拡張性が高く感心しています。おっしゃる通り、それぞれの機能からResourceを利用にする際に発生する競合のシナリオに対するDesignはまだ不十分だと思われます。個々の機能は素晴らしいので使い方の工夫をする必要がありますね。

        PS: 「様」は恥ずかしいので「さん」で十分です。

コメントを残す

メールアドレスが公開されることはありません。