HOI-LINKのELRS版

先日JDL宮崎の会場で「HOI-LINKのELRS版ってできないの?」と聞かれました。

今までのHOI-LINKS-BUS信号をUSBに変換してPCに送っているので主にフタバ系のプロポシステムが対象になっています。
一方ELRSというのはこちらで開発されているラジコン電波のプロトコルで、昨年あたりからドローンレース界隈でちょっとしたブームになっているのです。

私は今までELRSを扱える機材を持っていなかったのですが、そう言われるとやってみたくなるのが人情というもの。。。

システムは大体この図の様な感じになるので、試すには最低でも送信モジュール、受信モジュールは購入する必要がありますね。あと送信機本体はどうかな?

送信、受信のどちらのモジュールもCRSFプロトコル(ハードウェア的にはUART)で接続するので、このCRSFプロトコルを知るのがキモとなりそうです。

送信機本体でよく使われているのはファームウェアがOPEN-TXのものですが、ウチにはありません。さすがにこのために送信機まで購入するのはちょっとですね。。。
で、色々調べていくとどうやらJumperのT8SGが使えそうという事が分かってきました。
というのも送信機と送信モジュールの間はCRSFプロトコルというシリアル通信で接続します。で、T8SGにもCRSFプロトコルを選択できるのです。
ならばT8SGにCRSFプロトコルを出力させてみましょう。信号をオシロスコープで見ると、420Kbpsのそれっぽい信号が出ています。

420Kbpsも速いしデータの繰返し周期が約2mSなのも速いですねー。

なんか、イケそうですね。
ならば送受信モジュールだけ購入して実験してみましょう。

という事で発注しました。・・・そして到着したのは盆休みの最終日。もう少し前に届くと着手しやすかったんですけど、仕方ないですね。

購入した送信モジュールはBETAFPV”ELRS NANO TX”。このモジュールは技適が取れているので、日本では殆どの人がこれを使っています。
そして受信モジュールもBETAFPV”ELRS Lite RX”。この受信モジュールはメチャクチャ小さいですね。

これで材料が揃ったので、まずは普通に使えるかというところから。
こちらのページを参考にしながら試していきます。

まず最初にELRSモジュールは諸々の設定をするためにPCと接続する必要があります。送信モジュールとはUSB Type-Cで接続できるので簡単です。受信モジュールはUARTで接続しますが、フライトコントローラー経由でもBetaflightがうまくやってくれる様です(なのでFC経由でやりました)。

そして今回設定したのはこの内容。まずは送信モジュール・・・

そして受信モジュール・・・

各モジュールの設定ができたので接続します。まず送信側・・・

なおT8SGとNANO-TXの間はこの様に配線しました。

そして受信モジュールをFCと接続(実際にはファームを設定したときに接続した)・・・

FCの右についているのがERLS受信モジュール。
なお上についている基板は別の実験用なので関係ないです。

受信モジュールはTX/RX両方の信号を接続する必要があります。(テレメトリを使わなければRX側は繋がなくても良さそうに思えますが、たぶんファームの書換えにも使うのやっぱり繋いでおきます)。

ところで送信機←→送信モジュールの間、および受信機←→FCの間、両方共CRSFプロトコルで接続するという事になっているのですが、送信機側の接続はシリアル信号線は1本、受信機側は2本となっています。
たぶん送信機側は半二重、受信機側は全二重なのかと思いますが、名称的には区別ないんですかね?

そして送信機の電源を入れ、FCをPCに接続してBetaflightConfiguratorの”受信機”ページで確認すると、あっさり接続できていました。

T8SGで問題なくELRSできる様ですね。

・・・でもここまでは準備段階。ここからELRS(というかCRSFプロトコル)に踏み込んでいきます。

ふる~いソケットレンチセット

このふる~いソケットレンチセット・・・安物ですがウン十年使っています。

かなり前から中のプラスチックがボロボロで工具のおさまりが悪くなりました。

プラスチックだけ取り出すとこんな感じ

そこで作り直す事にします。
まず大体の寸法を測ってJw-cadで図面を書いて・・・

ダイソーの6mm厚MDFボードをレーザーでカット。

こんな感じで納めます。

しかし6mm厚MDFだけだとちょっと薄く、取っ手を持って歩くとケース内で工具がバラけます。
そこで蓋側にプチプチを貼り付けて対策しました。

いままでソケットがバラバラでどこに何㎜のがあるかわからなくなっていましたがこれで大丈夫。

小モス、U99に軽量化

今年6月から航空法が改正になるので100グラム以上のラジコン機は機体登録が必要になります。
この機体登録って6月以降に新規登録するとリモートIDという機器(でもまだ実物が世に出ていないっぽい)を積む必要がありますが、今の内に登録すれば3年間は免除なのです。 これには色々と言いたい事もありますが、体制をひっくり返せる様なエネルギーもなく、まずは所有する機体を順次機体登録しているところです。

大モス

で、下の写真の機体、ムサシノ模型のモスキート・モスを電動に改造したモノで私が初めて飛ばした機体なのですが、熊本地震の時に翼が壊れたままになっていました(本棚の上に乗せていたら揺れた拍子に本棚の裏側に落ち込んでプレスされたのです)。
なのでもう登録はしなくていいかと思っていたのですがそれも悲しいので応急修理して登録しました。

ムサシノ模型製キットを電動化したモスキート・モス。
ウチでは「大モス」と呼んでいる。

小モス

そして次の写真の機体。これはバルサとスチレンペーパーで作った1/2サイズのモスキート・モスですが、コイツが120gなのです。
これもこのままだと機体登録が必要なんですね。100gという制限はちょっと厳しすぎるなぁ。

スチレンで作った1/2サイズ。
「小モス」と呼ぶ。

これはできれば登録せずに済ませたいです。という事でU99(アンダー99グラム)を目指して軽量化してみました。
変更したのは次の点・・・

・モーターを2205→1105に変更。
・バッテリーを380mAhの2セルパック→Tiny用300mAhx2本に変更。
・サーボを4gタイプ→1.xグラム(公称値わすれた)品に変更。
・受信機をPWM出力→SBUS出力+PWM変換基板に変更。
・サーボコネクタを使わず直結。

その結果が次の写真で98gです。脚を除けば93gに収まります。

はかりに載せてみると・・・
98グラム!

飛ばしてみる・・・

機体サイズに対してパワー不足は感じません。でもやっぱり風には弱いですね。今までも弱かったけど軽量化するともっと弱くなった気がします・・・まあ98gじゃ仕方ないか。

各部の写真・・・

モーター。ペラはこれしかなかったので4inchの折ペラ。
ちょっと径が大きすぎる気がする。
いつだったかMakerFaireTokyoで買ったサーボ。

SBUS→PWM変換基板でサーボに接続。
変換基板はこの時作ったモノ(基板は再設計)。
サーボコネクタは使わず直結。
TinyWhoop用バッテリ2本を挿す為PHコネクタに変更。

最後に、今まで使っていて取り外した部品。

モーター、サーボが enRouteブランド だったりする 。
(ホビー用パーツを売っていた頃の)

これで今後も気兼ねなく飛ばせます。

自動金ノコ

気がついたら前の投稿から3か月が過ぎていました。
この間も色々とやってはいたのですが、更新をサボってしまったんですよね。
で、最近作ったのはこれ。自動金ノコ。

鉄を切るなら高速切断機が早いですがアルミを切る場合や外で作業できない時、いままで金ノコを使って人力で切っていました。でも時間はかかるし疲れるんですよね。

そこでみら太さんのブログに以前書かれていたのを参考に作ってみました。

ほぼ手持ちのガラクタから作りましたがギヤードモーターだけAliexpressで購入しました。12V167rpm、ブラケット付きで¥1,103-。

早速動作中の動画です・・・まだセンサーもスイッチも付ける前の画像。

その後、切り終わった事を判別するリミットスイッチと・・・

ノコ刃が引っかかってロックした場合を検出するフォトインタラプタを取り付けました。3秒以上変化がないとモーターへの通電を止めます。

センサーの信号をこの箱の中のArduinoで読み、パワーMOSでモーターをコントロールします。ボタンはスタートとストップ。

電源入力はXT60コネクタなのでドローン用3セルリポでも動くかも。
(野外で使う事はないですけど)。

使わない時、こんな感じで立てておくと邪魔になりません(多少)。

DSHOT信号を作ってみる。その2

前のを壊しまったので新たに発注していたNucleoボードが届きました。
実験を再開してモーターを逆転させてみようと思います。

左が新たに届いた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種類から選べるのに対し、上記コマンドもBEACON1~5まであるので間違いないでしょう。値として1番~5番を送ってやればモーターから音が鳴りそうです。
そこでさっき取り付けた2個のボタンを押せば1や2を送る様にプログラムを変更しました。
そして試すと・・・やっぱり鳴りません。

うーん。
betaflightのソースをもっと細かく見ていけば解るんでしょうけど結構大変ですよね。

そこでFCから出てくる信号をオシロスコープで見ながら機体発見ブザーを鳴らしてみます。反転信号だと一瞬なので波形を捕まえ難いですがブザーだと繰り返し発生するので捕まえやすいのです。そして以下の事が判りました。

まず今までDSHOTで送る16bitのデータはこう思っていました。
値とCRCの間の1bit(右のLSB側から5番目なので以後「5bit目」と呼びます)は通常は0でテレメトリを要求するとき(RPMフィルタで回転数を取り出す場合等)に1にする。・・・と色々なサイトに書いてあります・・・

Hパルス幅が長いと1、短いと0を表します。

しかし実際にFCが出しているブザーコマンドを見ると1になっていました・・・

どうやら制御コマンドを送る時は5bit目を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以下を使っても良さそうな気がします。

BetaflightでRPMフィルターONの波形

このあたりはもうちょっと調べる必要がありそうですね。

Nucleoボードを壊した

やってしまいました。
先日STM32 Nucleo-F411REボードでDSHOT信号を作って、もう少し調べようと試していたら突然PCとの接続ができなくなったのです。

Nucleo-F411REボード

よく見るとICクリップが壊れてバネが見えており、これがボードのST-LINK部分に接触していたみたいです。

根本で折れてバネが見えている。

ST-LINKのファームを更新(なぜかこの時更新はできた)したりPC側のドライバを入れ直してもダメです。

このボード、既に3.3Vのレギュレータが壊れており外付けで動かしていました。
自作フライトコントローラーの実験で屋根くらいの高さから落とした事もあります。
もうそろそろ諦めて新しいのを発注しました。秋月電子で1850円の出費です。

DSHOT信号を作ってみる。

先日自作フライトコントローラーでRPMフィルターをいじった時DSHOT関係でハマって以来、気になっていました。
何でも理解を深める為には作ってみるのが一番、という事でSTM32マイコンボードでDSHOT信号を作ってモーターを回してみます。

DSHOT とはフライトコントローラーからESCに伝える信号のプロトコルで、 これによりモーターの回転量をESCに伝えます。
同種のプロトコルには色々(PWM,ONESHOT,MULTISHOT等)ありますが、恐らく現在のドローンレースで一番使われているのがDSHOTなのです。

DSHOT の概要については以前NONSAYAさんが紹介されています。
これを読んで大体のところは理解できましたが、実際に信号を作るためにはもう少し詳細な情報が必要です。で、色々探したけれど全体を通した仕様というか、本家のサイトの仕様書みたいなのが見つからないのです。

それでもこの辺りのサイトが参考になりました・・・

DSHOT概略

詳しい内容は上記サイトを読んで頂くとして、ここではサラッと概略を書きます。
まずDSHOT波形の例・・・

  • まず16発のHパルスを1セットとし、少しの時間を置いてこれを繰り返します。PWMっぽくも見えますが一発ずつパルス幅が長かったり短かったりします。
  • Hパルスの幅が短い場合が0、長い場合は1を示し、これにより16ビットのデータを表します。
  • 左から11bit分がスロットル量を表します(左がMSB)。この11bitの値は48から2047迄なので2000個の値を表せます。なお0~47は特別な意味を持ち、例えば0だとディスアームです(それ以外の値は資料が見当たりませんが、モーター逆転等が含まれる様です)。
  • 12bit目は基本は0ですが、ここを1にするとテレメトリ要求の意味となり、16発のパルスを送り終えた後に今度はESC側から信号を送ってきます。RPMフィルターではこの機能を使って回転数を読み出している様ですが今回の実験ではそこまでの域には達しておらず、一方的に回転数を伝えるのみです。
  • 13bit目から16bit目の4bitはこれまでの12bitデータに対するCRC値で、次の式で算出しています。CRC=(DATA ^ (DATA >> 4) ^ (DATA >> 8)) & 0xf
  • これまで一言でDSHOTと言ってきましたが実際にはDSHOT150、
    DSHOT300、 DSHOT600、 DSHOT1200等、速度に応じた名前がついています。150とか300とかの数字は1bitを表すパルス幅が150Kbpsとか300Kbpsという意味みたいです。なのでDSHOT300での1bit分のパルス間隔は1/300Kbps=3.33μSとなります。
  • DSHOT300の場合、パルス間隔は上記の通り3.33μSで、L(を表す短いパルス幅)は1.25μS、H(を表す長いパルス幅)は2.5μSです。

マイコンボードSTM32 Nucleo-F411RE

マイコンボードにはNucleo-F411REを使用します。このボード、フライトコントローラの実験で使ったときに3.3Vのレギュレータを壊してしまい、それ以来外付けレギュレータで無理やり動かしています。

ピロッと付いているのが3.3Vレギュレータ。

開発環境

開発環境にはSTマイクロエレクトロニクス社純正のCubeIDEを使用します。
これにはCubeMXというコード生成ツールが付属していて、周辺機能の初期化をGUIで設定できるので便利です(でもドキュメントが分かりにくい気がする)。

構想

DSHOTの信号をどうやって作りだしましょう?DSHOT150でも6.66μS毎に異なる幅のパルスを生成する必要があります。手持ちのESCがなぜかDSHOT150では動作しないのでDSHOT300を使うとなると3.33μS周期という結構な速さで更新が必要です。
タイマーをPWMモードで使うのがやり易そうですが、1パルス毎に幅を変える必要があるのでDMAを使って都度書き換えてみます。
これにはあらかじめRAM上のバッファにパルス数分のデータを格納しておき、1パルス毎にDMAコントローラーが (パルス幅を決める) CCRレジスタに転送していくのです。図にするとざっとこんな感じ。

作る・・・

実際にはRAM上のバッファはデータの16個分に加えて空白期間34個分の合計50個分を用意し、後半の34個分は常に値を0にしています。
以上の動作は一旦タイマやDMAコントローラーを設定すればCPUとは係りなく動き続けます。
なおRAM上のバッファはDMAが呼び出す割り込み処理ルーチン内で書き換える事にします。DMAの割込みはバッファの内容を半分出力した時点で呼ぶ事もできるので、これを用いて空白期間の間にデータを書き換えています。

そしてメインプログラム側ではDSHOTに出力する値を決めます。
今回はスイッチと可変抵抗を1個ずつ使い、スイッチはアーミング、可変抵抗は回転数を決める事にします。なのでGPIO一つとA/D入力一つが必要ですが、これもCubeMXの機能で簡単に設定できます(設定後の使い方がドキュメント見てもわかりずらいのですが)。

メインルーチンは初期化後無限ループに入ります。このループ内で可変抵抗の値を取るためAD変換を実施し、ESCに送る16bitのデータを作ります。
これをRAM上の仮バッファに置くところまでがメインルーチンの処理です。
そして仮バッファの値をDMAバッファに転送するのがDMA転送が半分終了した時点で呼び出す割り込みコールバックルーチンで行います。わざわざバッファを2段階にしているのはDMA転送中にバッファを書き換えてしまう事を防ぐためです。

詳細はソースを参照ください。
これ→DSHOT_MX.zip
プロジェクトディレクトリ丸ごとなので他のプロジェクトと同列の場所に置いて下図のメニューで開けると思います(試した限り大丈夫でしたがIDEのバージョンが違うとエラーとか出るかもしれません)。

動かしてみる

ESCに繋いでモーターを回してみたところを動画で・・・

そして・・・

あとモーターを反転させるのを試したいのですが、このあたりの情報が見つかりません。Betaflightのソースを解読すべきなのでしょうか?

フライトコントローラーを自作してみる。~その17~ F7マイコンを載せる。

自作フライトコントローラーにはSTM32F411というマイコンを搭載していました。これは普通に飛ぶには十分な性能ですが、RPMフィルター等という負荷の高い処理には計算周期を下げる必要があるのです。そこでもっと早いマイコンを試したかったのですが、恐らく昨今の半導体不足のせいで納期が未定だったり発注してもキャンセルされたりして入手できていなかったのです。

そこに救世主が現れました。

宮崎ドローンクラブにお邪魔して練習させていただいたとき、基板のパターンがはがれて使えなくなったフライトコントローラーを頂いてきたのです。
これにはSTM32F722RET6という、まさに欲しかったヤツが載っています。

という事で、この基板からマイコンだけ取外しHOIHOI-FCに載せてみました。
今回も色々発見があったので忘れない内にこのブログに書いておきます。

まず頂いた基板をヒートガンで温めてマイコンを外しました。

そしてHOIHOI-FC Rev2基板に搭載します。

組み立て後の一発目、安定化電源から5Vを供給して電流を測ると180mAも流れていました。 F411搭載基板では70mA程度なので、 これはどこかミスったと思いショートした箇所を探したのですが、それらしき所は見当たりません。

そこで恐る恐るUSBケーブルでPCとつないでみたところ、あっさりとDFUモードに入りファームを書き込む事が出来ました(F722用ファームは前にビルドしておいたのです)。
もしかするとOSDデバイスに大電流が流れているのかという事も考えたのですが、カメラとVTXを繋ぐとこちらも正常動作しています。
またESCと接続してモーターを回しても正常です。
暫く通電していると結構温まりますがF7だとこれくらい流れるのでしょうか?データーシートには最大300mA流れる様な事が書いてあるので今の所これで正常だろうと思っています。

という事で、とりえあずはあっさり動作したかと思ったのですが、そう簡単にはいきませんでした。

受信機からSBUS信号を入れても受け付けてくれないのです。

このFCでは下図の回路でUART6RX端子にSBUS信号を入れています。

SBUS信号は通常のUARTとは極性が逆なので間にXORを入れて反転し、将来通常のUARTデバイスを接続したくなった場合はJP3をショートさせる事で正極性に戻せる様にしているのです。
今回SBUS信号を何故か受付けず、色々試してもダメなので 反転回路を外部のブレッドボードに載せてUART2から入れてみたけど、これでもダメでした。

こりゃファームの設定が間違っているのかと見直してもそれらしい箇所が見当たりません。

で、色々試している内に突然動作したのです。
改めて回路を見直すと、誤って外部で反転させた信号をまたXORで反転させていました。
・・・という事は反転しなくても良かったの?
そこでXORのジャンパーJP3をショートさせると正常に動作する様になりました。またUART2に直接(反転なしで)入力しても動作します。

F4の時は反転必須だったのにF7だと不要になった・・・?
F7のデーターシートでUARTの機能を確かめると次の文言があります。

「Separate signal polarity control for transmission and reception」

極性を個別に設定できる?(って事は個別じゃなければ今までもできたんか?)
詳しい事は解りませんがマイコン自体に極性を反転する機能が付いたのでBetaflightがこの機能を使って上手くやってくれるみたいですね。
という事はF4の時みたいにSBUS信号は反転回路がついたUART端子に接続しなければならないという制約はなくなり、F7なら受信機をどのUART端子にでも接続できるのだと思います。これは便利になりましたね。
今回はXORの片方の入力をLに落として対処しましたが次からはXORの搭載自体を止めて直結しようと思います。

という事でF7で一通りの機能が動作したので息子が持っていた適当な機体に載せてみました。
飛ばしてみると上手く飛んでいる様です。

RPMフィルターでハマる。

次にせっかくのF7なのでRPMフィルターをオンにすると・・・
フリップした時に変な挙動をしました。何だか急に思った以上のレートで回転した様です(さっきから「様です」と言うのはこの辺りのテストパイロットは息子に任せているのです。自分じゃフリップとかできないので。)。
もう一度RPMフィルターOFFに戻すと正常。またONにすると異常。
明らかにRPMフィルターが絡んでいます。

なんか、波形的な問題か?
そこで写真の様な中継基板を作ってFCとESCの間に割り込ませ、オシロのプローブを当ててみます。

で、波形はこれ。。。

モーター2 のDSHOT600 双方向ONの波形

ちょっとオーバーシュートはあるけど鈍ったりはしてなさそうですけどねー。
気になって市販のFCを眺めると、STM32の出力とモーター信号の間に100Ωの抵抗が載っていました。たぶんオーバーシュートを抑えるダンピング抵抗ですかね。または双方向Dshotで万一信号がぶつかった時の保護?

市販FCはこうなっていました。HOIHOI-FCには抵抗はなく直結です。

これが無いとだめなのかな?そこで先程の中継基板に100Ωを割り込ませてみましたが・・・効果はありませんでした。

ここであと一つ心当たりが・・・RPMフィルターをONにして動作を確認したとき、BetaflightConfiguratorのモータータブを使ってモーターを回転させ、回転数が取れている事を確認しますが、この時モーター2だけエラーレートが0.6%前後となっていたのです。

赤線部分が回転数取得のエラーレート。

BetraflightのWikiによれば1%程度までに抑える様にと書かれています。0.6%なので良さそうにも思えますが、過去に幾つかの市販FCで試した時は0%しか見たことはなく、今回の動作異常と関係しているかどうかは分かりませんがちょっと気になります。

この原因、色々試した結果 ファームをビルドする際のコンフィグファイルtarget.hに以下の記述があるとダメでこれをコメントアウトするとエラーは消えました。

#define DSHOT_BITBANG_DEFAULT   DSHOT_BITBANG_OFF

この記述はCLIで設定を見たときの’DSHOT_BITBANG’に相当します。
‘DSHOT_BITBANG’ はON|OFF|AUTOのいずれかを選択する内、上記行が記述してある場合はOFF、上記行を削除するとAUTOになる様です。
そして回転数取得のエラーはOFFだと発生し、AUTOまたはONだと発生しませんでした。

この辺り、BetaflightWikiにはOFFにしろと書いてある様に見えるので(英語ですが、たぶんそういう意味だと思います。汗。)、試した現象とは逆なのです。
どなたか真相が分かりますか?(そもそも DSHOTでのBITBANGとは何を意味するのでしょう?)。

何はともあれ市販のFCを見てもAUTOになっているし、HOIHOI-FCもAUTOで様子を見る事にします。

そして回転数取得エラーが無い状態で飛行させると「変な挙動」は無くなりました。やっぱり回転数エラーと同じ原因だったみたいですね。
以上で当面の使用には問題はなくなりました。

でもあと一つ気になっている事があります。

HOIHOI-FCはモーター8個まで制御できる端子を設けており、いずれオクタコプター(モーター8個の機体です)を作るという野望があるのです。
ここでCLIモードでDUMPコマンドを使って設定を見るとDMA周りが次の様になっていてB09端子にDMAが割り付けられていません。

 dma pin B04 0
pin B04: DMA1 Stream 4 Channel 5
dma pin B05 0
pin B05: DMA1 Stream 5 Channel 5
dma pin B06 0
pin B06: DMA1 Stream 0 Channel 2
dma pin B07 0
pin B07: DMA1 Stream 3 Channel 2
dma pin B08 0
pin B08: DMA1 Stream 7 Channel 2
dma pin B09 NONE
dma pin A00 0
pin A00: DMA1 Stream 5 Channel 3
dma pin A01 0
pin A01: DMA1 Stream 6 Channel 3

なおDMAというのはDirectMemoryAccessの略で、CPUを介さずメモリーと周辺レジスタとの間でデーター転送を行う機能です。その間CPUは別の仕事ができるので負荷が下がるのですが、具体的にDSHOTの制御として何をしているのかは分かりません。
これでも全端子ESCに繋いで回せる事は確認済みなのですが・・・。
でも一つだけDMAを使えないというのは気持ち悪いですよね。 もしかするとこれもRPMフィルターで影響を受けるのかも。

で、B09端子というのはモーター6に割り付けています。これはファームのコンフィグファイルtarget.cの中で下記(ここではPB9と表現)の様に指定しています。
そしてこのモーター端子はタイマー4のCH4を使用しています。

 DEF_TIM(TIM3, CH1, PB4 ,  TIM_USE_MOTOR,  0, 0), // MOT1
DEF_TIM(TIM3, CH2, PB5 , TIM_USE_MOTOR, 0, 0), // MOT2
DEF_TIM(TIM4, CH1, PB6 , TIM_USE_MOTOR, 0, 0), // MOT3
DEF_TIM(TIM4, CH2, PB7 , TIM_USE_MOTOR, 0, 0), // MOT4
DEF_TIM(TIM4, CH3, PB8 , TIM_USE_MOTOR, 0, 0), // MOT5
DEF_TIM(TIM4, CH4, PB9 , TIM_USE_MOTOR, 0, 0), // MOT6
DEF_TIM(TIM2, CH1, PA0 , TIM_USE_MOTOR, 0, 0), // MOT7
DEF_TIM(TIM2, CH2, PA1 , TIM_USE_MOTOR, 0, 0), // MOT8

なぜこのモーター6だけがDMAが割り当てられないのか、この原因を探るため、STM32F72xxxリファレンスマニュアルを調べると下の表がありました。タイマー番号_チャンネル番号毎にDMAの割り当てが決まっている様です。
表の中で色を塗っている項目はHOIHOI-FCでモーターに使っているタイマー番号ですがモーター6に割り当てているTIM4_CH4は記載がありません(なので恐らくDMAが割り当てられない)。

次に基板を変更するときはこの辺りの端子割当ても考え直そうと思います。
また今の基板のままオクタコプターをやるなら他の端子を使う事も可能です。例えば現状UART2に割り当てているPA2,PA3だとTIM2_CH3,TIM2_CH4なので,どちらもDMAの割り当てがあります。UART端子は1本減りますが。

という事で・・・

まずはF7でも使えそうだという事が分かってきました。
次に基板を作るなら直したいところが色々と溜まってきましたが 、そもそもF7のマイコンがまだ普通に買えそうにないんですよね。

フライトコントローラーを自作してみる。~その16~ JDLで飛ばす。

自作フライトコントローラーの目標の一つにレースで飛ばすというのがありました。
そこで今回 JDL(ジャパン・ドローン・リーグ) 2021年Round4の宮崎戦に息子と共に参加してきました。
実は昨年の宮崎戦にも参加したのですが結果はボロボロで、今回は少しはマシに飛ばせるでしょうか? なお息子は今回本気で臨んでいます。

こんなコースです。

通常JDLは土・日の二日間あり、初日は練習日、二日目が実際のレースとなります。しかし今回は土曜日が雨(雷も!)のため中止となり、日曜日のみの開催となりました。実は中止を知らず早起きして宮崎まで行ってしまったので、初日は宮崎ドローンクラブSkyDRONEの方々と一緒に練習させていただきました。

なお私が飛ばす機体はこれ。
これTyro99というかなり安物で普通レースに使う人は見かけない機体をベースに、上側だけ載せ替えて軽量化したもので、元は息子のお古なのです。

ここに自作フライトコントローラー’HOIHOI-FC’を載せています。
がんばってくれよー(というか自分が操縦頑張らにゃならんのですが)。

緑の基板がHOIHO-FC

・・・そして日曜日。
時間を詰めて朝イチに一回だけ練習フライトが設けられる事になりました。

という事で早々に(一度きりの)練習フライトの順番が回ってきます。
スタート位置に機体を並べ、ゴーグルをつけて他の選手と3人で操縦席に座ります。そしてスタート・・・と思ったら私の機体はモーターだけブンブン回って離陸しません。なんと、プロペラ2枚を逆に取付けていたのです。やってもうた~!
他の選手はフライトしているのでコースに入る訳にはいかず、一度きりの練習フライトは飛べずに終わりです。

あとはぶっつけ本番で2回の予選フライトを飛ぶのみ。

そして予選フライト1回目。機体をセットした時に少しモーターを回して確認したので今回はちゃんと離陸しました。
操縦席の後ろで、以前我が家の工作室に来られた事のあるNONSAYAさん(井上さん)がアドバイスして頂けたので落ち着いて飛ばすことができました。
でもシミュレーターではもっとスロットルを開けれたんですがねー。実機だと辛うじて落ちずに飛んでいる程度です。結局既定の時間内にコースを2周して終了。
でもまあ、自作フライトコントローラーでJDLを飛ぶという目標は達成したので良しとしましょう。

私が参加しているオープンクラスは多くの人が規定時間内にコースを3周回ります。そして4周できれば予選通過というのが今回の目安になりそうです。
私としては次は3周を目指さねば(最初っから4周とは言わない)。

そして予選フライト2回目。
今度は先程よりもスロットルを開け気味で飛んだのですが、2周目の最終ゲート直前(ここって直角に曲がる初心者泣かせのポイントなのです)でフラッグに接触して墜落。リスタートして最終ゲートを通過したのですが約1.5秒足りず結局2周で終了です。

以上で私のJDL2021 Round4は終了しました。

息子はというと、9人が予選を通過できる内の8位で何とか準決勝に進んだ様です。
そして準決勝も他の選手がミスってくれたおかげで決勝に進み、この時点でオープンクラスからエキスパートクラスに昇格決定!
決勝戦ではもう飛ばすしかないという事で何か吹っ切れた様にスロットルを開けて2周目の時点では先頭を飛んでいたのですが、煙を吐いた機体が騒ぎになった(その瞬間息子の機体かと思ったのですが別の選手の機体でした)のに動揺してクラッシュ、何とかリスタートしたのですが結果は3位で終了です。

3位なので表彰状をもらっています。

結果として・・・
・自作フライトコントローラーでレースを飛べた。
・息子はエキスパートクラスに昇格した。
という事で収穫ありとしましょう。


Prusa i1を復活させてTPUをプリントする

ドローンパーツを3DプリントするのにTPUのフィラメントを使いたくなりました。TPUというのはゴムっぽい素材で柔軟性がある為、ぶつけても壊れにくく、バンパーの様にショックを吸収してくれるのです。

現在我が家の3Dプリンターは2号機が稼働しておりABS素材を調子よくプリントしています。

3Dプリンター2号機

しかしこれ、ボーデンタイプなのでエクストルーダーからホットエンドまでパイプの中をフィラメントが通っていきます。この場合TPUの様に伸縮性があると上手くプリントできる気がしません。
いや、世の中ではボーデンタイプでTPUを出力されている方も居られる様なので試してみるのもアリなのですが、それよりも以前使っていたPrusa Mendel(今はi3が主流ですがこれは初期型だからi1なのです)を使う方が可能性がありそうです。

という事で引っ張り出してきます。
まだバラしてなくてよかった。

Prusa Mendel (MakerGearのキット)

コントローラーのArduinoMegaは外してあったので取り付け直し、ファームウェアとしてMarlinを書き込みました(この辺りは勉強を兼ねて息子にやらせています)。

そしてプリントしてみると・・・
上がTPU、下は2号機を使ってABSで出したもの。出したデータは若干異なりますが、TPUの方は形がいびつで表面もデコボコのゴーヤみたいな仕上がりです。

で、色々条件を変えて試しました。

試行錯誤の後・・・

そして分かってきたのは、速度をかなり落とす必要がある事。最初は30mm/Sでプリントしていましたが20mm/Sに落とすとまあまあ。10mm/Sだとだいぶマシになります。しかし全部10mm/Sだとものすごく遅いので外側だけ10mm/Sで内部は15mm/Sあたりに設定しました。
これで全体の形はまあ納得がいくプリントになったのですが、やっぱりまだ表面がゴーヤ肌で、温度を変えてもある程度以上改善しないんですよね。

ひとつ気になったのはノズルを少し浮かせて空中に樹脂を出した時、出口で縮れた様になって真っすぐ出ないので、これがゴーヤ肌になる原因かと・・・
ならばとノズルの掃除をしてみたけど改善しません(上手く掃除できていなかったのかもしれない)。
そこで2号機を2ヘッド化してやろうと入手していたJ-Headのホットエンドがあったので、これに交換したところ縮れ麵だった樹脂がかほぼ真っすぐになり、プリントするとゴーヤ肌だったのがほぼ納得のいく積層跡となりました。

旧ホットエンド。
MakerGear製
J-Headに交換してプリント中。

余談ですがガラスを止めているのは「バチクリップ」という名前のクリップです。良くある黒くて針金を折りたためる様なタイプのクリップよりも薄型なので邪魔になりにくくて気に入っています。

という事でTPUが使える様になったので色々とパーツを出力中です。

2号機xABSには負けるけど
まあ納得できる仕上がりになった。