フライトコントローラーを自作してみる。~その19~ F7マイコン購入

コロナ禍による半導体不足で長らく手に入らなかったSTM32F722マイコン、最近Aliexpressを見たらマトモな値段で売られているのを見つけ、2個注文したのが届きました。
1個1297円×2個。

自作FCの中に壊したのが1枚あって、どうもマイコンが壊れているっぽいのでこれに交換しようと思います。
でも最近、ちょっと忙しいのでもう少し先。。。

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を頂けると非常に助かります。

ESCまで含まれていますがこっちの自作は難易度高く、今の所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枚完成です。

実は今年も7月23,24日のJDL宮崎戦に参加する予定なので予備基板を作っておきたかったのです。機体に積んでいるFCは去年作ったF4搭載の物なので今回作ったF7の方が高性能ですが、レースまでに飛ばす機会がないので実績のある方を積んでいきます。
去年は自作FCで参戦する事が目標な感じでしたが、今回は人並みのタイムで飛ばし、できれば(オープンクラスですけど)予選を通過したいと思います。

フライトコントローラーを自作してみる。~その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位なので表彰状をもらっています。

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


フライトコントローラーを自作してみる。~その15~ 基板データ公開

フライトコントローラーを作ってみませんか~?
HOIHOI-FC F411 Rev2基板のKi-cadデータとガーバーを公開します。

基板データ

Ki-cadデータ→HOIHOIFCF411R2.zip
ガーバーデータ→HOIHOIFCF411R2_gerber20210314.zip
※Ki-cadはVer5.1.9で作成しました。
 ライブラリのキャッシュファイルも含んでいるので大丈夫なつもりですが、
 もし何か不足していたら連絡ください。
※そのままの形で基板を発注するならガーバーデーターだけで大丈夫です。

部品表

部品表→HOIHOIFCF411Rev2BOM.ods
※参考に私の購入先も記載しています。

部品配置図

部品配置図(表)→HOIHOIFCF411R2PlaceFront.png
部品配置図(裏)→ HOIHOIFCF411R2PlaceBack.png

基板データの使用に関する表示

今までこのサイトの掲載物に著作権的な表示をしてこなかったのですが、利用しやすくする為、きちんと表示したいと思います。
どういう形式が良いか考えた結果、クリエイティブコモンズ CC BYとして公開するのが良かろうという結論になりました。詳細はこちらを参照ください。

クリエイティブ・コモンズ・ライセンス
上記基板パターンはクリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供しています。

Betaflightファームウェア

ファーム→ betaflight_4.2.8_HOIHOIF411R2_101738d8e.zip

FCを作るには

もっと詳細に書くべきですが取り合えず簡単にいうと・・・
まず基板メーカーにガーバーデーターを送って発注します。この時メタルマスク(裏/表)も一緒に作成します(私はPCBGOGOに発注しました)。
並行して部品表に記載した部品を入手します。
メタルマスクを使って基板にクリームハンダを塗ります。
配置図に従って部品を載せ、リフローすれば完成!
あとはBetaflightConfiguratorを使ってファームを書き込んで使います。
※細かい所は過去に書いたブログを参照願います。

フライトコントローラーを自作してみる。~その14~ マイコンパワーアップ検討

これまでフライトコントローラーに搭載するマイコンはSTM32F411RET6を使っていました。パッケージはLQFPの64ピンです。普通に飛ぶ為の性能としてはこれで問題ないのですが、RPMフィルターを使う場合はPIDループの周波数を落とす必要がある様です。RPMフィルターとはESCからモーター回転数の情報を読み取ってノイズを取り除く機能で色々な効能があります。
詳しくはここ→https://github.com/betaflight/betaflight/wiki/Bidirectional-DSHOT-and-RPM-Filter
そう考えるともっと処理能力の高いSTM32F405やSTM32F722あたりを使ってみたくなるのですが、前回も書いた様に中々入手ができません。

取りえず今のところは以下の様な構想をするにとどめておきます。

STM32F405RGT6

最大クロック周波数がSTM32F411の100MHzに対しSTM32F405は168MHzとなります。
これもLQFP64パッケージでF411とほぼ同じピン配置なのですが微妙に異なるところがあるんですね。
下図はデーターシートの抜粋で、31pinと47pinがF411ではVSSだったのに対しF405ではVCAPになっています。
なおVCAPは内蔵レギューレータにキャパシタを繋ぐ端子です。

今回作ったRev2基板では47pinはキャパシタまたは0Ω抵抗を選べる様にしていました。F411の場合は0Ω抵抗を取り付けてGNDに落とし、F405の場合はキャパシタを取り付けるという算段。。。

しかし31ピンについてはGNDに直結してしまいました。。。これはマズったですね。
パターン的にカットもできないのでF405を取り付けるときは31ピンのリードを無理やり曲げて30ピンのパターンに接続するしかなさそうです。ここも次にパターンを変更する事があれば0Ωかキャパシタを選択できる様に改良しましょう。

STM32F722RET6

F722になると周波数も最大216MHzとなります。
コイツのLQFP64版はVSS,VCAP共F411と同じ配置なので換装し易そうです。ただし25~29ピンの並びがF411/F405とは違うんですよね。なんで同じにしてくれないのでしょう。

STM32F722RET6のピン並びがRev2基板で問題になるのは27pinに接続している電流センサー端子です。27pinはF411/F405ではPB1が割り当てられているのですがF722ではPB2となっています。最初はPB2でも問題ないだろうと思っていたのですが機能をよく見るとPB2はA/Dコンバーター入力ではないんですね。アナログ値を取り込めないのでF722だとここから電流値を読めません。まあこれはモーター7,8やUART2に割り当てている端子にアサインし直すのも有りだと思うので大きな問題はないでしょう。
(そもそもワタシ電流検出機能を使った事がないのです)

まあいずれにしてもマイコンが入手できないとどうしようもないのですが。
いま再びRSコンポーネンツを見たら入荷予定が11月とか来年とかそんな予定になっていました。やれやれです。

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

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

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