Pixels to Motors | 人とロボットの関わりをシミュレーションでデザインする

AIに任せたSEO対策 ― 公開したサイトは「Googleに載せない」設定のままだった。説明のない画像1万枚まで直した記録

Studio を閉じて、旧 URL は Cloudflare で転送する ― 公開・通知メール・DNS 移行・LOG への改番を1日で

サイトを pixelstomotors.com へ ― 動画が再生されなかった原因と、URL から /pixelstomotors を外した理由

フィジカルAI研究室を作る Log#5 | π0.5 を mechArm 270 の成功19本で2,000ステップ学習 ― 予測した最初の1秒が、お手本の平均とほぼ重なった

Studio を出て、GitHub に push すると公開されるサイトへ ― 553ページを Astro と Cloudflare に移し、画像は R2 へ

何本も並行する動画づくりを見える化する ― 段階の自動判定と、PCは一覧・iPhoneはハコブくんという役わけ

解説動画の作り方を2つ増やす ― 「試してみた回」の型と、画面の文字を大きくする大文字型で1本作った

フィジカルAI研究室を作る Log#4 | Physical Intelligenceπ0.5を mechArm 270 のデモで追加学習し、Mac で予測を受け取るまで

NVIDIAのAlphaNISTは二つ爪のグリッパーで組立を覚えた ― 成功か失敗かだけの報酬が生んだ滑らかな動きと、ソフト側の立ち位置

解説動画の台本15本 ― ネタ25本から絞った基準と、事実確認で直した29か所

サイトを Studio の外へ持ち出せる形で残す ― 533ページを1フォルダにまとめ、codex に2回検証させた

解説動画の1本目を公開まで通す ― 声・BGM・間・直し・サムネイルを部品ごとに決め、23手順にまとめた

YouTubeチャンネルの顔を作る ― チャンネル名・アイコン・バナーをハコブくんにそろえるまで

解説動画のナレーションをハコブくんに任せる ― 口と目と光をコードで動かし、文字が重ならない区画を決めた

解説動画をAIと作る ― 型の分析から敵対的検証まで、試作1本で決めたこと

MicroFactoryは市販アームFAIRINO FR3でロボットセルを作った ― アームは買い、手先を作り、AIは準備の段階に置く

ロボティクスを声に出して覚え直す ― 開発ログから用語164語と判断の型104枚の練習ページを作った

フィジカルAI研究室を作る Log#3 | Physical Intelligenceπ0.5をシミュレータで評価し、本当に必要なGPUメモリを測る

フィジカルAI研究室を作る Log#2 | Physical Intelligenceπ0.5を借りたGPUで動かし、Macから指示を届けるまで

画像認識と物体検出を学び直す Log#11 | Decisions API は爪の間のブロックを0%か100%で見分けたが、持ち上がったかは判定できなかった ― 把持判定テストと実機640試行の失敗分類

フィジカルAIは産業用ロボットの何を変えるのか ― 精度・導入コスト・操縦・人材育成を対話で整理する

論文4本で、SO-101 の成功率を左右する条件を先に確かめる

アバターと義体を考える Log#2 | ピカリくんとロボのアバターさん ― 生身を超えて操りたくなる分身ロボットを設計する

アバターと義体を考える Log#1 | アバターという義体に人が宿るとき ― 自動運転の先で、人は何を操りたくなるのか

AIにロボットを直接動かさせない設計 ― MicroFactoryの構成から、Physical AIが学習できる環境までを読む

AI外観検査は撮り方で決まる ― 照明の設計と検査員の限度見本から考える

役に立つロボットのタスクは、人が集まらない仕事から探す ― 箱の組み立てデモから研究テーマの選び方を組み直す

画像認識と物体検出を学び直す Log#10 | SAM 3 は透明なガラス瓶とペットボトルを同じ物として切り出した ― 言葉で指定する最新モデルを分別ラインの画像で試す

ロボットカー教材を比べながら自動運転の中身を分解した ― カメラだけのテスラ、専用チップ、AIから独立した安全層

道路の白線を引く機械の求人から考える ― フィジカルAIは人型ロボットより先に、既存の機械の中に入っていく

フィジカルAI時代のロボットに渡す仕事を、まだ誰も切り出していない ― 導入が進まない理由を現場の判断から考える

画像認識と物体検出を学び直す Log#9 | 用語を下から積み直す ― モデル・学習・推論から基盤モデルまで

計算資源のそばで実世界データを取る ― 秋田2兆円計画をロボティクスから読む

Autodesk Fusion でロボットの治具やパーツを作る Log#3 | イラストを1時間なぞったら、3D CADの中でロボットの形になった

画像認識と物体検出を学び直す Log#8 | 斜めから撮った紙を真上から見た形に直す ― 傾きを調べにいって物差しの誤差を見つけた

画像認識と物体検出を学び直す Log#7 | 特徴点マッチングで2枚の写真から同じ場所を見つける ― 別の物を撮った写真でも「同じ」と判定される

Autodesk Fusion でロボットの治具やパーツを作る Log#2 | ハコブくんの外形を Claude の指示だけで作ろうとして失敗した

Autodesk Fusion でロボットの治具やパーツを作る Log#1 | Fusion を Claude から動かせる状態にするまで

サービスロボットは現場のどこで止まるのか | 配膳・清掃・警備を調べて出てきた「例外」という共通点

ハコブくん 病院オペレーションのデジタルツイン Log#3 | 病院の搬送ロボットは看護師の負担を減らすのか ─ 作る前に調べたら、前提が四つ崩れた

画像認識と物体検出を学び直す Log#6 | 重心・面積・外接矩形・円形度 ― 紙を回すと壊れるのはどれか

Figmaのデザイントークンを整理する | 生hex 3,977箇所を変数化し、コントラスト不合格をゼロにするまで

画像認識と物体検出を学び直す Log#5 | モルフォロジー演算 ― 型紙が入らないものだけが消える

画像認識と物体検出を学び直す Log#4 | 光が変わると、赤検出が青を拾う

画像認識と物体検出を学び直す Log#3 | シーリングライトのオレンジの光の下で青いブロックが色を失う

画像認識と物体検出を学び直す Log#2 | 画素の数字は、読むと・保存すると・撮ると変わる

画像認識と物体検出を学び直す Log#1 | 9つの層と、評価指標を先に学ぶ理由

mechArm 270 Pi 受け渡し動作の成立を探る Log#7 | 手の高さを測る前に、手が写るかを1枚撮った

機械として合理的で、かつ柔らかい ― ロボットの動きの柔らかさをどの層で作るかの整理

mechArm 270 Pi 受け渡し動作の成立を探る Log#6 | 届いたUSBカメラを最小手順で確かめ、番号ではなく固有名で同定する

mechArm 270 Pi 受け渡し動作の成立を探る Log#5 | AI任せで全部作ってから実機に出したら、動きは前と変わらなかった

mechArm 270 Pi 受け渡し動作の成立を探る Log#4 | E-4からE-6まで。台帳・撮影・53件のテストで制御コードを閉じる

産業用ロボットでも、ヒューマノイドでもないロボットの話 ― 「役に立つ=作業する」以外のロボットを想像できるか

ヒューマノイドを追わない人たち ― 用途を固定して勝つという戦い方

自動運転の高精度地図は、どこまで情報を減らせるか ― 作り込む派と持たない派の争点は、ゼロにできるか

mechArm 270 Pi 受け渡し動作の成立を探る Log#3 | 人に手渡す姿勢の決め方と、検証コードが検証になっていなかった話

mechArm 270 Pi 受け渡し動作の成立を探る Log#2 | アームが差し出し、人が受け取る。設計が4回の外部レビューで固まるまで

mechArm 270 Pi 動的追従の限界を探る Log#56 | Pick & Place の全過程を映像+関節ログで残す。学習データ収集への第一歩

62万円のロボットアームが町工場に入らない理由 ― 3Dプリンターとの決定的な差と、Physical Intelligence が認めた限界

mechArm 270 Pi 受け渡し動作の成立を探る Log#1 | 今まではピック&プレースの成功判定は座標にあったが、次の判定基準は人の中にある

mechArm 270 Pi を ROS2 + MoveIt に載せる Log#1 | 独自スクリプトから業界標準へ

mechArm 270 Pi 動的追従の限界を探る Log#55 | Pick & Place 実行の常駐化と中断時の自動退避。モックで固めて、実機で分かったこと

MicroFactory と大規模事前学習 ― 賢さをモデルに積むか、環境を作り込むか

mechArm 270 Pi 動的追従の限界を探る Log#54 | 67,228点スキャンしても動かなかった。真犯人は lookup の3枚フィルタだった

mechArm 270 Pi 動的追従の限界を探る Log#53 | テンプレートマッチングが「白箱の中心」をずっと角で測っていた

mechArm 270 Pi 動的追従の限界を探る Log#52 | pick&place観測画面の見直し。参照と姿勢選択を可視化する

MicroFactory の入力設計 ― 精度はモデルではなく、人間とロボットの変換比で作られていた

フィジカルAI研究室を作る Log#1 | 自宅にゼロから、誰でも再現できる形で

MicroFactory を分解する ― ロボットを専用ワークステーションに閉じ込めて環境を固定する設計

mechArm 270 Pi 動的追従の限界を探る Log#51 | 掴めなくなったアームと、原因を七回取り違えた記録。A_PICKが真上に来ないという一点

mechArm 270 Pi 動的追従の限界を探る Log#50 | PLACE が送信前ガードで止まる。FKテーブルの穴を埋めて実機で置ききる

mechArm 270 Pi 動的追従の限界を探る Log#49 | 箱に当たる原因を三度取り違えた。当たりを検知して姿勢を上げるループ

mechArm 270 Pi 動的追従の限界を探る Log#48 | 動的追従 再構想設計書 — 非同期 dual-system

mechArm 270 Pi 動的追従の限界を探る Log#47 | 仮説が三度データに殺された日。PLACEサーボが一度も動いていなかった理由

mechArm 270 Pi 動的追従の限界を探る Log#47 | アーム学習の記憶を人の目に渡すためのダッシュボードを制作

ハコブくん 病院オペレーションのデジタルツイン Log#2 | ただのダッシュボードではなく、意思決定の補正ループを設計する

mechArm 270 Pi 動的追従の限界を探る Log#46 | ロボットアームに付けた安全装置が、正しい動きまで止めた理由

ハコブくん 病院オペレーションのデジタルツイン Log#1 | まずはシステム全体設計から始める

mechArm 270 Pi 動的追従の限界を探る Log#45 |  mechArm の横カメラを開け、PLACE 補正記憶を入れる。だが j4 が pick 到達を止めた

mechArm 270 Pi 動的追従の限界を探る Log#44 | FKテーブルの穴を測って、埋めて、1本化する

欲しいロボットを60個考えて全部捨てた | アイデアはロボットからではなく苦痛から探す

mechArm 270 Pi 動的追従の限界を探る Log#43 | PLACEの位置は合った。だがアームの手首が捻れ、姿勢が深すぎた

Reachy Mini が映す Motion UX | 身体を持ったAIは「間」で試される

mechArm 270 Pi 動的追従の限界を探る Log#42 | グリッパーの握り方を位置から押し込みに変えたら、ブロックが落ちなくなった

Raspberry Piを起点に、ロボットの脳と筋肉の分け方、Pi Zero、mechArmの実時間制御の正体、停電や電波断でも破綻しない縮退設計までを考察する

mechArm 270 Pi 動的追従の限界を探る Log#41 | ブロックを掴んでいるのに落とす。原因を測定で剥がしていく

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#09 | 実機を動かす前に data_manifest_rules.md を新設した。保持を測る受け皿を先に作る

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#08 | 補正がZ方向に効かない、その原因はデジタルツインの姿勢の使い方にあった

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#07 | 実機の前に、データフローをコードで確定する

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#06 | pose_idで、姿勢と実機結果をつなぐ

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#05 | PLACEの姿勢面を、点から半周へ広げる

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#04 | Unity で作る FK テーブルを、マット全面・左右対称まで広げる

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#03 | 現行PICKはFKテーブルを読んでいなかった

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#02 | 「データが足りない」を疑って、腕の到達データを数えてみた

mechArm 270 Pi 実機データを土台にデジタルツインを作る Log#01 | 綺麗に動くデジタルツインには無い「ズレ」が、実機にはある

ロボットの骨格はコードで、判断はClaude Codeに | 搬送ロボットとアームで考える２つの可能性

mechArm 270 Pi 動的追従の限界を探る Log#40 | 安全装置を全部外して見えた、ロボットが動かなくなる本当の理由

ロボットアームのテレメトリダッシュボードを作る Log#5 | 比較用プロトタイプを本番に載せ替え、実データで見えた表示の穴をふさぐ

mechArm 270 Pi 動的追従の限界を探る Log#39 | 完走したが、掴めていなかった。空欄だった掴み判定をCSVに残す

全天候ロボットと、まだ書かれていないナンバープレート ― 人がひと目で「誰の責任か」を読む設計は誰の仕事か

mechArm 270 Pi 動的追従の限界を探る Log#38 | ドラッグティーチングで取ったZ別固定姿勢を、カメラが自動選択してPick&Place

ロボットアームのテレメトリダッシュボードを作る Log#4 | 青シールで測る爪先とブロックのズレ。掴めても15mm離れていた

ロボットアームのテレメトリダッシュボードを作る Log#3 | 待機表示・全stage履歴・置けたかの in_box 判定を、テレメトリ画面に揃える

ロボットアームのテレメトリダッシュボードを作る Log#2 | VLM の判定理由と、赤ブロック・白箱の座標を画面と台帳に残す

ロボットアームのテレメトリダッシュボードを作る Log#1 | ターミナルに流れて消えていた状態を、止めずに観る

mechArm 270 Pi 動的追従の限界を探る Log#37 | j4 は壊れていなかった。壁の正体と通しの立て直し

mechArm 270 Pi 動的追従の限界を探る Log#36 | Pick&Place が止まる原因を測る。手首 j4 は浅い側に戻れなかった

「最後の数メートル」を誰が引き受けるか ― 自律飛行の着陸問題と、体験が成立する瞬間の設計

ロボットの目は、鏡像も「ある」と見る ― SAM 3で器具を切り出して気づいたこと。

mechArm 270 Pi 動的追従の限界を探る Log#35 | place が箱に当たる。姿勢を教え直して対応表を取り直す

SO-101 失敗から学ぶアームを作る Log#2 | 2TBの外付けSSDを、学習データの定位置にする

フィジカルAIの社会実装を止めるのは、デモではなく構造的な課題だ ― 36課題を地図にした

mechArm 270 Pi 動的追従の限界を探る Log#34 | 置く姿勢は、ドラッグティーチングで教えた軌道の中にあった

mechArm 270 Pi 動的追従の限界を探る Log#33 | 沈黙していたのはアームではなく、コマンドの中の1°だった

mechArm 270 Pi 動的追従シリーズ Log#32 | j0を振って実測する。工程姿勢の到達範囲をカメラで地図にした日

運ぶロボットと、掴む双腕アーム | 医療現場で、受け渡しは責任の受け渡しになる

mechArm 270 Pi 動的追従シリーズ Log#31 | 動く前例を離れたら、8回かかった。単発の send_angles が無視された実機テストの記録

mechArm 270 Pi 動的追従シリーズ Log#30 | 手で教えた軌道を実機で忠実再生し、上カメラで取った対象物位置を紐づける。位置入りサンプルの最初の一本まで

mechArm 270 Pi 動的追従シリーズ Log#29 | 手でアームを動かして教え、再生する。版差と可動域を実測で越え、軌道に「意味」を与える設計まで

SO-101 失敗から学ぶアームを作る Log#1 | 精度を上げることと、失敗から学ぶことは違う ― 単腕から双腕へ、ハードを選び直す

mechArm 270 Pi 動的追従の限界を探る Log#28 | 「できた」が場所を変えると崩れる。

正しい動きと、いい動き | Motion UX の二層構造

mechArm 270 Pi 動的追従の限界を探る Log#27 | 現実の行き詰まりを、デジタルツイン学習で埋める

世界はVLA、こちらは計画と評価 | ロボットを動かすVLMの、二つの使い方

mechArm 270 Pi 動的追従の限界を探る Log#26 | 「完璧に届くまで待つ」をやめた ― だいたい合ったら離して、入った/入らないを人が見て決める

巨大ラボπはロボットの「動き方」をデータとして使う。こちらは、その動き方をMotion UXとして設計する

AIで「作る速さ」が横並びになった世界で、むき出しになるもの | プロダクトマネージャー不要論と、最後に残る「捨てる判断」

mechArm 270 Pi 動的追従の限界を探る Log#25 | 降下は通った。だが個人ロボティクスは本題より「カメラが何番か」で時間が溶ける

mechArm 270 Pi 動的追従の限界を探る Log#24 | 「同じ接続が原因」という見立てが外れた ― 動かない理由を測って2つに分け、APPROACH が実機で通るまで

mechArm 270 Pi 動的追従の限界を探る Log#23 | アームを白箱の上空へ動かす実機テストと、動かない原因の切り分け

コードが消えても、設計は残る | ニューラルネットワークがロボットを動かす40年と、その先

mechArm 270 Pi 動的追従の限界を探る Log#22 | 検証を積み上げる PLACE 動作の足場を組み直した記録

動きの滑らかさは安心ではない | ロボットの動きと不気味の谷

mechArm 270 Pi 動的追従の限界を探る Log#21 | place_test.py を 6 つの単体スクリプトに解体した記録

mechArm 270 Pi 動的追従の限界を探る Log#20 | アームが動かない 4 回の修正と4 回の失敗

mechArm 270 Pi 動的追従の限界を探る Log#19 | PLACE 動作の入口 設計と現場の往復で見えた構造的な詰まり

mechArm 270 Pi 動的追従の限界を探る Log#18 | mechArm 把持初成立。視覚サーボだけでブロックを掴むまでの 21 ループ

Motion UX とは何か | ロボットの動きを体験として設計する

Pixelsの起源が二つに増える | ブロック認識とマット撤廃が同じ問いに収束した話

mechArm 270 Pi、まだやれることが結構ある

mechArm 270 Pi 動的追従の限界を探る Log#17 | 視覚サーボ Y 補正の最短解。2関節を比べて j4 単独に落ち着いた

mechArm 270 Pi 動的追従の限界を探る Log#16 | 何がいつ動いているか。ロボット制御パイプラインの可視化

 mechArm 270 Pi 動的追従の限界を探る Log#15 | DESCEND という段階を捨てる

Beyond Dynamic Tracking | Dual-Arm Collaboration and the Coffee Demo

mechArm 270 Pi 動的追従の、その先を考えた | 双腕協働とコーヒーデモへの構想

mechArm 270 Pi 動的追従の限界を探る Log#14 | 関節制御の試行錯誤と、外部AIレビューが見つけた致命的バグ

mechArm 270 Pi 動的追従の限界を探る Log#13 | 降りてないアームを 横カメラに監視させる

There's No Such Thing as a Free Lunch — On Dependency Design in the Age of AI Agents

タダより高いものはない | AIエージェント時代の依存設計を考える

mechArm 270 Pi 動的追従の限界を探る Log#12 | なぜアームが動かないのか カメラとdaemonの干渉を追った

mechArm 270 Pi 動的追従の限界を探る Log#11 | 横カメラを統合する 検出パイプラインを上向きと前向きに分割した

The Day I Read My Own Articles with Three AIs — and Redesigned How I Write

自分の記事を3つのAIで読み比べた日、コンテンツ生産の構造が変わった

Robotics UX Designer | A Profession That Exists in the US, Not Yet in Japan

Robotics UXデザイナーという職業 | 米国に既にある、日本にはまだない仕事

記事をビジュアルウィジェットで作り直す日 | STUDIOとGitHub Pagesの二層公開システムを建てた

mechArm 270 Pi 動的追従の限界を探る Log#10 | 視点を増やす日 設計判断とiPhone 2台体制の物理構築

mechArm 270 Pi 動的追従の限界を探る Log#9 | 視差と平行スライド 横カメラが必要になった瞬間

mechArm 270 Pi 動的追従の限界を探る Log#8 | DESCEND後に見えた次の壁 把持姿勢への二段追従という問い

mechArm 270 Pi 動的追従の限界を探る Log#7 | 動きの質が変わった日 Z符号の実測とPi常駐デーモン化

mechArm 270 Pi 動的追従の限界を探る Log#6 | SSHオーバーヘッドを40倍速化して通信律速の壁を越える

Engineers Build It. Designers Define It. A Category Strategy for Motion UX / Robotics UX.

エンジニアが作り、デザイナーが定義する。Motion UX / Robotics UX カテゴリ戦略

mechArm 270 Pi 動的追従の限界を探る Log#5 | Z方向へのリーチ制御とSSHオーバーヘッドという壁

mechArm 270 Pi 動的追従の限界を探る Log#4 | 動的追従の本体が回り始めた日 j0視覚サーボから2D収束判定へ

mechArm 270 Pi 動的追従の限界を探る Log#3 | TIP検出ノイズの正体を特定して初めて赤ブロックを掴んだ

mechArm 270 Pi 動的追従の限界を探る Log#2 | 視覚サーボのループ周期を設計するために、アームの物理応答速度を測った

mechArm 270 Pi 動的追従の限界を探る Log#1 | 実測 ソフトとハードの限界はどこにあるか

The Three-Phase Model of Motion UX

Motion UX 三相モデル

mechArmの静的把持は解けた。動的追従の限界を、次は攻める

dynamic homography一本化と、5 trial が示した補正の効きムラ

Unity FKに頼らず、カメラで掴む方針へ転換した

Unity FKスキャンは実機と一致しない。実測で確定した

mechArm 270-Pi でのPICK→PLACE通しシーケンス成立、と「ログを信用するな」の発見

届かないPICKポーズを諦めて、CSVから新しいangles候補を再生成した

Why Physical AI Won't Take Off in Japan — And It's Not About Technology

日本でフィジカルAIが本格普及しない本当の理由

公式スペックを信じて実機で検証したら、mechArm 270-Piの可動域は「姿勢の組み合わせ」で決まることがわかった

4回投げて、4回ともj1=90度で止まったロボットアームの話

ハコブくんの世界に住む人々を設計する

97mmの乖離は、fk_scan_motion_based.csv のコピーし忘れだった話

Unity のグリッパーの爪先を TipBrepReader で測れる目を持って、誤差の正体が見えた

PICK実機動作で3つの問題を分解し、青シール計測で19mm誤差を実測した | mechArm 270 × iPhone × Unity FKスキャン

Pixels to Motorsをメソドロジー化する

深度カメラはまだ買わない｜1時間の対話でNVIDIA戦略にたどり着いた話

白箱検出、3方式の試行。OpenCV HSV失敗からテンプレートマッチング0.994まで

ロボットアームの座標系、ズレを補正せず可視化する。ホモグラフィ検証からマット射影ツールへ

OpenCV Convex Hullで、マット四隅検出が0/10から10/10になった。pixel→mmホモグラフィ変換基盤の構築

補正では解決不能と確定した。固定オフセットが効かない理由と、根本修正への方針転換

ロボティクスの正解のない現場で生きる

マットが動く、iPhoneカメラがブレる、mechArmも触る。ズレる前提でUnity座標系を作り直す

グリッパーにカメラを足す。hand-eye構成の設計を物理から考え直した

FKScanner_PlusX では足りなかった。「Yもだよ、Zもだよ」から始まった命名再設計

213,312点が、実は手首の位置だった話。座標系を全部作り直した日

213,312点のデータより、人間の目1回。AIが3回スキャンを回しても気づけなかったこと

Claude Designを触った日に、フィジカルAIのセキュリティを考えた

「これが箱だよ」と教える 。テンプレートマッチングと自動学習ループ

動かしてみて初めて見えた4つの罠 。lookup方式の実機初稼働で踏んだ落とし穴の連鎖

平面型仕分けロボットHyperSortから見えた、環境設計とフィジカルAIの役割分担。Amazon Vulcan・Moxiとの対比

8点のモーションデータから81点の補間軌跡を生成し、20体のデジタルツインがウェーブ再生した

CCD IKを捨てて、確認済み姿勢からFKで空間を埋めた

UnityのFKをコードで再現しようとして、Unityが既にやっていることに気づいた

バイブコーディングのセキュリティリスクが、他人事ではなかった

考察記事のサムネイルを統一し、SEOタイトルを見直した

send_coords()のIKが信頼できない。だからデジタルツインシミュレーションが必要だ

大阪市の自動運転タクシーが示した：技術は完成する。でも社会は動かない

Unity × ROS2で座標変換の設計矛盾を根本から直した｜mechArm 270 R2R2R

TeslaのEnd-to-Endニューラルネットから学ぶ｜デモとデータを同時に生む設計

OpenCVカメラ座標とUnity World座標の構造的矛盾を発見した｜デジタルツイン検証

英語版4コマアーカイブページを公開した

AGIBOTが100万エピソードでやることを、自分は10エピソードから始める

iPhoneカメラをロボットの目にした｜homography.npyでmechArm 270と接続

GA4が教えてくれた。海外の人がアクセスしている

UnityシミュレーションでmechArm 270がブロックを掴んで箱に入れた

Gitのことを、わかってるようでわかってなかった

ロボティクスUXがゲームUIから借りるべきはコントローラーではなく思想｜HRI設計論

mechArm 270のアダプティブグリッパーをUnityデジタルツインに組み込んだ

Unityと実機mechArm 270の動作時間が一致した。シミュレーション49秒、実機49秒。

mechArm 270のリアル動作がUnityシミュレーションで再現された｜R2R2Rループ検証

USB-C Ethernetアダプタ1本でmechArm 270が自律動作した日｜Pythonスクリプト制御

R2R2Rのデータ収集設計を疑った｜mechArm 270 × Unityのフェーズ2開始前に

Pythonループが回った。mechArm 270 × OpenCV × Unity R2R2Rパイプライン初成功

Claude Codeのマルチエージェント設計がSim-to-Realループと同じ問いを解いていた

1gの壁。mechArm 270が「言葉を持たない」とはどういうことか｜HRIデザイン考察

Generalist AI GEN-0を解剖する。シミュレーション×実世界データの戦い

ループを証明するとはどういうことか。R2R2Rの設計を問い直した

mechArm 270 × Unity R2R2Rループが閉じた瞬間｜PickAndPlaceシミュレーション完成

実機の全関節が、Pythonで動いた

mechArm 270 Pi実機セットアップ。有線キーボード・マウスが必要だった理由

Build in Public × AI時代。AIがコンテンツを読む時代にDAYログを書き続ける理由

mechArm 270 Pi実機初動確認｜MyCobot Python SDKとPower on over手順

ロボット産業はなぜまだ「速さ・精度・重量」を競うのか。産業ロボットの設計思想を問う

GoogleのRT-2とFigureが証明した。良い動きはデータ量で決まる

ロボットアームにキャラクターを与えるとはどういうことか。ツカムくん誕生まで

ツカムくん誕生。ロボットアームのキャラクター設計と、500gの壁

人間の動作に隠された秘密と、精度を超えるMotion UX

コーヒーカップが重くて持てなかった話。mechArmのペイロード上限は250g、コーヒーカップは251gだった

mechArm 270Pi 開封の儀 - ACアダプタが入っていない…

スワイプとピンチを定義したのはAppleだった

ハコブくんの表情をチャットUIのステートとして実装した日。Dify × Studio × JavaScriptでHRI表情設計

Web/UIデザイナーがXへの発信とDAYログを続けて気づいたこと。Build in Publicが知性になる理由

Boston Dynamicsが示した「身体で考える」ロボットと、問いの本質

UnityでmechArmが2体独立動作した｜マルチロボットHRI設計の検証

フィジカルAI市場の設計者不足。関心はあるのに実装できる人がいない理由を考察する

YouTubeチャンネル、SNSインフラを一日で構築した、そして何度かつまずいた

Clineのコードベース管理。CLAUDE.mdとGit運用でAIエージェントを制御する

ハコブくんがAIエージェントになった

mechArm 270 Pi購入決断の夜。Switch Scienceで選んだ理由と比較検討の全記録

ロボットアーム（mechArm 270）購入前に事業仮説を立て直した｜Pixels to Motorsの設計転換

UnityシミュレーションフェーズからmechArm 270実機フェーズへ｜R2R2Rの転換点

mechArm 270 PickAndPlace 12回試行。PythonログとUnityデータで「全成功」と判明した

mechArm 270がUnityシミュレーションでコーヒーカップを掴んで台座に置いた｜PickAndPlace完成

mechArm 270のUnity ArticulationBodyをゼロから再設計した話｜関節制御パラメータの見直し

CCD IKを捨てた

PythonログとUnity可視化の乖離。mechArm 270の動作ログが「成功」でも目視がおかしかった理由

UnityのArticulationBodyが初めて物理的に正しく動いた｜mechArm 270関節制御の転換点

mechArm 270 PickAndPlaceのUnityステートマシンを解剖した日。REACH_CUP→GRASP→LIFT→PLACEの6ステート設計

mechArm 270のPickAndPlaceデータ収集を始めた｜Unity × Python記録設計

FixedJointで「掴む」が成立した

FixedJointで「掴む」を実装した

6軸CCD IKでアームが動いた

Prefab混入との戦い

Unityシミュレーションでコーヒーカップが初めて動いた｜mechArm 270 PickAndPlace検証

UnityとPythonで作るロボット設計工程はAIに置き換わる｜それでも手で作る意味

ロボットアームはどうやってカップを「掴む」のか？PickAndPlace実装の設計判断

coffeecup_3をUnityへ。スキャンモデルに命を吹き込む

iPhoneで撮った3Dスキャン（coffeecup）の精度問題とUnityへの取り込み検証

AIが壊して、AIが直した。Unityデータ消失から復元までの全記録

3Dpressoで動画から3Dモデルを生成する 

iPhoneで小鉢をスキャン。ロボットアームが押して倒すまでの全記録

UnityでmechArm 10体をアルゴリズムで個体差設計する｜マルチロボットシミュレーション

Studioを使わずWebサイトを公開する｜運用コスト極限カット × 表現力最大化

Claude×ChatGPT×Geminiで実現するLP制作ワークフロー

Clineのコストパフォーマンスを最大化について

mechArm 270 Unity ArticulationBody並列実装の再設計｜動作最適化の全記録

デジタルツイン学習-R2R2R バックアップ構造の見直し

Gemini-Human-Cline 三位一体による自律ロボット開発フレームワーク

Unityで10台のmechArmを5×2配列で同時制御する｜マルチロボットシミュレーション実験

3DGS（3D Gaussian Splatting）を用いたのリアルな再現のための準備

デジタルツイン学習-R2R2R デモ動画撮影用ミッション

Clineと挑むデジタルツイン構築｜Unity 6のデバックとmechArm 270 M5召喚の10時間全記録

AIリードエンジニア Cline と挑む、1時間で構築する一人ロボティクス・スタートアップの基盤

R2R2R: 次世代ロボティクスUXデザインの構築

Clineを「AIエンジニア」として雇用する。デザイナーがClaude × Clineでチームを作る最初の30分

デジタルツイン学習シミュレーション-R2R2R（Real to Render to Real）についての考察

ハコブくんと看護師の「距離感」をUnityで実装する｜病院廊下のHRI設計

ハコブくんの自律走行がUnity病院シーンにもたらす動的ノイズ｜HRI設計の検証

UnityでUV-C光を可視化する｜ハコブくん病院フロアのマテリアル管理とシェーダー設計

デジタルツインで育つ知能 - ハコブくんの自律実装プロジェクトはじめます

ハコブくんと看護師が通路でお見合い状態になるのを防ぐための設定

ハコブくんNavMeshと周回路による自律走行の実装プロセス

看護師の接近に呼応するハコブくん発光ロジックの構築

気配りを可視化する｜ハコブくんの発光による意図の伝達

動くワイヤーフレーム｜壁を透過させ、Unity6で実現する没入感

GeminiでGemini活用レベルを査定する。2026年1月時点の生成AIリテラシー自己評価｜Master（上位3.2%）

HRIデザインにおける物理空間の「振る舞い」設計｜ハコブくんのUnityシミュレーション考察

Unityで構築する20の動くワイヤーフレーム規格

フィジカルAI時代のデザイン思想。ロボティクス領域でデザインが利益率を決定する理由

UV-C農業ロボットとロボティクスが変える「製造業としての農業」｜フィジカルAI農業の現在地

FigJamで描くロボットの意思｜物理空間を制御するフロー図の構築

FigJam × ハコブくん設計。なんとなくのデザインではなく仕様としてのフロー図作成

Unityで看護師カプセルエージェントの自律移動と障害物回避テスト。NurseWander.cs × Raycastの実装記録

Unity UI Canvas連携｜センサー検知と同期した警告パネルの動的制御プロセス

ハコブくん、自律パトロールへ。自動往復走行の実装

Unity × ROS 2 実装：Raycastを用いた全方位衝突回避システムと、進行方向判定による自動ブレーキ解除ロジック

ハコブくん、ついに目と声を持つ。デジタルツインで実現するロボットの安全制御

ハコブくんをUnityとROS 2で繋ぐ通信開通全記録。Docker × ROS-TCP-EndpointからHakobuMove.csまで

ロボティクスPMの視点。ハコブくん × Unity × ROS 2のA/BテストでデザインをKPI・経営指標へ変換する

なぜ今、日本の「多湿」がPhysical AI・UV-C農業ロボットの最前線なのか

Atlasの思考をデスクトップに。Gemini × mechArmの実装プロセスガイド

Gemini × mechArm｜AIを物理的な動きへ変換する

「通れるはず」のストレスを可視化する。ハコブくんの動くワイヤーフレーム構築

薬剤搬送ロボットハコブくんのデジタルワイヤーフレームによる検証プロセス

マルチロボットHRIシステム開発全記録。Unity HUD × ROS 2 × Pythonで2台のmechArm 270を制御する

ハコブくんの「心」をUnityで可視化する｜HRIデザインの実装記録

mechArm 270をPrefab × Namespace設計で複数台管理する。Unityで実現する1対多フリート実装記録

HRIリサーチ報告書。ROS 2 × Unity × mechArm 270で検証した産業用AIの「信頼UI」設計

UnityとROS 2の「座標変換」からの解放｜Physical AI時代のデジタルツイン設計インパクト

デザインと論理の架け橋。デザイナーが知っておきたいPythonの正体

実験3-ROS 2とUnityを介した双方向リアルタイム・テレオペレーションの確立

Unityでデジタルツインに「解析の眼」を授ける｜mechArm 270データ可視化

mechArm 270デジタルツインを実用へ｜Unity × ROS 2で次に挑む3つの実験的ステップ

Unity × ROS 2連携完全ガイド-試行錯誤の全記録

mechArm 270 M5、Unityでの初駆動ドキュメント

mechArm 270 M5の関節駆動テスト計画書（手動テスト編）｜Unity ArticulationBody検証

召喚成功！mechArm 270 M5 視点操作マスター（デスクトップ・MacBook別）

仮想世界を構築。Unityにロボットを呼ぶための「翻訳機」を導入！

UnityとROS 2を繋ぐ架け橋。バーチャルmechArmを召喚

RViz2のScale・座標系の基準作りとR2R2R独自「テックログ」運用設計

「カメ」の正体と、ROS 2の「信号」をのぞき見＆3Dで可視化（RViz2）

ROS 2とUnityを繋いでロボットアーム（mechArm 270 M5）を動かすための事前連携ガイド

Figmaへのコレクション作成とバリアブル登録

Figmaのカラー管理。バリアブル（Variables）とスタイル（Styles）について解説します

4コマ漫画でバズる！？SNS拡散投稿術【X & Instagram編】

デザインとエンジニアリングの境界線へ。AIエディタCursorとFigmaを連携させて見えた、新しい効率化の可能性

Figmaを使ったUIデザインのブラッシュアップ。UIの効率化プロセス

ロボットが当たり前に存在する社会はどうなるのか。デザイナー視点のHRI未来論

GeminiとFigmaで4コママンガ量産体制構築｜X・Instagram投稿を回し続けるための管理設計

ハコブくん管理者向けダッシュボードのUIデザイン｜FigmaによるHRI管理画面設計

薬剤搬送ロボット（ハコブくんモデル）12台5稼働の運用設計。SaaSサブスクで実現する止まらない医療搬送

GeminiとFigmaで創るロボットUI全仕事。ハコブくんのUIデザイン全工程

共感を呼ぶストーリーテリング。GeminiとFigmaで作る「4コママンガ」

GeminiとFigmaで作る「認証画面」。ハコブくんのセキュリティUIデザイン工程

GeminiのアイデアをFigmaで仕上げる｜ハコブくんの表情デザイン工程

ハコブくんの表情デザイン。愛着だけでなく「信頼」を生むHRIデザインの実践

生成AIより確実。「Layermate」で加速するUIデザイン構築

ハコブくん薬剤搬送システムのUIスコープ定義。Figmaで作る画面リストと情報設計

ハコブくん薬剤搬送ロボットのUI設計と情報アーキテクチャ｜Figmaによる病院現場HRI設計

WebデザイナーがHRI設計へ。ロボット保守UIのための情報設計術

「愛されるロボット」はUIデザイナーが作る。HRI（Human-Robot Interaction）デザインの最前線