ブログの「←古い投稿」ボタンのリンク切れ修正

このブログの下の方に「←古い投稿」というボタンがあります。

赤で囲んだボタンの事です。

本来このボタンを押すと名前の通り古い投稿のページに移り、どんどん押していくと時期をどんどん遡って古い投稿が表示されていくずなのですが、最近までリンクが切れておりサーバのエラーメッセージを表示していました。

だいぶ前から気づいてはいたのですが修正方法が分からず放置していましたが、今日やっと修正ができました。

多分大丈夫です。

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

PCBGOGOに発注していた基板ができてきました。

こんな箱に入ってきました。

そして基板・・・

10枚550円。以前と比べると信じられない低価格です。
パターンを見ていると何だか無駄な場所が見えてきます。

今回表面実装なのでリフローをする予定です。
ハンダペーストを塗るためのマスクは画用紙をレーザーカットして作れるかとも思ったのですが、リフロー初挑戦なのでメタルマスクを購入しておきました。

メタルマスクは1100円。
基板よりこっちの方が高い・・・。

基板はできましたがまだ部品が揃っていません。
オーブントースターの改造もしなければならないので組立てができるのはしばらく先になりそうです。

HOIドン入手

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

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

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

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

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

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

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

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

2020年台風10号

9月6日から7日にかけて台風10号が熊本に接近しました。
風速70m/Sとか80m/Sとかの予報で、本当に80mも吹いたら一溜りもなさそうです。
とにかく雨戸がある窓は全部閉めて、雨戸がない窓はテープを貼ります。
そして足しになるかはわかりませんが霧吹きで濡らしたガラスに梱包用ラップを 貼っておきました。

テープを貼っていると中心に星マークができます。どうでもいいんですけど、これを綺麗な形に貼ろうとしますがどっちかにずれます。

テレビで「段ボールを隙間なく貼ると良い」と言っていたので面積の広い窓に貼りました。

一昨年MakerFaireに荷物を輸送した段ボールにも頑張ってもらいましょう・・・

モバイルバッテリーに加えドローン用リポバッテリーも2本ほど充電しておきます。
リポはTiny用充電器を通すとスマホの充電にも使えるのです。

これだけやって避難します。
しかし地元の避難所はコロナ対策の為、受け入れ人数を制限すると言っており、もしかすると入れない心配も出てきました。
一時は暴風圏外の広島に宿をとって避難しようと真剣に考えましたが、道中の危険性も考えて止めました。
とにかく地元の避難所に行ってダメなら家で耐える事にします。
・・・そして避難所に行ったらあっさり入れました。

熊本最接近が夜中の3時頃との事ですが、避難所の中ではそんなに強い風には感じられず、むしろ夜が明けてからの方が風が強い気がしました。

結局朝8時に自宅に戻ったところ全く問題ありません。
段ボールも貼った時のまま。

工作室の窓も問題なし。

何事もなくて幸いでした。
予報よりも勢力が落ちたのか、たまたま何かが良い方に働いたのか・・・
でもこれに安心して今後の台風の時に対策を怠る事がない様、肝に銘じておきます。

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版として再アップロードしました。

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

前回の投稿から3か月も過ぎてしまいましたが、細々とフライトコントローラーの自作は続けています。
前回までで回路は決まったので基板の設計に取り掛かったのですが、私のレベルでは35mm角に収めるのが結構大変で、最初はアナログとデジタルのGNDを分けてやろうとか色々と考えていたんですが、とにかく詰め組むのがやっとな状態です。
4層にすれば楽なんでしょうけど基板代が大幅にアップするので何とか2層に収めたいし・・・ところで市販のFCは何層なんだろう?

基板パターンって一旦配線が完了しても細かい所を色々いじっていると、どんどん時間が過ぎてしまいますよね。あまりいつまでもパターンをいじっていてもキリがないし疲れてきたのでここらで一旦発注してみる事にします。何かミスがあるとは思いますが・・・。

今回発注した基板パターン
どこかミスっている気がする。

基板の発注先ですが、過去何回かFusionPCBに発注しているので今回もそのつもりでしたが、500円ちょっとで10枚作れる仕様だとソルダーレジストの最小幅が0.4mmという制約がネックになりました。マイコンやジャイロセンサのパッドとパッドの間にソルダーレジストを塗りたいのですが、そうすると0.4mmよりも少し細くなってしまうんです。0.1mmというオプションもありますが、これを選ぶと3000円を超えて一気に値段が上がります。
そこで他社を調べたところPCBgogoというメーカーだと0.25mmまでなら500円ちょっとで作れるみたいなのでここに発注してみました。

まだ部品が全部揃ってないし、リフロー用にオーブントースターの改造もいるので、基板ができても組立てがいつになるかわわかりませんが、少しづつ進めていきます。

オシロスコープ購入

10万円の給付金をもらったし前から欲しかったオシロスコープを購入しました。
今まで使っていた古いアナログオシロだと見たいものが見れない事が多々あったのです。

当初RIGOL DS1104Zが帯域100MHzの4chでデジタル入力もあって良いかと思ったのですが8万円以上します。これでも昔と比べたら格段に安いのですが。ただデジタル入力といってもオプションのプローブが必要で何万かするんですよね(どこで値段を見たのかわからなくなりましたが)。

他に候補として考えたのがAnalogDiscovery2。オシロスコープとしての機能は今一つですがロジアナ、ファンクションジェネレータ、パターンジェネレータ等、機能がてんこ盛りで3万円台後半です。オシロの機能が今一つといっても家での作業なら大半は事足ります。

そしてネットを見ていたらAmazonのタイムセールでRIGOL DS1202Z-Eが¥39,886-で出ていました。2chですが帯域200MHzです。なおデジタル入力はありません。
願わくば帯域は100MHzでいいから4chある方が便利なのですが、この値段は魅力的です。

DS1104Z買ったとして後日必要な時にデジタルプローブも買うと合計10万円を超えます。だったらDS1202+AnalogDiscovery2という手もあるかと考えました(AnalogDiscovery2はまだすぐに買うわけではありません。「必要になったら」です。いつの事かわかりませんが)。

結局DS1202Z-Eを¥39,886- で注文しました。昨日Amazonを見たら5万6千円に戻っていたので良いタイミングで買ったと思ったのですが、今日見たらまた
¥39,886- になっていて、見間違えたのかな?

そして2~3日後、この様な箱で届きました。

箱を開けるとまた箱が・・・厳重です。

そして中身に到達。イメージしていたよりも小さいです。

早速プローブを基準信号につないでトリマーを調整します。

こんな感じですかね。

と、やっていると玄関のチャイムが・・・。この時発注していたレーザー管が到着しました。結構時間がかかっていたのにこのタイミングで来て部屋がダンボールだらけです。

レーザー管は後日交換するとして、とりあえず何か波形を見てみましょう。先日からイジッているS.BUS信号・・・
ところでこのオシロにはシリアル通信のデコード機能があります。
会社でつかっているTektronixのオシロだとこのあたりの機能がオプションだったりしますがコイツは標準で使えるのが嬉しいのです。

ちゃんと先頭が’0F’で始まっているのがわかります。
こういうのが簡単に見れるのが今どきオシロの良いところ。

マニュアルはRIGOLのサイトからダウンロードしました。
なぜかDS1202という名前では辿り着けずシリーズ名であるDS1000Z-Eを選び、「カタログ&チラシ」→「ユーザー・マニュアル」に切り替える必要があってちょっと解り難いです。
また今のところ英語版しか上がっていません。
でも中身は真面目にしっかり書かれている印象です。

その後もイジっていますがTektronixと操作が似ていてわかり易くイイ感じです。
でも表示を日本語にすると変な訳になり余計に解り難いので英語に戻しました。

このオシロが¥39,886-で買えるのは感動的ですね。ヘタするとTektronixのパッシブプローブ1本よりも安いです(帯域は全然ちがいますけど)。

バシバシ活用していきたいと思います。

2020年6月21日の日食

先週の日食、梅雨時なのに熊本は晴れたので日食グラスを使うとよく見えました。そこでグラス越しにスマホで撮影したけどうまく撮れませんでした。

日食グラスでみたらもっとそれっぽい形でしたが撮影するとこんなのです。

なので次の策、木洩れ日を探して撮影・・・。
明るい部分が三日月形に撮れています。夕方近かったので地面よりも壁に映る影の方が角度的にはっきり分かりました。

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

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

BlackBoxについて

前回書いた通り、基板化する前にBlackBoxを動作させてみます。
BlackBoxとはフライトコントローラー(以下FC)が諸々の情報をログとして記録する機能です。
ログの保存先としてBetaflightがサポートするメディアには、OpenLog基板、SDカード、SPIフラッシュIC 等があります。

OpenLogはSparkFun(SwitchScienceでも取扱いがある様です) のロギングデバイスで、FCには外付けする事になり機体内のスペースを取るため今回はパス。またSDカードは安くて大容量なのが魅力ですがカードコネクタがFC基板の面積を喰い設計が難しくなりそうなので、もうちょっと腕が上がってからにします。
という事で今回はSPIフラッシュを使ってみようと思います。

記録メディア

BetaflightがサポートするSPIフラッシュICはこちらのページに記載されている下記のデバイスで、この中から16MBのW25Q128を購入しました。

  • Micron/ST M25P16 -2 MByte
  • Micron/ST N25Q064 -8 MByte
  • Winbond W25Q64 -8 MByte
  • Macronix MX25L64 -8 MByte
  • Micron/ST N25Q128 -16 MByte
  • Winbond W25Q128 -16 MByte
ちょっと思っていたよりサイズが大きい。

配線

接続は電源とSPI信号をつなぐだけ・・・。

ファームウェア定義ファイル

Betaflightのターゲット定義ファイルtarget.hに以下を追記しました。
SPI3に接続しています。

#define USE_SPI_DEVICE_3 
#define SPI3_SCK_PIN PC10
#define SPI3_MISO_PIN PC11
#define SPI3_MOSI_PIN PC12
#define USE_FLASHFS
#define USE_FLASH_M25P16
#define FLASH_SPI_INSTANCE SPI3
#define FLASH_CS_PIN PA15
#define ENABLE_BLACKBOX_LOGGING_ON_SPIFLASH_BY_DEFAULT

気になったのは’USE_FLASH_M25P16’の行。M25P16は2MBのメモリーですが今回接続するW25Q128は16MBです。このあたりの設定は不要なのでしょうか? 他のFCの設定を見ても特に容量を指定する箇所もなく、単にM25P16を指定しているの様なのでこのままやってみます。

動作確認

ファームをビルドしてFCに書き込み、BetaflightConfigratorから接続してみると・・・

ちゃんと16MBとして認識しています。

適当に動作させたログをPCに取り込み、Blackbox Explorerで結果を見てみました(FCは机に置いたままなのでジャイロや加速度センサーの値は全く動いていませんけど・・)。

動作は大丈夫そうです。

ということで・・・

いよいよ基板設計を開始しました。一般的な一辺35mmの正方形に収める予定ですが、手ハンダも考慮してSMDパーツのパッドを大きめにしたため、面積的に結構厳しいです。くじけたら35mm角は諦めて基板サイズを広げるかもしれません。