Chassis geometry and weight distribution

The base is a triangle seen from above: two driven wheels on the motor axis line at the front, one swivel caster behind. The two SO-101 arms sit on a line parallel to the motor axis, and they reach forward — out past the front wheels, over the only tipping edge that matters. The whole design problem is that one sentence.

Frame and sign conventions

Origin on the ground at the midpoint of the drive-wheel axle.

• x — forward, perpendicular to the motor axis. Positive is the direction the arms reach.
• y — left, along the motor axis.
• z — up.

So the forward tipping edge is the line x = 0, and the whole of the weight-distribution problem is "keep the centre of mass at negative x".

What is already fixed

These are not design choices left to make — they are already in the repo or in a datasheet, and the rest of the geometry has to live with them.

Mass budget

Only the parts that matter for balance. Everything else — LiDAR, converters, wiring, fuses, hub — is deliberately excluded, and gets a reserve line instead.

Four of those eleven lines are assumptions, and they are 3.0 kg of the 6.3 — so treat the absolute numbers as provisional and the ratios as the real output. hardware_inventory.md has recorded "total robot mass is not measured" as an open item for months; this table is the first estimate to close against.

What the arms can actually lift

This sets the disturbance the base has to survive, so it comes first.

The shoulder (Pitch) is a single STS3215 at 1.863 N·m stall. Holding the arm out horizontally already costs most of that: at full extension the unloaded gravity torque at the shoulder is 0.956 N·m, just over half the budget, before anything is in the gripper.

Solving τ_shoulder(m_payload) ≤ 1.863 N·m across the workspace, using the MJCF link masses and centres of mass:

Max reach is 476 mm from the arm mount to the grip point, at 120 mm above the mount plane. At 50% of stall — a sane continuous rating — the payload at full extension is zero: the arm can just barely hold itself up.

Tipping: the only equation that matters

The support polygon is the triangle with vertices at the two wheel contacts (0, ±170) and the caster contact (−L, 0).

For forward tip-over the edge is the front axle, and the caster's position is irrelevant — only the centre of mass matters:

tips forward  ⟺  x_cm > 0

Write d = −x_cm, the distance the CoM sits behind the axle. Then the static load split follows from one moment balance about the front contact line:

N_caster = W · d / L        N_drive = W · (1 − d / L)

That is the whole trade in two symbols. d buys tip-over safety; d/L costs traction. Push the CoM back to stop the arms tipping the robot and you unload the drive wheels; the only way to have both is to make L — the longitudinal length — longer.

Two more disturbances eat into d, and both scale with CoM height:

braking:   d_used = a · z_cm / g          slope θ:  d_used = z_cm · tan θ

This is where the arm mount height bites, and it is why the mast is not free.

Where the arms have to go

Run the CoM sum for the worst arm pose while sliding the arm mount line along x (battery and caster fixed):

Mounting the arms over the wheel axle — the intuitive choice — leaves 19 mm of margin and a robot that tips at 2.9°. Mounting them ahead of the axle tips it standing still. The arms have to sit ~180 mm behind the motor axis, reaching forward over the drive wheels rather than out beyond a cantilever.

Moving the battery cannot substitute for this. To reach d = 90 mm with the arms on the axle, the 1.33 kg pack would have to sit 600 mm behind the axle — well outside any sane footprint. The battery is a 1.33 kg trim adjustment on a 7.3 kg robot; the arm position is the actual control.

The design point

Which gives:

Forward and sideways tip angles land within 1° of each other in the loaded case (17.7° vs 18.6°), which is the sign that L is correctly matched to the track — neither axis is the weak one.

The margin budget

104 mm of static margin sounds generous. It is almost entirely spoken for:

Braking at the motors' peak thrust costs 72.6 mm; a 5° downslope costs another 28.4 mm. Doing both at once leaves 3 mm. The robot is stable, but it is stable by design, not by accident — which means two rules follow:

• Cap deceleration in software, or accept that a hard stop on a wheelchair ramp is the tip-over case. The limit falls from 3.14 m/s² on the flat to 2.27 m/s² on a 5° downslope — below the motors' 2.19 m/s² peak by only 4%.
• Any mass added high up spends this budget. Every 10 mm of z_cm costs about 3 mm of margin.

Arm mount height is stability-limited

d doesn't change with arm height, but z_cm does, and the braking term scales with it:

Traction and the caster load

Direct drive means thrust comes straight from motor torque with no gearbox multiplication — F = 2τ/r:

Available traction is μ · N_drive:

The awkward case is stowed: folding the arms back moves the CoM to 167 mm behind the axle and hands 46% of the weight to the caster. On slick floors the wheels break traction before the motors stall. That is a benign failure — slip, not fall — and current-limiting fixes it, but it is worth knowing that the robot has less grip when it is not carrying anything.

Per-wheel load peaks at ~25 N against the MF5010's 153 N bearing rating, so the cantilevered wheel mount is not a concern.

Where the camera mast goes

The D455 sits behind the arms so its mass helps the balance instead of hurting it, and so it looks over the arms rather than through them. The mast at 300 mm behind the axle puts it 120 mm behind the arm line.

The constraint that sets its height is not field of view — it is minimum depth range. The D455's wide 95 mm baseline buys it 20 m of range at the cost of a min-Z around 0.52 m; anything nearer returns no depth. The nearest point of the workspace is only 150 mm forward of the mast horizontally, so:

√(0.15² + Δz²) ≥ 0.52   →   Δz ≥ 0.50 m

The camera must sit 500 mm above the arm plane — 950 mm above ground — purely so the near edge of the workspace is outside its blind zone. Field of view is not close to binding: the workspace spans 32.6° vertically against the D455's 58°, and 300 mm of half-width against the 745 mm it sees at the far edge. Depression angles run 73° (near) to 41° (far), so the mount wants ~57° down.

For comparison, XLeRobot puts its head camera 438 mm above its arm plane. Same ballpark, arrived at independently.

Ride height and caster sizing

The deck sits at 100 mm, which is set by the caster, not by the wheels: a 3-inch swivel caster with a top plate is ~100 mm from floor to mounting face. The drive axle has to be at 50 mm — the wheel radius — so the motors hang 50 mm below the deck on drop brackets. Get this wrong and the robot rocks on two wheels.

The BOM already has 4× 3-inch swivel casters on hand for a layout that needs one, so there is nothing to buy here.

What to measure before cutting anything

1. Weigh the two drive wheels. 300 g each is a vendor listing, and 600 g is 10% of the dry mass.
2. Weigh an assembled SO-101. The 760 g figure is 609 g of MJCF inertials plus a 150 g guess for the base link.
3. Measure the XLeRobot plate's actual arm spacing and confirm the 266 mm from the URDF matches the physical part.
4. Measure the caster's trail — it sets how much of L is real.
5. Confirm the MF5010 winding (10T vs 35T). It changes peak thrust by a third, which changes the braking term, which is 70% of the stability budget. This is already flagged unrecorded in the BOM.
6. Decide the arm height before printing the pedestal. 450 mm and 750 mm are different robots.

Then fix the sim: move the arm offsets from ±200 mm to ±133 mm, and add the base so that policies see the same geometry they will be deployed onto.