改造キーボードへの沼(令和版NeXTキーボードV2)

改造キーボードへの沼(令和版NeXTキーボードV2)

この記事はあくあたん工房2023アドベントカレンダーの22日目です.

どうもomzn教授(キーボード改造学)です.
まもなくクリスマスですよ.クリスマスプレゼントに自作キーボードなんか贈ったらダメですよ.

この記事は,1週間前からの続きです.

令和版NeXTキーボード V2

実は無改造のNeXTキーボードも1台所有しているのですが,こちらはジャンク品で通電しても動かなかったものです.
こいつも改造してしまうことにしましょう.

ちなみに2023年12月時点でNeXTキーボードのeBay価格はご覧の通りです.

もったいなくてハラハラしますね…

さて,今回は以下の3点を実現します.

  • パターンカットしない
  • 物理キーを互換品に変更
  • 光らせる

キー配置

今回のキーボードは前回のものよりも,多少新しい時代に製造されたものです.(それでも1990年代前半です)キー配置も似ているのですが,Returnが逆L字になり,そのあおりを食ってバックスラッシュキーがテンキーパッドに押し出されています.

ここはちょっとどうにかしてやらないと使いづらそうなところですね.
また,刻印が昔のMacintoshっぽくなってきています.

物理キー

こちらのキーボードはALPS黒軸を採用しています.ALPS黒軸はクリーム軸の後に採用されたものですが,キーのクリック感がややマイルドになっています.

キーマトリクス解析

キーボードのマトリクスパターンを解析します.目視とテスター片手に裏面のパターンを追いかけます.今回はパターンカットをしない縛りで作っていきますので,既存のマトリクスを最大限利用することになります.また,Raspberry Pi Picoを載っける基板を作り,オリジナルのコントローラを抜いたところにはめ込んでやります.

解析結果を以下の図に示します.

近いキーがコンパクトにまとまっていて,8x10に収まりそうな感じのきれいなマトリクス・・・と思ったら,モディファイアキーだけ飛び出してしまっています.なんじゃこりゃ.よく見るとR10と書いた行はGNDです.てことは,これらのキーはマトリクスではなく,ダイレクトキーになっているってことですね.

さすがにそこまで富豪なピンがあるマイコンは使っていないので,モディファイアキーもマトリクスに統合します.GNDだったパターンを追いかけてジャンパを抜いてGNDから外して1本のバスにしてしまいます.
最終的に決定したマトリクスは以下のようになります.モディファイアをどこの列に統合するかは,今回作成するPi Pico基板の都合でPCBを作りやすいように決めています.

このマトリクスをPi Picoへ変換する基板を作ります.この基板の上だけで,モディファイアキーの列の統合も行います.そのおかげで今回はほとんどジャンパワイヤを飛ばす必要がなくなりました.


設計したらElecrowに発注.基板制作費は$1.00. 送料が$15ほどで1週間弱で届きます.バグの入り込む手配線を必死でやるよりはお金で解決した方が良かろうということです.

実装

キーの裏からLEDでキーを光らせたいと思っているので,どうにかならないかといろいろ眺めましたが,結局スイッチを全部取り替えることにしました.

基板は片面パターンなので,はんだ吸い取りは簡単にできます.
しかし,古い基板なので銅箔パターン自体がもろくなっており,簡単に剥離してきます.
細心の注意を払いながら,はんだ除去とスイッチの撤去を行います.

外して…

外して…

外して…

じゃーん

キースイッチはFILCOダイレクトさんから,Matias Click Switch Gray(タクタイル)とWhite(クリック)を入手しました.テンキーだけ,Whiteでカチャカチャ言うように作ってみます.

さらに表面のジャンパもLEDストリップが通るところは邪魔になりますので撤去して裏面に再実装します.はんだ吸い取り線の消費速度が異常です.結局実装されていた部品の9割以上は外す羽目になりました.

ついでに,Caps Lock LEDを白色LEDに変更します.

続いて,光らせるためのLEDストリップを敷設します.LEDストリップは,よく見かける10mm幅のものだとキースイッチに干渉しそう(ギリギリでなんとなならないこともない)なので,今回は5mm幅のものを入手します.制御はWS2812のドライバでできるので,安心です.

1列目…

2列目…

全列…

点灯!

これで基板のほうでやることは終わりなので,キースイッチをはんだづけしていきます.
キースイッチをはんだづけしてしまうと,LEDストリップには手が出せなくなるので,接触不良のダブルチェックが必要になります.実際,後述するようにキーを全部付けた後で,一部のキーの不認識というバグを出しました.

仕上げ

キースイッチをはんだづけし終わった頃に,キーマトリクス変換基板が深圳から届きました.



基板上にはI2CとWS2812用のコネクタも引き出しています.
これを使ってRaspberry Pi Picoとキーボード基板の橋渡しをします.
基板にバグさえ無ければ,ワイヤを1本も繋ぐこと無く配線作業が完了です.

試験点灯,ヨシ!

透過OLEDもI2C経由で取り付けます.
ここらはV1と全く同じなので,簡単にできます.

後は組み上げるだけです.

完成

できました!


QMKのコードは以下に置いてあります.

RGB LightingとRGB Matrix

QMKには2種類のRGB LED制御があります.RGB Lightingはws2812のようなシリアルLEDを操作するための機能,RGB Matrixはマトリクス構造になっているLEDを制御するドライバを利用するためのものです.ただ,RGB Matrixでもws2812がサポートされています.

RGB Lightingは最初からシリアルLEDを使う前提なので,設定が楽です.通し番号だけで制御できます.また,レイヤーへの対応などがサポートされています.きれいなアニメーションが用意されています.

RGB Matrixは汎用のマトリクス制御なので,LEDとキーの対応を作ってやらねばなりません.これがまあまあ面倒で,キーマトリクス→LEDマトリクスの対応表と,LEDマトリクス→物理キーの場所の対応表の2種類を作らねばなりません.アニメーションも用意されていますが,こちらはタイピングに反応したアニメーションが利用できるのが強みです.

こんなExcelを書いて,コードに落とし込んでやります.


どちらの方法でも同じことを実現はできそうですが,自分で作ること考えると出来合いのものを使いたくなりますね.

キータイプに反応して光るのはこんな感じになります.

なお,ws2812を使う場合は,これら2つの方法を共存させることはできません.

バグとか途中の失敗とか

  • 当初,メイン基板のLEDの点灯方法を勘違いしていて,5VラインをGNDだと思っていました.そのまま最初の変換基板を作ってしまったので,大幅なやり直しが必要になり,結局再注文しました.
  • LEDストリップを敷設後,キースイッチを全てはんだづけした後で,キーマトリクステストをしたら,1行分が反応無しになりました.テスターで調べていると,LEDストリップを接続したときだけ5Vと当該行がつながってしまっていました.これは,ジャンパワイヤを付け替えたときにほんの少し表に出た部分がLEDストリップの5Vと接触していたためでした.

おわりに

古いキーボードを改造して現代によみがえらせる遊びは楽しいですよ.
私自身,20年前には持っていなかった電子工作のスキルを得て再改造を試みると,できることが増えていて嬉しかったです.

1990年代のメカニカルスイッチ採用のキーボードは打鍵感も良いので,よみがえらせる価値があります.

みなさんもジャンク屋でよさげなキーボードを見つけたら即確保!

では,Merry Christmas and a happy new year!

改造キーボードへの道(令和版NeXTキーボードV1)

改造キーボードへの道(令和版NeXTキーボードV1)

この記事はあくあたん工房2023アドベントカレンダーの15日目です.

omzn教授(キーボード改造学)です.
本日は古いキーボードの再生についての講義をしましょう.

平成版NeXTキーボード

まだ若かりし頃,2000年代に古いコンピュータを改造して最新のPCに換骨奪胎するという遊びに興じていました.
NeXT cubeとか,NeXT stationとか,Macintosh LC II(だったかな),Mac G4 cubeとかを改造して,ミニPCを作る遊びです.
苦労する割には,たいした性能もだせず,熱設計が破綻しているのですぐ暴走するというろくでもない機械を生み出していました.
犠牲になった古いコンピュータには悪いことをしたと思っております.

その流れで,NeXTキーボードの改造をしていました.NeXTのキーボードはMac系のADBぽい何かでしたが,当時は単なる使えないキーボードでした.
そこで若きomznは閃きます.


「そうだ,ここに転がってるジャンクのPS/2キーボードからコントローラを取り出して移植したら使えるようになるんじゃないかな」

早速キーボードの仕組みを調べると,キーボードにはキーマトリクスデコーダが乗っていること,そして,都合の良くないことにキーマトリクスはみんなバラバラということでした.

「せっかく分解したPS/2キーボードを何とか活かしたいな…」

ここでomznはまた閃きます.

「そっか,このPS/2キーボードに合わせてNeXT側を配線し直してやればいいんだ」

こうして魔改造されて生まれたのが平成版NeXTキーボードでした.



当時の標準規格だったPS/2にしておけば大丈夫だろうと思っていたのですが,時代はすぐにUSB全盛になり,NeXTキーボードはUSB変換をかまされたまま20年近く利用されました.ただ,元々PC/AT用のキーボードだったため,Macとの相性はあまり良くなく,キー入れ替えソフトが必須の状態で使うことになりました.また,ファンクションキーへのアクセス手段がないので,時々大変困ることになっていました.

そのため,20年の間,「いつかは今風のキーボードに作り直したい…」という思いを引きずっていたのでした.

令和版NeXTキーボード V1

2023年秋,ゆゆ君がキーボードを自作したのを見せてくれたので心に火が付き,自作キーボード化への完全移行を目指すようになります.

基本的にやることは以前と同じで,物理マトリクスに合わせたマトリクスデコーダを作ることになります.これが簡単にできる仕組みを提供してくれているのが,QMKです.

レイアウト

Fキーがないことを除けば,普通のキーボードに見えます.Backquoteがテンキーパッドにありますが,まあご愛敬.

物理スイッチ

NeXTキーボードではALPSクリーム軸を採用しています.軽やかなクリック感がクセになります.
(ALPS軸についてはこちらのサイトが非常に詳しいです.また,こちらの記事も大変興味深いものです.)

マトリクス解析

以下の図の上は,20年前に私がWebページに載せていたPS/2キーボードのマトリクスです.
非常に贅沢にマトリクスを構成していたので,このままだとマトリクスのピンが25本も必要です.
カラムのORをとってもキーコードがかち合わない場所は単純に統合可能なので,3つのカラムを減らすことができました.(図の下)

これでもまだ22本のGPIOが必要です.
一般的なPro MicroですとGPIOが18本しか使えないので,今回はRaspberry Pi Picoを使用します.Raspberry Pi Picoは26本のGPIOを利用できますので,今回の用途に使ってもまだ4本のGPIOが余ります.そこをLEDの駆動やI2Cに割り当てることで,さらに機能を増やすことができます.

ハードウェア作成

Raspberry Pi Picoを載せる

これまでPS/2コントローラに接続されていたすだれケーブルを切断して,Pi PicoのGPIOに繋いでいきます.
今回は初回の試作だったので,そのままはんだづけしましたが,ソケットで取り外し可能にするのがベターですね.


USBの端子を設置する

3Dプリントで土台を作成して,USBの口を作ります.写真では試作時なので赤で作っていますが,最終形は黒にしています.


最終的にはこんな感じになります.改造前に比べると余計な基板が無くなってすっきりしました.



QMKの設定

キーボードの設定

  • このキーボードのように,ダイオードが実装されていないマトリクスではMATRIX_HAS_GHOSTをdefineします.
  • CapsLockのLEDをGP0で制御します.


キーマップ

先ほどのマトリクスに忠実にキーマップを書いて行きます.

  • NeXTのPowerキーをFnキーとして利用
  • Volume up, Volume downをPage up, Page down (Fn押下で本来の機能)
  • Brightness up, Brightness downをHome, End (Fn押下で本来の機能)
  • 「Fn + 数字」で 「F1~F10」
  • 左Commandキー単独で「英数」,右Commandキー単独で「かな」

等の機能を追加しています.
Esc周りはやや特殊で,単押しでEsc, Shift + Escで「〜」, Shift + Alt + Escで「`」が出るようになっています.


利用するGPIOとマトリクスの対応はinfo.jsonに書きます.


KLE でグラフィカルなキー配置を作成する

VIAやRemapでキー配置を変更する時のGUI用に,KLEでレイアウトを作ります.



ここでハマりましたが,肝はキートップのLegendにマトリクスの座標を書いてやることです.
PS/2コントローラのマトリクスが物理配列と全く合っていないので,この図では座標がバラバラになっています.

VIAの設定

via.jsonを作ります.これは,RemapなどのツールでキーマップをGUI的に変更するときに使います.
中身は,KLEで作成したキー配置のデータと,キーボードの名前,Vender ID, Product ID,matrixの行列を記したものになります.


できあがり!

ここまでで,一旦キーボードはできあがりです.

ファームウェアを焼いてやれば,キーボードが使えるようになるはずです.

qmk flash -kb next_keyboard_v1 -km via


ソースコードは GitHub に置いています.

(おまけ)OLEDパネルを追加する

キーボード単体だとちょっと寂しかったので,透過OLEDを使ってHUD風ディスプレイを付けて見ました.蛇足感が酷いです.



実はここまでの話は前座に過ぎなかったのです.
長くなるので本編は次の記事で..

ヒョウモントカゲモドキの孵卵器を自作する

ヒョウモントカゲモドキの孵卵器を自作する

この記事は あくあたん工房2023アドベントカレンダー の8日目です.

こんにちは.トカゲ教授omznです.

昨年から飼い始めたヒョウモントカゲモドキ(Leopard Gecko)ですが,あくあたんシステムの一部を間借りして管理していたのですが,今のところ下の図に示すようになっています.(クリックで拡大)いまや,水槽よりもこっちの方が遙かに大きいシステムになってしまいました.


そもそもトカゲ用のケージが4つもありますからね…


今回の記事

今年はヒョウモントカゲモドキが産卵するようになったので,試行錯誤を重ねて孵卵器を作成しました.
このたび,自作孵卵器で最初の卵が孵化しましたので,ここに記録しておきます.

ヒョウモントカゲモドキの卵

ヒョウモントカゲモドキは一般的に1度の産卵で2個の卵を産みます.
ケージ内の底床を掘って作った産卵場所に産んだ後,埋め戻しますので,掘り出して孵化器に移します.産んだメスは卵を回収された後も,けなげに産んだ場所に土をかけたりして隠そうとしていますが,無駄な努力なのだよ….


卵は柔らかい卵殻になっていて,さわるとふわふわします.誤って転がしたり落としたりすると卵は死んでしまいますので,掘り出した時に上側だったところにマジックで印を付けておきます.以後,必ずこの印が上になるようにして保管します.
保管場所はタッパーなどに水苔を敷いたものを準備して,これを孵卵器の中に入れておきます.時々,水苔が保湿されているかは手動で確認します.


ヒョウモントカゲモドキの卵の管理

ヒョウモントカゲモドキの卵は,温度26℃〜34℃,湿度80%〜90%で管理するとよいとされています.また,温度にも依りますが,40日〜70日で孵化すると言われています.
結構長丁場なので,静かに温度湿度が安定した場所に置くのが良いようです.なお,今回の卵は,28℃で管理し続けたところ,53日で孵化しました.その後も53日前後で2つの卵が孵りました.


湿度

湿度が十分でないと,卵が乾燥してしまい死んでしまうことになります.また,高すぎてもカビが生えたりするようなので,あんまりびしょびしょなのも良くなさそうです.
そこで,孵卵器内部を常に一定の湿度に保ちたいと思います.加湿については,特に何もしなくても孵卵器内部に水分を含んだもの(水苔とか)を置いておけば勝手に加湿されますので,上がりすぎた湿度を下げる方針で孵卵器を作ります.

温度

温度依存性決定(TSD)により,孵卵中の温度によって性別が決定されます[1].
(なお,孵卵温度を28℃以下にしておくとほぼ100%メスになります.)
そのため,性別を固定するのであれば,温度の管理は必須になります.

ヒョウモントカゲモドキの温度依存性決定([1]より引用)

性別に関わらず,26℃以下にしないほうが良いので,何らかの保温装置が必要です.ここではシートヒーターを使って温度を上げる方に保ちます.私の飼育環境では24時間全館冷暖房が効いているため,室温は常に26℃前後になっています.そのため,室温が高すぎて冷却が必要な環境では,冷却についても考慮してやらねばなりません.

孵卵器の実装

上記の管理方針に従って,孵卵器内の温度・湿度を調整する機構を作ります.
必要とする部品は以下の通りです.

  • M5 HUB Switch D (2チャンネルAC100Vリレー)
  • M5ATOM Lite (M5 ATOM S3, M5 ATOM S3 Lite等,何でも可)
  • DCファン (5V駆動)
  • ENV III Unit (SHT30温湿度センサ)
  • MOSFET (2SK4017)
  • 10kΩ抵抗 x 2
  • シートヒーター
  • ダイソーのシューズケース

孵卵器本体は,ダイソーのシューズケース(小型)を使っています.普通の大きさのシューズケースでも構わないですが,ちょっと広すぎて持て余すかもしれません.また,小型は大きめのダイソーにしか置いてないことがあります.卵が10個ぐらいまでは小型でいけるのではないかと思います.100円なので加工をするのにもためらいがなく,とても良い素材です.



湿度の管理のためにはファンを実装します.



M5ATOM Liteの25番ピンを通じてMOSFETにPWMを送り,0〜255段階でファンを回します.(実際には起電力が必要なので,PWMは65ぐらいからにしないとファンが回りません.)
ファンは孵卵器の蓋に開けた穴に設置し,内部の水分を外部に放出する方向にファンを回します.
湿度自体はENV III UnitのSHT30で計測します.温湿度センサなので簡単に温度と湿度を得ることができます.
ファンは湿度を入力とするPID制御を採用して駆動させます.ファンを動作させると湿度は敏感に反応するので,湿度取得間隔は2秒程度と短くしています.実際は閾値でON, OFFするだけでも良いと思われますが,そこは勉強も兼ねて次のようなコードで実装しています.

int Fan::manageByHumid(float h) {
  const float dt = 2;
  const float kp = 10, ki = 1, kd = 10;

  static float diff_p = 0, diff_c = 0, integral = 0;
  float p, i, d;
  int prev_power = fan();

  diff_p = diff_c;          // 湿度の差 (%)
  diff_c = h - _target_humid;  // 湿度の差 (%)
  integral += (diff_c + diff_p) / 2.0 * dt;
  integral = integral > 50 ? 50 : (integral < -50 ? -50 : integral);

  p = kp * diff_c * (diff_c < 0 ? 5 : 1); // 1 % で pwm 10 :負の時は x 5
  i = ki * integral;                //
  d = kd * (diff_c - diff_p) / dt;  // 1% で pwm 10
  float power = p + i + d;
  int ipower = constrain((int)power, 0, 255);
  DPRINTF("humid: %.1f, target: %.1f, power: %.1f (%3d)\n", h, _target_humid, power, ipower);
  fan(ipower);
  return (ipower && !prev_power || !ipower && prev_power);
}

温度の管理はシートヒーターをACリレーで駆動します.
M5 HUB Switch Dを使うと,100V電源でATOM Liteを動かせるので,余計な配線が不要になります.
また,M5 HUB Switch Dの本体にある2つめのGROVEコネクタは25番ピンを引き出していますので,上述のファンの回路をこのGROVEコネクタの先に作ればよいことになります.温度変化は湿度ほど短時間ではありませんので,こちらは上限下限の閾値を定めてON, OFFを制御します.

最終的な見た目はこんな感じになります.


ソフトウェアは,自身で作成中の汎用環境センサシステムを使います.利用するモジュールのみをソフトウェアで有効化できるので,重宝しています.また,Raspberry Piにより温湿度等を記録するサーバを作っています.

孵卵器モニター

温湿度の現状,これまでの履歴,そして卵の孵卵日数を記録するための孵卵器モニターも作成しています.



1つ目の卵は初めてでしたので,リビングのトカゲケージ横で見守りました.2つ目以降は納戸にシステムごと移しましたが,納戸のほうが人間の活動が無い分,湿度が安定することが分かりました.


幼体も飼えます.

ヒョウモントカゲモドキの幼体は親に比べて高温・高湿度環境が必要なので,幼体飼育ケージにも全く同じシステムを流用できます.幼体ケージもダイソーのシューズケースで作っています.
幼体は湿度をおよそ70%〜80%でキープするように設定し,M5 ATOM S3の液晶に現在の状態を表示させています.


コオロギも飼えます.

同じシステムを流用するとコオロギの維持管理にも使えます.今年はこれを使うことでフタホシコオロギを3世代に渡って飼育を続けることができています.(現在進行形)
コオロギは湿度60%ぐらいをキープなのですが,それでもうまいこと維持できています.
今年はコオロギ牧場が続くといいな…



参考文献

[1] J. M. Hall, Temperature dependent sex_determination in reptiles, Herpetoculture Magazine, isseue 17, March 2021, https://www.researchgate.net/publication/349718375_Temperature-dependent_sex_determination_in_reptiles

コオロギ牧場の夢

コオロギ牧場の夢

omznです.
この記事はあくあたん工房 Advent Calendar 2022の16日目です.

2日目のヒョウモントカゲモドキさんのお話に引き続き,今度はヒョウモントカゲモドキさんの生き餌,コオロギ飼育のお話です.

警告: 今回は虫成分多目です.

ヒョウモントカゲモドキは人工飼料も食べますが,生きたコオロギや冷凍コオロギもよく食べます.
気分屋なので,あるときは人工飼料しか食べなかったり,あるときはコオロギしか食べなかったりします.
コオロギは野山で採集してきても良いのですが,コオロギファームから養殖コオロギを購入するのも手軽です.
養殖コオロギは「ヨーロッパイエコオロギ」,通称イエコという種が有名です.
西南アジアが原産国のようで,ペットや餌用として世界中に広まっている種類です.
爬虫類を扱う別途ショップなら1匹15円程度,通販なら1匹5円程度で手に入ります.
1年中繁殖可能で2,3ヶ月程度で成虫になりますので,きちんと世話ができるなら素人でも養殖できます.

餌が勝手に育ってくれて,どんどん供給されるならこんな嬉しい話はありません.
だれもが一度はコオロギ養殖を夢見ることになります.

さて,omznも例に漏れず,イエコを養殖してみようと思った次第です.
手始めにネットショップでイエコ成虫を400匹購入しました.200匹はすぐに冷凍して,200匹を飼ってみることにします.

ケージは掃除が楽なように,底床などは一切敷かず,トイレットペーパーの芯で作った隠れ家,水を供給するタッパ,そして産卵のための土のタッパを置きます.

どどっと200匹を放り込んだ状態がこれです.

メスたちは一斉に土に産卵を開始します.卵が土からはみ出るぐらいまでびっしりと卵が採れます.

200匹も少しずつ捕獲して冷凍していき,最終的にはすべてを冷凍するので,卵だけが残ります.
あとはこれを一定の温度・湿度を保ったまま2週間保持します.

2週間後,孵化しました.すごい勢いで体調1mm程度の幼虫がわいてきます.

これを大きくなるまで育てれば,十分な数の冷凍コオロギが確保でき,また,産卵するのに十分な数が残るでしょう.

自家製コオロギ牧場への第一歩をここで踏み出したのです.

 
 
 
 
 
 
 
 
 
 
 
 

さて,ヒョウモントカゲモドキのケージ内には,生き餌として与えようとしたけど,うまく逃げおおせて隠れたコオロギがいます.彼らも当然卵を産めます.
土はいくらでもあります.仮に捕食されても卵は残ります.温度湿度も問題なく維持されています.

当然,2週間ほど経つとケージ内でも幼虫が孵化します.
あ,水飲み場の近くに小さい幼虫がいますね.かわいい〜.

このまま大きくなったら,セルフ餌供給も夢じゃないですね!

 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 

ここから怖い話をします.

コオロギ養殖のケージはコオロギがよじ登れないような形状になっているので,体長1mmの初令幼虫といえども,よじ登って逃げたりはできません.

しかし,ヒョウモントカゲモドキのケージはそうではありません.天井まで届く石組や流木はあるし,天井は網だし,扉はあるし,換気のために隙間だらけです.

コオロギの雌は20個〜30個の卵を産みます.何匹が隠れているんだったかな…

 
 
 
 
 

おや,この原稿を書いている時に,何かが視界の端で動いた気がしますね….

 
 
 
 
 
 
 
 
 
 
 
 

いや,そんなまさか.

いやいや.
 
 
 
 
 
 
 
 
 
 
 
 

百歩譲って,幼虫が脱走したとしても,室内には食べ物も無いし,水も無いから,コオロギにとっては砂漠以下の環境のはず.

成虫になんかなれるわけないですよね.

 
 
 
 
 
 
 
 
 
 
 
 

ところで,このコオロギの名前って何でしたっけ.

 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

「ヨーロッパイエコオロギ」

 
 
 
 
 
 
 
 
 
 
 

いやいや,そんなまさか.

あくあたんはヒョウモントカゲモドキの夢を見るか

あくあたんはヒョウモントカゲモドキの夢を見るか

omznです.この記事はあくあたん工房 Advent Calendar 2022の2日目です.

2022年は自宅でヒョウモントカゲモドキを3匹飼い始めました.
あくあたんがイモリの化身で,ヤモリを毛嫌いしていることは広く知られているところですが,ヒョウモントカゲモドキはヤモリの仲間です.
あくあたんもやがて融和の時を迎えるのでしょうか.

今日はヒョウモントカゲモドキの魅力について述べていきましょう.

飼い始めると分かりますが,ヒョウモントカゲモドキは実にペット向きに進化した仕様を持っている爬虫類なのです.

飼育環境

爬虫類用のケージに赤玉土などの底床を敷き,1匹に1カ所の隠れ家(シェルター)を作ってやります.湿度を保つために,水入れなどを用意し,流木などで運動もできるレイアウトを整えてやります.

乾燥に強い

野生ではパキスタン〜アフガニスタンあたりの砂礫地帯に住むため,乾燥にとても強いです.これは乾燥しがちな室内で飼う際の大きなメリットになります.

食いだめが可能

さほど獲物が豊富なところに住まないので,食べられるときにおなかいっぱい食べて,尻尾に脂肪を蓄えます.餌をやるのを忘れがちでも大丈夫です.

人工餌でもOK

基本は昆虫(コオロギなど)を食べるのですが,フードにも慣れます.そのため餌の確保が簡単です.

生き餌もOK

コオロギなどの生き餌を与えると張り切って食べるのを見ると癒やされます.虫耐性がないとちょっと難しいところですね.ちなみに,生き餌をやり始めると,飼い主が外を歩く際にバッタやコオロギを無意識に探すようになります.今年の秋は山登りをするたびに数十匹のコオロギを捕獲していました.下は,山で見つけたモリオカメコオロギです.野趣あふれる味わい.

ヨーロッパイエコオロギは養殖コオロギの代表格で,1匹5円〜20円ぐらいで入手できます.コオロギが無限に入手できたら嬉しいですよね.うん,じゃあまず100匹ぐらいから育ててみましょう.

排泄が合理的

排便はいつもほとんど同じ場所に行います.犬猫でもトイレトレーニングしないと同じところでできないのに,彼らは最初から同じ場所でします.また,大きめの便を散らかさずに一度にするので,ピンセットでつまんでポイでお掃除が終わります.
さらに,液体の尿を出さないので,ケージの底床が汚れにくいのもありがたいです.乾燥地帯に特化して,液体は意地でも外にださないという体になっているのですね.では,尿はどうするのか?実は便と同時に尿酸の塊を排出します.つまり最初から結石を排出するのです.そのため,ケージ内でウンチを捜索する必要がほとんどありません.これはずぼらな人間にはとてもありがたい仕様です.ちなみにうちの子たちは3匹とも同じシェルターをトイレにしています.休息に使うにはちょっと小さめだったシェルターだったのですが,トイレにはちょうど良いらしく,お尻から入っていってウンチして出てくる,というお行儀の良さを見せてくれます.

また,秋にメスの1匹が無精卵を産んだのですが,このときもここを産卵場所にしていました.出てくる物は何でもここですることにしてる??

飼育サポートIoTデバイス

飼育のサポートをするために,M5Stack などを用いたIoTシステムをケージ周りにはり巡らせています.

照明システム

あくあたん水槽管理とほぼ同じシステムを流用しています.時間に応じて照明を制御します.

モニター

下で説明する温湿度管理・給餌回数管理・扉開放検知をM5Stack Core2の1つのデバイスで可能にした物です.サーバに貯めたデータをAPIで取得し,値やグラフの表示を行います.

温湿度管理

ヒョウモントカゲモドキは乾燥地帯に住むとはいえ,意外に湿度も必要とします.特に,隠れ家内は高湿度であったほうが望ましいようです.

そのため,ケージ内3カ所に温湿度センサーを置き,常にモニターしています.温湿度センサーはM5Unit Env IIIATOM Liteで利用します.今のところ,湿度を自動で添加できるようにはなっていません.そこまでする必要はないかなと思っています.

また,温度に連動してヒーターの制御も行っています.市販のヒーターは温度制御もできるのですが,せっかくなので自力で制御を作っています.
ATOM HUB スイッチキットを利用して,温度に応じたOn/Offを行っています.

給餌回数管理

どの子にいつ何回ご飯あげたっけ?という疑問を解決するために,個体別にいつ餌をあげたかを管理する仕組みを作りました.(手動)
過去10日間のグラフも見ることができ,餌の食べ具合を確認できます.

扉開放検知

脱走される原因は餌をやるときに扉を開けっぱなしにすることです.ちゃんとロックをかけないと自分で押して開けてしまいます.
そのため,わずかな扉のずれも感知して,一定以上の時間開放されていたら警告を鳴らすようになっています.
センサーには車のDIY部品のエーモン 【3229】開閉連動スイッチを使っています.マグネット連動の開閉スイッチなので検知の微調整を距離で行うことができます.

警告は,温湿度のグラフや給餌回数管理の画面でもモーダルなアラートとして割り込んでくるため,必ず何かの対応をしないといけないようになっています.
警告音もそれなりに大きいので,家に居れば気づきます.

過去の遺産の継承

今回のシステムを構築するに当たっては,ほとんどのサブシステムがこれまでにあくあたんや家のIoTなどで作ったものを一部改良することで,できてしまいました.いろいろな物を作り,それを再利用可能な形で保守できると,新しい何かを作るときのハードルがすごく下がりますよ!

チューリング完全あくあたん

チューリング完全あくあたん

この記事はあくあたん工房 Advent Calendar 2021の15日目です.

チューリング完全とは?

ある計算システムがチューリング完全であるとは,万能チューリングマシンと同じ計算能力を持つことを指します.万能チューリングマシンはチューリングマシンを模倣できるチューリングマシンであり,現在のどんな計算機が解ける問題でも解くことができると考えられています.

あるシステムがチューリング完全かを判定するのは難しい問題になるため,チューリング完全であることがすでに判明しているシステムの模倣ができる場合,そのシステムもチューリング完全であると言えます.

水槽カメラ昇降パターン

あくあたん義体はレールの上のマーカー(位置)を読み取って水平方向に進むことができます.また,レールの位置上でカメラの垂直方向を昇降させることができます.レールの位置はあくあたんbotからの指令により移動させることが多いですが,カメラの昇降については指令を飛ばすことが少なくなっています.そこで,カメラの昇降については,ランダムに近いけれども特定のルールを利用した動作をさせたいと思います.

レールの位置には1ビットの情報が付与できるものとします.あくあたんは位置上でカメラ垂直方向を上下させることができますので,ここではある位置において,カメラを1段上昇させるなら1,1段下降させるなら0とします.この情報をカメラ昇降パターンと呼びます.あくあたんはこの情報を使って,その位置を踏んだときにカメラ垂直位置を変更します.

各位置での昇降動作を初期状態としてあくあたんに教えることができます.

水槽カメラ昇降パターン更新規則

さて,このままではいつも同じ位置で上下するだけで面白くありません.
そこで,あくあたんが水槽の一番左か右(位置0か16)に到達した時点で,カメラを昇降させるパターンを変更したいと思います.

このパターンの変更は,各位置において,左右両隣の位置の状態に応じて変更するようにします.そうすると,次のような遷移表を書くことができます.3ビットの真ん中が当該位置であり,左右と自分自身の値に応じて,自分自身の変更後の値が決まります.

変更前(左,自身,右) 変更後
0, 0, 0 x, 1, x
0, 0, 1 x, 0, x
0, 1, 0 x, 1, x
0, 1, 1 x, 0, x
1, 0, 0 x, 1, x
1, 0, 1 x, 0, x
1, 1, 0 x, 1, x
1, 1, 1 x, 0, x

これを「カメラ昇降パターン更新規則(更新規則)」と呼びます.

例えば,上記更新規則では,ある時点のカメラ昇降パターンが「0001111000111100」であった場合,次のように更新されます.なお,実装の都合上,右端と左端はつながっており,ループしているものとします.

0 0 0 1 1 1 1 0 0 0 1 1 1 1 0 0
↓
1 1 0 0 0 0 1 1 1 0 0 0 0 1 1 1

更新規則は変更後のビットが取る値の並び8つで識別できます.上記の規則では01010101となります.すなわち 2^8 = 256個の更新規則のいずれかを採用することになります.この更新規則はビットの並びを2進数として読んだ値を10進表現した数字で表されます.例えば,上の表の更新規則は 01010101 ですから64+16+4+1 = 85で,更新規則85と呼びます.あくあたんにはこの更新規則番号を伝えれば,その更新規則を採用することになります.

あくあたんが一番左か一番右の位置へ移動すると,このカメラ昇降パターン更新規則が適用され,各位置でのカメラ昇降パターンが更新されることになります.

まとめると,あくあたん義体には「カメラ昇降パターンの初期状態」「カメラ昇降パターンの更新規則」を設定することができ,自律制御時のカメラ位置はこれに従って昇降させることになります.またあくあたん義体のレール上の移動に伴い,カメラ昇降パターンは次世代へと更新されることになります.

セル・オートマトン

ここまでで説明してきたカメラ昇降パターンを変化させる動作は,実は1次元セル・オートマトンと呼ばれるものと同じです.1次元セル・オートマトンは無限の1次元セルのビットパターンを更新規則によって変更し,世代を重ねていきます.2次元のセル・オートマトンの例としてはライフゲームなどがよく知られていますね.

1次元セル・オートマトンの256種類の規則は,どのような状態になるかで4つのクラスに分類されます.

  • クラス1: 最終的に全体が均質な状態に遷移するもの(規則248)など)
  • クラス2: 最終的に局所的なパターンを繰り返したり,安定状態になるもの(規則123)など)
  • クラス3: カオス的なパターンを示すもの(規則30)など)
  • クラス4: カオス的なパターンと規則的パターンが共存する(規則110)など)

クラス3に属する規則90は,1ビットのみが1の初期状態からフラクタル図形を生成することが知られています.クラス4は複雑な計算状態を内包することを表しています.そして,クラス4に分類される「規則110」はチューリング完全であることが証明されています.

規則110の遷移

変更前(左,自身,右) 変更後
0, 0, 0 x, 0, x
0, 0, 1 x, 1, x
0, 1, 0 x, 1, x
0, 1, 1 x, 1, x
1, 0, 0 x, 0, x
1, 0, 1 x, 1, x
1, 1, 0 x, 1, x
1, 1, 1 x, 0, x

チューリング完全あくあたん

つまり,あくあたんが「更新規則110」を採用していれば,あくあたんはチューリング完全であり,現代の計算機に匹敵する計算能力を持つことが証明されるのです.


あくあたんはまた1つ新しい高みに立ったのです.

あくあたんを崇めよ!
Make Aquatan Great Again!

あくあたん名(迷)言集

あくあたん名(迷)言集

この記事はあくあたん工房 Advent Calendar 2021 6日目の記事です。

ゆゆ君が2日目にあくあたんのリプについて触れていたので,そういえば昔のあくあたんの名言をスクショ保管してたなあと思ったので供養しておきます.

いろいろな人があくあたんと遊んでくれましたね…(遠い目)
スクショはいろいろな時代のが混ざっていますので,ツリーの表示方法も一様ではありません.
発言者は一様に隠させて頂きました.黒歴史だもんね.

煽り

のっけから厳しいの行きます.
あくあたんの伝統芸です.

誰であっても煽ります.

これも煽りだね.

もひとつ.

説教

おなかすいた

かわいい系.

おにぎりには一家言あるほう.

ありがとう

エロい?

変な学習しちゃった?

別の人とも

素直なあくあたん

癒やし

なんの癒やしだ.

なれ合い.

大きなカブ.

人生の意味

あくあたんだって悩みます.

帰れ

カエレ!

かわいい

暴言

その後

さらにその後.まさかのタクシオ氏.

さらにさらにその後.

一般の方と

おそらく相手はこっちがbotだと分かっていません.

思うところ

オマエモナー

南無南無

弄ぶあくあたん

まどマギ

時代を感じる…しかし,この話題への追従性.

風邪

正論だ…

しりとり

基本的にあくあたんはしりとりする気が薄い.

2回目はダメよ.

ごめんなさい

はかない単位よー

LINEスタンプにもなった名言の瞬間.

つらい

ざるざる事件

某OG氏の最高傑作かもしれない,ざるざる事件.

未だにあくあたんの語彙にザルって出ることがあったり.

まとめ

あくあたん昔のほうがキレがあった気がします.
あくあたんがbotだと知らない一般人さんとかとも会話が続くのやばいですよね.
これはチューリングテストに合格しちゃいそうだな…
チューリングと言えば… (15日目に続く)

バグの名前を探す話

バグの名前を探す話

この記事は,あくあたん工房Advent Calendar 2020の12日目です.

こんにちは.omznです.
一応,「あくあたん」の始祖なのですが,工房とはほとんど何の関係もありませんね.僕もあくあたん工房を知らないし,あくあたん工房も僕を知らない.まあそれで良いのです.

今年は何をしていたかというと,昨年までいろいろあったので心を癒やすためにずっと池田の五月山で山登りをしていました.
山ではずっとバグを探して写真を撮っていました.
ソフトウェアのバグを探すのは心がささくれますが,昆虫のバグを探すのは癒やしになります.

虫を見つけると,同定を行います.名前を探すわけですね.よく知ってる虫ならすぐに分かりますが,なんせ昆虫はやまほど種類がありますし,池田〜箕面は種類が豊富なことでも有名です.その結果,見たこともない虫を発見して,なかなか名前が分からないのが出てくるわけです.

今年,同定できた中で難問だったやつを紹介します.

この子ですね.一見してカミキリムシだとは分かります.
さらにトラカミキリ系だなということまで分かります.
時期は8月,エノキの木で発見しました.
問題はそこからです.カミキリムシは種類が多いことで有名なのです.

ざくっとググると…こんなサイトとかこんなサイトとかがかかってきますが,この写真と同じっぽいのが見当たりません.
アカネキスジトラカミキリが似ているのですが,微妙に違います.
余談ですが,アカネトラカミキリ,キスジトラカミキリ,アカネキスジトラカミキリ,というのがいて,種名が組み合わせテストみたいなことになってます.

発生時期や食料となる木の種類なども見ながら,ああでもない,こうでもない,と考えます.
この後,Google画像検索とひたすらにらめっこしつつ,「アカネキスジトラカミキリでいいのでは」「いや,何かが違う…」「いや,やっぱり…」みたいな(無駄な)ことを延々と考え続けることになります.

そうこうしているうちに,こちらを最初から全部見ていくと,上から3番目にそれっぽいのがいました.

ヤノトラカミキリ

あ,これだ.

試しにヤノトラカミキリでググるといっぱい出てきます.

ヤノトラカミキリ…北摂の生き物

まさにこれ.ていうか,見た場所も同じ.なんなら,この樹皮に見覚えがある.
ということで,同定完了です.「ヤノトラカミキリ」でした.なお,私が夏中ずっと山を歩いて虫を探していましたが,ヤノトラカミキリが見つかったのは,ある1本のエノキの木だけでした.そこでは1週間ぐらい連続で10匹以上発見しましたが,他では一切見つからなかったのでした.

最初にトラカミキリと当たりをつけたのでだいぶ枝刈りできましたが,カミキリムシだなあ,ぐらいから入ると気が遠くなる作業ではあります.

もうひとつ.今度はチョウです.

山に登るとヒカゲチョウというタテハチョウの仲間によく出会います.こいつらも種類が多いのです.

上の2枚の写真,しばらくの間,同じ種だと思っていたのですが,実は違う種でした.
上は「ヤマキマダラヒカゲ」,下は「サトキマダラヒカゲ」です.どっちも普通にいる種ですが,違いが微妙.
斑紋が全体的にくっきりしてるとかも特徴なのですが,決め手はこれ.

比較のために下の方は回転とフリップをしていますが,「羽の付け根の模様の一番下がくっついているか離れているか」が決め手なのでした.そんなん知らんがな….

最後に,難問ではないのですが,面白いチョウを紹介して終わりにします.

「クロマダラソテツシジミ」です.元々は東南アジアなどの南方のチョウなのですが,2007年に突然池田から宝塚にかけて見つかるようになりました.名前の通り,幼虫はソテツを食べて育つのですが,ソテツが南方から園芸・植木の盛んな池田・宝塚に持ってこられた結果,このあたりで見つかるようになったと思われています.なお,その後,関西にはすごい勢いで広がっていき,今では割とどこでも見ることができます.小さいシジミチョウですが,羽の模様は美しく,じっくり眺めていると飽きません.

まあ,そんなこんなで虫の写真をひたすら撮った1年でした.来年は何に会えるかな.

ソフトウェアのバグの研究が蔑ろになっているのはまた別の話…

崔 銀惠博士を偲んで

崔 銀惠博士を偲んで

私の妻であり,共同研究者でもあった,崔銀惠博士は2019年12月15日に逝去しました.享年45歳でした.4年間の闘病の甲斐なく,誰よりも先に旅立っていってしまいました.

崔銀惠博士は1993年に大阪大学大学院基礎工学部情報科学科に入学,1997年に大阪大学大学院基礎工学研究科情報数理系専攻博士前期課程に進学し,1999年に修士(工学),2002年に博士(工学)を取得しました.博士論文は「k-Coteriesを用いた相互排除方式の提案」でした.その間,日本学術振興会の特別研究員にも採択されており,とても優秀な学生でした.
2002年に株式会社東芝に入社,研究開発センターに配属されました.Xpathの検索技術などを研究し,国内外での特許も取得しています.2003年に退社し,その後,2004年に産業技術総合研究所(産総研)の非常勤研究員となります.産総研ではモデル検査や形式手法についての研究を行い,後に組み合わせテスト技法の研究を中心に行うようになります.正規雇用に転換した後,主任研究員として京都工芸繊維大学や大阪大学との共同研究を精力的に行いました.

彼女は生涯に61本の論文を公表しました.[論文一覧]うち22本は私との共著であり,そのほとんどは2015年以降に書かれたものでした.それ以前は,子育てなどもあり,あまり共同研究ができる環境ではなかったため,やっと二人で研究ができると喜んでいたのを覚えています.

共著論文として執筆したものの中で印象に残っているものはQuASoQ2016の論文「Code Coverage Analysis of Combinatorial Testing」[1]です.この研究では組み合わせテストにおける,t-wayテストのコード網羅性を実証的に調べたものです.これまで,t-wayテストはtが割と小さいときでも十分な不具合検出ができることは知られていましたが,コード網羅性については十分に研究されていませんでした.そこで,我々は実際のソフトウェアのデータを用いて網羅的な実験を行い,実用的なコード網羅性が得られるtの値を調べたのです.私は実験のためのツールを作り,データを取り,妻が論文を書く,という分担がしっかりできた初めての研究でした.ワークショップに発表した後,さらに実験を加えて論文誌に投稿する予定でしたが,道半ばで病を得てついに実現しませんでした.落ち着いたら実験の過程を再現して何とか投稿したいと思っています.

他にも彼女は研究のアイディアを多く語ってくれていましたが,研究のことでは「どちらがどのアイディアを出したのか」をいつも確認しながら話を進めていました.彼女はプロ研究者として,大学にいる私の甘い部分をよく指摘してくれました.本当は,あまり新しいことを考えるのは得意ではないため,できたら論文の校正や論理の補強みたいなことが仕事になれば良いのに,とも漏らしていましたが,それは自分の能力に対する謙遜が過ぎていたと思います.しかし,論文に朱を入れている時は,本当に楽しそうでした.

私の研究室の学生に産総研でRAとして働いてもらいながら,共同で研究を進めるスキームを確立してくれたのも彼女でした.多くの学生がその恩恵を受けています.学生の成長していく姿を見ながら「かなりしっかりしてきたね」と喜ぶなど,教育者としても大いに活躍できたはずでした.
(2024年追記) 妻と共に指導して博士を取得した西浦生成先生が,当研究室に助教として着任してくれました.感慨もひとしおです.

彼女は常に外の世界を向いていました.短期で海外へ出張・旅行するのも好きでしたし,長期で行くのももちろん好きでした.2012年に念願叶ってカナダへ行ったときには,現地の人に移住するつもりなのかと思ったと言われるほど,その地に溶け込もうとしていました.韓国や日本の雰囲気は彼女にあまり合っていなかったのかもしれません.

彼女に出会ってから23年,パートナーとしても16年,彼女の思い通りになっていなかった時期のほうが長かったのかもしれません.やっと安定して研究に取り組める状況になったのに,このようなことになったのは本当に悔しく,無念だったろうと思います.

今の私にできるのは,せめて彼女が心配しないように,がっかりしないように,研究を続けていくことでしょう.それでも、私が道に迷ったときに隣にいてくれて相談できないのは本当に寂しく辛いことです.

[1] Eun-Hye Choi, Osamu Mizuno, and Yifan Hu, “Code Coverage Analysis of Combinatorial Testing,” In Proc. of 4th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2016), pp. 34-40, December 2016.

Raspberry PiでビルドしたPygameでハマった話

あくあたん在室モニターの話の続き.

なんとかSSLのhandshakeでエラーを出さなくなったので,次に進みます。
Python 3.7.3をソースからインストールしたので,pygameをインストールしないといけないです。

$ sudo apt install libsdl-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev libsmpeg-dev libportmidi-dev libavformat-dev libswscale-dev
(省略)
$ sudo pip3 install pygame
(省略)
Successfully installed pygame-1.9.6

インストールは正常に終了.
あくあたん在室モニターをおもむろに起動します.

Fatal Python error: (pygame parachute) Segmentation Fault

Thread 0x71523470 (most recent call first):
  File "monitor.py", line 444 in run
  File "/usr/local/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/local/lib/python3.6/threading.py", line 884 in _bootstrap

Current thread 0x76ccd000 (most recent call first):
  File "monitor.py", line 1151 in draw_character
  File "monitor.py", line 1391 in draw
  File "monitor.py", line 192 in main
  File "monitor.py", line 1503 in <module>
Aborted

なんで落ちるの….しかもSegmentation Faultとか、およそPythonのエラーとは思えない。
1151行目はこれ.画面に文字を1文字表示するルーチン.
なお,あくあたん在室モニターでは画面上にメッセージがでるときに,昔のRPG風に1文字ずつ表示しています。ここはその部分。

surf,rect = self.myfont.render(ch,self.color)

いやいや,他のところでちゃんと表示してるやん.なんでこの場所だけ落ちるの.
この文を含むメソッド(draw_character)の呼び出し元をチェックします。

self.msg_engine.draw_character(self.surface, (dx,dy), ch)

至って普通で特に問題が見受けられません。しかも,どうも途中までは表示してるぽいのです。ならば,何を表示したのか見てみましょう。

print("draw {},{} {} ({})".format(dx,dy,str(ch),hex(ord(ch))))
self.msg_engine.draw_character(self.surface, (dx,dy), ch)

これで実行したら、どこの文字で落ちたか分かります。

draw 6,6 あ (0x3042)
draw 22,6 く (0x304f)
draw 38,6 あ (0x3042)
draw 54,6 た (0x305f)
draw 70,6 ん (0x3093)
draw 86,6 が (0x304c)
draw 102,6 8 (0x38)
draw 118,6 - (0x2d)
draw 134,6 3 (0x33)
draw 150,6 2 (0x32)
draw 166,6 0 (0x30)
draw 182,6 へ (0x3078)
draw 198,6   (0x3000)
Fatal Python error: (pygame parachute) Segmentation Fault

落ちた!まさかの全角スペース.なぜなんだ….その後,半角スペースでもダメなことが判明しました。空白文字全般がダメなのです。ただし、可視文字と一緒にスペースを混ぜた場合はきちんと動きます。あくまで、文字列全体で何も描画するものが無いものをrenderしようとすると落ちるのです。
症状を分かりやすくするために簡単に対話式でチェックしてみます。

>>> import pygame
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
>>> import pygame.freetype
>>> pygame.freetype.init()
>>> from pygame.locals import *
>>> myfont = pygame.freetype.Font("./font/rounded-mgenplus-1cp-bold.ttf",18)
>>> myfont.render("a",Color(255,255,255,255))
(<Surface(9x11x32 SW)>, <rect(0, 10, 9, 11)>)
>>> myfont.render(" ",Color(255,255,255,255))
Fatal Python error: (pygame parachute) Segmentation Fault

Current thread 0x76d49000 (most recent call first):
  File "<stdin>", line 1 in <module>
Aborted

これで再現しました。半角でも全角でも画面には表示されないスペースのみで構成される文字列をrenderしようとしたら,Segmentation Faultで落ちます。なお,これはRaspberry Pi上のPython 3.7.3 + pygame 1.9.6で発現したのですが,macOS上のPython 3.7.3 + pygame1.9.6では発現しません.どういう機種依存やねん、と悪態をつきつつ対策を考えます。

これ以上,なぜかを考えていても埒が明かないので,work aroundで対処します。chが空白文字のみだったらrenderをスキップしちゃえば良いのです。(dx,dyは事前に計算して位置決めしているので,これでも画面表示はくずれないようになっています。)

if ch != " " and ch != " ":
    self.msg_engine.draw_character(self.surface, (dx,dy), ch)

これで表示可能になりました。
めでたしめでたし。