カテゴリー : Quadcopter
ようやく、テスト用の基板のためのテスト基板が上がってきました。
USBを何とかしてMPUであるATMega1284Pに認識させてあげないといけないのですがこれがなんだか難しい様でいろいろと悩み中です。新しく作った基板で何とかしたいと思っています。（左から2番目の基板がUSBテスト用）
残りの2枚はMultiWiiにモータードライバを積んだテスト基板と遊びで作ってみたTLC5940用のテスト基板です。この2枚は時間があったら組んでみようかと言ったところですがTLCの基板は遊んでみると面白そうです。
なんだかんだでうまくいかなかったため個別機能を再度テスト基板に起こし直しました。
ブレッドボードでは検証しているのですが部品サイズでどの程度までリフローできるかがまだつかめないのでいろいろなサイズの部品を載せたテスト用基板です。
今回作ったのは３種類のテスト基板
今回の基板ではテスト用に変更しています
設計段階ではこんな感じの3種類を作ってみる予定です。
2，3日眺めてみて修正点が思い浮かばなかったらこのまま注文します。
今回は、前回届いた基板に部品を載せてテストできる環境を作ります。
MPU/FCUには事前にプログラミングアダプタでファームを書き込んだ上で後で手ハンダで載せしました。
■プログラミングアダプタ
その後で、silhouette CAMEOでマスクを作成しましてハンダを塗布して部品を載せてリフローしてみます。
途中、写真取るの忘れて出来上がった基板がこちらです。（ちまちました作業に夢中になっていたら写真を忘れました）
全部入りの基板設計した後で「Fusion PCB」に発注してあった基板ですが1週間程度で到着しました。10枚頼んで11枚入っていました。（やはり小さい文字はつぶれてしまいますね）
リフローの実験まだなので部品載せられないのですけれどテスト出来る状態に来週中ぐらいで組み上げたいと思います。
テストに問題がなければですが、これからの予定としては最小構成のフライトモデルをRev1として制作してテスト予定です。(PS3コントローラーでのコントロール）その後、問題がなければ本命のモジュラー形式で制御系を入れ替えられるRev2を作ってサブボードとして手動制御（Bluetooth/赤外線/PPM）/自律制御の4種類を作成する予定です。
基板構成はどう考えても4層にしないと部品を納められないと思われるので4層を基本として考えたいと思います。ルールを変更して何とかFusion PCBに注文したいところですが、無理だった場合にはPCBCARTでしょうか。
いやいや、設計してPCBCARTに注文しようとしたのですが4層でピッチとかが細かくなると追加料金だそうで、10枚作って驚きの$500越えでした。一発オッケーであることの自信は全くないので、まずはテスト用の基板を作ってテストすることに軌道修正。とりあえずですが全部入りのテスト基板を作ることにしました。
テスト用なので結構ゆるいルールで作ったのでFusion PCBにでも注文してみるつもりです。
詰め込める物は詰め込んで、Eagleで基板の回路設計とかをしてみました。どう考えても乗らないでしょ…。Orz
そう考えると、「Crazyflie Nano Quadcopter」はよくあのサイズに回路を詰め込んできましたね。向こうとこっちの差はCPUの数と無線系の回路ですが、そのあたりが増えている分こちらの方が不利ですね。
ちゃんと機能が動くかをブレッドボードでテストしていますよ。
大枠は固まった感じですが、手半田で付けるとか考えると吐き気がするのでリフロー炉を何とかしてカッティングシートでマスクを作ってとか考えていたりします。ある程度数がはけるのなら少量生産請け負ってくれるところとか探したいのですが小型のクアドロコプターとかの需要はあるんでしょうか？？
Crazyflie Nano Quadcopterが日本で飛ばせないなら作ってしまえと言うことで実験していましたので基本設計とかを考えてみます。手のひらにはのって欲しいのでそのあたりを基準に設計してみますと以下の様なモデルができあがりました。
基板の部分だけを、せっかくあるので3Dプリンタを使って印刷してみるとこんな感じになりました。
いろいろと検証していましたけれども、どうやら本格的に作れそうな気配となってきたので基本構成とかを考えてみることにします。今の処のあくまで想定で作ってみたのですが、LEDアレイ載せるのは厳しそうな予感がします。
本来は簡単にPPM信号でRCデータを入力しようと企んでいたのですが、LED-Arreyを搭載しようとした所どうしてもTLC5940を積みたくなり…。そうすると、タイマーが使えなくなり、同時に割り込みも使えなくなり、PPM入力が不安定なdelay関数やmicros()を使わないといけなくなってしまうためしょうがなく置き換のため検討。たかだか、LEDの点灯のために安定した送信が可能なタイマーを使ったPPM信号を捨ててmicros()関数とか使って飛行を不安定にしたくない。だとすると、BTのデータ受信時に使っているプログラム内でそのままデータをシリアル送信してあげたほうがはるかに効率が良かろうということでの検証です。
MultiWiiの2.1以降には「Multiwii serial protocol」などというものが実装されているようでこれを使ってのPC信号の入力が可能ですのでこれを使ってテストします。
信号の形式：$M>[data length]
[code][/code]
[data][checksum]
ヘッダコード：’$”M’
データの向き：'<‘ or ‘>’
データ長(data length)：コマンドで送信するデータ長（8ビット1文字換算）
コード(code)：指示コード（詳細は以下「Multiwii Serial Protocol Code」参照
データ(data)：「データ長」で指定した数のパラメータ
チェックサム(checksum)：データ長からデータ迄を順次XORした値の下位8ビット
※：コード(code)に関しては、MultiWiiプログラム内の「Serial.ino」に情報があるので参照
今回のテスト構成はシリアル通信でのコントロールが可能かを試すだけなのでBluetoothでのコントロールは考えずに簡単にします。
（ATMegaはシリアルデータを中継する途中でRCコントロールデータを追加送信します）