kishima blog

test

2026-10-24T00:21:12+09:00

同人誌書きつつRustでmruby VMを作った話

2026-09-28T23:55:29+09:00

SabiRuby という、Rust で書いた mruby 互換の VM を作っています。mruby のバイトコード（mrbc が出す .mrb）をそのまま実行し、本家の mruby 4.1 と同じに動くことを目指したものです。crates.io に出していて、先日 0.7.0 を公開しました。

リポジトリ: https://github.com/sabiruby/sabiruby
ブラウザで試せる Playground: https://sabiruby.github.io/sabiruby-playground/
Bevy（Rust のゲームエンジン）に組み込む crate: https://github.com/sabiruby/rubevy

先日、h6n さんが Cloudflare Workers 向けの mruby VM「Chiburu」の記事の中で SabiRuby に触れてくれていました（mruby VMをつくった👍📱）。その中に「結局みんな Rust で mruby を作っているなら何が違うのか？」という一文があります。

いい問いだと思ったので、この記事では、SabiRuby がどういう経緯で生まれ、どういう作り方をしているかを書いてみます。ほかの実装との細かい比較ではなく、背景の話です。

きっかけは本だった

2019 年に「mruby バイトコードハンドブック」という同人誌を出しました。mruby の命令を 1 つずつ解説した本です。今、それを土台にした新しい本「Deep dive into mruby」（mruby 4.1 対応）を書いていて、11 月の技術書典に出す予定です。

mruby は 2.0 から 4.1 までの間に、命令の数も、例外処理の仕組みも、コンパイラ（Prism への移行）も大きく変わりました。前の本の内容はほとんどそのままでは使えなくなっていたので、書き直すなら、命令の解説だけでなく、VM・GC・コンパイラまで含めた「mruby の解説書の決定版」にしたいと思いました。

今回の本には、もう一つ目的があります。この本と本家のソースがあれば、別の言語に mruby の VM を移植できる。そういう仕様書として使えることです。

命令の意味を書くだけなら、ソースを読めば分かります。移植する人が本当に知りたいのは、「どこまでを再現しなければならず、どこからは mruby がそう決めただけで選び直してよいのか」という線引きです。たとえば、例外の伝わり方やメソッドの探し方は再現しなければなりません。一方で、値の表現（NaN boxing）や GC の細かい仕組み、setjmp/longjmp は、移植先に合わせて選び直してかまいません。本ではこの線引きを、各章に書いています。

そう書くからには、本当に移植できるのかを確かめたくなります。SabiRuby は、その確かめとして始まりました。本の説明（レジスタの重ね方、OP_ENTER、環境、ensure をまたぐ大域脱出……）を、そのまま Rust に写していく形で作っています。

移植先に Rust を選んだのは、Bevy でゲームを作るときに、ゲームのロジックを Ruby で書きたかったからです。C の mruby を組み込むこともできますが、VM が Rust で書かれていれば、ゲームと同じ言語・同じビルドの中に収まり、ブラウザ（WebAssembly）にもそのまま持っていけます。

何ができるか（2026 年 9 月末の時点）

本家 mruby 4.1.0-rc2 の mrbc が出すバイトコードを実行する（119 命令すべて）
本家のテストスイートで互換を確かめている（既定のビルドで 2508 件中 2344 件が通る）
本家と同じ追跡型の GC、Fiber、mruby-task（タスクスケジューラ）、eval・binding、require、正規表現、数値の塔（bigint・有理数・複素数）など、本家の gem のほとんど
VM は pure Rust で no_std（+ alloc）。VM の crate に unsafe は 1 行もありません
本家のコンパイラ（Prism と mruby の codegen）も crate として同梱していて、実行中に Ruby のソースをコンパイルできる
速さは、27 本のベンチの合計で本家の 2.57 倍の時間がかかります。つまり遅いです。速さで勝つことより、互換と安全を優先しています

VM が安全な Rust だけで書かれていると、スクリプトの誤りや VM の不具合があっても、メモリが壊れて謎のクラッシュ、ということが構造的に起きません。ゲームに他人の書いたスクリプトを載せる、といった使い方を考えると、この性質はかなり効きます。

Bevy に組み込む: rubevy

作りたかったのは、Bevy の中でゲームのロジックを Ruby で書けることでした。そのためのつなぎが rubevy です。

スクリプト 1 本が mruby-task のタスク 1 本になり、フレームごとに、命令数の予算の中で動きます
ゲームに問い合わせて答えを待てます（Rubevy.ask）。待っている間、タスクは CPU を使いません
ECS のコンポーネントに名前で触れ（e[:Transform]）、Bevy のイベントを受けられます（on(:hit) { ... }）
ゲームを動かしたまま、ゲーム内のエディタでスクリプトを書き換えると、すぐに反映されます

rubevy を使ったサンプルのゲームが 3 本あり、ブラウザで遊べます（3 本の入口: https://sabiruby.github.io/rubevy_games/ ）。どれも、ゲームの振る舞いが Ruby のファイルに書かれていて、ゲームを動かしたまま書き換えられます。

SabiRuby Battle: ロボットどうしが戦うゲーム。ロボット 1 台の振る舞いが Ruby のファイル 1 つです https://sabiruby.github.io/rubevy_games/sabibots/
箱庭（Garden）: 3D の小さな世界。生き物が自分の ECS のコンポーネントを Ruby から名前で読み書きし、遺伝子を混ぜて増えます。クリックした生き物のファイルをその場で書き換えられます https://sabiruby.github.io/rubevy_games/garden/
Factory: 上から見る小さな工場。品物やレシピを Ruby で宣言し、工場で起きたことを Ruby で受け、インサーター 1 台ずつが自分のスクリプトで「いつ物を運ぶか」を決めます https://sabiruby.github.io/rubevy_games/factory/

最新の 0.7.0 では、ゲーム用の DSL を書きやすくするために、block の中でも「待つ」ができるようにしました。たとえば instance_exec で評価する DSL の block の中で、タスクがゲームの答えを待てます。

これを作る途中で、本家 mruby の振る舞いを 36 通りの経路で実測しました。すると、本家のほうが待てる経路が多いことが分かり、本に書いていた説明の誤りも 2 か所見つかりました。その結果は本の VM 章に反映しています。VM を作ると本が直り、本を直すと VM が直る。この往復があるのが、本と VM を一緒に作っている面白さです。

作り方: AI と一緒に作る

SabiRuby も rubevy も、ほとんどのコードは Claude Code（Anthropic の AI）が書いています。私の役割は、方針を決めること、計画を承認すること、結果を見て直しを頼むこと、そして公開するかを判断することです。

VM のように、正しさを細かく確かめなければならないものを AI と作るうえで、効いたと思うやり方がいくつかあります。

計画書を先に書く。 段階ごとに「到達点」と「どう確かめるか」を決めてから、実装を任せます
作業の記録（worklog）を必ず残させる。 何を試して、何を測って、何を捨てたか。後から同じ調査をやり直さないためです。ここに溜まった知見は、本の素材にもなっています
本家で確かめる。 振る舞いに迷ったら、本家の mruby を Docker で動かして比べます。推測で書かせません
決まり事を短く書いておく。 たとえば「根拠のない数を書かない（測るか、導く）」「VM の crate に unsafe を入れない」
性能は測ってから言う。 変更の前後を交互に何度も測ります。その前に、同じバイナリどうしのばらつきを測って、「遅くなった」とみなす線を決めておきます

うまくいかなかったこともあります。0.7.0 の前に、数 % の性能の差の原因を追いかけさせすぎて、測っては直す、を何巡も続けてしまいました。時間もトークンも有限です。「最初の目標を満たしたら一度止まって報告する」と決めておくことが、AI と長く作業するうえでいちばん大事な決まり事かもしれません。

副産物として、作業の途中で見つけた本家 mruby の不具合について、PR を 3 本出し、マージしてもらいました。

これから

まずは本を仕上げて、11 月の技術書典で頒布します。本と一緒に使う移植キット（検証用のデータとテストの一式）も公開しています。SabiRuby と rubevy は、ゲームで Ruby を使いたい人、mruby を別の環境に持っていきたい人に触ってもらえるとうれしいです。

本「Deep dive into mruby」: 11 月の技術書典で頒布予定
移植キット: https://github.com/kishima/mruby-porting-kit
SabiRuby: https://github.com/sabiruby/sabiruby（crates.io: sabiruby）
rubevy: https://github.com/sabiruby/rubevy（crates.io: rubevy）
Playground: https://sabiruby.github.io/sabiruby-playground/

RubyKaigi 2026 で登壇した話

2026-04-30T00:37:41+09:00

先週は、会社を休んでRubyKaigiに参加するため、函館に行ってきました。

この記事は登壇までの記録です。

経緯

もともとCFPが採択されたのは２回目で、１回目は2020年開催のRubyKaigiでした。ただちょうどCOVID-19の拡大の時期と被ってしまい、キャンセルされて、RubyKaigi Takeout 2020として実施されました。

以下はその時の資料です。

now-is-the-time-to-create-your-own-mruby-computerfrom kishima7

楽しみにしていたので、当時は、大変意気消沈してしまいました。その後、仕事の方もCOVID-19の影響もあり、色々とどたばたして、転職したり、結婚したり、など趣味の時間を取れない時期が数年続きました。

生活もやっと落ち着いてきた2025年から本格的に個人プロジェクトを再開させて、その成果が採択されて、今回発表させていただくことができました。

事前準備

本格的に開発に着手したのが2025年の10月ごろで、そこからまずはLinuxシミュレーション環境で開発進めて、基本形を12月までに作り、2026年1月のCFPに応募しました。

CFP投稿時点のLinuxシミュレーション環境でのデモ

実機については、基板も並行して設計進めており、2025年11月に最初の基板を注文してます。CFP提出後、本格的に基板を使った開発に移行し、2026年2月末に基板の不具合を直した二次試作を発注し、3月末に本番向けの三次試作を発注しました。間に合うかどうか不安でしたがオプション積んだおかげか、１週間で基板が届き、それをつかって最後の調整ができました。

OSとしてのベースができあがってきたおかげで、Claude Codeでのデモアプリの実相が捗りまくって、4月に入ってから、一気にかなり映える感じにできました。アプリを作るとまた問題点も浮かび上がってくるので、それをぎりぎりまで潰しつつ、移動の日を迎えました。

Day0

午前中少しだけ仕事としてから、新幹線での移動でした。前日にあった大きな地震の影響があるかもしれず心配でしたが、無事予定通り移動できました。移動中に資料の最後の仕上げをして完成させ、やんちゃハウス入り後、先入りしてたみなさんと軽く飲んで緊張しつつも気持ちよくその日を終えました。

Day1

発表当日です。

はすみさんの発表を聞いて、すげーと思ったらすぐ通訳さんとの打ち合わせでした。初めてでしたが、こんな感じで意識合わせするのか、と新鮮な体験でした。資料が前日に修正しててごめんなさい。

私の発表は午後からだったので事前に接続確認してたのですが、基板の映像がでなくてかなり焦りましたが、結局ケーブルの接続ミスでした・・・。

あわてて会場の外で動作確認中の様子

直前のhadashiAさんの発表も何とか聞けました。落ち着いて資料見返したいです。

本番

PicoRuby as a Multi-VM Operating SystemRubyKaigi 2026, #rubykaigiRubyKaigi

@Kirika_K2 さんにとって頂いた写真

本番のスライド

harukasan(さん)の発表

Building a Standalone Ruby Programming EnvironmentRubyKaigi 2026, #rubykaigiRubyKaigi

PicoPicoRubyのDiscordでなんとなくやられていることは、見てましたが、気が付いたら私とかなりやってることのゴールが近くて驚きました。（PicoRubyで独立した開発環境を備えたミニPCをハードから作る）

おなじRubyKaigiでこのニッチなテーマで並んで発表できたことは、PicoRubyの応用のすそ野の広さと、同じテーマでもいろいろなアプローチ手法がある、ということをお見せすることができて、とても有意義だったのではないかな、と勝手に思ってます。

私も大いに刺激を受けたので、今後の開発にも生かしていきたいです。Harucom 基板も買えました。（仕事もお忙しいはずなのに、基板を量産してRubyKaigi本番で売るまでもっていくのは超人過ぎる・・・）

以降のことは、長くなりそうなので、忘れないうちに別記事にまとめたいと思います。

謝辞

2025年にモチベーション高く活動を続けることができたのはPicoPicoRubyやそのDiscordでPicoRubyやってる同士のみなさんと触れ合えたおかげだと思っています。主催の @makicamel さん @youchan さんをはじめとしたコミュニティの皆さんには感謝でいっぱいです。

私の活動は完全に趣味でやっているので、仕事の外でも活動してる仲間が居る、という事実に大変勇気づけられました。これは2019年ごろの状況とは大きく違う点です。

また、Omotesando.rbでも時々LTさせて頂いて、アウトプットの場を頂けて大変感謝しております。

追伸：基板も販売してます。

Family mruby Narya 基板 (v3 prod r1) - Kishima Craft Works - BOOTH# 注意 2026/5/27までに受け付けた注文については、2026年5月中に発送予定です。 # Narya基板（v3 Prod R1） ESP32上で動作するPicoRubyベースOS「Family mruby」に対応した検証用基板です。 PicoRubyをベースに、マイコン単体でGUIアプリケーションの開発・実行が可能です。デモ動画： https://www.youtube.com/watch?v=9vkRaOoxJJI ディスプレイ出力・入力デバイス・音源制御を統合し、Rubyコードで直接制御できます。silentworlds.booth.pm

2025年の振り返りと2026年の抱負

2026-01-01T21:11:23+09:00

明けましておめでとうございます。今年も無事新年を迎えられてありがたい限りです。

昨年は色々対外的な活動も増やしたり、自分の趣味プロジェクトも新しく始めたりしたので、活発な一年だったと思います。

今年は仕事始めて２０周年でもありますし、色々頑張り時な年だと思うので、抱負と合わせて、昨年の振り返りを残しておきたいと思います。

2025年振り返り

2025年は、４月までは仕事のほうがかなり忙しく、日々仕事で忙殺される日々でした。

2/2 Tokyu.rb新年会2025

まだ忙しい季時期でしたが、地方出張前に荷物抱えて参加した記憶があります。

Tokyu.rbは、みんなで美味しいもの（主に肉）をいただく集まりなのですが、そこで関西Ruby会議のことを聞いたことが、この後の動きの伏線になりました。

５月になって仕事が落ち着いてきたので、一念発起して久しぶりに地域Ruby会議へのプロポーザルを送ったのでした。

5/26PicoPicoRuby #1

待望のmruby関連の勉強会！ということでウキウキで参加しました。

以降も月イチで安定して開催されており、私の活動のモチベーションの源のひとつとなってます。

5/28 Shinjuku.rb #99

自由な時間が取れるようになってきたのは５月くらいからでした。そんな中でKaigiEffectネタで募集があったので、参加してみました。

この時点で、関西Ruby会議08での採択通知が届いており、気合を入れて、準備を進めていました。

6/28 関西Ruby会議08

京都で発表してきました。とても素敵なイベントで、アフターイベントや夜通し鴨川で語ったり、記憶に残りました。

やはり来年のRubyKaigiは行きたいなあ、と思ったのもここが起点でした。

詳しいレポートはこちら参照。

7/19 PicoRuby Overflow会議

PicoPicoRubyでお誘い頂いこともあり、応募して、ポスターセッション形式で発表してきました。大阪日本橋ではんだ付けしたりもできて、地域をまたいでmrubyの輪が広がっていることを感じられて良かったです。

このあたりから、Family mrubyの方のアイデアも固まってきました。

8/28 Ruby Association Activity Report

Family mrubyで使いたい部品である、ファミコン音源をマイコンで鳴らすことをテーマに、LTしてきました。

Claude Codeにがっつり課金して使うようになってきたのはこのあたりからですね。

9/4 Omotesando.rb #113

activity reportでのLTでは、デモを失敗してしまったので、リベンジしてきました。ついでにMIDI連携の基礎も確認できました。

このあたりから、仕事の方でも開発、インテグレーション業務に加えて、本格的にマネージャー業の重みも増えてきた時期でした。

9/9 ROSConJP2025

残念ながらプロポーザルは通らかなかったので、一般参加でした。ここで得た繋がりで仕事関係でも関係が増えたりして、行った甲斐ありました。

関西RubyKaigiの内容をベースに、LTも準備してたのですが、抽選の結果、残念ながら時間内の発表枠はもらえませんでした。

Family mruby開発

ROSConJPも終わったことで、イベントは一区切りついたので、本格的にFamily mrubyプロジェクトの開発に取り掛かりました。

GitHub - family-mruby/family-mruby: A development platform that enables mruby development and execution directly on microcontrollers. It features audio and graphics capabilities and is designed to run on ESP32.A development platform that enables mruby development and execution directly on microcontrollers. It features audio and graphics capabilities and is designed to run on ESP32. - family-mruby/family-...GitHub

久しぶりにKiCADを開いて、基板の設計もしました。そしてJLCPCBでPCBAの発注も行いました。

11/29 TokyuRuby会議16

これまではずっとスタッフ参加でしたが、この回は、LTをしたり飯を持ち込んだりして、一般参加を満喫できました。

そして飯王の称号をいただきました。これも夢だったので嬉しかった。

/2025/11/tikintomatozhu-torebapesutonoresipinoji-yi-2/

12/4 Omotesando.rb #116

movさん開催ということで、オフィス遊びに行ってみたかったので、LTもって参加してきました。

ニーズが根強いM5Unified for PicoRubyについて発表してきました。

GitHub - kishima/picoruby-m5unifiedContribute to kishima/picoruby-m5unified development by creating an account on GitHub.GitHub

12/19 Shinjuku.rb #101

資料は載せられないですが、技術的というよりは、仕事の体験談やそこからの学び、的な話をしました。

PicoRubyへのコントリビュート

R2P2-ESP32向けにファイル転送機能を追加する提案中です。

Add USB-Serial-based file transfer feature for ESP32 environment · Issue #64 · picoruby/R2P2-ESP32Unlike the Raspberry Pi Pico version, the ESP32 version of R2P2 does not currently support MSC (Mass Storage Class). As a result, users must rebuild and flash the firmware every time they update th...GitHub

2026年の抱負

仕事も忙しくなりそうなので、どこまでできるか未知数ですが、日々体力も頭のキレも鈍くなってるのだから、あとは効率をよくせんといかんです。

趣味のプロジェクト

Family mrubyを実際に自作基板にのせて配布できるレベルまで仕上げていきたいです。

派生や発展させたいユースケースもたくさんアイデアあるので、早く基盤を固めて、そういうアプリケーション作りを楽しめるところまで行きたい。

発表

今CFPオープン中の、RubyKaigi2026で発表したい！と思って準備してます。

その他にも関西の方の地域Ruby会議も面白そうなので、CFPトライしようかどうか、悩み中・・・　

料理

昨年、やれなかった自作クラフトビール体験もやってみたい。問題はどうやって消費するか・・・。

製麺も加水率高めの麺はまた再開してみたい。生パスタもいいかもしれない。

仲間内で振る舞う会ともいつかできたらいいなと思ったりしてます。

旅

円安物価高だし、時間的にも2026年中は、難しいかもですが、海外もまた旅行してみたいですね。欧州の行ったこと無い地域いってみたい。

キャンプやりたい。キャンプベアードは行きたい。

キャンプベアードキャンプ・ベアードへようこそキャンプベアードは日本のクラフトブルワリーの老舗、ベアードブルーイングが経営するキャンプ場です。ここは、ビール愛に負けないくらいの情熱で自然を愛するベアードブルーイングの従業員チームにより運営されています。個性あふれるベアードビールを楽しみながら、修善寺の素晴らしい自然を存分に満喫してください。伊豆半島の豊かな自然に囲まれ、美しい狩野川とベアードビールの工場の間にキャンプ場は位置しています。狩野川のほとり、木立が整然と並ぶフリーテントサイト(24サイト)・キャンピングカーサイト(2サイト)、オートキャンプサイト(11サイト)・キャビン(3棟)にトレーラーハウス(1棟)、そして2024年8月からは車中泊サイBaird Beer

運動

仕事と、趣味の開発に集中する結果、運動する時間が犠牲になっているので、なんとかしたいんですが、自分のタスク管理にブレイクスルーが必要・・・。

仕事

あまり詳しくは欠けないですが、新しい取り組みが始まり、立場上、自分への期待も大きいと理解してます。視野を広く、事業に貢献できるような動きをしていきたいな、と思ってます。

電子工作遍歴をたどる（２）

2025-12-30T21:45:44+09:00

前回の話のつづきです。

作例５ラズパイとGroveによる音楽プレーヤ

2017/08ごろ

ラズパイで遊び始めて、そろそろ単なるミニPCとしてではなく、いろいろ電子工作っぽいことをやってみたくなってきました。

そのころSeeedのGroveというものを知って、これなら初心者でも色々電子デバイス試せる！となって色々買ってきて作ったのがこちらです。

/2018/04/a-first-step-to-raspberry-pi-project/

GitHub - kishima/RaspiMusicServer: An music server on Raspberry pi and ArduinoAn music server on Raspberry pi and Arduino. Contribute to kishima/RaspiMusicServer development by creating an account on GitHub.GitHub

RaspiMusicServer demo

ラズパイをプラスチック箱に入れて、テキストディスプレイに情報表示しつつ、ジェスチャセンサやスライドバー、ジョイスティックなどで制御してます。

ラズパイのシャットダウン電源制御も外部のArduinoから行うようにして、独立したデバイスとして使えるようにしました。

この開発で、いろいろなセンサーやデバイスの使い方や、マイコン間の連携など、今後のオリジナルデバイス開発の基礎をここで勉強できたと思います。

箱に入れる前の様子

作例６　GameBoy Zero

この作品は電子工作のスキルを一段引き上げてくれたものなので、印象深いですね。

2017/11 ごろ

もともとレトロゲーム好きで、いろいろ電子工作の情報をあさっていたら、mintyPiなど見かけて、いいなあ、自分も作ってみたいなあと思っていました。

そんな中、ラズパイゼロを使って、ゲームボーイの中身を置き換えて、ラズパイマシンに改造するプロジェクトを知りました。

ゲームボーイにRaspberry Piをぶち込んでスーファミタイトルなどゲーム三昧な魔改造を施した「Game Boy Zero」単3電池を詰め込んで、小さなモノクロ画面でどこでも任天堂のゲームを楽しめるようになった「ゲームボーイ」は、いまではレトロに思えるデザインのせいか今でもゲーム愛好家に大人気の存在です。そんなゲームボーイにシングルボードコンピューター「Raspberry Pi Zero」をぶち込んで、ゲームボーイだけでなくスーパーファミコンなどさまざまなプラットフォームのゲームタイトルをプレイできる様に改造した「Game Boy Zero」を作り上げた強者が登場しています。GIGAZINE

実際に参考にした情報が何だったのかは、思い出せなかったのですが、当時は何かのYouTubeの動画を参考してました。

細かい設計図などはなかったので、動画を見つつ、必要な部品を整理して注文して、配線を考えたりしました。

手書きの設計図

まずは中古でジャンクのゲームボーイを買って、分解して、洗浄します。

下の部分だけ再利用する

基板をカットします。

ここでリューターというものを買って使いました。こういうものを切るときは砥石を使うことも新しい知識でした。

液晶のサイズを大きくするために、枠をカットして、ボタンを増やすために、穴開けたりもしました。

別のコントローラから剥がしてきたボタンガイドを増設

ボタンの接点のために、元基板の一部を利用

パターンから信号を取る

銅箔テープで接点を作ったり

銅箔テープの使い方を知ったり。グルーガンで配線固定したり。

ラズパイゼロと液晶を取り付けた図

LiPoバッテリーも初めて使いました。

USB Auidoのパーツを分解してつかったり、右下は充放電管理だったような

これをケースに詰めます。

正面

背面。バッテリーを入れた様子。

背面。ソフトのカバーを被せてなるべく基板が見えないように

参考にした動画より液晶のコネクタの高さが高かったようで、ケースとラズパイが干渉して、背面を少し削ることに。

かなり時間かかりましたが無事、動いたときは感動でしたね。

この作品では、細かいはんだ付け作業や、プラスチックの加工や、LiPoバッテリーを使ったり、かなり本格的な電子工作でした。

これをやり切れたことで、自信がついて、以降の工作へのモチベーションもあがっていったと記憶してます。

少し背伸びしたトライも大切ですね。

Family mruby OS: A Multi-VM MicroRuby System Built on FreeRTOS

2025-12-26T02:32:08+09:00

Today, I’d like to introduce Family mruby, a personal project I’ve been working on recently, and its evolution into Family mruby OS.

(This post is translated from a previous post)

This is a demo running on the current Linux-based simulation environment. Wouldn’t it be exciting if a UI like this could run on an ESP32 microcontroller using mruby, and you could even develop and execute mruby code directly on it?

Background and Motivation

Family mruby is a project that I originally started in 2019.
I also presented an early prototype at RubyKaigi Takeout 2020.

What is Family mruby?

Family mruby(legacy)Kishima’s projectsKishima Craft Works

Long ago, BASIC was often the first programming language that children encountered.
Despite its limitations, there were products like Family BASIC, which allowed BASIC programming not only on PCs but also on platforms such as the MSX or the Famicom(NES). Many programmers discovered the joy of programming through these environments.
Today, development environments for most programming languages are freely available and easily installable on PCs. However, because so much is possible, beginners often don’t know where to start. Even reaching the point where you can make something slightly beyond “Hello World,” such as a simple game, can require a surprisingly high setup cost.
With that in mind, I wanted to create an environment where you could build small games or applications using a scripting language on a single microcontroller board. That idea became Family mruby.

Features of the Original Family mruby

Standalone mruby editor and execution environment running directly on ESP32
Designed to run on ESP32 with PSRAM
Custom-designed dedicated hardware board
VGA video output
Analog audio output
PS/2 keyboard input

Dormant Period

Due to the COVID-19 pandemic and the busyness of my personal life, development stopped for a while.
Still, the idea of rebooting the project always lingered in the back of my mind.

Encounter with PicoRuby / MicroRuby

While I was away from the project, I learned that @hasumikin had developed PicoRuby, which greatly inspired me.

In my original implementation, I ported raw mruby to the ESP32 and built a custom editor on top of it. PicoRuby, however, was much more resource-efficient and implemented many features that significantly improved user experience, such as a filesystem and USB device support.

Inspired by this design philosophy, I decided to rebuild my own ideal mruby development and execution environment from scratch.

PicoRuby is based on the mruby/c VM, but I heard that MicroRuby would be based on the standard mruby VM, which meant I could leverage my previous mruby experience.
By 2025, my personal life had stabilized enough to allow me to fully reboot the project and resume development seriously.

Differences Between the Original and the New Family mruby

During the project’s dormant period, I changed jobs and shifted from a PM-focused role back to hands-on coding. With my development instincts refreshed, I decided to design the new system with a “do everything I want” mindset, partly as a skills refresher.

The architecture of the original Family mruby looked like the diagram below.

Original Family mruby diagram

The new Family mruby architecture is shown in the next diagram.

New Family mruby diagram

The system has been reconstructed as an OS, allowing the world of “developing and running software in mruby” to expand significantly.

The main differences are summarized in the table below.
To address pain points from the original version—such as the cumbersome setup for PS/2 keyboards and VGA output—I switched to USB devices and enabled development on Linux as well.

Family mruby OS

In the new Family mruby, USB mice can also be connected. Taking advantage of this, I wanted to provide a simple window-based GUI inspired by Windows 3.1 and FM-TOWNS OS, which I personally grew up with.

Since ESP-IDF is built on FreeRTOS, I realized that it should be possible not only to run mruby code but also to execute multiple VMs concurrently.

I decided to call this new environment Family mruby OS.

Assumptions

Compared to PicoRuby and similar systems, Family mruby OS is expected to require several times more memory.
Therefore, it assumes an ESP32 equipped with several megabytes of PSRAM, such as:

Wi-Fiモジュール ESP32-S3-WROOM-1-N16R8: 半導体秋月電子通商-電子部品・ネット通販電子部品,通販,販売,半導体,IC,LED,マイコン,電子工作Wi-Fiモジュール ESP32-S3-WROOM-1-N16R8秋月電子通商電子部品通信販売akizukidenshi.com

In a sense, this might be the “luxurious microcontroller environment” that mruby originally envisioned.
In the future, I’d also like to support the ESP32-P4.

Key Features

Adoption of MicroRuby

By using MicroRuby as the primary VM, we benefit from its compact yet dynamic compilation capabilities, as well as various picoruby-gems.

Since MicroRuby is under active development and may introduce breaking internal changes, it’s important to track upstream carefully rather than maintaining a fork.

I initially considered PicoRuby for its stability, but since mruby/c relies heavily on global variables, it appeared difficult to isolate memory spaces cleanly, so I decided against it.

MicroRuby’s built-in multitasking features remain useful. Combined with FreeRTOS-level concurrency (machine-code level), we can also retain bytecode-level concurrency.
(Currently, instead of using interrupt handlers, each VM’s tick is driven from a dedicated task.)

Multi-VM Architecture

FreeRTOS is a real-time operating system that provides task functionality.
Each task (similar to a thread) has its own stack and can operate independently.

By placing one VM per task and creating multiple tasks, multiple VMs can run concurrently.
To make this possible, memory isolation and hardware resource separation are essential.

To manage VMs like processes, various supporting mechanisms have been implemented.
FreeRTOS Thread Local Storage (TLS) is used to manage VM contexts.

Each VM is assigned its own memory allocator handle, limiting its accessible memory to a predefined pool. This approach:

Prevents system-wide memory fragmentation
Isolates failures so one VM does not corrupt others
Improves overall system stability

In the worst case, a misbehaving application can be terminated, its memory pool reallocated, and restarted.
(Of course, illegal memory access at the C level or hardware resource conflicts are a different matter.)

To avoid busy loops in a resource-constrained environment, event waiting is implemented using FreeRTOS queues.
When inter-VM events arrive, the corresponding callback method is invoked immediately in the target VM.

As long as memory and hardware resources are properly isolated and size constraints are met, languages other than mruby can also be supported.
Currently, Lua is integrated as a proof of concept, and MicroPython is a future candidate.

Hardware Abstraction

With a system of this scale, development directly on a microcontroller can be challenging.
To address this, all hardware- and OS-dependent functionality is accessed through an abstraction layer.

As a result, the same code can now run on Linux as on the ESP32.
This leverages ESP-IDF’s Linux build support and LovyanGFX, which can also run on Linux via SDL2.

A well-defined abstraction layer improves portability and opens the door to future possibilities such as:

Running via WASM
Supporting new board designs

One challenge is that existing picoruby-gems for peripherals may not align perfectly with Family mruby OS’s abstraction model, especially regarding memory management.
Additionally, many are not designed for multi-VM environments, so some form of mutual exclusion will likely be required.

For GPIO and I2C, I think I should rewrite implementations to be thread-safe while using the hardware abstraction layer (HAL).

Development Location

Development is carried out under the following GitHub organization:

Documentation is still sparse, but I plan to improve it gradually.

Family mrubyFamily mruby has 10 repositories available. Follow their code on GitHub.GitHub

Execution Environments

Family mruby is designed to run either on dedicated hardware or on Linux.

Dedicated Hardware

There is no mass-produced board yet, but I designed a development board and had it assembled via JLCPCB’s PCBA service.
Unfortunately, it didn’t work as expected, and debugging is currently underway.

The rough block diagram is shown below.
In a somewhat desperate move, I mounted two ESP32 chips on the board. Someday, with an ESP32-P4 and a dedicated display, I might be able to consolidate this into a single chip.

All hardware design data is publicly available:

GitHub - family-mruby/narya-board: Dual ESP32 board for Family mrubyDual ESP32 board for Family mruby. Contribute to family-mruby/narya-board development by creating an account on GitHub.GitHub

Here is a photo of the actual development board. The BOM was correct, and assembly quality was excellent.
This was my first time having through-hole components assembled as well, which was a valuable learning experience.

Linux

By using ESP-IDF’s Linux simulation along with SDK2 and LovyanGFX, fmrb-core runs almost unchanged on Linux.

The secondary ESP32 is represented by a separate process.
Instead of SPI, communication is implemented using a custom protocol over sockets.

Architecture on Linux Environment

Current Demo

I recorded a demo video of Family mruby OS. So far I’ve only verified it in the Linux environment, so my next step is to finish debugging the board and then get the same setup running on the ESP32 in the near future.

The OS management features, the wallpaper/system bar screen, and a pseudo-shell app are each running in their own independent MicroRuby VM. Lua is also running separately in its own VM.

Since there’s no launcher yet, I open the pseudo-shell and Lua windows in response to mouse clicks.

The pseudo-shell app doesn’t implement shell functionality yet, but keyboard input is sent to the MicroRuby VM running the pseudo-shell app and reflected on screen.

Mouse interaction is still incomplete as well, so for now I move the shell window using the arrow keys.

Family mruby OS prototype3

Bouncing Ball App Demo Application Code

https://github.com/family-mruby/fmruby-core/blob/main/flash/app/sample/mruby.app.rb

class BouncingBallApp < FmrbApp
  def initialize
    super()
    @counter = 0
    @bounce_count = 0

    # Ball properties
    @ball_x = @window_width / 2
    @ball_y = @window_height / 2
    @velocity_x = 3
    @velocity_y = 2
    @ball_radius = 8

    # Colors
    @bg_col = FmrbGfx::BLACK
    @ball_col = FmrbGfx::RED
  end

  def on_create()
    log_puts "[BallApp] on_create called"
    log_puts "[BallApp] user_area: x0=#{@user_area_x0}, y0=#{@user_area_y0}, width=#{@user_area_width}, height=#{@user_area_height}"
    log_puts "[BallApp] window: width=#{@window_width}, height=#{@window_height}"

    # Initialize ball position within user area
    @ball_x = @user_area_x0 + @user_area_width / 2
    @ball_y = @user_area_y0 + @user_area_height / 2

    draw_full_screen

    log_puts "load my_lib"
    require "/lib/my_lib"
    log_puts "load my_lib done"
    inspect_env

  end

  def draw_full_screen()
    @gfx.clear(FmrbGfx::WHITE)
    draw_window_frame
    draw_ball
    @gfx.present
  end

  def draw_ball()
    @gfx.fill_circle(@ball_x, @ball_y, @ball_radius, @ball_col)
  end

  def erase_ball()
    @gfx.fill_circle(@ball_x, @ball_y, @ball_radius, FmrbGfx::WHITE)
  end

  def on_update()
    # Erase old ball position
    erase_ball

    # Update ball position
    @ball_x += @velocity_x
    @ball_y += @velocity_y

    # Calculate user area boundaries
    left_boundary = @user_area_x0 + @ball_radius
    right_boundary = @user_area_x0 + @user_area_width - @ball_radius
    top_boundary = @user_area_y0 + @ball_radius
    bottom_boundary = @user_area_y0 + @user_area_height - @ball_radius

    # Check collision with left/right walls
    if @ball_x <= left_boundary || @ball_x >= right_boundary
      @velocity_x = -@velocity_x
      @ball_x += @velocity_x  # Move away from boundary
      @bounce_count += 1
    end

    # Check collision with top/bottom walls
    if @ball_y <= top_boundary || @ball_y >= bottom_boundary
      @velocity_y = -@velocity_y
      @ball_y += @velocity_y  # Move away from boundary
      @bounce_count += 1
    end

    # Draw new ball position
    draw_ball

    @gfx.present
    @counter += 1

    # Return sleep time in milliseconds (33ms = ~30fps)
    33
  end

  def on_event(ev)
  end

  def on_destroy
    log_puts "[BallApp] Destroyed"
  end
end

begin
  app = BouncingBallApp.new
  app.start
rescue => e
  log_puts "[BallApp] Exception: #{e.class}"
  log_puts "[BallApp] Message: #{e.message}"
end

What Has Been Implemented So Far

OS Framework
- Implementation of basic functionality
- Launching multiple MicroRuby VMs using FreeRTOS tasks
  - During the process of enabling multitasking, issues were found with memory space isolation and tick behavior, so patches have been applied. How these should ultimately be handled still requires further consideration.
- Launching a guest VM (Lua) using FreeRTOS tasks
- Memory pool management
  - The system is designed so that each VM is assigned an independent memory pool. For memory allocation, the default estalloc allocator is used inside MicroRuby, while TLSF is used elsewhere. estalloc has also been configured to operate correctly in a multitasking environment.
- Foundation of an inter-core communication protocol
  Currently implemented using sockets
- Simple drawing API
  RPC implemented on top of LovyanGFX
For Linux
- Execution environment using SDL2 + LovyanGFX
  - Audio is not yet implemented
For real hardware
- Porting the APU block from an NES emulator to the ESP32
- Proof-of-concept for fmrb-audio-graphics
  - Simultaneous operation of LovyanGFX (NTSC) and the APU has been confirmed
Board
- Design and implementation of a prototype board
  - However, issues remain
Applications
- Only development-time drawing samples so far

Future Development Items

OS framework improvementsHID event handling / STDIO replacementWindow management (z-order, movement)Application lifecycle managementFullscreen modeGUI redesign
LinuxExpanded graphics supportAudio implementation
HardwareInter-core communicationUSB host support (keyboard, mouse)Sub-ESP32 firmware
BoardDebuggingMass-production design
ApplicationsShellFile managerGPIO/I2C sample apps

Looking Ahead

My next step is to submit a CFP to RubyKaigi, then aim for a full presentation.
This project is far too large to complete in a few months, so I plan to continue gradual development throughout the coming year.

Once things stabilize, I’d like to sell the board as a set at events.

Dreams

If this project takes shape, I’d like to explore:

Enhanced inter-VM communication
Integrating MicroPython and reusing its ecosystem
Pixel-art and music editors for game development
GUI-based GPIO and I2C control
Wi-Fi connectivity and app sharing/downloading
Ports to LCD-equipped ESP32-S3 or Tab5 devices
A PicoCalc-style device with LCD and mini keyboard
Browser execution via Emscripten, with sensors handled by companion boards

References

Picotron - Fantasy Desktop

I discovered this during development. While it’s not for microcontrollers, its UI closely matches my ideal vision.
It’s a retro, 8-bit-style game development environment.

Picotron by Lexalofflewww.lexaloffle.com

Family mruby OS：FreeRTOSベースのMicroRubyマルチVM構想

2025-12-25T12:19:48+09:00

この記事は、mrubyファミリ (組み込み向け軽量Ruby) Advent Calendar 2025の12/25の記事です。25日の枠が空いていたので、滑り込ませていただきました。

今日は私が最近取り組んでいる個人プロジェクトであるFamily mrubyとそこから発展したFamily mruby OSについて紹介したいと思います。

現在のLinuxシミュレーション環境上でのデモ。ESP32マイコン上で、こんなUIがmrubyで動いていて、mrubyのコードも開発、実行できたら夢が広がりますよね？

開発に至る経緯

Family mrubyは2019年から開発着手したプロジェクトです。2020のRubyKaigi Takeoutでも初期型について発表しました。

Family mrubyとは？

Family mruby(legacy)Kishima’s projectsKishima Craft Works

今は昔、子供が最初に触れるプログラミング言語といえば、BASICという時代がありました。制約は多いですが、パソコン以外にも、MSXやファミコンでBASICができるFamily BASICという製品もあり、そこからプログラミングの面白さを知り、プログラマーになった方もたくさん居られると思います。
そして現在は無料で大抵のプログラミング言語の開発環境はパソコンにインストールすることができる時代になりましたが、できることが多すぎて何をしたらよいのかわからなかったり、Hello Worldの先のゲームを作ったりするまでの環境構築ハードルが高かったり、するような気がしています。
そこで、マイコン一つでちょっとしたゲームなどをスクリプト言語で作れる環境を作ってみたい、と思って開発したのが、Family mrubyです。

特徴

mruby専用のエディタおよび実行環境をESP32上でスタンドアロンで実現
PSRAM付きESP32上での動作を想定
専用の基板も設計
映像はVGAで出力
音声はアナログで出力
PS/2のキーボードで入力

休眠期

コロナの流行や、私生活のあわただしさもあり、しばらく開発がストップしてました。でも頭の片隅にはプロジェクトをリブートしたいという思いがずっとありました。

PicoRuby/MicroRubyとの出会い

私がしばらくプロジェクトから遠ざかっているうちに、@hasumikinさんがPicoRubyを開発されたことを知り、大いに刺激を受けました。

私の初期型では、ESP32へ素のmrubyを移植して、自作のエディタを動かすまででしたが、PicoRubyでは、より省リソースになり、ファイルシステムやUSBデバイス化などユーザ体験を向上させるための機能が多数実装されてました。

この設計思想を一部受け継いで、自分なりに自分が求める新しいmrubyの開発実行環境をまた１から作り直したくなりました。

PicoRubyはmruby/cのVMがベースになっていましたが、MicroRubyではmruby VMベースになると聞いて、mrubyでの経験も生かせるのではと思いました。

ある程度私生活も落ち着いてきた2025年から本格的にプロジェクトをリブートして開発に着手しました。

初期Family mrubyと新Family mruby は何が違うのか

プロジェクト休眠期中に転職をしてPM寄りから、コーディングもする仕事になって、多少開発の勘も戻ってきたこともあり、腕試しの意味も込めて、やりたいこと全部やる方針で設計しました。

初期型の構成は↓の図のような感じです。

初期型Family mrubyの構成

新型Family mrubyの構成は↓のようになってます。

新型Family mrubyの構成

mrubyで開発、実行できる世界を拡張できるようにOSとして再構築しました。

主な違いは以下の表にまとめてみました。PS/2キーボードやVGA出力がちょっと準備が面倒なので、USBに変えたり、Linux上でも開発できるようにしたり、と旧型で気になった部分を解消するように見直しています。

旧Family mrubyとの違い

Family mruby OS

新型Family mrubyでは、USBマウスもつなぐことできるようになります。それを生かして、昔のWindows3.1や私が親しんだFM-TOWNS OSをオマージュして、シンプルなWindow GUIを提供したいと考えました。

ESP-IDFのベースになっているFreeRTOSを生かせば、単にmrubyのコードを実行する環境としてだけでなく、コンカレントに複数のVMを実行できるはずです。

この新しい環境をFamily mruby OSと呼ぶことにしました。

前提

Family mruby OSを動かすためには、PicoRubyなどと比較して何倍ものメモリが必要なることが見込まれます。そのため、PSRAMを数MB以上搭載したESP32を前提としました。

mrubyが当初想定していた富豪的マイコン環境がこれなのかなと思ってます。

将来的にはESP32-P4にも対応できたらいいなと思ってます。

特徴

MicroRubyを採用

MicroRubyを主たるVMとすることで、コンパクトでダイナミックなコンパイル機能や、各種pico-gemなど、たくさんの恩恵を受けることができます。

MicroRubyは絶賛開発中で内部的には破壊的変更も発生するので、Forkはしないでうまく追従していくように努力が必要です。

より安定しているPicoRubyの採用も最初考えましたが、ベースのmruby/cがグローバル変数が前提の実装になっており、メモリ空間の分割が難しそうだったため断念してます。

MicroRubyの提供するマルチタスク機能も有効なので、FreeRTOSによる機械語レベルの並行動作に加えて、バイトコードレベルでの並行動作も変わらず使えるはずです。（現在は、割り込みハンドラではなくて、専用タスクから各VMのTickを呼び出す形にしてます）

マルチVM

FreeRTOSは、リアルタイムOSであり、タスク機能を提供しています。タスクはいわゆるスレッド的なもので、それぞれがスタックをもって独立して動作することができます。

１タスクに１VMを載せ、タスクを複数生成することで、VMを並行で動かすことができます。そのためにはメモリ空間やHWリソースの分離などが必須になります。

VMをプロセスのように管理するために、必要な各種機能を実装しています。タスクのTLS（Thread Local Storage）を活用することで、VMのコンテキストを管理しています。

VMごとにメモリアロケータのハンドルを割り与えることで、１つのVMがアクセスできるメモリはあらかじめ確保したメモリの範囲に限定しています。こうすることで、メモリのフラグメンテーションがシステム全体に波及することを防いだり、１アプリのメモリが壊れても、他アプリへの影響しないようにしたり、などシステム全体の安定化に大きな効果があります。最悪、アプリの状態がおかしくなっても、タスクを強制的に終了させて、またメモリプールを割り与え直せば復帰できます。（もちろんC言語レベルでなにか不正なメモリアクセスしたり、HWの取り合いなど起こしたときは別の話になります）

性能が限られた環境でビジーループ的なことは極力避けたいので、イベント待ちはFreeRTOSのキュー機能で実装してます。アプリ側ではVM間イベントが届き次第即座に所定のメソッドがコールバックされるようしています。

基本的にメモリ分離、HWリソース分離ができて、バイナリサイズ、実行メモリサイズが適合すれば、mruby以外の言語も搭載可能です。現状はPoCとしてLuaを仮搭載してます。将来的にはMicroPythonも搭載してみたいです。

HWの抽象化

これだけ大規模な実装になるとマイコン上での開発はなかなか大変です。そのためLinuxでも実行できるようになると嬉しいです。そのために、HWやOSに関する機能は全て抽象化レイヤーを介してアクセスするようにしました。

その結果、Linux上でもESP32向けと同じコードを実行できるようになりました。ESP-IDFがLinux向けのビルドが可能なのと、描画用に採用しているLovyanGFXもSDL2 on Linuxでも実行可能なので、それを生かしています。

抽象化レイヤーをしっかり実装することで、移植性が向上するので、将来的にWASMで実行したり、新しい設計の基板で実行したり、応用の幅が広がることも期待しています。

課題としては、既存のペリフェラルに関するpico-gemは、メモリの管理など、Family mruby OSの抽象化レイヤーに必ずしも適合しない場合があります。また、そもそもマルチVM環境での動作も想定されてないので、複数VMで動かないようにするために、何らかの排他機構も必要になるはずです。

GPIO、I2Cあたりは、HW抽象化レイヤー(HAL)を使いつつ、スレッドセーフな実装に書き直すべきかなと思っています。

開発場所

以下のOrganazationで開発してます。

ドキュメント等まだ全然整理できてないので、徐々に整えていきたいと思ってます。

Family mrubyFamily mruby has 10 repositories available. Follow their code on GitHub.GitHub

実行環境

Family mrubyは、専用の基板か、Linuxでの実行を想定しています。

専用基板

まだ量産版はありませんが、開発基板を設計して、JLCPCBのPCBAで生産してみました。しかし、うまく動かなかったので、現在デバック中です。

大まかなブロック図は以下のようになってます。半分やけくそでESP32を２つ搭載してます。将来、ESP32-P4で専用ディスプレイ使えば１チップ化もできるかな、と妄想してます。

HW設計データはすべて公開してます。

GitHub - family-mruby/narya-board: Dual ESP32 board for Family mrubyDual ESP32 board for Family mruby. Contribute to family-mruby/narya-board development by creating an account on GitHub.GitHub

実際の開発基板の写真です。BOMも間違いなく、きれいに実装できました。スルーホール部品の実装までやってもらったことはなかったので、勉強になりました。

Linux

ESP-IDFのLinuxシミュレーションおよび、SDK2とLovyanGFXを利用することで、fmrb-coreはほぼそのままに、Linux上でも実行できるようできました。

サブESP32に相当するものとして、別プロセスを立ち上げてます。SPIの代わりにソケットで独自プロトコルで通信してます。

Linux環境での構成

現状のデモ動画

Family mruby OSのデモ動画を撮りました。Linux環境でしか確認できてないので、基板のデバッグを完了させて、近いうちにこれをESP32でも同様に動かしていきたと考えています。

OSの管理機能と、壁紙やシステムバーの画面と、疑似Shellアプリをそれぞれ独立したMicroRuby VMで実行してます。Luaも独立して実行してます。
まだランチャーがないので、マウスのクリックに合わせて、疑似ShellとLuaのウィンドウを開いてます。
疑似Shellアプリは、Shellとしての機能はまだ実装されてませんが、キー入力は疑似Shellアプリが動くMicroRubyVMへ送信して、画面に反映してます。
マウス操作もまだ実装不十分なので、十字キー入力で、Shellウィンドウを動かしてます。

Family mruby OS prototype

デモ動画

Shell風アプリ（表示だけデモ）のコード

これは現状デモ用なので、STDIO対応などした上で将来大きく変更されると思います。どれくらいのコードでデモ動画のようなことが実現できているのかの参考になれば。

https://github.com/family-mruby/fmruby-core/blob/main/main/app/default_app/mrblib/shell.app.rb

class ShellApp < FmrbApp
  def initialize
    super()
    @current_line = ""
    @history = []  # Line history
    @cursor_x = 0
    @cursor_y = 0
    @char_width = 6
    @char_height = 8
    @prompt = "> "
    @need_redraw = false
  end

  def on_create()
    @gfx.clear(FmrbGfx::WHITE)
    draw_window_frame
    draw_prompt
    @gfx.present
    puts "[ShellApp] on_create called"
  end

  def on_update()
    if @need_redraw
      redraw_screen
      @need_redraw = false
    end
    33 # msec
  end

  def draw_prompt
    # Draw all history lines
    @history.each_with_index do |line, i|
      x = @user_area_x0 + 2
      y = @user_area_y0 + 2 + (i * @char_height)
      @gfx.draw_text(x, y, line, FmrbGfx::BLACK)
    end

    # Draw current input line
    x = @user_area_x0 + 2
    y = @user_area_y0 + 2 + (@history.length * @char_height)
    @gfx.draw_text(x, y, @prompt + @current_line, FmrbGfx::BLACK)
  end

  def redraw_screen
    # Clear user area
    @gfx.fill_rect(@user_area_x0, @user_area_y0,
                    @user_area_width, @user_area_height, FmrbGfx::WHITE)
    draw_window_frame
    draw_prompt
    @gfx.present
  end

  def on_event(ev)
    puts "on_event: shell app"
    p ev

    if ev[:type] == :key_down
      handle_key_input(ev)
    elsif ev[:type] == :key_up
      handle_key_up(ev)
    end
  end

  def handle_key_up(ev)
    keycode = ev[:keycode]

    # Window position control with arrow keys
    x = 0
    y = 0
    case keycode
    when 82  # up
      y = -10
    when 81  # down
      y = 10
    when 80  # left
      x = -10
    when 79  # right
      x = 10
    end

    if x != 0 || y != 0
      set_window_position(@pos_x + x, @pos_y + y)
    end
  end

  def handle_key_input(ev)
    keycode = ev[:keycode]
    puts "[Shell] keycode=#{keycode}"

    # Enter key (keycode 13 = CR)
    if keycode == 13
      handle_enter
      return
    end

    # Backspace key (keycode 8 = BS)
    if keycode == 8
      handle_backspace
      return
    end

    # Ignore arrow keys (79-82)
    if keycode >= 79 && keycode <= 82
      return
    end

    # Convert keycode to character (ASCII printable range)
    if keycode >= 32 && keycode <= 126
      char = keycode.chr
      @current_line += char
      @need_redraw = true
    end
  end

  def handle_enter
    puts "[Shell] Command: #{@current_line}"

    # Add current line to history
    @history << (@prompt + @current_line)

    # TODO: Execute command here and add output to history

    # Clear current line
    @current_line = ""

    # Check if we need to scroll
    max_lines = @user_area_height / @char_height
    if @history.length >= max_lines - 1
      # Remove oldest line to make room
      @history.shift
    end

    @need_redraw = true
  end

  def handle_backspace
    if @current_line.length > 0
      @current_line = @current_line[0...-1]
      @need_redraw = true
    end
  end

  def on_destroy
    puts "[ShellApp] Destroyed"
  end

end

# Create and start the system GUI app instance
puts "[ShellApp] ShellApp.new"
begin
  app = ShellApp.new
  puts "[ShellApp] ShellApp created successfully"
  app.start
rescue => e
  puts "[ShellApp] Exception caught: #{e.class}"
  puts "[ShellApp] Message: #{e.message}"
  puts "[ShellApp] Backtrace:"
  puts e.backtrace.join("\n") if e.backtrace
end
puts "[ShellApp] Script ended"

これまでにやったこと

OS Framework
- 基本的な機能の実装
- FreeRTOSタスクでのマルチMicroRuby VM起動
  - マルチタスク化にあたって、メモリ空間の分離や、Tickの挙動などで、問題があったため、パッチをあててます。最終的にどう扱うかはもう少し検討したいところです。
- FreeRTOSタスクでのゲストVM(Lua)起動
- メモリプール管理
  - VMごとに独立したメモリプールを与えるように設計してます。アロケータについては、MicroRuby内ではデフォルトのestallocを利用し、その他ではTLSFを利用してます。estallocもマルチタスク環境で動くように設定してます。
Linux向け
- SDL2+LovyanGFXの実行環境
  - Audioは未実装
実機向け
- NESエミュレータからESP32へのAPUブロック移植
- fmrb-audio-graphicsの原理検証
  - LovyanGFX(NTSC)とAPUの同時動作確認済み
基板
- 試作基板の設計実装
  - ただし不具合あり
アプリケーション
- 開発用の描画サンプルのみ

今後の主な開発アイテム

OS Framework
- HIDのイベント管理/STDIOの差し替え
- Window管理（表示順、移動）
- アプリのライフサイクル
- フルスクリーンモード
- GUIデザインの刷新
Linux向け
- Graphics系の拡充
- Audio系の実装
実機向け
- コア間通信の実装
- USB HOST対応（キーボード、マウス）
- サブESP32のファームウェア実装
基板
- ESP32ボードのデバッグ
- 量産型の設計、試作
アプリケーション
- シェル
- ファイルマネージャ
- GPIOやI2Cデバイス連携のサンプルアプリ
- etc...

今後

今後は、まずはRubyKaigiへのCFP投稿、うまくいけば発表を目指して完成度を上げていきます。

開発アイテムは多岐にわたり、発展課題も含めると、とても数カ月で完了する内容ではないので、来年はずっと少しずつ開発を進めて完成度を上げていくつもりです。

ある程度、安定したら基板もセットで、イベントで販売したりしてみたいですね。

夢

このプロジェクトが形になってきたら、色々やってみたいことがあります。

VM間通信の強化
MicroPythonも取り込んで、MicroPython資産をどうにかして生かす
ドット絵エディタや音楽エディタも実装して、ゲーム開発環境として成立させる
GUIでI2CとかGPIOも操作できるようなアプリを作る
WiFiもつないで、ネットでアプリをシェアしたりDLできる仕組みを作る
Tab5やESP32-S3搭載の液晶パネル付きデバイスへの移植
LCD対応して、ミニキーボードも搭載して、PicoCalc風のデバイスを作る
Emscriptenでビルドできるようにして、ブラウザ上でも実行する。センサーとかの接続は、コンパニオンボードを開発してそれで行う

参考にしたプロジェクト

PicotronのFantasy Desktop

開発中に存在を知って、マイコン向けではないですが、UIのイメージが自分の理想にとても近かったです。

レトロな8bit風ゲーム開発環境です。

Picotron by Lexalofflewww.lexaloffle.com

PicoRubyとMicroRubyの歩き方

2025-12-15T03:02:44+09:00

この記事は、mrubyファミリ (組み込み向け軽量Ruby) Advent Calendar 2025に参加してます。

今日は、PicoRubyとMicroRubyについて、具体的にどんな技術なのか、どんな活用が可能なのか、いまいち想像がついていない方向けへの情報を提供できればと思っています。

PicoRubyとは

PicoRubyとは、hasumikinさんが開発されたオリジナルのmrubyバイトコードコンパイラとmruby/cのVMを組み合わせた、Raspberry Pi Picoのようなメモリのリソースが少ない環境向けのRuby環境です。

mruby単体でもコンパイラやVMを持っていますが、それだとRaspberry Pi Picoで動かすにはちょっとメモリが足りなかったのもあり、開発されたようです。

PicoRubyは、限られたリソースでmruby互換のコードを動かすだけでなく、以下のような特徴を備えてます。

フラッシュメモリ上のファイルシステムをFATで実装
動的コンパイルの仕組みを導入、ファイルシステム上のコードをrequireも可能に
USBのマスストレージクラスに対応して、簡単にファイルを読み書きできる
などなど

これらの特徴を備えることにより、単なる言語のマイコンポーティングを超えた統合された環境として実装されています。hasumikinさんもMicroPythonについて言及されてますが、PicoRubyによって、mrubyがMicroPythonに肩を並べるところまできたのではないかと思います。

R2P2とは？

R2P2とは、PicoRubyのアプリケーションとして、シリアル通信でアクセスできる簡易シェルを実装したものです。

PicoRuby Shellが起動した様子

中身では、以下のようなことを行ってます。

shellの実装はpicoruby/mrbgemsにあるので、R2P2は、アプリケーションの実装ではなく、エントリーポイントやターゲットにあわせたビルド環境の提供を行う役割になってます。

R2P2-ESP32とは？

R2P2をESP32に移植したものです。ビルド環境としてESP-IDFを利用するので、picorubyのコードはESP-IDFの作法のcomponent（picoruby-esp32）としてビルドする形式を取っています。

PicoRubyをESP32マイコン上で動かすR2P2-ESP32のはじめかた - QiitaR2P2 はRaspberry Pi Pico上で動作する PicoRuby で書かれたシェルシステムです。私はこのR2P2をESP32という別のマイコンで動作させる取り組みをしています。先日、 R2P2-ESP32 という名前でGitHubリポジトリも公開しました。 ...Qiita

PicoRubyはどんな要素から構成されるのか？

picoruby/mrbgems以下には、Rubyコードから使うgemや、コンパイラのバイナリや、mrubyやmruby/cのVMコードなど色々なレイヤーのmrbgemが並んでいます。

全体像を理解する上で重要なmrbgemは以下のあたりかなと思います。

mruby-compiler2
- Prismパーサーを取り込んでコンパイラが実装されています。ホスト側でのmrbcでも使われますし、マイコン上の実行中も使われます。
picoruby-mruby
- lib/にmrubyのリポジトリがサブモジュールとして取り込まれています。VMやmruby用のgemが参照されています。
- src/にはmrubyには元々含まれてないタスク機能に必要なtask.cなどが居たりします。
- mruby本家から改造が入っているので、hasumikin/mrubyを参照してます。
picoruby-mrubyc
- lib/にmruby/cのリポジトリがサブモジュールとして取り込まれています。
picoruby-filesystem-fat
- PCで使うように使うにはファイルシステムが大切です。こちらではFATのコードをビルドしてファイルシステムを実現してます、
picoruby-machine
- Sleep処理など、VMの実行に必要なHW依存部を定義しています。
picoruby-sandbox
- コンパイラを使って動的にコードをロードして実行するための仕組みを提供してます。

ビルドも含めて詳しく知りたい方は、以下の記事を読まれると良いかもしれません。

hasumikin.comhasumikin is a programmer.hasumikin.com

MicroRubyとは？

MicroRubyとは、RubyKaigi2025でhasumikinさんが発表したPicoRubyから派生した実装です。ざっくりいうとVMがmruby/cベースから、mrubyベースに変わっています。PicoRubyとの比較は、以下のhasumikinさん発表時の資料がわかりやすいと思います。

RubyKaigi2025 @hasumikin さんスライドより

その他参考になる記事はこちら。

RubyKaigi 2025 で発表したMicroRubyとはなんだったのか - hasumikin.comRubyKaigi 2025 で発表したMicroRubyとはなんだったのかhasumikin.com

特に面白いのは、mruby/cの特徴であるマルチタスク機能をmrubyに取り込んでいる点です。以下のあたりで実装されてます。

picoruby/mrbgems/picoruby-mruby/src/task.c at ff5693303ff27c5a11d3cb5cb0db7a29db9171dd · picoruby/picorubyPicoRuby is the smallest Ruby implementation for one-chip microcontrollers - picoruby/picorubyGitHub

PicoRubyとMicroRubyは別のリポジトリ？

いいえ、今は同じpicorubyのリポジトリ上で開発されています。

各mrbgemの内部で、コンパイルオプションにより、PicoRuby向けと、MicroRuby向けの実装のどちらかが選ばれてビルドされています。

どうやってR2P2をビルドするのか？

rakeでビルドできますが、現時点での最新版だと以下のようなオプションが選べるようです。

PicoRubyとMicroRubyそれぞれについて、Raspberry Pi Pico, Pico-W, Pico2, Pico2-Wがターゲットとして選択できます。

私は試したこと無いのですが、Posixビルドもできるらしいので、Linuxでもデバイス依存しない部分は試せるようです。

$ rake -T
rake microruby:pico2:clean    # Clean microruby for pico2 (both debug and prod)
rake microruby:pico2:debug    # Build microruby for pico2 (debug)
rake microruby:pico2:prod     # Build microruby for pico2 (prod)
rake microruby:pico2_w:clean  # Clean microruby for pico2_w (both debug and prod)
rake microruby:pico2_w:debug  # Build microruby for pico2_w (debug)
rake microruby:pico2_w:prod   # Build microruby for pico2_w (prod)
rake microruby:pico:clean     # Clean microruby for pico (both debug and prod)
rake microruby:pico:debug     # Build microruby for pico (debug)
rake microruby:pico:prod      # Build microruby for pico (prod)
rake microruby:pico_w:clean   # Clean microruby for pico_w (both debug and prod)
rake microruby:pico_w:debug   # Build microruby for pico_w (debug)
rake microruby:pico_w:prod    # Build microruby for pico_w (prod)
rake picoruby:pico2:clean     # Clean picoruby for pico2 (both debug and prod)
rake picoruby:pico2:debug     # Build picoruby for pico2 (debug)
rake picoruby:pico2:prod      # Build picoruby for pico2 (prod)
rake picoruby:pico2_w:clean   # Clean picoruby for pico2_w (both debug and prod)
rake picoruby:pico2_w:debug   # Build picoruby for pico2_w (debug)
rake picoruby:pico2_w:prod    # Build picoruby for pico2_w (prod)
rake picoruby:pico:clean      # Clean picoruby for pico (both debug and prod)
rake picoruby:pico:debug      # Build picoruby for pico (debug)
rake picoruby:pico:prod       # Build picoruby for pico (prod)
rake picoruby:pico_w:clean    # Clean picoruby for pico_w (both debug and prod)
rake picoruby:pico_w:debug    # Build picoruby for pico_w (debug)
rake picoruby:pico_w:prod     # Build picoruby for pico_w (prod)

ビルドの仕組みは、rakeとCMakeが連動していて、かつ多段でビルドしたり、生成されるバイナリが複数あったりと、すこし複雑です。

またリポジトリもgit サブモジュールで複数のリポジトリが階層関係を持っています。下の図にその関係を図示してます。

ビルド全体の詳細を理解するには各サブモジュールのCMakeList.txtやRakefileも確認する必要があります。

R2P2は、picorubyを内包する形になっています。ESP32の場合は、ESP-IDFのcomponentとして、picorubyを扱うために、picoruby-esp32が存在しています。

サブモジュールの関係

picorubyの構成のポイントとしては、現在はmrubyのコードは、本家をフォークしたhasumikin/mrubyを参照してる点と、mrubycは本家を参照している点、picoruby/mruby-compiler2が、ruby/prismを参照している点あたりかなと思います。

R2P2-ESPの場合は？

コマンドは異なりますが、ESP-IDFが有効な環境で、R2P2同様にrakeでビルドできます。

ESP32でMicorRubyは使える？

今は使えません。

現状のpicorubyのESP32向けビルド設定（xtensa-esp.rb）では、PicoRubyのビルド用の設定しか用意されていないです。

また、picoruby/mrbgems以下の必須のmruby向けのポートが存在していません。

どう使えばよいのか？（あなたはどう使いたいのか？）

使い方は以下のようなパターンに分かれると思います。

ハードはこだわらずRubyのコードでセンサーやデバイスを使いたい

Raspberry Pi Pico2 あたりで、R2P2のビルド済みバイナリを書き込んで、Rubyで開発するのが王道と思います。（ただしmrbgemで対応できてないデバイスはC言語でバインドを書く必要がでてくることもあり）

M5StackとかのデバイスでR2P2使いたい

R2P2-ESP32を使うことなります。

現状はコードの転送のたびに、フラッシュを上書きする必要があったりするので、開発の利便性に劣るところがありますが、ハードの選択肢が広いのが魅力です。

MicroRubyでR2P2使いたい

現状は、Raspberry Pi Pico2 で rake microruby:pico2:prod とかするのが良さそうです。Pico1だとメモリ不足しがちなので。

R2P2以外のアプリケーションをPicoRuby/MicorRubyで作りたい

R2P2の実装を雛形にして、起動のシーケンスを書き換えることで、すぐ作り始めることができます。

今後の展望

思っていることをつらつらと。

個人的にはESP32推しなので、コメントがそちらに偏りますが、MicroRubyがより安定したら、ESP32向けの対応も進むのかな、と思ってますが、どうなのかな？（色々実装を追加することで、個人的なプロジェクトではMicroRubyをESP32で動かしてる実績ありますが、本家の方向性とは異なるので）

今準備中のシリアルによるファイル転送も取り込まれると、ESP32でも毎回ビルドしたりフラッシュの領域ごと上書きとかは不要になるはず。

Raspberry Pi Pico2でも、最近はPSRAM付きボードが出てきているので、メモリ面では結構緩和される日が来るのかな、と思ったりします。

PicoRuby向けのM5Unified/GFX mrbgemを作る話

2025-12-02T02:43:02+09:00

この記事は、mrubyファミリ (組み込み向け軽量Ruby) Advent Calendar 2025に参加しています。

本日の記事では、先日のTokyuRuby会議16 でLTした内容をブログ記事としても残しておきたいと思います。

ESP32とPicoRuby

PicoRubyはもともと、@hasumikin さんがRaspberry Pi Picoをターゲットとしてスタートしたプロジェクトです。

その後、ESP32への対応も@Yuuuさんの尽力もありなされています。(picoruby-esp32)

PicoRubyをESP32のcomponentsとしてビルドしてリンクするような形でポーティングされています。

現在は主なESP32シリーズで、PicoRubyを動かすことができるようになっています。

M5Stackシリーズを使いたい

ESP32を使いたい理由の一つとして、市場にいろいろなバリエーションのESP32をコアとしてパッケージングされた製品があるという点があると思います。

M5Unified/GFXを使いたい

M5シリーズにはディスプレイやボタンやスピーカーなど色々なデバイスが標準搭載されていますが、機種を変えるたびにAPIの仕様が微妙に異なることがあったのを解決するために、機種をまたいだAPIとして、M5Unified（グラフィクスはM5GFXが担当）というライブラリがあります。Arduino以外にもESP-IDF環境でも利用可能です。言語はC++です。

機種を違いを意識しないでプログラミングするには、これを利用しない手はないわけです。

しかし当然PicoRubyには対応していないので、PicoRubyから使うには各メソッドのバインディングを書く必要があります

どうやって大量のバインディングをさばくか

メソッドの数が少なければ、手作業でバインディング書けばよいところではあるのですが、幅広い機能を抽象化しているため、メソッドの数が数百もあります。

これを手作業で書くのはあまり現実的ではないというか、あまりやりたくない作業です。

たとえばCRubyであれば、Ruby-FFIというものがあり、Ｃ言語のライブラリをダイナミックリンクして、各関数のインタフェースを自動で定義する機能があります。

こういう場面で役に立つ機能なのですが、マイコン上で動くmrubyではそのままではFFIを動かすことはできません。

そのため、Claude Codeでどこまでやれるか試してみることにしました。

AIに仕事をやらせるための手順

これまでClaude Code使ってきた感覚として、漠然と大量の仕事をやらせても、途中でコンテキストが切れて、一貫性のある作業が難しくなります。

そのため、作業をステップに分割しつつ、進捗もドキュメントに書きつつ、途中でとまって再開できるようなことを意識しつつ、作業してもらう必要あります。

今回は以下のような手順でやってもらいました。

実装対象の関数をC++ヘッダからスクリプトで抽出
抽出した結果をYAMLにまとめる
YAMLからmrubyバインディングのスケルトン関数を生成
スケルトン関数を段階的に実装

中間生成物

作業する中で、各メソッドは以下のようなYAMLで抽出されます。

classes:
- name: M5Unified
  namespace: m5::m5
  file: M5Unified.hpp
  methods:
  - name: getPin
    return_type: int8_t
    parameters:
    - type: pin_name_t
      name: name
    modifiers: []
    line: 250
  - name: getButton
    return_type: Button_Class&
    parameters:
    - type: size_t
      name: index
    modifiers: []
    line: 252
  - name: getDisplay
    return_type: M5GFX&
    parameters:
    - type: size_t
      name: index
    modifiers: []
    line: 256
  - name: getDisplayCount
    return_type: std::size_t
    parameters:
    - type: void
      name: ''
    modifiers:
    - const
    line: 260
...

これベースにをCのmruby/c用のバインディングの作法に則った形のスケルトン関数にします。

結果

まずは一番ニーズがあるであろう描画系を試してみました。

よく使うであろうメソッドから対応して、100メソッドほど実装しました。

全体: 99/180 (55%)

M5Unified Core: 20/20 (100%) ✅

M5GFX Color: 12/12 (100%) ✅
M5GFX Draw: 30/30 (100%) ✅
M5GFX Fill: 3/13 (23%)
M5GFX Text: 9/31 (29%)
M5GFX Image: 2/13 (15%)
M5GFX Display: 9/29 (31%)
M5GFX Low-level: 4/18 (22%)
M5GFX Utility: 0/13 (0%)

サンプルコード

以下のコードを、/home/m5.rb として保存して、R2P2を起動させて実行してみます。

r# M5Unified Basic Display Example
# Based on actual C extension implementation

require 'm5unified'

puts "Initializing M5Unified..."

# Initialize M5
M5.begin

disp = M5.Display

w = disp.width
h = disp.height
puts "Display: #{w}x#{h}"

# Clear screen to black
disp.fill_screen(0x000000)

# Set text properties and display title
disp.set_text_color(0xFFFFFF)  # White
disp.set_text_size(2)
disp.set_cursor(10, 10)
disp.print("Hello M5!")

# Draw shapes with RGB888 colors
puts "Drawing shapes..."

# Red rectangle
disp.fill_rect(10, 40, 100, 60, 0xFF0000)

# Green circle
disp.fill_circle(w/2, h/2, 40, 0x00FF00)

# Blue line
disp.draw_line(0, 0, w-1, h-1, 0x0000FF)

# Yellow triangle (now implemented!)
disp.fill_triangle(w-80, h-40, w-30, h-60, w-10, h-20, 0xFFFF00)

# Cyan text label
disp.set_text_color(0x00FFFF)
disp.set_text_size(1)
disp.set_cursor(10, h-20)
disp.print("PicoRuby on M5")

puts "Drawing complete!"
puts "Press Ctrl+C to exit"

loop do
  M5.update
  sleep 0.1
end

m5.rb

ターゲットデバイス

M5Stack FireとM5StickC Plust2でさっきのサンプルコード試してみました。

無事、同じコードで、同じような描画がされましたね。

M5Unifiedは自動でデバイス認識する機能があるため、特に機種を指定することなく違うLCDでも正しく動作します。

課題

おそらくこの調子でやれば、全メソッド制覇もできそうではあるのですが、そのメソッドのコードレビューと動作確認をするのがかなり大変です。

また何かバージョンアップがあった時の追従も大変そうです。

個人的に使う分にはいいのですが、継続的なメンテナンスが厳しそうなので、今後どうしたものか悩ましいです。

またFFI的なアプローチもあるかなと思ったのですが、M5UnifiedがC++なので、Cと違って、シンボルテーブルを解析して、FFI的なものを自作するのも厳しそう、となっています。

以下は、現在のPicoRuby mrbgem実装です。一応、導入方法も記載したので、試して頂くこともできるかと思います。

GitHub - kishima/mruby-m5unifiedContribute to kishima/mruby-m5unified development by creating an account on GitHub.GitHub

R2P2-ESP32に統合したブランチはこちら

GitHub - kishima/R2P2-ESP32 at m5unified_dev3PicoRuby shell for ESP32. This project runs PicoRuby on ESP32 using picoruby-esp32. - kishima/R2P2-ESP32GitHub

チキントマト煮と鶏レバーペーストのレシピの記憶

2025-11-30T23:28:50+09:00

昨日はTokyuRuby会議１６があり、そこで差し入れ料理の投票で１位を取ることができました。食べて頂いたみなさん、ありがとうございました。

長年スタッフ側で参加してて、いつか飯提供したい気持ちをずっと、温めてたんですが、今回は一般参加で飯提供の念願叶った上に、飯王までとれて最高でした。

その時のレシピを自分のためにも残しておきます。

分量は目分量でやってたので、そのあたりは適宜補完ください。

今回の料理の品目アイデア出しのブレストにはChatGPTにも手伝っていただきました。ありがとう。

チキントマト煮

3リットル分つくった

材料

国産鶏むね肉（ハナマサで購入）
トマト缶
赤ワイン
たまねぎ
にんじん
にんにく
マッシュルーム
ローリエの葉
ローズマリー（生）
塩
コンソメの素
オリーブオイル
サラダオイル

下処理

鶏肉はまず塩を強めに降って揉み込んで数十分おいておく

鶏もも肉５枚分。包丁研いでなかったので、カット大変だった

塩で処理した鶏肉は水で洗い流して、余分な油を切り落として、一口サイズに切り分ける

切り分けた肉は皮を背にして、サラダオイルを引いたフライパンで表面を焼いて、余分な脂を落とす

赤ワインは半量くらいまで煮詰めておく

本調理

鍋でオリーブオイルを引いて、にんにく、玉ねぎ入れる。塩を軽く振る。

玉ねぎを焦げ付かないよう、玉ねぎが小麦色程度まで炒める。

トマト缶を入れて、とろみが出るまで煮詰める。

鍋に、焼いた鶏肉、煮詰めた赤ワイン、カットしたマッシュルーム、刻んだ人参、ローリエの葉、ローズマリー、コンソメの素、水を入れる

しばらく煮込む

味見して、必要ならローリエ、ローズマリーを引き上げる。

味を見て、塩で調整。

シャトルシェフの保温ケースに入れて、２，３時間おく

（最初、ローズマリーの香りが結構強く出ていたが、保温することで全体的に味や香りがまろやかになり、肉もほろほろになって最高だったので、この２，３時間の保温は重要）

完成

鶏レバーペースト

クラッカーと合わせて

材料

国産鶏レバー（ハナマサ）
玉ねぎ
にんにく
生クリーム
バターたくさん
塩
こしょう
ローリエの葉
イタリアンパセリ

下処理

レバーを水で洗う。ハツがついていたら外す。

血の塊が血管につまってたらしごいて出す

（できれば包丁でレバーを開いたほうがよい）

水を交換しながら濁りがすくなくなるまで洗って、しばらく水につけておく

本調理

玉ねぎはみじん切りにする

フライパンで玉ねぎにんにくをオリーブオイルで炒める

レバーを入れて軽く炒める

生クリームとローリエ。コンソメ、塩コショウを入れて少し煮込む（煮立てすぎるとクリームの油分が分離するので弱火で）

レバー＆ハツ４パック分

レバーに火が通ったら、火を止めて、ローリエを引き上げる（レバーに火を通しすぎると滑らかさが減るのでいい塩梅で火を通す）

網で裏ごしする（量が多いと、とても大変なのでミキサー推奨）

バターも予熱で溶かして、全体をよく混ぜる

味見をして塩で調整

容器に入れて冷蔵庫で冷やす

完成

食べるときにパセリを散らすとよい

TokyuRuby会議16での提供のようす

チキントマト煮をシャトルシェフごと持ち込んだ

リッツと合わせて提供

PicoRubyベースのミニコンピュータ（PicoCalc編）

2025-11-26T08:58:48+09:00

以前の記事で、PicoCalcが届いたら、PicoRubyを動かしてみたい、というお話をしていました。

/2025/06/picorubybesunominikonpiyuta/

9月頭に実際にPicoCalcが実際届きました。5月に注文していたので、4カ月弱で届いたことになりますね。

PicoCalcはRaspberry pi Picoで動くコンソールマシンです。

320x320の液晶とキーボードにスピーカーなどもついてきます。

付属のPicoにブートローダソフトがあらかじめインストールされており、SDからアプリを起動することができます。

インストールされているバイナリのソースはこちら。

GitHub - clockworkpi/PicoCalc: A calculator like nothing you've ever seen before, right?A calculator like nothing you've ever seen before, right? - clockworkpi/PicoCalcGitHub

以下、PicoCalcの写真たち。

外箱

組立前の中身

PicoMiteを起動させたところ

開発環境

ファームウェア側をいじることになるため、毎回手作業でファイルコピーするのは面倒です。そのためPicoProbeを繋いでみました。ただ、そのままで背面からデバッガー用の線を出すのはちょっと厳しかったので、ケースの背面の一部だけカットして線を通す穴を作ってます。

Probeを接続したところ

改造の方法

PicoCalcでPicoRubyを動かすためには、PicoRubyの文字列の入出力周りを置き換える必要があります。

PicoRuby Overflow Kaigiで展示した以下の資料で考え方を説明しています。

PicoRuby Overflow Kaigi

この時は、まだ実機が無かったので、類似の液晶コントローラで動いている液晶と、キーボードはI2C対応の別のM5Stackから出ているやつを使ってます。

実際にPicoCalc実機に移植するときは、最低限の修正で１日で動かすことができました。

コードはこちら。PicoCalcお持ちであれば試せます。私はRpi-Pico 2で試してます。

GitHub - kishima/picocalc-R2P2: PicoRuby shell for PicoCalcPicoRuby shell for PicoCalc. Contribute to kishima/picocalc-R2P2 development by creating an account on GitHub.GitHub

実際に起動させるときには、横幅の解像度が標準より狭いので、そのままだとPicoRubyのロゴが表示されません。そのためShell起動処理にあるロゴの絵文字を手作業でいじって、ぎりぎり収まるように修正してます。

PicoRubyを起動させたところ

一応、基本的な機能は使えるはずです。

課題

画面のスクロールするときに全画面かきなおしているため、スクロールがとても遅いです。液晶コントローラとうまく連携して高速描画やスクロール処理するなど、改善が必要です。

今後のこと

いったん、動かせて満足しちゃったところはありますが、自作のESP32コアの基板と連携させたりできたらいいな、とか、この素晴らしい機体を生かす方法は考えていきたいと思っています。

昔、Arduino Uno（RAM 2KB）でmrubyのバイトコードを走らせた話

2025-10-14T00:27:02+09:00

背景

最近、生活が落ち着いてきたので、また電子工作やmrubyを触るようになりました。

ここ数年はPicoRubyが一部で盛り上がっており、私も勉強会に参加しつつエンジョイしているところであります。

PicoRubyのすごいところは、Raspberry Pi Picoのような264kBというメモリが少なめの環境でも、マイコン上でmrubyのコードをコンパイルして、実行できるところです。これまでいちいちPCでバイトコードにコンパイルしてマイコンに焼いたりしないといけないところが不要になります。加えてPicoRubyではターミナルで動くShellや、USBストレージまで実装されていて、それもまた使いやすさに大きく貢献してます。

※ちなみに素のmrubyでもESP32のPSRAM(2MBや4MB)付きのものであればマイコン上でコンパイルできます。（Family mrubyの取り組み）

作者の羽角さんと以前、Arduinoでmrubyをなんか動かしたことがある、という話をしたときに、ふつう動かないよね？となったのですが、その時自分でも自分が何をしたのか完全に忘れていたので、それを振り返っておこうかなと思いました。

Arduino Unoで動かすとは？

Arduino UnoはFROM32KB、RAM2KBです。RAMについて言えば、Raspberry Pi Picoの1/100です。

mrubyの小型VMであるmruby/cでも実行時のメモリ40KBとあるので、ふつうに考えて全く動かないのです。

mruby/cITイノベーションセンター（ITOC）｜公益財団法人しまね産業振興財団

動かすために何をした？

自分の本に詳しく書いてました。2018年の技術書典5で出した同人誌です。

mruby/cの小さな世界 | インプレス NextPublishing【マイコン上でもRubyを使ってみよう】本書はRubyの組み込みハード向け実装であるmrubyをベースとし、よりリソースの限られたマイコンなどの環境...NextPublishing デジタルファースト宣言！

商用本にもなっているので、ブログにはあまり書き残してなかったので、詳細忘れてました…

やったのは以下のようなことです。

mrubyのバイトコードのうち、対応するものを削る＝mrubyの機能を削る
mruby/cのVM実装をベースに不要な部分を削っていく
シンボルなど、定数として扱えるものをROMへ割り当てるようにする
- Arduino用プレフィックスが必要になるため、バイトコードファイルを解析して、C言語コードを吐くような、ポストプロセスを実装
ArduinoIDEでコンパイルでは、8bitマイコンでも、8bit以上の変数を扱えるように対応してくれているので、mruby/cベースのコードもコンパイルできた

とにかくROMに割り当てることで、2KBのメモリには実行時に生成するオブジェクトだけ乗るようにしました。

データ構造とビルドの流れ

ROMにシンボルを置いてRAMを節約、という発想の取り組みはmruby本家でも対応されて、presymとして利用されています（私の理解があってれば）。

結果、この挑戦では、簡単なメソッド呼び出しやループくらいは動くようになりました。

サンプルコードとVMをビルドした結果

コードは以下で公開しています。

GitHub - kishima/micro_mruby_for_arduino_uno: An Arduino library of mircro mruby VM implementation for Arduino unoAn Arduino library of mircro mruby VM implementation for Arduino uno - kishima/micro_mruby_for_arduino_unoGitHub

このときはmicro mrubyなんて名前をつけてました。

PicoRubyやMicroRubyが存在している現在だと、FemtoRuby とでも呼んだほうがいいのかもしれませんね。

利用してくださった方々

実用性皆無と思ってましたが、ググッてみたら、利用してくださった方がいることを今さら見つけて嬉しかったので、リンクしておきます。

micro_mruby_for_arduino_uno を使って Arduino Uno の上で動くアプリケーションを Ruby で書く - Qiitaこの記事は、Fujitsu Advent Calenderの 19 日目の記事です。はじめに @GORO_Nekoです。ご存知の方ご無沙汰してます。初めての方お初にお目にかかります。えーっと、先にお断りをば一言。自分、仕事では一切 mruby や mruby/c を...Qiita Ruby on Jam!? micro mruby VM for LPC1114, ひとまずIchigoCakeで動かしてみようIchigoJamでRubyを動かす2つ目のアプローチ、mrubyの中間コードをIchigoJamで動かすトライ、ひとまずプログラムサイズが50KB程度だったので、ROM56KB/RAM8KBのIchigoCakeで動作確認！点滅しました！...福野泰介の一日一創 / create every day

今後のこと

Arduino Unoでバイトコード動かすのはちょっと無理があるので、この件については特に何も展望はないですが、こういう隅っこを攻める開発は頭の体操によいと思います。

最近は、ESP32を２個使って、Family mrubyの進化版を開発してます。

電子工作遍歴をたどる（１）

2025-07-25T01:16:40+09:00

経緯

最近、Rubyの界隈で自作キーボードからの派生も含めて電子工作を始める人が増えているようで、もう少し前からやってた自分としては、そんな状況がとても嬉しく小躍りしてます。

私は色々動画とか見つつ、それに憧れて、真似をしたり創作をしたりを繰り返して、だんだん作りたいものを作るのに何をすればよいか判断できるようになってきました。

一応組み込みに近い開発やら研究やらPMの仕事をしてきましたが、直接的にマイコンを触ることはほとんどなかったので、背景知識はありつつも、それ以外は初心者からスタートした人間です。

最初のハードルの高さを超えると一気に楽しくなった実感があるので、そのハードルを下げるお手伝いを色々したいなと思っています。

話は変わりますが、先日、PicoRuby Overflow会議というのがあり、少しポスターセッション的な枠で参加したりして、とてもいい時間を過ごしてきました。そこで色々新しいことの挑戦される方の話を聞いて、応援したい気持ちが更に高まりました。

支援の一つとして、昔書いた「ゼロから始めるmrubyデバイス作り」のLight版を無償公開しました。

https://kishima.github.io/my_books/20250719/my_mruby_device_light_v1.0.pdf

私も最初から、基板を作ったりしたわけではなく、色々既存のものを組み合わせたり、真似したりして楽しむところからのスタートでした。ネットを眺めるとすごい作例ばかり目につきますが、誰でも最初は小さなところからのスタートだったはずなので、その過程の例を紹介できれば、電子工作の気持ちの面での壁を超えるサポートができるかと思って、作例を紹介することにしてみました。守破離の流れをお伝えできればと思います。

最初の２つは思い出話から。写真とかはなく。

作例１　じゃんけんマシン

小学生のころ、小学校の図書館にあった工作の本に、ICとか使わずに配線だけで、じゃんけん対戦ができる装置の作り方が書いてありました。

夏休みの自由研究でそれを見様見真似で作ったことがあります。多分これが記憶に残っているうちで最初の電子工作だと思います。

はんだ付けもした記憶があります。ホームセンターに売ってる安いはんだごてで、人にも聞かずだいたいは一人で延々と取り組んでた記憶があります。当時の状況を思うと、感傷的になる思い出です。

どんな回路だったんだろうなあ。あの本をもう一度読んでみたい。

作例2　音でLEDが光るマシン

多分その次の年の夏休みに作ったもの。小学６年生でしょうか。

当時かそのちょっと前、音に反応してくねくねするダンシングフラワーが流行っていて、それを見て、音で反応するトリガーにできるのなら、何か光らすことができるんじゃないかと思い、ダンシングフラワーを分解しました。

ダンシングフラワーのコアを、スイッチを入れると複数のLEDがチカチカする電子工作キットのスイッチとして無理やり合体させました。

電圧とか電流とかよくわかってないのに、よくやったなあ、と思います。

たぶんこれが最初の創作電子工作だと思います。

それ以降は、BASICを触り始めたり、部活が忙しくなって、電子部品関連触るのは大学の工学部の授業までおあずけになります。

大学では電気系だったので、最低限の電気回路関係の基礎は学びました（不真面目な生徒でしたが）。当時はどうやって使う知識なのかよくわかってなかったですが、電子工作を始めてやっと肌身をもって感じことができた知識も多いです。

作例３　ESP32で温度センサー

時間は流れて、社会人になりました。社会人になって本格的な産業用の組み込みソフト開発にも触れて、RTOSや組み込みLinuxなどの経験も積みましたが、電子工作はほとんどやってませんでした。

特に2014～2016年まで、仕事で海外出張繰り返して、人生で最高にやばい時間を過ごしてた反動で、何かいままでやりたいと思ってできてなかったこととして、電子工作にも手を出そうと思いました。

加えて、そのやばい仕事で、ソフトウェアのPMとして初めてHW屋さんとバチバチやりあった経験もあって、HW屋さんとの会話について行けるように電子機器の基礎知識を付けたいという思いもありました。仕事で長年組み込みやっているフリーランスの方にもArduino使った治具作ってもらって助けてもらったのもあり、それくらい自分で作れるようになりたい、という思いとかいろいろ重なっていたように思います。

記録を振り返ると、やっとプロジェクトが落ち着いてきた2016年の中ごろに、ESPシリーズを触り始めたようです。

ESP8266で温湿度センサーをつないで、結果をさくらVPSのサーバに送っていたと記憶してます。

温度センサがマイコンに近いと、放射温度を拾っているのか、結構温度が高くでてしまう現象に遭遇して、センサの難しさも学びました。

ブレッドボードを始めてまともに使ったかも

ユニバーサル基板にセンサのせて、長時間稼働させたりした

作例４　ラズパイ遊びとUSBスピーカー

それから勤務場所の変化とかあり、少し間が空いて、2017年。このあたりから電子工作を本格的にやってみようという気が出てきたようです。

ラズパイ３を買って、モニタ付きのセットに乗せてみたりしました。

ゲームを動かしたりしたくて、USBスピーカーを繋ぎましたが、ちょっと市販品が大きかったので、練習がてら、小さなスピーカー＋アンプ回路＋USBオーディオ変換を合体させて、小さなUSBスピーカーを作りました。

ここのあたりからコロナ期になるまでの数年間集中的にいろいろ作りました。

市販のUSBスピーカーを繋ぐ

ラズパイ搭載モニタ

USBオーディオ変換を分解して信号と電源を横取り

アンプの基板（秋月？）

はんだ付け汚い

関西Ruby会議08で発表してきました

2025-07-01T02:37:42+09:00

ありがたいことに投稿した発表が採択されたので、2025/6/28 京都にて開催された関西Ruby会議08にて、発表してきました。

とてもよい２日間だったので、その記憶を残しておきたいと思います。

CFPに応募した経緯

２月にあったTokyu.rb（＝飲み会）に参加した際に、どんな話の流れだったか覚えてないですが、@makicamelさんから、kishimaさんも参加しましょうよ！という話をしてもらって、それがきっかけで、イベントの存在を知りました。

遠征するのであれば、発表するくらいの理由がほしいと思っているのと、久しぶりに個人開発も再開していきたいと思ったので、会議ドリブン開発も意図して応募してみました。

直近の半年くらいのお仕事がROS 関係でだいぶ忙しく、その分、未知の分野の経験が蓄積された感触があったので、これをなんとかRubyの世界に引っ張ってきたいと思って生まれたテーマです。

当日までの準備

久しぶりに本格的にmruby触るので、勘所復習するところからで、なかなか大変でした。特にビルド環境整理したり、寄り道でPicoRuby関係のデバッグしたりに時間をだいぶ使ってしまったので、直前にだいぶばたばたしてしまいました。若いときほど体力もないので無理はよくない・・・。

発表の内容

登場する際に出囃子的な音楽を掛けていただけるということで、悩んだ結果、ロボット絡みの発表テーマに合いそうで、好きな曲ということで、FF6の「魔導研究所」が頭に浮かんだので、それでお願いしました。（FF6は子ども頃にサントラCDずっと聴いたり、ピアノコレクションの楽譜買って打ち込んだりしてた程度には好き）

もともと子供の頃遊んだレトロゲームにずっと脳を焼かれている人なので、好きな音楽をバックに花道から登場する、という体験ができて思い出になりました。

資料はこちら。

伝えたいところは、20分の範囲で詰め込められたかなと思ってます。

mruby micro-ROSまだ道半ばなので、もっとAPIを整理して、他の人にも使ってもらえる形で紹介できればと思ってます。私の個人のgithubで開発中。

追記：発表中、ROSを使ったことある方～？という質問をしました。ライトがまぶしくて、手を上げてくださっている方が見つからなかったのですが、あとで聞いたら数名いらっしゃったようで、気づかず申し訳なかったです。ぜひお話してみたかった。

追記２：資料中の動画はオフライン再生できる準備をしておくこと

聴講者としての感想

他のトークの内容もそれぞれ色々なアプローチで、Rubyで何かを作る、作ってきたお話で、一貫して自分もなにか作ってみたくなる、そんなインスピレーションがもらえる内容だったと思います。そういった皆さんのすばらしい活動の一端に自分の活動も並べてもらえたと思うと、嬉しさが込み上げて来ました。

運営さんが熱量持ってこの会を作っておられるのも、端々に感じて、それも気持ちが上がりました。

過去にTokyuRuby会議の実行委員長をやらせて頂いたときの経験を思い返すと、こういう大きなイベントを運営することは、きっととても大変なはずなので、ydahさんはじめとする運営スタッフの皆さんには感謝しかないです。

最後の地域Rubyコミュニティのパネルセッションもたくさんのコミュニティが集まりつつ面白い軽妙なやり取りが繰り広げられていて、関西のパワー感じました。

準備で睡眠削ってしまってふらふらでしたが、あの鴨川の「川」にも合流できてこれも良い思い出になりました。端っこの方で先輩Rubyistの方々とお話してたら気がついたら４時前まで居たようです。

翌日

どうせ遠征するなら色々参加しようと思って、叡電LTと非公式打ち上げにも参加しました。

電車一両の参加者みっしり乗って、車内放送でLTするのが面白くないわけがなく、@makicamelさんの電車の中で、PicoRuby on Railsする発表は忘れられないLTになりました。

京都

LTのあと、ご褒美でうなぎ食べました。ラーメンとかも考えましたが、二日酔い的にちょっと厳しそうだったのでスキップ。

今年に入って仕事の出張ついでに京都に泊まる機会があり、そのとき中学生の修学旅行ぶりに二条城行こうと思って行ってみたら、受付終了してたということがあったので、そのリベンジとして、二条城行ってみました。

異例の６月の猛暑でかなりきつかったですが、歴史の舞台をしっかり目に焼き付けることができました。

ちょっと移動に時間かかりすぎて、打ち上げに遅れてしまったのが申し訳無かった。

最後に

行ってよかった。

色々作ってくの、もっとがんばりたい。そう思えるイベントでした。

PicoRubyベースのミニコンピュータ

2025-06-15T23:53:07+09:00

先日、SNSを見ていたらPicoCalcというデバイスを見つけた

PicoCalc | ClockworkPiClockworkPi - Creators of PicoCalc uConsole DevTerm and GameShell, Open Source Portable Hardware for Every Dev.ClockworkPi

これはclockworkから出ているRaspberryPi Picoをコアとして、キーボードとモニタを搭載したスタンドアロンなポケットコンピュータキットです。

clockworkはRaspberryPiベースのロマンあふれるデバイスをこれまで提供している会社で、私も昔クラウドファンディングに参加したこともありました。

私自身も、以前、ラズパイをタカチケースに入れて気合でポケコンもどきを作ったりしたこともあったので、この洗練された筐体には当然心が躍りました。

電子工作始めたころ作ったラズパイコンソールデバイス

デフォルトで動くのはBasicで、これもまた味わいがあってよきですが、やはり自分としてはmruby動かしたい、ということで、Raspi PicoといえばPicoRubyの出番です。特にR2P2がこの画面とキーボードで動くと熱い。

GitHub - picoruby/R2P2: PicoRuby shell for Raspberry Pi Pico (RP2040)PicoRuby shell for Raspberry Pi Pico (RP2040). Contribute to picoruby/R2P2 development by creating an account on GitHub.GitHub

そんな風に思って、とりあえず注文したのですが、結構発送に時間かかりそうです。

もし間に合えば、７月のPicoRuby Overflow会議に持っていきたいなと思っています。ちょっと実機で動かせる状態にするのは間に合わないかも、と思って試作用にI2Cキーボードの例を準備したりしてました。SPIのモニタは確か部品箱に何か眠っていたはず…

M5StackのI2Cキーボードカード

実現方法としては、RaspberryPi PicoのSDKによれば、stdioのドライバは任意のものが追加可能らしいので、そこを差し替えればよいはず。一度基本的なものが作れれば、あとはPicoCalc環境に移植するのも難しくはないはずです。

PicoCalcには、PSRAMやスピーカーとかも載っているので、専用のmrbgem開発するとより楽しく遊べそうです。

PicoRubyを理解する１

2025-05-28T19:17:50+09:00

PicoRubyA Ruby interpreter implementation for one-chip microcontrollers - PicoRubyGitHub

ちゃんと中身を理解できてなかったので、コードや資料を読んで理解したい。

特にパーサーやVMの周りをどうやって小さくできているのか。

まずは基礎知識から。

公式情報

PicoRuby DocumentationAPI documentationPicoRuby Documentation

羽角さんの資料

2025

MicroRuby: True Microcontroller RubyRubyKaigi 2025, #rubykaigiRubyKaigi RubyKaigi 2025 で発表したMicroRubyとはなんだったのか - hasumikin.comRubyKaigi 2025 で発表したMicroRubyとはなんだったのかhasumikin.com

MicroRubyとは？

Ruby会議には参加できてないので、詳細はブログの記事からの理解ですが、以下のような、図のような感じなのかと理解しました。コンパイラをカスタムして準備してしまうのが驚くべきところ。パーサーもPrismに置き換わっているらしい。

で、コンパイラの周りやmrbgemの扱いなどは、やはりコードを追っていかないといけない。

2024

Unlock The Universal Parsers: A New PicoRuby CompilerRubyKaigi 2024, #rubykaigiRubyKaigi 2024 令和の隙間産業——PicoRubyはどこから来てどこへ行くのか - HASUMI Hitoshi - Rabbit Slide ShowPresentation slide for 大阪Ruby会議04Rabbit Slide Show Ruby Prize 2021 最終ノミネート者羽角均インタビューRubyPrizeRubyPrize | Rubyコミュニティの「個人賞」

Matz：「そっか、256KBあったらmryubyのVMだけなら動くのか。」

ESP32でPSRAM 8M乗ってるとmrubyのパーサ/コンパイラも込みで動かせた実績あるので、Raspi PicoでもPSRAM搭載ボードなら行けるはず。

羽角さん「僕としては、PicoRubyとかmrubyのエコシステムを広げていくのに、PicoRubyコンパイラを作っただけじゃ面白くなくて、使われないと楽しくないわけですよね。」

とても共感。C書けるなら、Cで書いてしまっても良いのだけど、せっかく環境を作るからには他の人に使ってほしい。羽角さんは一人でエコシステムまで作ろうとしててほんとすごい。

n月刊ラムダノート Vol.4, No.1(2024)計算機好きのための技術解説情報誌エヌゲッカンラムダノート（不定期刊行）106ページ A5判紙書籍は1色刷 2024年2月6日第4巻第1号／通巻7号発行目次 #1 手を動かして学ぶストリーム処理入門（中谷翔）#2 WebAssemblyの制約を越える（齋藤優太） #3 PicoRubyといっしょに学ぶ、プログラミング言語が電気回路を動かす仕組み（羽角均）技術書出版と販売のラムダノート

買って読んでみた。

基本的なところからとても丁寧に書いてあるので、PicoRubyちゃんと使いこなしたい方は必読と思いました。

その他

mruby/c and data-flow programming for small devicesRubyKaigi 2025, #rubykaigiRubyKaigi mruby/c and data-flow programming for small devicesIn my presentation, I will show how data-flow programming can be used for software development of small devices. The effectiveness of the proposed method is demonstrated with a microcontroller implementation in mruby/c. In IoT programming, we want to focus on the flow of data generation and processing. This is data flow programming, also known as the Node-RED development environment. Data flow is processed asynchronously. I will explain how to implement this asynchronous processing in a reasonable manner using mruby/c and demonstrate its operation on a real microcontroller. - Download as a PDF, PPTX or view online for freeSlideshare

mruby/cについて、田中先生のスライドが公開されていた。

Node-REDから使えるようにした、というお話。

次のステップ

PicoRubyのコードを読む。

RubyとROS 2

2025-05-24T22:29:56+09:00

普段仕事でROSを触るときはPythonかC++を利用することになるが、Ruby好きとしては、やはりRubyでもノードを書いたりしたくなる。

ということで、すこし調べてみた。

ROS 2以前

調べるとROS 2ではなくて、ROSに関する取り組みはあるようだった。

GitHub - OTL/rosruby: ruby ROS client.ruby ROS client. Contribute to OTL/rosruby development by creating an account on GitHub.GitHub

九州工業大学の田中先生の研究室の学生さんの記事。対象はNoetic。

【Ruby】RubyでROSを動かしてみた - Qiita九州工業大学田中和明研究室の大学院生です。Rubyと産業用ロボットに関する研究に携わっています。背景 ROSでロボットを動かす場合、一般的にはPythonやC++を使用したプログラムが基本です。また、ROSは主にUbuntu上で動作し、ターミナル操作やUNIX系コマ...Qiita

ROS 2対応のrclrb

やはり今ならROS 2使いたいので、調べてみると１つだけ見つかった。

2024年5月の記事。

rclrb: bindings for using ROS2 with RubyHi everyone, I am happy to announce here bindings to use ROS2 RCL with the Ruby programming language. The bindings have been stable for a few months now and are ready for more wide spread usage. Feel free to report any issue on the gitlab tracker. The bindings can be installed as a gem or as a colcon package. Instructions can be found in the readme of the repository: Documentation is sparse, but the API is generally similar to Python/C++ one. The main difference is that the only available ex...Open Robotics Discourse

リポジトリ

rosrb / rclrb · GitLabGitLab.comGitLab

FFIでrclをラップしてRubyから使えるようにしてある実装で、コードもシンプルで素敵です。

動かしてみる

サンプルコードを動かしてみる。Pythonで書いたような雰囲気でROSのノードが書けている。

Publisher

require 'rclrb'

require 'std_msgs/msg'

class MinimalPublisher < Rclrb::Node
  def initialize()
    super("publisher_node")
    string_msg = StdMsgs::Msg::String.new
    string_msg.data = "Hello World!"
    pub = self.create_publisher(StdMsgs::Msg::String, "topic", 1)
    @timer = self.create_timer(1.0) do |time|
      pub.pub(string_msg)
    end
  end
end

def main(args)
  Rclrb.init(arguments: args)

  Rclrb.spin(MinimalPublisher.new)
end

if $0 == __FILE__
  main(ARGV)
end

Subscriber

require 'rclrb'

require 'std_msgs/msg'

$stdout.sync = true

class MinimalSubscriber < Rclrb::Node
  def initialize
    super("subscriber")
    self.create_subscription(StdMsgs::Msg::String, "topic", 1) { |msg| puts msg.data }
  end
end

def main(args)
  puts "start subscriber node"
  Rclrb.init(arguments: args)
  Rclrb.spin(MinimalSubscriber.new)
end

if $0 == __FILE__
  main(ARGV)
end

ROSのインストールとか大変なので、Dockerで簡単に試してみる環境を準備しました。

GitHub - kishima/try-rclrbContribute to kishima/try-rclrb development by creating an account on GitHub.GitHub

実行結果

$ docker compose up
[+] Running 1/1
 ✔ Container try-rclrb-ros-nodes-1  Created                                                                                     0.2s
Attaching to ros-nodes-1
ros-nodes-1  | run publisher node
ros-nodes-1  | ros2 node list
ros-nodes-1  | /publisher_node
ros-nodes-1  | ros2 topic list
ros-nodes-1  | /parameter_events
ros-nodes-1  | /rosout
ros-nodes-1  | run subscriber node
ros-nodes-1  | start subscriber node
ros-nodes-1  | Hello World!
ros-nodes-1  | Hello World!
ros-nodes-1  | Hello World!

細かいところ対応してなさそうだが、シンプルな使い方なら普通に使えそうと感じた。必要があれば、自力でrcl叩いて拡張することもできそう。

こちらも踏まえて、mruby絡めたり、いろいろ可能を探っていきたいと思って色々試しているところです。

JetCobotとJetson Orin NXを迎えた

2025-05-07T22:09:53+09:00

JetCobot

最近本業でロボットアームを扱う機会があり、いろいろ新しく知識も得たので、その経験を生かしてRubyと組み合わせていろいろ試してみたいと思って、個人でも買えるロボットアームを探してみた。

ElephantRoboticsのmyCobot280が手ごろで扱いやすそうなので、こちらを購入してみることにした。単体で買うとグリッパーや台座などついてなかったり、SwitchScience経由で買ったりするとちょっと高くなったりするのだけど、YahboomのJetCobotだと、一式揃って、加えてJetsonも付いて安かったので、そちらをAmazonで注文した。

香港からの発送で、１週間ほどでUPSで届いた（配達はヤマトだった）。

梱包の様子

組み立ては難しくなく、JetsonNanoをケースに収めて、本体とUSB接続して、電源を入れると自動で起動する。（付属の無線は使わないでおく）

myCobot本体はUSBシリアルで認識されており、それをPythonで制御している。

チュートリアルに従えば、紹介動画にあるような画像認識と制御のデモも簡単に試せそう。

JetCobot 7-axis visual collaborative robotic arm for Jetson NANO 4GB/Orin NANO/Orin NX

Jetson Orin NX 16GB

今回はさらに奮発して、Jetson Orin NX 16GBも購入した。

仕事では会社のプロダクトがJetsonベースだったりして、Jetsonをよく使うので、Isaac ROSを自分でも試して勉強したかったので購入した。別途買ってるロボカーと組み合わせてROSでVSLAMやNavigationあたりももっと試したかったのが理由。

JetCobot付属のJetsonNanoだとあまり自由が利かないので、Orin NXから制御しようと思う。

動かしてみる

Jetson nanoに最初からPythonの制御プログラムが起動するようにサービスが設定されているので、電源を入れると自動で初期位置に戻る。

そのプログラム

Ubuntu22.04とmyCobot280のシリアル

JetPack6.2をインストールした環境で試していたが、myCobotにつながっているUSBシリアルをつないでもOrinNX側でうまく認識したい。

CH341のドライバが読み込まれていない模様だったので、次の手順で対応してつながるようになった。

Fix Driver issues for CH340N usb serial chip in Linux (Ubuntu 22.04)Fix Driver issues for CH340N usb serial chip in Linux (Ubuntu 22.04) - CH340N_linux_fix.mdGist

そしてアームのUSBカメラの映像をCheeseで見ようとしたら、JetPack環境のlibjpegとマッチしてないようで、エラーが起きた。ffplayでUSBカメラも映ることが確認できた。JetPack環境は素のUbuntu環境と微妙に異なるので、ちょいちょいこういうことが起こる。

自由に制御する

JetCobotにはあまり依存したくないので、まずはmyCobotの環境をDockerでOrinNX側に作って、今後はそちらで開発を進めたい。elephantroboticsのPythonライブラリをインストールする。

GitHub - elephantrobotics/pymycobot: This is a python API for ElephantRobotics product.This is a python API for ElephantRobotics product. - elephantrobotics/pymycobotGitHub

バージョンによって依存関係があれこれあってビルドが通らなかったりしたが、とりあえず動かせたDockerの設定を以下に置いてある。いったんPythonを経由するが、余裕があればシリアルを叩く部分を移植できればと思う。

GitHub - kishima/mycobot-rubyContribute to kishima/mycobot-ruby development by creating an account on GitHub.GitHub

今後これをROS2、moveit2とも組み合わせて、rclrbとも連携させていく予定。

ロボカー(MentorPi)

SLAM関係も試してみたいので、LiDAR、深度カメラ付きのミニカーも購入した。

MentorPiという製品。Raspi5でコントロールするタイプ。

mrubyとESP32 2024

2024-12-21T11:47:37+09:00

こちらはmrubyファミリ (組み込み向け軽量Ruby) Advent Calendar 2024に参加している記事です。

※すみません、まだ準備中です。冬休み中に公開したいです>忙しい状態が続いているので、春くらいになりそう…

M5シリーズのESP-IDF開発環境をWSL2&Dockerで作る

2024-12-01T23:36:03+09:00

ESP32 PSRAM Timer Camera X

この記事は、M5Stack Advent Calendar 2024 に参加してます。

久しぶりのM5、ESP32

いろいろと作ってみたいものはありつつも、なかなか手がつかない日々でしたが、試したいことができたので久しぶりにM5シリーズのデバイスを買ってみました。

買ってみたのは、ESP32 PSRAM Timer Cameraです。こちらを使って、HTTPSでクラウドのサービスにつないでみるのが目的です。

で、今後また色々ビルドしたり、ESP32の機能を使うためにESP-IDF上で開発をしたいと思い準備しました。

ESP-IDFの環境はバージョンによってしばしば互換性が失われるので、昔のコードが最新Verでビルドできないのはしょっちゅうあるかと思います。そのときESP-IDFバージョンを上げ下げするのも大変です。

なので、試行錯誤するにはDockerで環境を作れると何かと便利です。その内容を共有したいと思います。環境はWSL2です。

準備

基本的には、公式の手順を読めばわかる内容ではありますが、すこし躓いた点もあったのでそのあたり説明したいと思います。

ビルドのコマンド例

例えば以下のようになります。

$ docker run --rm \
   -e MY_ENV_VAR="$MY_ENV_VAR" \
   -v $PWD/$TARGET_PROJECT:/project -w /project -u $(id -u $USER):$(id -g $USER) -e HOME=/tmp espressif/idf:$IDF_VER idf.py build

$PWD/$TARGET_PROJECT:/project の部分でホスト側のプロジェクトをコンテナから参照できるようにしてます。

$(id -u $USER):$(id -g $USER) ホスト側のユーザIDでコンテナ内で作業するようにします。

$IDF_VERの変数で、使用するIDFのバージョンを調整します。

Flash時のコマンド

通常は"idf.py -p (PORT) flash"でよいはずですが、なぜそれだとエラーが起きてしまったので、build時に表示されるesptoolを使ったコマンドを利用してます。

作業用のスクリプト

長いDockerコマンドを毎回打つのも面倒なので、簡単なシェルスクリプトにまとめました。menuconfigやイメージの書き込みなどもコンテナで実行できます。

実際のスクリプトはgithubで公開してます。（リンクは下の方に）

WSL2でESP32とシリアル通信

usbipdを使って、Windowsのホスト側のUSBデバイスをIP通信を介して、WSL2上でUSBデバイスとして認識させます。usbipdインストールについて検索すると色々情報が出てきますが、少し古くて、今だと不要な手順が書いてあったりするようです。

今(2024/12)は以下の公式の手順で準備するのがよいと思います。うまくいくと/dev/ttyUSB0として認識されました。

USB デバイスを接続するusbipd-win を使用して、USB デバイスを WSL 2 Linux ディストリビューションに接続する方法について説明します。learn.microsoft.com

Cameraのサンプルコードについて

ESP32 PSRAM Timer Cameraのサンプルはいくつか存在しているのですが、それぞれ依存しているESP-IDFのバージョンが異なっているようで、最新のIDFだとビルドできなかったりして、サンプルを動かすことが難しかったです。

GitHub - m5stack/TimerCam-idf: TimerCam idf exampleTimerCam idf example. Contribute to m5stack/TimerCam-idf development by creating an account on GitHub.GitHub

こちらはアーカイブになってました。

GitHub - m5stack/M5_Camera_Examples: M5 camera series product examples.M5 camera series product examples. Contribute to m5stack/M5_Camera_Examples development by creating an account on GitHub.GitHub

今はこちらを使うのが良さそうでした。対応してるESP-IDFのバージョンがReadmeに書いてないのですが、v5系はダメなようなので、v4.4.8で動かしました。

Docker開発環境の例

githubで開発環境用のサンプルスクリプトを公開してます。

.envをいじったり、src以下にプロジェクトを配置したりして、使用できるかと思います。

GitHub - kishima/dev-esp-idf-docker: Development environment for ISP-IDF on DockerDevelopment environment for ISP-IDF on Docker. Contribute to kishima/dev-esp-idf-docker development by creating an account on GitHub.GitHub

さいごに

Dockerを使うと簡単に環境を差し替えたり、持ち運びできるので楽ですね。またmrubyビルドしたりして、面白いものを少しずつでも作っていきたいです。

会社のサービスに繋いでみた話は、会社の技術ブログで後ほど公開予定です。

aptpod Tech Blog株式会社アプトポッドのテクノロジーブログですaptpod Tech Blog

kishima blog

test

同人誌書きつつRustでmruby VMを作った話

きっかけは本だった

何ができるか（2026 年 9 月末の時点）

Bevy に組み込む: rubevy

作り方: AI と一緒に作る

これから

RubyKaigi 2026 で登壇した話

経緯

事前準備

Day0

Day1

本番

harukasan(さん)の発表

謝辞

追伸：基板も販売してます。

2025年の振り返りと2026年の抱負

2025年振り返り

2/2 Tokyu.rb新年会2025

5/26PicoPicoRuby #1

5/28 Shinjuku.rb #99

6/28 関西Ruby会議08

7/19 PicoRuby Overflow会議

8/28 Ruby Association Activity Report

9/4 Omotesando.rb #113

9/9 ROSConJP2025

Family mruby開発

11/29 TokyuRuby会議16

12/4 Omotesando.rb #116

12/19 Shinjuku.rb #101

PicoRubyへのコントリビュート

2026年の抱負

趣味のプロジェクト

発表

料理

旅

運動

仕事

電子工作遍歴をたどる（２）

作例５ ラズパイとGroveによる音楽プレーヤ

作例６ GameBoy Zero

Family mruby OS: A Multi-VM MicroRuby System Built on FreeRTOS

Background and Motivation

What is Family mruby?

Features of the Original Family mruby

Dormant Period

Encounter with PicoRuby / MicroRuby

Differences Between the Original and the New Family mruby

Family mruby OS

Assumptions

Key Features

Adoption of MicroRuby

Multi-VM Architecture

Hardware Abstraction

Development Location

Execution Environments

Dedicated Hardware

Linux

Current Demo

Bouncing Ball App Demo Application Code

What Has Been Implemented So Far

Future Development Items

Looking Ahead

Dreams

References

Picotron - Fantasy Desktop

Family mruby OS：FreeRTOSベースのMicroRubyマルチVM構想

開発に至る経緯

Family mrubyとは？

特徴

休眠期

PicoRuby/MicroRubyとの出会い

初期Family mrubyと新Family mruby は何が違うのか

Family mruby OS

前提

特徴

MicroRubyを採用

マルチVM

HWの抽象化

作例５ラズパイとGroveによる音楽プレーヤ

作例６　GameBoy Zero

作例１　じゃんけんマシン

作例2　音でLEDが光るマシン

作例３　ESP32で温度センサー

作例４　ラズパイ遊びとUSBスピーカー