Мода на ИИ-помощников, кажется, достигла пика. Даже далёкие от темы люди интересуются, что такое OpenClaw и как его установить. Более продвинутые пользователи покупают Mac Mini M4 — 16 Гб единой памяти и нейропроцессорные ядра позволяют запускать локальные модели, а устройство при этом тихое и энергоэффективное.

Ограничения OpenClaw

У OpenClaw есть не только преимущества, но и серьёзные недостатки. Речь не о безопасности, а о системных требованиях. Минимум — 2 Гб ОЗУ, рекомендуется 4 Гб. Плюс нужен как минимум 4-поточный CPU, иначе возможны проблемы с параллельными задачами.

На сцену выходят китайские разработчики из Sipeed — те самые, кто создал миниатюрный NanoKVM. «Подержите наше Tsingtao», — словно заявили они, представив PicoClaw: ИИ-ассистент, которому хватает 10 Мб ОЗУ и одноядерного CPU с частотой 600 МГц. Сегодня — тест этого чуда китайской инженерии на Arduino Uno Q.

Что такое PicoClaw

PicoClaw — это не альтернатива OpenClaw. Он не справляется со сложными сценариями, но идеален для простых задач. Может работать с локальными моделями, с моделями на удалённом ПК с GPU или напрямую с облачными сервисами вроде ChatGPT и Claude.

Проект создан в рамках экосистемы Sipeed, специализирующейся на дешёвых платах на архитектуре RISC-V. Например, LicheeRV Nano построен на SoC SOPHGO SG2002: два ядра RISC-V C906 (1 ГГц и 700 МГц), всего 256 Мб ОЗУ.

Такие ограничения исключают тяжёлые среды вроде Node.js. Вместо этого PicoClaw почти полностью написан на Go. Это резко снижает потребление памяти. Любопытно, что 95% кода сгенерировано ИИ, а platform-specific части доработаны вручную.

Например, в Makefile есть патч для сборки под MIPS: Go по умолчанию не ставит флаг EF_MIPS_NAN2008, а ядро Ingenic X2600 требует его. Патч вручную меняет 4 байта в e_flags — чисто для совместимости.

Оптимизации в основном стандартные: build tags для исключения тяжёлых зависимостей, флаги линковщика без таблицы символов и DWARF. Это сократило размер бинарника почти на треть. Сборщик мусора работает в штатном режиме — без нестандартных настроек.

PicoClaw — не конкурент OpenClaw, а «киллер-фича»: ИИ-ассистент на плате за 10 долларов. Поддерживаемые архитектуры впечатляют: Windows, Linux, macOS, FreeBSD, NetBSD, Android. Возможна даже установка на Nintendo Wii с NetBSD — интересно? Пишите в комментариях.

Установка и запуск

Arduino Uno Q работает под Debian, поэтому установка стандартна. На момент написания актуальна версия 0.2.1. Скачиваем пакет с GitHub и устанавливаем через dpkg.

Выполняем базовую настройку — аналог openclaw onboard. Или сразу редактируем конфиг, указав используемые модели и каналы связи: Slack, Telegram, IRC — для любителей ретрокомпьютинга.

Я выбрал локальную модель qwen3-4b-thinking-2507 через LM Studio. Запускаю сервер на домашнем ПК и указываю модель в двух местах конфига PicoClaw. Затем запускаю сам ассистент.

Отображение статуса

Uno Q — не просто одноплатник. У него есть MPU и MCU STM32U585, а также встроенная LED-матрица на 104 светодиода. Разрешение маленькое (8×13), но идея — отображать статус PicoClaw через анимации.

Где брать статус

У PicoClaw нет полноценного API для внешнего мониторинга. Есть только:

• /health — жив/мертв;
• /ready — готов/не готов.

А мне нужно отображать: «думает», «принимает», «отправляет», «свободен». Таких состояний в PicoClaw нет. Форкнуть и добавить /status — сложно и долго.

Решение: читать stdout. Туда выводятся строки вроде Processing message from, LLM response, Routed message, Published outbound response. Перенаправляю stdout в файл и пишу простой HTTP-сервер, который отслеживает эти строки и выдаёт нужный статус.

Добавил сброс статуса через 4 секунды — иначе он «залипает».

Встроенная LED-матрица

Матрица: 8 строк × 13 столбцов. Управление — через библиотеку Arduino_LED_Matrix. Инициализация в скетче стандартна.

Создаю пять анимаций:

1. Thinking — «эффект матрицы» (пиксели бегут вниз);
2. Receiving — антенна со сходящимися волнами;
3. Sending — антенна с расходящимися волнами;
4. Ready — статичное изображение краба;
5. Clear — пустой экран.

Сначала пробовал шестерёнку для «думает» — на таком разрешении неразборчиво. «Матрица» смотрится лучше.

Анимации — это последовательность кадров. Для антенны использовал одни и те же кадры (ant0–ant5), но в разном порядке — экономия кода.

MPU и MCU: как передавать статус

Связь между MPU (Linux) и MCU (STM32U585) — через UART. MCU использует Serial1, Linux — /dev/ttyS0. Прямой полнодуплексный канал.

Поверх UART — RPC-протокол на основе MsgPack (бинарный аналог JSON). При компиляции скетчей подтягиваются библиотеки MsgPack, ArxContainer, ArxTypeTraits — для сериализации.

Самый сложный слой — arduino-router. Он работает на MPU как демон, держит /dev/ttyS0 открытым и выступает брокером между Python-кодом (на MPU) и скетчами (на MCU). Без него не было бы мультиплексирования: несколько Python-процессов не смогли бы делить UART.

Router также обеспечивает устойчивость к перезапускам контейнеров. Иначе каждый рестарт требовал бы повторного handshaking с MCU.

Плюс — независимость от языка. Хотите писать не на Python, а на другом ЯП? Реализуйте MsgPack-клиент к роутеру. MCU всё равно — он общается по RPC.

Контейнеры и сеть

App Lab запускает приложения в Docker-контейнерах. А PicoClaw и сервер статусов — на хосте. Проблема: при обновлении App Lab может измениться IP-адрес шлюза. Хардкодить — плохо.

Решение: скрипт автоопределения IP через /proc/net/route. Читаем маршрут по умолчанию, извлекаем шлюз, конвертируем из hex. Если ошибка — fallback на 172.17.0.1 (стандартный Docker bridge).

Теперь соединение устойчиво к смене адресов.

Сборка воедино

Финальный пайплайн:

• Запуск PicoClaw;
• Запуск сервера статусов;
• Перенаправление логов;
• Отправка статуса на MCU через роутер.

Создан скрипт start_picoclaw.sh с поддержкой запуска и остановки:

#!/bin/bash
stop_all() {
  echo "Останавливаем..."
  pkill -f "picoclaw gateway" 2>/dev/null
  pkill -f state_server.py 2>/dev/null
  pkill -f "tee /home/arduino/picoclaw.log" 2>/dev/null
  echo "Готово"
}
start_all() {
  picoclaw gateway 2>&1 | tee /home/arduino/picoclaw.log &
  python3 /home/arduino/state_server.py &
  echo "Всё запущено"
}
case "$1" in
  stop) stop_all ;;
  *) start_all ;;
esac

Добавил автозапуск через cron:

@reboot sleep 10 && /home/arduino/start_picoclaw.sh

Теперь после включения питания через 10 секунд запускаются PicoClaw и сервер статусов.

Заключение

Этот эксперимент показал, насколько эффективным может быть лёгкий ИИ-ассистент. PicoClaw — отличная альтернатива OpenClaw для простых задач. Пишу ему в Telegram, он обращается к локальной модели или в облако, выбирает решение и возвращает ответ.

Всё это работает быстро, бесшумно и с низким энергопотреблением. А LED-матрица позволяет с первого взгляда понять, занят ли помощник — можно ли задать вопрос или попросить выполнить действие, например, создать файл.

А вы пробовали PicoClaw? Делитесь впечатлениями в комментариях.

Мода на ИИ-помощников, кажется, достигла своего пика. Даже далекие от этой темы люди начинают интересоваться, что это за OpenClaw такой и как бы его установить. Более прошаренные скупают Mac Mini M4 просто потому, что 16 Гб объединенной памяти + нейропроцессорные ядра позволяют гонять локальные модели, а само по себе устройство тихое и с небольшим энергопотреблением.

Если присмотреться получше, у OpenClaw есть не только достоинства, но и ощутимые недостатки. Речь даже не о безопасности, а банально о системных требованиях. В частности, базовый минимум — 2 Гб ОЗУ, а рекомендованное значение — вообще 4 Гб. Плюс CPU нужен хотя бы 4-поточный, иначе возможны проблемы при работе с параллельными задачами.

Вот тут на сцене появляются наши китайские товарищи из Sipeed. Да-да, те самые, которые делают миниатюрный NanoKVM (о нем мырассказывалив конце 2025 года). «Подержите наше Tsingtao», — заявили они и выпустили PicoClaw — AI-ассистента, которому надо всего лишь 10 Мб ОЗУ и который работает на любом одноядерном CPU со скоростью 600 МГц. Сегодня мы глянем на это чудо китайской мысли внимательно и запустим его наArduino Uno Q.

• Что за зверь PicoClaw
• Установка и первый запуск
• Отображение статусаГде брать статусВстроенная LED-матрицаMPU и MCUКонтейнеры и сетьСобираем воедино
• Заключение

Что за зверь PicoClaw

PicoClaw это не OpenClaw, он не способен вытянуть сложные сценарии. При этом для простых задач он идеален и в паре с локальными моделями, и с запущенными где-нибудь на отдельном ПК c GPU (либо напрямую с сервисами вроде ChatGPT, Claude и т. п.).

PicoClaw стоит рассматривать сразу в контексте экосистемы. Sipeed сконцентрировала бизнес на продаже плат для разработки. Все они строятся вокруг RISC-V-архитектуры и достаточно слабых (но крайне дешевых) процессоров. Например, LicheeRV Nano сделан на SoC SOPHGO SG2002 — внутри пара ядер RISC-V C906, одно из которых работает на частоте 1 ГГц, а второе — на 700 МГц. ОЗУ тоже мало: всего 256 Мб.

Все это накладывает серьезное ограничение на софт. Тут уже не будет места для массивного рантайма вроде Node 24, который использует OpenClaw. Вместо этого «младший брат» почти целиком написан на Go. Именно это обстоятельство кардинально снижает потребление оперативной памяти. Любопытно то, что код проекта на 95% сгенерирован AI, некоторые platform-specific-штуки подкрутили вручную.

Например, в Makefile можно найти вот такое:

Go для MIPS собирает softfloat-бинарники и не ставит флаг EF_MIPS_NAN2008. Ядро Ingenic X2600 работает в NaN2008-only-режиме и отказывается грузить такой ELF, хотя FP-инструкций в бинаре нет вообще. Патч правит 4 байта по смещению 36 в e_flags — чисто косметика для ядра.

Отдельной экстремальной оптимизации тут нет — она досталась бонусом с выбором рантайма. Дополнительно в этом роль играет грамотный релиз-инжиниринг, вроде build tags для тяжелых зависимостей и флагов линковщика, отрубающих таблицу символов и DWARF. Экономия составила почти треть размера исполняемого файла.

Забавно, что сборщик мусора работает на дефолтных настройках — никаких нестандартных GC-политик. PicoClaw создавался скорее не как конкурент OpenClaw, а как киллер-фича: вы можете запустить собственного AI-ассистента на плате за 10 долларов. К слову, список поддерживаемых архитектур впечатляет. Помимо стандартной тройки Windows/Linux/macOS, тут есть FreeBSD, NetBSD и даже Android.

Кажется, мне стоит попробовать запустить его на Nintendo Wii. На Хабре мырассказывали, как установить туда современную NetBSD. Кстати, напишите в комментариях, интересно ли вам такое. А пока что расчехлю одноплатник Arduino Uno Q, который с недавнего времени обзавелся модным корпусом, напечатанным на 3D-принтере.

Установка и первый запуск

Uno Q функционирует под управлением операционной системы Debian, поэтому к нему применимы все те же самые инструкции, как и к любому другому компьютеру на Linux. На момент подготовки этой статьи актуальной была версия 0.2.1, поэтому скачиваем соответствующий пакет с GitHub:

Устанавливаем при помощи пакетного менеджера dpkg:

Теперь выполняем команду, которая базово конфигурирует AI-ассистента, аналог openclaw onboard:

Альтернативно можно с ходу заняться редактированием файла, который как раз и правит предыдущая команда, занести используемые нейросетевые модели и выбрать способы коммуникации, например Slack, Telegram или даже IRC (для тех, у кого специфические вкусы). Кстати, это неплохой вариант для любителей ретрокомпьютинга.

Я решил использовать локальную модель на своем домашнем ПК.qwen3-4b-thinking-2507можно поставить буквально в один клик изLM Studio, и она неплохо справляется. Важно при этом не забыть запустить локальный сервер, а в файле конфигурации PicoClaw указать модель в двух местах.

Теперь можно запустить приложение командой:

Отображение статуса

Работающий AI-ассистент — это прекрасно. Но тут мы вспоминаем, что, вообще-то, у нас не просто одноплатник, а Uno Q, у которого, помимо MPU, есть MCU STM32U585 — можно запускать скетчи для Arduino. Более того, в девайс встроена LED-матрица аж на 104 светодиода. Понятно, что этого очень мало: даже у первых тамагочи экранчик был поинтереснее (32 × 16).

Идея научить микроконтроллер выдавать анимации, отображающие работу PicoClaw, возникла спонтанно. Вот только оказалось, что подводных камней на этом пути довольно много. Декомпозиция — наше все, поэтому составил небольшой план и пошел по нему.

Где брать статус

Пожалуй, это был самый первый вопрос, на который предстояло ответить. Внимательно изучив логи и репозиторий проекта, пришел к неутешительному выводу: фактически у PicoClaw нет штатного API для внешнего наблюдения за его рабочим состоянием. Есть лишь пара эндпойнтов:

• /health— бинарный жив/мертв;
• /ready— готов / не готов.

Мне же хотелось отображать, когда ассистент думает, принимает/отправляет сообщения и когда он свободен. Увы, но этих четырех состояний у PicoClaw просто нет. Конечно, в теории можно было бы форкнуть, залезть в код и уже там сделать отдельный эндпойнт, например /status. Но это путь самурая: сложно и не факт, что получится быстро.

Мое внимание привлек лог в stdout. Дело в том, что именно туда ассистент пишет вполне читабельные фразы вида Processing message from, LLM response / Routed message и Published outbound response, которые как раз подходят для определения состояния. Оставалось лишь перенаправить stdout в файл, а дальше написать крошечный http-сервер, реализуя отсутствующий штатный эндпойнт:

Тут отмечу только один момент: статус порой «залипает», поэтому добавил сброс после 4 секунд (выяснил эмпирическим путем). Пришла пора разобраться, как сделать анимации.

Встроенная LED-матрица

При горизонтальной ориентации платы у нас получается 8 строк и 13 столбцов (формат: uint32_t[4], 104 бита, построчно слева-направо, сверху-вниз). Для работы с ней нужно включить библиотекуArduino_LED_Matrixв скетч и далее инициализировать ее примерно так:

Теперь пришла пора продумать сами иконки и анимации. Всего их будет пять:

1. Thinking— «матрица» (процедурные пиксели бегут вниз).
2. Receiving— антенна со сходящимися волнами.
3. Sending— антенна с расходящимися волнами.
4. Ready— статичное изображение краба.
5. Clear— пустая «матрица».

Сначала для статуса Thinking я пробовал сделать что-то вроде шестеренки, но при столь малом разрешении это выглядит вообще невнятно. Потом допилил «матрицу», и получилось довольно зрелищно.

Результат выглядит как-то так:

Любые анимации — просто отрисованные подобным образом кадры, отправляемые поочередно. Это, кстати, позволило сэкономить код для анимации антенны: сходящиеся и расходящиеся волны можно было реализовать последовательностью вывода кадров (ant0-5):

Теперь, когда с выводом статики и анимаций разобрались, пора понять, как нам извещать микроконтроллер о необходимости рисовать ту или иную анимацию.

Чтобы лучше понимать процесс, нужно немного заглянуть в многослойную архитектуру обмена данными между чипами на плате.

Слой 1.QRB2210иSTM32U585соединены друг с другом напрямую через самый обычный UART. Со стороны MCU это портSerial1, а со стороны Linux — символьное устройство вида/dev/ttyS0. По факту обычный прямой полнодуплексный канал.

Слой 2.Поверх сырых байтов UART живет RPC-протокол на базе MsgPack (бинарная альтернатива JSON). При компиляции скетчей вы часто будете видеть автоматически подтягиваемые библиотекиMsgPack,ArxContainerиArxTypeTraits— это вот как раз для сериализации RPC-запросов/ответов:

Слой 3.Самая мудреная и нетривиальная часть — маршрутизатор (arduino-router). Дело в том, что скетчи для Uno Q состоят из двух частей: кода на Python и кода скетча. Первый исполняется на MPU, а второй — на MCU. Прикол в том, что прямой связи между ними нет. Вместо этого на Linux-стороне крутится демон arduino-router, который все время держит открытым /dev/ttyS0 и читает/пишет в MCU. Это такой брокер сообщений, связывающий две части воедино и превращий запросы на локальный сокет в запросы к MCU по UART, и наоборот.

Слой 4.Непосредственно клиенты. Со стороны микроконтроллера — библиотекаArduino_RouterBridge, а со стороны Linux —arduino.app_utils, входящая в состав пакетаapp-bricks-py. Последний, в свою очередь, поставляется вместе с контейнеромApp Lab.

Зачем там целый роутер, спросите вы? UART таки один, а экземпляров кода на Python в архитектуре Uno Q может быть несколько. Так чтоarduino-routerиграет роль мультиплексора, позволяя каждому экземпляру спокойно делить UART без конфликтов. Это же дает сверхспособность переживать рестарты контейнеров, особенно с кодом на Python. Иначе каждый перезапуск приводил бы к необходимости повторного хендшейка с MCU.

Ну и совсем приятный бонус — отсутствие привязки к конкретному ЯП. Если вместо Python вы захотите написать код на чем-то другом — без проблем. Главное — реализовать MsgPack-клиент к роутеру. Скетчу на MCU все эти высокоуровневые штуки по барабану: он общается с любой сущностью, лишь бы последняя умела принимать RPC.

Контейнеры и сеть

Еще одна проблема, которую нужно будет решить, — связность. Дело в том, что App Lab деплоит приложения внутри Docker-контейнера, а мы поставили picoclaw и запустили сервер состояний непосредственно на Linux-хосте. Проблема в том, что между деплоями App Lab может менять имя и шлюз. Если захардкодить конкретный IP, то при любом обновлении образа самого App Lab адрес поменяется и придется лезть в код.

Воспользуемся тем, что внутри контейнера адрес шлюза по умолчанию из/proc/net/routeбудет IP-адресом хоста со стороны контейнера. Напишем небольшой скрипт автоопределения IP:

def detect_host_ip():

override = os.environ.get("PICOCLAW_HOST")

if override:

print("[net] PICOCLAW_HOST override: {}".format(override), flush=True)

return override

with open("/proc/net/route") as f:

for line in f.readlines()[1:]:

fields = line.strip().split()

# destination == 00000000 → default route

if len(fields) >= 3 and fields[1] == "00000000":

gw_hex = fields[2]

ip = ".".join(

str(int(gw_hex[i:i+2], 16))

for i in range(6, -1, -2)

print("[net] default gateway detected: {}".format(ip), flush=True)

except Exception as e:

print("[net][ERROR] detect_host_ip: {}: {}".format(

type(e).__name__, e), flush=True)

# Запасной вариант - дефолтный docker bridge

print("[net] fallback to 172.17.0.1", flush=True)

return "172.17.0.1"

HOST            = detect_host_ip()

HEALTH_URL      = "http://{}:18790/health".format(HOST)

STATE_URL       = "http://{}:18791/".format(HOST)

POLL_INTERVAL   = 0.5

SENDING_TIMEOUT = 3.0

Теперь не страшно, если App Lab поменяет адрес контейнера, — код всегда подскажет актуальный.

Собираем воедино

Когда все ключевые моменты ясны, пришла пора написать код и вспомогательный скрипт для запуска сервера состояния. Финальный пайплайн выглядит так:

Для ручного старта был создан простой скрипт (start_picoclaw.sh), который, помимо запуска, умеет еще и останавливать работу, если вызвать его с параметром stop:

#!/bin/bash

stop_all() {

echo "Останавливаем..."

pkill -f "picoclaw gateway" 2>/dev/null

pkill -f state_server.py2>/dev/null

pkill -f "tee /home/arduino/picoclaw.log" 2>/dev/null

echo "Готово"

start_all() {

picoclaw gateway 2>&1 | tee /home/arduino/picoclaw.log &

python3 /home/arduino/state_server.py&

echo "Всё запущено"

case "$1" in

stop)  stop_all ;;

*)     start_all ;;

Запуск скрипта при перезагрузке я просто запихнул в cron. Теперь достаточно подать питание, и спустя 10 секунд сначала поднимется сам PicoClaw, а затем и сервер состояний:

@reboot sleep 10 && /home/arduino/start_picoclaw.sh

Под спойлерами вы найдете полный код для App Lab. Всего три файла:

Заключение

Вот такое получилось интересное погружение в особенности AI-ассистента и платы Arduino Uno Q. Я очень доволен результатом — ведь теперь у меня появилась легковесная альтернатива OpenClaw для простых задач. Вы пишете своему PicoClaw в Telegram, а он стучится в локальную модель или облако, выбирает лучший путь решения и в конце выдает вам ответ тоже в мессенджер.

Особенно здорово, что вся эта логика работает быстро, а живет на бесшумной плате с низким энергопотреблением. Обычного взгляда на нее будет достаточно, чтобы понять, свободен ли помощник и может ли прямо сейчас ответить на вопрос или выполнить какое-либо действие, например, создать файл.

А вы уже пробовали PicoClaw? Ждем вас в комментариях.