Forward vs. inverse​

Forward kinematics is the easy direction: given a set of joint angles, figure out where the end effector ends up. Just chain the transforms down the chain — this joint rotates this much, that joint rotates that much, tip lands here. Mechanical, no ambiguity, one answer.

Inverse kinematics is the direction we actually want, and it's the hard one: given a target position, figure out what joint angles get you there. With enough joints, there's no clean formula for this — you can't just "solve for q." So instead of solving it directly, we solve it iteratively: start from wherever the arm or hand currently is, and nudge the joints a little bit at a time until it gets close enough to the target.

Both of the IK systems on the robot — the bimanual arm and the hand — work this way. Same core technique, damped least squares (DLS), used in two different setups depending on what's being targeted.

Two arms, two independent chains​

For the bimanual arm setup (video above), a cube in the scene is the target — move the cube, and the arm's 6 joints follow to keep the gripper tip on it. This one runs on Isaac Lab's built-in DifferentialIKController with ik_method="dls", so we get damped least squares for free without writing our own solver.

That works cleanly here because each arm only ever has one target: its own gripper tip. And since the left arm's 6 joints and the right arm's 6 joints don't overlap — two fully independent kinematic chains off the torso — there's zero coupling between them. Each arm gets its own controller instance, chasing its own target, completely unaware the other arm exists.

Five fingertips, one shared chain​

The hand can't get away with the same trick. It's a 6 DOF arm plus a 15 DOF hand — 21 degrees of freedom total — driving 5 fingertips at once, and all 5 of those fingertips share the same upstream arm joints. A target for one fingertip and a target for another aren't independent: moving the arm to help one finger reach its target shifts where every other finger ends up too.

A single-target controller like DifferentialIKController has no way to solve that — it only ever sees one Jacobian block for one body. So instead, fingertip_ik.py is a hand-rolled solver that stacks all 5 fingertip Jacobians into one system and solves for all 21 joints jointly, so the shared arm joints get moved in a way that's good for all 5 targets at once, not just whichever one happened to go first.

Why damped least squares​

With 21 joints and only 15 position constraints (5 fingertips × 3D each), the naive approach — just invert the Jacobian and solve directly — runs into trouble near certain poses: the Jacobian gets close to singular, and a plain inverse tries to divide by something close to zero. That means huge, unstable joint jumps right when the hand is near a tricky configuration.

Damped least squares fixes this by adding a small penalty on how big the joint step is allowed to be, instead of solving the system exactly. That penalty (the damping term) keeps the solution well-behaved even when the Jacobian is near-singular, at the cost of moving a bit more cautiously.

The loop​

Each iteration does basically the same four things:

1. Where are we now? Run forward kinematics to get the current fingertip positions.
2. How far off are we? For every fingertip with a target, compute the error vector — target position minus current position — and stack all of them into one big error vector $\mathbf{e}$.
3. Which way do we move? Build the Jacobian $\mathbf{J}$ — it maps small joint changes to small fingertip movements — and solve the damped least squares problem for the joint step $\Delta\mathbf{q}$:

4. Take the step. Apply a fraction of that joint step ($\mathbf{q} \leftarrow \mathbf{q} + \alpha\,\Delta\mathbf{q}$), clip to joint limits, and repeat.

That loop runs until the error drops below a tolerance or it hits a max iteration count — at which point you've got a joint configuration that puts every fingertip where it needs to be, or as close as the hand's geometry allows. The Jacobians and forward kinematics come from MuJoCo, with Isaac Sim handling visualization. Only fingertip position is constrained — orientation is left free — which keeps the problem smaller and the solver faster per iteration.

For the exact algorithm, defaults, and code-level detail, see the Software & ML docs.

This term​

• 40+ contributing members — the team grew to one of the largest design teams at UWaterloo, all in a single term.
• A functional 7 DOF humanoid arm — currently working through a motor issue, fix incoming.
• A 22 DOF humanoid hand with fully routed tendons.
• A fully designed 12 DOF humanoid leg, set to be built next term.
• A full-body humanoid is coming soon, and everything above already exists in simulation for ML training.
• Renewed partnerships and sponsorship — companies like CubeMars, plus a growing list of people reaching out to learn more about the team.

We set our goals for the term in our quest book at the start of the summer, and we've far exceeded all of them.

Where we're headed​

One-year goal: a humanoid that walks around campus on its own, with arms doing useful work — assembling its own components, folding clothes, that kind of thing.

What is TVC?​

Have you ever wondered how NASA or SpaceX control their rocket during flight? For a small model rocket, the most straightforward option is fins — just let the airflow keep the rocket pointed straight. But fins get impractical once you're at large scale: no airflow, no control, and they're just extra drag and weight you're dragging along.

So instead, big rockets use thrust vector control (TVC). The idea is simple: you control where the thrust points, and use the horizontal component of that thrust to generate a torque that controls the rocket's orientation. Tilt the engine a few degrees off-center, and now part of that thrust is pushing sideways instead of straight down — and since it's acting away from the rocket's center of mass, it rotates the rocket. Doesn't matter how fast (or slow) you're going, it still works, which is why it's the go-to for landings too, not just ascent.

Meet Pioneer​

The long term goal here is propulsive landing — bringing the rocket back down under its own thrust, SpaceX-style, or eventually even catching it out of the air like Starship's booster does with the tower's "chopsticks." Both of those are really just TVC problems taken further, needing control through a much harder flight regime than ascent.

Pioneer, the rocket in the video above, only has to nail one thing: ascent. Stable, controlled powered flight. Landing and catching come once that's solid.

The control algorithm​

So the first thing you're probably wondering is: what's actually driving the gimbal? This is where it gets technically kind of hairy.

Two things are working against us:

1. We're using solid rocket motors — the impulse is huge the moment it lights, and once it's lit, that's it, you can't throttle it or shut it off.
2. Every launch burns exactly one motor. There's no re-testing on the cheap — if the controller doesn't work, you don't get a redo, you just wasted a motor.

Put those together and you get a lot of pressure to have the control method figured out before it ever leaves the ground. The solution we went with is honestly just PID control, and it works surprisingly well even under these constraints.

The ping-pong ball analogy​

Easiest way to think about PID: balancing a ping-pong ball on a racket, trying to keep it centered.

• P (Proportional) — as the ball gets further from center, you'd naturally tilt the racket more to bring it back. That's proportional control: you tilt based on how far off-center the ball currently is. Bigger offset, bigger tilt.

  $u_P(t) = K_p\, e(t)$

• D (Derivative) — if the goal is to have the ball sitting still at the center, position alone isn't enough. You also watch how fast it's moving toward the center, and pre-emptively tilt against that motion so it slows down and settles right at the center instead of flying past it.

  $u_D(t) = K_d \frac{de(t)}{dt}$

• I (Integral) — if the ball keeps drifting the same way over time (say your racket's slightly tilted to begin with), you accumulate that error and correct for the persistent bias — something P alone can't fix.

  $u_I(t) = K_i \int_0^t e(\tau)\, d\tau$

Worth noting: not every real controller actually uses all three terms. A lot of actuator-driven systems run PD instead of full PID — the integral term can cause "windup" issues once the actuator saturates (maxes out), where the buildup causes a big overshoot once it un-saturates. For a fast gimbal that's often close to its deflection limits, that tradeoff usually isn't worth it, so some setups skip the I term entirely.

Applying it to the rocket​

Same principle, just applied to the rocket instead of a ball. Instead of position, the error term is the gap between desired and actual pitch/yaw angle:

$e(t) = \theta_{desired}(t) - \theta_{actual}(t)$

The PID controller turns that error into a commanded gimbal deflection angle $\delta(t)$:

$\delta(t) = K_p\, e(t) + K_i \int_0^t e(\tau)\, d\tau + K_d \frac{de(t)}{dt}$

And that commanded angle turns into actual torque on the rocket through the gimbal geometry:

$\tau = F_T \sin(\delta) \cdot L$

where $F_T$ is the thrust force, $\delta$ is the gimbal deflection angle, and $L$ is the distance from the gimbal pivot to the rocket's center of mass. Tune $K_p$, $K_i$, and $K_d$ right, and that torque is what keeps the rocket pointed where it should be throughout the burn, correcting for disturbances in real time.

Airframe and avionics​

The body's a foil-wrapped tube with a 3D-printed nose cone, but the part that actually matters is the gimbal mount at the base: a printed bracket holding two servos at 90° to each other, one for pitch and one for yaw, so the motor can be pushed off-axis in any direction.

Flying the electronics is a custom PCB — Arduino Nano as the flight computer, an MPU6050 for rate/angle data (that's what feeds the PID loop) and a BMP180 barometer. All of it sits in a bay cut into the body tube, wired straight to the servos.

Testing, one milestone at a time​

Since a real launch is a one-shot, motor-consuming event, we can't just wing it and see what happens. Instead there's a staged pipeline, each step cheaper and safer to fail at than the next:

1. MATLAB/Simulink simulation — check the control loop and gains actually work against a simulated rocket, before touching hardware.

2. BLDC test bench — get the gimbal actuator and control loop timing working on the bench, driven by a BLDC motor instead of a real rocket motor.

3. Motor test bench static fire — full control loop, real motor, but static-fired on a stand so we can measure thrust and gimbal response without an actual flight.

4. Actual flight test — Pioneer leaves the pad.

Results​

After all the vigorous testing, we got two consecutive successful launches!