From silent UART to a working NanoPi R2S
An evidence-led NanoPi R2S investigation: isolate an unreliable UART path, identify a wrong Rockchip image, boot Alpine Linux, and map the RK3328 SD-card chain.
Mayphus
I build practical systems across mechanical engineering, software, electronics, and AI.
A chronological record of what I am learning, making, and finding useful.
Notes
Twelve volts, one wrong pin
I tried to bring an old HiSilicon camera board back to life. The plan was cautious at first: identify the H1102NL Ethernet magnetics, verify the USB-TTL adapter with a loopback, keep its VCC disconnected, and listen for boot output. The mistake was the unverified eight-pin harness. I put 12 volts onto what I thought was the input pin. The board answered with a pop and was finished. The TTL adapter survived a second exact loopback test. The useful lesson is embarrassingly physical: a connector that fits is not a pinout, wire color is not evidence, and voltage should not be applied until ground, input protection, and the power path have been traced with continuity. Sometimes the artifact is the failed board and the rule it leaves behind.
OpenLens: a local-first camera that admits what it does not know
Building a portable multilingual learning companion, testing offline vision on Android, and keeping model uncertainty visible.
The real value of an AI agent
An IDE, tab completion, and autocomplete help an engineer do known work faster. An AI agent is a much larger step: it can carry an intention across tools and through many known, well-specified technical problems—inspect the real system, choose a method, implement it, diagnose failures, run tests, and preserve the evidence. TinyStories on my RP2040 board and the bring-up of my SO-101 robot made this concrete. I described the outcome I wanted and what I could physically observe; the agent handled most of the technical path. I still operated and calibrated the hardware, protected the physical safety boundary, and replaced the broken motor. The value is not making the human disappear. It is reaching a usable system sooner, so our attention can move from repeated technical friction to the different, useful, and creative question: what should we make the robot do now?
A TinyStories model on my RP2040 board
I trained a tiny Transformer, quantized it, and ran its C inference runtime entirely on my custom Raspberry Pi Pico display board. I did not solve the individual technical issues myself. I described what I wanted and what I could see; the AI agent handled the technical path, while I supplied the physical observations needed to verify the screen, button, and board. The final 98,944-parameter model fit inside the RP2040 memory budget and generated a punctuation-complete micro-story on the physical board in 10.394 seconds.
The old depth camera was not dead
I pulled an old LeTV LeTMC-520 RGB-D camera out of storage and initially thought it had failed: Linux repeatedly rejected it during USB setup. Windows showed that the ordinary RGB camera still worked, but the depth interface had no driver. The useful clue was the connection itself. On a rear USB 2.0 port, Linux cleanly enumerated the camera's internal hub, Orbbec Astra Pro depth sensor, and UVC color camera. With one small video utility, I streamed 720p MJPEG over SSH to my Mac without installing a depth driver or running a permanent server. The depth stream can wait for a separate OpenNI test on a Raspberry Pi. Old hardware is easy to misdiagnose when physical health, USB compatibility, and software support are treated as the same question.
A week of verified loops
This week I kept returning to the same way of working: build the smallest real loop, verify it, and widen the boundary only when the evidence holds. The main thread was robotics. I moved the SO-101 simulator through camera-guided pick and place, repeatable safety checks, staged learned policies, and the beginnings of an object-packing architecture. Around it, I shipped a small agent-operated store, booted a minimal Rust/RISC-V kernel, extended an AI gateway with verified image input, and fixed focused dependency issues. The projects were different, but the useful habit was the same: turn an idea into an observable system before making it bigger.
AI-centered robot stack
I do not think ROS 2 should be the center of a modern robot. The center should be an AI agent that understands the goal and works through explicit capabilities such as navigate, inspect, and grasp. ROS 2, vendor SDKs, and generated adapters can remain replaceable integration layers. Learned skills and whole-body control can execute below them, while hard limits, watchdogs, emergency stop, and motor loops stay outside the agent. AI can optimize the software around the robot; it should not be allowed to rewrite the safety boundary while the robot is running.
Sugar from a soldier
Testing a grandmother’s memory of Japanese soldiers giving sweets to children in wartime Liu Yuan against Japanese and international records.
Website as working memory
I do not want my website to be a separate job. It should become a durable public memory that participates in my AI work: when an idea or investigation becomes useful, I can ask the assistant to turn it into a concise note, keep private details out, and create a review before anything goes public. The website is not the work itself. It records the proof and lessons from real work.