ページ

2021年10月4日月曜日

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

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. AJisai74Sparrow62)

ところが、トッププレートを使わない場合は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
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ビットを表現しています。よくよくデータシートを読んでみるとWS2812WS2812-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ファイルを書き込むことでファームウェアの書き換えが可能になります。

2021年1月2日土曜日

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

 TL; DR

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

はじめに


2019年の中頃に、完全無線分割キーボード Thumbsplit58 を設計しました。1年ほどキーボードを使って出てきたフィードバックを取り込んで、今年の終わりに一度ケースを作り直しました。スイッチはKailh Choc  (ソケット対応)、キーキャップは MBK Low Pro (1u/1.5u) を想定しています。MitosisComet46 がベースになっていて、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

2020年8月17日月曜日

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

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 (公式ページ)

DAN Case A4-SFX v4 - PCケース&パーツ、オーディオのパイオニア ...

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 (公式ページ)

T1 V1.1

基本構造が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 (公式ページ)

vk7 side.jpg

このケースは筐体体積を極限まで小さくするために縦置き配置とし、マザーボードとグラフィクスカードを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を選びました。

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

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


2019年10月2日水曜日

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

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分程度)ようなのですが、このようにコマンドプロンプトで何かをダウンロードしているログが出れば正常に進んでいると思います。

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

--

動かしてみる


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つ追加されており、アーム先端が取れる姿勢が多くなると思います。