« 2016年2月 | メイン | 2016年4月 »

2016年3月

2016年3月28日 (月)

digiCamControlの外部トリガー用リレーボックスの製作

PDH2でのディザリングを調べていたら、以前書いたニコンカメラをコントロールできるフリーソフトのdigiCamControlとの組合せで自動ディザリングができることがわかりましたが、私の天体写真撮影の主力機のNikon D5000がdigiCamControlでのバルブ撮影に対応していない(USB経由でのバルブ撮影コマンドがない)ので、利用はできないものと思っていました。

しかし、さらに調べてみると、digiCamControlには外部トリガーを使用するための仕掛けが用意されており、USB経由で可能となることがわかりました。
その接続方法は、下図のとおりです。

Photoこれ用の外部トリガー用リレーボックスに相当するものとして、digiCamControlのホームページにも対応製品の紹介がありますが、簡単そうなので自作してみました。

digiCamControlの設定は、「setting」の「Devices」を選択し、「add」をクリックして、下の画面で新しいデバイスを登録します。

Digicamcontrol_deviceConfiguration na・・・適当な名前を入力
Driver・・・・・・・・・・・・・・USB Relay Releaseを選択
Com port・・・・・・・・・・・有効なポートを選択
Init sequence・・・・・・・適当な数値を16進数で入力①
Shutter On・・・・・・・・・・適当な数値を16進数で入力②
Shutter Off・・・・・・・・・・適当な数値を16進数で入力③
でOkをクリックすれば、デバイスの登録は終了です。

天体写真モードで「EXTERNAL SHUTTER RELEASE」でUse configuを設定したデバイスを選択し、Enableにチェックを入れれば、動作するようになります(下の画面)。

Digicamcontrol_device2実際のシャッター動作では、シャッターオン時に上記で入力した①②のデータが送信され、シャッターオフ時には③のデータが送信されます。

これをArduinoのシリアル通信で受けて、シャッターを開閉するリレーを動作するようにすればよいことになります。

これを最近使い慣れているArduino nanoで動作させるようにしてみました。シリアル通信ができればなんでも良かったのですが・・・。

スケッチ(プログラム)は非常にシンプルで、LEDチカチカに毛の生えた程度です。

--------------------------------------------------------------------------------------------
// リレー接続ピン
#define RELAY_1             4
// モニターLED接続ピン
#define RED_1                2
#define INIT_CODE1   0x51
#define INIT_CODE2   0x00
#define SHUTTER_ON  0x41
#define SHUTTER_OFF 0x40

void setup() {  
     Serial.begin(9600);  
// USB接続では、この待ちルーチンが必要
     while(!Serial);
     pinMode(RELAY_1,OUTPUT);
     pinMode(RED_1,OUTPUT);
}

void loop() {
  unsigned char val[4];
  int              i,n;
  n = 0;
  while(1){
       while ( Serial.available() > 0 ) {
          val[i] = Serial.read();
          n += 1;
       }
       if ( n != 0 ) {
          // シャッター開動作
          if ( (val[0] == INIT_CODE1) && (val[1] == INIT_CODE2) && (val[2] == SHUTTER_ON) ){
                 digitalWrite(RELAY_1,HIGH);
                 digitalWrite(LED_1,HIGH);
          }
          // シャッター閉動作
          else  if ( val[0] == SHUTTER_OFF ){
                 digitalWrite(RELAY_1,LOW );
                 digitalWrite(LED_1,LOW);
          }
          n = 0;
      }
  }
}
------------------------------------------------------------------------------------------------

でも、最初setup()の「while(!Serial);」の待ちルーチンが必要だということが分からず、1回目の動作部分の通信データが取れなかったり、データの先頭0x51が取れなかったりと動作が不安定でした。

Arduino IDEのスケッチ例を見てみたら、この注意書きをみつけました。
この待ちルーチンを挿入すると、嘘みたいに安定して全てのデータが受信できました(当然なんでしょうが)。

このリレーボックスの出来上がりの写真です(用意したボックスに納まらず裸のままです)。

20160328_3297Arduino nanoを使うまでもなかったのですが、これだけでUSB経由のシリアル通信が出来ること、互換品ですので750円と安いことから、まあーいいかです。

これで、天体写真メイン機のD5000でもdigiCamControlでの撮影が可能になり、PHD2と連携してディザリング撮影もできることになります。

でも、実際の撮影で有効かどうかは試してみるまでわかりません。

それと、この撮影方法では、USBが3ポート(PHD2,digiCamControl,リレーボックス)必要になりますが、私のレッツノートは2ポートしかありませし、せっかくコントローラの7号機でケーブルの整理をしたはずなのに、またまたケーブルが増えてしまいます・・・・・。

ですから、作ってはみたものの実働するかどうかは未定です。

実は先日コメントいただきましたリュウさんのブログで、OnStepと言う望遠鏡コントロールソフト(Arduinoベースでプログラムはオープンソース)を知り、そのASCOMドライバを使えば、自分のコントローラでも自動導入ができるのではないかと思ったこともあって、Arduinoでのシリアル通信にトライして見たわけです。

最初はうまく送信されてくるデータを拾えませんでしたので、半ばあきらめたけていたのですが、先に書いた待ちルーチンできっちり受信できるようになりましたので、試してみる素地は出来上がりました。

まあ、これについては、おいおいと進めることにして、また別の機会に書きたいと思います。

2016年3月18日 (金)

SP赤道儀用一軸制御コントローラ8号機(3)~PEC機能の検証~

SP赤道儀用一軸制御コントローラ8号機についての続きです。

前回のテストでは、平均的速度は恒星追尾速度にほぼ一致させることができましたが、ピリオディックエラーキャンセラ機能(PEC)については、PICマイコンのプログラムミスがあったため検証できませんでした。

PEC機能の検証のまえに前回のデータを使い、数値シュミレーションをやってみました。
実装するPEC機能の原理もわかると思いますので、その結果を載せておきます。

Pec前回のデータでは下りカーブの部分(時間として0~300秒部分)がやや不規則なことを反映して、この部分の打ち消しが不充分なため、±8秒程度になることが予想されました。

さて、実際にPEC機能を働かせた結果が下図です。

Pec_2グラフでわかるとおり、予想以上にPEC機能の効果があり、1周期(600秒)で±5秒程度、後半の400~600秒を除けば、±2.5秒程度にピリオディックエラーを押さえ込むことができています。

私的には、上出来だと思います。
これで、180mmクラスだと長時間露出も可能になると思います。
あとは、実際に撮影して、再現性を確認することが必要です。

それとSP赤道儀の調整について気づいたこと。

SP赤道儀のウォームギアの取付・調整についてです。

20160318_3296ウォームギアボックスとモータを実装している部分の写真です。

この調整箇所はウォームギアボックスの両側の①イモねじ、正面の②押しねじ(イモねじ)、③引きねじ(キャップボルト)の3箇所で調整することになります。
私は、ウォームギアボックスを押し当て、①のイモねじをなるべく均等になるように軽く締め後、③の引きねじを調整し、その後②の押しねじで調整しています。

この調整中は、ウォームギアを回し、重くならないように調整するのですが、これらのねじを最終的に締めつけるとバックラッシュが相当ある状態(ウォームフォイルに強く押しつけていない状態)でも回転が非常に重くなってしまいます。
これは、各ねじをきつく締めつけるとウォームギアボックスが変形し、結果として重くなってしまうのではないかと思いいたりました。
そこで、今回は、バックラッシュが少なくなる位置に調整後は、ウォームギアの回転が軽いままとなるよう、各ねじの締め付けを軽くすることに心がけてみました。

結果として、この調整方法がよかったのかどうかわかりませんが、極軸後端の止リングを含めあまり強く締めつけない(と言うか、ガタつかない程度に緩く締める)のが良いのではないかと思っています。

また、私のモータ実装方法では、ウォームギア軸とモータ軸の中心が一致していることが重要となりますので、④モータ取付ねじ、⑤モータ架台取付ねじ、⑥赤道儀への取付ねじ部分も若干の調整ができるようにしています。
そこで、ウォームギアボックスの取付調整が終わったあと、モータを取付ても、ウォームギアの回転が重くならないようこれらの締め付け位置を調整して固定しています。

今回の調整では、これらの各部の調整を慎重に行いましたので、結構軽く回転できる状態でセットでき、自分的には満足できる調整だと思っています。

後は、8号機を小型化したケースに収容すべく、基板の小型化に取り組むことになります。

2016年3月16日 (水)

SP赤道儀用一軸制御コントローラ8号機(2)

SP赤道儀用一軸制御コントローラ8号機についての続きです。

前回のテストでは、全体の速度がやや遅いことが判明し、これを補正するのに、使用しているPIC12F629のTimer1のレジスタ値を+12すればよさそうだというところまででした。

その後天候に恵まれず、やっと前日テストすることができました。

その結果が下のグラフです(テスト方法は前回と一緒です)。
SP赤道儀の調整も慎重にやり直した結果です。

Photoグラフはきれいになり、全体の速度もほぼ恒星追尾速度に一致するようになりました。

これでみると、私のSP赤道儀と自作コントローラ組合せでの精度は±20秒といったところでしょうか。

このピリオディックエラーをソフト的にキャンセルする機能を付けようとしているのですが、これは非常に単純で、速度変化を打ち消すようにサインカーブ状の速度補正値を入れて対応するものです。

具体的には、ウォームギア1回転を360に分割し、1/360毎(1.667秒毎)に速度補正値を変化させて回転速度を調整しています。

次のグラフは、そのテスト結果ですが、みごとに失敗しています。

Pec1原因は、PIC12F629のプログラム上に単純な誤りがあったためで、全く機能していませんし、全体の追尾速度は早くなってしまっています。

※赤丸部分は効果があるように見えます。

プログラムの誤りは判明しましたので、次回のテストへ繰り越しですが、ここにきて関東地方は、晴天が長続きしなくなってしまいまい時間がかかりそうです。

2016年3月 4日 (金)

SP赤道儀用一軸制御コントローラの改造(準備/SP赤道儀の追尾精度の検証)

SP赤道儀用一軸制御コントローラの改造について(8号機)についてです。

8号機は6号機の機能(カメラのシャッターコントロールとそれに伴って必要なボタン及びLCDキャラクターディスプレイ)を削除するものですので、コントローラの基板は転用の形となりそれほど手間をかけずに済みます。

そこで、SP赤道儀用一軸改造版(ポタ赤化とはいいにくい大きさ)での追尾精度について検証してみました。

検証環境は、
ガイドスコープ φ60mm F240mm
ガイドカメラ     QHY5L-II
ガイドソフト    PHD2
を載せて(撮影用カメラは載せず)、赤道上の子午線付近にセットして、若干の東側ウェイトで行ってみました。

テストでは、北極星が望めませんので、PHD2のドリフト機能を使い極軸をセットした上で、ガイドをオフにして追尾精度を記録しました。

まず、未調整での追尾精度です。

Photo4回分のデータについて、ある程度位相が揃うように並べています。
ログファイルの「RARawDistance」を使っていますので、+側に振れた場合追尾遅れを示しています。

このグラフを見ると、
・ピリオディックエラーは大きい(±30秒?)が、グラフ毎の個々の凹凸は、結構相似していること。
・全体として右上がり傾向で、追尾速度が遅くなっている。
・近似直線でみると、0.028秒/秒(1.67秒/分)程度速度が遅い。
ことなどが見て取れます。

そこで、まず、この追尾速度の調整からすることにしました。

モータコントローラは3号機以来、同じ手法によっていまして、モータドライバ(L6470)のステップモードを使用し、モータの回転速度は、PIC12F629(20MHz動作)のTimer1割り込みを使って、TMR1レジスタの初期値を設定し、割り込み間隔を調整して一定の周波数で発生させたパルスによって制御していますので、このTMR1レジスタの初期値をわずかに増減させて試してみました。

調整値を入れた結果が次のグラフです。

1今度は、過修正で、0.042秒/秒(2.50秒/分)速くなってしまいました。

この時はTMR1レジスタの初期値を+30していますので、両方の結果から+12でほぼ速度誤差がなくなるものと考えられます。

駆動用パルスの周波数については、正確な周波数カウンタを持っていませんので、テスタと簡易型オシロスコープで0.1Hz単位で見ていました。

パルス周波数は
計算値(設定値) = 85.57Hz              
テスタ計測値     = 85.5Hz
で、漠然と合っているだろうと思っていたのですが、実は、駆動用パルスの周波数の0.1Hzの誤差は、1.04秒/分の速度差となり、赤経軸の1周期(10分間)では10秒の誤差となって現れることになります。

改めて微妙な世界であることを痛感しました。

上記の速度誤差を修正するためのTMR1レジスタの「+12」については、実は、こうしたクリティカルなパルスを割り込み処理でつくる際には当然考慮しておくべき、PICの割り込み処理においる必要なCPUクロック分だと思われます。

取りあえず、総体的な追尾速度についてはこれで解決するものと思っていますが、ピリオディックエラーが大きく、かつバラツキもありますので、次の段階に進む前に、SP赤道儀の分解・調整をやり直してみます。

今回から、ガイドフソトとしてPHD2を使っていますが、前にちょっと使ってみてPHDに比べ設定項目が多くとっつきにくかったのですが、今回の検証作業で、実用上支障が内程度まで習熟でき、PHDより使い勝手がよいことがわかりました。