NormaCore pairs a Rust driver stack with a Go station that streams what the hardware sees
Physical Operations Platform
At a glance
- What is it?
- NormaCore is a Physical Operations Platform: a Rust workspace of device drivers, a Go real-time station binary with a web UI, a Protobuf SDK called Gremlin in Go and Python, and 3D printed hardware designs for a robotic arm, a gripper and a desk lamp. It is a research platform built from scratch, still on a 0.1.0 beta version line, and the Rust and Go halves are separate toolchains in one repository.
- Who is it for?
- Adopt NormaCore if you are building robot or sensor systems and want a driver layer, a real-time collection and inference service, and a shared Protobuf contract in one repository, especially if you already work in Rust or Go. Do not adopt it as a general robotics library, since the drivers are specific to the named devices and the platform ships with its own hardware designs and web UI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A physical system, not a library, and the hardware comes with it
NormaCore describes itself as a Physical Operations Platform and a unified toolkit for physical system development and operations. The README frames the audience broadly, from complex robotics to distributed sensor networks and hobby projects, and states the design goal plainly: a unified API, high performance data pipelines and visual tooling so an entire ecosystem can be managed as one.
What makes the repository unusual is that the hardware is in it too. The contents table lists ElRobot, a fully 3D printed 7+1 DoF robotic arm for imitation learning, a modular Parallel Jaw Gripper for the SO-101 arm, and Lamp, a fully 3D printed 5 DoF robotic desk lamp with an optional LED ring and web UI. The README is explicit that the team had to build complete hardware systems from scratch, not just software, to make the platform approach work.
That coupling is the central design decision and also the central trade-off. You get a complete stack that has been exercised on real hardware, including the exact arm the AI training path targets. You also get a repository whose scope is far larger than most robotics libraries, where the drivers, the runtime, the SDK, the AI training code and the mechanical designs all move together.
The three software projects are what an adopter would actually consume. Station is described as a real-time robotics platform for data collection, inference and control, delivered as a single binary with a web UI. SmolVLA fine-tune is the path to train and deploy a SmolVLA policy on the SO-101 arm. Gremlin is a high-performance Protobuf SDK for Go and Python, used across the station and the driver stack, and it exists in two implementations at shared/gremlin_go and shared/gremlin_py.
The Rust workspace is a list of device drivers plus the station interface
The Cargo.toml at the root defines a Rust workspace with resolver 3, and the member list is the clearest available map of what the platform supports. The drivers are the bulk of it: airgradient-open-air-o-1pst for air quality sensors, arduino-nicla-sense-env for a Nicla environment sensor, ina226 for a current and voltage monitor, hikmicro-thermal for thermal imaging, st3215 for a serial bus servo, vesc-trampa for a VESC motor controller, victron-smartsolar-mppt for a solar charge controller, ov5647 for a camera sensor, usbvideo for video capture, motors-mirroring, inferences, sysinfod, and yahboom-dogzilla-lite for a robot platform.
Three non driver members stand out. shared/i2c-async is the asynchronous I2C layer that the sensor drivers sit on, software/station/bin/station is the station binary itself, and software/station/shared/station-iface and software/station/shared/systime-rs are the shared interface and system time crates.
The workspace dependency list shows the shape of the runtime. tokio is pulled in with the full feature set, so everything is async from the ground up. prost and prost-build handle Protobuf, tokio-serial is there for the serial devices, and there are pinned versions of bytes, log, parking_lot and lazy_static. The workspace package version is 0.1.0-beta.10, which is the same string as the most recent release tag.
The choice of tokio with the full features set for a driver stack is what makes the async i2c-async crate coherent rather than bolted on. A driver for a serial servo and a driver for a USB camera can share the same task model, and the station can drive many of them concurrently.
The Go half is the station, and it terminates the data path
The Go module is separate from the Rust workspace, and the go.mod shows a different set of concerns. The module is named norma_core and targets go 1.25.6, with a replace directive pointing the Gremlin SDK at the local path so the two halves of the repository always build against the same code.
The direct dependencies tell you what the station does. Apache Arrow Go and parquet-go are there for the data pipeline, which means the platform stores and moves columnar data rather than log lines. There is a normfs filesystem library from the same organisation, and the terminal stack is bubbletea with lipgloss and aurora for rendering, so the station has a terminal interface as well as the web UI mentioned in the README.
The picture that emerges is a two language architecture. Rust owns the hardware, the drivers and the async runtime that talks to devices. Go owns the long running station process, the columnar data pipeline and the human facing interfaces. The contract between them is the Protobuf schema, which is what Gremlin generates code for in both languages.
The repository root confirms the split: go.mod and go.work sit next to Cargo.toml, with a go.work.sum and a shared/ directory holding both the Go and Python SDKs. There is a staticcheck.conf for the Go static analysis, and a device-support/ directory at the top level whose contents are not shown in the repository listing.
The build regenerates Protobuf for Go and Python from one schema directory
The Makefile is where the two toolchains and the schema meet. Its default goal is all, which depends on build-all, and there is a clean target that removes and recreates the target directory.
The protobuf target is the important one, because it is the mechanism that keeps the Gremlin SDKs in step:
protobuf:
go run ./shared/gremlin_go/gremlinc/main.go -src ./protobufs -out ./target/generated-sources/protobuf -module norma_core/target/generated-sources/protobufThe Go generator is a program inside the repository, gremlinc, run from the shared/gremlin_go directory, and it reads from the protobufs/ directory and writes into target/generated-sources/protobuf under the norma_core module path. A shell loop then walks the protobufs directory and invokes the Python generator for each subdirectory, producing Python files under target/gen_python/protobuf.
So the schema lives once in protobufs/ and both SDKs are generated from it, and a change to a message definition propagates to Go and Python in one build step rather than by hand.
The rest of the Makefile is a standard Rust and Go quality gate. The deps target installs staticcheck at a pinned version, and the prebuild target depends on deps, protobuf, configs, generates and checks before running the test suite with a coverage profile. The tests target uses -failfast, and the checks target runs go vet and staticcheck over the Go code. A generates target runs go generate over the tree, and there is a separate all target chain. The build number is stamped from a timestamp and the branch name comes from git rev-parse.
The Python side exists for the AI path, not for the drivers
The SmolVLA fine-tune project lives at software/ai/smolvla_py and is described as training and deploying a SmolVLA policy on the SO-101 arm, with the upstream model documentation hosted on Hugging Face's LeRobot pages. It sits in the Python tree alongside the generated Protobuf code, which is what makes it usable: the training code talks to the hardware through the same Gremlin messages as everything else.
The table also names a Gremlin implementation for Python at shared/gremlin_py, and the Makefile's Python generator is invoked with an import path of shared.gremlin_py.gremlin, so the Python package name is fixed by the build rather than being incidental.
The hardware is what makes the AI part credible. The arm ElRobot is described as a 7+1 DoF design for imitation learning, and the Parallel Jaw Gripper is explicitly modular for the SO-101 arm. So the loop the project is built around is: a cheap reproducible arm you can print, a gripper that fits the standard research arm, a lamp as a second manipulator, and a policy training path on top.
One detail in the Makefile hints at how Python is treated in the build. The copy command prefers the Homebrew coreutils build of gcp over the system cp, which is a macOS specific accommodation, so the repository is developed on macOS at least as much as on Linux.
A beta version line, an MIT licence and a wide surface to maintain
The version line is the clearest signal about maturity. The published releases are v0.1.0-beta.10 on 2026-08-09, v0.1.0-beta.9 on 2026-07-03 and v0.1.0-beta.8 on 2026-06-02, and the Cargo workspace package version matches at 0.1.0-beta.10. The project has not reached 1.0, and the beta suffix on every tag says the interface is still moving.
The last push was on 2026-10-16 and the repository is not archived, so the work is current and roughly two months behind the most recent tag. The top level entries also show a go.work file, which means the Go code is itself a multi-module workspace, and a .cargo/ directory plus a target/ directory at the root, the latter being the build output directory that the clean target recreates.
The licence is MIT, with a LICENSE file at the repository root, so there is no copyleft obligation on code you reuse. That is a licensing note rather than legal advice, and it does not cover the hardware designs, which carry their own practical considerations if you print and redistribute parts.
The honest limitation is breadth. Thirteen named device drivers, a station runtime, two SDK implementations, a schema compiler, an AI training path and four mechanical designs in one repository is a lot of surface for a small team, and the beta version number means the drivers and the station interface can change. The most likely failure mode for an adopter is not that the code does not work, but that a driver for their exact device is missing or the model they needed has moved.
The alternative to adopting all of it is to take one piece. The Gremlin SDKs and the schema are the narrowest useful unit, since the Protobuf contract can be used to talk to the platform from your own code without taking on the drivers or the web UI. Taking the full platform only pays if your hardware matches the supported list.
Editorial conclusion
Adopt NormaCore if you are building robot or sensor systems and want a driver layer, a real-time collection and inference service, and a shared Protobuf contract in one repository, especially if you already work in Rust or Go. Do not adopt it as a general robotics library, since the drivers are specific to the named devices and the platform ships with its own hardware designs and web UI. Verify first which languages your team can maintain, since the drivers and the i2c-async layer are Rust while the station and the Gremlin SDK are Go, and check the release line, since the published versions are 0.1.0 beta tags rather than a stable 1.0.
Frequently asked questions
What is NormaCore?
NormaCore is a Physical Operations Platform, a unified toolkit for developing and deploying physical systems. It combines a unified API, high performance data pipelines and visual tooling, and it ships both software and 3D printed hardware designs such as the ElRobot arm, a parallel jaw gripper and a robotic desk lamp.
Which programming languages does NormaCore use?
The device drivers and the i2c-async layer are a Rust workspace, while the station binary and the Gremlin SDK are Go, and there is a Python implementation of the SDK plus a Python AI training project. The two halves communicate through Protobuf messages defined once in the protobufs directory.
Which devices does NormaCore support?
The Rust workspace lists drivers for air quality and environment sensors, an ina226 current monitor, a hikmicro thermal camera, an st3215 serial servo, a vesc-trampa motor controller, a victron smartsolar MPPT charger, an ov5647 camera, usb video capture, motors mirroring, inferences, system info and the yahboom dogzilla lite platform.
How do I build NormaCore?
The Makefile drives the build. The protobuf target runs the gremlinc generator for Go and the Python generator over the protobufs directory, the generates target runs go generate, the checks target runs go vet and staticcheck, and prebuild depends on deps, protobuf, configs, generates and checks before running the test suite with coverage.
Is NormaCore ready for production use?
The published releases are all 0.1.0 beta tags, with the most recent being v0.1.0-beta.10 on 2026-08-09, and the Cargo workspace version is 0.1.0-beta.10. The last push was on 2026-10-16 and the repository is not archived, and the licence is MIT.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/norma-core-norma-core)Was this useful?