« 2016年1月 | メイン | 2016年3月 »

2016年2月

2016年2月20日 (土)

性懲りもなく、赤道儀モータドライブ用自作コントローラの改造

先週は、11~14日に帰省して、機材調整、あわよくば遠征もと思っていたのですが、帰省前日の9~10日は快晴となったものの、以後は曇り/雨と天候はままなりません。

機材の調整、主にBKP150の光軸調整とスパイダー隠しの仕上げを行ったのですが、実写ができずに調整結果の確認まではできませんでした。

ほんと、福岡市が日本海側気候であることを思い知らされた次第です。

5月の連休までは帰省の予定が立たないので、この期間は単身赴任先で機材(主にコントローラ)の改善に当てたいと思っています。

そこで、SP赤道儀を改造した一軸ノータッチガイド機一式を単身赴任先に送り、コントローラ7号機の製作と平行して、一軸制御コントローラの改造に取り組むことにしました。

目標は、コントローラを小型化し、赤道儀にキチッと搭載できるようにすること、ピリオディックモーションキャンセラー機能を搭載し、180~300mmの長時間露出を可能にすることです。

ここで、改めて今までに作成した赤道儀モータドライブ用自作コントローラの変遷についてまとめてみました。

【自作コントローラの変遷】

  1. < 1号機>
    ・タンジェントスクリュー式式用
    ・ユニポーラ型ステッピングモータ
    ・モータドライバ STK672-050   
    CPU PIC16F886 モータドライバ STK672-050の動作が不安定で、マイクロステップが機能しない。
    動作不安定の原因は、外付け回路の不備が原因と思われたが、追求せず、新しいドライバ(外付回路不要)を選択。
  2. <2号機>
    ・タンジェントスクリュー式用    
    ・バイポーラ型ステッピングモータ    
    ・モータドライバ L6470    
    ・CPU Arduino Uno
    モータ回転はスムースになるも、タンジェントスクリュー式に限界(撮影可能時間、追尾精度)を感じ、放棄する。
  3. <3号機>
    ・ウォームホイル式用   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換) + PIC12F629(モータ駆動パルス発生用)    
    ・シャッタータイマー機能付き    
    ・結露防止ヒータ温度制御機能付き
    モータコントローラの構成・機能は本機でほぼ完成、これ以降のコントローラはこの構成を踏襲。
    ほぼ、意図どおり動作するも、ギア等の機械部品の精度からか再現性に乏しく、追尾精度が向上しない。市販赤道儀の改造へ方針変更。
  4. <4号機>   
    ・ナノトラッカー用   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換)    
    ・シャッタータイマー機能付き
    ナノトラッカーの精度向上を目指して導入するも、再現性が悪く放棄。 現時点で考えると、再現性の悪さの最も多いな原因は、カメラを搭載機構(雲台を含めた)の強度不足ではなかったかと思われる。
  5. <5号機>   
    ・SP/GPD赤道儀用二軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換) +  PIC12F629(モータ駆動パルス発生用)    
    ・オートガイドへ対応    
    ・天体導入補助機能付き    
    ・シャッタータイマー機能付き    
    ・結露防止ヒータ温度制御機能付き
    焦点距離1,000mmでもオートガイダー使用でほぼ満足できる精度がでており、機能的には満足できたが、コントローラの操作性が悪く、使い勝手に不満が残った。
  6. <6号機>   
    ・SP赤道儀用一軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換) + PIC12F629(モータ駆動パルス発生用)    
    ・シャッタータイマー機能付き
    ほぼ、意図どおり動作するも、赤道儀への搭載方法、ノータッチ追尾精度に180mmカメラレンズでも露出90secが限界と不満が残る。
  7. <7号機>(5号機の改善版、製作中)   
    ・GPD赤道儀用二軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU Arduino nano + PIC12F629(モータ駆動パルス発生用)    
    ・天体導入補助機能付き    
    ・シャッタータイマー機能付き    
    ・結露防止ヒータ温度制御機能付き
    本体/手元コントローラに分割し、操作性の向上を意図している。
  8. <8号機>(6号機の改善版、製作中)   
    ・SP赤道儀用一軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU Arduino nano + PIC12F629(モータ駆動パルス発生用)
    SP赤道儀への搭載のための小型化、PEC機能によるノータッチ追尾精度の向上を意図するのがメイン、小型化のためシャッタータイマー機能を省く。

こうやって見てくると、なにか天体写真を撮ることよりも、電子工作そのものを楽しんでいるのではないかと思えてしまいます。

製作や改造がなくなったら、撮影のモチベーションが下がってしまうのではないかと心配です。

2016年2月 9日 (火)

悪戦苦闘のI2C通信

前回に書きましたようにモータコントローラ7号機を製作中ですが、本体コントローラと手元操作ボックスをつなぐ肝心のArduino同士のI2C通信で泥沼状態を経験しました。

プログラムのデバッグにあたり、I2C通信については、マスタ→スレーブの一方向通信は、LCDキャラクタディスプレイのI2C化で経験していましたが、今回は、双方向通信となるため不安はあったのですが、それが現実のものになってしまった次第です。

今回のブログラムは5号機の改変ですので、デバックは、通信が主体となりますので、確認のためエミュレータをブレッドボードで作成して確認しながら進めました。

20160207_3283作成したエミュレータ

問題は、マスタ側(=手元操作ボックス)からの送信要求に対してスレーブ側(本体コントローラ)が返す結露防止ヒータの温度データがうまく取れないと言うことです。

スレーブ側が返すデータは、モータコントローラのBUSY状態(1byte)、温度制御の状態(1byte)、温度データ(2byte)の計4byteを返すように設定しているのですが、うまく行きません。

Arduinoのスケッチ例を見ても、1byte送信か文字列送信しかなく、複数バイトの送信方法がうまくないみたいです。

最初に書いたスケッチ

viod Send_THermo(){
       Wire.write(L6470_BUSY);                // L6470_BUSY=BUSY/nBUSYの1byteデータ(0又は1)  
       Wire.write(TEMP_CON_NOW);         // TEMP_CON_NOW=上昇/降下/制御なしの1byteデータ(0~3)  
       Wire.write(TEMP_NOW / 0x100);     // TEMP_NOW 温度データ(2byte)(0~600)  
       Wire.write(TEMP_NOW % 0x100);   // 少数点以下1位を有効とするため温度×10のデータとしている
}

結局、これでは最初の1文字だけが送信されるだけでうまくいきません。

色々と試したり、Web上で検索したりした結果、次のように書くべきだと言うことになりました。

viod Send_THermo(){  
     char c[6];

     c[0] = L6470_BUSY;              // (1又は2)  
     c[1] = TEMP_CON_NOW;       // (1~4)  
     c[2] = TEMP_NOW / 0x100;   // (10~600)  
     c[3] = TEMP_NOW % 0x100;  
     c[4] = '\0'; 
     Wire.write(c);
}

とし、文字列のポインタ渡しによる送信でうまく行きそうでした。

※この時点で、各送信データバイトに「0」があると、終端文字と解釈されて、以後のバイトデータは送信なれないことはわかっているつもりでした。

ここに至るまで、3日を要してしまいましたが、なんとかうまく送信できました。

ところが、その他の部分のデバックにかかると、2バイト目まではうまく送信できるものの、肝心の温度データが取れなくなるケースがあり、またぞろケーブルやコネクタの接触不良を疑ったりと際限がなくなってしまいました。

結論は、しごく単純なこと、温度データが256未満(25.6度未満)では、温度データの上位byteが0となって、終端文字と解釈されていただけでした。

つまり、うまく行くときは、結露防止ヒータの温度が26度以上の時で、それ以下になっていると、送信の3yte目が0となって温度データが送信されない状態になっているだけでした。

ケーブルやコネクタの方の不都合ばかりに気をとられ、こんな単純なことに思いが至らなかったことに、唖然とした次第です。

エミュレータで確認しながら作業を進めたのが正解でした。
これで、本番同士で接続して確認していたなら、なにがなにやらわからず、放り出していたかもしれません。

以後のデバッグは多少の紆余曲折はあったももの、概ね順調にすすみ、5号機では隠れていたバグ潰しもできて、ほぼ完成の状態まで仕上がっています。

7号機で手元操作ボックスから本体コントローラへ送信するコマンドは下表のとおり。
これだけで、5号機の機能はすべて動作させることが可能です。

7

さて、今週末は金曜日を有給とし、連休で帰省し、機材の調整とあわよくば遠征もと欲張っていたのですが、案の定、天気予報は最悪を示しています。

2016年2月 7日 (日)

まさかのSDカードデータ消失!!

前回に書きましたようにGPDモータコントローラを置き換えるべく、7号機を製作中ですが、意気消沈の事故が発生してしまいました。

手元操作ボックス側のソフトのデバック作業がほぼ終わり、本体コントローラと接続したデバックを開始したところ、その途中でプログラム、基板図等を入れていたSDカードが突然認識しなくなってしまいました。

ここ2週間近い期間のプログラムが全部パーです。

要因となったのは、手元操作ボックスと本体コントローラとをつなぐ4芯のカールケーブルです。

20160207_3282上が問題のコード
下は、作り直した約1mのコード

一見かっこよかったので採用したのですが、カールしているため短そうですが、実は2m以上あって、これでI2C通信をしたのが裏目に出ました。

プログラムのデバックをやろうとすると、全く動作しません(LCDキャラクタディスプレイに表示されない)。
本体コントローラ側は、初期のL6470チェック部分は動いていますし、I2Cの接続をしないと通信部分は通過して、プログラムは進行していましたので、なかなか原因がわからず、試行錯誤がつづきました。

結局I2C通信線を50cmくらいの短いのに換えたら、正常に通信できるようになりましので、通信で止まる原因が長すぎるケーブルであったことがわかりました。

しかし、通信が正常になったあとも、結露防止ヒータからの温度データがうまくとれません。
温度センサーとGNDの間に5.1kΩの抵抗をいれているのですが、この点(=電圧を取っている場所)の電圧をテスターで計ると0ボルトになってしまっています。

これらの問題点を検証するため、USBの抜き差し、Arduino nanoをICピンから抜き差しするなどを繰り返してしたところ、突然USB接続していたSDカードが認識しなくなったわけです。

このArduno nanoは互換品で、非常に安かったのですが(780円)、内1個が入手当初からUSBMiniの差し込みが奥まで入らず、中途半端だったものです(もう1つの方はチャンと刺さります)。

20160207_3287激安互換品

結局、このArduino nanoもお亡くなりになりました。

分かったことは、I2C通信ができないような長さのケーブルをつないだ状態では、I2C通信のルーチンで待ちになってしまうと言うことです。

また、温度データが取れなかった原因は、以前の回路と接続ピンを変更したことで、シャッター開閉用リレーピンと温度センサーデータ取得用ピンの混同があり、アナログデータ取得用ピンのモードを「出力」にし、初期化(LOW)したピンに対してアナログリードを行っていたことでした。

温度データの本体コントローラ側からの送信(スレーブ側からの送信)については、まだまだトラブルがつづいたのですが、これは後日。

今回も色々勉強させてもらいました。

今回のプログラムは、全く最初から作成したものではなく、現用の5号機から改変したもので、このプログラムはバックアップがありましたので、全くはじめからのやり直しではないのですが、大幅な手戻りとなってしまいました。

また、このデバック作業中に虎の子のL6470モータコントローラキットも端子間をショートさせたみたいで、あえなくご臨終となってしまいました。

このキットは、まだ、秋月電子で品切れ状態は続いています。