背筋トレーニング日記

Kailh ChocV2の完全無線分割キーボードを作ってZMKで動かした話

noreply@blogger.com (Kazuyuki Arimatsu) — Sun, 03 Oct 2021 15:18:00 +0000

TL;DR

Kailh Choc V2スイッチ対応のキーボードを新しく設計しました
3Dプリントのインテグレーテッドトッププレートでスイッチを嵩上げして、対応キーキャップを増やしています
フレキ接続でキーマトリクス基板とマイコン基板を分割して有線版と無線版を作りましたが、組み立てが面倒なのと設計の自由度が下がってしまうのでおすすめしません...
無線版のファームウェアにはQMKではなくZMKを使用しました

はじめに

前回Thumbsplit58を設計した時点で理想のキー配列が固まり、エンドゲームに到達したかに思われました。使い心地はほとんど問題なく、実際毎日使っているわけですが、使用しているスイッチがKailh Chocのためキーキャップのバリエーションが少なく、カッコいいキーキャップが発売されても指を咥えて見ていることしかできませんでした...

そこでCherry MX互換のカッコいいキーキャップを嵌めて見た目もエンドゲームなキーボードを目指すべく、Choc V2スイッチを使って新しいキーボードを作りました！

Thumbsplit58 Wired

Thumbsplit58 BLE

このとき実験的な試みとして、3Dプリントのインテグレーテッドトッププレートでスイッチを嵩上げすることで、キー押下時のキーキャップとトッププレートのクリアランスを確保し、従来Choc V2スイッチに嵌めるとトッププレートに当ってしまっていたキーキャップも使えるようにしています。また、設計を使い回せるように、フレキ接続でキーマトリクス基板とマイコン基板を分割し、AVRを使った有線版マイコンボードと、nRF52を使った無線版マイコンボードを作りました。

ファームウェアの方も少し実験的な試みとして、無線版のマイコンボードではQMKではなくZMKを使い、BLEの完全無線キーボードとして動作させています。ZMKの設定などはあまり解説しているブログがないので、備忘録的な意味も含めてこのあたりのことをブログに残しておこうと思います。

Kailh Choc V2キースイッチの嵩上げ

Kailh Choc V2スイッチはKailh社製のロープロファイルキースイッチ (Chocシリーズ) の十字ステム版で、キーキャップをはめる部分がCherry MXスイッチ互換になっているため、Cherry MXスイッチ向けのキーキャップをはめることができるようになっています。

ところがChoc V2スイッチにはすべてのCherry MXスイッチ向けのキーキャップをはめることができるわけではありません！AJisai74のビルドガイドによると、CherryプロファイルやGRIDプロファイルはスイッチ自体とキーキャップが干渉してしまうようです。DSA、ADA、OEM、SAなどではキーキャップとスイッチは干渉しないのですが、これらのキーキャップを使った場合でもキー押下時にトッププレート取り付け位置よりもキーキャップが下側に来てしまうので、トッププレートを使うとキー押下時にキーキャップがトッププレートにあたってしまいます。

DSAキーキャップがキー押下時にトッププレートと接触しています

なので、Choc V2スイッチ対応の自作キーボードキットは、基本的にトッププレートを使用していません。(c.f. AJisai74、Sparrow62)

ところが、トッププレートを使わない場合はPCBがむき出しになってしまうのでデザインが限られてしまうのと、スルーホール部品がある場合には半田付け部などに汚れやホコリが付着しやすくなってしまいます。PCBが直接打鍵の荷重を受けるので、打鍵感や打鍵音にも難点があるかもしれません。

そこで、Choc V2スイッチでトッププレートを使いつつ、キーキャップとトッププレートが干渉しないようにするため、キースイッチを1mm嵩上げするインテグレーテッドトッププレートを3Dプリンタで作りました。

インテグレートトッププレートの断面

トッププレートは板厚1mmで、スイッチの爪にかかる0.5mmのリブ部分だけ1mm嵩上げされており、キー押下時にキーキャップがトッププレートに干渉しないようになっています。トッププレートはPCBに接触するため、RGBLED以外の電子部品はすべて裏面に表面実装で実装しました。

PA12で刷った試作トッププレート(原理確認はできたのですが、PA12では歪んでしまったので作り直しました… ※後述)での確認の様子です。嵩上げによってキー押下時にトッププレートとキーキャップの間に余白が残っています。

嵩上げによってDSAキーキャップがトッププレートと接触しなくなりました

PA12GBで作り直したトッププレートにスイッチを載せるとこのような感じになります。手持ちのDSAプロファイルのキーキャップでは1mmの嵩上げで接触しなくなりましたが、他のプロファイルの場合は干渉するかもしれません。その場合には、トッププレートを薄くして嵩上げ高さをさらに上げる必要があります。

スイッチをはめた様子

嵩上げ部分は0.5mm厚になっており、打鍵の荷重も受けること考えると一般的なFDMの3Dプリンタでは強度を維持するのが難しいかもしれません。今回は高い形状再現性と機械強度を得るべく、DMM.makeのMJF PA12GBで出力しました(※詳細は後述)。まだ1ヶ月程度しか連続使用していませんが、特に破損する様子はありません。

ロジックボードをフレキ接続 (※おすすめしません)

今回キーボードの設計を始めた当初、既に自分は理想のキー配列に到達したと感じていました。そこで、どうせキー配列が変わらないのなら共通で使い回せるキーマトリクスの基板を作っておけば、有線バージョンも無線バージョンにも使えるし、今後新作を作るときにも使い回せるかもしれない！、という考えのもと、基板を「マイコンやコネクタが載ったロジックボード」と「キーマトリクス配線とスイッチソケット、RGBLEDが載ったシールド」に分割しました。

ロジックボードはおなじみのAVRを使った有線接続のロジックボードと、nRF52モジュールを搭載した無線接続ロジックボード(※詳細は後述)を作りました。基板上にはマイコン周りの回路と、TRRSジャック、USB Type-C ハウジング、リセットスイッチが載っており、分割キーボードの背面部分に取り付けて使う想定です。

有線接続ロジックボード (Atmel ATmega32U4)

無線接続ロジックボード (Minew MS88SF2)

2種類のロジックボードは、キーマトリクスの配線にスイッチソケットとRGBLEDを実装した共通のシールド基板とフレキケーブルで接続します。ROWとCOL併せて13ピンと、RGBLED用のシリアル1ピン、RGBLEDのVCC/GNDはフレキコネクタの定格電流が低いために3ピンずつ割り当てて、合計20ピンのフレキコネクタを使いました。

フレキケーブルでロジックボードとシールドを接続

コネクタには0.5mmピッチのMolex 50348-2000を使っています。ロック付きでフットプリントが小さいため、スイッチを180度回転させなくても行間に配置することができました。

ただし、このコネクタはJLCPCBのパーツリストにはないので、自分でDigiKey等で購入して実装する必要があります。また、Molex純正のフレキがめちゃくちゃ高い (1個400円とかします…) ので、コスパは非常に悪いです…

また、新しいキーボードを作るときには全体的にいろいろ変えたくなるものなので、使い回すことはあまり考えるべきではないのかもしれないです… (次に作ろうと思っているキーボードでは早速互換性を捨てる予定です…)。新しいキーボードを作るときには現状に満足できなくなったときだと思うのですが、その時に互換性を保つことが設計上の制約になってしまって、理想を追求することができずに本末転倒になってしまう、というのが今回共通化を目指してみて得られた知見です。

無線版のマイコンボードの設計

低消費電力で技適が通っている無線キーボード向けのマイコンとなると、現状はほぼBLE Micro Pro (BMP) 一択になってしまっています。Switch ScienceではISP1807を搭載したPro Micro互換のボードも最近発売されましたが、無線キーボードで使う場合には電源LEDを剥がしたり、USB接続時にBATに電流が流れないようにする外付け回路が必要になると思います。

今回はキーボードをなるべく小さくしたかったためにBMPは使わず、技適取得済みのnRF52のモジュールを使用したボードを自分で設計することにしました。ただ、自分はリフロー設備を持っていないため、手ハンダ可能なモジュールを使う必要があります。

nRF52の技適取得済みモジュールはいくつかあるのですが、USB接続可能 (52840 or 52833 or 52820) なもので、かつ手ハンダ可能なものはMinew MS88SF2しかありませんでした。Switch Scienceでもブレイクアウトボードの販売がありますが、モジュール単品の販売はなかったので、AliExpressから購入しました (ちゃんと技適マーク付きのモジュールが届きました)。

ただ、MS88SF2には、VBUSが外に出ていない(モジュール内部でVDDHと接続されている)という大きな問題がひとつあります。これはバッテリー駆動しない場合や、USBからの電源供給のみで動作する場合には問題ないのですが、バッテリー駆動とUSBからの電源供給を切り替える場合には外付け回路が必要になってしまいます…

VBUSとVDDHが切り離されていれば、VDDHは使用せずに電源はVDDから供給しつつUSBの内部モジュールのみをVBUSで駆動することができるのですが、VBUSとVDDHが接続されているために、USB接続時にVDDHに5Vが入って、内部レギュレータの出力がVDDから出てきてしまいます。

回避策はNordicでも同様の質問が上がっている通り、「バッテリー駆動時はVDDに入力、USB接続時にはVDDをバッテリーから切り離してVDDHにVBUSを入れる」という回路を外付けで用意する必要があります。

自分はPch MOSFETを3.3V LDOの後にいれてVBUS接続時にバッテリーを遮断することにしました。VDDHに5Vがかかるとモジュール内部の電源回路がVDDに3.3Vを出力しますが、FETがOFFになっているのでバッテリーに電流は流れません。

USB接続時のバッテリー切り離し回路

無線キーボードを動作させるためには何らかのバッテリーが必要になってくるわけですが、前回のキーボードでは塩化チオニルリチウム電池という一次電池を使用していました。この電池は流せる電流が非常に限定されている(~100mA)代わりに、体積あたりの容量が非常に大きく (単三電池型で0.5mA連続放電で2400mAh)、自己放電も少ないのが特徴になっています。

ただ、前回キーボードを実際に毎日運用してみたところ、実測で半年～1年ぐらいしか持たない事がわかりました (前回のブログで計算した理論値より少し短いです)。十分長いといえば長いのですが、それでも電池交換が面倒に感じたので、今回のキーボードは二次電池を搭載して充電できるようにしたいという思いがありました。

今のキーボードの大きさに入れるとなると、リチウムイオン電池は3.7V 500mA程度が限界になります。それだとZMK Power Profilerの計算ではCentral側が1 ~ 2ヶ月ぐらいしか持たない計算になります(※これはDeep Sleepありの場合でこの値のようです。Deep Sleepは現時点ではデフォルト無効になっているのですが、後述のようにZMK_SLEEPで有効にできます)。

3.7V 500mAh のリポバッテリーを搭載

そこで、リポ充電回路を載せてUSB接続時に充電できるようにしました。といっても回路としてはMCP73831をリファレンス回路通り使っているだけです。LEDは砲弾型の2色LEDを使っていて、ステータス用にマイコンから青色を駆動、MCP73831から充電ステータス用に赤色を駆動としました。USB接続時にはRGBLEDを点灯させる可能性もあるので、充電電流は100mAとしています。

リポ充電回路

自作基板に合わせてZMKの設定をする

自分で設計したnRF52のボードでBluetoothの無線キーボードを作ろうとした場合、QMKを使うのであればsekigon-gonnocさんのqmk_firmwareのフォークのnrf52ブランチを使わせてもらうという選択肢があります(BLE Pro Microの方は"BMPAPI"内部の実装が公開されていないので、自作のボードで動作させることはできません)。

ただ、nrf52ブランチは現在はメンテナンスされていないのと、QMK以外のファームウェアを試してみたかったので、ZMK Firmwareを使用してみました。ZMKはZephyrというRTOSのアプリケーションとして動作するキーボード用のファームウェアで、Permissive License (MIT)なのと、Wireless動作を前提にしているのが特徴になっています。

後発のキーボード用ファームウェアではありますが、精力的に開発が続けられていて、QMKから乗り換える場合でも比較的機能の差異は少なくなってきています(OLED、Mouse Keyやキーマップ書き換えは目下開発中のようです)。

ただ、少し(非常に？)とっつきにくい部分があるのも事実で、ZMKの機能がDevice Tree Bindingとして実装されているために、キーマップ等の設定にDevice Treeの編集が必要になる点です(単純にキーマップを変更するだけならoverlayで良いのですが、自作のボードに対応させようとすると編集するファイルが多くなってけっこう大変です…)。

Device Tree自体はARM Linuxのデバイスドライバの肥大化を防ぐために開発された設定パラメータ格納構造ですが、Zephyrではこのデータ構造をハードウェアごとの設定パラメータを記述するために使用しています。一番の違いはLinuxのDevice Treeはプロパティを格納したツリーでデバイスドライバからは動的に値を参照されるのに対し、ZephyrではDevice Treeをビルド時にマクロ経由でCのソースコードに変換してしまうところでしょうか…。もともとのDevice Treeの思想からは離れてしまうような気がしますが、ZephyrではDevice Treeによる柔軟なハードウェア構成記述を活用して、組み込みデバイスごとの設定を管理しているようです。

ZMKの機能(LayerやMod Tap等々)はDevice Tree Bindingとして実装されていて、基本的にはこれを"zmk,keymap"をcompatible設定したにDevice Treeノード(専用の.keymapファイルに記述します)に書いていくことでキーマップを設定します。ただここで設定したキーマップはビルド時にソースコードに変換されてしまうため、今のところZMKには動的にキーマップを書き換える方法は用意されていません。

また、少しややこしいのが、ZMKではDevice Treeによる設定とは別に、KConfigによる設定というものも存在します。ZephyrではDevice Treeがハードウェアの構成や(その機能を使った場合の)デフォルトの設定値を記述するのに対して、KConfigはアプリケーションが使う機能を取捨選択するのに使うというガイドラインがあるようで、ZMKでもそのガイドラインに習った棲み分けがなされていて、例えばRGBLEDが接続されているピンやSPIの設定はDevice Treeで行った上で、実際にRGBLEDを使用するかどうかはKConfigで設定を行う、といった形です。

今回のキーボードは(基板上は分かれていますが、入れ替えて使用することはできないので)BoardとShieldとして分けずに、マイコン直付けの分割キーボード(=Board)として設定を作成しました。Board内でLeftとRightのDTSを用意するために少し複雑になってしまっていますが、普通に新たなキーボードをZMKで動かすためには、Kconfig.board、Kconfig.defconfig、${board_name}_defconfig、${board_name}.dts、${board_name}.keymap、${board_name}.yaml、のファイルが必要になります (改めて多いですね… ※各ファイルの役割の詳細はZMKのこちらのドキュメントに記載されています)。

また、まだデフォルトで有効にはなっておらずドキュメントにもまだ記載がないのですが、ZMKにはDeep Sleepという機能があり、ZMK_SLEEPのオプションで有効にすることができます。これはその名の通りマイコンをDeep Sleep状態にする機能で、デフォルトでは1440秒(24分)でDeep Sleepします。この状態になると無線機能はすべてオフになり左右間およびホストPCとのBluetooth接続は解除され、消費電力が非常に小さい状態になります。

上記のPRを読む限りではキー押下でスリープから復帰しそうに見えるのですが、自分が試した限りではキーを押してもスリープから復帰してくれませんでした。なので、今のところはリセットスイッチを押してマイコンをリセットすることで対応していて少し不便なのですが、この機能は特にスプリットキーボードでは必ず有効にしておく必要があります。

スプリットキーボードのホスト側はスレーブからのキー入力を受け付けるために定期的にBLEを受信モードで待機する必要があり、キーボードを使用してない間も電力を消費し続けてしまいます。ZMKでは消費電力を予測するZMK Power Profilerというページが用意されていて、ZMKで動くキーボードのバッテリーがどの程度持つのかを手軽に調べることが可能になっています。注意しなければならないのは、この値はDeep Sleepが有効になっている場合のシミュレーション結果になっているので、この値と同等のバッテリー持続時間を得るためにはZMK_SLEEPを有効にしておく必要がある点です。

例えば、今回作成したキーボードは721855サイズの500mAhのバッテリーを搭載していて、PSUはLDO、1日8時間使用するとしてPercentage Asleepを70%とすると、このような結果になりました。

ZMK Power Profiler

左手(Central)側は右手(Peripheral)側から送られるキー入力を受信する必要があるためマイコンの待機時間が多く、バッテリー持続時間が少なくなっていることがわかります。

実際に毎日使用して運用している限りでは、充電せずに使用し続けて1ヶ月経過時点で残量レポートが40%を切るような形だったので、大体プロファイラーのシミュレーション結果通りになっていると思います。

ZephyrのBluetoothスタック使用と技術基準適合証明(技適)について

Zephyrはnrf52が公式にサポートしているNordicのSoftDeviceではなく、独自のBluetoothスタックを使ってBluetoothを飛ばします。これが無線モジュールの製造業者が工事設計認証を受けた時の検査に使用したBluetoothスタックと異なるものだった場合、製造業者が付与した技適マークが無効になるかもしれない、という懸念があるかもしれません。

Bluetoothスタックの実装によって結果が変わる試験項目にあるのか、技適取得時の何のBluetoothスタックを使ったのか、またそれ以外のBluetoothスタックを使用した場合は技適が無効になるのか、少し調べてみたのですが確かな情報を得ることはできませんでした。

未解決の問題について

今回、キーキャップを嵩上げすることによってDSAキーキャップがトッププレートに接触するのを防ぐことはできたのですが、現状の設計ではスタビライザーを使用できないという問題が残っています。今後の計画としては、インテグレーテッドトッププレートに直接スタビライザーのハウジングを造形して、MXスイッチ向けのスタビライザーのステムが刺さるようにしたいなぁ、と考えています。

今回の基板にはRGBLEDとして、WS2812-2020を使用しています。今までWS2812-2020はWS2812互換だと思っていて、実際QMK(のBitBang)では問題なく使用できていたのですが、ZMKではうまく制御することができず、ランダムにピカピカ光る状態になってしまいました…

ZMKではZephyrに実装されているWS2812のSPIドライバを使用しており、デフォルトの設定だとSPIの駆動周波数が4MHz (250ns / bit)、8bit毎に 0x70 (0b0111'0000) と 0x40 (0b0100'0000) でWS2812のHとLの1ビットを表現しています。よくよくデータシートを読んでみるとWS2812とWS2812-2020ではT0Hが220ns ~ 380nsとシビアで、SPI 4MHzではデータシートの条件を満たしたパルスを作ることはできません。そこで、SPIを8MHzにしてHを 0x7E (0b0111'1000)、Lを 0x60 (0b0110'0000) としてデータシートの条件を満たすようにしました。また、ZMKではWS2812では動くからという理由で、データシートでは250us以上必要なリセットディレイが8usに設定されてしまっている、このコミットをcherry-pickしてリセットディレイもデータシートに合わせました。

ただ、これらの変更を加えても状況は改善せず、現状はRGBLEDをオフにしています…

3Dプリントの材質についてのTips

DMM.makeでは3Dプリントに多くの材料を選ぶことができますが、個人的にはMJF PA12GBを非常におすすめします。HP社のMulti Jet Fusionは層ごとにナイロン粉体を選択的に熱で溶かして立体を成形する方式で、複雑な形状の立体を異方性がなく、実用に耐えられる強度で印刷することが可能です。

DMM.makeのPA12GB出力サンプルを手で曲げてみた限りでは、力をかけると1mm厚の部分は弾性変形の範囲を超えて歪みが残ってしまいますが、2mmの部分は全力で力をかけても折ることはできませんでした。PA11、PA12もそこまでPA12GBとは硬さに違いがありませんでしたが、ガラスビーズが添加されていない分少し柔らかく、折れる可能性はより低いと思われます。

PA12GB出力サンプルを手で曲げた図

ただ、MJFでも粉体を焼結するときに応力が発生するようで、造形時には歪みが発生します(異方性がないことと、歪みが発生することは別)。PA11で造形を頼んだ際には非常に歪みが出てしまい、まともに使用できないものができてしまったこともありました。

歪みが発生してしまったトッププレート

このあとに設計を見直して歪みが大きく発生していた右下部分の厚みを均等にしたのと、PA12GBで印刷し直したことで無事に歪みは発生しなくなりました。経験的にはPA11よりもPA12GBのほうが造形時の歪みは少ないように思えます。ただし、DMM.makeでは造形方向を指定できないので運頼みの側面もあります。

PA12GBで印刷し直したトッププレート

染色に関するTips

DMM.makeでは、100mm以上の物体は色むらが出るため、造形時のオプションでブラックは選べません。PA12GBは無地だと吸水性があるのと、見た目もそこまできれいなわけではないので、何らか色をつけたほうがきれいに見えると思います。

初めは塗装の条件を色々試してみてみたのですが、ナイロンは塗装しづらいのでプライマーが必須なのと、造形物に細かい凹凸があるからなのか、マットで塗装しても変な光沢が出てしましました。もちろん下処理をしたり何回も塗り重ねると良いのかもしれませんが、あまり手軽にできる作業ではありません…

そこで、もう少し手軽に色を付けられる工程として、染色を試してみることにしました。ナイロンは塗装はしにくいですが染色はしやすく、SDN染料というものを使うと簡単に染色できます。自分はこのページを参考に、SDNの説明書より濃い目の10倍希釈した溶液をジップロックに入れて、湯煎して70度に温めた後に造形物を投入、10分後に取り出しました。

ベランダでプラスチックを煮る図

SDN染料は非常に匂いが独特でキツいのと、こぼした時に床が黒く染まってしまう可能性があるので、屋外でやるのが良いと思います。もし万が一こぼしてはいけないところで熱い溶液をこぼしてしまった場合は、反応を止めるためにすぐに冷水で流すのが良いと思います(経験談)。

一番左がDMM.makeから届いたままのPA12GB無地、中央が軽く残留粉を落とした後にミッチャクロンマルチ、Mr.サーフェイサー500、アサヒペン水性多用途つや消し黒で塗装したもの、一番右がSDNの黒を10倍希釈したものを70度で湯煎して10分間つけた後に乾燥させたものです。

左からPA12GB無地、プラサフつや消し塗装、SDN10倍10分染色の結果

染色だと比較的お手軽にマット黒にできているのがわかると思います。ただし染色では積層痕は完全には消えないので造形時の線が残ってしまったり、少し匂いが残るので鼻を近づけるとSDNの匂いがします(半年たっても匂いは完全には消えませんでした)。また、同時にすべての部品を染色しないと色が変わってしまうという欠点もあります。

この4つのパーツはSDN染料を1本使用し、同一日に10倍希釈70度10分で順番に煮たものなのですが、明るい照明下で並べると違いが分かる程度には仕上がりの色が異なってしまっています。原因はSDN染料の濃度なのか温度/時間条件の少しの違いなのかはわかりませんが、完全に同一の色にしたいパーツがある場合には同時に煮るのが良いと思います。

同一条件で染色しても仕上がりの色は異なる

ただ、そこまで見た目にこだわらないのであればMJF12GBをマットブラックにする際は染色がお手軽なのでおすすめです。

Minew MS88SF2のBootloaderについて

ZMKのバイナリは直接デバッガを使って焼くこともできるのですが、キーマップを書き換えるたびに一度分解してデバッグ用の端子にアクセスするのは現実的ではありません。そこで、UF2ブートローダーを使用してUSBストレージとしてOSに認識させて、UF2ファームウェアを書き込むようにするのが一般的だと思います。

今回はAdafruitのnRF52ブートローダーのボード設定を追加して、ボードに書き込みました。キーボードをUSBで接続した状態でリセットスイッチを連続して2回押し込むとブートローダーモードになり、認識されたUSBストレージにZMKのUF2ファイルを書き込むことでファームウェアの書き換えが可能になります。

完全無線分割キーボード Thumbsplit58 を作った話

noreply@blogger.com (Kazuyuki Arimatsu) — Sat, 02 Jan 2021 06:22:00 +0000

TL; DR

完全無線分割キーボードを設計しました。今のところエンドゲームです。
日本語キーボードは親指周りにキーが多いので、BackSpace/Enterを無変換/変換等に割り当てることで、ノートPC使用時にもキーマップの互換性をある程度担保できます。

はじめに

2019年の中頃に、完全無線分割キーボード Thumbsplit58 を設計しました。1年ほどキーボードを使って出てきたフィードバックを取り込んで、今年の終わりに一度ケースを作り直しました。スイッチはKailh Choc (ソケット対応)、キーキャップは MBK Low Pro (1u/1.5u) を想定しています。Mitosis、Comet46 がベースになっていて、NordicのGazellプロトコルで左手と右手がキー情報をQMKが動くUSB接続のレシーバに対して送信します。

最近流行りのBluetooth自作キーボードに対する利点としては、とりあえずレシーバをUSB接続したら動く、左右の手が独立にレシーバに送信するので低レイテンシー低消費電力(のはず)、QMKはレシーバのatmega32で動くのでQMK標準の方法で書き込み可能、とかでしょうか…？

今のところこのキーボードを販売する予定はありませんが、備忘録も兼ねて設計思想をここに残しておこうと思います。

どうして作ったのか？

もともと自分は10年以上ThinkPadの日本語キーボードを愛用していて、ノートパソコンはX40からずっとThinkPadですし、USB接続のトラックポイントキーボードも初代から使い続けています。

※世代が変わってもずっと同じ配列 (13インチの日本語キーボードは違いますが…) でキーボードを設計してくれているので安心です。

ただトラックポイントが必須かというとそういうわけではなくて、人差し指が腱鞘炎になりかけてVimキーバインドを覚えてからは打鍵中にトラックポイントを使うことは減り、現在は特になくても不自由ではないという状態です。

ちょうど2年前ぐらいに自作キーボード界隈に入沼し、ErgoDashを作って分割キーボードの素晴らしさに目覚めたあとは、エンドゲームを求めて自分でキーボードを設計する方法を模索していました。椅子の肘掛けに置いて使うために、完全無線分割にするという構想は当初からあったような気がします。

分割キーボードというとErgoDoxの地を受け継いだColumn Staggeredのものが多い印象ですが、実際に使ってみてRow Staggeredのほうがあっている感じがしたのと、ノートパソコンを使う際にはThinkPadの配列で打鍵するので、それに近いものが良いなぁと思っていました。ただ、親指周りにキーを配置して小指の負担を減らすのは非常に効果があったので、親指周りは3キーずつ欲しいという思いがありました。

なので設計の要望をまとめると、

完全無線分割
Row Staggeredで、ThinkPadと同じ配列(各行が0.5u/0.25u/0.5uズレる)
日本語キーボードのキーマップができるキー数(右手小指に十分なキーが必要)
親指にBackSpace、Space、Enterを配置したい

みたいな感じでした。

自分が日本語キーボードにこだわっている理由は親指周りのキーの豊富さにあって、USキーボードのスペースバーの部分(CVBNMの下)に4キー配置されています。そのため、ThinkPadを使用しているときにも無変換にBackSpace、変換にEnter、カタカナ/ひらがなにDeleteを割り当てることで、最低限の互換性を保つことができるようになっています。

※キーマップについての詳細は後述します

具体的には、Thumbsplit58では日本語キーボードのこの範囲を切り出しました。右手小指が担当していたBackSpace、Enterは無変換、変換にマップしているので、その範囲のキーは省いています。

※6とBは右手にも置きたかったのですが、後述のNordic MCUのGPIO数の制約があって配置できませんでした。

基板

基板の設計はKiCadで行いました。設計にあたっては @foostan さんの「自作キーボード設計入門」を参考にしています。また、使用している部品は殆ど Comet46に使われているものと同じで、MCUはNordic nRF51822が載っている Raytac MDBT40 を使用しています。

MDBT40周りは一応データシートに沿って設計したつもりですが、これで無線電波特性がちゃんと期待通り出ているかはわかりません…

実装部品を少なくするために全キー直接GPIOに繋いでスイッチ入力を検知しているのですが、MDBT40はGPIOが31本しかないので、右手30キー + ステータス用のLEDでいっぱいいっぱいになっています。

なお、レシーバは自分で設計は行っておらず、 Comet46 の OLED Display Receiver をそのまま使わせてもらっています。

基板はFusion PCBに発注しました。キーマトリクスがないのでLEDはついておらず、スッキリしてます。

もともとは写真のようにCR2032を1個で運用していたのですが、普通に使っていると1ヶ月で電池が切れてストレスに感じたので、設計変更時に塩化チオニルリチウム電池を使用するようにしました。

定格上は 3V 220mAh から 3.6V 2600mAh なのでエネルギーは14倍になりますが、実際はそれ以上に電池の持ちは良くなると思います (まだ切れたことがないので分かりませんが…)。というのも、MDBT40は無線の送信時に 15mA 程度の電流を消費しており、CR2032を1個で運用していたときは標準的な放電電流を大きく上回ってしまっていたためです。

※消費電力の計測については後述します

ケース

マウント方式はサンドイッチマウントというかボトムマウントというか…、トッププレートがPCBの貫通穴を通してボトムケースのボスにネジ止めされています。あまり打鍵感について理解せずにケースを設計したので、8本のボス + 外周でトッププレートを支えており、打鍵感は非常に硬いです。

もともとは奥に見えるケースのように、CR2032の部分のケースをくり抜くことで、高さをなるべく低く & 電池が外から交換可能を実現していました。ただ、いくら外から簡単に電池が交換できるとはいえ月イチでキーボードの反応が悪くなるのはダメでした…

そこで設計変更時にはキーボードに10度の傾斜をつけ、足の部分に単三電池と同じ形状の塩化チオニルリチウム電池を入れることにしました。手前側はCR2032がなくなったことで、逆に高さを低くすることができています。

プレートは過去記事でお世話になった、AliExpressのBestCarbonに注文しました。1mm の綾織マットを切削してもらっています。特にカーボンである必要はないのですが、見た目が好きなのでカーボンを使用しています。

※カーボンは導電性で電波を遮断してしまうので、電波特性的には樹脂のトッププレートのほうが良いかもしれません

このときは1.5uキーキャップが手に入らなかったのですべて1uの位置にキースイッチを配置していますが、今は1.5uの位置にキースイッチを挿し直して、プレートも1.5u専用のものを作り直しています。

ファームウェア

このキーボードは、左手と右手にそれぞれ入っているNordic MCUがキー状態が変更されるたびに現在のキー押下状態を送信し、PCにUSB接続されたレシーバに入っているNordic MCUがそれを受信します。レシーバのatmega32はNordic MCUからシリアル通信でキー状態を受信して、QMKのマトリクススキャン関数の中では、実際にはマトリクスをスキャンせずに受信した値を使用します。

左手と右手は電池で動くので、可能な限り消費電力を少なくする必要があります。そのため、なるべくMCUがスリープしている時間を長くして、キー入力があったときだけ割り込みで起動するようなファームウェアにしなくてはいけません。

ところが、割り込みとスリープが絡むとファームウェアの挙動を追うのは難しいですし、クロックソースや無線送信の設定で大きく消費電力が変わってしまうこともあるので、消費電力が少ないファームウェアを開発する際には、実際にボードが消費している電流を計測してみるのが良いと思います。

良いオシロスコープを持っていればそれで計測することもできたのですが、自分は持っていなかったので、Nordic Power Profiler Kit を購入してみました。

Nordic PPKはNordicのMCUに限らず、(出力電圧電流の範囲であれば、)どんなボードでも消費電流を計測することができます。もちろんオシロスコープでも同様のことは可能ですが、PPKはUSBで繋ぐだけで簡易的に計測可能なので、お手軽さが良い感じです。

最近、後継の Nordic Power Profiler Kit II が出たようです。最大出力可能電圧が3V -> 5V、サンプリングレートが10倍になって、さらにアクリルのケースもついてくるようなので、無線自作キーボードを作っている方は消費電力計測用にに購入してみても良いかもしれません。

実際にPPKで計測するとこのような計測結果を得ることができます。グラフで大きく立っているスパイクが無線を送信したときの消費電流になっていて、1キー押して離した時には2回の送信が行われます。

※このグラフはThumbsplit58のファームウェアで、nRF5 SDK 11のデフォルトの無線設定を使用した状態の計測結果です

Comet46の実装では何もキーの状態に変更がない場合でも10秒間に一度キーの状態を送信しようとする挙動になっていたのですが、Comet46は最大リトライ回数が100回に設定されているのもあり、PCがスリープしてレシーバに電流が共有されていない状態では10秒おきに100回の送信が行われてしまっていました。

そこで、Thumbsplit58のファームウェアでは送信失敗した場合に、送信成功するか500msが経過するまで125ms周期でキー状態を再送信する挙動に変更することで、送信失敗時に不整合が起きる状況をなるべく回避しつつ、無駄な送信をしないように変更しています。

※このグラフでは送信成功しているので、再送信は発生していません

※500msタイムアウトはデバウンス用の1000Hz割り込みの中でカウントしているのですが、もう1本周期割り込みを追加すれば消費電力を更に減らせるかもしれません

次のグラフはサンプリングレートを上げて送信部分を取り直したものです。1回の送信(上のグラフでスパイクに見えていた部分)は実際は「キーボードからレシーバへの送信」と「レシーバからのACK受信」の繰り返しになっています。

このグラフは送信信号強度を +4dbm に設定したときのものですが、送信信号強度を落としてもデータ送信の山が小さくなるだけでACK受信の山は変化しないため、送信信号強度はそこまで消費電力に大きな影響を与えず、むしろリトライ回数を減らすほうが重要そうです。

送信時にリトライが発生するのは周波数ホッピングを行っているためです。Nordic MCUは下記のようにある一定時間ごとに送受信するチャンネルを変更しながら送受信を行いますが、送信側と受信側で時刻同期が取れていない状態では、チャンネルが合わずに送受信を行うことができません。そこで、送信側は送信が成功するまで同じ周波数で何度も(timeslots_per_channel_when_device_out_of_sync回)送信を行い、送信が成功したあとは受信側と同期してホッピングを開始します。

※Gazell Link Layer User Guide の Frequency Hopping より

デフォルトでは channel_table に入っているのが 4ch, 25ch, 42ch, 63ch, 77ch の5つで、Timeslot が 600us 、timeslots_per_channel は 2 になっていて、1.2ms毎にチャネルホッピングしているようです。

timeslots_per_channel_when_device_out_of_syncのデフォルト値は 15 になっていたのですが、そのチャンネルが競合しているケースのリトライ回数を減らすために、自分のファームウェアでは 10 (ちょうど総当り) に変更してみました。また、最大リトライ回数は20に設定しているので、チャンネルが競合していた場合は次のチャンネルを試します。ただし、この設定変更をしても劇的にリトライ回数が減らせるわけではなく、ベストな設定はいまいち見つけられていません…

※channel_tableに入っているチャネル数を減らすと良かったりするかもしれませんが、未検証です

送信側と受信側が同期している時間を増やせばリトライ回数を大きく減らすことができるのですが、syncを維持するには16MHzクロック(HFCLK)を動かし続ける必要があるので、sync維持時間をむやみに伸ばしてしまうとsync維持中の消費電流が1mA程度に増えてしまって本末転倒になってしまいます。

自分の計測では1回のリトライあたり6.7uC、1msのsync維持に1.2uCの電荷が消費されました。チャンネル競合がないとするとリトライ回数の期待値は3.6回になるので、全くsyncしない場合の送信1回のリトライによる電荷消費量の期待値は24.12uCになり、これはsync維持時間の20msに相当します。つまり、20msの間に送信が2回以上連続して発生しない場合は、sync維持時間を20msより伸ばしてしまうとsyncの意味がなくなってしまいます。

デフォルトでは 18ms 間syncを維持するようになっていますが、キーボード用途の場合は1回の送信ペイロードにすべてのデータが収まるためにデータを連続送信する必要がなく、普通に打鍵していて20ms以内にキー入力が重複することは多くないので、自分のファームウェアではsync維持時間は 0ms にして常に out of sync 状態にするように無線設定を変更しています。

キーマップ

現在のキーマップはこんな感じで、前述の通り日本語キーボード配列がベースになっています。BackSpace、Space、Enter、DelはThinkPadでも近い場所にリマップしているので、ノートPC使用時でもそこまで違和感なく使用できます。1年程このキーマップを使っていますが、特に不満な点は出てきませんでした。

キーが2つ書いてあるキーは QMK の Mod-Tap の機能を使って、短押しで通常のキー入力、長押しで Modifierキー入力になるように設定しています。例えばCapsLockのところにあるキーの場合、短押しでEsc、長押しでCtrlになります。

残念ながら Mod-Tap は Windows/Ubuntu で容易に実現する方法がないので、ノートPCのキーボードを使用しているときには使えません。ノートPCとのキーマップ互換性の観点では入れないほうが良いのかもしれませんが、Esc/Ctrl等は実際使っていて結構便利なので入れてしまっています。

レイヤー機能は(ノートPC使用時に使えないのもあって)あまり使いこなせておらず、F1 ~ F12を数字キーに入れたり、HJKLをカーソルキーにしたり、WASDをマウスキーにしている程度です…

おわりに

初代 Thumbsplit58 を1年間使って見えてきた電池の持ち等の課題については、無事に rev2 で解決できました。今のところこれが自分にとってのエンドゲームな気がしていますが、使っていて不便なところが出てきたらまた改良していこうと思います。

塗装に関するTips

ケースは DMM.make のサービスを使って MJF で出力しました。材料はPA12GBを使用しています。

塗装はなしでも良いかなと思っていたのですが、1辺が100mmを超えていてブラック染色オプションを選べなかったのと、MJFには吸水性があるという話を聞いていたので、汚れる前に塗装することにしました。

MJFの出力は積層痕が目立ちにくく、全く表面処理をせずに塗装しても上の記事のように十分綺麗になります。

PA12はナイロンなので、プライマーは必須です。自分はミッチャクロンマルチのスプレーを使いました。ベランダで塗装するときはホコリが舞わないように水を撒いてからやると良いと思います。ただし冬場は乾燥を室内で行う必要があるので、塗料は水性のものをオススメします。自分はアサヒペンの水性多用途シリーズを愛用しています。

塗装前のPA12GBナチュラルはこんな感じで、薄いまだらなグレーです。

これをつや消しブラックで塗装するとこんな感じになりました。塗装前の表面処理は全くやっていないため、造形の都合でできた線のようなものが見える箇所があります。気になる場合は塗装前に目地埋めしたり、何度か重ね塗りする必要があるかもしれません。

突然押したキーと全く違うバラバラなキーが入力された際のTips

1年使っている中で突然押したキーと全く違うバラバラなキー入力を返したり、(キーコードにマップされてなくて)押しても反応しなくなったりする現象に遭遇したのですが、これはどうもQMKの問題というか、EEPROMが壊れたときに起きる現象のようです。

このページにあるように、EEPROM Resetを行うことで無事に押した通りのキーが入力されるようになりました。

dfu-programmer atmega32u4 flash --eeprom eeprom_reset.hex

LOUQE Ghost S1 Mk3ケースで小型Ryzenゲーミングマシンを組んでみた

noreply@blogger.com (Kazuyuki Arimatsu) — Mon, 17 Aug 2020 13:43:00 +0000

TL;DR

LOUQE Ghost S1 Mk3ケースで小型 (9.6L) のゲーミングマシンを組みました
内部の電源ケーブルを自作しましたが、高効率電源用のカスタムケーブルは自作が大変です
ケースはtaobaoで購入しましたが、taobaoを利用するには覚悟が必要です

SFF PCの世界

皆さんはPCのケースを購入する際に、何を基準にして選ばれているでしょうか？

入れようとしているマザーボードの大きさに対応しているか確認したり、ケースファンがいくつ付けられるとか、5インチベイは必要かどうか、HDD/SSDを搭載するから3.5インチベイや2.5インチベイが何個必要か、などといったことを確認すると思います。もしくは、本格水冷するならリザーバタンクが配置できるかとか、サイドパネルが強化ガラスになっていて中身のRGBライトが見えるか、なんてことが重要になってくるかもしれません。

世の中にはPCケースが小型であることに強い魅力を見出し、拡張性や冷却性能を犠牲にしてもなお、より小さいPCを組もうと探求するスモールフォームファクター (SFF) というジャンルの自作PCがあります。このSFFのコミュニティ (Reddit, SFF.Network) ではPCケースを選ぶ際に、ケースの容積 (リットル) を重要な基準とみなし、ハイスペックなCPU/GPUをなるべく小さな容積のケースに押し込めることが良いことであるとされています。

自分も2014年にVRデモ用に持ち運べるデスクトップPCを作って以降、小型PCの魅力に取りつかれており、第3世代 Ryzen が登場してからデスクトップPC更新の機会をうかがっていました。そしてついに様々な要因から「今しかない」という直感を感じたので、給付金を片手に満を持してPCの更新に手を付けた次第です。

これから発売される、もしくは過去に販売されたSFFケースの大部分は、SFF.Networkのこのスプレッドシートに網羅されています。

今回自分が購入するに当たって、以下の条件を満たす

2スロットフルサイズのグラフィクスカードが入る
電源はSFXサイズに対応している

ものを検討しました。有名どころをいくつかピックアップして紹介すると…

DAN Cases A4-SFX (公式ページ)

2016年にKickstarterで登場して以降、昨今のSFFブームを牽引し続ける最も有名なケースです。7.2Lの筐体に295mmまでの2スロット幅グラフィクスカードを搭載することが可能となっています。ライザーケーブルを使ってマザーボードとグラフィクスカードを背中合わせに配置する「サンドイッチ」構造を導入したケースで、発売以降非常に強い人気を誇っており、このケースの構造を真似た多くのケースが登場しました。

2020年1月にはv4.1が登場し、PCIe Gen4やフロントI/OのUSB3.2 Gen2に対応しました。日本ではDIRACが代理店となっており、各社通販サイトから購入することが可能です。

LOUQE Ghost S1 (公式ページ)

A4-SFXの流れをくむケースで、8.2Lサイズです。A4-SFXの弱点だったCPU冷却性能を改善するためにケースの幅を広げ、CPUクーラーの最大高さを 47mm から 66mm まで大きくしています。また、ケースの上部にTopHatと呼ばれる別売りの拡張パーツをつけることによって、ストレージを増強したり、上部に25mmファンを追加してエアフローを改善したり、水冷ラジエーターを搭載したりして冷却能力を高めることが可能になっています。TopHatをつけた場合のサイズは、M TopHatが9.6L、L TopHatが11.0Lになります。

2020年7月に登場したMk3ではPCIe Gen4に対応しましたが、日本には代理店がなく、購入するにはtaobao等を利用する必要があります。

FormD T1 (公式ページ)

基本構造がA4-SFXやGhost S1と同じ9.5Lケースですが、Ghost S1とは異なるアプローチで拡張性を高めています。Top Hatを追加することで拡張性を持たせたGhost S1に対してFormD T1ではケースの大きさは固定 (Ghost S1 + M TopHat相当) ですが、CPU/GPUコンパートメントの仕切りを動かすことができ、70mm CPUクーラー + 2スロットGPU、もしくは 50mm CPUクーラー + 3スロットGPUに組み替えることが可能になっています。

現在公式サイトから第2バッチのPreorderを受け付けており、10月から出荷が開始されるようです。

VELKASE Velka7 (公式ページ)

このケースは筐体体積を極限まで小さくするために縦置き配置とし、マザーボードとグラフィクスカードを90度方向を変えて配置することで、現行製品で最小の筐体体積 5.9L を実現しています。

ただし、このケース (revision 2.0) はまだ発売されておらず、出荷時期も未定になっています。

各ケースのサイズを模式的に箱で比較すると、このような形になります(右から順にSodaCan、A4-SFX、Ghost S1、T1、Velka7、SG05)。参考までに、2014年にゲーミングPCを組んだ時に使用した小型ケース Silverstone SG05 (公式ページ) も並べてみました。SG05も十分小型 (10.8L) なのですが、サンドイッチ型ではないのでケース内にデッドスペースができてしまい、254mmまでのグラフィクスカードしか搭載することができません。

上の候補から、現時点で入手可能なA4-SFXとGhost S1で迷ったのですが、拡張性の高さとCPU冷却性能に余裕がある点が良いと思ったので、LOUQE Ghost S1を選びました。

ほかに入手性が良い似たようなケースだと、

Nouvolo Steck (8.7L) https://www.nouvolo.com/pages/steck
Sligger SM550 (9.7L) https://www.sliger.com/products/cases/sm550/
GEEEK A50 PLUS (9.9L) https://www.geeekstore.com/shop/a50-plus-mini-itx-case/
NCase M1 (11.4L) https://ncases.com/products/m1
RAIJINTEK OPHION (16.0L) https://www.raijintek.com/jp/products_detail.php?ProductID=90

あたりがあると思いますが、外見が好みではなかったので選択肢から除外しています。

パーツ構成

CPUは今勢いに乗っているAMDのRyzen 7です。チップセットはPCIe Gen4に対応するミドルレンジのB550、メモリはRyzenの定格に合わせて3200MHz、小型ケースに収めるためにストレージはm.2のみとしました。強いグラフィクスカードを搭載するため、電源には余裕をもってCorsair SF750を選択しました。

種類	品名	値段	備考
CPU	AMD Ryzen7 3700X	38,888円	TDP 65W
マザーボード	GIGABYTE B550I AORUS PRO AX	21,450円	PCIe Gen4 / WiFi 6
メモリ	CFD Gaming CX1 DDR4-3200 16GB x2	15,279円	XMPでOCが必要
ストレージ	CFD M.2 2280 NVMe 1TB	23,980円	PCIe Gen4
電源	Corsair SF750 Platinum	21,647円
ケース	LOUQE Ghost S1 Mk3 + M Tophat	37,082円	taobaoで購入
CPUクーラー	Noctua NH-L12 Ghost Edition	6,929円	eBayで購入
ケースファン x2	Noctua A12x25 x2	8,096円
合計		173,351円

今回GPUは購入していないので、このリストには含まれていません。今初めて合計を計算して自分でもびっくりしたんですけど、10万円を軽くオーバーしてますね… 当初は給付金の範囲内でPCを更新する予定だったのですが…

Ryzen 7 3700Xは定格だとメモリ周波数が3200MHzまでに対応しているので、それに合わせてDDR4-3200を購入しました。ただし購入したCFD Gaming CX1は定格電圧1.2Vでは2666MHzでしか動作しないので、1.35V 3200MHzで動作させるためにはBIOSからXMPを有効にしてオーバークロックする必要があるので注意してください。

マザーボードはB550のmini-ITXマザーボードの中から、CPUクーラーと干渉しにくそうなもの(後述)を選びました。B550マザーボードであれば、PCIe Gen4のm.2スロットがついているので、対応するSSDを取り付ければシーケンシャルリード5GB/sの爆速ストレージが手に入ります。

電源にはCorsairの750Wのものを選択しましたが、この構成だと600Wでも十分だったかもしれません。実際、TDP250WのNVIDIA Titan RTX (TDP280W) を取り付けて3DMark TimeSpyを実行した場合でも、システム全体の消費電力はワットメーター読みで390W程度なのでかなり余裕があります。

小型ケースでハイエンドCPUを使用する場合に最も重要になるのが、CPUクーラーの選択です。Ryzen7 3700XにはWraith Prismという高品質な(しかも光る)CPUクーラーが付属しているのですが、残念ながらGhost S1には大きすぎて入れることができません。一般的に小型ケースのベンダーはケースに適したCPUクーラーのリストを提供していますが、DAN Caseは既製品のCPUクーラーに飽き足らず、A4-SFX専用に設計された Alpenfohn BlackridgeというCPUクーラーを販売しています。LOUQE Ghost S1に適合するCPUクーラーとしてはNoctua NH-L12が最も良いとされていたのですが、既に販売が終了してしまっており、Ghost S1オーナーの間では後継のNH-L12Sのヒートパイプを無理やりまげる方法などが確立されていました。ところが、2020年7月にLOUQEがNoctuaとタイアップし、NH-L12を再設計したNH-12 Ghost S1 Editionを発売し、Ghost S1にも公式専用CPUクーラーが誕生しました。

小型ケースで空冷を選択する場合にはエアフローを稼いで効率的にコンポーネントを冷却する必要があるので、ケースファンは値段は高価だが性能が高いことに定評のあるNoctuaの定番モデルを購入しました。実際、OptimumTechの比較動画ではNoctua A12x25が他を圧倒しています。

組み立て

組み立てにあたって重要なのが、CPUクーラーとマザーボードの干渉です。特に最近のハイエンドマザーボードはVRMに一体型の大型ヒートシンクがついているものが多く、mini-ITXのマザーボードではCPUクーラーのマウントと干渉する可能性があります。今回使用したNoctua NH-L12 Ghost S1 Editionではマウントの形状が改良されていて、各種マザーボードに取り付けられますが、NH-L12 無印版 だとASUS X570I等のヒートシンクにマウンタが干渉するようです。

今回のNH-L12 Ghost S1 EditionとGIGABYTE B550Iの組み合わせでも、クリアランスはギリギリでした…

また、今回の組み立てにあたって少し凝ったことをしてみようと思い、内部のATX電源ケーブルを自作してみました。蛍光グリーンとブラックのPETスリーブケーブルで、今回のパーツ構成に合わせてピッタリの長さになるようにしています。

カスタムケーブルの自作自体は (作業は非常に面倒ですが) それほど難しくなく、自分の手で行うことが可能です。基本的にはPSUのピン配置対応図 (Corsairの場合はこのページがわかりやすかったです) を確認しながら、長さを合わせて線を切って、コネクタを圧着して差し込むのを繰り返します (OptimumTechのこの動画がわかりやすかったです)

PETを使った場合に面白いのが末端の処理で、動画にあるように端子を圧着した後に熱収縮チューブを被せて、少し長めに熱を加えます。すると、PETスリーブが熱収縮チューブに圧縮された状態で溶けて固まり、熱収縮チューブをはぎ取った際に綺麗にまとまります。

ただし、カスタムケーブルを自作するうえで一つ注意しなければならないのが、高効率電源 (Corsairの場合PlatinumのSF450/600/750) 用の24pinケーブルには sense wire と呼ばれるものが取り付けられており、高効率電源はマザーボードコネクタ側の電圧をそれで計測しています。つまり、24pinケーブルを作成する際にNCを除いた23本を結線するだけではだめで、+4本追加で線をつなぐ必要があります。

Corsairの電源の場合hardforumのスレッドによるとsense wireはこの画像の4本で、この4本には電流がほとんど流れず、マザーボード端の電圧を計測するためだけに使われます。この4本の線はPlatinum未満のGoldクラスの電源では使用されないので、カスタムケーブル作成サイトや、自作紹介動画でも省略されることが多いのですが、CorsairのPlatinum電源の動作には必須なので、注意が必要です。

今回はRedditのスレッドを参考に、スリーブの中にDouble Wireの4本については給電用のAWG16とセンシング用のAWG24の2本の線を通し、AWG24を途中でスリーブから分岐して出してPSU側のコネクタに刺しました。

実際にケーブルを作ってみた感想としては本当に大変だったので、自分でやるのは (特にPlatinum電源を使用している場合は) オススメできないです… もしカスタムケーブルが欲しいのであれば、このページのようなGhost S1向けのカスタムケーブルを作成しているサイトから購入したほうが良いかもしれません… ※その際にはsense wireが必要かどうかのオプションを正しく選択してください

パフォーマンスと冷却性能

メモリをXMPで3200MHzにオーバークロックした以外はデフォルトで、NVIDIA TITAN RTX (TDP 280W)を取り付けた状態で計測を行いました。

CrystalDiskMarkで計測したSSDのベンチマークでは、PCIe Gen3の3.5GB/sの限界を超えており、PCIe Gen4が活かされているような気がします。※ベンチマーク以外ではほとんど違いを体感することはできませんが…

3DMark TimeSpyで計測したCPU/GPUのベンチマークスコアはそれぞれ、10139/14660でした。また、この時にHWiNFOで計測した最大消費電力は、CPUのパッケージが84.1W、GPUが284W、ワットモニターで計測したシステム全体の消費電力が390Wでした。

CPUのTDPは65Wなのにどうしてパッケージ消費電力が84.1Wになっているのか気になる方もいらっしゃるかと思いますが、これはRyzenの自動オーバークロック機能によるもので、Ryzenはデフォルトの設定で、冷却能力に余裕がある場合には消費電力を設定値 (PPT; 3700Xのデフォルト値は88W) までコアの動作周波数を上げようとします。

また、NVIDIAのGPUもブーストクロックという設定を持っており、設定したサーマルスロットリング (デフォルトでは84度)に到達していない場合は定格クロックから自動でブーストクロックまで動作周波数を上げようとします。ただ、Founder’s Editionのデフォルトの設定ではファンの騒音を抑えるためか、サーマルスロットリングに到達してもファンの回転数は100%にならない設定になっています。

3DMark TimeSpyのストレステストをかけてCPU/GPUの温度上昇を見てみると、デフォルトの設定ではGPU温度が87度まで上がっていますが、この状態でもGPUのファンは100%になっていません (上のグラフ)。そこで、MSI Afterburnerを使ってファンの回転数カーブを調整し、温度が80度を超えた時点で100%になるように設定したのが下のグラフになっています。

下のグラフでは2つのケースファン、GPUファンは100%で回転していますが、GPU温度は82度に到達しています。また、この時点では設定された最大ブーストクロック (1770MHz)には到達しておらず、1750MHzを超えたあたりでサーマルスロットリングされていました。現状の空冷構成では、TITAN RTXでブーストクロックを維持するのは難しいようです。

おまけ：taobao店舗からのLOUQE Ghost S1 Mk3購入

今回、LOUQE Ghost S1 Mk3はTwitter公式アカウントがツイートしていたtaobao公式店舗のうち、NOEDIY から直接購入して、転送ネコを使って国内に転送してもらいました。

昔はtaobaoの利用には中国国内の銀行口座が必要だったようですが、現在は支付宝 (Alipay) のアカウントとクレジットカードがあれば購入可能なようです。注意点としては、Alipayには観光客用のTourPassという機能があってお金をチャージして支払いに利用できるものがあるのですが、それは利用せずに、taobao支払い時に直接クレジットカードで支払います。

購入はすべてアプリ内から行う必要があり、SMS認証でtaobaoアプリのアカウントを作成したら、ストアに在庫や納期を問い合わせ、問題なさそうなら購入します。当然、アプリはすべて中国なので自分は全く読めないのですが、

アプリのスクリーンショットを撮影して、Google翻訳アプリからカメラ入力 > スクリーンショットを読み込みでなぞったところを翻訳してるので、一応表示されている内容を理解することは可能です。

taobaoで商品を購入するにあたって最も重要なのが、taobao店舗ページに書いてあることの半分は嘘で、もう半分は誇張である (特にクラウン未満の店舗場合) ということを理解することです。自分もこれを全く理解しておらずにひどい目にあったのですが、商品ページに書いてある在庫数は全て嘘 (10,000を超えていても在庫なしの可能性あり) で、記載してある納期も信用してはいけません。

これまで中国の Banggood や AliExpress といったECサイトや米国の eBay 等のオークションサイトでも買い物をしてきましたが、taobaoはそれらとは比較にならないほど圧倒的に無法地帯で、支払いをしてから急に連絡が取れなくなることもあります (※ありました)。

クラウン以上の信頼できる店舗をちゃんと選んで、購入しようとしている商品の出荷実績があるかを確認して、購入前にチャットで店舗に在庫と納期を問い合わせて、問い合わせのレスポンスが早くて信頼できそうだったらやっと購入に踏み切るぐらいがちょうどよいのかもしれません。幸いNOEDIYは英語にも問い合わせにも対応しているので、英語でチャットが可能です。また応答も非常に早く、注文した当日に発送してくれて、翌日には転送倉庫に到着しました。

taobaoにはGhost S1のクローンも多数出品されており、Redditで観測していると実際に届くものもあるようですが、コピー品は受注生産の場合も多く納期もあてにならないことが多いのでやめたほうが良いです。また、正規品を購入するにしても、他に手段があるならtaobaoから購入するべきではないと思います。

自分ははじめ、Ghost S1のクローン品を別の店舗から、taobao代行サービス (タオバオ新幹線) を使って購入しようとしたのですが、この代行サービスもまた曲者でした… てっきり代行サービスに任せておけば店舗との交渉をやってくれると思っていたのですが、その考えは甘かったようです… というのも、代行サービス業者自体が中国の商習慣 :thinking_face: で働いており、3日おきに確認しないと何もしませんし、問い合わせは50%の確率で無視され、約束した期限までに何かをしてくれたことは一度もありませんでした。結局、6/13 に買い付け依頼をしてから 8/3 の全額返金までを通して、得られたのは大きなストレスだけでした。

なので、もしどうしても必要になってtaobaoから何かを購入される場合には、信頼できる店舗を見つけて、直接交渉してみることをお勧めします…

uFactoryの格安ロボットアームxArm 5 Liteが届いたので動かしてみた

noreply@blogger.com (Kazuyuki Arimatsu) — Wed, 02 Oct 2019 07:56:00 +0000

2018年10月にKickStarterでバックしていた xArm - Most Cost-Effective Intuitive Industrial Robotic Arm を先日ついに受け取ることができました！
バックしていたのは一番安い5軸のxArm 5 Liteで、Suer Early Bird価格でなんと$2,399、他社の同スペックのロボットアームと比較すると破格のお値段です！
※エンドエフェクタは別売りなので、自作するか別途購入する必要があります
※写真のものはアクリルで自作した、電磁石つきのプレートです

ただ、当初の出荷予定は2019年4月だったのですが、順調に遅れて、最終的に受け取れたのは2019年8月末になってからでした… まだ発送されていない人も多いみたいなのでマシな方ではあるのですが、やはりKickStarterは当初から遅れることを計算に入れて気長に待つほうが良さそうですね…

この記事では、届いたxArmをセットアップして、とりあえず動かして遊んでみるところまでをまとめたいと思います。

--

固定するためのフレームを作る

xArmはこのような形でダンボールに梱包されて届きました。各関節は電磁ブレーキでロックされており、電源が投入されていない状態では動かないようになっています。

他のロボットアームでもそうだと思うのですが、xArmは何かに固定した状態で使用することを想定されており、単体で自立することができません。まずは、アームを動かしても倒れないように、何かにしっかり固定してあげる必要があります。

今回は、ミスミのmeviy (メヴィー) というサービスを使って固定用のプレートを作り、

同じくミスミで販売している30mm角のフレームで床に置くための足を組みました。

meviyは今回初めて利用したのですが、200mm角でt5のSS400プレートにφ5.5とφ6.6の穴を12個ずつ開けて、4,712円でした。stepファイルをアップロードしてオンライン注文してから6日で製造して発送、1週間程度で受け取ることが可能ですし、材料費も考えればお得で手軽だと思います。

フレームの方は30mm角のHFS6-3030で、300mmずつ脚が4方向に伸びるようにしてみました。倒れないか少し不安があったのですが、フレーム自体の重さもあるため、重りを載せなくても特に倒れる心配はなさそうです。

組み立てる際に問題になるのが、(おそらく初期ロットのxArmはすべて同じだと思うのですが、)電源コネクタが干渉してM5のネジを1本締めることができない点です…

※写真は電源プラグがついたままですが、電源プラグを外しても、コネクタが干渉してネジをフランジに開いている穴に入れることができません…

完全にuFactoryの設計ミスなのですが、電源コネクタのネジを外して少し浮かせた状態でネジを入れて、ボールポイントの六角で抑えながら、裏側のナットを回すことでなんとか固定することができました。

裏側には溝にはめるゴム足を付けているのと、フレームの端には断線と怪我防止のためにキャップをはめています。取り外しを考慮して、プレート裏には位置決めできるナットを使ったりしたので部品代が高くついてしまい、合計12,000円程度になってしまいました。

--

ファームウェアのアップデート

とりあえず動かすために必要なソフトウェアとマニュアルは、公式ページのxArm向けDownloadからダウンロードすることができます。このページはモバイル版ページが存在しないようで、モバイル端末で見ようとするとトップページが表示されてしまいます。携帯端末から見る場合にはPCブラウザモードで見るようにすると見られると思います。

とりあえず xArm Studio を使うと簡単にロボットアームを動かすことができるので、ダウンロードしてインストールしておきます。初回起動時に自動でアップデートが走るので、インストールが終わったら起動して、待っている間にxArm 5 User Manual と xArm Studio User Manual を読んで置くのが良い感じでした。xArm Studioのアップデートが終わったら、マニュアルに従ってロボットアーム、コントローラ、PC接続すれば良いと思います。
※コントローラ本体には2つのRJ45コネクタがあるのですが、RS485で接続する場合とEthernetで接続する場合で、刺す場所を間違えないように注意する必要があります

初期ロットの場合、ただ電源を投入してつなげただけではxArm Studioの画面に何も表示されず白い画面のままになってしまうので、フォーラムの記事【Official】White screen in xArm Studioに従って、コントローラのファームウェアを更新する必要があります。

フォーラムでは「xArm Controller自体がインターネットに接続できる必要がある」と書いているのですが、「xarm-tool(アップデートプログラム)」を実行するPCがインターネットに接続できれば問題なくアップデート可能でした。

アップデートにはかなり時間がかかる(15分程度)ようなのですが、このようにコマンドプロンプトで何かをダウンロードしているログが出れば正常に進んでいると思います。

他にもトラブルがある場合には、公式フォーラムのFAQ、FAQ2、を読み、それでも問題が解決しない場合にはフォーラムで質問すると答えが得られると思います。

--

動かしてみる

xArm Studioが無事に起動するとこのような画面が表示されると思います。

左から

LiveControl ... とりあえず動かすモード、関節を個別に動かしたり、外力を加えてポーズを設定することも可能
Blocky / Python ... プログラムで動かすモード、エディタ機能も内蔵
Recording ... 外力を加えてモーションを記録再生するモード、Blockyから記録したモーションを呼び出すことが可能
Settings ... 設定

となっていますが、実際に動かしてみる前にまずSettingsを開き、

Sensitivity SettingsのCollision Sensitivityが0より大きな値になっていることを確認します。この値はアームが何かに衝突した際に緊急停止する機能の設定で、どの程度の外力が加わった場合に停止するかを設定します。この値が0になっていると緊急停止機能が無効になり、何かに衝突してもアームが止まらずに自分自身や周りの物を破壊してしまう恐れがあるため、特別な事情がない場合は0より大きな値に設定しておくことをおすすめします。

LiveControlではとりあえずアームを動かしてみることが可能です。

緊急停止スイッチが入った状態でロボットを接続、電源を入れてxArm Studioを起動していると思うので、最初はこの画面のReal Robotではなく、Simulation Robotにチェックが入っている状態だと思います。

まず緊急停止スイッチをオフにして(この状態でアームやエンドエフェクタに電源が供給されますが、電磁ブレーキは効いたままです)、Real Robotのラジオボタンを押すと

この画面になるので、Enable Robotを押すと関節の制御がオンになり、電磁ブレーキが外れます。また、Manualを押すことでロボットの関節を外力で動かすことが可能になり、手で触って自由にポーズを変えることが可能になります。
※エンドエフェクタが何もついていない場合には問題ないのですが、何か付けている場合は重さを予め設定しておかないと、重力方向に力がかかったと判定して勝手にうごいてしまうので注意が必要です

Blocky / Pythonでは内臓のエディタを使って、自由にプログラミングしてアームを動かすことが可能になっています。エンドエフェクタのGPIOから入力も取れるので、面白いことができそうな気がします。ビジュアルプログラミングができるってことは実質知育玩具なので、ご家族の目が気になって導入を躊躇している方も、是非ゴリ押ししてみてください。
※結果は保証しません

Recordingではアームを自分で動かしてモーションを記録してファイルに保存したり、記録したモーションを再生することが可能になっています。モーションはあくまで決まった動作を行うものなので、Blocky / Pythonほど自由に動かすことはできませんが、自動で動くので見ていて面白いです。
※エンドエフェクタはアクリルで自作してみました

また、xArmはROSにも対応しているので、MoveItで動かすことも可能になっています。もちろんアーム自体のgazebo用descriptionファイルも公開されているので、軌道計画も簡単に行うことが可能になっています。ただしxArm 5 Liteの場合は自由度が足りず、軌道が生成できないケースが目立ちました。

--

xArm 5 Liteを買ってみての感想

実際に動かしてみた感触では、動作はなめらかですし、価格が非常に安いにもかかわらず、しっかり動作していると思います。ただ、今回、一番安かったので5軸のxArm 5 Liteを買ってみたのですが、用途によっては自由度が足りないケースが出てくることがわかりました。

xArmには5 Lite、6、7と3種類の製品があり、それぞれ自由度が5軸、6軸、7軸となっています。上から物を掴んで別の場所に移動させるような用途では5軸で問題ないのですが、壁のスイッチを押したり、斜めになっているタッチパネルを操作する場合などでは、5軸では自由度が足りず、アームの先端をそこまで動かせないと思います。

エンドエフェクタで工夫することも可能かもしれませんが、xArm 6であればxArm 5 Liteの3番めと4番目の関節の間に、軸方向に回転する軸が1つ追加されており、アーム先端が取れる姿勢が多くなると思います。

GLSLでGPUを活用するROSノードを作ってみました

noreply@blogger.com (Kazuyuki Arimatsu) — Thu, 22 Aug 2019 16:48:00 +0000

TL;DR

OpenGL + GLSLでsensor_msg::Imageの画像をGPUで処理できるROSノードを作りました (GitHubレポジトリ)
EGL + OpenGLで実装しているため、X serverが起動していない環境でも(多分)動作します
OpenGLは勉強してて色々限界を感じたので、Vulkanが使える環境ならVulkanを使ったほうが良いかもしれません

はじめに

最近、NVIDIAのJetsonシリーズを始めとしたGPUが強い組み込みデバイスが登場してきました。Project C.G.S.ではJetson TX2をドローンに搭載して自律飛行にチャレンジしているのですが、Jetson TX2にはせっかく強いGPUが載っているのにもかかわらず、全く使いこなせていませんでした。

GPUを活用しようとした場合、CUDAやOpenCL、OpenCVのGPU実装を使う手もありますが、なるべく移植性の高い方法で手軽に書けた方が幸せになれそうです。GLSLなら移植性が高いですし、画像を扱う分には手軽で、CG分野の知見を活かせそうだったので、ROS環境でOpenGL + GLSLを使ってGPUによる処理をしてみることにしました。

※本当はVulkanが使いたかったのですが、手持ちのノートPCのCPUが古く(Broadwell; Core i5-5300U)、搭載しているIntel HD Graphics 5500はVulkanに対応してなかったので、ノートPCでも開発するために仕方なくOpenGLにしました
※この直後の世代のSkylakeから、Intel HD GraphicsがVulkan対応になってます、惜しい！

Direct Xのほうは9と11を触ったことがあったのですが、OpenGLはほとんど素人で、全く知らないところから手探りで進めてます。そのあたりも含めて、OpenGLについて全然知らないところから学んだ軌跡についても、ここに残しておきたいと思います。なるべく正確な記述を心がけていますが、情報が間違っている箇所があるかもしれません。もし何かありましたら、コメントで指摘していただけると幸いです。

オフスクリーンレンダリングについて

まず、今回ROSでOpenGLを使う上で、一般的なCG分野でのOpenGLの使用とは大きく違う点が一つあります。普通、OpenGLを使う際には何かしらレンダリングした結果を画面に表示すると思うのですが、今回ROSでOpenGLを使うにあたって、入出力ともROSのメッセージを使用するため、画面へのレンダリングは行いません。これをオフスクリーンレンダリングと呼ぶようです。

※Windows環境でオフスクリーンレンダリングされている方の記事 : ウインドウを作らずにOpenGLでレンダリングする方法

Ubuntu上でどのようにレンダリングが行われているか理解するのに、WikipediaのLinux Graphics Stackの図が非常にわかりやすくまとまっていました。

※Attribution: Shmuel Csaba Otto Traian; This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.

図中の色分けにはちゃんと意味があって、重要な登場人物は

緑 : libGL ... OpenGL系APIの実装、GPUベンダやMesaが提供するライブラリ、プロプライエタリなものは直接カーネルを叩くものもあるが、Mesaが提供するものは命令をハードウェア固有のAPI呼び出しに変換してlibDRMに渡す
紫 : Display Server / Window Manager ... OSのウィンドウを管理する仕組み、X Window Systemが最も普及している仕様で、Xorg / libX がそれぞれ、サーバー / クライアントのリファレンス実装

の2人です。Ubuntu上で画面にOpenGLでレンダリングをしようとした場合、ウィンドウ(=ディスプレイの領域)を管理している紫の人たちにお伺いを立ててから、そのウィンドウに紐付いたコンテキストを使って緑の人たちを初期化する必要がありました。
※それによって、GPUはレンダリングしようとしているウィンドウの上に別のウィンドウが重なっている場合に、そこ部分のレンダリングを行わないということが可能になります(Pixel Ownership Test)

上の図を見ながらThe Linux Graphics Stack (翻訳してくれた方のブログ) のブログ記事を読むと歴史の流れがよくわかります。当初、ウィンドウに紐付いたOpenGLの初期化を行う方法は、プラットフォーム固有のAPIでウィンドウを作成した後にWGL/GLX APIというAPIを使う必要がありました。WGLがWindows向けのAPIで、GLXがLinux向けのAPIです。このあたりをラップして簡単にクロスプラットフォームでOpenGLの初期化ができるようにしたのがGLUTやGLFWです。

名前から想像できる通り、GLX APIはX Window Systemに依存したAPIなのですが、モバイルデバイスがGPUを搭載するようになって問題が出てきました。当然モバイルデバイスではX Window Systemは動作していないで、OpenGLの初期化をする上でGLX APIは使用できません。そこで、OpenGL ESの登場とともに生まれたのがEGLというAPIです。EGLが作られたことで、紫の部分とは全く関係なく、独立して緑の部分の初期化を行うことができるようになりました。

EGLは当初OpenGL ESしかサポートしていなかったのですが、EGL 1.4からOpenGL (デスクトップ用のフル機能)をサポートするようになりました。よく勘違いされがちなのですが、EGLとはOpenGL ESに紐付いたものではなく、OpenGLコンテキストを作成するための独立したAPIセットです。現在EGLは、WGL/GLXを置き換えるクロスプラットフォームのAPIとなっています。

普通にOpenGLアプリケーションを作ろうとすると、GLUTやGLFWを使用するのが簡単だと思います。GLUTやGLFWは、ウィンドウの作成(紫の部分)とOpenGL Contextの作成(緑の部分)をセットで行い、簡単にクロスプラットフォームのデスクトップアプリケーションを作る思想で作られています。GLUTのglutCreateWindowやGLFWのglfwCreateWindowでは、Display Serverでウィンドウが作成された後、それに紐付いたOpenGL Contextがセットで作られます。そのため、OpenGLを使用するためにはDisplay Server(Xorg等)が動作している必要がありますし、アプリケーションはlibX等をリンクしなくてはいけませんし、アプリケーションはOpenGLの機能を使う前にWindowを作成しないといけません。

一方、EGLを直接使用することで、Display Serverとは独立してOpenGL Contextを作る事が可能です。今回作成するROSノードは組み込みデバイス上で動作することを想定していますので、ディスプレイは繋がっていないかもしれませんし、X Window Serverも動作していないかもしれません。そのため、EGLを使用したOpenGLの初期化を行う必要があります。

EGLを使ったコンテキストの作成

EGLに関することは公式ドキュメントに詳細が書かれていますが、ここでも簡単にまとめておきたいと思います。

EGL Introduction
https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglIntro.xhtml

EGLが提供しているのは、従来GLXなどのプラットフォーム依存APIで提供されていた、OpenGLの初期化部分の処理になります。オフスクリーンレンダリングに必要なのは、EGLを使ってディスプレイハンドルの取得(GPUの指定)をした後に、パラメータを指定して
OpenGLコンテキストを作成するところのみです。GLXのAPIと手順が近いですが、ウィンドウを作成しなくてよいのでシンプルですね。

//Get default display handle
auto display = eglGetDisplay(EGL_DEFAULT_DISPLAY);

//Bind OpenGL API to use full desktop function other than OpenGLES
eglBindAPI(EGL_OPENGL_API),

//Create default configuration
constexpr std::array<EGLint, 1> configAttributes = {
    EGL_NONE,
};

EGLConfig config;
EGLint numConfig;
eglChooseConfig(display, configAttributes.data(), &config, 1, &numConfig);

//Specifying OpenGL Core 4.5; this should be match glad loader profile.
const std::array<EGLint, 7> contextAttributes = {
    EGL_CONTEXT_MAJOR_VERSION, 4,
    EGL_CONTEXT_MINOR_VERSION, 5,
    EGL_CONTEXT_OPENGL_PROFILE_MASK, EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT,
    EGL_NONE,
};

auto context = eglCreateContext(display_.get(), config, EGL_NO_CONTEXT, contextAttributes.data());

ここではデフォルトディスプレイを使用していますが、GPUが複数搭載されている環境では、明示的にディスプレイIDを指定する必要があるかもしれません。このあたりはDirectXでも同様の仕組みがあるので、比較的とっつきやすいかもしれません。

次に、作成したEGLコンテキストを使ってOpenGLコンテキストの作成(OpenGLの初期化)を行います。OpenGLコンテキストはOpenGLの全ての内部状態を保持するインスタンスです。
プロセス内に複数作ることも可能ですが、スレッドに対して1つしか持つことができません。スレッドローカルにCurrentなContextを設定できて、すべてのOpenGL APIはCurrentContextに作用します。

OpenGL Context
https://www.khronos.org/opengl/wiki/OpenGL_Context

今回はOpenGLESではなくデスクトップ版のフル機能のOpenGLを使うので、eglBindAPIでOpenGLを指定してからコンテキストを作成する必要があります。また、コンテキスト作成時のAttributesには、使用するOpenGLのバージョンを指定しておきます。ここで指定するバージョンは、後述するOpenGLローダーで指定するバージョンと一致している必要があります。

OpenGLのコンテキストには、Core Profile / Compatibility Profileという2つのContextが存在します。Compatibilityはすべての機能を実装しますが、CoreはObsoleteな機能を実装しません。自分で一から実装を行う範囲ではCore Profileで十分だと思うので、これもAttributesに設定しておきます。

実装にあたっては、こちらのブログ記事(Kabuku; GCPのGPUインスタンスでレンダリングを高速化)も参考にさせていただきました。また、この方の別の記事にあったのですが、NVIDIAの最新ドライバをEGL使用する場合には、libGLではなく、libOpenGLをリンクする必要があるようです。NVIDIAのGPUをお使いの方でうまく行かない場合には、試してみてください。

NVIDIA公式も、EGL + OpenGL without an X serverという記事を公開しています。libOpenGLをリンクする必要がある話についても、ここに記載されていました。

OpenGL APIのエントリポイントをロード

Contextさえ作ってしまえば、普通にgl〜の関数を利用してレンダリングすることが可能になります。ところが、残念ながらOpenGL 1.1以降のCore APIと拡張は、エントリポイントがデフォルトで定義されていないので、Contextからポインタを取得しないと使用することができません。EGLでContextを作ったならeglGetProcAddress関数でひとつずつ必要なAPIのエントリポイントを取得することもできるのですが、サードパーティのOpenGL Loading Libraryを使うと便利である、とKhronosがアナウンスしています

OpenGL Loading Library
https://www.khronos.org/opengl/wiki/OpenGL_Loading_Library

正直この辺はサードパーティに頼るのではなくてちゃんと手順を整えて欲しいとは思うのですが、どうなんでしょう…
※現状、紹介されている多くのライブラリがメンテナンスの手が足りず、更新されなくなってしまっています

最も広く使われているのはGLEWだと思うのですが、Ubuntu 16.04にaptで入るバージョンだとEGLに対応していないのと、直近2年ほど更新が止まっているので、代わりにGladを使用することにしました。Gladは継続的に更新されており、GitHubのスターも多く、GLFWのチュートリアルでも使われています。

Gladでは、このページのWeb UIを使ってOpenGL APIのバージョンとプロファイル、使用する拡張機能を指定して、ヘッダファイルとコードを自動生成することができるようになっています。

今回は、Ubuntu16.04 にaptで入る最新のlibglx1-mesa-glxが対応するOpenGL Core 4.5を選択しました。指定するバージョンはコンテキストを作成した際のAttributeのバージョンと合わせておきます。また、他にも必要な拡張機能があれば追加します。
※ハードウェアがサポートする拡張機能はglxinfoで調べることが可能です

生成されたGladのOpenGLローダーコードが提供しているgladLoadGLLoaderは、プラットフォーム依存のOpenGLエントリポイント取得関数を外部から渡すことが可能になっています。EGLでコンテキストを作成した場合には、eglGetProcAddress関数のポインタをgladLoadGLLoaderに渡せば後はよろしくやってくれます。

gladLoadGLLoader(reinterpret_cast<GLADloadproc>(eglGetProcAddress))

OpenGLの拡張機能を使用する場合には一つ注意点があって、OpenGLでは同一の機能がVendor/EXT/ARB/Coreで提供されているので、まず機能がCoreに無いか探す -> 次にARB、EXT、Vendorの順で提供されている機能を探す必要があります。これは、OpenGLに新しい機能が実装される場合、まずVendorが独自拡張で機能を実験的に実装し、それがARBに認められてから、最終的にCoreに統合されるといったステップを踏んでいるためです。

今回のROSノードの処理の流れ

ここまでで、OpenGLの初期化処理まで実装することができました。ここからは、OpenGLのAPIを使ってシェーダ、頂点バッファ、テクスチャ、サンプラ、フレームバッファとレンダリングに必要なパイプラインのセットアップを行います。

処理の基本的な流れは、

頂点バッファ、シェーダ、FBOをセットアップ
ROSノードに届いたsensor_msgs::Imageをcv_bridgeでOpenCV画像に変換
画像データを入力テクスチャとしてGPUに転送
シェーダを実行、FBO経由でテクスチャにレンダリング結果を書き込み
レンダリング結果が書き込まれたテクスチャをCPUに転送
画像データをsensor_msgs::Imageとして出力

と言った流れになります。

以降の記事では、この図のOpenGL APIが絡むそれぞれの要素について、コード例を交えながら説明したいと思います。詳細な実装については、GitHubレポジトリのSimpleRenderer.cppと、cgs::egl名前空間、cgs::gl名前空間のそれぞれの機能のラッパーの実装を参照してください。

-----

頂点バッファ

頂点バッファとインデックスバッファはそれぞれ、cgs::gl::VertexBuffer、cgs::gl::ElementBufferのかたちにまとめてみました。基本的にはglCreateBuffersしてからglNamedBufferDataでデータを転送しているだけです。この2つをcgs::gl::VertexArrayでシェーダと紐付けて使用します。

//Prepare simple vertex type
struct Vertex
{
    float x, y, z;
};

//Prepare verticies and indicies for a quad that covers the whole screen
static constexpr std::array VERTICIES = { 
    -1.f, -1.f, 0.0f,
     1.f, -1.f, 0.0f,
     1.f,  1.f, 0.0f,
    -1.f,  1.f, 0.0f,
};
static constexpr std::array INDICIES = { 
    0, 1, 2,  
    2, 3, 0,
};

cgs::gl::VertexBuffer vbo(ERTICIES, GL_STATIC_DRAW); 
cgs::gl::ElementBuffer  ebo(INDICIES, GL_STATIC_DRAW); 
cgs::gl::FrameBuffer          fbo;

vao.mapVariable(vbo, glGetAttribLocation(program.get(), "position"), 3, GL_FLOAT, 0);
vao.mapVariable(ebo);

OpenGLの頂点バッファの扱いについては、こちらの記事(算譜記録帳; OpenGLでの頂点データの扱いの変化)が非常に参考になりました。ただ、ブログ中のコードではDSAではない古いAPIが使われているので、実装の際にはglCreateBuffers/glNamedBufferDataを使用するようにしたほうが良いと思います。より詳細な情報に関しては、公式ドキュメントを参照してください。

Vertex Specification

https://www.khronos.org/opengl/wiki/Vertex_Specification

シェーダ

シェーダのコードも同様にcgs::gl::Shaderとcgs::gl::Programにまとめています。cgs::gl::Shaderで個々のシェーダをファイルから読み込みコンパイルし、cgs::gl::Programに指定してリンクします。

std::array shaders({
    cgs::gl::Shader(GL_VERTEX_SHADER,   "vertex_shader.glsl"),
    cgs::gl::Shader(GL_FRAGMENT_SHADER, "fragment_shader.glsl"),
}); 
std::gl::program program(shaders); 

//Uniform parameters  setup
program.use();
glUniform2f(glGetUniformLocation(program_.get(), "resolution"), width_, height_);
glUniform1i(glGetUniformLocation(program_.get(), "texture"), 0);

より詳細な情報に関しては、公式ドキュメントを参照してください。

Shader Compilation
https://www.khronos.org/opengl/wiki/Shader_Compilation

テクスチャ

テクスチャは2Dのみをcgs::gl::Texture2Dとしてまとめています。これもglCreateTexturesして、glTextureStorage2Dしているだけですね… レンダリングパイプラインの初期化では、シェーダに対して設定する入力テクスチャと、レンダリング結果を保存する出力テクスチャの2つを同じサイズで作成しています。

cgs::gl::Texture2D textureIn(GL_SRGB8, width_, height_);  //
cgs::gl::Texture2D textureOut(GL_SRGB8, width_, height_); //Assuming sRGB input and output

ここでポイントになるのは、テクスチャのinternalFormatにSRGBを指定している点になります。カメラ画像などを含む一般的な画像のRGB画素値には、輝度に対して線形の値ではなく、一般に1/2.2乗のガンマ補正を適用した値(SRGB値)が格納されています。ところが、GLSLを始めとするシェーダー内の処理ではRGB画素値が線形である前提で書かれることが多いため、どこかでSRGB値から線形RGB値に変換する必要があります。OpenGLはこれを簡単に行う仕組みが用意されており、テクスチャのフォーマットにSRGBを指定することで、テクスチャから読み出す際にSRGB -> 線形RGB、テクスチャに書き込む際に線形RGB -> SRGBへの変換を自動で行ってくれます。

現在のROSノードでは画像の入出力はSRGB色空間で行われることを前提にしていますが、Bayerパターンのカメラを扱う場合等では線形RGBを直接扱うこともあると思いますし、2.2以外のガンマ補正が書けられた画像を扱う場合もあると思います。そういった場合にはテクスチャのフォーマットはRGBとして、GLSL内で適切な補正を行う必要があります。

入力テクスチャは毎フレームレンダリング開始前にCPUからデータを転送し、出力テクスチャはcgs::gl::FrameBufferにセットして、レンダーターゲットに設定、レンダリング結果をCPUに転送します。

//Write input image to the texture
textureIn_.write(GL_BGR, GL_UNSIGNED_BYTE, src.data);

//Perform rendering here...

//Read result
textureOut_.read(GL_BGR, GL_UNSIGNED_BYTE, dest.data, dest.rows * dest.cols * dest.channels());

CPU/GPU間のテクスチャの受け渡しにはPixel Transferを使うと速いという回答をよく見かけますが、Pixel TransferはCPU/GPU間のデータ転送を非同期で行い、レンダリングパイプラインを待機させずにテクスチャデータを書き換える用途に使われます。

Pixel Transfer
https://www.khronos.org/opengl/wiki/Pixel_Transfer

今回のオフラインレンダリングでは毎フレームGPUを動かす前にテクスチャの転送を完了させ、描画結果をCPUに戻してPublishする必要があるので、Pixel Transferによる非同期転送の恩恵を受けることができません。そのため、今回の実装ではPixel Transferは使用せず、glTextureSubImage2DとglGetTextureImageで転送を行いました。

GPU/CPUの実行速度の比較

ここまでで、OpenGLを使ったレンダリングパイプラインの初期化があらかたできました。あとは頂点バッファ、シェーダ、フレームバッファをバインドして、レンダリング関数を呼びだせばレンダリングができます。

//Bind OpenGL Objects
textureIn_.bindToUnit(0);
sampler_.bindToUnit(0);
fbo_.bind();
vao_.bind();

//Perform rendering
glViewport(0, 0, width_, height_);
glDrawElements(GL_TRIANGLES, INDICIES.size(), GL_UNSIGNED_INT, nullptr);
glFinish();

次に、実際に実行して速度を比較してみたいと思います。比較はUSBカメラから取得した画像をimage_transportで転送し、CIELab色空間に変換してから線形SVMで特定の色を分離する、という処理で行ってみました。CIELab色空間を線形カーネルで分離するのが適切かは置いておいて(一応、赤色であればそれっぽく分離は可能です)、GPU版はGLSL(Fragment Shader)で、CPU版はOpenCVで実装を行いました。

該当処理にかかった時間をnsで出力しながら計測し、記録されたログの中間50フレームの平均をとったものがこちらです。計測はIntel Core i5 5300U 2.3GHz (Intel HD Graphics 5500)で行いました。
※GPU版の方はGPUへのテクスチャ転送と、CPUへの書き戻し時間も含めた時間で計測しています

解像度	CPU	GPU
320x240	5.85 ms	1.25 ms
640x480	21.8 ms	4.30 ms
1280x720	60.0 ms	12.3 ms

低い解像度ではGPU/CPU間の転送でGPUが不利になるかと思ったのですが、CPU/GPUとも解像度に応じてリニアに処理時間が増えているようです。全体としてGPUの方が5倍程度早い結果となりましたが、CPUの方のコードは残念な感じの実装なので、この程度の処理の場合は工夫すればCPUでも十分なパフォーマンスが出せるかもしれないです。

以降の記事では、OpenGLの実装に関する雑多な情報を(恨み混じりで)補足します。

-----

OpenGLについて

DirectXと違って、OpenGLのAPIは同じ名前空間に新しいAPIと互換性のための古いAPIが混在している上に、拡張APIも多くの種類があるので、ぱっと見どうすればよいのか非常に分かりにくいです。新しいAPIを使えば非常に簡単にできる場合でも、互換性のために残されている古いAPIを使って面倒な実装をしてしまうこともありますし、特に警告が出るわけでも無いのでそれに気づくことも難しいです。また、インターネット上にある情報は古いものが多く、参考にしているページが古いAPIを使っている場合も多いです。

Khronosが公開している CommonMistakes のWikiページには、インターネット上にはびこる古いコードの問題と、新しいAPIでそれを代替する情報が含まれているので、OpenGLを使った開発を始める前には是非読んでおいた方が良いと思います。

Common Mistakes
https://www.khronos.org/opengl/wiki/Common_Mistakes

ハマりがちな落とし穴として個人的に気になったのが

テクスチャに適切なパラメータを一括で設定するために、glTextureImage2Dではなくて、glTextureStore2Dでテクスチャを作成してからglTextureSubImage2Dでデータを転送する
API呼び出し毎にglGetErrorを呼び出すのをやめて、glDebugMessageCallbackを設定して全てのエラーを補足する
internalFormatはテクスチャのフォーマットを決めるだけで実際にGPUがどんなメモリ配置でデータを格納するかは実装依存で、internalFormatが合っていても転送時に変換が起きる可能性がある
パラメータを変更する際にglBind系APIを使うとグローバルな状態(何がBindされているか)が変化してしまうので、Direct State Access(DSA)を使う

でした。特にDirect State Accessは非常に重要で、パラメータ設定時に毎回glBind〜系のAPIを呼び出す苦悩から開放されます。

Direct State Access
https://www.khronos.org/opengl/wiki/Direct_State_Access

OpenGL 4.5でDirect State Accessの導入に伴って、OpenGL Objectに対するDSA版のAPIが新たに一式追加されたのですが、DSAではない元のAPIとの名前の対応が本当に意味不明で辛いです…また、glGen〜系呼び出すOpenGL Objectの場合、DSAを使用するためにはglCreate〜系のAPIを呼び出す必要がある点にも注意が必要です。

Texture、Framebuffer、Bufferオブジェクトに対するDSAのやり方は、こちらのページ(A Guide to Modern OpenGL Functions)が本当に参考になりました。また、同ページには他にも新しいOpenGL APIを使った実装についての記述がたくさん含まれているので、是非読んでいただくと良いと思います。

OpenGLとOpenCVとの相互運用について

もちろんOpenCVにもCUDAやOpenCLのモジュールがあって、GPUを活用した実装が可能になっています。必要な機能が既にそこに実装されているのであれば、まずはそれを使うのが良いと思います。しかし、いくつかの処理を組み合わせたり、一部CPUで処理を行おうとすると、GPGPUではどうしてもCPU/GPU間のコピーがボトルネックになりがちです。一方、OpenGL + GLSLを使ってシェーダーで処理を書けば、レンダリングパイプラインをつかった処理を比較的簡単に柔軟に記述することができます。

また、OpenCVのcv::ogl名前空間には、OpenGLとの相互利用のためのクラスが提供されていますが、ROSのOpenCVではオプションが有効になっていなかったのと、ドキュメントにGTKとQtバックエンドのみ対応と書かれていたので、今回の用途には使えなさそうでした。

OpenCVのCIELab色空間変換とガンマ補正について

今回、GLSL内でRGBからCIELab色空間への変換を実装する際に、OpenCVのドキュメントを参考にして実装しました。ドキュメントには線形RGB -> XYZ -> CIELabと変換する際の式が書いてあり、GLSL内にこれを実装することで、GPUを使ったCIELab色空間への変換が可能になります。入力テクスチャをSRGBフォーマットに指定しておけば、シェーダー実行前に自動的にSRGB -> RGBの変換は自動的に行われるので、GLSLで実装する場合にはドキュメントの式をそのまま実装して問題ありません。

ところが、1点注意しなくてはいけない落とし穴があります… 実はOpenCVのcvtColorにcv::COLOR_BGR2Labを設定して変換した場合、このドキュメント通りの変換は行われません。cv::COLOR_BGR2Labは入力をSRGBとして解釈し、ガンマ補正を戻して線形RGBに変換してからドキュメントの式を適用するためです。

リリースノートによるとどうやらこのあたりの挙動はOpenCV 2.2のリリース時に変化したらしく、以前はcv::COLOR_BGR2Labはちゃんとドキュメント通りの変換を行っていたのですが、現在は入力をSRGBとして解釈しているようです。従来通りの線形RGBに対する変換は、cv::COLOR_LBGR2Labを使えと書いてあります。

用語まとめメモ

X Window System ... ウィンドウ管理システムの仕様
X11 ... X Window Systemで使われるプロトコル
libX ... X Window Systemのクライアントのリファレンス実装
libXCB ... libXの低レイヤーが分離されたもの
Xorg ... X Window Systemのサーバーのリファレンス実装
DIX ... Driver Independent X、Xorgのグラフィクスサブシステム
DDX ... Driver Dependent X、Xorgのグラフィクスサブシステム
fglrx ... FireGL and Radeon for X、AMDのプロプライエタリなlibGL実装
OpenGLES ... OpenGL Embedded System、OpenGLの組み込み向けプロファイル
GLX/WGL ... X Window System / Windows向けのOpenGL拡張API、libGL.soに含まれる、プラットフォーム固有のウィンドウシステムで作成したフレームバッファを使用するために作られたAPI
AIGLX ... Accelerated Indirect GLX、X11を通してOpenGLを使うAPI？
EGL ... GLX/WGLを置き換えるプラットフォーム非依存のOpenGL Context構築用API、間違えられやすいがGLX/WGLのような特定プラットフォームに依存した拡張ではないし、GLUT/GLFWのようなそれらの上にあるライブラリでもない

遅ればせながら自作キーボードデビューしました

noreply@blogger.com (Kazuyuki Arimatsu) — Fri, 15 Feb 2019 16:48:00 +0000

最近自作キーボードが熱いですね！技術書典でキーボード島の熱気を横目に見ながら、面白そうなことやってるなぁと、つい最近まで傍観に徹していました。

というのも、自分は10年以上Thinkpadのキーボードを使い続けていているせいでTrackpointがないと生きていけないと思っていましたし、何よりJIS配列が手に染み付いているので英字配列のキーボードにはどうにも抵抗があってなかなか手が出せずに居ました。

そんな中、先日キーボード沼に一足先に浸かっていた @hecomi さんから自作キーボードについて熱く語られた上、断る理由を全て論破されてしまったので、ここはひとつデビューしてみることにしました。

※Trackpointは後付可能だし、基板を起こせばトラックボールやタッチパットだってつけられる！
※キーマップはQMKで自由自在にいじれるし、基板を起こせばキー配置だって自由自在、キートップだって既成品の108キートップにバリエーションがないなら作ってしまえば良いじゃない！

--

で、先日ついに初めての自作キーボードを完成させました！

初めての自作キーボードに選んだのは、@omkbd さんの、ErgoDash(親指あり)です！　

もともと左右分割キーボードに興味があり、親指シフトなどの親指に仕事を割り振るようなキーボードも触ってみたいと思っていたのでセパレート型のキーボードで良いのがないかを探していました。また、Ortholinear配列は親指周りが窮屈そうな見た目だったので、親指部が独立しているColumn Staggered配列なキーボードに狙いを絞りました。

探し始めた当初は慣れ親しんだThinkpadのパンタグラフ式キーボードに近いLow Profileのスイッチが使えるキーボードを物色していたのですが、

Iris Keyboard (v2.5 Low Profile対応) ... 在庫切れ ※keeb.ioのTrello によるともうすぐ3.0が出るらしい
Lily58 Pro ... 在庫切れ ※春節の影響で基板の発送が遅れているとか…
Corne Chocolate ... 2019年2月14日発売

と、Low Profileのセパレートキーボードは手に入るものがありませんでした。
また、Corne Chocolateはキー配置が同じCorne Cherryを遊舎工房さんの店頭で試し打ちしたところ、存在しない数字キー行の文字をタイプしようとして指が空を切ることに衝撃を受け(特に'-'キー)、いきなり40%キーボードはハードルが高すぎるのではないかと考えなおしてしまいました。

また、Kailhロープロファイルスイッチは全高こそ低いのですがストロークは3.0mmと通常スイッチと比較して0.5mmしか変わっておらず、また動作点は1.5mmとなっておりKailh Speedスイッチのほうが動作点は短くなっています。

実際に遊舎工房さんの店舗で触ってみた感じでも、そこまでロープロファイルスイッチにこだわらなくても良いかな？と思ったので、結局その場で在庫のあったErgoDashを購入しました。

--

組み立て

組み立てにあたって購入した部品のリストは以下のような感じになります。ErgoDashのキットにはPro Microは同梱されているのですが、Type Cのコネクタが良かったので最近出たPro Micro互換のElite-Cを店舗で同時に購入し、それを使って組み立てを行いました。

購入場所	品名	値段	備考
遊舎工房	ErgoDash 親指あり	14,040円	初めての自作キーボード
遊舎工房	Kailh Speed Copperスイッチ 70個	3,010円	パンタグラフっぽい打ち心地を目指してこれにしてみました
遊舎工房	Elite-C 2個	5,184円	ちょっとお高いですが、USB Type-Cのためです…
遊舎工房	BigBang キーキャップ	7,020円	見た目が気に入っているのでこれにしました
千石電商	3mm LED 電球色 80個	3,200円	キーキャップの色味に合わせるならこの色かなぁと
千石電商	200Ω チップ抵抗(3216) 100個	400円	ビルドガイドでは470Ωですが、明るくしたかったので…
千石電商	1kΩ チップ抵抗(3216) 10個	50円
千石電商	TRRSプラグ 2個	600円	見た目で選びました
秋月電子	Nch チップMOSFET 10個	240円
秋月電子	WS2812B 30個	1,080円	※注
合計		34,824円	Elite-Cがちょっと高かったですね… それを除けば30,000円に収まります

※似た名前のWS2812Sという製品を千石で取り扱っていますが、互換性がないので注意してください！！

バックライト用LEDの抵抗は公式のパーツ表では470Ωとなっていますが、これだと購入したLEDには4mAしか電流が流れず暗い気がしたので、抵抗を200Ωにして流れる電流を10mAまで増やしました。
※消費電力的には全てのLEDを点灯した状態で両手で1A程度なのでまぁ良いかという程度なんですが、バックライトLEDのドライブ用FETが非常に小型なのでちょっと心配です。常時運用するのであれば少しバックライトLEDの輝度を下げた状態にしておいたほうがよいかもしれません。

組み立てにあたっては、まずElite-C取り付け時にType-Cコネクタが干渉する部分の基板を削ります。組み立てた時の厚みが増えても大丈夫な場合はスペーサーを延長しても良いですし、Elite-Cを本来付ける位置と逆側に表向きに取り付けて、アクリル板側を削ることもできると思います。

PCBを削った場合には、この部分に右手のRGB LEDのシリアルが通っていますので、そこの部分の配線もなくなってしまいます。ただ、左手マスターで組む場合には右手のRGB LEDはTRRSジャックから来たシリアルで光るので、左手マスターで組む場合には特に何もする必要はないと思います。右手マスターで組む時だけ、以下のようにD3ピンをジャンパで繋ぐ必要があります。

また、Elite-Cにもともと付いているリセットスイッチは組み立てた時に裏側に取り付けるキースイッチと干渉してしまうので、予め剥がしておきます。剥がしたスイッチを再利用する必要はないと思いますので、パターンを剥がさないように注意しながら、鋭いニッパーでスイッチを破壊して、最後にはんだごてでランドを外せば簡単に剥がすことができます。

　

その他の点については、公式のビルドガイドに沿って組み立てればOKです！

組み立てが終わったらqmkのファームウェアを書き込みます。
Elite-Cへの書き込みの際には、`rules.mk`のBOOTLOADERのところを

BOOTLOADER = atmel-dfu

に変更して、基板をUSBでPCに接続した状態で、基板に付いているリセットボタンを押したら

make ergodash/rev2:default:dfu

で書込みできます。

※個人的にハマったこととしては、せっかくLEDを頑張ってつけたのでバックライトLEDのほうも明るさを自動で変更したりしたかったのですが、残念ながら`BACKLIGHT_BREATHING`はマスター側のバックライトの明るさしか変更することができないようです…　
※仕方ないので、今はRGBライトの方のモードをBREATHINGにして我慢しています

少しだけ残念だったのは、保護紙を剥がした際に両手ともここの部分のアクリルにヒビが入っていたところでしょうか…
※どの段階で入ったものなのかは分かりません…

まぁ力がかかる部分ではないのでアクリサンデーで接着した上で組み立て、もし見た目が気になるようであればレーザーカッターで切り直すことにしました。

--

キーマップの設定

キーマップは日本語JIS配列に合わせて、以下のように作成しました。
※keymap_jp.hをインクルードしてわかりやすい識別子で日本語キーを定義しています

  /* Qwerty
   * ,--------------------------------------------------------------------------------------------------------------------------------------------------.
   * | ZHTG(GUI) |   1  |   2  |   3   |   4  |   5       |   ^   |                      |   \   |   6       |   7  |   8   |   9  |   0  |  -          |
   * |-----------+------+------+-------+------+-----------+-------+----------------------+-------+-----------+------+-------+------+------+-------------|
   * | Tab       |   Q  |   W  |   E   |   R  |   T       |   [   |                      |   ]   |   Y       |   U  |   I   |   O  |   P  |  @          |
   * |-----------+------+------+-------+------+-----------+-------+----------------------+-------+-----------+------+-------+------+------+-------------|
   * | Esc(Ctrl) |   A  |   S  |   D   |   F  |   G       | PrtSc |                      |       |   H       |   J  |   K   |   L  |   ;  |  :          |
   * |-----------+------+------+-------+------+-----------+-------+----------------------+-------+-----------+------+-------+------+------+-------------|
   * | Shift     |   Z  |   X  |   C   |   V  |   B       | Raise |                      | Lower |   N       |   M  |   ,   |   .  |   /  |  \(Shift)   |
   * |-----------+------+------+-------+------+-----------+-------+-------+------+-------+-------+-----------+------+-------+------+------+-------------|
   * |           |      |      | LOWER |||||||| Bksp(Alt) | Space |  LClk ||||||||  RClk | Enter | Del(Ctrl) |||||||| RAISE |      |      |             |
   * ,-------------------------------------------------------------------------------------------------------------------------------------------------.
   */
  [_QWERTY] = LAYOUT( \
    GUI_T(JP_ZHTG) , KC_1   , KC_2   , KC_3   , KC_4   , KC_5           , JP_CIRC,                         JP_YEN , KC_6           , KC_7   , KC_8   , KC_9   , KC_0   , KC_MINS        , \
    KC_TAB         , KC_Q   , KC_W   , KC_E   , KC_R   , KC_T           , JP_LBRC,                         JP_RBRC, KC_Y           , KC_U   , KC_I   , KC_O   , KC_P   , JP_AT          , \
    LCTL_T(KC_ESC) , KC_A   , KC_S   , KC_D   , KC_F   , KC_G           , KC_PSCR,                         XXXXXXX, KC_H           , KC_J   , KC_K   , KC_L   , KC_SCLN, JP_COLN        , \
    KC_LSFT        , KC_Z   , KC_X   , KC_C   , KC_V   , KC_B           , RAISE  ,                         LOWER  , KC_N           , KC_M   , KC_COMM, KC_DOT , KC_SLSH, RSFT_T(JP_BSLS), \
    XXXXXXX        , XXXXXXX, XXXXXXX, LOWER  ,          LALT_T(KC_BSPC), KC_SPC , KC_BTN1,       KC_BTN2, KC_ENT , RCTL_T(KC_DEL) ,          RAISE  , XXXXXXX, XXXXXXX, XXXXXXX          \
  ),

自分がハマった注意点としては、MT_マクロ(キーの長押しと短押しでキーアサインを変える設定)は、Modifierキー(Ctrl, Shift, Alt, GUI)にしか使えないというところでしょうか…
特にエラーは出ずにビルドが通ってしまうので、勘違いしたまま`俺が考えたさいきょうのキーマップ`を作成してしまうと、後で動かないことに気づいて考えなおすことになります。※なりました

なるべく親指に仕事を割り振りつつ、MT機能を使ってなるべく多くのキーをJIS配列から崩さずにデフォルトレイヤーに入れたつもりです。他のレイヤーについてはマウスキーを入れたぐらいで、ほとんど変えておらず、あまりLower/Raiseキーは使いこなせていません…

正直、組み立てにかけた時間よりもキーマップをいじくり回している時間のほうが長かったかもしれないです。まだ自分の中でしっくりきてない部分もあるので、試行錯誤中ですね… これは沼の予感がします…

--

EndGameに向けて

今使っているのはMDAプロファイルのBigBangですけど、やっぱりもう少し高さが低いキーキャップが欲しいと思っています。いくつかMDAより薄いプロファイルのものもあるようなので、いくつか買って試してみますかね…(沼)
※もしくはやっぱりLow Profileで組んで、射出成形で好みのキーキャップを作るとかでしょうか…

Thinkpadのキーボードと併用しているとどうにも、キーのStaggerd方向が違うので指が混乱しがちで、キーの間をタイプしてしまうことが結構あることがわかってきました…
ただし、親指キーは実際に使ってみて非常に便利なので、もしかするとRow Staggeredな親指キーボードが次のEndGame候補になるかもしれないですね…(沼)

後はやっぱりThinkpadトラックポイント愛用者としてはキーボードから指を離さずにマウス操作ができるようになりたいです… 今はマウスキーを使ってHJKLでマウスカーソルを動かしているのですが、どうにもしっくりこないので、ダメそうだったら小さいトラックボールかタッチパッドを付けたいですね… ただ良いデバイスが見つかっていないので、継続的に探していく必要がありそうです(沼)

--

この記事はErgoDash (親指あり; Kailh Speed Copper)で書かれました。

ドローンにJetson TX2を載せて自律制御する (ハードウェア準備編)

noreply@blogger.com (Kazuyuki Arimatsu) — Sat, 29 Dec 2018 06:37:00 +0000

Project C.G.S.では、現在次期大会に向けてドローンの機体制作を行っています。

※残念ながらドローンの開発とUnityは特に関係ありません

MBZIRC 2017に参加した機体ではコンパニオンコンピュータにHardkernelのOdroid XU4を使用していたのですが、計算資源に余裕がなく、あまり複雑な認識処理を行うことができなかったので、MBZIRC 2020に向けて制作している機体ではNVIDIAのJetson TX2を使用することにしました。

※最近、NVIDIAからはJetson TX2iやAGX Xavierなどの新しいボードが出ていますが、(キャンペーンで開発キットが定価の半額で購入できる)Jetson TX2もコスパという意味では負けていません。

Jetson TX2をドローンに搭載しようと思った際に問題になるのが、どのキャリアボードを使用するかだと思います。AGX Xavierなどは純正のキャリアボード十分小さいのでそのまま乗せれば良いのですが、Jetson TX2の純正キャリアボードは拡張性が高い代わりに非常に大きく(Mini-ITXサイズ)、そのままでは到底ドローンに搭載することはできません。

そこで、各社から発売されているキャリアボードにJetson TX2を載せ替える必要があるのですが、様々な会社が多種多様なキャリアボードを出しており、用途に合わせて選定するのがけっこう大変です…

Project C.G.S.では、今回の用途に合わせて、

ドローンに載せられるサイズである
MIPI CSIインターフェースでカメラを接続することができる
mSATAかm2でSSDを接続することができる

という3つの条件でボードを選定しました。

Jetson TX2は組み込みビジョン用途を非常に強く意識しているのか、なんとMIPI CSIを6本まで入れることができるようになっています。USB経由でカメラを接続するよりも、MIPI CSIの内蔵ハードウェアブロックを使ったほうがオーバーヘッドが少ないですし、JetsonにはもともとUSBポートが少ないので、カメラを多数積むのであればMIPI CSIインターフェースは必須です。また、自律制御アルゴリズムの開発時には実際に飛ばしながらカメラ画像をロギングする必要があるのですが、Jetson TX2のmicroSDインターフェースはUHS-Iにしか対応しておらず、カメラ画を記録するのは書き込み速度的に非常に難しいです。なので、ログを書き込むためのSSDを接続する必要があります。

※ただし、Jetson TX2はSATA2にしか対応していないので、SSDを接続した場合でも書き込み速度には上限があります。もし、更に高速にログを書き込む必要であれば、PCIeにNVMeのSSDを接続する必要があるかもしれません。

前提を踏まえてボードを列挙すると、現時点では

メーカー	型番	ボードのサイズ[mm]	MIPI CSI	mSATA/PCIe	値段
Connect Tech	Spacely Carrier	125x95	x6(IPEX 30pin)	mSATA x1、miniPCIe x1	¥156,750(日本代理店)
Colorado Engineering	X-Carrier	87x71	x6(純正カメラコネクタ*1)	mSATA x1、x4 PCIe x1	$399
Aetina	ACE-N310-A	87x70	x6(純正カメラコネクタ*2)	mSATA x1	$240

*1 Jetson純正の開発ボードと同じカメラ用のコネクタが搭載されています。

*2 Jetson純正の開発ボードと同じカメラ用のコネクタが搭載されていますが、サイズが小さいボードしか接続できず、固定用の穴位置も異なります。

あたりが候補に登ります。Spacelyは流石に高すぎて(Jetson TX2開発キットの定価の2倍)腹が立ったので候補から外しました。次にX-CarrierとACE-N310-Aで検討していたのですが、X-Carrierが在庫切れで納期が遅かったので、結局Aetina ACE-N310-Aを購入しました。

Aetina ACE-N310-Aを購入したのは良いのですが、すでに購入していたLeopard ImagingのMIPI CSIカメラボード(LI-JTX1-MIPI-ADPT-6CAM)を取り付けようとしたところ、実はACE-N310-Aのカメラコネクタに接続できるボードのサイズに制約があることがわかりました。

これ、カメラボードを接続しようとするとヒートシンクと基板が干渉してしまって取り付けられません… そもそも穴位置も合わないですし、このコネクタは基本的にAetinaがオプション別売りで出している"6 x MIPI CSI-II Camera Board"を取り付ける前提で設計されているようです。

※ただしこのCamera BoardのコネクタはFPCなので、これに手持ちのLeopard Imagingのカメラ(IPEX 30pin)を接続することはできません。

購入前にAetinaのサポートにJetson TX2開発キットのカメラコネクタと互換があることは確認していたのですが、こんな罠があるとは…

そこで、なんとかカメラコネクタにボードを取り付けるべく、下駄基板を自作しました。

この基板を使うことで、Leopard Imagingのカメラボードをオフセットして取り付けることができ、無事に接続することができました。

以上、ドローンにJetson TX2を載せて自動制御する (ハードウェア準備編)でした。

後日、Jetson TX2にROSをセットアップする、ソフトウェア準備編を公開予定です。

備考1: rosbag書き込み速度の実測値

Jetson TX2を純正のキャリアボードに接続して、rosbagに画像を記録した実測値は以下のようになりました。テスト用にRealSense D435のcolor、infra1、infra2、depthのVGA画像4つをrosbagに保存し、rosbagに記録できたサイズを時間で割ったものです。

ストレージ	インターフェース	書き込み速度
microSD Samsung PRO Plus 64GB	UHS-I	18.1 MB/s
SATA SSD CSSD-S6T128NHG5Q 128GB	SATA2	36.9 MB/s

※どちらの場合も全データを保存できておらず、ストレージ書き込み速度で頭打ちになっています。

RGBのVGAで30FPSだと約27MB/sなので、rawで保存した場合microSDでは書き込みが間に合わないです。2カメラ以上保存する場合にはSSDでも間に合わないので、圧縮して保存する必要がありそうです。

備考2: MIPI CSIカメラについて

MIPI CSIは通信の規格を定めているだけで、コネクタについては規定がありません。そのため、各社が独自にいろんなコネクタのモジュールを作っており、互換性が全くありません。Jetson用のキャリアボードも当然各社が独自に様々なコネクタのボードを作っているので、一般的に他社の別のボードのカメラを流用することは難しいです。

流石にこれはまずいと思ったのか、比較的新しいキャリアボードはJetson純正の開発ボードが採用しているカメラコネクタをキャリアボードに搭載し、Jetson純正開発ボード向けのMIPIカメラを流用できるような設計になっています。また、AGX Xavierも同じコネクタを搭載しているので、このコネクタが搭載されているMIPIカメラを使用しておけば、TX2からXavierに乗り換えてもカメラを使い回すことができます。

Ali ExpressのBest Carbonにカーボン加工を外注してみた

noreply@blogger.com (Kazuyuki Arimatsu) — Sat, 01 Sep 2018 01:54:00 +0000

Project C.G.S.では、現在次期大会に向けてドローンの機体制作を行っています。

ベースには市販のフレームを使用しているのですが、限られたスペースになるべく多くのセンサを搭載するため、汎用品で対応できない部分は独自に設計した自作パーツを使用します。

負荷がかからない部分は3Dプリンタなどで成型したパーツで十分なのですが、力がかかるところ、壊れると致命的な部分は、軽くて丈夫なカーボンでパーツを作るのが理想的です。

前年までは、カーボンの切り出しはメイカースペースのCNCを使って自分たちの手で行っていたのですが、

- カーボンの材料費が高い
- エンドミルがすぐ摩耗して切れなくなるので、エンドミルの費用も馬鹿にならない
- 切子が飛ばないように切削油に沈めて加工するので、加工に手間と時間がかかる

という問題があったので、今回はカーボンの加工を外注することにしました。

作成したパーツ

外注先は(国内よりは中国の会社のほうが安いイメージがあったので)、Ali ExpressのBest CarbonにCarbon Fiber Plate CNC Cutting Serviceをお願いすることにしました。

--

ページの冒頭にも書いてあるのですが、注文方法がちょっと特殊になっています。

注文するにはAli Expressで商品をカートに入れる前に、

carbonfiber (AT) foxmail.com

にメールします。

本文には材料のカーボンの厚み、織り方、表面処理方法、発送方法を記入して、作りたいパーツの図面をdxfで添付します。

Hello BEST CARBON team,

I have looked at your "Carbon Fiber Plate CNC Cutting service" page on AliExpress.
I would like to order cutting 4 pieces of plate of attached DXF file,
using plain mat carbon plate of 2mm thickness.
I also would like to use 7 days arrival shipping method to Japan.

Could you give me an estimate of the total cost for this?

Best regards,
xxx

すると、こんな感じで返信が返ってきます。

Hi xxx ,

USD 12/pcs
4 pcs
EMS shiping - USD 20

Total USD 68

この時点で、Ali Expressのページに行くと、単価がUS $1.00 / pieceになっているので
指定された金額なるようにQuantityを入力して(この場合は68個)、Ali Expressから購入します。
※注文時に選択するShipping MethodはFree Shippingで大丈夫です

購入が済んだらメールで連絡

Hello xxx,

OK, I would like to place an order with that price.
I have purchased on AliExpress page.

Thank you.

すれば、注文から1週間ぐらいで発送してくれます。

--

EMSで発送された荷物はAli ExpressのMy OrdersからTrack Orderで追跡することができるのですが、更新が遅くてイマイチ使いにくいので、日本郵便のページにトラッキング番号を入力して調べたほうが確実です。
※中国側のトラッキング番号(EVBxxxxxxxxxCN)を入力してもちゃんと結果が出てきます。

商品はこんな感じで梱包されて届きました。

端面はちょっとバリが出ていますが、2mmの細溝も綺麗に切削できていますし、品質には満足です。

注文から到着まで2週間かかるので、自分で加工するのと比較すると少し時間はかかりますが、このような形で簡単にカーボン加工を簡単に依頼することができるので、ぜひ利用してみてはいかがでしょうか。

海外プロポ Taranis Q X7Sを日本で合法に使用する

noreply@blogger.com (Kazuyuki Arimatsu) — Mon, 06 Aug 2018 14:48:00 +0000

ドローンを飛ばし始めたときからずっとプロポにはTurnigyの9XR PRO(これも海外プロポです)を使ってきたのですが、定期的に電源スイッチが固着したりして電源が入らなくなるのに悩まされていました。

先日、また9XR PROの電源が入らなくなったので、良い機会だと思い、Taranis Q X7Sを購入しました！

9XR PROの頃からファームウェアにはOpen TXを使っていてとても便利なので、それに対応したプロポの中で候補を探していました。といっても、OpenTXが対応している新しいプロポはFrskyのTaranisかHorusしかなく、その中でお手頃価格で買えるものとなると結構数が絞られてきます。その中で、磁気式のジンバルが面白そうだったのでこの機種にしました。
※ジンバル単体でも購入できるので、X7などのプロポを購入してジンバルを交換しても良かったのですが、見た目が気に入ったのでX7Sにしました

ところが、このプロポは技適を通っておらず、そのまま日本で使った場合には電波法違反になってしまいます。

※電波法違反のプロポを使用した場合、事故が発生したときにラジコン保険が下りない可能性があります

そこで、Taranis Q X7Sを日本で合法で使用するために、以下の作業を行いました。

アンテナの取り外し
技適取得済みの外部送信モジュールを装着
外部送信モジュールを使用するように設定

アンテナの取り外し

まず、バッテリと外部送信モジュール用の蓋を外したら、ネジを4つ外して裏蓋を開けます。

※詳細な分解方法はこの動画などが参考になると思います

裏蓋を開けたらアンテナの配線を外し、

アンテナを筐体から外します。

設定からInternal RFを無効にすることもできるので、アンテナを無理に外さなくても良いと思います。
※かなり固いので、もし外す場合は筐体を割らないように注意してください

ラジオペンチを2本使って、筐体ごと挟んでアンテナの根本押し込むようにすると外れやすいかもしれません。

ついでに、必要であればジンバルのフィーリングの調整も行います。Taranis Q X7Sはデフォルトではスロットルスティックを動かすとカチカチとクリック感があるので、それが不要な場合はこのネジを少し緩めます。

隣のネジで摩擦も調整できるので、好みの硬さに合わせます。

技適取得済みの外部送信モジュールを装着

配線を挟まないように裏蓋を戻したら、技適マークがついた送信機モジュールをはめ込みます。

この外部送信モジュールはWorld RCから購入したFrsky D8Tです。

JR PROPOに対応したものであれば使えると思いますが、もうあまり取り扱っている店舗はないかもしれませんね...
合法で使用する上で一番難易度が高いのが、この外部通信モジュールの入手かもしれません…

外部送信モジュールを使用するように設定

次に、メインスイッチを長押しして起動します。

これ、短く押すと一瞬だけ電源が入って落ちるように見えるので、買った直後は何が起きているのかわからず困りました。

長押しで起動、長押しでシャットダウン
ヨーとロールのトリム内側にして短押しでファームウェア書き込みモードで起動

のようです。

プロポが起動したら、オプションボタンを短押しして、Page 2の設定から

Internal RF	OFF
External RF	PPM

にします。使用する外部送信モジュールによって、PPM以外のモードを選択しても良いと思います。
※External RFを有効にした時点でモジュールへの電源供給が行われるようです

この設定はモデルごとにする必要があるので、新規にモデルを作った際には忘れずに変更する必要があります。

ここまでで、Taranis Q X7Sを合法で使用するために必要な作業は終わりです。

おまけ1 - ファームウェアの更新とmicro SDのセットアップ

とりあえずファームウェアは最新のものに更新しておきます。また、micro SDカードを用意して必要なデータを書き込むと、プロポがしゃべるようになるので、そちらの設定も行います。

ファームウェアの更新はOpenTX Companionから行うので、まずは自分のOSで動作するOpenTX Companionをインストールします。

UbuntuならLaunchpadからamd64のパッケージをダウンロードしてインストールして、

companion22

で起動します。

※Write Firmwareの前に必ずRead Firmwareして、今のファームウェアのバックアップを取っておきましょう

microSDカードに書き込んで、Taranis Q X7Sの下面についているスロットに入れればOKです。

おまけ2 - FPVシミュレータでTaranis Q X7Sを使用する

Taranis Q X7Sの大きなメリットとして、USBでPCに接続するとジョイスティックとして使うことができるというものがあります。

9XR PROではこの機能がなく、今までシミュレータでプロポを使うときにはTrainer信号を変換するUSBアダプタ経由でPCに接続していたのですが、Taranis Q X7Sではその煩わしさから開放されます！

USBコントローラーでプレイできるクアドコプターのシミュレータの中で、安価で楽しめるものの筆頭にFPV Freeriderがあると思います。
FPV FreeriderでTaranis Q X7Sを使用する際には、プロポ側で設定を変更しないとController Calibrationがうまくいかないので注意が必要です。

まず、プロポ側に適当なモデルを作ったらRFをOFFにして、

カーブの設定で値が50 - 100にマップされるようなものを作ったら、

それをすべてのミキサーの出力に割り当てます。

これで、すべてのスティックの値が、50から100にマップされます。
※ミキサーをひとつずつ開いて、オフセットとウェイトを50に変更しても大丈夫です。

※詳細な設定については、この動画が詳しいです

このモデルを使用してFPV Freeriderをプレイすれば、きちんとUSB Calibrationができるようになります。FPV Freeriderで実際にFPVでプレイすると、こんな感じになります。

※残念ながら、まだ全然うまくないです…

とてもリアルでおすすめですし、カメラ画角等も自分の(実際の)機体に合わせて変更することができるので練習に役立ちます！

MavESP8266をESP-WROOM-02に焼いてPixhawkとWifiで通信する

noreply@blogger.com (Kazuyuki Arimatsu) — Wed, 25 Jul 2018 15:14:00 +0000

Project C.G.S.は、MBZIRC 2020年度大会も無事に書類選考を追加しました！

2017年度大会に参加した機体ではペイロードが小さく、今より処理能力の高いボードを載せたり、重い物体を運搬したりするのは難しいので、現在Project C.G.S.では、2020年度大会用の機体を作成しています。

一般的にドローンを自作する場合には、機体を組み立てた後に、機体がうまく飛行できるようにパラメータを調整する作業が待っています。これには機体を手で持ってぐるぐる回したり、少しずつパラメータを変えながら実際に飛ばしたりする作業が必要なのですが、大きいドローンになると指示に従って機体をぐるぐる回すのも一苦労ですし、パラメータ調整のたびにいちいちUSBケーブルを接続するのは非常に面倒です。

なので、やはりパラメータの設定などは無線で通信したいものです。少し前にPX4ファミリーに加わったPixracerはなんとESP8266を使ったWifiモジュールがバンドルされており、これを使えばそのままWifiでQGCと接続することができちゃいます。また、このモジュールを接続すれば、Pixracerに限らずPixhawkなどでもWifi経由で接続することができるようになっています。

ところがここで問題がひとつ... 付属のモジュールは技適認証を受けておらず、日本国内で自由に使うことはできないのです！

そこで、この記事ではESP8266用のファームを技適認証を受けているESP-WROOM-02に書き込み、合法にWifi接続する方法を紹介します(と言っても普通に書き込むだけなのですが...)。

ファームウェアの書き込み

まずは、ESP-WROOM-02(スイッチサイエンスで扱っているピッチ変換基板に実装したもの)を書き込みモードにしてPCと接続します。接続には秋月電子のFT232RL USBシリアル変換モジュールを使いました。

ESP-WROOM-02への書き込み

ESP-WROOM-02は3.3Vで動作しますので、変換モジュールの出力が3.3Vになるようにジャンパピンを設定するのを忘れないでください。

J1	1-2間ショート
J2	ショート

※念の為、ESP-WROOM-02に接続する前にVIOの電圧が3.3Vになっていることを確認してください

ESP-WROOM-02のピンと、変換モジュールとの結線はこちらのスライドの情報を参考に行い、ESP-WROOM-02がUART Download Modeになるように行います。

IO0をGNDにショートしています

ESP-WROOM-02	AE-UE232R
3V3	VIO
IO15	GND
IO2	VIO
IO0	GND
TX	RX
RX	TX
GND	GND

この状態で、Githubレポジトリの手順に従ってファームウェアのビルドと書き込みを行います。
※ビルド済みバイナリをesptoolで書き込んでみたのですが、残念ながら動作しませんでした… esp12e向けにビルドしたものでないと動作しないのかもしれません

まずは

sudo pip2 install platformio

でplatformioをインストールしたら、mavesp8266のレポジトリで

platformio run -e esp12e -t upload

でファームウェアのビルドと書き込みをします。
書き込みが終わったらIO0をプルアップに変えて、

IO0をVCCにショートしています

※MavESP8266はGPIO2がGNDに落ちていると設定されているコンフィグをリセットしますので、IO2はGNDに落とさないように注意してください。

PixhawkのTELEM2に繋ぎます。

Pixhawkとの接続

このとき、PixhawkのTELEM2の電源は5Vになっているので、間にレギュレータを挟んでESP-WROOM-02に供給される電圧が3.3Vになるようにしてください。

ボーレートの設定

Pixracerの場合はESP8266用のWifi Serialは921600ボーに設定されているのでこのままで通信できますが、Pixhawkの場合は使うTELEMのボーレートを921600に変更する必要があります。

PixhawkをUSBでQGroundControlと接続し、この公式ページを参考にPARAMETERのSYS_COMPANIONの値を`ESP8266 (921600 baud, 8N1)`に変更します。
※MavESP8266側のWebUIでボーレートをPixhawk側に、合わせる方法もありますが、57600ボーだとQGCでのパラメータのグラフ表示が残念なカクカク具合になるので、こちらの方法をおすすめします。

Pixhawkの電源を入れるとESP-WROOM-02のアクセスポイント(Pixracer)が見えるので、ノートパソコンでアクセスポイントに接続し、QGroundControlを立ち上げると自動で無線で接続されます。😄

その他

今回は、

PX4	Firmware v1.8.0
MavESP8266	610f4be5
QGroundControl	v3.3.2

で動作することを確認しました。

技術書典4で頒布した「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」をBOOTHで再販開始しました

noreply@blogger.com (Kazuyuki Arimatsu) — Tue, 24 Apr 2018 03:50:00 +0000

先日開催された技術書オンリーイベント技術書典4に、社会人サークル「Project C.G.S.」として出展しました！

当日は「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」という、Project C.G.S. がつくばチャレンジを始めとするロボットコンテストへの参加に向けて行ってきた、地上を走る自律移動ロボット(UGV) とドローン(UAV) の開発に関する様々な記事を集めた内容の本を頒布していました。

ところが、初参加ということもあり印刷部数を絞りすぎてしまって、入場開始早々に完売してしまいました… せっかくブースに来ていただいたのに買えなかった方には、本当に申し訳ありませんでした…

当日もアナウンスしていましたが、この度

PDF版をBOOTHにて頒布開始致しました！

ので、買い逃してしまった方は是非、BOOTHから購入をご検討ください。
Project C.G.S.では今後共、ロボットに関するホットな情報発信を続けてまいりますので、引き続きよろしくお願いいたします。

技術書オンリーイベント技術書典4で「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」を頒布します！

noreply@blogger.com (Kazuyuki Arimatsu) — Wed, 18 Apr 2018 15:51:00 +0000

技術書オンリーイベント技術書典4に社会人サークル「Project C.G.S.」として出展します！

技術書典4は、4/22の11時から、秋葉原UDX アキバ・スクエアで開催される技術書オンリーの同人誌即売会です。Project C.G.S.は「け23」にブースを構えてます。
技術書典4のサークルページはこちらにありますので、もし良かったら当日ブースに来ていただけると嬉しいです。

頒布物は「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」という薄い本で、表紙はこんな感じになってます。

内容はProject C.G.S. がつくばチャレンジを始めとするロボットコンテストへの参加に向けて行ってきた、地上を走る自律移動ロボット(UGV) とドローン(UAV) の開発に関する様々な記事を集めた内容になっています。章ごとに著者が異なり、コンテストの参加録のようなものから、ハードウェア、ソフトウェアの実装に関する少し込み入った内容まで、雑多に詰め込まれたオムニバス形式になっております。

私は主に最初の導入と、「第3章実環境で動かすTensorFlow Object Detection API」を執筆しました。第3章では、市街地を自律走行する移動ロボット(※表紙のロボットです)にTensorFlow Object Detection APIを使った物体検出機能を実装して、つくばチャレンジ 2017というロボットコンテストで実際に走行させるまでの話を紹介しています。

もしよければお手にとっていただけると嬉しいです！

Ubuntu 16.04.3 LTSでROBOTIS Dynamixel SDKが通信に失敗する

noreply@blogger.com (Kazuyuki Arimatsu) — Wed, 27 Sep 2017 15:32:00 +0000

3行まとめ

Ubuntu 16.04.3を再インストールすると、Kernel 4.10が使用されます
Linux Kernel 4.10からFTDI USBシリアルドライバのデフォルトレイテンシタイマが1msから16msに変更されました
ROBOTIS Dynamixel SDKではシリアルドライバの設定値によらず、タイムアウトが固定値(1.x系では5ms)になっているので、通信に失敗します

--

Project C.G.S.というチーム名で、毎年自律移動ロボットコンテストつくばチャレンジに参加しています。

我々のチームでは環境の3次元マップを取得するためにTopURGというレーザーセンサを前後に振っているのですが、3年ほど前からそこの機構にRobotis Dynamixel MX-28というサーボを利用しています。

Capybara J.V. (つくばチャレンジ '16)

ところが先日、機体で使用しているUbuntuを再インストールしたところ、突然このMX-28が動かなくなるという問題が発生しました。

--

Dynamixel SDK からは

Dynamixel communication error : There is no status packet!

のようなエラーが返ってきており、どうもこれはタイムアウトが発生した際に返るエラーのようです。サーボや電気系統に問題はなく、またWindowsのツールからは正常に通信できていたので、Ubuntu側に何らかの問題があると判断しました。

このタイムアウトの値はDynamixel SDKのここで設定されており、3.x系のSDKではLATENCY_TIMER定数値をもとに設定されているようです。

USBシリアルのLatencyTimer設定値を疑い、setserialコマンドを使って

setserial /dev/ttyUSB0 low_latency

としたところ、通信エラーがなくなり、無事サーボが動くようになりました。

--

少し調べてみると、どうやらLinux Kernel 4.10で、FTDIのUSBシリアルドライバftdi_sioに、low latencyフラグを外すパッチが取り込まれていることがわかりました。

これにより、デフォルトのUSBシリアルのポーリングレートが1msから16msに変更されます。

Ubuntu 16.04.3からはLinux Kernel 4.10が使用されるので、この変更によりタイムアウトが発生するようになってしまった可能性が高そうです。

ROBOTISのgithubでもこの問題について言及されていて、udevルールに

ACTION=="add", SUBSYSTEM=="usb-serial", DRIVER=="ftdi_sio", ATTR{latency_timer}="1"

を、追加する対応が提案されています。

--

ロボット系ではUSBシリアルを使ってセンサ/アクチュエータと通信することが多いので、特にROSユーザーで心当たりのある方はudevルールへの追記を考えたほうが良いかもしれません…

--

追記 20170929

どうも、ROBOTIS Dynamixel SDKにLatency Timer関係でUbuntu 16.04.2の時も修正が入っているようですね…
我々は1.x系の古いSDKを使っていたので、こちらの方に引っかかっていたのかもしれません。いずれにせよudevルールの修正で解決できると思います。

かっこいいU199ドローンを作ってみた

noreply@blogger.com (Kazuyuki Arimatsu) — Fri, 19 May 2017 15:42:00 +0000

先日のアブダビでの事故で操縦技術の不足を痛感したので、ドローンの操縦技術を磨かねばと思いました。
で、どうせ練習するならドローンレース参戦に向けてやってみようとなったわけです。

日本で屋外でドローンを飛ばそうと思ったときには、改正航空法の規制を満たす必要があります。改正航空法では飛行禁止区域などの取り決めに加えて、目視外飛行(ゴーグルを覗いて操縦するなど)にも申請と許可が必要であると定められています（参考ページ）。

ただし、200g未満の機体に関してはこの制約を受けず、事前申請無しで目視外飛行を行うことができます。
※もちろん法律の規制を受けないからと言って、好き放題飛ばしてよいわけではありません
※土地の権利者が飛行を禁止していない区域で、周囲の安全に十分に配慮して飛行する必要があります。

この法律をうけて、日本では重量を200g未満に抑えたU199というカテゴリが誕生しました。

--

早速ですが、今回組み立てたU199はこんな感じになりました。頭が光ってます。
実はU199を組み立てるのは2機目で、今回はFPVの画質を頑張る方向で組んでみました。

組み立てたU199の写真

構成は以下の通りです。

Frame	Realacc Belix-3 130MM	Banggood
FC	HGLRC F4 FLAME	Banggood
ESC	Favourite FVT LittleBee-Spring 6A	Banggood
Motor	DYS BX1306 3100kv	Banggood
Prop	Gemfan Bull Nose 3030	Hobbyking
RX	FD800 Tiny FrSky receiver	Banggood
Camera	RunCam Owl Plus	Banggood
Battery	Turnigy BOLT V2 500mAh 3S	Hobbyking

この構成でeCalcでシミュレーションするとこんな感じです。

eCalc シミュレーション結果

フルスロットルのThrust-Weightは2:1なんでレース用って感じではないですけど、飛ばしやすいパラメータだと思います。カメラとVTXを軽くすればESCを変えて4sにできそうなので、慣れてきたら変えてみるかもしれません。

--

フレームは130クラスではかなり軽い方だと思います。
組み立てには付属のネジは全く使わず、超低頭のM3ネジと樹脂スペーサを使っています。

FCが面白くて、30mm規格のボードにPDB、BEC、OSDが一緒に載ってます。四隅にESC用の電源と信号が出ていて、使い勝手がいいですね。

FCと配線

このFCにXT30コネクタとブザーを直付けして、四隅からESCの配線、RXとカメラとVTXとLEDはコネクタを生やしてます。
※この線はもっと細くても良いかもしれないですね...

ESCにはDSHOT600に対応したBLHeli_Sが焼かれたものを使っています。Betaflightと組み合わせて使うと、FC経由でESCの設定が変更できるので非常にありがたいです。組み立て時にはひと通りESCとモーターを配線した後に回してみて、逆に回ったやつのESCをBLHeli Configuratorを使って逆転しています。

で、この上に、RX、カメラ、VTX、LEDを取り付けたものがくっつきます。

完成したU199

LEDについてなのですが、CleanFlightやBetaFlightはWS2812BというシリアルLEDに対応しています。なるべく小さいものを探していたところ、秋月電子にちょうどいいボード（マイコン内蔵RGBLEDモジュール）があったので購入してみたのですが、そのまま繋いだだけでは全く点灯しませんでした...

抵抗を外した秋月電子のWS2812B基板

どうもLEDのDINの前に入っている100Ω抵抗が悪さをしているようなので、ハンダごてで剥がしてジャンパを繋いだところ無事に点灯するようになりました。
やっぱりLEDがあるとエラーやARM/DISARMの状態が視覚的にわかるので良いですね。

上面と背面のところのパーツは、3Dプリンタを使ってABSで作りました。（STLファイル）

3Dプリンタでつくったマウンタ

LED、RX、VTXを載せた状態

ネジ穴のところにはM3インサート（HSB-304530）をハンダごてで押し込んでいます。3Dプリンタで作ったものにネジどめするときはだいたいこんな感じにしてるんですが、まぁまぁしっかり固定出来るのでおすすめです。

また、線材をはんだ付けした部分やコネクタの根本はBONDICで固めています。エポみたいに練らなくて良いし、4秒でカチカチに硬化するので、めっちゃ便利でおすすめです。

めっちゃ便利なBONDIC

--

最後にDVRで撮った初飛行動画を貼っておきます。

特に障害物もないところをぐるぐる回ってるだけなので、あんまり面白みもないですが...
今度はどこかのコースにお邪魔して、ゲートくぐりとかしたいですね。

P.S. 一緒に飛ばしてくれる人募集中です！

ロボットの世界大会、MBZIRC2017のドローン自律制御部門に出場してきました

noreply@blogger.com (Kazuyuki Arimatsu) — Sat, 01 Apr 2017 15:57:00 +0000

ロボットの世界大会、MBZIRC2017のドローン自律制御部門に、社会人サークルProject C.G.Sとして出場してきました。

思い返せば、かれこれ1年半ほどこの大会に向けて開発を続けてきました。チームとしてもUAVの自動制御は初の試みだったのもあり、並みいる有名大学や企業に混じって何とか出場に漕ぎ着けるので精一杯で、チャレンジの結果は非常に悔いの残る結果になってしまいました。

技術的には突飛なものを使っているわけではなく、特筆するべきアルゴリズムもないので技術ブログしてはコンテンツ不足ではあるのですが、この1年半のけじめをつける意味でもここにまとめを残しておこうと思います。

もしこの記事がこれからドローンの自律飛行を始める方の助けになれば幸いです。

出場した大会について

MBZIRC 2017はMohamed Bin Zayed International Robotics Challengeの名の通り、UAEの首都Abu Dahbi首長国の皇太子が主催したロボット大会です。

http://www.mbzirc.com/

大会はAbu DahbiのYas島にあるYas Marina Circuitにて行われました。
※正確にはサーキットの敷地内のCar Display Areaにネットで囲まれたアリーナが敷設され、そこでコンテストが行われました

各チームには電源、冷房完備のテントが割り当てられました。また、昼食や水の配布、ドラッグカーの余興付きのレセプションなど、参加費が無料なのにも関わらず非常に素晴らしい待遇を受けました。さすが石油王ですね！

大会は3つのチャレンジに分かれており、Project C.G.SはこのうちChallenge 1に出場しました。Challenge 1では、着陸ランドマークが描かれた鉄板を上に載せた自動車が8の字に走っており、その上にドローンを着陸させるまでの時間を競います。

大会としてはFPVなどを使った無線操縦も認められているのですが、我々のチームは得点の高い完全自律操縦にチャレンジしました。この場合、スタートの合図でロボットをスタートさせたあとは一切の手動オペレーションが認められず、ドローンは離陸、着陸ランドマークの探索、着陸アプローチ、着陸後にプロペラ停止までを全て自動で行います。

機体について

Project C.G.SではUAVの開発経験がなかったので、機体に関してはなるべく既製品を流用し、一般的な構成になるようにしました。

フレーム	Bumblebee Carbon Fiber Quadcopter Frame 550mm
ランディングギア	自作

フライトコントローラ	Pixhawk (PX4 Flight Stack 1.4.4)
受信機	Futaba R3008SB
ESC	ARRIS SIMONK 30A 2-6S OPTO
モーター	Sunnysky v2216 kv800
プロペラ	ATG1238 (APC 12x3.8SF相当品)
高度センサ	LidarLite v3
GPS	Ublox Neo-M8N GPS with Compass

コンパニオンコンピュータ	Odroid (Ubuntu 16.04)
USBシリアル変換	自作(PixhawkのTELEM2に接続)
USB無線LAN	ELECCOM WDC-433DU2HBK
カメラ	oCam-1MGN-U
電磁石コントローラ	自作(GPIOに接続)
電磁石	ZYE1-P20/15

PDB	Power Distribution Board with 2 x UBEC Output
DC-DC	Hobbyking HKU5 5V/5A UBEC
バッテリー x2	Multistar LiHV 5200mAh 3S 10C x2 (2並列)

この構成で20分ぐらい飛びます。ただslowflyの大きいプロペラを小さめのモーターで使っているのもあって、機体の動きは緩慢であまり応答性はよくありません。また位置制御のゲインも小さめにしていて、風のある環境では結構ふらふらしていました。

我々のソフトウェアはすべてROS上のノードとして構成されており、OdroidのCPU上で動作します。さすがに画像関係の処理はOdroidにとってかなり辛いようで、1280x960のカメラ画像を320x240にbinningしてrectify、HOG識別器でターゲットを認識する処理を5 Hzで動かすので精一杯でした。

また、これらの機能が最初から全てあったわけではなく、すべての機能が搭載されたのはかなりギリギリになってからでした。
特にカメラについては紆余曲折があり、アブダビ出発の2日前にカメラを載せ替え、出発の日に3DプリンタでNDフィルタのマウントを刷ったりとかなり直前まで開発をしていました。

Progress Report 1

MBZIRC 2017では、エントリーから大会本番までに2回、中間審査がありました。Progress Report 1では小型の機体を作って自動制御のテストしました。

この時点では機体が小さいのでコンパニオンコンピュータを載せることができず、機体とノートPCをWifiで接続してノートPC側のROSからリモートで自動制御していました。GPSを載せずに室内環境で自己位置推定するのが難しく、px4flowをちゃんと動かすためにレジャーシートの上でしか飛行できませんでした…

機体はフレームからオリジナルで設計したものです。Wifiモジュールは日本の技適を通っているESP-WROOM-02にmavesp8266のファームを書き込んでノートPCと通信していました。

Progress Report 2

2回目のProgress Reportでは、本番と同じ機体フレームで機体を組み立て、自律飛行のテストをしました。

この時点では自動離陸、探索、自動着陸まで一通り自動で動作しています。

現地リハーサル

現地に入ってから大会本番まで、各チームには2回のリハーサルのチャンスが与えられました。1日あたり40分の時間が割り当てられ、時間が来たらテントからアリーナまでバギーで移動する形です。

現地に入ってからも開発に追われ、足りない機能の追加や改良など、なんだかんだギリギリまでコードを書いていました…

そのかいもあり、2回目のリハーサルの最後では着陸ターゲットにアプローチ、もう少しで着陸できるところまで行きました。この時点ではあわよくば賞金ゲットもありえるという空気がチーム内にありました。

ですが、現実はそう甘くなかったです…

大会本番

本番はリハーサルの2日間とはうってかわって曇り空、風速も5m/s程度あり、あまり良いコンディションではない中での開催となりました。

リハーサルではフィールドに出てテストをしていたのですが、本番はこのようなテントの中からロボットを見て操作します。

Project C.G.Sの機体は1回目のチャレンジで、着陸ターゲットを認識後に高度制御が不安定になり、機体高度が異常に上昇しました。
※後の調査で、機体の状態によっては高度制御が働かない(垂直方向速度を0にする制御のみで外乱による高度変化を打ち消さない)ケースがあり、上昇気流によって機体が大きく持ち上げられてしまった可能性が高いことがわかりました

またテントの中から機体を目視できなくなってからの対応が遅れ、POSCTLに切り替えてテントの外に出たときには既に機体高度は100mを超えていました。この後も上空の強風の影響でPOSCTLで高度を下げることができず、やむを得ずマニュアル飛行に切り替えて着陸を試みました。しかし、高高度の機体制御経験に乏しかったのもあり操縦がうまくできず、最終的に機体は南に大きく流された後に水路に墜落してロストしました。

1日目のチャレンジで機体がロストしてしまったので、2日目のチャレンジは棄権し、Project C.G.Sのスコアは0となりました。チャレンジの全スコアボードはここから参照できます。

他のチームも含めた大会全体のライブストリーミングはYoutube見ることができます。今回入賞したチームはどこも10秒以内での着陸をキメており、技術力の高さを伺わせました。

これからについて

チャレンジ結果は予想の遙か上を行く最悪の結果でしたが、人的被害がなかったのが不幸中の幸いでした。これは我々の空モノの制御に関する知識不足と操縦技術に関する慢心が招いた結果で、この結果を真摯に受け止め今後の改善に努めていきたいと思います。

ただ一方で、他のチームと比較しても我々のチームの技術力はそこまで劣っているわけではないようにも感じました。次大会までの2年間で経験をつみ最新の技術動向を積極的に取り入れていくことで入賞を目指したいです。個人的にはシミュレータの調査と、FPGAベースの画像処理あたりを開拓していきたいですかね…

あと忘れがちですが、ドローンの自動制御をやるには、マニュアルでドローンを安定して飛ばせる技術をもった人が必要です。自動制御プログラムが動作している最中には、バグなどでドローンが予期せぬ挙動をすることが往々にして起こります。また、自作の機体では製品の機体と比べてギリギリの構成で動作することも多く、FCU側のパラメータも調整不足なためPOSCTLがうまく働かないこともあります。その時に瞬時にマニュアル飛行に切り替え、安定してドローンを着陸させる人は絶対に必要です。

自動制御と操縦技術、少しずつではありますが両方とも精進していきたいと思います。

日曜溶接DIYにチャレンジしてみた

noreply@blogger.com (Kazuyuki Arimatsu) — Wed, 23 Dec 2015 11:00:00 +0000

近頃、パルスロケットエンジンを自作して自転車に積んでみたりだとか、強力な電磁石を内蔵した靴で天井を歩いてみたりする動画がYoutubeに上がっています。

そんな頭のネジが何本か外れたMakerたちの動画を見ていて、

俺はそういうものづくりをやってみたいんだ！

という思いが強くなりました。

そういう人たちは得てして人が乗ったりとか、乗らないにしても迫力のある大きなモノをつくっているわけなのですが、そういった大物を作るにあたっては溶接の工程が必ずといって動画の中に含まれていました。

そこで、頭のおかしいMakerを目指すべく、溶接にチャレンジしてみようと思ったわけです。
※純粋に興味もあったのでとりあえずやってみたかった、という面もあります。

--

いろいろとググってみたところ、溶接機には家庭溶接機というジャンルがあるようで、一般の100Vコンセントと低電流溶接棒を使えば一般家庭でも溶接ができるようです。

家庭用溶接機のジャンルでは大きく分けて

交流アーク溶接機
+ とても安価
- アークスタート、維持が難しい

直流半自動溶接器
+ トリガーを引くだけで使えるので簡単
- 交流アーク溶接機と比べると少し高価

が広く普及しているようですが、100V電源で一般家庭用の15Aだと低電流用の細い溶接棒しか使えず、板厚3mm程度の溶接しかできないために、大きな構造物を作るには今ひとつ力不足感が否めませんでした。

そこで、もう一つのタイプの溶接機

バッテリー溶接機
+ 電源によらず大電流を出力できる
- 非常に高価

の入手を検討しました。

※もし万が一このページをご覧の方で、ご家庭での溶接に興味のある方がいらっしゃいましたら、溶接人さんのページを参考にされると良いと思います
※大物を作る気がないのなら直流半自動溶接機が最適だと思います

--

流石に30万円もするバッテリー溶接機をホイホイ購入するわけにはいかないので、ヤフオクを巡回して手頃な出品を漁っていました。ヤフオクでは様々なタイプの溶接機が出回っているようで、家庭用低電流のものからエンジン溶接機まで一通り出品されています。

一般的な溶接機でしたら、購入にあたっては

- 見た目の綺麗さ
- 動作品かどうか

あたりを気にすれば大丈夫だと思うのですが、
バッテリー溶接機の落札ではさらに、

- バッテリーが生きているかどうか

についても気にかける必要があります。溶接機に内蔵されているバッテリーが意外と高価で、せっかく溶接機を安く落札出来てもバッテリー代が高くなってしまっては悲しいですからね。

--

で、つい手が滑って落札しちゃいました。
※送料込みで2万2,000円でした、多分破格だと思います

マイトアーク社の少し古いモデルで、一般的な自動車用12Vバッテリーサイズ(55B24R)を3直列で使うタイプです。充電は100V15Aで、出力電流は150Aほど取れるようです。もちろん電源のない場所でも使うことができます。ただし、バッテリーを内蔵している関係で重量が90kgあるので、取り回しが少し大変です。

購入当初は汚れが酷く、電圧計も壊れていたのですが、

分解してケースのサビを取って内面をゴム塗料で塗装し、
※プラスティディップは正義

バッテリーケーブルを作りなおして、
※ホルダーを買った時の余りのキャブタイヤケーブルで作りました

回路部のホコリ(ヒューム？)を除去し、

電圧計の中身を汎用品から移植して、
※中に入っている抵抗器だけ元の電圧計のものを使うことで、元の目盛りに合わせて針が動くようになりました

不自由なく使える状態になりました。
バッテリーも生きていたようで、特に交換はしていません。

また、溶接を始めるにあたって、溶接機以外にも

- ホルダー、アースケーブル
- 溶接面
- スズキッド手棒溶接セット(エプロン、手袋など)
- 2.0mmの溶接棒
- 作業台兼アース用の鉄板
- スパッタシート
- 自作の衝立

を用意しました。
※通算は溶接機込で6万円ほどですかね… ホルダー、アースケーブルが予想以上に高かったです

残念ながら家には庭がないのでベランダで溶接作業をしたのですが、音や煙などはそれほど近所迷惑にならない印象でした。例えるなら、ちょっと花火をするぐらいの感じです。むしろケースのサビ取り時にディスクグラインダーを使った時のほうがよっぽど近所迷惑でしたね…
※ただ、強力な紫外線がでるので、それについては配慮が必要だと思います。

実際に溶接機を使って、キット付属の練習用端材を溶接してみました。

…これはひどい

初めてにしてももう少しなんとかならなかったのか。

溶接機のパワーは充分あるのですが、アークスタートも維持も安定せずまだまだ練習が必要ですね。これからも隙を見てチャレンジしていきたいです。

--

今回初めて溶接にチャレンジしてみたのですが、鉄が溶けてくっつくのを間近で体験するのはとても新鮮で、ものづくりの幅が広がった気がしました。

まだまだDIYの中でも敷居が高く思える溶接ですが、実際やってみると意外と簡単にできちゃう感じです。この投稿が、これから日曜溶接DIYにチャレンジされる方の後押しになればと思います。

mbedを使って女子高生に囲まれた話

noreply@blogger.com (Kazuyuki Arimatsu) — Fri, 17 Jul 2015 17:27:00 +0000

高校で教師をしている大学同期の繋がりで、先日とある女子校で講演をする機会をいただきました。

テーマは「ものづくりの面白さ」で、「女子校生ウケする話をしてくれ」という振りに答えるべく、職場の先輩たちと3人で講義に行き、授業時間2コマの間、生徒さんたちと向き合ってきました。

※このスライドは講義で使用したものではなく、mbed祭り2015にてその様子をLTした時のものになります

また、その際に「ものづくりの講義をするからには何か作って持って行くべきだろう」と思い立ち、mbedを使ってミクが歌う楽器のような物を作っていきました。

手の高さで音程を取り、フットペダルとボタンでリズムを刻むとミクが歌ってくれます

このミクの楽器がなかなか好評で、休み時間には教卓の周りに人だかりができ、生まれて初めて女子高生に囲まれるという経験ができました。
※mbedを使えばモテるというのは本当だったみたいです

また、二コマ目はちょっとしたワークショップを開催し、生徒さんに実際に手を動かしてもらう機会を設けました。

作ってもらったのは「光るプリクラ」で、AgICペンと呼ばれる導電性インクのペンで回路を描き、シールのLEDを貼って写真を重ねて貼るといった構造になっています。USBモバイルバッテリーに刺すと写真が光ります

1人1枚好きな写真を持参してもらい、自分オリジナルの作品を作ってもらいました

実際に手を動かしてもらうことで、ものづくりの楽しさや、「なんかよくわかんないけどテクノロジーを学んだら面白いことができそうな気がする感」みたいなものは伝えられたんじゃないかなと思いました。

実際、授業のあとに採ったアンケートではほとんどの方が「またなにか物作りをしてみたい」と回答してくれたのは、素直にうれしかったです。

講義をしてみるまでは、「ウケなかったらどうしよう」と内心心配していたのですが、予想の300％ぐらい食いつきがよかったです。この年代の子たちにとって自分からMakerイベントやワークショップに参加しないと、なかなかモノつくりに触れる機会はないと思いますが、実際に見て触って手を動かしてみることで「あ、これなんか楽しい」って思ってもらえたんじゃないでしょうか。
今回お邪魔した学校に限らず、是非日本中の学校でこういった取り組みを続けて欲しいと思いますね。

最後に、私に話を持ちかけてくれた同期M氏、このような機会をいただけたお茶の水女子大学付属高校学校の先生方、講演を一緒に成功に導いてくれた先輩方、目を輝かせながら話を聞いてくれた生徒さんたちにお礼を申し上げます。

P.S. Makerの方々、高校に作ったガジェットを持って行くと女子校生に囲まれることができるので、是非お試しあれ！

Kinect 360を使ってRTAB-mapで部屋を3Dスキャンしてみた

noreply@blogger.com (Kazuyuki Arimatsu) — Sat, 17 Jan 2015 16:21:00 +0000

RTAB-mapという3次元スキャンアプリケーションが面白そうだったので、手元にインストールして動かしてみました。動作させた環境はWindows8 + Kinect 360です。

--

まず、公式チュートリアルのWin64 Binariesに従ってインストールを行います。

1) Open NIのインストール
2) PrimeSense Sensorをインストール
3) rtabmapをインストール

ところが、Windows 8を使っている場合、この状態でKinect 360を接続してrtabmapを起動してもSouceを選択する段階で、

OpenNI PCLを選ぶと強制終了
OpenNI CVを選ぶと、"Camera initialization failed..."とでて、ログには"CaptureRGBD: Failed to create a capture object!"と表示

で、失敗してしまいます。

これは、Kinect 360のドライバが正しくインストールされていない時に起こる問題のようです。
Windows 8 では署名されていないドライバがインストールできなくなってしまったので、
通常の方法ではPrimeSenseのKinect 360ドライバをインストールすることができません

なので、このページを参考に、

テストモードへの移行 *1
ドライバー著名の矯正を無効化 *2
Windows Smart Screenの無効化

をする必要があります。

*1) これはやらなくても大丈夫なようです
*2) Win8.1では、[チャーム]>[設定]>[PCの設定変更]>[保守と管理]>[回復]>[今すぐ再起動する]>[トラブルシューティング]>[詳細オプション]>[スタートアップ設定]です

すべての手順を実行したら、C:\Program Files\OpenNI\Driverにあるドライバを実行すればRTAB-mapを実行する準備が整います。

--

インストールが完了したら、あとは公式チュートリアルに沿って実行すれば簡単に3Dスキャンが行えます。

まず、FileからNew databaseで新しいデータベースを作ります。
※最初にこれをしないと次以降の作業ができないので注意してください。

RTAB-mapはこのデータベースによって各スキャンの対応する特徴点をグラフで管理しているようです。特徴点ベースでループを見つけたら、グラフ全体を補正して整合性を保とうとします。これによって、スキャンの際に歪みが蓄積されないようになっています。

次に、Detection > Select Sourceから、Select Sourceを選びます
OpenNI PCLと、OpenNI CVが選べるのですが、PCLのほうだとたまに落ちることがあったので私はOpenNI CVを使っています。

この状態でStartすれば、部屋の3次元スキャンを行うことができます。

スキャンの際の留意点なのですが、SURFでの特徴量抽出を行って2枚の点群をマッチングしているので、素早く回転したり、特徴点が抽出しにくい(白い壁など)環境だと自己位置を見失ってしまします。

ただ、特徴点が多くサンプリングできるようなごちゃごちゃした環境( == 私の机の周り)ですと、ほとんどロストすることはありませんでした。

実行画面はこんな感じになります。左上が直前のシーンの特徴点情報、左下がループ検出結果、右側が各シーンを合成した3次元スキャン結果です。ビューワも軽いのでグリグリ動きます。

少し引いてみてみると、ループ検出のお陰で部屋がしっかり四角くスキャンされているのがわかります。

File > Exports 3D cloudsを選べば、*.ply, *.pcd形式で点群を出力することができます。
出力時のオプションでボクセル化やメッシュ化することもできるので、3Dソフトウェアで扱う際に重宝しそうです。

先ほどのスキャン点群をボクセル化 + メッシュ化するとこのような感じになります。

デフォルトの設定だとだいたい100万ポリゴンぐらいのデータになります。
ただ、ボクセルサイズを大きくすれば点群を間引くことができるので、Unityなどで使う場合にはエクスポートの設定をいじったほうが良いと思います。

公式ページの動画ではかなりきれいなマップが出来たのですが、手元で実行した限りだとループ検出がうまく働かない場合があるようでした。Kinectの最小検出距離もあるので、もう少し広い環境で試してみたらもっときれいなマップができるかもしれません。

持ち運べる高性能GPUデスクトップを組んでみました

noreply@blogger.com (Kazuyuki Arimatsu) — Mon, 29 Sep 2014 15:06:00 +0000

最近Oculus Riftでデモする際など、出先でハイスペックなPCが必要になる機会が増えてきました。

Alienware欲しいなぁ、でも高いしなぁ…なんてことを思いながら、ただ高いPCを買うだけなのもつまらないとPE-4CでeGPUに手を出したりしてみたのですが、PCIEx1の帯域がボトルネックになってUnityでのパフォーマンスがでず…
(eGPUについては後で別エントリにまとめるかもしれません、質問等あれば@でもどうぞ)

結局、持ち運べるぐらいの大きさのデスクトップPCを組みたてました。

CPUはHaswell Refreshのi5低消費電力版、マザボはmini ITX、メモリは8GB、ストレージはSSD+HDD(の、予定でした…)、GPUはeGPU用に用意したTDP 195WのPalit GTX760、電源はSFXのPlugin 500Wです。
です。
※今思えば、結局HDDも光学ドライブも積んでないのでCPUは通常版で問題なかったかもしれません

CPU	Intel Core i5 4590S
マザーボード	ASUSTeK H97I-PLUS
メモリ	CFD Elixir DDR3-1600 4GBx2
ストレージ	Samusung SSD 128GB (前PCから引継)
グラフィックカード	Palit GTX760 (eGPU用に購入したもの)
電源	鎌力ゴールドSFXプラグイン 500W

ケースは手持ちのグラボがぎりぎり入るSilverstone SG-05 Liteをチョイスしてみました。このケースはハイエンドGPUを少ない容積に詰め込むことをコンセプトにしているようで、シャドウベイが少ない代わりにギリギリまでケースの大きさが詰められてます。

ただ、このケース、公式では10inchのグラボまでOKと書かれていますが、実際のところ240mmのPalit GTX760でギリギリです。ケースファンを外して、グラボを斜めにするとなんとか入れることができました。というか、プラスチックのハウジングがケースに干渉してるので若干無理に押し込んでます。

そしてグラボもなんとか取り付け終わってあとはストレージを取り付けるだけというところで、今回最大の問題が…

なんとプラグイン電源が干渉してシャドウベイが取り付けられません！！！

もうこの大きさは無理やり押し込むとかそういうレベルじゃないですね…

どうもこのケースは奥行き100mmのSilverstone純正電源に合わせて作られているようで、通常の奥行き130mm電源ではどう頑張ってもシャドウベイが干渉するようです。さらに私はプラグイン電源を選択したのでシャドウベイに細工したぐらいじゃどうにもならない状態に…

結局、アルミ板でSSDのマウンタを自作し、SSDはなんとか中に入れることが出来ました。

まぁHDDはUSB3.0のケースがありますし、ドライブも外付けで十分なので軽量化できたぶん結果オーライですかね？
※若干ケースの剛性が気になりますが…

持ち運びに関しては、当初はバックパネルの隣に取っ手をつけて、岡持ちみたいに持ち運べればいいかなぁと考えていたのですが…あまりにケースが華奢でぐにゃぐにゃ曲がるので不安になり、大型のカメラケースに入れて持ち運ぶことにしました。

ケンコーのaosta Frontana Lサイズです。こちらも超ギリギリのピッタリサイズ、というかギリギリアウトのサイズなので、ファスナーがぶっ壊れないように慎重かつ大胆に無理やり閉めないと入りません。
※このままだとその内ファスナーが壊れそうなので、もう一回り大きいものを購入されることをおすすめします…

これで今まで懸案事項だったデモの際のPCスペック不足も解決出来たので、どこでもデモにいけるようになりました！

VRで女の子に歯磨きするまでにやったこと

noreply@blogger.com (Kazuyuki Arimatsu) — Sun, 10 Aug 2014 15:00:00 +0000

※この記事はUnityアセット真夏のアドベントカレンダー2014参加記事です

----------

長い人生の中で、誰しもが一度は

『可愛い女の子に歯磨きしたい』

という思いに駆られるんじゃないでしょうか

----------

ただ、リアルでそれを実現するのはなかなか難しいですよね……このご時世、下手なことしたら捕まっちゃいます。

でも安心してください！我々にはVRがあります！先日、触覚ハッカソン2014で、私たちのチーム『VRで女の子に歯磨きしたい』が皆さんの夢を叶えてきました。

頭がどうかしてますね。本当にありがとうございます。

--

今回のデモ、VR歯磨きでは、以下のような機能を実装しました

ヘッドマウントディスプレイを被ると、目の前に女の子が座っています
VR空間の中の歯ブラシが手に持った歯ブラシと連動して動きます
歯ブラシを差し出すとそれを女の子が咥えます
歯磨きの擬似触覚が手に伝わります
出し入れすると白い歯磨き粉が出てきます

※言葉で表現するとより猟奇的ですね… 最後の白い歯磨き粉は本当に必要だったのか…

擬似触覚を実現するにあたり、触覚ハッカソンではKMDの南澤先生からTECTILE toolkitという触覚デバイスをお借りしました。入力歯ブラシからサンプリングした振動を、体験者の持つ出力歯ブラシに伝えることで、体験者はあたかも実際に歯を磨いているかのような振動を感じることができます。

※TECHTILE toolkitは一般販売もされていますし、作り方がオープンソースで公開されているのでDIYすることも可能です！詳しくは別エントリにまとめましたので、こちらの記事をどうぞ

--

デモの全体構成はこのような感じになってます。

※Creative Gesture Cameraはデプスカメラとなっていて、物体までの距離を計測することができますが、今回は距離画像は利用せずにただのWebカメラとして利用しています。

私が主に開発したのは歯ブラシコントローラの部分です。ProcessingからUDPで送られてくる複数のマーカー位置を座標変換し、すべてのマーカーから計算した位置をごっちゃにして指数移動平均で平滑化しています。

※マルチマーカーで真面目にやるなら、凹みさんのフィルタ関数などをかけたほうがいいとは思いますが、時定数を大きく取れば問題なさそうなので上の方法で簡単に済ませています

--

VR歯磨きでは、主に2つのUnity Assetを利用させていただいきました。

Unityちゃん

みんな大好きUnityちゃんです。Unity Asset Storeからダウンロードすることができます。モーション、表情モーフ、声と、非常に多くのアセットが付属しています。version 1.0から1.1に上がったタイミングで、ポーズが19種類、ボイスが343種類(！)追加されています。初期バージョンしかDLしたことのない方は、ぜひDLしてみてください。

VR歯磨きではポーズ19の体育座りを利用しています。また、歯ブラシが近づくとangry2モーションで口を開き、歯ブラシを口に入れるとsapモーションで口をすぼめるようにしています。本当にいろんなポーズとモーションが含まれており、どれを利用するかについてはチーム内でも議論の対象になりました。

※ボイスに関してはチーム内でも議論になったのですが、あまりマニアックな声を設定しても一般受けしなくなってしまいそうなので、当り障りのないところに落ち着きました

Oculus Unity Integration

Oculus Rift向けの画像変換や、アセットです。Oculus VR社のページからダウンロードすることができます。樽型に歪ませる処理にImageEffectが使用されており、Unity Proでないと実行することができないので注意です。

最近DK2の出荷に合わせて、version 0.0.4が出ました。Oculus Rift DK2はまだ購入していないのですが、是非とも機を見て購入したいですね。

--

NyAR Toolkit for Unity 3D

また、ハッカソンでは使わなかったのですが、NyAR ToolkitにはUnity用のパッケージも存在します。ハッカソンが終わったあと、このパッケージを用いてUnity上でARキューブを認識して歯ブラシを動かすところまで行うスクリプトを作ってみました！

サンプルプロジェクトを用意しましたので使ってみてください。このスクリプトを使って、自由な発想で歯に限らず色んなものを磨いて頂けたらと思います。

--

2日間という短い時間の中でプロトタイプを作るにあたって、Unityの表現力には本当に助けられました。ただ、モデルやエフェクトにこだわるあまり、デモにゲームとしての面白さがかけてしまっていたのが反省点です。今後はゲーム性も加えたデモ作りを目指していきたいですね。

さて、本日のアドベントカレンダーは楽しんでいただけたでしょうか？アドベントレンダーに不慣れな上、さらにUnityアセットアドベントカレンダーと言いながらアセットあんまり関係ない記事で肩身が狭いです…

明日はK_U_さまより、「FXMakerことはじめ」です！
よろしくおねがいします！

>> Unityアセット真夏のアドベントカレンダー2014へ戻る

--

[追記] 20140813

触覚ハッカソン2014での様子が日経テクノロジーオンラインさんで記事になりました！

TECTILE Toolkitを作ってみた

noreply@blogger.com (Kazuyuki Arimatsu) — Sun, 27 Jul 2014 13:40:00 +0000

最近、Oculus Riftを皮切りにVR空間に没入するコンテンツが増えてきました。

ヘッドトラッキングと視界を覆い尽くす映像、そしてバイノーラル音源のリアルな音による没入体験ができるようになりました。

すると次に欲しくなるのは…そう、触覚ですよね！

※味覚や嗅覚にも非常に興味があるのですが、ちょっとまだ実現は難しそうですよね

個人的に触覚フィードバックには興味を持っていて、8/2、8/3に開催される触覚ハッカソンにも参加する予定です。

つい先日、その触覚ハッカソンの事前説明会にも参加してきまして、いろいろな触覚デバイスを触ってきました。

その中でも特に印象的だったのが、慶応義塾大学の南澤先生が持ってきていた、TECHTILE Toolkitというデバイスでした。さらになんと、TECHTILE Toolkitはオープンソースで開発されており、部品を集めれば自分で作ることも可能です！

このページに行けば作り方が丁寧に解説されていて、だれでもTECTILE Toolkitを作ることができます！

…と、言いたいところなのですが

ページ中で使用されている「任天堂DS振動カートリッジ」と、「ラステームのRSDA202というアンプ」はともにディスコンとなっており、手に入れるのが難しいのが現状です…

任天堂DS振動カートリッジの中には、アルプス電気のフォースリアクタというデバイスが用いられています。

※大小2種類のモデルが存在するのですが、DS振動カートリッジ、DS Lite振動カートリッジ共に大きい方のモデルが使用されています

フォースリアクタは振動モータではなく、中に入っている振動板をコイルで駆動する方式を採用しています。

そのため、高い周波数の振動を再現することができ、よりリアルな触覚フィードバックが得られる…というデバイスだそうです。

※暦本先生のWISS2013の抄録にデータが載ってます

こればかりは無いと仕方がないので、Amazonや駿河屋などで頑張って手に入れます。

私はAmazonで同梱版のメトロイドプライムピンボールを中古3,000円で買いました。

※一時期極端な品薄になったことで、中古ゲーム業者が買い取りに積極的になったのか、今はお金を出せば手に入るようです

ラステームのアンプはちょっと手に入りそうになかったので、代わりに秋月のTA7252を使ったオーディオアンプキットを利用してみました。

組み立ててみた様子がこちらになります。

スピーカー端子から音声を出力し、それをオーディオアンプを通して増幅してフォースリアクタを駆動しています。

今回はコップを使った触覚フィードバックデモを再生するので、フォースリアクタはこのようにコップに貼り付けました。

※底面に密着して貼り付けられなかったので、側面に貼り付けています

作ってみて早速コップの中でビー玉が回転している触覚データを体験してみたのですが、実際に会場で体験した時と比べるとどうにもリアリティが少ない気がしました…

※映像に合わせてコップを動かすと十二分に触覚が感じられます、VRの中で真骨頂を発揮しそうな予感がします

会場での体験と比べて今一歩及ばなかったのは、やはりアンプが良くなかったのでしょうか？

ラステームのRSDA202はトライパスのTA2020というデジタルアンプICを利用しているそうなので、同じICを利用した安いアンプを買って試してみたいと思います。

--

[追記] 20140806

TA2020使ったオーディオアンプ、Lepai LP-2020+がAmazonにて2000円ほどで販売されていたので、例によってコップ音源を再生してみました。

秋月アンプよりだいぶ良い感じがして、本家のTECHTILE toolkitとだいぶ近い感じがしました。簡易イコライザがついててローパスかけられるのもありがたいです。

Unity for PSMを使って、PS Vita上でユニティちゃんを動かす

noreply@blogger.com (Kazuyuki Arimatsu) — Wed, 04 Jun 2014 15:32:00 +0000

Unity for PSMというPS Vita上でUnityアプリケーションを動かす開発環境が今自分の中でアツいです。

公式にもチュートリアルはあるのですが、PSM開発経験のない自分にとってはドキュメントが散らばっていて分かりにくい部分が多かったので、公式のユニティちゃんサンプルを動かすまでに自分がやった手順を備忘録的にまとめてみたいと思います。

PSMとはPlayStation Mobileのことで、PS Vita(とAndroid)向けのゲームエンジンとそのエコシステムを指します。そのエコシステム上で、PSMランタイムとは全く独立した形でUnityランタイムを動かし、Unityで作られたゲームをPS Vitaで動作させるのがUnity for PSMになります。現在Public Preview版が出ていて、今年の夏に正式版のリリースが予定されています。

もともとPSM (PlayStation Mobile)自体もMonoベースのゲームエンジンだったのでUnityを動かす土台はあったということでしょうか？
それでも、自前のゲームエンジンの競合を敢えて個人利用可能な形で公開するというのはなかなかできない決断だと思います。

Unite2014のスライドにPSM、Unity for PS Vita、Unity for PSMの違いがよくまとまって記載されているので、詳しくはそちらをご覧ください。

--

Unity for PSMを用いた開発の手順は、PSM Dev Portalのこのページにまとまっています。基本的にこのページにそってやれば大丈夫なはずですが、ここでは自分が躓いた部分をつらつら書いていきたいです。

このページにもある通り、Unity for PSMで作成したアプリケーションをPS Vita上で動かすためには、PSMデベロッパー登録とPSMパブリッシャーライセンスの取得が必要になります。PSMデベロッパー登録はすぐ完了するのですが、PSMパブリッシャーライセンスの取得には1-2週間程度の審査時間がかかるので、とりあえず申請しておくことをおすすめします。なお、現在PSMパブリッシャーライセンスは無料で取得することができます。

次に、Unity 4.3.4f1とPSM ToolSet for UnityをPCにインストールします。Unityは通常のバージョンとは異なり、PSM向けにパッチが当てられたバージョンなので注意してください。

そして、PSM DevAssistant for UnityをPS Vita上にインストールします。これはUnity for PSMで開発したアプリケーションを、PS Vitaでテストする際に必要になるソフトウェアです。アプリケーションをPS Vitaに転送、実行する際にはPSM DevAssistant for UnityがPS Vita上で実行されている必要があります。
※PSM SDK向けのPSM DevAssistantとは別物なので注意してください

インストール自体はPS Storeで検索するか、bit.ly/psmdevappにPS Vitaからアクセスすることでダウンロード可能です。
※PS Vitaに紐付けられたPSNアカウントがDev Portal上でPSMデベロッパー登録されていない場合にはストア上でダウンロードボタンが表示されず、インストールすることはできません。

以上で準備は完了です。

--

公式のサンプルプロジェクト、unity-chan-PSMをダウンロードします。
ファイルを適当なディレクトリに解凍したら、Unity for PSMで開きましょう。初回のロードは少し時間がかかります。

プロジェクトを開いたらユニティちゃんのシーンが自動的に読み込まれると思います。読み込まれなかった場合はAssets/UnityChan/Scenes/Locomotion.unityを開けばいいと思います。
※Locomotion.unityを開いてもシーンが正しく読み込まれない(HierarchyにMainCameraしかない)という状態になったことがあるのですが、ファイルの解凍からやり直したらうまく読み込めました

まずはFile > Build Settingsを開いて、PlatformをPlayStation Mobileに変更します。

次に、Open Publishing Utilityを押して、PSM ToolSet for UnityのPublishing Utilityを開きます。

Publishing Utilityでは、パブリッシャ鍵の管理r、デプロイの際のapp.xmlの設定、デバイスシードの作成、アプリ鍵の作成などを行うことができます。マニュアル操作でPS Vita向けのパッケージを作成する際にはこのあたりの設定を利用することがあるかもしれませんが、ひとまずはパブリッシャ鍵の作成だけを行なっておけばOKです。このあたりの(ややこしい)しくみについてはPSM SDKのこのドキュメントが詳しいです。

パブリッシャ鍵の作成の時に No PSM device found! のようなエラーが出た場合には、PS Vitaとの接続に問題があります。PS Vita上でPSM DevAssistant for Unityを起動した状態でUSBで接続してください。
また、パブリッシャ鍵の作成や認証の際にはSCEサーバとの通信が必要になります。通信に問題がある場合にはプロキシ等の設定が正しいかをファイル > プロキシサーバの設定から確認して下さい。
※一度鍵の作成に失敗したのですが、一度鍵を削除してもう一度作りなおしたらうまくいきました

パブリッシャ鍵の作成が終了したら、Publishing Utilityを終了して、Build And Runを実行します。

このBuild And Runコマンドは非常に優秀で、デバイスシードの作成、デフォルトapp.xmlの読み込み、アプリ鍵の生成、パッケージ生成、PS Vitaへのパッケージ転送、実行までをすべて自動で行ってくれます。2回目以降はこれを実行するだけでPS Vita上でゲームのデバッグ実行が可能になります。

--

[おまけ]

Unity for PSMを使うと、PS Vitaのジャイロと加速度センサの値を、UnityのInput.gyroとInput.accelerationを使って取得することができます。

しかし、地磁気の値についてはInput.compassを用いて取得することができませんでした…
Unite 2014でも地磁気については言及されてませんでしたし、PSM SDKでも取得することができないようなので、もしかしたら地磁気については取得する方法がないのかもしれません…

--

[追記] 2014/06/14

Unity for PSMでCompass APIが利用できないことについてUnityのForumで聞いてみたところ、Public Preview版では利用できないとの回答を頂きました。Unity 5から使えるようになるらしいので、それまで楽しみに待っていることにします。

--

[追記] 2014/07/27

このコンテンツは、『ユニティちゃんライセンス』で提供されています

Oculus Riftに表示されたVR空間の中にRGBDカメラで撮影した自分の手を投影する

noreply@blogger.com (Kazuyuki Arimatsu) — Sun, 20 Apr 2014 06:52:00 +0000

かねてからOculus RiftとIntel Perceptual Computing SDKを組み合わせて何かできないかと、手を動かしていたのですが、やっとひとまずの形になったのでブログ記事にまとめてみたいと思います。技術的な内容は後ほどまとめるとして、今回は紹介まで。

ハードウェアには、Oculus RiftとCreative Gestureカメラを用いていて、それをThingiverseで公開されているマウンタを使ってつなげました。

ソフトウェアではGesture Cameraで撮影したRGBD画像からPerCライブラリの力を借りて手領域を抽出し、該当点群を少し回転させてOculus RiftのVR空間に重ねて表示しています。
背景にはTHETAのような正距円筒図で作成された360度画像を、Oculusの向きに合わせて展開して表示しています。

ソースコードはgithubに公開しています。
デモに利用した言語はC#で、Unityなどのフレームワークは利用していません。Livet、Oculus SDK、PerC、SharpDX、RiftWrapperを利用して開発を行いました。
3次元メッシュ再構成は、当初はOpenCVやMIConvexHullなどを使ってドロネー三角形分割で行おうと考えていたのですが…
結局実行速度の関係で諦めました。点群が密なことを前提にした独自の(手抜き)アルゴリズムでメッシュの再構成を行っています。その関係で、手のメッシュのエッジで粗い部分が目立ちます。これは今後の課題ですね。また、せっかく手の点群データを持っているので、ゆくゆくはVR内の物体と物理演算をするようなインタラクティブなデモを作ってみたいです。

ニコニコ超会議3の中で開催される、第6回ニコニコ学会βシンポジウムの野生の研究者ポスターセッションでデモを行う予定です。場所はMikujalusのきゅーこんさんの隣になるようです。
Oculus界隈で著名な方のお隣ということで少し緊張してますが… 自分のデモがうまく動くことを祈ってます。

Travis CIでconfigure.acにAC_CHECK_HEADER_STDBOOLを含んだプロジェクトをビルドする

noreply@blogger.com (Kazuyuki Arimatsu) — Sun, 16 Feb 2014 10:24:00 +0000

MikuMikuPenguinをTravis CIで自動ビルドする際に、Travisのワーカー上で以下のようなエラーが発生しました。

configure.ac:***: error: possibly undefined macro: AC_CHECK_HEADER_STDBOOL
    If this token and others are legitimate, please use m4_pattern_allow.
    See the Autoconf documentation.

MikuMikuPenguinのconfigure.acにはAC_CHECK_HEADER_STDBOOLという記述があり、stdbool.hが存在するかを探しているようです。

どうもこのエラーはstdbool.m4がaclocalから読み込まれていないことが原因のようです。これを解決するには、stdbool.m4を含むgnulibパッケージをインストールしてからaclocalの検索パスに/usr/share/gnulib/m4を追加します。

.travis.ymlを

language: cpp
compiler: gcc
install:
   - sudo apt-get install -qq gnulib #stdbool.m4 is required for AC_CHECK_HEADER_STDBOOL in configure.ac
script:
   - autoreconf -i -I/usr/share/gnulib/m4 && ./configure && make

のように記述すると、無事にautoreconfのエラーが消えてビルドを行うことが出来ました。

Intel Perceptual Computing SDKのutil_capture.hでのビルドエラー

noreply@blogger.com (Kazuyuki Arimatsu) — Mon, 10 Feb 2014 04:41:00 +0000

Point Cloud Library (PCL) 1.7.1経由でSenz3Dから取得した点群データを描画するアプリケーションを開発しています。
PCL 1.7.1は内部でIntel Perceptual Computing SDK (PerC SDK)を利用しており、\sample\common\include\util_capture.hにも依存関係を持っています。

Visual Studioで自前のプロジェクトを作成してプログラムを作成していたのですが、どうやらVisual Studioでプロジェクトを作成するときに、「Win32コンソールアプリケーション」や「Win32プロジェクト」を選択しない場合にはutil_capture.hで以下の様なエラーが発生するようです。

error C2664: 'errno_t wcscpy_s<256>(wchar_t (&)[256],const wchar_t *) throw()' : 1 番目の引数を 'pxcCHAR [256]' から 'wchar_t (&)[256]' に変換できません。

どうやら、これはpxcCHARの型がwchar_tになっていないことが問題のようです。pxcCHAR型はpxcdefs.hに以下のようにtypedefされています。

#if defined (WIN32) || defined(WIN64) || defined(WINAPI_FAMILY)
#include <wchar.h>
typedef wchar_t pxcCHAR;
#else
typedef char pxcCHAR;
#endif

これを見るとわかるように、WIN32やWIN64が定義されていない場合にはpxcCHARがchar型となってしまうようです。同様のエラーがintelのフォーラムにも投稿されていて、そこでもWIN64の定義が問題になっています。

この問題を解決するために、プロジェクトのプロパティから「構成プロパティ > C/C++ > プリプロセッサ > プリプロセッサの定義」にWIN32を追加したところ、問題は解決しました。同様のエラーに悩まされた時はプリプロセッサ定義を確認してみると良いかもしれないです。

背筋トレーニング日記

Kailh ChocV2の完全無線分割キーボードを作ってZMKで動かした話

TL;DR

はじめに

Kailh Choc V2キースイッチの嵩上げ

ロジックボードをフレキ接続 (※おすすめしません)

無線版のマイコンボードの設計

自作基板に合わせてZMKの設定をする

ZephyrのBluetoothスタック使用と技術基準適合証明(技適)について

未解決の問題について

完全無線分割キーボード Thumbsplit58 を作った話

TL; DR

はじめに

どうして作ったのか？

基板

ケース

ファームウェア

キーマップ

おわりに

LOUQE Ghost S1 Mk3ケースで小型Ryzenゲーミングマシンを組んでみた

TL;DR

SFF PCの世界

DAN Cases A4-SFX (公式ページ)

LOUQE Ghost S1 (公式ページ)

FormD T1 (公式ページ)

VELKASE Velka7 (公式ページ)

パーツ構成

組み立て

パフォーマンスと冷却性能

おまけ：taobao店舗からのLOUQE Ghost S1 Mk3購入

uFactoryの格安ロボットアームxArm 5 Liteが届いたので動かしてみた

固定するためのフレームを作る

ファームウェアのアップデート

動かしてみる

xArm 5 Liteを買ってみての感想

GLSLでGPUを活用するROSノードを作ってみました

TL;DR

はじめに

オフスクリーンレンダリングについて

EGLを使ったコンテキストの作成

OpenGL APIのエントリポイントをロード

今回のROSノードの処理の流れ

頂点バッファ

シェーダ

テクスチャ

GPU/CPUの実行速度の比較

OpenGLについて

OpenGLとOpenCVとの相互運用について

OpenCVのCIELab色空間変換とガンマ補正について

用語まとめメモ

遅ればせながら自作キーボードデビューしました

組み立て

キーマップの設定

EndGameに向けて

ドローンにJetson TX2を載せて自律制御する (ハードウェア準備編)

備考1: rosbag書き込み速度の実測値

備考2: MIPI CSIカメラについて

Ali ExpressのBest Carbonにカーボン加工を外注してみた

海外プロポ Taranis Q X7Sを日本で合法に使用する

アンテナの取り外し

技適取得済みの外部送信モジュールを装着

外部送信モジュールを使用するように設定

おまけ1 - ファームウェアの更新とmicro SDのセットアップ

おまけ2 - FPVシミュレータでTaranis Q X7Sを使用する

MavESP8266をESP-WROOM-02に焼いてPixhawkとWifiで通信する

ファームウェアの書き込み

ボーレートの設定

その他

技術書典4で頒布した「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」をBOOTHで再販開始しました

技術書オンリーイベント 技術書典4で「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」を頒布します！

Ubuntu 16.04.3 LTSでROBOTIS Dynamixel SDKが通信に失敗する

かっこいいU199ドローンを作ってみた

ロボットの世界大会、MBZIRC2017のドローン自律制御部門に出場してきました

出場した大会について

機体について

Progress Report 1

Progress Report 2

現地リハーサル

大会本番

これからについて

技術書オンリーイベント技術書典4で「Do It Ourselves: 社会人サークルによる自律移動ロボット開発」を頒布します！