roboticsbench
Six robotics tools that run in your browser.
Rotation converter
Quaternions, Euler angles in all 24 conventions, axis-angle and matrices, kept in sync.
URDF viewer
Load a robot, drag its joints, read the end-effector pose and Jacobian.
PID tuning
Tune a drone, an arm and an inverted pendulum, with the math live.
Kalman filter
Steer a noisy cart, mis-tune Q and R, and watch the estimate react.
Localization
Particle filter against EKF on a landmark map. Kidnap the robot, or turn on the wind.
Motion planning
Draw or upload a map, then race A*, Dijkstra, RRT and RRT* to the goal.
Robot arm basics
A short class in six steps: where things are, how an arm moves, and how to make one reach a point. Every step has an arm to play with and the math beside it, updating as you go.
The math, live
Rotation converter
Edit any form and the rest follow. Every convention is spelled out, so a quaternion in the wrong order cannot slip through.
Paste anything
tf2_echo, a ROS message, NumPy, Eigen, a listQuaternion
Euler angles
Axis-angle
Rotation vector
axis × angle, in radRotation matrix
rows; columns are the rotated X, Y, Z axesPreview
Watch out
- ROS messages, tf2 and SciPy store quaternions
x y z w. Eigen's constructor takesw, x, y, z, but.coeffs()returnsx y z w. - URDF
rpyis roll, pitch, yaw about fixed axes: extrinsic XYZ, which equals intrinsic ZYX with the angles reversed. qand-qare the same rotation. This page keepsw ≥ 0; other tools may not, so compare rotations, not raw numbers.- SciPy: uppercase sequence letters are intrinsic, lowercase are extrinsic.
"XYZ"and"xyz"are different rotations. - Inputs accept
pi,sqrt()and arithmetic, sopi/2orsqrt(2)/2work.
URDF viewer
URDF, the Unified Robot Description Format, is the XML file that tells the rest of a robot stack what the robot is shaped like. Load one, drag its joints and read off the end-effector pose and Jacobian. Files stay in your browser; nothing is uploaded.
Robot
Or drop a URDF and its meshes (STL, DAE, OBJ) on the viewer. Drop the whole package folder so package:// paths resolve.
Paste URDF text
Joints
Forward kinematics
Position (m)
Quaternion (w x y z)
RPY (deg, URDF)
Geometric Jacobian
Columns are joints from base to tip. Rows are linear (v) then angular (ω) velocity of the tip, in the base frame, per unit joint velocity.
What URDF is
and what reads itThe format
An XML file describing one robot as rigid links joined by joints. A link carries three optional bodies: visual for what you see, collision for what the planner tests against, usually a coarser shape, and inertial for mass and the inertia tensor.
The joints form a tree: one root link, and every other link reached by exactly one joint from its parent. That is the format's main limit. A closed loop, like a delta robot or a four-bar linkage, cannot be written down directly. mimic couples one joint to another and covers some of it; past that you need SDF or a solver that closes the loop itself.
What a joint says
origin places the child frame in the parent at zero position, axis is the unit vector it turns or slides along, and limit caps travel, effort and velocity.
Six types, three of them common: revolute turns within limits, continuous turns forever, like a wheel, prismatic slides. fixed moves not at all and is how sensors, tool plates and named frames get attached. floating and planar exist and are thinly supported.
Meters, radians and kilograms throughout. rpy is fixed-axis roll, pitch, yaw, applied X then Y then Z, which is the same rotation as intrinsic Z-Y-X. Frames are right handed, and REP 103 asks for x forward, y left, z up.
Where it gets used
It is the one description a whole ROS stack shares, so the pieces agree on the geometry:
- robot_state_publisher takes the URDF plus live joint angles and publishes the TF tree, which is how anything else answers "where is the camera relative to the gripper right now".
- RViz draws the robot from it. Gazebo and other simulators take the inertial and collision bodies as the physics, with extra gazebo tags for sensors and plugins.
- MoveIt plans against the joint limits and collision bodies, with a companion SRDF adding the meaning: which joints form an arm, what counts as the end effector, which link pairs never collide.
- KDL, Pinocchio and friends build forward kinematics, inverse kinematics, Jacobians and dynamics from the same file. This page does the first and third of those.
How they are really written
Almost nobody types URDF by hand. It comes out of a CAD exporter, or it is written as xacro, an XML macro language with variables, arithmetic and includes, and expanded into plain URDF when the robot launches. Raw URDF has no way to reuse anything, so a six-jointed arm would be six copies of the same block with the numbers changed.
Meshes are referenced as package://my_robot_description/meshes/link1.stl, a path resolved against the installed ROS packages rather than the disk. Nothing outside ROS knows how to follow that, which is why this viewer asks for the folder: it matches the tail of the path against the files you handed it.
PID tuning
Move the gains and watch the system settle, overshoot or shake itself apart. The physics runs live at 800 Hz with the controller at 200 Hz.
Rise time
Overshoot
Settling (2%)
Steady error
Live response
last 10 sPresets
Speed
Controller output, live
The math
updates liveControl law
The sent to the actuator.
The system
What the code runs, every step
Closed loop, linearized about the setpoint
A linear prediction: it ignores the actuator limit, large angles, the derivative filter and sampling. When the output saturates, the simulation and the prediction part ways.
Kalman filter
A cart moves along a track and a noisy sensor reports its position. The filter blends a constant-velocity model with each reading. Set what the filter assumes apart from the true noise and see whether its error band stays honest, or steer the cart yourself and watch a filter that was never told about the maneuver.
Sensor RMSE
Estimate RMSE
Inside ±2σ
Position σ
Live estimate
last 10 sTruth and sensors
The filter is told this value.
What the filter assumes
R = m²
Presets
The math
updates liveLocalization
A robot works out where it is from noisy odometry and range and bearing to known landmarks, with walls in the way. Five estimators read the same data. Turn on the wind to push the robot in a way none of them is told about.
How do they differ?
- Particle filter: many sampled guesses at the pose. Guesses that explain the measurements survive resampling, so it can hold several at once.
- EKF: one Gaussian, updated by linearizing the motion and measurement models.
- UKF: one Gaussian, carried through the models by seven sigma points instead of a linearization.
- Grid: a probability for every 25 cm cell and 22.5° heading. Slow to update, but it can hold any shape of belief.
- Dead reckoning: adds up the odometry and ignores the landmarks.
Error now
| Algorithm | Position | Heading | Status |
|---|
Neff / N
In view / in range
Position error
last 20 sWind
Plans around walls with A* and loops through eight waypoints.
Drive
Hold a button, or click the map and use the arrow keys or WASD. Driving turns the autopilot off.
Around the robot
What am I looking at?
The true robot sits at the center. Each estimate is drawn as an offset from it, with a trail of the last 8 seconds, so you can see how each one wanders around the robot. The scale adapts: a few centimeters while tracking, meters after a kidnap.
The math
updates liveMotion model
The estimators get the commanded v and ω. The real robot executes them with this noise added, and a wall can stop it while the command says it moved.
Measurement model
Only landmarks within the max range are measured, and only if the straight line from the robot to the landmark crosses no wall. Each measurement says which landmark it came from.
Dead reckoning
No measurement step. Every bit of slip and every bump stays in the estimate for good, so the error only grows.
Particle filter, every step
Grid Bayes filter
Cells inside walls are held at zero. Motion that would carry belief into a wall leaves it where it was.
EKF predict
EKF update, per landmark
EKF covariance, now
UKF
Motion planning
Draw walls, move the start and goal, and watch each planner search the grid, or scrub the search back and forth one expansion at a time. Bring your own map as a text file. The table runs every planner on the same map.
What goes in the file
One character per cell, one line per row. Any text editor will do.
- . free cell
- # wall
- S start, at most one
- G goal, at most one
- ; a note, for any line you want ignored
Rows may be ragged: a short one is padded with free cells. Leave out S or G and they are placed in the free space for you. Between 5 by 5 and 200 by 200 cells. The quickest way in is Download this one, edit it, and bring it back.
Drag on the grid to draw walls. Hold Shift or use the right button to erase. Drag the start or goal to move it.
Nodes expanded
Frontier size
Path length
Path found
Every planner on this map
updates when the map changes| Algorithm | Expanded | Path length | vs Dijkstra | Optimal | ms |
|---|
Grid planners use the moves and heuristic set on the right. Optimal means the same length as Dijkstra. RRT and RRT* show iterations used, with seed 1; their paths are not tied to grid moves, so they can come in under 1.000.
Drag to rewind or fast-forward. The search is replayed, not recorded, so every step is exact. Arrow keys nudge it one at a time.
Edit
Moves
Each run draws new samples. Narrow corridors, like the maze, need a small step.
The math
updates livePriority
What the result guarantees
Heuristic
RRT* rewiring radius
Each new node takes the cheapest parent within r, then any neighbor within r that would be cheaper through the new node switches to it. Edges are checked cell by cell, so no corner is clipped.