The Community SDK and ROS 2 Path

7.1 What this volume covers

Wire-pod (Vol 6) keeps Vector alive at the cloud-replacement layer — it handles voice recognition, knowledge-graph answers, and the gRPC/TLS plumbing that the robot expects of a cloud server. The present volume climbs one layer higher: the community Python SDK that talks to wire-pod and exposes Vector’s sensors, vision, navigation, and animation control to application code, and the ROS 2 bridge built on top of that SDK that places Vector inside the standard ROS 2 autonomy ecosystem. Together they convert a consumer desk robot into a programmable sensor-rich research platform — without touching the robot’s firmware.

The revival stack has three tiers. The robot firmware and its real-time behaviours sit at the bottom; wire-pod and the gRPC interface sit in the middle; the SDK and ROS 2 wrapper sit at the top. This volume addresses the top tier.

7.2 The Python SDK — fork chain and install

7.2.1 Lineage

The Python SDK available to Vector owners today descends through four hands. Anki shipped an official SDK alongside the original robot; when Anki folded and DDL’s cloud went dark, community maintainers carried it forward. The lineage confirmed by the project’s own repository is Anki → cyb3rdog → MoonDog83 → kercre123 (github.com/kercre123/wirepod-vector-python-sdk). Each fork adapted the SDK to the community revival stack; the kercre123 fork is the current active version, published to PyPI as wirepod-vector-sdk.

7.2.2 Installation

The package installs with a single pip command (github.com/kercre123/wirepod-vector-python-sdk):

pip install wirepod_vector_sdk

Supported Python versions run from 3.6.1 through 3.12, giving the SDK a wide compatibility window across current distributions (github.com/kercre123/wirepod-vector-python-sdk).

7.2.3 Relationship to wire-pod

The SDK is designed for wire-pod but does not strictly require it (github.com/kercre123/wirepod-vector-python-sdk). In practice, because the original DDL cloud is dead (Vol 4) and OSKR key issuance has been suspended since mid-2023 (Vol 5), wire-pod is the operative server for any unmodified retail unit, and the SDK pair should be treated as an integrated community stack rather than independently versioned components.

7.2.4 What the SDK exposes

The SDK surfaces the following capability classes confirmed by the repository (github.com/kercre123/wirepod-vector-python-sdk):

Table 1 — (github.com/kercre123/wirepod-vector-python-sdk)

Capability class	Notes
Sensors	Access to the IMU, proximity/ToF, cliff sensors, and touch sensor readings
Vision	Camera feed; face recognition and object detection pipeline
Mapping and navigation	Access to the robot’s onboard spatial mapping; navigation control
Animations	Triggering and sequencing the onboard animation library

Full API documentation is hosted at keriganc.com/sdkdocs (github.com/kercre123/wirepod-vector-python-sdk).

7.2.5 A note on the hardware target

Every sensor the SDK exposes is a confirmed hardware feature of the Vector platform (wevolver; iFixit): the four-microphone beamforming array, the six-axis IMU, the time-of-flight infrared laser distance scanner, the four cliff sensors, the 2 MP front-facing camera (Vector 2.0), and the capacitive touch surface. The SDK gives application code a single Python interface to all of them simultaneously — a sensor density that most purpose-built research platforms of comparable size do not offer off the shelf.

7.3 The ROS 2 bridge

7.3.1 What it is

vector_ros2 (github.com/nilseuropa/vector_ros2), authored by nilseuropa, is a ROS 2 Jazzy wrapper that sits over the wirepod-vector-python-sdk and places Vector inside the standard ROS 2 node graph. A robot that began life as a consumer desk appliance becomes, through this bridge, a first-class citizen in the ROS 2 ecosystem: subscribable topics, publishable commands, callable services — the full Nav2/SLAM- compatible interface that any ROS 2 autonomy stack expects.

7.3.2 Hard requirements

vector_ros2 carries two confirmed prerequisites (github.com/nilseuropa/vector_ros2):

1. OSKR — the DDL open-source kit that permanently converts a retail Vector to a developer build and unlocks system-partition flashing (covered in full in Vol 5).
2. wire-pod — the community local server that replaces the dead DDL cloud (covered in full in Vol 6).

Both prerequisites must be in place before the ROS 2 bridge will function. A stock retail Vector pointed at DDL’s defunct cloud cannot run vector_ros2; an OSKR-unlocked unit running wire-pod can.

7.3.3 Topics published

The bridge publishes the following topics, confirmed by the repository (github.com/nilseuropa/vector_ros2):

Table 2 — (github.com/nilseuropa/vectorros2)

Topic	Content
Pose	Robot pose in the map frame
Odometry	Wheel-odometry estimate
IMU	Six-axis inertial measurement (accelerometer + gyro)
Battery	State-of-charge
Camera	Front-facing camera image stream
Proximity	Time-of-flight distance readings
Touch	Capacitive touch-sensor state
Cliff	Four cliff/drop sensor states
Joint states	Lift arm and head joint positions
Occupancy grid	The robot’s onboard occupancy map

7.3.4 Topics subscribed

The bridge subscribes to two command topics (github.com/nilseuropa/vector_ros2):

Table 3 — (github.com/nilseuropa/vectorros2)

Topic	Effect
cmd_vel	Twist commands; drives the tread base
Head/lift control	Sets the head angle and lift arm height

The cmd_vel subscription is the standard ROS 2 velocity interface, meaning vector_ros2 accepts commands from any standard ROS 2 navigation stack — including Nav2 — without translation.

7.3.5 Services offered

The bridge exposes six callable services, confirmed by the repository (github.com/nilseuropa/vector_ros2):

1. Explore — triggers autonomous exploration behaviour
2. Fetch cube — engages the robot’s cube-interaction routine
3. Dock — sends the robot to its charging dock
4. Animation — plays a named animation from the onboard library
5. Text-to-speech — speaks a string through the robot’s speaker
6. An unnamed sixth service — the repository lists six services; the sixth is confirmed to exist by count but its exact name was not separately stated in the reachable source. UNVERIFIED beyond the confirmed count of six (github.com/nilseuropa/vector_ros2).

7.3.6 Build

The package is built with colcon, the standard ROS 2 build tool (github.com/nilseuropa/vector_ros2). No non-standard build system is required; a working ROS 2 Jazzy installation plus colcon is the build prerequisite.

7.3.7 What ROS 2 Jazzy implies

ROS 2 Jazzy Jalisco (released May 2024, per ROS 2 documentation) is a long-term support release targeting Ubuntu 24.04 Noble Numbat. Pinning the bridge to Jazzy gives the wrapper a defined, stable support window and aligns it with the current LTS-to-LTS conventions of the ROS 2 ecosystem. A host machine running Ubuntu 24.04 LTS with a standard Jazzy desktop install is the implied base environment; the sourcing notes do not name alternative distributions, so any deviation from the Jazzy/Noble pairing should be treated as UNVERIFIED.

7.4 Other community wrappers

vector_ros2 is not the only community-authored interface layer. The confirmed sourcing notes identify the following additional wrappers (github.com/kercre123/wirepod-vector-python-sdk; vector_sourcing_notes §7):

• CtfChan — a community wrapper (repository confirmed; details beyond existence are NOT FOUND in reachable sources).
• gregory-j-r — a community wrapper (confirmed by name; details NOT FOUND).
• jonmo (GitLab) — a wrapper hosted on GitLab (confirmed; details NOT FOUND).
• betab0t — a ROS 1 wrapper (confirmed; the sole identified ROS 1 interface layer; details beyond the ROS 1 / betab0t attribution are NOT FOUND).

These are confirmed to exist as distinct community projects. None of the four are documented in detail by any reachable source used for this dive; their current maintenance state, feature sets, and compatibility windows are left unclaimed.

7.5 Vector as a ROS 2 target — comparison with RoboDog

RoboDog — a from-scratch ROS 2 quadruped build also in this hub — starts from a component survey and authors its own ROS 2 / Nav2 / SLAM stack from the ground up. The contrast with Vector is instructive.

A RoboDog builder assembles a sensor suite, writes or adapts a ROS 2 hardware abstraction layer, tunes a Nav2 configuration, and commissions each subsystem individually before any useful autonomy code runs. The robot is the build project.

A Vector owner who has OSKR, wire-pod, and vector_ros2 in place has a ready-made, sensor-rich ROS 2 target: IMU, odometry, a camera, a ToF laser, cliff sensors, touch input, and an occupancy grid all arrive as confirmed published topics. The robot is complete; the programming is the project. The sensor density — four-microphone array, six-axis IMU, time-of-flight distance scanner, 2 MP 120° camera, four cliff sensors, capacitive touch — is high for a palm-sized platform.

The trade is openness for convenience. RoboDog’s hardware is the operator’s to modify; Vector’s hardware is fixed. RoboDog’s firmware is the operator’s to write; Vector’s firmware is closed, and the revival stack’s authority ends at the gRPC interface. For research use cases that fit within that boundary — navigation, SLAM, sensor fusion, behaviour scripting — Vector offers a rapidly deployable sensor-equipped ROS 2 node. For use cases that require firmware-level access to motor controllers, timing loops, or custom hardware, the approach does not generalise.

7.6 Summary

The community programming path above wire-pod consists of two confirmed layers. The wirepod-vector-python-sdk (kercre123; PyPI wirepod-vector-sdk; fork lineage Anki → cyb3rdog → MoonDog83 → kercre123; Python 3.6.1–3.12) exposes Vector’s sensors, vision, navigation, and animation control to Python application code and is documented at keriganc.com/sdkdocs. Built on that SDK, vector_ros2 (nilseuropa; ROS 2 Jazzy; requires OSKR + wire-pod) publishes ten confirmed topics, subscribes two command streams, and offers six services — placing an unmodified Vector body into the standard ROS 2 node graph. Together they represent the highest-level confirmed layer of the Vector revival stack, one that turns the hardware of a failed commercial product into a programmable research platform without opening the robot’s case or modifying its firmware.

Sources

• github.com/kercre123/wirepod-vector-python-sdk — authoritative source for the SDK fork chain (Anki → cyb3rdog → MoonDog83 → kercre123), PyPI package name (wirepod-vector-sdk), install command (pip install wirepod_vector_sdk), Python version range (3.6.1–3.12), wire-pod design intent, and exposed capability classes (sensors, vision, mapping/nav, animations); documentation pointer (keriganc.com/sdkdocs); confirms existence of CtfChan, gregory-j-r, jonmo (GitLab), and betab0t wrappers.
• github.com/nilseuropa/vector_ros2 — authoritative source for the ROS 2 bridge: Jazzy target, OSKR + wire-pod hard requirements, all ten published topics, two subscribed topics, count of six services (five named, sixth count-only), and colcon build system.
• github.com/kercre123/wire-pod (wiki) — wire-pod capabilities and architecture, cross-referenced throughout; detailed coverage in Vol 6.
• github.com/digital-dream-labs/oskr-owners-manual; personalrobots.biz — OSKR as the vector_ros2 prerequisite; detailed coverage in Vol 5.
• wevolver.com/specs/vector-20-ai-robot-companion; iFixit, “Anki Vector” — hardware sensor suite (IMU, ToF, cliff sensors, camera, touch, microphones) confirming the physical targets that the SDK exposes.
• Full gated fact base with confirmed/unverified markers and source reachability: 02-inputs/vector_sourcing_notes.md.