OpenCat: the NyBoard quadruped framework behind Bittle and Nybble

What OpenCat solves, and which robot it actually targets

Writing a walking robot from scratch means writing the same layers every time: a servo abstraction, a gait scheduler, an IMU read loop, and a serial protocol so a host computer can send commands. OpenCat packages those layers so the person building a robot can work above them. The README states the framework "handles the hard parts, gait coordination, servo control, IMU integration, so you can focus on what you're actually building on top of it." The audience is stated just as plainly: K-12 classrooms, university research labs, maker spaces, and independent builders.

There is a catch that decides whether this repository is even relevant to you. The README opens by saying this repo "covers the legacy NyBoard platform" and points readers on current-generation hardware to OpenCatESP32. The original Bittle and Nybble mini robots, built on NyBoard and the ATmega328P, are described as discontinued but still fully supported by this codebase. So the framework is maintained for the hardware it was written for, not for the hardware Petoi sells today. If you bought a Bittle X or a Nybble Q, you are in the wrong repository, and the README says so in its first blockquote.

How the framework is laid out: firmware, skills, host tools

The repository layout is the clearest description of the architecture. OpenCat.ino is the Arduino entry point, the sketch that gets compiled and flashed to the board. src/ holds the framework itself: the C++ that drives servos, schedules gait frames and reads the IMU. SkillLibrary/ contains the behaviour definitions, the named postures and motions the robot can be told to perform. ModuleTests/ exists so individual modules can be exercised without running a full behaviour, which matters when a servo or sensor misbehaves and you need to isolate the fault.

The host side is split by language. serialMaster/ and pyUI/ are the serial-side tools, and OpenCatPythonAPI/ is the Python binding for talking to the board over the serial link. Resources/ carries the non-code assets. That split is the data flow: a host program sends a command down the serial line, the firmware in src/ interprets it, selects or modifies a skill from SkillLibrary/, and drives the servos while folding IMU readings back into the loop. Nothing in the layout suggests a ROS node or a network service in this repository; the README mentions ROS compatibility as community-documented for SLAM and navigation pipelines, not as something shipped here.

Getting the firmware onto a NyBoard robot

The README does not walk through a first flash, so the practical path is the one the repository layout implies: open OpenCat.ino in the Arduino IDE, select the board that matches your NyBoard hardware, and upload. The Arduino toolchain is the delivery mechanism; there is no separate installer in the top-level entries. Once the sketch is running, the serial link is what you talk to, and the Python API is the friendlier end of it.

A minimal session looks like this: install the Python client from the repository's OpenCatPythonAPI/ directory, open the serial port at the baud rate the firmware uses, and send a skill name. The exact baud rate and command strings are defined in the firmware and the API source, not in the README, so read those two files before writing your own sender.

cd OpenCatPythonAPI
pip install -r requirements.txt

After that, the loop you will actually run is: send a posture command, watch the robot settle, then send a gait command and watch it walk. If a leg moves the wrong way or not at all, ModuleTests/ is where to go next, because it lets you drive one module without the rest of the behaviour stack in the way. This is the part of the project that rewards reading source over reading documentation: the README tells you what the framework does, and the code tells you the command vocabulary.

Where OpenCat stops being the right tool

The largest limitation is stated by the project itself. This repository supports NyBoard hardware, and the robots built on it are discontinued. New buyers with a Bittle X or Nybble Q should be in OpenCatESP32 instead. That is not a maintenance problem, since the last push to this repository was on 2026-09-08; it is a hardware-scope boundary, and it means tutorials, pin maps and board definitions you find for current kits will not line up with this codebase.

A second constraint is the compute ceiling. The ATmega328P on NyBoard is a small 8-bit microcontroller. Anything that needs a camera pipeline, a neural network or a SLAM stack has to run on a Raspberry Pi or another host and send commands over serial. The README lists sim-to-real reinforcement learning and ROS-compatible navigation as things the platform supports, and those are host-side workloads, not firmware workloads. Treating the NyBoard as the place where perception runs will not work.

Finally, the documentation is thin in exactly the places a beginner needs it. The README is heavy on product context and light on the serial protocol, the baud rate, and the mapping from skill names to firmware behaviour. If you are not comfortable reading C++ headers to find the command set, budget time for that before you buy hardware.

OpenCat against a from-scratch gait stack

The realistic alternative is not another product; it is writing your own firmware on a hobby servo controller, or starting from a general robotics framework and building the quadruped layer yourself. The difference in approach is where the abstraction sits. A general framework gives you a message bus, a process model and tooling for distributed nodes, and leaves gait generation, servo calibration and IMU fusion to you. OpenCat gives you the opposite: a single Arduino sketch with a fixed gait library and a serial command interface, and no process model at all.

That trade favors OpenCat when the robot is the point and the software stack is not. It favors the general framework when you need multiple sensors, logging, and a debugging story that survives a crash mid-run. For a classroom, the Arduino sketch is the smaller thing to explain. For a research group that already runs ROS, the serial link into a host machine is a bridge, not a replacement, and the README presents ROS support as community documentation rather than a maintained integration.

Licence, upgrade path and what maintenance costs you

OpenCat is MIT-licensed. In practice that means you can fork it, ship a product based on it, and keep your changes closed, as long as you preserve the copyright notice and licence text. It does not oblige Petoi to accept your patches, and it does not give you any warranty. If you build a classroom kit around this code, the licence is the least of your problems; the hardware supply is the real one, since the boards it targets are discontinued.

Upgrade cost is dominated by that hardware fact. Petoi's release history for the desktop application shows a steady cadence through 2025, with 1.2.6beta in August 2025, but the firmware repository and the desktop app are different artifacts with different lifecycles. The README's own instruction is to move to OpenCatESP32 for current hardware, and it describes the ESP32-S3 code structure as similar to this repository. That similarity is the migration path: your skill definitions and host-side Python will port more easily than your board-specific pin configuration will. If you are starting today, the cheaper decision is to begin on the ESP32 side and read this repository for the gait and servo concepts it established.

Editorial conclusion

Adopt OpenCat if you own a NyBoard Bittle or Nybble, or if you want a small, readable C++ codebase for studying gaits, servo control and IMU integration on hardware you can hold. Do not adopt it as the starting point for a new build: the README redirects current hardware to the OpenCatESP32 repository, and this one supports the discontinued ATmega328P boards. Before committing, confirm which board your kit ships with, check that the pin definitions in src/ match your wiring, and read the serial protocol in serialMaster/ against the Python API in OpenCatPythonAPI/ so your host-side code speaks the same commands.

Frequently asked questions

Official sources

1. License: MIT
2. PetoiCamp/OpenCat-Quadruped-Robot on GitHub
3. Project website
4. README
5. Releases