くっつきーの歴史 開発開始〜初販売後まで（後編）
Table of Contents
「くっつきー」は、2024年初頭から2025年3月まで1年強にわたって開発し、販売を開始した自作キーボードです。現在も開発は続いていますが、一区切りということで初販売までの開発履歴を記録してみました。
この記事シリーズでは、プロトタイプから製品版に至るまでの試行錯誤の過程を詳しくお伝えします。記事が長くなってしまったため2回に分けており、前編では動機やコンセプトなど全体的な話をまとめ、後編では各モジュールの変遷と技術的詳細について記載します。
前編はこちら。
ここからは、各モジュールの変遷と詳細を見ていきます。
キーモジュール編
キーモジュールは、くっつきーの中核となるモジュールです。その開発は大きく4つの段階を経て、現在の形に至りました。
プロトタイプ: ブレッドボード
ブレッドボードでI2C接続の検証
まずはブレッドボードでI2C接続の検証を行いました。使用しているICは、Pro Micro（ATmega32U4）とI/Oエキスパンダー MCP23017です。I2CをUSBケーブルに通す検証も同時に行っています。USBケーブルはD+とD-の2本のデータ線、VCC/GNDの合計4本を持っており、I2Cに最低限必要な線がちょうど賄えるので使っています。また、この時点でQMKを使い、ファームウェアを含めてキーボードとしての機能が動作するかも検証しています。まさに最古のくっつきーと言えるでしょう。
アルファ版: TRRSケーブル基板
ブレッドボードで回路の検証を済ませた後、まずは実際の接続方式を検討しました。選択肢として、キーモジュール同士をケーブルで繋ぐデイジーチェーン方式と、各モジュールからハブに繋ぐハブ方式の2つを考えていました。現在はハブ方式となっていますが、初期の判断として「ハブモジュールを増やしたくない」ということと、「キーモジュール同士が近接配置される」ことを想定し、デイジーチェーン方式を採用しました。
回路と基板設計も必要です。くっつきーはキーボード基板の中でも特にパーツ配置の制約が厳しいです。なぜかというと、4キーごとにICやDIPスイッチを積んでいて点数が多いうえ、19.05mm（1キーのサイズ=1U）のキーモジュールを並べられるよう作る必要があるためです。これはケースを含めた幅なので、基板に使えるのは大きくても左右1mmを削った17mmです。この制約を満たしつつ、デイジーチェーン用に2つコネクタを並べないといけません。基板の先頭と末尾にそれぞれコネクタを置くこともできますが、配置の柔軟性が下がりロウスタッガードが組めなくなるので、先頭のみにコネクタを置くことにしたためです。まずは、オーディオと自作キーボードでおなじみのTRRSジャックなら2つ並べてもいけるかな、ということで試作してみました。
この段階から、これからずっとお世話になるJLCPCBでプリント基板（PCB）を発注しました。JLCPCB自体の検証（基板発注のテスト）は済ませていたため、この時点から既に検証がてらPCBAを使っていました。形状は既に現在とかなり近いです。
TRRS接続の4キーモジュール基板
PCBAでは、JLCPCBが対応している様々なパーツが使えます。MCP23017は大きすぎて困っていましたが、漁ってみるとI2C対応のI/Oエキスパンダーには色々あることを知り、ここではPCA9555を採用しています。16bitも要らないので過剰スペックですが、ビット数が変わっても値段があまり変わらなかったことと、QFNパッケージで小さかったことから使ってみた記憶があります。ディップスイッチは現在と異なり4bitです。ICは3bitまでしか対応していないので1bit分無駄ですが、4bitの方が安かったような記憶があります。この時点でキースイッチのホットスワップにも対応しており、定番のKailh Switch Socketを付けています。TRRSジャックと合わせて、これらは自分ではんだ付けした記憶があります。
余談ですが、くっつきーでのパーツ選定はPCBAができることをかなり重視しています。一番の理由はサイズ制約が厳しいことですが、はんだ付けが大変という理由も大きいです。自分でやると不良品を大量製造してしまいそうなので、最小限のはんだ付けで済むよう、PCBA前提で開発を進めています。
このように初期段階ではTRRSケーブルを試していましたが、4キーモジュールで2つ並べると多くのケーブルで干渉する問題が判明しました。また、TRRSケーブルは意外と入手が難しく、TRSケーブルと間違える問題もありました。別のコネクタを探していましたが、結局ブレッドボードで使っていたUSBケーブルでいいか、という考えに落ち着きました。PCに間違えて接続してしまいそうな心配はありますが、入手性が非常に高く、低コストで頑丈なケーブルなので採用に至ります。
ベータ版: USBケーブル基板
USBケーブルの懸念として、コネクター部分が大きく干渉しそうな点がありました。しかし意外と幅は細く、縦なら2つ並べても余裕があります。JLCPCBで直角（right-angle）タイプのコネクタを見つけられたためPCBAができ、上手く機能させることができました。この時点でケースと土台もBambu Lab A1 miniで用意し、基礎となる形が完成しました。
土台とスイッチなしの4キー。印刷の難しさが垣間見える
USB版の4キーと5キー
たくさん繋いだ形。キーキャップも3Dプリンター製
見た目通りUSBケーブルは信頼性が高く、抜き差ししやすいメリットがあります。一方で、高さ（幅）があることと、ケーブルが硬くてゴツいことが挙げられます。高さがあると何が起きるかというと、土台との接続が不安定になってしまうのです。要は力のモーメントが大きくなります。土台との接続が重要なキーモジュールでは、安定性向上のために高さは低いほど良いです。また、隣接していないとケーブルが届かず、配置の自由度が下がってしまう問題もありました。かといって長くすると邪魔になってしまうというジレンマがあります。
この段階で色々動くものを作っていた
ジョイスティックのプロトタイプも
この時点で一度動くものを作ってみたい、ということでPCBを沢山製造しました。JLCPCBのパネリングを使いましたが、V-Cutだと高価になるため、自分でMouse Bitesで配置した基板データを用意し、勢いよく20個x5枚の合計100個のPCBAキーモジュール基板を発注しました。Mouse Bites自体はニッパーで簡単に分離でき、バリはあるものの上手く動作しました。この頃はここから形が変わるなんて思っていなかったんでしょうね。当然100個も要らず、形変更でほぼ無駄になりました。そんな事もある。
頑張ったパネリング。そして無駄になる
製品版: HYケーブル基板
そこからもケーブル探しの旅は続きました。直角（right-angle）コネクターは意外と少ないため、2つのコネクターを横に並べて1Uに収める方向で考えていました。そのためには、一つのコネクターが8mm程度に収まる必要があります。しかし、このサイズで並べられるものは少ないです。そこで、デイジーチェーン方式から切り替え、ハブを作ってみることにしました。これにより、基板側では1つのコネクタを横向きに用意すれば良くなり、高さが大きく削減されました。また、使用できるケーブルの自由度も高まりました。ハブモジュールが増えたのは管理面ではマイナスですが、配置の自由度が上がり、チルティングやテンティングにも利用できるため、結果的には良かったと思っています。
ここで採用したのは、20cmの4ピンHYケーブルです。HYケーブルはGroveケーブルとしても知られ、M5Stackでも採用されています。そこそこの入手性があり、操作しやすいサイズの4ピンケーブルということで採用しました。
現在の形
なお、使用しているI/Oエキスパンダーも、よりコスパの良いTCA9535にしています。Texas Instruments製品に限れば、このような表などでグラフィカルにスペック比較を出してくれているのでありがたいです。Digikeyなどのサイトも合わせて探し、JLCPCBで可用性と価格を見る生活を続けていました。現在の1チャンネルに対してキーは8つまで、という制約もTCA9535から来ています。TIのI/Oエキスパンダーは大抵アドレスが1-8程度設定できるようになっており、片手分のキーモジュールは8つ置ければ十分か、ということでこのような仕様に落ち着きました。
I/Oエキスパンダーの比較例
現在、高さに寄与しているのはDIPスイッチとHYコネクターです。いずれも重要なコンポーネントなので、削るには多くの工夫が必要です。
なお、HYケーブルの4ピンはGND,VCC,SDA,SCLという順にアサインしています。対向のモジュールでも同じ順番になっているため、リバースケーブルで接続します。
I2Cコネクターのピン配置
なお、製品版の製造にはとにかく時間が無かったのと、数がある程度見込めたので、V-Cutによるパネリングを使ってみました。V-Cutを使うとStandard PCBAになってしまいオーバースペックな製造なのですが、想定していた単価より安かったのでそのまま進めました。ペキッとするだけできれいな基板が出来上がるので、キーモジュールなどケースへの配置がシビアな基板にとても便利です。
キーケース編
キーモジュールの基板を格納するケースも、様々な変遷を経ています。
プロトタイプ版: 左右接続方式
最初期のケースは、キーモジュールは隣接されるという前提のもと左右で連結する形で土台がありませんでした。この頃はまだ底面が平らで、横のキーケースとネジなどで連結して固定することを考えていました。しばらく取り組んでいましたが、次のような問題があったため、土台とケースをそれぞれ作成する方式に変更しました。
- 側面は1mmに満たず、穴の強度に問題がある
- ケース同士の強力な固定が困難（加えて、複数箇所で止めないと回転する）
- 小さいので手が入らず、固定具を付けるのが困難
- 自由度が低い（左右に隣接しないといけない）
最初期のキーケース
アルファ版: ブロック組み立て方式
「ブロックの固定といったらLEGO®では？」というアドバイスを受け、凸を組み合わせて固定する方式に転換しました。凸の土台にフチで囲まれた凸を置く形です。この変更により、配置の自由度が飛躍的に向上しました。寸法は後述します。
ブロック組み立て方式の初期版
この時点で、凸や丸を正確に印刷する難しさが出ています。どの方向を下にして印刷するかによりますが、丸にはバリが出がちです。このバリは固定に寄与して嬉しいこともあれば、邪魔になってはまらないこともあったのですが、いずれにせよLEGO®のような強い固定はできませんでした。そもそも規格がLEGO®と同一ではなく、1Uサイズに合うように、かつ細かく移動できるように変更した凹凸なので、どうしても上手く成形できないサイズになってしまいます。
問題はあれど、この時点で大まかな形と仕組みは製品版と同じです。基板は入口にある台座と末尾のスリットを通して高さが固定されます。コネクターやHotswap Socketを通せるよう内部に隙間を用意しており、キースイッチを挿して固定する方式です。設計は複雑でしたが、なんだかんだ上手く固定できています。この仕組み上打鍵感は硬めなので、調整できると面白そうだと思っています。
スリット部分
ベータ版: マイナーチェンジ
固定を強くする方法を考え、なんだかんだで縁の溝を無くした方法を試したのがこちらです。少し強度は上がったものの、依然課題は解消していません。土台も上手く印刷できていないですね。
マイナーチェンジ。土台の印刷はやはり難しい
製品版: 凸と凹み
キーモジュール基板で見たとおり、ハブ方式に変えたことで高さを減らすことができました。最終的に、ケースの高さは8mmもの削減がなされました。これだけ違うと、見た目の印象も変わります。
ケースの高さ比較（横）
ケースの高さ比較（正面）
それでもまだ物足りず、さらに固定を強くしたいと考えて悩むこと数日、天啓が降りてきました。
「どうして凸を組み合わせるの？」
LEGOでは凸同士を組み合わせているため、その先入観に囚われていました。しかし、片方が凸ならもう片方は凹でいいじゃないか、と気づいたのです。これにより、キーケース側は凹、土台は凸という現在の形になりました。高さは削れないため同じですが、固定を少し強くすることができました。
製品版は設計をFDM（熱溶解積層方式）のA1 miniで試した後、精度を保った量産が大変なのでJLC3DPで光造形による作成をしています。非常に高い成形精度が出るのですが、逆に揺らぎが無いため、FDMと同じ値だと固定が弱い場合がありました。何度か発注して異なるサイズの穴を検証し、何とか上手く固定できるサイズの組み合わせにたどり着きました。かなりの微調整が必要で、わずかな成型のブレはどうしても発生するので、より精度を問わない固定方式を模索したいと思って今に至ります。
土台編
土台もキーモジュールと同時期に作り始めました。LEGO®は規格が公開されているのですが、そのままではキーのサイズ（19.05mm四方）には合いません。そのため、19mmを4等分した4.75mmの距離を空けた穴を配置しました。
現行バージョンでは凸と凹を組み合わせる形で、それぞれ2mmの高さを持たせています。穴は完全にサイズが一致していると挿さらないため、凸部分は直径3.05mm、凹部分は直径3.07mmで設定しています。ただしこれは光造形などの高精度が出る場合で、FDM方式では0.2mmほど余白を増やしていました。
調整にかなり気を使った土台部分ですが、このようになった変遷を見てゆきましょう。
アルファ版：三角錐
初期の三角錐土台設計
初期の土台は、チルティング・テンティングの角度が固定の三角錐でした。野心的に真横にも配置することを想定し、凸を上面と左右面に配置しました。3Dプリンターで印刷して使ってみると想定通りに動作してくれましたが、角度が固定されてしまうこと、印刷の難易度が高く失敗しがちなこと、一度のフィラメント消費量が大きいことが課題でした。なお、中は空洞になっており、ケーブルを入れられるのは便利でした。
空洞部分にケーブルを格納できた
ベータ版：プレート組み合わせ式
平面プレートを作り、必要に応じて傾き付きのチップを重ねて三角錐を作る試みは、ブロックの組み合わせから自然な発想として出てきました。印刷自体の難易度は変わらず高いですが、三角錐よりは楽です。チップの組み合わせで角度調整も可能になりました。滑り止めを付けたチップを付けられるのも同じですが、チップの片面は凹凸がありません。この時点では天面も底面も凸でした。
上手く印刷できているように見える土台
同じ土台の底面。こちらはところどころ上手く印刷できていない
いずれの土台も印刷をすると、端に行くほど急激に精度が落ちる＆プレートへの吸着が悪くなって頭を悩ませていました。土台はA1 miniの限界サイズに近く、形も長いので収縮と反りの影響を受けやすい模様です。その上に精度を要する丸が大量にあるので、実に厄介。1層目の設定を工夫してもなかなか上手く印刷できず、この段階でJLC3DPのレジンを使うことにしました。前述した通り、いくつかの穴のサイズを試して上手くいくパターンを検証しました。
製品版：穴あき設計による最適化
土台は大きいのでどうしてもフィラメント消費量が大きく、コストに直結します。そこで、ミニ四駆などの肉抜きにインスパイアされ、穴を開けてみることにしました。モジュールは少なくとも1U以上のサイズがあり、全ての穴で固定する必要が無いため、問題なく機能します。適当な穴を開けても十分な強度が得られ、副次的な効果としてケーブルを底面側に通した整理もできるようになりました。
初期製品版の土台。現状はもう少し大きい
なお、製品版は一度改訂しており、少し横幅を大きくしています。複数の土台をくっつけて大きくすることは出来ますが、固定が難しいので土台自体を大きくしました。色々な形に対応するため土台もモジュール化したいところですが、接続部や剛性の課題があり、現状いい案は無いため研究の日々は続きそうです。
ロータリーエンコーダー編
ここは比較的素直な設計と形なので、あまり書くことがありません。秋月で売られているロータリーエンコーダーで検証し、EC12シリーズで良さそうなEC12D1524403を見繕いました。
一点、思いもよらない罠がありました。ICはキーモジュールとI2Cアドレスが被らないようにTCA9534Aを使ったのですが、設定可能なアドレスは0x38から0x3Fまでです。これを見てピンときたら凄いです。SSD1306搭載のディスプレイをペンダントで利用しているのですが、このアドレスは0x3C固定です。つまり設定次第で衝突します。ロータリーエンコーダーは手間がかからなかったので製造に取り掛かったのも終盤で、気付いた後にICを差し替えるのも困難でした。結果、変更できるアドレスを下位2bitだけにして回避しました。これにより1つのチャンネルに4つしか置けないという制限が出来てしまいましたが、致し方ないのでそのままリリースしています。
なぜかDIPスイッチが2つしか使えない理由
ペンダント編：システムの頭脳
ペンダントは、PCと接続されてファームウェアが動く頭脳部分です。多くの検証は開発ボードで行っていたので、回路を設計しはじめたのは後半で、かつ初期版から大きな変化はありませんでした。そのため、歴史というよりは現状を記録します。使用している特徴的なICは次のとおりです。
- MCU: RP2040
- フラッシュメモリー(12MB): W25Q128JVSIQ
- I2Cスイッチ/マルチプレクサー: PCA9546A
- OLEDディスプレイ: HS96L03W2C03
MCU選定
早い段階でRP2040（Raspberry Pi PicoのMCU）を採用しました。扱いやすさと高機能性、実績の多さ、公式ドキュメントに設計例が豊富で、かつ安価という非常に使い勝手の良いMCUです。
一般にモジュールを作る時、Raspberry Pi Picoをはんだ付けして利用するか、RP2040自体を使って回路を作るかを選択しないといけません。Picoは非常に安価なので、そのまま使う方が安定し、トータルでコスト減になった可能性が高いです。しかし、自分ではんだ付けをしないで良いこと、ついでに勉強も兼ねて、RP2040を使った回路を設計することにしました。
RP2040はRaspberry Pi Pico公式のデータシートでリファレンス回路が載っており、配置も公式に寄せることで比較的簡単に設計できます。とてもありがたいですね。一度原因不明で動かない基板ができたものの、二度目で上手く動作しました。当初は意図していませんでしたが、Picoでは得られないメリットとして12MBのフラッシュメモリーが載せられた点があります。結果的には使い勝手を高めるうえで非常に重要で、160キーを8レイヤー以上VIAでリマップでき、様々なパラメーターも格納できました。
I2Cスイッチ/マルチプレクサー
キーモジュールで使っているI/Oエキスパンダー（PCA9555）は8種類のアドレスしか取れません。すなわち、最大で5*8=40キーしか対応できず、このままでは60%キーボードも組むことができません。当時は「詰んだ」と思った記憶があります。その後色々調べてみると、I2Cスイッチ/マルチプレクサーを発見しました。これはその名の通り、1つのI2Cバスを複数チャンネルに切り替えられるようにし、アドレス衝突の問題を緩和するものです。
I2Cスイッチ/マルチプレクサーのイメージ図
使用したICはPCA9546Aです。これ自体がI2Cデバイスになっており、どのチャンネルを使うかを制御できます。これをペンダントに搭載して現在の4チャンネル型にしています。前述した通り、1チャンネルで8つのキーモジュールまで処理できるため、4チャンネルで十分だと判断しました。
OLEDディスプレイ
ペンダントには情報表示用のディスプレイを搭載しています。定番のSSD1306搭載OLEDディスプレイを秋月で買って試し、HS96L03W2C03をPCBAして使っています。マウスセンサー同様、こちらもOLEDのドライバーが用意されていますので、とても簡単に実装できました。ペンダントとして独立しているので、比較的大きいディスプレイを搭載することにしました。くっつきーは動的なパラメーターが多いので、OLEDのページ切り替えで実装しています。ついでにFWバージョンを表示したりと、デバッグに活用できそうな情報も出しています。
ケース
ケースはあまり変化していませんが、初期は寸胴のI字型で、底面と上面の爪がより明確にある形でした。その後、方向が分かりやすいようT字型に変更し、爪は積層痕で固定するようなゆるい固定にしています。爪が折れにくいのは良いですが、少し固定がゆるすぎたのは課題です。なお、ケースにある文字はエンボスとして用意して印刷しました。おまけ程度に用意したものですが、あった方が良さそうで、光の加減で読めたり読めなかったりするので、いずれ多色刷りにして読みやすくすると思います。
トラックボール編
トラックボールは、様々な側面で開発に苦慮したモジュールでした。特に厄介だった点は次の2つです。
1つ目はICの特殊性です。マウスセンサーは何を使うにも入手性が悪く、数十程度の規模ではAliExpressなどでのリセールで入手する必要があります。公式からの卸しも規模が小さいとできず、JLCPCBで購入したりPCBAできるセンサーもない[1]ため、諦めてはんだ付けしています。さらに、SPI接続のものしか見かけず、他のモジュールと別の仕組みとケーブルが必要になりました。2つ目はケースの設計です。わずかにずれるだけでも動きを認識しないことがあるため、繊細な調整が必要でした。しかも球が上手くはまって回り、落ちない必要もあります。
他のモジュールと色々異なった結果、JLCPCB、LCSC (Custom Cables)、JLCMCと幅広いJLCグループ会社を活用したモジュールになっています。
ADNS-5050と球
トラックボールモジュールは、手元にあったmeishi trackballを参考に設計しました。センサーは同様のADNS-5050を選択しました。QMKでもドライバーが用意されているため、安心感があります。ボールは信頼のペリックス 34mm パールホワイトを使っています。
ADNS-5050ではセンサーとは別にLEDを用意する必要があります。meishi trackballで使われているものが見当たらず難儀していましたが、JLCPCBの海を彷徨ってそれっぽい直角LEDを何とか発見できました（XL-C4040UBC）。また、今回は青色LEDを採用しました。一般的な赤色より読み取り精度が向上するかも、という情報をどこかで見たので試してみました。
が、実際に使ってみると、赤色の球だと認識しないということが判明しました。実装する前に気付くべきでしたが、データシートの内容と色の特性を考えるとさもありなんです。まず、青色LED（XL-C4040UBC）のデータシートを見ると、波長のピークは460nmです。藍色から青色の間くらいです。この光が照射され、トラックボールの球に当たり、反射した光をADNS-5050が認識すれば反応します。そもそも色が見えているということは、その物体が吸収しなかった波長の光を反射した結果ということです。例えば、赤色の球はざっくり言えば赤色以外の波長を吸収しています。そのため、今回使った青色LEDに対して赤色の球を使うと、多くが吸収されてしまいます。また、ADNS-5050も680nmほどに認識のピークがあり、460nmは6割程度の反応率です。すなわち赤色に特化しているため、多く吸収されてしまうと反応できる光量が得られません。
光の波長と色の関係 ref: http://ene.ed.akita-u.ac.jp/~ueda/education/sentan/photochemistry/principle.htm
ADNS-5050の波長に対する反応特性
製品版ではほぼ白の球を使い、無事青色LEDで反応するようになりました。ケース越しにぼんやり光るのは面白いポイントです。
ぼんやり光るタマ
余談ですが、トラックボールの球といえば赤だったのは、普及していて安価なLEDが赤色だということに関係していることに気付きました。なお、昨今の高機能センサーは赤外線が多く、可視光線の制約に縛られません。反応するかは材質など様々な条件によりますが、基本的に使える球が増え、考慮すべき事項が減りそうですね。
ZH 6ピンでの接続
本来はキーモジュールと同様にI2Cで処理したかったのですが、ADNS-5050をはじめマウスセンサーはSPI通信が多いです。そして何故か3線式（MOSI/MISOが共通）が多い。つまりI2Cで使われる4pinケーブルでは線が足りません。SPIとI2CのブリッジをするICを使うことも考えましたが、やりたいことに対し非常に高価な解決策となってしまいます。そのため、別のコネクタとして6ピンのZHコネクターを採用しました。また、SPI接続のため、ペンダントから直に接続する必要がありました。
6ピンはGND,VCC,SDIO,SCLK,NCS,NRESETという順にアサインしています。ペンダント側でも同じ順番になっており、リバースケーブルで接続します。実際NRESETは使いませんでした。トラックボールだけリセットすることが無かったので、MOTIONを割り当てる方が有用ですね。
トラックボールのケーブルピンアサイン
ZHコネクタは1.5mmピッチなので2.0mmピッチのHYより小さいですが、しっかり固定できます。ただし、ZHコネクタは完成品のケーブルの入手性が低いという問題があります。ZHの6ピン、両方の端子を実装したリバースケーブル、かつそれなりの長さというものが全く見つからず、何とかマルツオンラインでA06ZR06ZR28H305Aという30cmのケーブルを発見しました。
ペンダントとの距離はそこまで離れないかと思いましたが、実際短いとのフィードバックもあったため、最終的にLCSCのCustom Cableを使いました。詳細は省きますが、これは好きな仕様のケーブルを作ってくれるサービスです。何度か（こちらの指定ミスで）失敗しましたが、無事製造でき、現在トラックボールに付属しているケーブルは100cmになっています。価格も元々のケーブルより（一定数作れれば）若干安くなりました。
ベアリングへの挑戦
折角トラックボールを自作するならベアリングを試したい！という気持ちがあったので、設計当初からベアリングを使うことは決まっていました。過去にトラックボーラーだったこともあり、滑り出しの滑らかさとメンテナンスの容易さに憧れがあったのです。ベアリングは高価な部品というイメージがあり、実際に店頭で探してみると1つ150円から300円がザラでしたが、JLCMCで探してみると50円を切るものもありました。そのためJLCMCで小さめのベアリングを探し、それで設計をしてみることにしました。実際に届くと、かなり小さいかと選んだベアリング（BCTA-P-605）が意外と大きく、設計に難儀することになりました。
ケース設計に関わりますが、3Dプリンターで軸を作るのは難しいので、丸型の黄銅スペーサーを軸として使い、それにワッシャーとネジを組み合わせ、回転するように固定しています。
1つのベアリングを固定するのに必要なパーツ
ケース設計
トラックボールモジュールのケースは、最も試行錯誤しました箇所です。特にレンズと球との距離調整が難しく、僅かな高さの違いが影響して反応しないことが度々ありました。設計上難しいのが、ベアリングを付けると高さが変わる点です。ベアリングが無い場合は上手く反応しても、付けると高さが変わり反応しないことが度々ありました。全体としての高さは抑えつつ、センサーへ干渉しない適度な距離を持ち、球が飛び出ないように爪で支えつつベアリングに上手く接地する、という条件を満たす必要があり、長い期間試行錯誤していました。何とか動いたのが今の形です。
また、ケースは下部の土台部分、上部のそれ以外部分に分かれています。組み合わせは下部パーツにある爪で行い、パチっと止まるようになっています。基本外さないですが、一応外しても爪が割れない程度の塩梅に調整しています。
ハブ編
現状、ハブはただコネクターが並んでいるだけなので、回路設計上の工夫は特にありません。また、ケースも比較的素直な形です。特筆すべき開発エピソードはありません。
なお、ここまで本文中に出てきた3DモデルはGithubで公開しています。
ファームウェア
ファームウェアはQMKをforkしてユーザー部分のみ改変し、Githubにて公開しています。フルモジュラー方式、VIA（REMAP）に対応し、システムを支えています。また、コンセプトを実現するため、トラックボールとオートマウスレイヤーの調整、ロータリーエンコーダーの解像度など、かなり細かく調整可能なパラメーターを用意しています。
このような仕組みを実現するには、QMKの内部処理にある程度潜り、理解する必要があります。
まず、肝心のキー入力がI2C経由で届くため、デフォルトの処理では実現できません。詳細は「自作キーボード入門 バラバラなキーボードのつくりかた」で細かく記載したので詳細は省きますが、キー入力部分が弄りやすくなっているので、システムに合うよう改変しています。
また、トラックボールも結局ドライバーを作成しました。というのも、「2つ以上の」トラックボールが「接続されているか分からない」状態に対する考慮がないためです。普通のキーボードでは全く問題になりませんが、接続したり外したりされるくっつきーでは対処が必要です。まず認識をする部分と、複数のトラックボールをそれぞれ処理し、動きをマージするドライバーを別途作成しました。センサーに対する処理自体は既存のコードがほぼそのまま使えました。
さらに、エンコーダーの解像度変更も躓くポイントです。25keysさんの記事で詳しく書かれていますが、現状コア部分をいじらないと実現が難しいです。今回のファームウェア開発では、最新バージョンに対応しやすくするため、ユーザーランド部分での改変のみで無理やり実現しています。やや挙動が怪しいもののそれっぽい動きをしています。
一般に有名なキーボードのファームウェアは、一定以上の調整をしたい場合、エンドユーザーがどこかでビルドをしてバイナリファイルを生成し書き込む必要があります。これが「動的」な調整を行うというコンセプトと合わず、なかなかに悩む日々を過ごしています。QMKはユーザーが書き換えられるweakな関数が多く柔軟性が高いので、今のところコア部分をいじらず何とかなっていますが、将来的にどうなるかは分からないところです。
まとめ
あまりにも記事を書くのが遅すぎて、考古学的な調査が必要でした。開発ログは定期的に出さないとだめですね。
1年間以上に渡るキーボード開発は、想像以上に大変で挑戦的なプロジェクトでした。プロトタイプから製品版まで、各段階で新たな課題が見つかり、本当に出来上がるのか不安な日々でした。最終的には何とかなり、またそれを解決する過程で多くの技術的知見を得ることができました。特に印象的だったのは、制約が創造性を生むという体験でした。高さ制限、サイズ制限、コスト制限など、様々な制約の中で最適解を見つける過程で、予想していなかった解決策が生まれました。
構想でしかなかったキーの分離と、それを固定する仕組み、FWの改変などを含めモジュラーシステムが実際に動作できたのは大きな成果でした。基本的な機能はすべて実現でき、加えてFWのパラメーター調整など、コンセプトを支える機能も追加でき良かったです。一方で、まだまだキーボードとして追求できる点は多く、さらに追加できる機能、撤廃できる制約、製造上改善できる点も多く見えています。くっつきーはまだ発展途上の製品で、それだけに改善の余地も大きく、今後さらに魅力的な製品に成長できればと思います。
現時点で開発は少しずつ進んでいますが、新しい取り組みも多く、製品として出せるのは来年になりそうです。今後の情報はくっつきーのSNSなどをご確認いただけると嬉しいです。なお、大きなお知らせは（自称）くっつきーの日、9/29に出す予定です（お知らせの日をGoogleカレンダーに追加）。
商品ページがあるもので試しにQuoteをしても失敗しました。パーツをこちらで入手してJLCPCBに送りPCBAしてもらうConsign Partsは可能です ↩︎