どどーんはじめました。~その8~ 6chプロポの憂鬱

私が使用している送信機はフタバT6EXで、2.4GHzではありますがFASST方式のちょっと古い物です。

FASSTだとマルチコプター向きの小型で安い受信機があまりなく、AliexpressやBanggoodで探すととこのあたりぐらいです。

ケースから出して熱収縮をかぶせています

そして6chというチャンネル数ですが、飛行機とかを飛ばしているときは不足を感じませんがマルチコプターでレースをやると色々と不足してきます。

まず6chの内、1~4chはスティックに割り当てるので残りは2chとなります。

しかしドローンレースで欲しい機能を列挙するとこんな感じ・・・

  1. ARMING切替(モーター回して飛ばせる状態か又は待機状態かの切替)
  2. 機体発見ブザー
  3. 飛行モードの切替(レースの時はACROモードだけど 初心者なので安定重視のANGLEモードも使える状態にしておきたい 。)
  4. 機体反転モード(墜落してひっくり返った時に起こすためのモード)
  5. 電波遮断後何秒か以内にモーターが停止する事。

1.のARMING切替は必須でこれしないと飛べません。
2の機体発見ブザーも私には必須です(今年の夏、山に飛び込んだ機体を探し回りブザーの音で発見する事が出来ました)。
3.のモード切替は上手になれば常にACROモードだけも良いのかもしれませんが当面はANGLEモードも使える様にしときたいと思います。
4.の機体反転モード(カメモードとも言うそうです)はレース本番以外は無くても何とかなるかな?本番までに腕を磨きANGLEは無くしてカメモードにしようと思います。

最後の5はチャンネル数と直接関係ないのですが、これが義務付けられているレースもあったりするし安全の為なので設定しておきたいところです。ところが私が使っている受信機は電波が途切れた事をFCに伝えてくれない様です。
こちらのSBUSプロトコルの説明によると「FAILSAFEが入ると24バイト目の下から4bit目が立つ」となっていますが波形を見る限りこの受信機では変化がありません。因みに息子が使っているFHSSの受信機では電波が途切れるとSBUS出力自体が止まってしまうので、これが正しいかどうかは分かりませんがFCには伝わりそうです。
ただし私の受信機にもFailSafe機能というのがあり、 この機能をONにしておくと電波が途絶えた際あらかじめ送信機側で設定した スロットル値になるという動作をします。という事はこの機能でARMINGチャンネルをOFFにしたら良いかと思いましたが、私の送信機の制約なのかFailSafeにはスロットルチャンネルしか設定できません。またスティックを最小にしてもモーターが止まる所までスロットルを下げる事ができなかったので、苦し紛れですが次の方法で設定しました。

  • FailSafe機能をONにする。
  • 送信機側でFailSafe時のスロットル値を設定する。この時デジタルトリムを最小値にした状態でスロットルスティックも最小にして記録する(その後トリムは元に戻す)
  • フライトコントローラーの設定(BataFlightConfigurator使用)の基本画面で「 MOTOR_STOP アーム後にモーターを回転させない 」をONにする。

FailSafe設定の際トリムも含めて最小の値にするところがミソです。トリムが通常値だとスティックを最小にしてもモーターが完全に停止しませんでした。最後のMOTOR_STOPをONにするのは安全上良くないですが他に方法が見当たりません。

・・・で、話が横道にそれましたが6チャンネルプロポの空き2チャンネルをどう割り当てるかという話です。
まずARMINGは当面スティックワークでやる事にします(ARMINGはどのチャンネルにも割り当てなければスティックで操作できます。このときスロットル=最小、ラダー=最右にする事でARMING、ラダー=最左にするとDISARMとなります)。
あとは機体発見ブザーに1チャンネル、モード切替に1チャンネルを割り当てる事にします。機体反転モードの割り当てが無いですが、レース本番ではANGLEモードは不要なのでACROモードに固定する事で切替をなくし、そこで空いたチャンネルを機体反転に割り当てようと思います。

・・・と、この状態で暫く練習し・・・

そろそろカメモードを試そうとして機体反転モードにしたらブザーを鳴らせる事を知りました。そうすると機体発見ブザー代りに使えそうな気がします。すると今までブザーに割り当てていたチャンネルが空くのでこれにARMINGを割り当てる事が出来そうです。試してみたところこれで何とかなりそうなので11月の初レースはこれで行ってみます。

ハンズマン ガラクタ市2019秋

恒例のハンズマンガラクタ市(秋)、今年は少し早くて10月18日(木)から開催されました。例年だともう1週間くらい後の木曜に始まり翌週月曜が最終日というパターンですが、今年は即位の礼で祝日となる10月22(火)までの6日間の開催です。という事で今回も何度か足を運んできました。

初日、7:02分(ちょっと出遅れ)。

これ一瞬3Dプリンタ用フィラメントかと思いましたが電線です。安いのですがここまで大量にしかも一色だけ要るかというのを考えて購入しませんでした。

買っとけば良かったかも。

段ボール2箱だけでしたが今回も激安ネジ袋がありました。

ウォッシュレット。こういう大物も売られていますが今特に必要ないのでパス。

で、初日の朝に買ったもの。

めぼしいものは・・・・
アルミの針金が10巻き入って100円。

ワイヤレスマウスが195円

激安ネジ袋

なぜか銘柄の違うBD-Rが20円×2枚

どういう訳か衝動的に欲しくなった巣箱

この巣箱は早速組み立てて・・・

庭の木に括り付けました。

ここから先は初日の夜および2日目以降に購入した物、ドリル13本セット。
「西ドイツ製」っていったい何年眠っていたのでしょう?

ACインバーターが360円ですが購入後に24V品と気づきました。
しまった、家にはトラックはありません。これどうしよう?

大量買いしている人を見かけましたが24Vと承知の上である事を祈ります。
トラックがある人は「買い」ですね。

USB電源と事務用クリップ

USB電源って幾つあっても無駄になりませんよね。

そして本日最終日。せっかくの祝日なので朝から行ってみました。
初日に比べてガラクタ市売り場はだいぶ縮小されていましたが今まで見なかった商品が出ています。今回最大の買い物がファイバースコープ5900円(値段シール125000円の上に5900円と貼られていましたが帰ってくる途中で剥がれました)。
あとAM/FMラジオは350円です。

という事で以上が2019年秋のガラクタ市でした。
次は2020年春を楽しみにしています。

どどーんはじめました。~その7~いろいろ修理

前回書いた通り11月に鹿児島県出水市で開催されるレースに出る為、日々練習をしております。
しかし実機を飛ばすと(または飛ばさなくても)色々な箇所を壊し、そして修理を繰り返しており、その記録です。

フライトコントローラー その1

フライトコントローラーOMNIBUSF4 V3を修理した話を先日書きました。
このFCは息子が逆電圧を印加してレギュレータICが壊れたので交換した物で、その他は一見問題なさそうなので暫くは木のフレームに積んで飛ばしていました。ところがある時から飛行中に訳もなく墜落したり、電源を入れても何も操作が出来なかったり、その内BetaFlightConfiguratorとも接続できなくなってしまいました。結局はファームを書き直したら復活したのですが、逆電圧のせいでフラッシュメモリが消えた(又は書いていないbitが書き込み状態になった?)のでしょうかね?
そもそも 逆電圧で壊れない方が不思議な気もしますが。
とりあえず様子見中です。

フライトコントローラーその2

同じ様に修理したフライトコントローラー(以下FC)がもう一つあります。
「Mini F3 Flytower」という名称でAliexpressから購入した物。購入時はESCとセットでしたがESCは燃えてしまって交換しています。
ところが元々のESCはBEC回路(5Vレギュレータ)を内蔵していたのに、交換後のESCはBECを搭載しておらず、FCの5V入力端子にバッテリー電圧(11.1Vや14.8V)が直接加わっていました。これで息子が飛ばしていたのですが、今回私がレースに出る為に借りたら上記の接続が発覚しました。とりあえず飛べはするのですがいつ壊れても不思議はありません。また5V端子に(高電圧の)電源が入っていますが本来バッテリ電圧を与えるはずの端子はオープンのままなのでOSD表示にバッテリー電圧が出ないという問題もあります。もちろん電圧低下アラームも出ないので非常に不安です。
そこで正しい接続(VBAT端子にバッテリーを接続)してみると・・・案の定レギュレータが壊れていてFC内の5V電源が出ていませんでした。
レギュレータの型番をみると先日修理したOMNIBUSF4V3と同じ型番のICを使用しています(FCでは標準的なICなんですかね?)。先日買ったICがまだ残っているので交換すると、ちゃんと5Vが出る様になりました。・・・という事でこのFCでレースに出場予定です(大丈夫か?)。

真ん中付近に写っている1F8のマーキングがあるのが交換したレギュレータIC。

木のフレーム

予備機として使用予定の木のフレームは相変わらずポキポキと折れていきます。しかし木のフレームの良いところはエポキシで修理できる点です。また原価が安いので沢山レーザーカットしておきどんどん交換していけます。 強度アップの工夫も色々としており今のところ4代目となりました。
が、やっぱり木製フレームでレースするのは無謀なのかも。

色々強度アップの工夫をした4代目フレーム。
縦に補強を入れてT字型の断面になっています。その分重くなるのを防ぐためアームを少し細くたりFCの下を肉抜きしたり・・・。

カーボンのフレーム

こちらは息子が折ったカーボンのフレーム。カーボンの板が折れると重ねた層が分離した様になるんですね。繊維が完全に切れている訳でもなさそうなので(いや多少は切れているんでしょうけど)、ダメ元で修理してみました。エポキシ接着剤をドライヤーで温めて柔らかくしておき、層の隙間に行き渡る様にした後、万力で挟んで固定したところ結構いい感じに固まっています。耐久性は分かりませんが。

VTX

練習していて息子の機体と空中衝突し、VTXの押しボタンスイッチとLEDが吹き飛んでいました。とりあえず電波は出ているので周波数や出力を変更しないならこのまま使えるのですが・・・これもその内なんとかしたいと思います。
しかしレースに間に合わないとマズイのでVTXは新たに発注しました。

FPVゴーグルのスポンジ

以前書いたEachineの安いゴーグルを使っていますが、顔に当たる部分のフェルトが剥がれてきました。スポンジとフェルトの2重構造になっているところが剥がれるのです。そこで「ボンドGPクリアー」で接着してもまたすぐ剥がれるので今度は「ボンドウルトラ多用途」で試したところ上手くついています。

他にも根本で電線が切れたモーターとかパワーMOSFETから煙を吐いたESCとか、なんとかしたいパーツが色々あるので、いずれ修理にトライしたいと思います。

どどーんはじめました。~その6~

昨年11月、鹿児島県出水市で開催されたU199ドローンレースに息子が参加した話を書きました。 この大会が今年も開催されるそうです。 そこで今回、ついに私もエントリーしてしまいました。
因みにU199とは航空法的に「無人航空機」とはみなされない200g未満の機体で速さを競います。200g未満だと「模型飛行機」という扱いだそうです。

私が使用する機体は昨年息子が飛ばした物をベースに宮崎ドローンクラブの方から頂いた部品を使って色々と修理したもの・・・

息子のお下がり。


予備機も欲しいなという事で先日修理したFCその他を載せて製作する事にしました。このFCは本来5インチ機等で使う物なのでサイズが大きく、普通のU199フレームには収まらないので合板をレーザーカットして製作しました。エポキシ接着剤をドライヤで温めて木に浸み込ませています。

2.5mmの合板2枚をエポキシで貼り合わせ。

レースまでに何とか落ちずに飛べる様、日々シミュレータ(VelociDrone)および時々実機で特訓中です。

実機で練習すると壊しては修理の繰り返しです。
合板のフレームはやっぱり折れやすいですが エポキシで修理できるし予備も簡単に作れます。

ポッキリ。
折れたところをエポキシで固めるとその部分は丈夫になるのですが次は別の場所が折れます。

さてどうなる事やら。。。

フライトコントローラ 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間が短絡しそうな気がします。

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はマーカーの四隅の頂点位置から角度を算出しますが、マーカーの角が曲がると正しい角度を割り出せないんですね。そこでマーカーの曲がり易そうな箇所を裏からスチレンペーパーで補強したところ、イイ感じになっています。
これでバッテリーが無くなるまでホバーリングを続ける様になりました。
安定化後の動画 ↓

PIC18F14K50+HIDブートローダ~その2~

前回ArduinoUNOを使った書き込み機で、PIC18F14K50のコンフィグビット0x30002番地に0x01を書いたのに読出したら0x21になってしまう件を書きました。
違いはbit5が0か1かで、このbitはデバイス上で何にも割り当てられず、データーシートによると割り当てが無いbitは0として読み出される筈なのに1が出てきているという謎でした。

因みにHID版ブートローダーをビルドするとこの番地は0x01ですがMCHPUSB版ブートローダーでは0x21になっています。この違いがなぜあるのか、特にMCHPUSB版をビルドすると割り当てのないbitがなぜ立つのかは気になりますが、これについてはその内調べたいと思います。で、その前に今回はArduinoに載せたスケッチがバグっているのか、またはPICKit3が何か細工をしているのかを確かめたくて波形を見てみました。

といってもわが家のオシロスコープは古くてこの出力をピンポイントで見るのは困難です。そこであるところからAnalogDiscovery2を借りてきました。

AnalogDiscovery2

そしてまずArduinoUNOで0x30002番地を読み出す瞬間の波形がこれ。
上段の波形がクロックでこの下りエッジで下段のデータを読み取ります。データはLSB側から出てくるので左右反転すると00100001=0x21と読めます。やっぱりデバイスから0x21が出ているんですね。

Arduinoで読み取る瞬間(0x21と出ている)

次にPICKit3で読み出す瞬間も見てみます。こちらはクロックがだいぶ早いですがやはり同じ様に0x21が出ています。

PICKit3で読み取る瞬間(こちらも0x21と出ている)

・・・という事でArduinoに書いたスケッチでもPICKit3でも波形的には’0x21’が出ています。なのにPICKit3の画面には’0x01’と表示されているのは恐らく使用していないbitを無条件に0として表示しているのだと思います。

Arduino用スケッチはどういう対策するのが正しいのでしょう?
使っていないbitなので書き込んだのと違う値が読めるのは当然と考えれば「ベリファイからこのbitは除外」が正解なのかな。でも単に読み出して表示する時には「読んだ通りに表示」しないと紛らわしい気がします。
表示する値とベリファイする値が異なるのは気持ち悪いけど「ベリファイ時は未使用bitを除外し、表示の際は読んだ通りに表示」かな。

というか、そもそも未使用bitなのであまり深く考える必要もないか・・・。

緑のカーテン

梅雨も明けて九州は夏本番です。

少しでも工作室の気温を下げるため、今年は窓の前にヘチマを植えてみました。

レーザーカッターの前が窓でその向こうにヘチマが見えるのです。

実は昨年も植えたのですが失敗しました。プランター植えがダメだったのか、または軒下に置いたので水不足だったのか・・・。そこで今年は地植えにしたところすくすく育って実もたくさんできています。

その内ヘチマタワシを作ってみたいと思います。

PIC18F14K50+HIDブートローダ

PIC18F14K50にArduino+9V電池方式でHIDブートローダを書込んでみたらベリファイでエラーが出ました。
コンフィグビット0x30002番地に0x01を書いたのに読出したら0x21になっています。

300000+    0  1  2  3  4  5  6  7  9  9  A  B  C  D
書込値 :00 32 01 1e -- 00 01 -- 03 c0 03 e0 03 40
Arduino読:00 32 21 1e 00 00 01 00 03 c0 03 e0 03 40
PICkit3読:00 32 01 1e 00 00 01 00 03 c0 03 e0 03 40

PICKit3で読むと0x01ですがArduinoだと0x21になるのです。
違いはbit5が0か1かですが、このbitはデバイス上で何にも割り当てられていません。PIC18F14K50のデーターシートによると割り当てが無い番地は0として読める事になっているのでPICkit3の結果が正しくArduinoの結果が間違いです。

しかしArduinoのスケッチを見ていますが特に問題なさそうに見えます。またこの番地のこのbit以外は問題が発生していないのも納得がいきません。因みにデバイスを交換しても変化なしでした。

書込み自体はできており問題なく動作はするのですが・・・謎です。

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工作が楽しめます。