「PIC AVR 工作室」サイトの日記的なブログです。
サイトに挙げなかった他愛ないことを日記的に書き残してます。
PIC AVR 工作室 ブログ



先日windows7でネコロジーを使いたいって思って
久々に動かしてみたら動かなかった件。
http://brown.ap.teacup.com/nekosan0/1182.html

シリアル経由でのI/Oが追いつかなかった対応を
色々やってみたんだけど、とりあえず安定して
動くようになったみたい。


最初に試してみたのは、ファーム側、PCソフト側とも
XON/XOFFに対応させてみること。

→やっぱりデータがあふれちゃって、途中で送信がNGに。

うーん、ソフトやファームのバグか?と思って調べ
直してみるも間違えはなさそう。

PC側のXON/XOFFは、VBのプロジェクト編集画面から
シリアルI/Oオブジェクトのプロパティー設定を開いて
弄ればOKのはず(プログラム実行時にドライバの設定
をこの内容で弄りなおす)なんだけど、一応コンパネから
ドライバの設定を見直してみると…

詳細設定にレイテンシの設定があったんだなぁ。見ると
16msになってる。ってことは、xoffをPC側ドライバが
発行しても、16ms経ってからようやくAVR側に送信される
ってことだよな?1msに変更してみる。

…動いた。取りこぼし無く取り込めた。しかもなんだか
ちょっと取り込み速度が速いな。

もしやと思って、VBの編集画面でXON/XOFF制御から
フロー制御なしに変えてみて、実行。

…動いた。


???何じゃこりゃ?

AVRからの送信は矢継ぎ早に…考えられる範囲でのフル速度
で行っているので、レイテンシが何ミリ秒に設定されて
いたって、USB-シリアル変換ケーブル内のバッファが一杯
になった都度PC側に送信されるんじゃぁ無いのかな?
それならレイテンシの設定変えるだけで動くようになる
はず無いんだけど。

なんだかつじつまが合わん…。


でもまぁ、なんにしてもゲイツ君にあらぬ疑いをかけて
しまってゴメン。多分ゲイツ君のせいじゃぁ無いよ。


ザックリ計算しなおしてみよう…。
115200bpsで16ミリ秒の間にAVRから何バイト出力されるか
というと、計算では184.32バイト。1ミリ秒では11.52バイト。
受信バッファは4096バイトに設定してあるんだけど、
どの段階でドライバがXOFFを送信しているかに因るのかな。

仮にバッファ残量5%程度でXOFFを送っているとすると、
およそ200バイトを割ったところで発行しているはず。
16msだとギリギリかもしれん。タイミングとバッファの
使用具合によっては確かにエラーが出るかも知れん…。

まぁ、115200bpsなら1msにしておけばXOFF制御でも
なんとかなりそう。


それにしても、16msにしただけでなぜAVR→PCの通信
速度が速くなるんだろう?散発データなら解るんだけど、
AVRから送信するデータは連続データだからなぁ…。
そんなはずは無いんだけど…


でもまぁ、ドライバの設定をフニャフニャすれば
ネコロジーのプログラム自体はそのままでもちゃんと
使えることが判った。シメシメ。


http://headlines.yahoo.co.jp/hl?a=20101222-00000006-maiall-bus_all
オイラのホンダ。ジェット機がテスト飛行に成功とのこと。
市販化までこぎつけるといいなぁ。

http://headlines.yahoo.co.jp/hl?a=20101223-00000009-jij-soci
こういう基礎研究が将来の医療進展を進めるといいなぁ。
メカニズムは大事だよな。思いもよらない応用範囲が
有るかもしれないからな。蛍光発光するクラゲみたいに。

http://nazunalab.blog.so-net.ne.jp/2010-11-28
ポルタを2軸モーター駆動の赤道儀にしちゃうのはすごいな。
http://nazunalab.blog.so-net.ne.jp/2010-11-07
PWMのデューティー比と電流は比例すると思ってた
んだけど、そいうじゃぁないのかな?ホント?



コメント ( 0 )
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする




天に見放された昨日とは打って変わって、今日は
すっかり晴れて、しかも北風に変わり始めたせいか
湿度も下がってきて、かなり夜空がきれい。

ってことで、0.5秒悩んだ挙句、完成品を近所で
ちょっぴり試してみることに。

とりあえずファーストライトとして写ってきたのは


お月様がオリオンの間近、ふたご座なので青空みたい
になってるけど…。星を撮るのが目的じゃなく、性能
チェックが目的なので…。

2分20秒ほどの露出時間。焦点距離45mm(銀塩換算
約68mm)

左下の大きな白いのがシリウス。右中央に3つ並んでいる
のがオリオンの三ツ星。その下の赤で囲ったところが
小三ツ星。小三ツ星付近を画素等倍で切り取ったのがこれ。



かろうじてM42と判るぎりぎりの線。ちょっと流れてるかな…


で、とりあえずほぼ点像に近い写真が撮れそうな事は
判った。目分量で適当に極軸合わせてみたけど、大体
合ってたみたい。よかった…。

だけど、実は色々と紆余曲折。やっぱ使ってみないと
欠点は見えてこないんだな…。ハードウェア側のバグ。


致命傷は、この写真を撮るちょっと前に発覚。というか
本当の最初の1枚は致命的な欠点によって失敗作に。
なにかというと、カメラを載せた時に重量で生じるひずみ
をどう逃がすかってことが設計上加味されて無かったこと。

正確に言うと、設計時には加味してはいたんだけど、まさか
ここまで… というのが正直なところ。

↓これは昨日の写真に赤く矢印書き入れたもの。


カメラを搭載すると、カメラの重量によってこの赤い矢印
のように微妙にウォームホイールが当初の想定以上に
ウォームネジ側に圧されて、ギヤ同士の摩擦がでかくなって
脱調を起こしてしまってました。

写った写真を見ると追尾が全然できてない状態。とりあえず
モーターのトルクはスペック的に精一杯でこれ以上はどう
しようもない。そもそもトルクがでかいからokってわけ
でもなく、適量の軸間距離を保たないとピリオディック
エラーが生じちゃうので、ナントカしないとイケナイ。

その場でできる打開策を考える…

筐体を90度横にクルッと回してみよう…そして力を受け流す
方向をウォームギヤの軸と平行にしてみよう…と。


で、その結果冒頭の写真になったんだけど、重量的に
というか構造的にというか、重さの支え方がイマイチ
不安定な姿勢。
姿勢は大事。ちょっとゆるい風が吹いてきても、姿勢が
悪いとすぐに揺れちゃう…

もっと困るのは、折角極軸合ってたのに、ニーニッパレンズ
に載せ変えた途端重量に耐えられなくなり、全体的にしなって
極軸が明後日を向いちゃう。200mm端(銀塩300mm相当)
では信じられないくらいに追尾エラー…。

まぁ、そもそも長焦点の重たいレンズは前提としていない
んだけど、ここまで構造上よわいとすると、さすがに
ちゃんと考えないと実用的にどうなのよ…と。カメラ
リュックにポンッと入るのはいいんだけど、実写に
向かなけりゃ意味無いからなぁ。


抜本的な解決として今考えているのは、ベースになっている
アルミ板上のレイアウトの変更。全体のレイアウトは縦長の
ままで、でもウォームネジは横側に持ってくる形にしたい。

それならカメラが載ったときでもウォームホイール
とウォームギヤの距離に影響する方向には力が加わらず、
かつ重量はストレートに三脚に逃がすことができるので、
重量の増減が極軸にあまり影響及ぼさないはず。


また穴あけやり直さないといけないかもしれない…
11mmの穴開けなおさないで済ませられないかなぁ…
それともハンズでアルミ板買ってくるか…?

とりあえずハード面で設計しなおさないと致命的なのは
この1つだけ。他は色々改善が図れるところだから
特に問題なし。

それにしても、頭の中でかすかに疑問を感じていたところ
って、大体テストしてみるとしょっぱなに顕在化するもの
なんだよな…。テストっていつもそうだから不思議。

うーん。なんとかなるといいんだけどな…。



コメント ( 0 )
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする