Quadruped Robot Platform

Limit: Runs on Limit X

One dog, twelve joints, three sensors, one 3D model. This site documents the robot itself, and a dry-run drive lab to feel the controls.

W/S + Q/E + A/D to drive · drag to orbit · scroll to zoom
LOADING LIMIT

The Robot:

The robot "Limit" is a quadruped platform: twelve GIM6010-8 gear-motor joints and a trot gait on alternating diagonal leg pairs. The locomotion controller (CHAMP) runs on the robot, and it picks up the velocity command, drives the 12 motors on CAN, and writes the joint angles back. The server's Gazebo sim runs its own CHAMP under the sim_* topic convention. The robot senses through three instruments, a ZED 2i front stereo camera with VIO and IMU, an Ouster OS0-128 rev7 128-channel LiDAR, and a u-blox F9P GNSS receiver. The ZED 2i's visual-inertial odometry gives the robot a local (relative) pose; global localization awaits a GNSS fix or AMCL map-matching, see Localization. For a deeper understanding of the data, see the Topics page.

The Software:

The software "Limit X" is a dockerized software stack designed to be deployed across vastly different frameworks and architectures. It can be used with arms, bipeds, or quadrupeds, like the one documented here, and makes for rapid deployments of the entire ROS 2 stack with ease: the same containers carry sensors, locomotion, localization, and Nav2 between an x86-64 server and an ARM robot, so a new platform comes up without rebuilding the stack.

Notes:

A few notes will help while you read this site. For much of it, this has been an independent research project I carried out over the first few years of my undergraduate engineering studies. It is not perfect, but I have tried to keep it cohesive and to hold the docs to the most relevant topics, so each page conveys a specific understanding. Thank you for your interest.

A few framing ideas will make what follows easier to follow. Robotics is heavy on coordinate transforms, an observation that shaped this work. The REP 103 standard, which fixes coordinate frames and xyz conventions, is what keeps them in check. Once you can say, "the start point is x, the robot sits at this offset, and the obstacle is that far away," the rest follows: you send commands that encode the gait, and those commands solve for the joint angles. That framing strips a lot of complexity away. Limit X is a stack designed to let you deploy any robot quickly with minimal configuration. For a sense of scale: my last full-stack deploy on a fresh install took under twenty minutes and brought the system fully through controls and global localization. A core goal is transparency about how data flows through the machine, To keep this as approachable as possible, another core goal is to take complex problems and make them approachable for broad audiences of users. The hope is to facilitate better conversations surrounding safety and better general understanding.

C++17 core 12 joints kinematics trot gait diagonal pairs ZED 2i front stereo · VIO · IMU Ouster OS0-128 rev7 128-channel LiDAR u-blox F9P GNSS 3D drive lab

Interact with it

model

Robot Model

The joint map, kinematics tables, and URDF structure, the reference for the body.

3D

Drive lab

Drive Limit with W/S (forward/back), Q/E (strafe), A/D (turn). The gait animation engages while a key is held and settles back to idle on release. Speed and turn rate are live parameters.

live

Limit Dash

The live operations console, documented on the Limit Robot page: the dog in its live LiDAR spatial map, the ZED 2i with depth and RGB, telemetry and the whole topic graph, and W/S + Q/E + A/D teleop straight into /cmd_vel.