{"slug": "gorai-a-go-based-robotics-framework-for-the-ai-era", "title": "Gorai – a go-based robotics framework for the AI era", "summary": "Gorai, a Go-based robotics framework, treats robots as distributed systems by using a NATS mesh for service discovery and communication, enabling sensors and actuators to be addressed by name rather than wired connections. The framework supports composite robots spanning multiple machines, enforces safety at capability nodes, and provides a CLI for validation, building, and mesh introspection.", "body_md": "**The robotics platform for the AI era.**\n\n*Pronounced \"go-ray\" (like \"sting-ray\")*\n\nA robot is a distributed system — so build it like one.Even a \"single\" robot is already a network of MCUs, SBCs, sensors, and sometimes a base station. Gorai stops pretending otherwise: every sensor and actuator is a service on a NATS mesh — discovered at runtime, addressed by name, never wired by hand. The discipline that built reliable cloud systems — service discovery, location transparency, health checks, fan-out, replay — is exactly what a real robot needs.\n\nCapabilities, not wiring.Sensors areresourcesyou read; actuators aretoolsyou call. Any agent on the mesh can perceive the world and change it — the capability model MCP gives AI agents, delivered natively over NATS withno MCP server in the path. We call it NCP, the NATS Capability Protocol.\n\nOne robot can be many machines.Because capabilities are addressed by name and not by location, a single logical robot can span a rover, a drone, a sensor mast, and a compute box — composed at runtime, degrading gracefully as platforms join and leave. This is theComposite Robot, and it's the whole point.\n\nAutonomy without replay is folklore.Action logs, state streams, and replay are first-class platform concerns — not add-ons. AI execution is welcome but never trusted: safety is enforced at the capability node, not the agent.Agent-compatible, not agent-dependent— deterministic state machines and rule-based planners drive the same capabilities.\n\nBuild robots like software. Run them like systems.Opinionated, pragmatic, operational. If you already think in APIs, distributed systems, and deployments, you'll be productive in days, not months.\n\nRead the north star: ** VISION.md**.\n\nFull documentation lives atStrategy, architecture, specifications, hardware analysis, a 20-chapter book, and implementation guides — all indexed for both humans and AI agents. Point your AI agent at that repo and it will navigate 100+ documents via[gorai-docs].`CLAUDE.md`\n\nand`INDEX.md`\n\nautomatically.\n\nThere are **two different binaries** in a Gorai project, and it's important not to confuse them:\n\n-\n**Your robot binary**— the program that runs on the Pi and*does the robot stuff*. This is your own Go module: a`main.go`\n\nthat blank-imports the components you want and calls`gorai.Run()`\n\n. Its embedded NATS server, the mesh, and every component compile into this one static binary. It is fully self-contained and**needs nothing from the**— you copy it to the robot and run it.`gorai`\n\ntool at runtime -\n**The**— a`gorai`\n\nCLI**developer and operator tool** you run at your workstation. It never runs on the robot in production. Think of it as`kubectl`\n\n+ a build wrapper + a package helper, rolled into one command.\n\nSo yes — you *could* just `go build .`\n\nyour robot project and `scp`\n\nthe result to the Pi. The `gorai`\n\nCLI earns its place by doing the things *around* that binary that a plain `go build`\n\ndoes not:\n\n| What you want to do | `gorai` command |\nWhat it actually does |\n|---|---|---|\n| Catch config errors before deploying | `gorai validate robot.json` |\nValidates your RDL (schema, deprecations) so you don't ship a broken config to the field |\n| Iterate fast without cross-compiling | `gorai run robot.json` |\nRuns the same runtime your robot binary uses, in the foreground — skips the compile-and-copy loop |\n| Produce a deployable binary | `gorai build robot.json --target linux/arm64` |\nWraps `go build` with validation, cross-compile ergonomics, version stamping, and deploy hints |\n| Find and add components | `gorai component search/add` |\nWraps `go get` and edits the blank-import list in `main.go` (the Caddy model — see below) |\n| See what's running on a live mesh | `gorai mesh services / watch / schemas` |\nConnects to a running NATS mesh and introspects it — your service-discovery browser for a robot or fleet in the field |\n\nThe first three are conveniences over the Go toolchain. The **mesh commands are the part you genuinely cannot replicate with go build** — they observe and debug a\n\n*running*system, which is what you reach for once a robot (or several) is live.\n\nThe rest of this README covers how to install the CLI, define a robot, and build it.\n\nBuild a robot in under an hour. Write JSON, get a binary, deploy to a Linux host (Raspberry Pi/Orange Pi/etc).\n\n```\n# 1. Install the CLI (a dev/operator tool — not the robot itself)\ngo install github.com/emergingrobotics/gorai/cmd/gorai@latest\n\n# 2. Create a robot project from the template\ngit clone https://github.com/emergingrobotics/gorai-robot-template.git my-robot\ncd my-robot\n\n# 3. Edit robot.json, then validate and run\ngorai validate robot.json\ngorai run robot.json\n\n# 4. Build for deployment\ngorai build robot.json -o robot --target linux/arm64\nscp robot pi@raspberrypi:~ && ssh pi@raspberrypi ./robot\n```\n\nNo containers. No K8s. No external services — just a single binary on a Raspberry Pi 5 or Orange Pi 5. That's the simple case, not the ceiling: point several binaries at a shared NATS bus (or a leaf node) and the mesh ties multiple platforms into one logical robot — same code, no rewrite.\n\nGorai targets prosumer-accessible field robots across marine, surface, underwater, and land domains — autonomous submersibles, autonomous surface vessels, and land robots. An autonomous submersible, for example, runs `gorai run`\n\non a Linux host (Raspberry Pi/Orange Pi/etc) inside a pressure housing.\n\nGorai uses the **Caddy model** for component packaging: your robot project is a standard Go module, and the import list in `main.go`\n\n*is* the component manifest. Each component self-registers via `init()`\n\ncalling `registry.RegisterComponent()`\n\n. There is no custom package manager -- Go modules handles everything.\n\nA robot's `main.go`\n\ndeclares which components to include via blank imports:\n\n```\npackage main\n\nimport (\n    gorai \"github.com/emergingrobotics/gorai/pkg/gorai\"\n\n    // Remote proxy components from GoRAI core\n    _ \"github.com/emergingrobotics/gorai/components/motor/remote\"\n    _ \"github.com/emergingrobotics/gorai/components/camera/remote\"\n\n    // Third-party component from the ecosystem\n    _ \"github.com/someone/gorai-component-lidar/rplidar\"\n\n    // Custom component in this repo\n    _ \"my-robot/components/ballast\"\n)\n\nfunc main() {\n    gorai.Run()\n}\n```\n\nThe Go import list replaces `package.json`\n\n, `requirements.txt`\n\n, or any custom manifest. What you import is what gets compiled into the binary.\n\n```\ngorai component search lidar          # Find components in the ecosystem\ngorai component add sensor/rplidar    # go get + add blank import to main.go\ngorai build robot.json                # Single binary with everything included\n```\n\nCustom components are ordinary Go packages in your project's repo. Write a package with an `init()`\n\nfunction that calls `registry.RegisterComponent()`\n\n, add a blank import in `main.go`\n\n, and it compiles into the binary alongside everything else.\n\nSharing a component means publishing a Go module. Extract the package into its own repo, push to GitHub, and anyone can `gorai component add`\n\nit. No registry servers, no package approval process -- standard Go module hosting.\n\nThis is a key advantage of choosing Go as the platform language. The single-binary story extends all the way to the component ecosystem: no runtime dependency resolution, no DLL hell, no version conflicts at deploy time. Every dependency is resolved at build time by the Go toolchain, and the result is one static binary you copy to the robot.\n\nNon-Go components (Python vision pipelines, C++ SLAM) run as external services communicating via NATS. They do not compile into the binary. This is Phase 2 complexity.\n\nFor the full design, see [docs/package-dev-approach.md](/emergingrobotics/gorai/blob/main/docs/package-dev-approach.md).\n\n**Use Gorai if you:**\n\n- Want\n**real autonomy**(not educational toys, not simulations) - Need\n**approachable software**(productive in days, not months) - Value\n**modern tooling**(AI-assisted coding, simple deployment) - Are building\n**prosumer robots**(marine monitoring, land vehicles, research platforms) - Are a\n**software-first team** adding physical embodiment to AI/ML or scaling from one robot to fleets - Care more about\n**behavior, coordination, and operations** than low-level kinematics or middleware internals\n\n**Use ROS 2 if you:**\n\n- Work in\n**enterprise/research** robotics (warehouse automation, autonomous vehicles) - Need the\n**full ROS ecosystem**(thousands of packages, simulation, SLAM libraries) - Are in\n**academia** where ROS 2 is the standard - Need\n**deep hardware or control-architecture experimentation**(ROS 2 is the right platform)\n\nWe're not replacing ROS 2 — we're targeting a different market. Think \"ROS 2 for prosumers,\" with an **AI-first** design for the next wave of autonomous systems.\n\nRobotics is shifting because **decision-making is moving up the stack**: autonomy is no longer only hand-authored logic. Perception, planning, and task selection are increasingly learned, probabilistic, or agentic. That shift—*physical AI*—changes what a platform must provide.\n\n**What the future market is:**\n\n**Physical AI**— systems where behavior, autonomy, and coordination are more complex than motor control or kinematics** Software-first teams**— engineers and AI/ML practitioners who need to ship robots and fleets without becoming robotics-infrastructure experts** Autonomy as a spectrum**— from scripted behaviors and state machines to learned perception and agentic planners, all needing the same operational surface\n\n**Why Gorai is built for it:**\n\n**AI-first by design**— we treat AI-driven execution as a first-class assumption: capability surfaces for tools, governance and safety at runtime, and auditability/replay as baseline, not add-ons**Start simple, scale without rewriting**— one binary today; same contracts and RDL when you add ML services, multi-robot coordination, or fleet operations** Clarity over maximal flexibility**— we optimize for teams whose hardest problems are autonomy, orchestration, deployment, and safety—not low-level robotics research\n\nWe are not trying to serve every robot. We are building the default platform for teams that ask: *\"How do we safely decide what the robot should do next—and scale that across systems?\"*\n\nFor the full strategic context, see [Gorai Overarching Strategy](https://github.com/emergingrobotics/gorai-docs/tree/main/docs/overview/) in the gorai-docs repository.\n\nYou need **Go 1.25+** to build gorai. That's it.\n\n**macOS:**\n\n```\nbrew install go\n```\n\n**Ubuntu/Debian:**\n\n```\nsudo apt update && sudo apt install -y golang-go\n```\n\nOr download from [https://go.dev/dl/](https://go.dev/dl/) for the latest version.\n\nNATS is embedded in the gorai binary -- no external message broker to install.\n\nThe NATS CLI lets you subscribe to messages and debug your robot:\n\n**macOS:**\n\n```\nbrew install nats-io/nats-tools/nats\n```\n\n**Linux:**\n\n```\ngo install github.com/nats-io/natscli/nats@latest\ngo install github.com/emergingrobotics/gorai/cmd/gorai@latest\n# Clone the template (or click \"Use this template\" on GitHub)\ngit clone https://github.com/emergingrobotics/gorai-robot-template.git my-robot\ncd my-robot\n\n# Update the module path to your own\ngo mod edit -module github.com/yourorg/my-robot\n```\n\nThe template includes a skeleton `robot.json`\n\n. Add components as needed:\n\n```\n{\n  \"version\": \"2\",\n  \"robot\": {\"name\": \"my-robot\", \"description\": \"My first robot!\"},\n  \"nats\": {\"embedded\": true, \"url\": \"nats://localhost:4222\"},\n  \"dashboard\": {\"enabled\": true, \"listen\": \":10101\"},\n  \"components\": []\n}\nmake validate   # Check configuration\nmake run        # Run in development mode\n```\n\nThe embedded NATS server starts automatically -- no separate process needed.\n\n```\n# Build for Raspberry Pi\nmake build TARGET=linux/arm64\n\n# Deploy\nmake deploy DEPLOY_HOST=pi@raspberrypi\n```\n\nFor multi-robot deployments or shared brokers, point at an external NATS server:\n\n```\n{\n  \"nats\": {\n    \"url\": \"nats://nats-server.local:4222\",\n    \"external\": true\n  }\n}\n```\n\nWhen `external`\n\nis `true`\n\nor the URL points to a non-local address, gorai connects to the external server instead of starting its own.\n\n| Platform | AI Performance | Cost | Best For |\n|---|---|---|---|\nRaspberry Pi 5 (8GB) |\nExternal (Hailo 13-26 TOPS) | ~$160 | Primary platform, best ecosystem |\nRaspberry Pi 5 (4GB) |\nExternal (Hailo 13-26 TOPS) | ~$100 | Budget builds |\nOrange Pi 5B (8GB) |\n6 TOPS (built-in NPU) | ~$145 | Budget AI builds |\n\n**Not supported:** Pi 3, Pi Zero\n\nSee Hardware Requirements in the [gorai-docs](https://github.com/emergingrobotics/gorai-docs/tree/main/docs/specifications/) repository for details.\n\nGorai supports two patterns for accessing hardware. Both produce components with identical interfaces — application code doesn't know or care which is used.\n\n**Co-processor (RP2040 via GSP/2):** An RP2040 microcontroller handles real-time hardware I/O (PWM, motor control, encoders). The RPi communicates with it over USB serial using the Gorai Serial Protocol v2. Best for timing-critical control, isolating hardware from Linux scheduler jitter, and reliability-critical applications (e.g., an autonomous submersible — motor control must not glitch underwater).\n\n**Native RPi hardware (GPIO/I2C/SPI):** Direct access to Raspberry Pi GPIO pins, I2C buses, and SPI buses from Go code. Best for simple sensors, I2C devices, prototyping, and cost-sensitive builds where an RP2040 is unnecessary.\n\nBoth patterns can be used simultaneously — e.g., RP2040 handling motors while the Pi reads I2C sensors directly.\n\n| Command | Description |\n|---|---|\n`gorai validate <config>` |\nValidate RDL configuration |\n`gorai run <config>` |\nRun robot in development mode |\n`gorai build <config>` |\nBuild standalone binary |\n`gorai components` |\nList available component types |\n`gorai version` |\nShow version information |\n`gorai migrate` |\nMigrate RDL v1 config to v2 format |\n\n| Command | Description |\n|---|---|\n`gorai component search` |\nSearch for third-party components |\n`gorai component info` |\nShow component information |\n`gorai component add` |\nAdd component to project |\n\n| Command | Description |\n|---|---|\n`gorai mesh services` |\nList running services in the mesh |\n`gorai mesh channels` |\nList registered NATS channels |\n`gorai mesh schemas` |\nList or show message schemas |\n`gorai mesh watch` |\nWatch for services joining/leaving |\n`gorai mesh summary` |\nShow mesh state summary |\n`gorai mesh robots` |\nList robots with registered services |\n`gorai mesh init` |\nInitialize predefined schemas |\n`gorai mesh reset` |\nReset mesh (delete all data) |\n\nThe core repo provides **component interfaces**, **remote proxies** (for multi-robot mesh access), and **fakes** (for testing). Hardware-specific implementations live in external Go modules.\n\n`arm`\n\n, `base`\n\n, `camera`\n\n, `gripper`\n\n, `input`\n\n, `link`\n\n, `motor`\n\n, `power`\n\n, `pwm`\n\n, `sensor`\n\n, `servo`\n\n, `space`\n\n, `stepper`\n\n, `thruster`\n\n, `valve`\n\n`camera/remote`\n\n, `gpio/remote`\n\n, `input/remote`\n\n, `motor/remote`\n\n, `pwm/remote`\n\n, `sensor/encoder/remote`\n\n`camera/fake`\n\n, `motor/fake`\n\n, `pwm/fake`\n\n, `servo/fake`\n\nHardware-specific implementations are installed with `gorai component add`\n\n:\n\n`gorai-picarx`\n\n- SunFounder PiCar-X robot kit`gorai-driver-hcsr04`\n\n- HC-SR04 ultrasonic distance sensor- More in the\n[component registry](https://github.com/emergingrobotics/gorai-registry)\n\nGorai uses a message-based architecture where all components communicate via an embedded NATS server:\n\n```\n┌──────────────────────────────────────────────────────┐\n│                  Your Robot Binary                    │\n│                                                      │\n│  ┌─────────┐ ┌─────────┐ ┌─────────┐                │\n│  │  GPS    │ │ Motor   │ │ Sensor  │    ...          │\n│  │Component│ │Component│ │Component│                 │\n│  └────┬────┘ └────┬────┘ └────┬────┘                 │\n│       │           │           │                      │\n│       └───────────┴─────┬─────┘                      │\n│                         │                            │\n│                   ┌─────▼─────┐                      │\n│                   │  Message  │                      │\n│                   │   Router  │                      │\n│                   └─────┬─────┘                      │\n│                         │ NATS Protocol              │\n│                   ┌─────▼─────┐                      │\n│                   │ Embedded  │                      │\n│                   │   NATS    │  (JetStream enabled) │\n│                   └───────────┘                      │\n└──────────────────────────────────────────────────────┘\n```\n\n**Key principles:**\n\n- Single binary with embedded NATS -- no external services required\n- Each component runs in its own goroutine\n- Internal control uses Go channels\n- Inter-component communication uses NATS only\n- No shared memory between components\n- Message-based architecture enables remote debugging\n- External NATS supported for multi-robot or shared broker deployments\n\n| Example | Description | Status |\n|---|---|---|\n|\n\n[gps-tracker](/emergingrobotics/gorai/blob/main/examples/gps-tracker)[gsp-pico](/emergingrobotics/gorai/blob/main/examples/gsp-pico)[hello-camera](/emergingrobotics/gorai/blob/main/examples/hello-camera)[pwm-controller](/emergingrobotics/gorai/blob/main/examples/pwm-controller)Gorai includes a built-in service mesh for runtime discovery across independent processes. This enables:\n\n**Cross-binary discovery**— Modules that aren't compiled together can find each other** Channel registry**— Discover available NATS subjects and their schemas** Health monitoring**— Automatic TTL-based expiry for stale services** Schema documentation**— JSON Schema definitions for message types\n\n```\n┌─────────────────────────────────────────────────────────────────────────┐\n│                         NATS JetStream KV                                │\n│  ┌─────────────────────────────────────────────────────────────────┐    │\n│  │  gorai-services (TTL: 30s)     → Active service registrations   │    │\n│  │  gorai-channels (persistent)   → Channel/subject descriptors    │    │\n│  │  gorai-schemas  (persistent)   → Message schemas (JSON Schema)  │    │\n│  └─────────────────────────────────────────────────────────────────┘    │\n└─────────────────────────────────────────────────────────────────────────┘\n// Register a service\nclient, _ := mesh.NewClient(natsConn)\nreg, _ := client.Register(ctx, mesh.ServiceDescriptor{\n    Name:    \"motor-controller\",\n    Type:    mesh.TypeComponent,\n    Subtype: \"motor\",\n    RobotID: \"robot-alpha\",\n})\ndefer reg.Deregister()\n\n// Discover other services\nmotors, _ := client.FindServices(ctx, mesh.Query{Subtype: \"motor\"})\n# List all running services\ngorai mesh services\n\n# Watch for changes in real-time\ngorai mesh watch\n\n# List available channels\ngorai mesh channels robot-alpha\n```\n\nSee the mesh service discovery specification in the [gorai-docs](https://github.com/emergingrobotics/gorai-docs/tree/main/docs/specifications/) repository for complete documentation.\n\nGorai supports **hybrid static/dynamic** configuration. Define structure in RDL, discover hardware at runtime.\n\nTraditional approach requires declaring every device in config:\n\n```\n{\n  \"components\": [\n    {\"name\": \"motor1\", \"type\": \"motor/pwm\", \"config\": {\"pin\": 18}},\n    {\"name\": \"motor2\", \"type\": \"motor/pwm\", \"config\": {\"pin\": 19}}\n  ]\n}\n```\n\nWhat if you don't know what devices will be connected? What if devices are hot-plugged?\n\nDefine **discovery rules** instead of individual devices:\n\n```\n{\n  \"gateways\": [\n    {\n      \"name\": \"usb-gateway\",\n      \"type\": \"gateway/gsp\",\n      \"config\": {\n        \"discovery\": {\"enabled\": true, \"patterns\": [\"/dev/ttyACM*\"]}\n      }\n    }\n  ],\n\n  \"discovery\": {\n    \"enabled\": true,\n    \"auto_adopt\": true,\n    \"rules\": [\n      {\"match\": {\"capability\": \"PWM\"}, \"adopt_as\": {\"type\": \"motor\"}},\n      {\"match\": {\"capability\": \"IMU\"}, \"adopt_as\": {\"type\": \"sensor\", \"subtype\": \"imu\"}}\n    ]\n  },\n\n  \"services\": [\n    {\n      \"name\": \"patrol\",\n      \"type\": \"behavior/patrol\",\n      \"depends_on\": [\"@discovered:motor/*\", \"@discovered:sensor/imu/*\"]\n    }\n  ]\n}\n```\n\n**What happens:**\n\n- Gateway discovers Pico on USB with PWM+IMU capabilities\n- Auto-adopts as motor and IMU sensor (via rules)\n- Patrol service's\n`@discovered:`\n\ndependencies resolve - Robot starts patrolling with discovered hardware\n\nSee the dynamic discovery specification in the [gorai-docs](https://github.com/emergingrobotics/gorai-docs/tree/main/docs/specifications/) repository for complete documentation.\n\n| Pattern | ROS 2 | Gorai | Benefit |\n|---|---|---|---|\nMessage Broker |\nDDS peer-to-peer | NATS server | Decoupled, easy monitoring |\nEvent Sourcing |\nrosbag (manual) | JetStream (built-in) | Replay, time-travel debug |\nObservability |\nCustom diagnostics | Prometheus /metrics | Industry-standard tools |\nPackage Management |\nCustom (rosdep, colcon) | Go modules | Standard tooling, no custom manager |\n\n**Go core**— NATS orchestration, configuration, web dashboard** Python services**— Vision (OpenCV), ML inference (PyTorch) —*future***C++ services**— SLAM (Cartographer), point cloud processing —*future*\n\nNATS has clients for 40+ languages. Use the best tool for each job.\n\n**Version:** 0.1.0 (Early Development)\n\nThe current focus is a zero-dependency, single-binary deployment model:\n\n- Single Go binary with embedded NATS server\n- No external services required -- everything in one process\n- No containers, no K8s\n- Runs directly on Raspberry Pi with systemd\n- JetStream enabled by default for event sourcing and mesh discovery\n\nGoRAI uses the [Caddy model](/emergingrobotics/gorai/blob/main/docs/package-dev-approach.md) for component distribution. Each hardware driver is a standalone Go module. A user's robot project has a `main.go`\n\nthat imports the GoRAI core plus blank imports for each component needed. `go build`\n\nproduces a single binary with exactly those components compiled in. See [REQUIREMENTS.md](/emergingrobotics/gorai/blob/main/REQUIREMENTS.md) for details.\n\n**Non-Go services**— Python/C++ services (vision, SLAM) communicate via NATS as external processes, not compiled-in components** Fleet management**— Multi-robot coordination (future phase)** ROS 2 bridge**— Interop with ROS 2 ecosystems (future phase)\n\nAll documentation has moved to the [gorai-docs](https://github.com/emergingrobotics/gorai-docs) repository, including:\n\n**Getting Started**— Hardware requirements, Robot Definition Language (RDL) configuration** Architecture & Design**— Strategy, vision analysis, design comparisons, mesh service discovery, dynamic discovery** For AI Assistants / LLMs**—[CLAUDE.md](/emergingrobotics/gorai/blob/main/CLAUDE.md)(in this repo),[gorai-docs INDEX.md](https://github.com/emergingrobotics/gorai-docs/blob/main/INDEX.md)**Future State**— Roadmap, component ecosystem plans\n\nGorai is built with [Claude Code](https://claude.ai/claude-code). We believe AI-assisted development is the future — the project is organized for both humans and AI to reason about effectively.\n\n- See\n[CLAUDE.md](/emergingrobotics/gorai/blob/main/CLAUDE.md)for contributor guidelines - See the\n[gorai-docs](https://github.com/emergingrobotics/gorai-docs)repository for code organization and package locations\n\n- See the LLM Design Guide in the\n[gorai-docs](https://github.com/emergingrobotics/gorai-docs)repository — everything needed to design new components and services without reading the entire codebase\n\nApache 2.0", "url": "https://wpnews.pro/news/gorai-a-go-based-robotics-framework-for-the-ai-era", "canonical_source": "https://github.com/emergingrobotics/gorai", "published_at": "2026-07-15 12:36:29+00:00", "updated_at": "2026-07-15 12:47:57.526896+00:00", "lang": "en", "topics": ["robotics", "developer-tools"], "entities": ["Gorai", "NATS"], "alternates": {"html": "https://wpnews.pro/news/gorai-a-go-based-robotics-framework-for-the-ai-era", "markdown": "https://wpnews.pro/news/gorai-a-go-based-robotics-framework-for-the-ai-era.md", "text": "https://wpnews.pro/news/gorai-a-go-based-robotics-framework-for-the-ai-era.txt", "jsonld": "https://wpnews.pro/news/gorai-a-go-based-robotics-framework-for-the-ai-era.jsonld"}}