Using TITAN O1 as a stand-in: from connecting to getting it moving

I spent two days trying out TITAN O1's embodiment avatar. It works, and it's genuinely convenient, but it's not a device you can just turn on and play with—there's a calibration step in the middle, and if you skip it, everything after is wasted effort.

TITAN O1 is a humanoid robot from Westlake Robotics, the company incubated out of Westlake University. The GAE embodiment avatar system it carries has a very intimidating name; in plain terms, you make movements on your own body, and the robot on the other end copies them. No pre-programming, no teaching pendant to bend each joint one by one. You raise your left hand, it raises its left hand; you rotate however many degrees, it rotates however many degrees. Official materials say the replication is millisecond-level, and it breaks geographical limits—one person can command dozens of units simultaneously.

My actual testing was limited to the same LAN, and I basically couldn't feel any latency. Cross-network remote operation wasn't tested this time; I don't have a ready public network link on hand, so I won't vouch for it. So the "connection successful" below is all limited to two devices connected to the same router; whether the remote layer drops latency, we'll have to wait until a real public network link is pulled.

Connect, then calibrate

The operating end is the device you wear that captures your movements; the robot is the body. First put these two on the same LAN. Power on the robot, wait for it to stand up on its own—don't rush it; taking over before it's stable will directly throw an error. Boot the operating end and enter the control interface; normally you'll see a device list, and TITAN O1's ID will pop up on its own. Click that ID, and wait for the status to go from gray to green—that means it's connected.

If the list stays empty, check two things: whether both devices are on the same router, and whether the router has device isolation enabled. I got stuck here on day one, fiddled for forty minutes before realizing isolation was on, and the two machines couldn't see each other.

After connecting, don't do any movements yet. There's a calibration entry in the interface; click into it, and the robot will first do a stand-up alignment, then ask you to stand about two meters directly in front of it, in a natural stance—don't slouch, don't put your hands on your hips—and stay still for a few seconds. When the skeleton on screen overlaps with your body and the error bar falls into the green zone, this step is done.

This step is the easiest to get wrong. People have habitual stances; if you're slightly crooked, the robot's zero point is crooked too, and every subsequent movement carries that offset—it just looks a bit off. I calibrated three times before getting it right the first time. I talked about calibration in another post last week—the bulk of the time goes into this, and it's the same here.

Start with the smallest movements

Even after calibration, don't throw a punch. First raise your right hand, see if it follows; once it follows, increase—twist your waist, take a step. At each level, pause for two seconds, see if it wobbles; if it wobbles, pull the amplitude back, wait for it to stabilize, then release.

The first time I went straight for a turn, the robot immediately triggered a protective stop and crouched down motionless. That's a safety policy; just restart and it's fine. So the order must be small to large—no rushing.

For one-to-many usage, check multiple units in the device list and then click sync. Materials say it can reach dozens; I don't have that condition on hand, only tried two following simultaneously. The movements were consistent, but you could see a tiny time difference between the two—visible to the naked eye, not serious. This was also tested on the same LAN; cross-network multi-unit sync hasn't been touched yet.

There are roughly three pitfalls: not on the same network, unnatural calibration stance, and giving too large a movement the first time. The first two are configuration issues, the third is a mindset issue.

After learning this, the next step can be trying cross-public-network—robot placed on another network, person operating from here, to see how much latency drops. This time only connection and calibration were run through on the LAN; the remote part is still blank, and that's exactly what embodiment avatar really needs to solve—firefighting, mining areas, high-altitude maintenance—these jobs where people shouldn't be on site in the first place.