オシロスコープ購入

10万円の給付金をもらったし前から欲しかったオシロスコープを購入しました。
今まで使っていた古いアナログオシロだと見たいものが見れない事が多々あったのです。

当初RIGOL DS1104Zが帯域100MHzの4chでデジタル入力もあって良いかと思ったのですが8万円以上します。これでも昔と比べたら格段に安いのですが。ただデジタル入力といってもオプションのプローブが必要で何万かするんですよね(どこで値段を見たのかわからなくなりましたが)。

他に候補として考えたのがAnalogDiscovery2。オシロスコープとしての機能は今一つですがロジアナ、ファンクションジェネレータ、パターンジェネレータ等、機能がてんこ盛りで3万円台後半です。オシロの機能が今一つといっても家での作業なら大半は事足ります。

そしてネットを見ていたらAmazonのタイムセールでRIGOL DS1202Z-Eが¥39,886-で出ていました。2chですが帯域200MHzです。なおデジタル入力はありません。
願わくば帯域は100MHzでいいから4chある方が便利なのですが、この値段は魅力的です。

DS1104Z買ったとして後日必要な時にデジタルプローブも買うと合計10万円を超えます。だったらDS1202+AnalogDiscovery2という手もあるかと考えました(AnalogDiscovery2はまだすぐに買うわけではありません。「必要になったら」です。いつの事かわかりませんが)。

結局DS1202Z-Eを¥39,886- で注文しました。昨日Amazonを見たら5万6千円に戻っていたので良いタイミングで買ったと思ったのですが、今日見たらまた
¥39,886- になっていて、見間違えたのかな?

そして2~3日後、この様な箱で届きました。

箱を開けるとまた箱が・・・厳重です。

そして中身に到達。イメージしていたよりも小さいです。

早速プローブを基準信号につないでトリマーを調整します。

こんな感じですかね。

と、やっていると玄関のチャイムが・・・。この時発注していたレーザー管が到着しました。結構時間がかかっていたのにこのタイミングで来て部屋がダンボールだらけです。

レーザー管は後日交換するとして、とりあえず何か波形を見てみましょう。先日からイジッているS.BUS信号・・・
ところでこのオシロにはシリアル通信のデコード機能があります。
会社でつかっているTektronixのオシロだとこのあたりの機能がオプションだったりしますがコイツは標準で使えるのが嬉しいのです。

ちゃんと先頭が’0F’で始まっているのがわかります。
こういうのが簡単に見れるのが今どきオシロの良いところ。

マニュアルはRIGOLのサイトからダウンロードしました。
なぜかDS1202という名前では辿り着けずシリーズ名であるDS1000Z-Eを選び、「カタログ&チラシ」→「ユーザー・マニュアル」に切り替える必要があってちょっと解り難いです。
また今のところ英語版しか上がっていません。
でも中身は真面目にしっかり書かれている印象です。

その後もイジっていますがTektronixと操作が似ていてわかり易くイイ感じです。
でも表示を日本語にすると変な訳になり余計に解り難いので英語に戻しました。

このオシロが¥39,886-で買えるのは感動的ですね。ヘタするとTektronixのパッシブプローブ1本よりも安いです(帯域は全然ちがいますけど)。

バシバシ活用していきたいと思います。

HOI-LINK高分解能化

以前我が家に来られた事のあるNONSAYAさん、当時はレーザー加工機の話題で盛り上がりましたが、今はドローンレース界の重鎮です。
そんなNONSAYAさんと最近Facebookでお話しする機会があり、コントローラーの分解能が何bit必要かという話になりました。
最近はVelociDrone(ドローンシミュレーター)を使ってオンラインのレース を開催されており、この時コントローラーからPCに送られる信号の分解能がプロレベルの速さでは影響するのではないかと。

OpenStickにしてもHOI-LINKにしても今のところ8bit幅でデータを送っています。一方実機のドローンでよく使われるS-BUS信号は11bit幅です。
私の素人的感覚では8bit幅(=256分解能)もあれば十分かと思っていましたが、レースのプロには影響するのかもしれません。

そこでHOI-LINKを高分解能化して試す事にしました。
HOI-LINKはラジコン受信機が出すS-BUS信号をPICマイコンで受け、USBのジョイスティック信号に変換してPCに送る仕組みになっています。
これを使えば実物のラジコン送信機を使ってドローンシミュレータの練習をしたり、PCに制御信号を送ったりできるモノなのです。

こんな仕組みです。

ここで先ほど書いた通りS-BUSからは11bit幅のデーターが送られてきます。これを8bitに変換するため下3bitは捨てて上位8bitだけをUSBに送っていました。これに対し高解像度版では11bit幅のデーターの下に5bit分の0を付加し、16bitデーターとしてUSBに送ります。
よってデーターは16bitで送りますがS-BUSの11bitから情報が増えるわけではないので結果的に11bit(=2048)分解能です。
なおラジコン送信機/受信機がスティック操作の変化を本当に11bit分解能で通しているかは不明です(ここで削られてたらどうしようもないのですが、どうなんでしょうね?)。

そして11bit版を使ってVelociDroneで飛んでみたところ・・・私レベルの感覚ではスムーズになった様な気もしますが自己暗示かもしれずよくわかりません。もうちょっとハイレベルな人に試してもらう必要があります。

実際にオンラインレースに出場されている方々の環境は8bitだったり11bitだったり様々だそうで、必ずしも11bitの人が勝つ訳でもない様です。

今回作成した高分解能版のファームとソースを下のリンクにアップロードしておきます(デバイス名の最後の’HR’はハイレゾのつもり)。
HOI-LinkHR20200615.zip

また受信機の機種によっては電源投入順序に制約がある問題(HOI-LINKをUSBに挿した後から送信機の電源を入れる順序でないと動作しない)が見つかったので修正しています。

なお以前はS-BUSに含まれる18ch分すべてをUSBに送り出していましたが今回のファームではチャンネル数を8bitに制限しています。
これには事情があって、ドローンシミュレーターで使うには問題ないのですが、Windowsの設定画面(下の図みたいなやつ)でみるとはアナログチャンネルは8chまでしか表示されず、一番大事なスティック操作が動いていない様に見えて気持ちが悪い上に、キャリブレーションができず、以前ARマーカーでドローン制御をしたときに影響があったので8CHにしてしまいました。

Windowsのこういう画面です

後半のチャンネルをデジタル値にしてやればいいのかも知れませんが、S-BUS信号は各チャンネルがアナログかデジタルかの見分けがつかないのでどれをデジタルにするか悩みます。で、実際には8chあればまず足りると思うので取り合えず8chまでにしています。
※もし18ch版必要な方がおられたらご連絡ください。

という事なのでもし8bitと11bitの違いを試してみようという場合は同じ土俵で比べるため下記のファームを比べてください。
HOI-LinkA20200614.zip ・・・8bit/8ch版
HOI-LinkHR20200614.zip ・・・11bit/8ch版 (上のリンクと同じ)

2020-06-15追記
HOI-LINKをPCに挿し送信機がONの状態でPCを立ち上げたときうまく動作しない問題が見つかったので修正しました。原因はUSBの通信が確立する前にSBUS信号を受けてUARTがオーバーフローしていたためで、初期化する処理を追加しました。
( 今回11bit版だけ修正しています。今後8bit版のメンテナンスは止めるつもり。)
HOI-LinkHR20200615.zip

フライトコントローラーを自作してみる。~その4~

BlackBoxについて

前回書いた通り、基板化する前にBlackBoxを動作させてみます。
BlackBoxとはフライトコントローラー(以下FC)が諸々の情報をログとして記録する機能です。
ログの保存先としてBetaflightがサポートするメディアには、OpenLog基板、SDカード、SPIフラッシュIC 等があります。

OpenLogはSparkFun(SwitchScienceでも取扱いがある様です) のロギングデバイスで、FCには外付けする事になり機体内のスペースを取るため今回はパス。またSDカードは安くて大容量なのが魅力ですがカードコネクタがFC基板の面積を喰い設計が難しくなりそうなので、もうちょっと腕が上がってからにします。
という事で今回はSPIフラッシュを使ってみようと思います。

記録メディア

BetaflightがサポートするSPIフラッシュICはこちらのページに記載されている下記のデバイスで、この中から16MBのW25Q128を購入しました。

  • Micron/ST M25P16 -2 MByte
  • Micron/ST N25Q064 -8 MByte
  • Winbond W25Q64 -8 MByte
  • Macronix MX25L64 -8 MByte
  • Micron/ST N25Q128 -16 MByte
  • Winbond W25Q128 -16 MByte
ちょっと思っていたよりサイズが大きい。

配線

接続は電源とSPI信号をつなぐだけ・・・。

ファームウェア定義ファイル

Betaflightのターゲット定義ファイルtarget.hに以下を追記しました。
SPI3に接続しています。

#define USE_SPI_DEVICE_3 
#define SPI3_SCK_PIN PC10
#define SPI3_MISO_PIN PC11
#define SPI3_MOSI_PIN PC12
#define USE_FLASHFS
#define USE_FLASH_M25P16
#define FLASH_SPI_INSTANCE SPI3
#define FLASH_CS_PIN PA15
#define ENABLE_BLACKBOX_LOGGING_ON_SPIFLASH_BY_DEFAULT

気になったのは’USE_FLASH_M25P16’の行。M25P16は2MBのメモリーですが今回接続するW25Q128は16MBです。このあたりの設定は不要なのでしょうか? 他のFCの設定を見ても特に容量を指定する箇所もなく、単にM25P16を指定しているの様なのでこのままやってみます。

動作確認

ファームをビルドしてFCに書き込み、BetaflightConfigratorから接続してみると・・・

ちゃんと16MBとして認識しています。

適当に動作させたログをPCに取り込み、Blackbox Explorerで結果を見てみました(FCは机に置いたままなのでジャイロや加速度センサーの値は全く動いていませんけど・・)。

動作は大丈夫そうです。

ということで・・・

いよいよ基板設計を開始しました。一般的な一辺35mmの正方形に収める予定ですが、手ハンダも考慮してSMDパーツのパッドを大きめにしたため、面積的に結構厳しいです。くじけたら35mm角は諦めて基板サイズを広げるかもしれません。

ArduinoIDEが保存するスケッチの改行コードが変わった?

最近ArduinoIDEでスケッチを保存し、gitにコミットする前にdiffを取ってみたら、数行しか変更していないはずなのに全行が不一致として表示されました。
どうやらArduinoIDEのバージョンを上げたのが絡んでいて、以前は改行コードがLFのみだったのが今はCR+LFに変っている様です。

リリースノートにはそのあたりの記述は見当たりません(英語なので見落としているかもしれないけど)。

そこでArduinoのサイトから旧バージョンのIDEを取ってきて色々試したところ、バージョン1.8.5から1.8.6になる時に変った様です。

Arduiooのフォーラムで検索すると次のやり取りが見つかりました。そのうち治してくれるんちゃう?っぽい会話みたいですが最新の1.8.12でも戻っていない様です。
https://forum.arduino.cc/index.php?topic=575025.0

致命的な問題ではないんですが、できれば統一したいところです。
どなたか、このあたりの経緯をご存じですか?

フライトコントローラーを自作してみる。~その3~

前回まででとりあえず’飛ぶ’という事については何とかなったので引き続きOSD機能を試してみます。
OSDはOnScreenDisplayの略で、テレビの映像に文字等をスーパーインポーズする機能です。よくアナログ時代末期のテレビではチャンネル番号や音量が画面上に表示されていたアレです(今もあるか)。
フライトコントローラーではFPV画像に重ねてバッテリー電圧とか諸々の情報を表示する為に使用します。

大抵のフライトコントローラはマキシムのMAX7456及びその互換ICを使っている様で、これを使えば問題なくBetaflightのファームウェアがコントロールしてくれるはず。

という事でAliexpressからMAX7456Eを3個買っておきました。
SOPパッケージなのでピッチ変換基板に実装します。

そしてほぼデーターシート通りの次の回路図でやってみます。

ブレッドボード上に回路を組んで・・・

ちょっとゴチャゴチャしています。
画像の上の方に適当なカメラを仮止めしています。

実行してみるとあっけなく表示されました。
まあソフトもハードも既存の物なので当然といえば当然ですが。

次はそろそろ基板化を考えたいところですが、その前にもう一つ、最近のフライトコントローラーには動作中のログをSDカードやSPIフラッシュに残す機能があります。
調子よく動作しているときは良いのですが不調の場合には必要となる可能性があり、できれば搭載しておきたいと思います。メモリーにはマイクロSDカードが安くて容量も大きいのですが、SDソケットを載せると基板の面積を喰って設計が難しくなるので今回はSPIフラッシュで試そうと思います。
そこでRSコンポーネンツにSPIフラッシュを発注し、入着を待ちながら基板の検討を進ていめます。

フライトコントローラーを自作してみる。~その2~

前回STM32F411Nucleo64ボードでフライトコントローラーを作ってホバーリングさせてみたら斜めに振動したところまで書きました。その続き。

「斜めに振動」といっているのはこういう風に、黄色線を軸にして赤矢印の方向に2~3Hz程度で揺れ、PIDをいじっても改善しないのです。

最初はプロペラとジャイロセンサーの高さが違うのが原因かと考えました。高さが違うと上図の様に揺れた振動をジャイロだけでなく加速度センサーまで拾ってしまいおかしくなるのかと・・・

一番上の基板にセンサーが載っているのでプロペラから2cmくらい高いのです。

そこでモーターの高さを上げてみましたが効果ありません。

この時はまだ レーザー管も元気だったので簡単に作れました。
前回書いた様に、この後レーザー管が弱ってしまったのです。

次にFCを90度回して取り付けてみました。こうするとジャイロ/加速度センサーも90度回るので揺れる方向も90度回るかと思ったのですが、変わらず同じ方向に揺れました。という事はセンサーがらみではないんじゃないかな?

試しに市販のFCに載せ変えてみたら、やはり同じ様に揺れます。という事は自作FCの問題ではなく、モーターやESCを含む機体側の問題っぽい・・・

ESCは得体のしれないセパレートタイプ(4in1ではない) を4つ載せています。4個が同じ設定ではないのかと疑いましたが、ファームがBLHeil等ではなく、特に資料もないので確かめ方がわかりません。そこで先日激安で購入したESCに載せ変えてみましたが・・・これでも変化ありません。

激安ESC

残るはモーターかとも思いましたが交換できるモノがないのです。また4つとも見た感じでは元気に回っています。

ここで一旦行き詰ったのですが、以前コアレスモーターの機体にBetaflightの最新バージョンを載せたら不安定になった事があったので、ダメ元でBetaflightのバージョンを下げてみ見ました。

今までVer.4.2.0だったのをVer3.5.7に変更したところ揺れが収まったじゃないですか。最新版の何が問題なのかは判りませんが自作FC,市販FC共にVer3.5.7だと安定しています。

Ver4.2.0の何が問題かは気になるのでいずれ調べたいと思います。

・・・という事で最終的にこんなゴチャゴチャな機体になりましたがちゃんと飛ぶ様になりました。

動画です。
なんかもう、とにかく飛べば良しという機体

次はOSDの回路を載せてみたいと思います。

レーザー管劣化

レーザー管が劣化してしまいました。

いきさつ・・・

前に冷却水をこういうのにした事を書いたのですが・・・

Water2_7
不凍液を電動ポンプで回し、ラジエーターで冷却していますが
水流がちょっと弱めでした。
手押しポンプが付いているのは電動ポンプまで水を通す為です。

あまり冷却が弱いとレーザー管が劣化するという事を読んだので直ぐに元の風呂水ポンプに戻していました。

今まで使っていた風呂水ポンプ

この状態で使っていても徐々に劣化感はあったのですが、先日MDF材を切っていたら途中でレーザーが出なくなっていました。みるとポンプが壊れてセンサーが水流を検出しなくなり、レーザーを停止させていた様です。

水流センサー
水流センサーのインジケーター

ポンプはもうウンともスンともいいません。でもこれは予備として買っておいたこちらの水中ポンプに交換します。

いつだか買っておいた水中ポンプに交換。

これで水は依然よりも良く流れるようになったのですが・・・・レーザーが弱々しくなり、フルパワーでも2.5mm厚のMDFが切れなくなってしまいました。

水流センサーが働いてレーザーは止まっていた筈ですが、余熱が逃げないだけで劣化してしまうのでしょうか?

ためし撃ち
購入時の試し打ち風景。
ブログを見返すとこのレーザー管は2015年に購入しています。
約5年使ったと考えれば諦めもつくかな。

という事で・・・

とりあえずレーザー加工機のない生活は考えられないので新たなレーザー管を発注しましたが、新型コロナで世の中おかしくなっているこのご時世、いつ届くのでしょうか?

フライトコントローラーを自作してみる。

ドローンレースの練習をしていると色々なところを壊します。
ほいほい堂本舗は貧乏性なのでできる限り修理して再利用したり、また可能なところは自作してみたくなります。

という事でフライトコントローラーを作ってみたいと思います。フライトコントローラーとは一言でいうとマルチローター系の機体を制御するマイコンボードです。固定翼の飛行機は構造的に自立安定して飛行しますが、これと違ってマルチローターは特に制御しなければ安定して飛び続けられません。そこでジャイロや加速度センサーで機体の姿勢を検出しどのモーターをどの程度のパワーで回すかを決めるのがフライトコントローラー(以下FCと略す)です。

自作フライトコントローラーの構想

近年の(ホビー系の)FCは殆どがSTマイクロエレクトロニクス製のSTM32Fxx マイコンが使われています。これにジャイロ/加速度センサーを載せるのですがマイコンとの接続はSPIやI2Cですし、モーターを回すためのドライバ(ラジコン界ではESCという)へはPWM(およびその変形)で信号を送るので、ほぼマイコン工作で作れそうです。

またソフトについては優秀なオープンソースのファームウェアが多数出ているのでこれらを用いることができます。

といっても、いきなりプリント基板を作る勇気はないのでまずはマイコンボードを使って動作を確認してみます。マイコンボードにはSTM32F411 Nucleo-64を使う予定。

STM32F411 Nucleo-64

全体像はこのブロック図の様に考えています。このうち水色で囲んだ部分をここではフライトコントローラー(FC)と呼ぶ事にします。

実用的にレースで使うにはこの他にOSD(On Screen Display:FPVの映像に諸々の情報をスーパーインポーズして表示する機能)も必要になりますが、まずは飛べる事を確認出来た後でこれらも試したいと思います(実はOSD用ICも入手済)。

Betaflightをビルドする。

ファームウェアはいつも使っているBetaFlightを書き込む予定ですが、その前にファームウェアをビルドする環境を作っておこうと思います。
BetaFlightのビルドはUNIX環境上で行うのが基本となっている様で、Windows上のWSL(Windows Subsystem for Linux)でも実行できます。詳細はBetaflight Wikiのこのページに説明されており、この通りにやれば構築できました。
手順通りに構築するとWSL環境内の~/Git/Betaflightというディテクトリ以下にファイル一式ができています。更に下には~/Git/betaflight/src/main/targetというディレクトリがあり、ここには下図の様に各種FC毎の設定があります。

このディレクトリ下に今回作るFC用として’HOIHOIF411’というディレクトリを作るのですが、まずは似たFCである’MATEKF411’の内容を丸コピーし、そこから変更していくことにします。

HOIHOIF411ディレクトリの中にはtarget.mk、target.h、target.cの3本のファイルがあります。ここら辺の詳しい説明資料が見つからないのですが、この3本のファイルを変更するとそれぞれのFC固有のファームウェアが出来上がる様です。で、いろいろ試行錯誤した結果のファイルを添付しておきます。→HOIHOIF411.tar.gz

targetディレクトリの設定ファイルができたらカレントディレクトリを
~/Git/Betaflight に設定し、ここで’make HOIHOIF411’とコマンドを実行すると ~/Git/Betaflight/binの下にファームウェアが出来上がります。このファイルをBetaflightConfiguratorのファームフラッシャーを使って書き込んでやる訳です。

ジャイロ/加速度センサー

当初ジャイロ/加速度センサーにはモーション・フライトシミュレーターで使ったので手元にあった MPU6050ボードを使ってみました。市販のFCは大抵SPIで接続できるセンサーを使っていますがMPU6050はI2C接続専用です。一応これもBetaflightにサポートされているっぽいのですが、しかし何故かうまく接続できません。mbedで書いたプログラムだとセンサー値を取れるのですがBetaflightのファームからは取れないのです。

MPU6050ボード

そうこうしている内にポチッていたMPU6500ボードが届いたのでこれをSPIで接すると問題なく接続できました。 名前が似ていてややこしいですがMPU6500はSPIで接続するタイプで市販のFCでも結構使われています。
どのみち最終的にはMPU6500を使うつもりなのでこれで行きます。

MPU6500ボード


回路図

こんな感じで行こうと思います。
NucleoボードはArduino互換ソケットが付いているので、なるべくこれを利用する事で、Arduino用シールド基板を使って配線し易い様にします。
なおOSDは後で追加予定です。

機体

動作確認用に、息子が作って今は使っていないこの機体に乗せてみます。

製作

まずはブレッドボードで動作を確認して・・・

大体動作したのでArduino用シールド基板上に回路を載せて・・・

機体に乗せてみます。

飛ばしてみる

で、飛ばしてみると・・・一応浮き上がるのですが斜めに振動して止まりません。
原因調査中ですが、市販のFCに載せ変えても同じ様に振動するのでFCの問題ではないのかもしれません。
この続きは後日・・・

レーザーカットしてマスクを作ってみた。~その2~

先日のマスク作成の続きです。

前回のデーターは片方のパーツを裏返し忘れていました。材料となる生地に裏表の区別がなければ特に問題はないのですが、区別がある場合は面倒になるので修正データを作りました。

また私にはサイズが小さい感じがしたのと鼻の横に隙間ができるので改良しようと思います。まず全体を10%大きくし、鼻側をちょっと広く取る事にします。あと縫い合わせがし易い様に2枚を中央で連結させてみました。

早速改良版をカットして縫います。

鼻の横には使い捨てマスクから取った針金を入れてみます。

大小並べて撮影。もうちょっと明るい色の生地にしようかな・・

まだミシンに慣ませんがなんとかできました。

今回のカットデータです。
<前回サイズの修正版>
MASKDATA2.jww
MASKDATA2.dxf
<サイズアップ版>
MASKDATA3.jww
MASKDATA3.dxf

レーザーカットしてマスクを作ってみた。

新型コロナウィルスで世の中えらい事になっています。
オリンピックもMakerFaireKyotoも中止だそうですね。(オリンピックは中止ではなく延期でしたね。訂正します。)
熊本でもマスクは全く手に入りません。仕方ないので使い捨てマスクを洗って消毒して使いまわしていますが、あまり何度も使えるとは思えません。

そんな中、家族がダイソーに行ったらマスク自作用の型紙を配っていたそうで、1枚もらってきました。

いずれ大量に作る必要があるかもしれないので、これをJw-cadに入力してレーザーカットしてみます。

これを2セット、合計4枚を切り出します。

適当な布をセットして・・・

布がラクダ色っぽい・・・

布を切るのは初めてなので条件設定を探りながら・・・
速度はF1200、レーザーパワーは40%で切りました(なおウチのレーザーは40WのCO2ですが最近パワーが下がってきている気がしています)。
でもまあ相手は布なので問題なく切れました。

4枚で一組のマスクになります。

そして不慣れなミシンで縫ったのがこれ。

二重構造で本来は中央と上下の縫い目を内側に折り返して見えなくするのですが、間違って縫ったのでどちらかの縫い目が表に出てくる様になってしまいました(上下の切り口がギザギザに見えるのはその為です)。
嫁曰く「初心者がやりがちな事」だそうです。

Jw-cadとDXFのデーターをアップしておきます。
MASKDATA.jww
MASKDATA.dxf