Category Archives: HOI-Link

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で接続出来る様に予め設定しておきます。

裏面:赤い線がELRC受信機に5Vを入れる配線。

そうするとこんな感じで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-EX_20220919.zip

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プロトコル)に踏み込んでいきます。

HOIドン入手

NONSAYAさんから販売仕様のHOI-LINK-HRを頂きました。
HOI-LINK-HRに受信機を一体化したドングルなので通称「HOIドン」なのです。

立派な箱に入っています。
内容物はドングル本体とクイックリファレンス
ボディは3Dプリントパーツですが綺麗にプリントされています。

いままで使っていたFRISKケース版と比べてかなりコンパクト。
受信機一体なので電線を切る心配がなくてよいです。

フリスクケース版の様に電線がピラピラしません。

では早速PCに接続してみます。ドングルの穴から適当なものを突っ込んでボタンを押しながらUSBポートに挿せば送信機とバインドされます。

ファームゥエアは最新のRev2が書かれていました。
このファーム、USBの更新レートを上げて遅延を減らしたバージョンで、旧版を購入された方にはNONSAYAさんが無償バージョンアップをされるそうです。

なおこのブログを見ていただいている方には申し訳ないのですが、Rev2のファームは大人の事情によってここでは非公開なバージョンなのです。すみません。
それはつまり、HOIドンが売れると私にも分け前を頂けることになっているのです。^^;

・・・という事でご購入はこちらへどうぞ→NOSAYA Graphics

HOI-LINK-HR の遅延を減らせるか試す。

NONSAYAさんが販売されて以来、HOI-LINK-HRがドローンレース界隈で静かな話題になっている様です。このHOI-LINK-HRはSBUSから受けた11bitのデータを8bitに減らさず11bitのままPCに届けるので分解能が上がっていて、私には効果が体感できませんがプロには評判がいい様です。
そこで更なる改良として遅延を少しでも減らせないか試してみました。

どうやって遅延を減らすか

まあそんなに大幅に遅延を減らす方法などはそうそう無いと思いますが、多少でも改善できそうなのが次の点・・・。

まずSBUS信号はRCチャンネル18ch分を25バイトのデーターとして送ってきます。そして25バイトの転送に約3.5mSを要します(計算上3mSだと思っていたのに実測すると3.5mSなのでした。とりあえず3.5mSで話を進めます)。
その後数msの無信号期間を挟んでまた3.5mSのデータを送出するという事を繰り返します(無信号期間の長さは送受信機によって異なりますが、いくつか見た限り4mS~10mS程でした)。

このデータをPIC18F14K50マイコンで受取ります。この時、これまでは25バイトを全部受け取ってからRCチャンネルデータに変換し、USBに送り出していました。そしてUSB側ではPCが周期的にポーリング(問合せ)したタイミングでデーターを転送します。SBUS信号とUSBポーリングのタイミングは同期してはいないのでポーリングのタイミングがデータ転送期間の3.5mSの間に来る事もある筈です。この場合今までの処理だとその瞬間にSBUS転送中のデータは、ひとつ後のポーリング周期にUSBに送る事になります。


そして今回の変更ですが、HOI-LINK-HRは8CHまでのサポートなので約1.5mSの時点で必要なデータは受取っている訳です。なので「この時点で処理を開始してもええんちゃう?」というのが今回の考えです。
先頭から1.5mSの間にポーリングが来たら従来と同じですが、それ以降だと最新のデータを転送する事ができるので、従来の3.5mSと比べ1.5mSなのて2mSの期間は一周期前倒しができる事になります。なおUSBのポーリング周期は10mSらしい(この値、資料が見当たらないのですが、どなたかご存じでしょうか?)ので約20%のデータが今までより一回分(10mS)早く転送できるはず・・・なのです。

例によってこの変更がどの程度体感できるか不明ですし、私にはまずわからないと思いますが、少なくとも今までよりは早くなっているはず・・・。

あとUSBの処理をプログラムで周期的に呼び出す方式から割り込み方式に変更しました。これはμS単位では早くなっているかもしれませんが殆ど気分の問題だと思います。

その他の変更

一時期SBUSの区切りを検出する方法が色々と迷走していました。8bit版HOI-LINKの時は無信号期間が数mSあったら区切りと判断していましたが、11bit化したとき受信器によって不安定なことが分かり、参考に見たSBUSデコードプログラムでは最終バイトが’00’である事を手掛かりに判断していたのでそれに従っていました。
しかしBetaflightの処理をみたら無信号期間検出方式だったので安心して元に戻しています(不安定だったのはSBUSを受けるUSARTのオーバーフロー処理をしていなかったためで解決済)。
この修正は NONSAYAさん販売バージョンは適用済です。

またPIC18F14K50のRC3~RC7ポート(5~9pin)は今まで空きピンでしたがデバッグ情報を出力する様に変更しており、LEDをつないでおくとオーバーフローやパリティエラー発生時に点灯する様にしています。まあ特に何も接続していなければ影響はありません。

でVelociDroneで試したら・・・

やっぱり体感できません。でも理屈の上では今までよりも遅延が減っているはず(・・・ホンマか?)
このあたり、何か遅延量を測定する方法が必要と考えているのですが、いい案はありますか?

ファームウェア

例によってファーム(ソース・バイナリ)を載せておきます。
なお過去に何度か書いていますがUSBのベンダーID、デバイスIDは適当な値を書いているので使用される場合は自己責任でお願いします。0xffff/0x0012というありそうにない値なので重複する可能性は低いと思いますがもし重複した場合はPCがその機器を認識できない可能性があります。この場合以前このブログに書いた方法でPCに過去の接続を忘れさせる事ができると思いますが保証はできません(まずそんな事態にはならないと思いますが)。
なおNONSAYAさん販売のドングルはマイクロチップテクノロジー社からサブライセンスを受けているのでちゃんとしたIDが書かれています。

またソースはOpenStick Liteから流用した関係で色々と無駄なコードを含んでいるので、読まれる方は温かい心で見てください。

HOI-LinkHR20200822.zip

追記:20200820版は一部ミスっていて効果が出ていなかったので20200822版として再アップロードしました。

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

ARマーカーでドローン制御

ドローンを自動制御してみたくなりました。
いきさつを言うと、とある大学でドローン競技があり、その中に人が操作せず空中に5秒間ホバーリングさせるという種目があるのを知りました。私が競技に出場する訳ではないのですがこれをやってみたくなりました。

まず空中に静止させるには考えられる方法が色々あります。GPSで座標を取得してフィードバックするというのが一番ありそうですが、世の中に既にあるし屋外で実験するのも中々大変です。できればコアレスモーターの軽いやつを使って室内で試したいのです。そこでARToolkitなるものを使ってみようと思います。

前に作った「どどーん」を使いたい。

ARToolkitはARマーカーという図形を印刷しておき、これをカメラで映すと画像に3Dの物体が合成されて現れるアレです。詳細はこちらを参照ください。
ARToolkit本家→ http://www.hitl.washington.edu/artoolkit/
工学ナビさんの説明→ http://kougaku-navi.net/ARToolKit/

そしてマーカーはこんな感じの図形です。

ARToolkitについてきたサンプルマーカーをそのまま使用

ARToolkit自体はCのライブラリなのでVisualC++から呼び出します。
ARToolkitに画像を渡しマーカーを認識しすると、マーカー座標からカメラ座標への変換行列が得られます。 ARtoolkitの一般的な使い方ではこれを元に図形を描画するのですが、この行列にはマーカーの位置が3次元的にどっちにあるか、またどの方向に傾いているかという情報が含まれるので、今回はこれを元にドローンを制御し、常に同じ位置にマーカーが見える様にしてやればホバーリングできるはず・・・という目論みです。

最初はこんな感じでやろうと思っていました。

ARマーカーは壁等に貼っておきます。

そしてコントローラーはこれ。Arduionoでサーボを制御して送信機のスティックを動かすという無理やりな構造。

やはりこのコントローラーは無理がありました。最初は手動でホバーリングさせてから自動に切り替えたいのですが、この切替がうまくできません。また縦軸を動かすと横軸が微妙に動くという問題もあります。 制御パラメーターの微調整が必要になる筈ですが、不安定なコントローラーでは訳が分からなくなりそうなので、まずはPCが考える値を確実にドローン側のフライトコントローラーに伝えるため、以前作ったTWE-Liteを使った送受信機を使う事にします。

またドローンに搭載したVTXから送られてくる画像では画質が今イチな上に振動の影響なのかARマーカーの認識が不安定でした。そこでARマーカーをドローンにぶら下げ、三脚に固定したカメラで検出する方法に変更しました。これでもマーカーが揺れますがカメラが固定なのでこっちの方がマシなのです。

カメラは固定に変更。ドローン側にARマーカーをぶら下げます。
こんな感じで糸でぶら下げました。

固定カメラで見たマーカーの位置を元に制御量を決め、FT232RL→TWE-Liteを経由してドローンのフライトコントローラーに伝えます。
また最初に手動で浮かせてから自動に切り替えるのでRC送信機→受信機→HOI-Link→PCの経路で送信機の操作量をそのままドローンにスルーすることもできます。HOI-Linkはこれまた先日作成したS-BUS→HIDコンバーターで、ラジコン受信機が出すS-BUS信号をPCからジョイスティックに見える信号に変換してPCに入力します。
なお手動と自動は送信機のスイッチで切り替える様にしました。

こんな感じで何枚もペラを折ってしまいながら調整を繰り返しました。
スロットルの制御が一番難しいです。まあ自分が操縦しても高度を維持するのが結構難しいので自動制御でも同じなのでしょう。特にロール、ピッチ、ヨーの制御だったらニュートラル位置がだいたい決まっているのでそこを中心に上下してやればよいのですがスロットルだけはこの値にすれば上下しない位置というのが決まっていないしバッテリーの残量によっても変わってくるので飛びながら調整していく必要があります。

そんな感じで何とかホバーリングが10秒以上は 持続するようになったのが次の動画です。まだ上下動が大きいのでもう少しパラメーターを調節したいところ。またバッテリーが消耗してくると何故かYaw軸が右に回ってきて制御で打ち消せなくなってきます

追記・・・

その後パラメータをイジってかなり安定になりました。
またYaw軸が回ってしまうのは機体の特性っぽいですが、これを制御で抑えられない原因が判りました。ドローンが右に回った時、回転行列から取ってくる角度が本来ならマイナスの値になる筈なのにプラスの値になる場合があります。この時自分の目で見てもマーカーは左に回っている様に見えるのです。この原因はARマーカーを印刷した紙が風で曲がっている為だと思います。ARToolkitはマーカーの四隅の頂点位置から角度を算出しますが、マーカーの角が曲がると正しい角度を割り出せないんですね。そこでマーカーの曲がり易そうな箇所を裏からスチレンペーパーで補強したところ、イイ感じになっています。
これでバッテリーが無くなるまでホバーリングを続ける様になりました。
安定化後の動画 ↓

ArduinoでPICマイコンに書込む~AE-PIC18F14K50編~

先日HOI-Linkを製作した時、秋月電子のPIC18F14K50基板「AE-PIC18F14K50」Arduiono UNOを使ってブートローダーを書き込みました。その際以前書いた「ArduinoでPICマイコンに書込む~OpenStickLite(PIC18F14K50)編~」とは若干変更する必要がありました。
またブートローダーだけでなくHOI-Linkのファーム全体を書いてみました。
なおArduinoに入れる書込み用スケッチにミスっていた箇所があったので修正版を掲載しています。

AE-PIC18F14K50基板は秋月電子で¥800 (現時点) で売られています。DIPパッケージ単体では¥220ですが発振子やUSBコネクタも買う事を考えると基板もそんなに割高ではありません。
以前DIP版のPIC18F14K50にArduinoからブートローダーを書き込んだのと同様にこの基板にも書込んでみました。

前回DIPパッケージ版と今回のAE-PIC18F14K50とで異なるところ

前回の回路図はこれ。この時マイコンのVDDにはArduinoから3.3Vを供給し、VUSB端子もVDDに直結していました。

PIC14K50WriteByUNOsch
ArduinoUNOでPIC18F14K50に書き込んでみた回路図。

一方AE_PIC18F14K50基板はVUSB端子が外部に出ていません。VUSBはチップ内にレギュレータを持っていて3.3Vが出力されるのでVDDに少し高い電圧(まあ5Vですよね)を入れてやればVUSBには外から印加する必要はありません。PICkit3でもそうなっていますしね。

という事で次の様な回路で上手くいきました。
上と違うのは電源を5Vに変えたのとVUSBには接続していない事。
なおVUSB端子はGNDとの間にコンデンサを接続する必要がありますがAE-PIC18F14K50は基板内に0.22μFを内蔵しています。

AE-PIC18F14K50基板に書き込む配線

ブートローダーだけでなくファームウェア本体も書いてみる。

といつもはブートローダーだけを書き込み、そのブートローダーから本体のファームウェアを書き込んでいました。今回ちょっと試しにブートローダー+HOI-Linkのファーム全体を書き込んでみます。

まずその前に書き込みデータを作ります。PICkit3を接続してファーム書込み済のマイコンからプログラムを読み出し、HEXファイルに書きだしました。このファイルにはフラッシュに書かれたプログラムとコンフィグデータ以外にEEPROMの内容も含んでいます。しかしArduino上の書込みスケッチをEEPROMには対応させていないのでテキストエディタでEEPROMに関する行を消しておきます。

そして出来たのがこのファイル→HOI-LinkAndBootloader.zip
解凍すると次のHEXファイルが出てきます。
HOI-LinkAndBootloader.hex
これをメモ帳で開いてTeratermにコピペする事でAE-PIC18F14K50に書き込みます。このあたりの手順は前回の記事に書いています。

そしてファーム全体を書き込むと1分程度で何事もなく終わりました。
因みにブートローダーだけだと約10秒です。Teratermの設定で速度を下げているので専用PICライタに比べると時間が掛かりますが、これは 書き込みデータ全てを Arduinoのメモリーに保存できないのでシリアル通信でPCから順次送りながら書き込んでいる為です。この時PCとArduinoの間でフロー制御できればよいのですが、Arduinoの素の状態ではこれが出来ないので送り込み速度の方を落としているのです。

続いてベリファイをしてみると・・・なんだかエラーが出ます。調べてみるとArduino上の書込みスケッチのベリファイルーチンでチェックサムの計算をミスっていたので、これを修正するとベリファイもエラー無く終了しました。
なお書込みルーチンでもチェックサムを計算していますがこちらは正常です。
書き込みとベリファイは殆ど同じ処理なので上手くサブルーチンで共有すればいいのに面倒になってコピペで作成した為、デバッグの時にベリファイ側の修正を忘れていた様です。

修正版のArduino UNO用書込みスケッチ→PICWrite18F14K50_190621.zip

という事で・・・

秋月電子のAE-PIC18F14K50基板に専用PICライタを使わずファームを書き込めるようになりました(Arduinoは必要ですけど)。 直接ファームを書いても良し、ブートローダーを書いてUSB経由でファームを送り込むのも良しでお手軽にUSB工作が楽しめます。

HOI-Link:S-BUS→PC接続 完成

前回の続きです。前回は秋月電子のPIC18F14K50搭載基板をブレッドボードに挿して実験していました。今回は完成版として基板に収めるのでDIPパッケージで製作します。

まずKi-cadで回路図を書いて・・・

基板のパターンを作って・・・

片面基板なので表パターン(赤の配線)は実装時に導線で接続します。

CNCで削って基板を作ります。

FRISKケース(何年か前から大きくなった120%Booster版)に入れてみました。

寸法を合わせて作ったので当然ですがピッタリです。

ところでFRISKケースの場合ソケットを使ってマイコンを実装すると高すぎて蓋が閉まらなくなります。なので基板に直付けする前にブートローダーを書き込んでおきます(後からでも書けるけどブレッドボードに載せられる実装前の方がやりやすいので)。前に書いた9V電池書きこみ方式で・・・

006Pの9V電池書き込み方式

そして部品取り付け。
私のコントローラーはフタバのFASST方式ですが息子はFHSS方式なので受信機を取り替えられる様にします。最初はXHコネクタの3ピンを使うつもりでしたがL字型のポストが部品箱にありません。L字型でないとコネクタを刺す方向が縦になっておさまりが悪いのです。
代りにL字のピンヘッダがあったのでこれを基板にとりつけ、ここにRCサーボ等で使う3pinコネクタ(QIとかデュポンコネクタとか呼ぶやつ)で接続します。
但し逆刺しができてしまうのは要注意。

完成の図。

そして当初の目的であったドローンシミュレータ実行中。

参考のためマイコンに書いたファームウェアを載せておきます(例によってソースは試行錯誤の後が残ったままで汚いです)。コンパイルはMPLAB-IDEのバージョン8で行っていますが今となってはかなり古い環境だと思います。最新の環境でビルドできるかどうかは確かめていません。
また本来USB機器には固有のVID,PIDを書き込んでおく必要がありますがこのプログラムには適当な値を書いてあるのでそのまま使われる場合は自己責任でお願いします( 確率は低いですがもしVID,PIDがダブった機器を接続した場合に上手くつながらなくなる可能性あり)。
なおOpenStickLiteで使ったのと同じブートローダーから書き込む仕様でビルドしています。

HOI-Link:S-BUS→PC接続

PC上でドローンシミューレータを動かすとき、今までこんなコントローラーを使っていました。

10年くらい前、ムサシノ模型のモスキートモス号を作った時に練習用に買ったコントローラー

私レベルだとこれで問題ありません。しかし息子によると実物の送信機とは感覚が違うのでレースの練習はやりにくいとの事。
そこでトレーナーコネクタからPCに接続するインターフェースの購入も検討したのですが、その前に手元にあるものでなんとかできないか考えました。

まずトレーナーコネクタというのは送信機の裏についているこういう四角いコネクタ。ここからPWM信号が出ているらしいです。

右上の四角いコネクタがトレーナーポートです。

まずこのコネクタをどこで入手できるかというところから検討しなければなりません。またここから信号を取出せたとしてパルス幅をチャンネル数分カウントし、HIDデバイスとしてUSBに伝える処理も必要で何となく面倒です。

そこでRC受信機が出すS-BUS信号をマイコンで取り込んでUSBに伝えるのなら、OpenStickのファームウェアを少し改造して実現できそうです。しかもシリアル通信なのでパルス幅を数えるよりも精度が良い筈。但し受信機が一つ余分に必要なのと電波が出っぱなしになるのがちょっと気が引けますが、たぶんトレーナーコネクタから取り出す方式でも電波は出ているんではないですかね?(想像ですが)

こんな構造にしようと思います。

受信機はSBUSが出せれば何でもよいので、まずはこれで試してみます。

REDCON FT4X
ケースは外していました。

マイコンは秋月電子で買って放置していたPIC18C14K50搭載ボードです。このマイコンはOpenStickLiteでも採用しているので馴染みがあります。

そしてRAM領域の不足に悩まされましたが何とか動作し始めました。S-BUSは18チャンネル分のデータが含まれていますが私のT6EXで出せる6CHまでしか確認していません。あとで息子のT10Jで10chを試してみようと思います。


T6EXで実験中。ちょっと古いFASST方式ですが現役です。

実物のコントローラーだしケーブルをつなぐ必要もなく操作性は良いです。
何か他の事にも使えそうな気がします・・・今すぐ思いつきませんが・・ラジコン送信機でPCを操作する何か・・・
またPCの画面の前にカメラを置いてVTXで画像を飛ばし、ゴーグルで見ながらシミュレーターをやったらもっとリアルになるかも(かなりオタクだなぁ)。

現状はブレッドボードですが、この後ちゃんとした基板に載せ、ケースにも入れて完成させたいと思います。FRISKのケースあたりが良いかな?