コロナ禍による半導体不足で長らく手に入らなかったSTM32F722マイコン、最近Aliexpressを見たらマトモな値段で売られているのを見つけ、2個注文したのが届きました。
1個1297円×2個。
自作FCの中に壊したのが1枚あって、どうもマイコンが壊れているっぽいのでこれに交換しようと思います。
でも最近、ちょっと忙しいのでもう少し先。。。
フライトコントローラーを自作してみる。～その19～ F7マイコン購入
返信
カテゴリーアーカイブ: MultiCopter
HOILog・・無人航空機飛行日誌を自動化 その2
先日報告したHOILogですが、飛行練習会で使ってみると幾つか問題点が見えてきました。
（Tinyなので本来ログはいらないですが）
一番問題なのはGoogleドライブにアップロードする時にリトライが発生した場合。自宅の無線環境だとリトライする事はほぼありませんが、スマホのテザリング経由だと(電波状況にもよると思うけど)頻繁にリトライが発生し、リトライしていてもGoogleドライブには届いている事も多く、複数回のログがアップロードされてしまいます。
Googleドライブ側はこちらの仕組みを使っていますが仕組み的にリトライが発生するとそのまま全部が残ってしまいます。リトライになること自体はネットの都合なので対応が厳しく、きちんと対策するにはGoogleドライブ上のスクリプトを変更していく必要があると思います。
一方SDカードには安定してログが残るので、当面はこっちを主に使いたいと思います。。。が、これまでSDカードには時刻ぐらいしか記録していなかったので、今回機体名や場所を残す様に変更しました。
SDカードに残すログのフォーマット：
右から時刻、飛行場所、機体名、離陸か着陸か、アップロードしたか、その場合のリトライ回数 を示します。
例：
2023-03-19 22:34:15,KUMAMOTO,Mobula6,TakeOff,Upload success,1
2023-03-19 22:34:25,KUMAMOTO,Mobula6,Landing,Upload success,1
2023-03-19 22:34:36,KUMAMOTO,Mobula6,TakeOff,Upload success,1
2023-03-19 22:34:45,KUMAMOTO,Mobula6,Landing,Upload success,1
あとコンフィグファイルのデータ中にスペース文字があった場合にスペースを消してしまっていたのを修正しました。
試しに飛行場所にスペースを1文字入れ「KUMA MOTO」にしてみたのが以下の結果です。。。
2023-03-21 23:58:14,KUMA MOTO,Mobula6,TakeOff,Upload success,1
2023-03-21 23:58:23,KUMA MOTO,Mobula6,Landing,Upload success,1
ついでに飛行場所に日本語を使うとどうなるか実験しました。
飛行場所を日本語(文字コード:UTF-8)で書いたところ、液晶画面には正常に表示できませんがSDカードとGoogleドライブ、どちらのログにも正しく記録されています。
2023-03-19 22:38:15,熊本県合志市,Mobula6,TakeOff,Upload success,1
2023-03-19 22:38:30,熊本県合志市,Mobula6,Landing,Upload success,1
なおM5Stackには液晶画面に日本語を表示させる方法もある様なので、そのうち試そうと思います。
以上を修正したスケッチをここに載せました。
→http://www.hoihoido.com/data/HOILog20230323.zip
HOILog・・無人航空機の飛行日誌を自動化
最近M5Stackにハマっていました。
M5Stackというのはまあ簡単に言うとESP32マイコンにLCDディスプレイやバッテリーを含んだ電源管理回路などをつけて一式をケースに入れたものです。
私が購入したのはCore2という機種で外観はこんな感じ・・・
M5Stackは数年前から出ていて気にはなっていたのですが、値段がちょっとお高めだったりして手を付けていませんでした。で、今更ながら購入してみたら結構便利なんですよね。 特に電源管理回路とかイチから作るとそれだけで何かにハマりそうですが、これなら最初から入っています。
HOILog
という事で何を作っていたかというと「無人航空機の飛行日誌を自動でとるシカケ」です。命名：HOILog。
M5Stack Core2を選んだのは内部に時計(RTC)を持っているので時刻を記録し易いのです。
構造は ざっと下の通り・・・
RC受信機が信号を受けるとSBUSやCRSFプロトコルでM5Stackに伝えます。
(SBUSはフタバ系、CRSFはELRS等で使われるプロトコルです。両方対応しています。）
M5Stack側では信号が来たら飛行開始と判断し、マイクロSDカードに時刻を記録します。そして信号が途絶えたら飛行終了ということでまた記録します。
更にM5StackにはWiFi接続機能があります。これを利用してWiFiが利用できる環境であればASAKICHI先生作の飛行日誌システム( 詳細 はこちら） にもアップロードできるので、Googoleドライブ上のスプレッドシートに記録が残っていきます。
動作しているところはこんな感じ→Twitterに上げた動画
ハードウェア
M5Stack Core2の裏にピンソケットがあります。新品の状態ではここにフタを兼ねた気圧センサー基板がついていますが、今回は不要なので取り外して+5V電源、GND、UART2のRX/TXを引き出し、RC受信機に接続します。
ELRS受信器には入力(RX)信号があり、現在は使っていませんが将来何かに使うかもしれないので繋いでおきます。SBUS受信機の場合は入力信号がないのでM5StackのG14(UART2-TX)端子はオープンにしておきます。
ブレッドボード上に組んだセット（回路図にはないですが分かりやすい様に電源にLEDをつけています）。
ソフトウェア
M5StackはULFlow、ArduinoIDE、Micropython等の開発環境が選択できます。私はこの中から一番なじみのあるArduinoIDEを使用しました。
ところがやり始めて気づいたんですけど、コンパイルが結構遅いんです。ググってみると皆さん同じ問題により、PlatformIOに乗り換えられている様です。PlatformIOとはVisualStudioCode(以後VSCode) に入れるプラグインで、たぶん一言で言い表すと各種マイコンに対応した開発環境だと思います。
確かにPlatformIOでビルドするとかなり早くなり快適です。またベースがVSCodeなので入力補完があったり、キーバインディングをEmacs風に変更したりできて便利です。（余談ですがEmacs風キーバインディングにしたとき、VSCodeの仕様によりEscキーを使用できず、代りにAltキーを使う事になるのが弱点です）。
ところがPlatformIOで作ったスケッチが大体安定した動作になった頃、このブログで公開しようかなーと思い、その前に一旦ArduinoIDEに戻してビルドしたところ何だかうまく動作しません。（M5Core2ライブラリはどちらも同じバージョン(0.1.5)なのですが、もっと奥の方のライブラリのバージョン違いが原因かもしれません。）
とりあえずハマったのは下記の２点。
・タイマーの一旦停止後再起動する場合の動作の違い。
timerStop(timerxx)で停止した後に再起動するとき、 PlatformIOはtimerRestart(timerxx) で再起動できていたのがArduinoIDEだと止まったまま。
→対策：timerAlarmDisable(timerXX)で止めて timerAlarmEnable(timerXX) で復帰させる。ただし復帰直後のカウントアップが嫌だったので timerAlarmEnable(timerXX) 直前にtimerRestart(timerxx) も実行した。
・HTTPにPOSTした後同じオブジェクトでGETできない問題。
Googleドライブへアップロードするとリダイレクト指定が返ってきます。このため一旦POSTでアクセスした後、今度はGETでアクセスするという２段階のアクセスが必要となります。そこでPlatformIO上では、HTTPClient http;で作ったオブジェクトを使いまわして接続していました。しかしArduinoIDEだとエラー(エラーコード400が返る)となりました。
色々試したところ、どうやらArduinoIDE上では GET→GETなら できますがPOST→GETはダメでした。
→ 対策： HTTPClient http2; の様にもう一つオブジェクトを宣言し、POSTはhttpオブジェクト、GETはhttp2オブジェクトで使い分けた。
使い方～セットアップ編～
- ArduinoIDEとM5Stack Core2の開発環境を準備する。私はこちらのページを参考にしました。
- この投稿の一番下からM5Stack Core2用のスケッチをダウンロードして解凍する。
- PCとM5Stack Core2の間をUSBケーブルで接続する。
- 「2.」で解凍したフォルダ内のHOILog.inoをダブルクリックするとArduinoIDEが開く。
- ArduinoIDEのツールメニュー→ボード名を”M5Stack-Core2″、シリアルポートを該当するポート名(不明な場合はWindowsであればデバイスマネージャーで調べる)に設定する。
- 書込みボタンを押して書き込む(若干時間が掛かります)。書き込みが完了したら電源ボタンを長押し（約６秒）して一旦電源を切る。
- 上の「ハードウェア」に書いた様にM5StackとRC受信機を接続する。
- 設定ファイル”hoilogini.txt”を作成して マイクロSDカードのトップディレクトリに置く。※SDカードの使用は必須です。
- 電源ボタンを押して起動！！
設定ファイルについて
SDカードのトップディレクトリに”hoihoiini.txt”の名前で作成します。
内容は１行に１パラメータを設定。１行は256バイトまで。行先頭にディレクティブ、その後1文字以上の空白を置いて設定値を書きます。#記号より右側はコメントです。
設定ファイルの例・・・
# HOILog 設定ファイル
LOGFILE /hoilog.txt # File name
SCREEN 60 # Screen save time.(Seconds)
RCTYPE SBUS # SBUS or CRSF
RCJUDGE RSSI # RSSI or RCSIGNAL
RCRSSICH 16 # Channel number
RCRSSITH 1000 # Threshold value
RCCONTTIME 3 # Signal continue time
BAUDRATE 100000 # SBUS:100000 CRSF:420000
WIFITIMEOUT 20
SSID XXXXXXXX
PSWD XXXXXXXXX
LOGURL https://script.google.com/macros/s/XXXXX/exec
LOC1 ASO
LOC2 AMAKUSA
LOC3 KOSHI
MODEL1 Tyro99
MODEL2 Switch
MODEL3 Five33
各ディレクティブの説明：
LOGFILE：SDカードに残すログファイルの名前です。
SCREEN：指定の秒数イベントがないと画面を暗くします。ボタンを押したりRC信号が変化すると表示を再開します。値が0の場合は常に表示です。
RCTYPE：RC受信機の信号フォーマットがSBUSかCRSFかの指定です。
RCJUDGE：飛行中の判定をRC信号の有無で判定するか、RSSIで判定するかの指定です。受信機によっては電波が途絶えても最後の状態を維持するので単に信号が途絶えたかどうかでは判別できません。その場合でもRSSI(信号強度)がどこかのチャンネルに出ていればこれを基に判別可能です。
RSSICH：RSSI によって飛行中である事を判定をする場合、RCチャンネルの何番がRSSIを示すかを指定します。
RSSITH：RSSI によって飛行中である事を判定をする場合、 RSSICHで示すRCチャンネルの値が幾つ以上なら信号ありとするかを指定します。CRSFの信号範囲が172～1811、SBUSも大体その程度なので1000あたりを入れておけば大体OKだと思います。
RCCONTTIME：瞬間的な信号の切断やノイズによる入感を除去するため、
（立上り／下り共） 信号が何秒間連続で続いたら変化したと判断するかを指定します。
BAUDRATE：RC信号のボーレートを指定します。SBUSは100000固定。CRSFは420000がよく使われる値です（115200も使われる様ですが手元に確認する環境がなく、動作を確認していません）。
WIFITIMEOUT：WiFi接続時、何秒以内に接続できなかったらあきらめるかを指定します。
SSID：WiFi接続のSSIDを指定します。
PSWD：WiFi接続のパスワードを指定します。
LOGURL：Googleドライブにアップロードする為のGoogleApplicationScriptへのURLです。こちらのASAKICHI先生の動画の８分20秒頃に説明があるURLです。
LOC1～5：飛行場所を５つまで設定できます。M5Stack上のメニューでこの中から一つを選択してログに残せます。電源投入直後はLOC1が選択されています。MODEL1～5：機体名を５つまで設定できます。 M5Stack上のメニューでこの中から一つを選択してログに残せます。 電源投入直後はMODEL1が選択されています。
※LOCxやMODELxの値に日本語等の2バイト文字を入れるとどうなるかは試していません。
使い方～操作編～
電源を入れるとまずWiFiに接続した後、下の基本画面になります。
WiFiに接続できなかった場合はSDカードへの記録のみ行い、Googleドライブへのアップロードはしません。
この状態でRC電波を受けるとRCCONTTIMEに設定した値の秒数信号が続く事を確認後、SDカード、およびGoogleドライブのログに記録を残します。
Googleドライブへ記録する間、飛行状態表示部に「START UPLOAD」又は「STOP UPLOAD」と表示し、この間RC信号モニタや時計は動作しません。
Googleドライブへの記録は失敗すると３回までリトライします。最終的に成功したか失敗したかはSDカードに記録します。なお稀にですがサーバが正常に受付けて成功した旨の通知を返したのにM5Stackまで届かなかった時はリトライするので複数回の記録が上がってしまいます。その場合はSDカードのログを参照しながら手動でGoogleドライブ上のデータを修正する必要があります。
M5StackのCore2にはボタンがA,B,Cの3つ搭載されています（このボタンは物理的な接点ではなくタッチセンサーになっていて、押した感触が伝わりにくいですがちゃんとボタンとして機能します）。
基本画面ではボタンCを長押しすると設定画面に移ります。
ボタンA,Bには機能を割り当てていませんが、スクリーンセーバーからの復帰には反応します。
設定画面（MAIN MENU)
上から時計設定、電源OFF、機体選択、飛行場所選択、メニュー終了です。
反転文字になっているところが現在対象となっている行で、ボタンAを押すと上、Bを押すと下の行に移動し、Cを押すと選択されます。
「電源OFF」を選択するとシステムの電源を切ります。「EXIT MENU」を選択すると基本画面に戻ります。
時計設定、機体選択、飛行場所選択の各画面を以下で説明します。
時刻設定画面
ボタンA,Bを押すと反転文字になっている部分の値が上下に変化します。ボタンCは決定ボタンで次の値に進みます。年月日～秒まで進み、次にボタンCを押すと図に「NEXT」と表示された部分に移ります。ここではボタンA,Bを押すと「NEXT」、「SAVE&EXIT」、「EXIT:NonSAVE」と順に変化して行きます。それぞれの状態でボタンCを押すと以下の動作をします。
・NEXT：最初の「年」の設定に戻ります。
・EXIT:NonSAVE：時刻は変更せずにメインメニューに戻ります。
・SAVE&EXIT：内臓時計に設定時刻をセットし、メインメニューに戻ります。
機体選択
ボタンA,Bで対象行を上下させ、ボタンCで選択すると機体が選択されてメインメニューに戻ります。
飛行場所選択
ボタンA,Bで対象行を上下させ、ボタンCで選択すると飛行場所が選択されてメインメニューに戻ります。
ログ
実行後はSDカードのLOGFILEで指定したファイル名に以下の様なログが残っています。
TakeOff,2023-03-05 22:46:36 ←離陸時刻
Upload success,2023-03-05 22:46:36 ←離陸をGoogleドライブにアップロード成功
Landing,2023-03-05 22:47:13 ←着陸時刻時刻
Upload success,2023-03-05 22:47:13 ←着陸ををGoogleドライブにアップロード成功
Googleドライブ上には（アップロードしていれば）次の様なログが残ります。
スケッチ
※このソフトウェアを使用されてもし問題が発生しても責任は持てませんのでそのあたりはよろしくお願いします。
HOI-LINKのELRS版～その2～
気づいたらまた長らくBLOGを放置していました。
HOI-LINKのELRS版のその後、割と直ぐに動作はしたのに改良しようとしたところでハマってそのままになったので、「とりあえず動作版」を公開いたします。
※このページの下の方にファームへのリンクを貼っています。
前回(いやもう4か月も前^^;)、JUMPER T8SGにBETAFPVの送信モジュールを接続して動作したところまでを書きました。その後の色々を書こうと思っていましたが時間が過ぎてしまったので以下簡単に済ませます。
まずELRS受信機が出すCRSFプロトコルをマイコンボードで読んでみました。420Kbpsで動作させたいのでArduinoUNO等ではスピードが足りず、いつかのトラ技の付録でESP32搭載のボードを使用。
そしてSTM32F411 Nuclero-64ボードでELRS版HOI-LINKとして動作を確認。
（これでドローンシミュレータVelocidroneで使えるぞー。 \^o^/ ）
STM32F411のボードだと勿体ないのでSTM32F103ボードに移植。
その後、改良したい点があったのですが時間が過ぎてしまったので一旦この時点のファームをページの最下部に貼り付けました。
HOI-LINK ELRS版 を試す方法
使ったボードは秋月電子で購入したSTM32F103C8T6マイコンボードです。
ファームを解凍するとHOI-LINK-EX\Debug\HOI-LINK-EX.binというファイルが含まれているので、ボードの取説に従いFlash loader demonstratorを使って書き込みます。
左上のゴチャゴチャッとしたのはUSBシリアル変換です。
再コンパイルする場合はSTMicroelectronicsのCubeIDEを使用します（私が使ったバージョンは1.7.0でした）。上記バイナリを書込むだけなら再コンパイルは不要です。
書込み後、基板回りの接続は次の様に配線します。
・PB10(USART3TX)<–>ELRS受信機のRX
・PB11(USART3RX)<–>ELRS受信機のTX
・基板GND<–>ELRS受信機のGND
・基板5V<–>ELRS受信機の5V
※基板上に5Vという端子がないのでSW2の真ん中の端子に接続しました。
※ USBを使用するのでJ1,J2のジャンパーはハンダで短絡しておく必要があります。
※なおELRS受信機は420Kbpsで接続出来る様に予め設定しておきます。
そうするとこんな感じでPCに繋がり、Velocidroneで練習できるのです。
注意：例によって正式なUSBベンダーIDがないので適当な値を書いています（VID:0xFFFF PID:0x0015) 。
よって使用する際は自己責任でお願いします。
改良したい点
ELRSの受信機はPCと接続して諸々の設定をする必要があります。その為にはHOI-LINKの回路をUSBシリアル変換としても使えると便利かなと思いますが、気軽に試し始めたらUSBとUART間のタイミングが結構難しくてハマっています。
またSBUS版HOI-LINKの時、このページで公開しただけでは世間に広まらず、NONSAYAさんが販売されて広まったという経緯がありました。しかし販売するためにはUSBのベンダーIDが必要なので、またマイクロチップテクノロジーのマイコンに移植してIDの分配を受けようかと考えています（実はPIC32MXでの動作は確認済なのです）。
HOI-LINKのELRS版
先日JDL宮崎の会場で「HOI-LINKのELRS版ってできないの？」と聞かれました。
今までのHOI-LINKはS-BUS信号をUSBに変換してPCに送っているので主にフタバ系のプロポシステムが対象になっています。
一方ELRSというのはこちらで開発されているラジコン電波のプロトコルで、昨年あたりからドローンレース界隈でちょっとしたブームになっているのです。
私は今までELRSを扱える機材を持っていなかったのですが、そう言われるとやってみたくなるのが人情というもの。。。
システムは大体この図の様な感じになるので、試すには最低でも送信モジュール、受信モジュールは購入する必要がありますね。あと送信機本体はどうかな？
送信機本体でよく使われているのはファームウェアがOPEN-TXのものですが、ウチにはありません。さすがにこのために送信機まで購入するのはちょっとですね。。。
で、色々調べていくとどうやらJumperのT8SGが使えそうという事が分かってきました。
というのも送信機と送信モジュールの間はCRSFプロトコルというシリアル通信で接続します。で、T8SGにもCRSFプロトコルを選択できるのです。
ならばT8SGにCRSFプロトコルを出力させてみましょう。信号をオシロスコープで見ると、420Kbpsのそれっぽい信号が出ています。
なんか、イケそうですね。
ならば送受信モジュールだけ購入して実験してみましょう。
という事で発注しました。・・・そして到着したのは盆休みの最終日。もう少し前に届くと着手しやすかったんですけど、仕方ないですね。
購入した送信モジュールはBETAFPVの”ELRS NANO TX”。このモジュールは技適が取れているので、日本では殆どの人がこれを使っています。
そして受信モジュールもBETAFPVの”ELRS Lite RX”。この受信モジュールはメチャクチャ小さいですね。
これで材料が揃ったので、まずは普通に使えるかというところから。
こちらのページを参考にしながら試していきます。
まず最初にELRSモジュールは諸々の設定をするためにPCと接続する必要があります。送信モジュールとはUSB Type-Cで接続できるので簡単です。受信モジュールはUARTで接続しますが、フライトコントローラー経由でもBetaflightがうまくやってくれる様です(なのでＦＣ経由でやりました)。
そして今回設定したのはこの内容。まずは送信モジュール・・・
そして受信モジュール・・・
各モジュールの設定ができたので接続します。まず送信側・・・
なおT8SGとNANO-TXの間はこの様に配線しました。
そして受信モジュールをFCと接続（実際にはファームを設定したときに接続した）・・・
なお上についている基板は別の実験用なので関係ないです。
受信モジュールはTX/RX両方の信号を接続する必要があります。（テレメトリを使わなければRX側は繋がなくても良さそうに思えますが、たぶんファームの書換えにも使うのやっぱり繋いでおきます）。
ところで送信機←→送信モジュールの間、および受信機←→ＦＣの間、両方共CRSFプロトコルで接続するという事になっているのですが、送信機側の接続はシリアル信号線は1本、受信機側は2本となっています。
たぶん送信機側は半二重、受信機側は全二重なのかと思いますが、名称的には区別ないんですかね？
そして送信機の電源を入れ、FCをPCに接続してBetaflightConfiguratorの”受信機”ページで確認すると、あっさり接続できていました。
T8SGで問題なくELRSできる様ですね。
・・・でもここまでは準備段階。ここからELRS(というかCRSFプロトコル)に踏み込んでいきます。
JDL2022R4 宮崎戦に参加
今年も行ってきました。JDL2022 Round4。宮崎での開催です。
JDL(ジャパン・ドローン・リーグ)は年間7戦のレースが開催され、各レースのポイント合計で年間の成績が決まるという仕組みです。この７戦は九州から北海道まで日本の各地で開催され、第４戦は宮崎開催なのです。
九州ではここだけなので、毎年１度だけ宮崎戦に参加しています。
機体
今回使った機体は昨年とほぼ同じ。ベースは息子の「お古」であるEachin製激安レース機Tyro99をベースに色々いじくった物です。
今回壊さなかったので、この１台で済みました。
また当然ながらフライトコントローラー(以下FCと略す)はHOIHOI-FC Rev2を載せています。
昨年はこのFCがマトモに動作するかドキドキでしたが、もうそこまでの心配はなくなりました。また、前回投稿した様に予備FCも準備しています。
まだ実績が少ないので予備とします。
でもまぁ、いい加減な機体ですよね。ウラから見るとベニヤ板を使っていたり。。。
JDLの中の人、A2Cさんにも心配してもらって色々とアドバイスして頂きました。（昨年はプロペラを逆につけて練習フライトを飛べなかったり、今回の練習フライトでもVTXのアンテナコネクタが抜けて映像が極端に弱かったり、 色々とやらかしてますからねー。 ）
こんな感じでドローンレースは初心者には優しいのです。
そして第一日目・・練習日
第一日目は練習日で５回の練習フライトが出来ました。練習フライトは予選と同じ形式なので９０秒間に何周飛べるかを競います。９０秒を過ぎて次に計測ゲートを追加した時の周回数が記録となるのです(同じ周回数の人同士ではタイムが早い方が上位となります)。
私が参加するオープンクラスは一番初心者向けのクラスですが上位の人は５周回ります。私は５回の練習フライトの内、ベストが３周でした。
本番では４周行きたいですねー。
いよいよ第二日目・・本番
予選は２回のフライトを行い良い方の記録が採用されます。
まず一回目スタート・・・しかし直後にゴーグルがずれてきて画像が見づらくなってきました。両手は送信機を操作しているのでゴーグルを修正する事はできません。しかしどんどん酷くなってくるので2周目の直線で速度を緩めてゴーグルを修正し、その後は良く見える様になったのですが、結局３周でゴールです。次からはゴーグルのベルトをもっときつく調整しておきます。
そして予選二回目スタート。 今回はゴーグルもずり落ちてはこないし、予選落ちすればこのフライトで終りなので後の事は考えずに速度を上げます。するとまあそれなりに飛べていますね。
という事で４周でゴール！一応本日の目標は達成です。
レースの結果
あとは結果発表待ち。この間に予選１回目の結果を見ると１８人中１０位でした。９位までに入れば予選突破なのであと一つ。
予選１回目は３周飛んで１０位だったので、４周飛べた２回目では順位が一つ上がれば予選通過できるはず（無謀にも期待してしまうのでした）。
で、結果が発表されると結局は予選落ち。・・・順位的には10位のままで、やっぱり皆さん２回目はタイムが上がってるんですね。
あと一つで予選通過と考えると惜しいのですが、タイムを見ると９位の人との差は約７秒もあり、これから考えるとそんなに惜しくもないです。
もっと精進するしかありません。
そして・・・
という事で天候にも恵まれ、適度に風が吹いたので暑さもそこまで厳しくもなく、年に一度のお祭りが終了しました。
また色々な人と話していると新たに作りたいものが次々と出てきて、そちらの面でも収穫がありました。
会場の「こどものくに」はすぐ横が遠浅のビーチです。浜に出てみると泳いでいるレース参加者もいました。
いいとこですねー。
BETAFLIGHT CLI設定の覚え書き
BetaFlightのCLI設定で、たまにしか使わないコマンドをすぐに忘れるのでメモ。
バッテリー電圧低下補正の設定。
# set vbat_sag_compensation = 80
補足：
出だしに比べてバッテリー電圧が下がってくると感触が変わってくる。そこで出だしのパワーを抑える事で最初から電圧が下がった時と同じ感触で飛べる様にする（なので出だしのフルパワーは下がる）。
SmartAudioのVer2.1の時にVTXに設定できるパワーを尋ねる。
# vtx_info
RUSH TINY TANKの例
# vtx_info
level 14 dBm, power 25 mW
level 20 dBm, power 100 mW
level 23 dBm, power 200 mW
level 25 dBm, power 300 mW
補足：
VTXテーブルの設定ページでは、そのVTXが使えるパワーの選択肢も設定するが、SmartAudioのVer2.0まではVTXが何mW出せるかはメーカーのドキュメントを見るしかなかった。
Ver2.1からはこのコマンドでVTXに問い合わせる事ができる。なおVer2.1からはdBm指定になっている。
フライトコントローラーを自作してみる。～その18～ またまたF7
久々のFC自作ネタですが、内容は前回とほぼ同じ。
壊れたFCを大量に貰ってきたので、ここからSTM32のF7マイコンを外して自作基板に載せるのです。
未だにSTM32マイコンは入手困難なので壊れたFCを頂けると非常に助かります。
こうしてみると見るからに壊れている基板からパッと見では何ともなさそうなモノまで色々あります。正常っぽいのはもしかして直るかもという期待もあるので今回は明らかに壊れていそうな中から2枚を選び、マイコンを外して新しいFCを2個作ろうと思います。
では取り外しから。ヒートガンで温めると・・・
隣の発振子も一緒に外れました。
もう一個も外しましょう。今度はレギュレーターらしきICも一緒に外れました。
次に新しい基板にハンダペーストを塗って部品を載せます。前回までは古くなったハンダペーストにアルコールをスプレーして無理やり使っていましたが今回は新しいハンダペーストを使う事にします。
そしてリフロー
なんかいっぱいブリッジしています。
でも裏面に進み、またリフロー。
裏面は結構うまくできました。
問題は表面のブリッジ。 基板から外した時にリードが曲がり、これを完全に直していなかったのでバラバラです。
実装前にもっと完璧に直しておくべきでしたね。
もう半田ゴテでやるしかありません。汗かきながらなんとか修正しました。
またSHコネクタが思いっきりずれているのを発見。
リフロー前に手でも当たったのな？こちらも修正。
なおこの部分、F4の頃はSBUS信号を入れる為に反転回路を通す必要があったのでXOR用ICを載せる設計にしていましたが、前回F7だと反転不要である事が判ったのでXORは載せずに直結しています。
ところで私のレベルでは実装をミスる事が結構あるので実機に載せてテストするまで安心できません。という事で実装テスト。
一番良く実装をミスるのがジャイロセンサーのMPU6000ですが、今回新品のハンダペーストが効いたのか一発で動作しました。
しかし片方の基板はバッテリーから電源を供給するとDCDCコンバータ付近からジーという音がします。このDCDCはバッテリー電圧から5Vを作り出しますが、5V波形をオシロで見てもガタガタです。
DCDC周りの配線を見まわしても原因らしきものが見当たらないし、以前「MP1584EN その3」の時にハズレICを引いているので今回もMP1584ENを外してみました。外観は異常ない様ですが、別の個体を取り付けてみると正常になったので、やっぱりハズレICを引いたんですかね（もう一度このICに戻せばハッキリするんですがやる気が起きません）。’’
今のところ10個買った内の2個がハズレなのは確率高すぎですね。やっぱりパチもんだったのかなぁ。まだ半導体不足になる前とはいえ10個で218円だったしなぁ。
ところでこの部分、VTX用の5V電源をチップコンデンサの根本から取っています。
回路図ではこの部分で・・・
ここから5Vを取ればUSBから電源供給する時にはVTXを動作させなくできます。
もし通常の5V端子からVTX電源を取ると、レースや大勢で飛ばすとき、PCと接続してレートを変更するだけでも電波が出てしまうと色々と不都合があるのです。
次に基板を設計する際はこのためのパッドを設けておこうと思います。
そんなこんなでFC2枚完成です。
実は今年も７月23,24日のJDL宮崎戦に参加する予定なので予備基板を作っておきたかったのです。機体に積んでいるFCは去年作ったF4搭載の物なので今回作ったF7の方が高性能ですが、レースまでに飛ばす機会がないので実績のある方を積んでいきます。
去年は自作FCで参戦する事が目標な感じでしたが、今回は人並みのタイムで飛ばし、できれば(オープンクラスですけど)予選を通過したいと思います。
ESC DR-20Aのファーム書換え
以前購入した激安ESC DR-20Aのファームを書き換えてみました。
まず最初に現状がどうなっているかを見ます。
FCのモーター端子2～3に接続してBLHeliSuiteで・・・
ん？現状のファームウェアはErased or unknownとなっていますね。一応パッケージにはBLHeliと書いてあるんですけど・・・
これだとどのファームを書けば良いのかわかりません。
ならばESCの基板を眺めまわします。
ラベルを剥がすと・・・
この写真を基にBLHeliがサポートするボード一覧のページ(どこだったか忘れた)と比べるとソックリのボードが載っていました。そこにはDYS SN20Aというファームを使えと書いてあります。
追記：本家ページのこの資料を見てました。33ページのところ。
↓ ↓
https://github.com/bitdump/BLHeli/blob/master/Atmel/BLHeli%20supported%20Atmel%20ESCs.pdf
ではDYS SN20Aを書き込んでみます・・・が、DYS SN20Aにも3つありますね。
とりあえず DYS_SN20A _MAINを選んだらメモリー不足っぽいエラーがでました。そこで DYS_SN20A _ MULTIを試すと書き込み成功。
追記：MAINはヘリコプターのメインローター用、TAILはテールローター用、MULTIはマルチコプター用との事です。
↓ ↓
https://github.com/bitdump/BLHeli/blob/master/Atmel/BLHeli%20manual%20Atmel%20Rev14.x.pdf
書込みが成功するとこんな画面となります。
モーターを繋いで回してみると動作も正常だったので3個とも書き込みました。
これで謎バージョンだったファームを最新に上げる事が出来ました。
ところで、なぜバージョンを上げたかったのかというと、回転方向をBIDIRECTIONに設定したかったから(謎バージョンにはこの選択がないのです)。こうするとスティックの中点をモーター停止、上を正転、下を逆転にできるのです。息子はこれで水中ドローンを作ろうとしています。
DSHOT信号を作ってみる。その２
前のを壊しまったので新たに発注していたNucleoボードが届きました。
実験を再開してモーターを逆転させてみようと思います。
右は壊したやつ。
前回「値として0~47のどれかを送ると逆転するはず」という様な事を書きましたが、結局何番なん？というと、やはり資料が見当たらないのでbetaflightのソースを眺める事にします。
探し当てたのはこれ。ソースツリーを~/Gitに置いたとして次の場所にあるファイルを見ると・・・
~/Git/betaflight/src/main/drivers/dshot_command.h
・・・こういう記述がありました。
typedef enum {
DSHOT_CMDtypedef enum {
DSHOT_CMD_MOTOR_STOP = 0,
DSHOT_CMD_BEACON1,
DSHOT_CMD_BEACON2,
DSHOT_CMD_BEACON3,
DSHOT_CMD_BEACON4,
DSHOT_CMD_BEACON5,
DSHOT_CMD_ESC_INFO, // V2 includes settings
DSHOT_CMD_SPIN_DIRECTION_1,
DSHOT_CMD_SPIN_DIRECTION_2,
DSHOT_CMD_3D_MODE_OFF,
DSHOT_CMD_3D_MODE_ON,
DSHOT_CMD_SETTINGS_REQUEST, // Currently not implemented
DSHOT_CMD_SAVE_SETTINGS,
DSHOT_CMD_SPIN_DIRECTION_NORMAL = 20,
DSHOT_CMD_SPIN_DIRECTION_REVERSED = 21,
DSHOT_CMD_LED0_ON, // BLHeli32 only
DSHOT_CMD_LED1_ON, // BLHeli32 only
DSHOT_CMD_LED2_ON, // BLHeli32 only
DSHOT_CMD_LED3_ON, // BLHeli32 only
DSHOT_CMD_LED0_OFF, // BLHeli32 only
DSHOT_CMD_LED1_OFF, // BLHeli32 only
DSHOT_CMD_LED2_OFF, // BLHeli32 only
DSHOT_CMD_LED3_OFF, // BLHeli32 only
DSHOT_CMD_AUDIO_STREAM_MODE_ON_OFF = 30, // KISS audio Stream mode on/Off
DSHOT_CMD_SILENT_MODE_ON_OFF = 31, // KISS silent Mode on/Off
DSHOT_CMD_MAX = 47
} dshotCommands_e;
enamを使ってコマンド毎の番号を定義しています。注目したのは20番と21番。
20だと正転、21だと逆転する様に見えます。更にソースを眺めると、コマンドを送る時は10回繰り返して送っており、それ以降は指定された回転方向になりそうな雰囲気です。10回送るのは少しくらい伝送エラーが出ても確実に伝える様にだと思います。
そこでNucleoボードのGPIOにボタンを2個追加し、これらを押すと回転数信号の代わりに20と21の値を出す様にプログラムを変更しました。
そしてESCとモーターを接続し、逆転ボタンを押した後に回転させると・・・何も起らず同じ方向に回っています。
何か違うのかなー。
上記リストを見ているとDSHOT_CMD_BEACON1というコマンドもあります。これはたぶんモーターを機体発見ブザー代りに鳴らす時のアレみたいですね。
betaflightからはブザーの音色を5種類から選べるのに対し、上記コマンドもBEACON１~5まであるので間違いないでしょう。値として1番～5番を送ってやればモーターから音が鳴りそうです。
そこでさっき取り付けた2個のボタンを押せば1や2を送る様にプログラムを変更しました。
そして試すと・・・やっぱり鳴りません。
うーん。
betaflightのソースをもっと細かく見ていけば解るんでしょうけど結構大変ですよね。
そこでFCから出てくる信号をオシロスコープで見ながら機体発見ブザーを鳴らしてみます。反転信号だと一瞬なので波形を捕まえ難いですがブザーだと繰り返し発生するので捕まえやすいのです。そして以下の事が判りました。
まず今までDSHOTで送る16bitのデータはこう思っていました。
値とCRCの間の1bit(右のLSB側から5番目なので以後「5bit目」と呼びます)は通常は0でテレメトリを要求するとき(RPMフィルタで回転数を取り出す場合等)に1にする。・・・と色々なサイトに書いてあります・・・
しかし実際にFCが出しているブザーコマンドを見ると1になっていました・・・
どうやら制御コマンドを送る時は５bit目を1にする様です。
ならばNucleoボードでもこの通りの波形を作ってみると・・・
鳴りますねぇ。
そして予想通りBEACON1 と2で音程が変わります。
また普段機体発見ブザーを鳴らすとピッ、ピッと断続的に鳴るのは FCから断続的にコマンドをON/OFFしている訳では なく、ボタンを押し続ければESC側で断続させてくれる様ですね。
試した様子を動画で・・・
では同様に逆転コマンドの20番、21番も5bit目=1でやってみます。
これもちゃんと逆転しますねー。
逆転に設定しておき電源を入れ直すと正転に戻ります(もしかするとどっかに覚えてるんじゃないかと思ったけど、そんな事ないですね)。
これも動画で・・・
という事でコマンドを送る時は右から5bit目を1にするのが正しい様です。という事はテレメトリの場合はどうなんでしょう？一つ判っているのはFCでRPMフィルターをONにするとDSHOT信号のH/Lが逆転している様です。
って事はテレメトリは5bit目ではなくH/Lの極性で決まるのかな・・・
あと回転数の値は48~2047だと思っていますが、コマンドである事が5it目で決まるのなら回転値は47以下を使っても良さそうな気がします。
このあたりはもうちょっと調べる必要がありそうですね。