フライトコントローラーを自作してみる。~その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のマイコンがまだ普通に買えそうにないんですよね。

フライトコントローラーを自作してみる。~その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の回路を載せてみたいと思います。

フライトコントローラ OMNIBUS F4 v3 修理

息子が買ったフライトコントローラー、OMNIBUS F4 v3 。Aliexpressで¥1450でした。
例によってヤツは小遣いをすべて継ぎこんでいる様です。

ところが新品なのにバッテリーから入れる配線の極性を間違って印加し、煙を吐かせました。基板上のスイッチングレギュレータが壊れて5V系統の電源が出てこなくなっています。

その他の機能は生きているので外から5Vを印加すれば動作はします。なのでESC側にBEC回路があればそこから電源をもらえますが4in1ESCにはBECが載っていなかったりするのでこのままだとちょっと辛く、基板上のレギュレータICを交換してみる事にしました。

壊れているであろうレギュレータICを拡大鏡で見ると1F8と書いてあります。これをネット上で辿った結果、MP2859DJというICに行き当たり、Aliexpressで10個入り¥141(送料無料)を発注しました。この手の部品は数が出ない為か配送時間が若干長く、最大29日となっているので気長に待ちます。

で、忘れかけた頃に届いたので交換に取り掛かります。
まずは基板からICを外します。6pinとはいえ細かいので外すのは結構大変です。パターンを少し剥がしてしまいながら何とか外しました。

一応外した状態でパターンと周辺部品との配線を確認し、配線が切れていないことを確かめます。

そして新しいICを取付け。取付けは大きな問題もなく完了。

電源を入れると問題なく5Vが出ています。「復活!」

なお5V電源回りをテスターでみたところ下図の様な配線になっている様です(テスターで測っただけなので保障はありません)。5Vの電源ラインは今回のレギュレータ、USB、PWM端子の3系統の入力がありダイオードで分離してあります。図にはPWM端子を一つしか書いていませんが実際は複数あって5V信号も4本ありますが、これらは個別には分離されていない様なので、4in1ではない個別ESCを使う場合は気を付けないとBEC間が短絡しそうな気がします。