u/SynriaRobotics_01

We've been putting together real data collection for robot-arm manipulation, and the gap between recording one demo and actually having a usable training sample turned out way bigger than I expected.

Here's the setup. A teaching arm, the leader, is moved by hand by the operator. A follower arm copies its motion joint by joint, and cameras record the whole thing. Every clean pass counts as one collected demo. For our test the task was picking up a rubber duck and placing it into a marked mold.

The stuff that didn't make the cut, the usual suspects:

- The grip slips mid pull. The follower tracks fine, but the grasp was never solid, so the trajectory teaches the wrong thing.

- Occlusion. When the arm extends it blocks the camera, and that stretch of frames is just gone.

- Inconsistent speed. Early passes were slow and careful, the later ones rushed. The data ends up describing two different tasks instead of one.

For contact-rich work, cloth, placing parts into a tight mold, this bites harder. Simulation still doesn't get the physics right, so you can't just synthesize a clean replacement. You collect for real, and then you throw most of it out.

How about you all? Filter first, or just throw more demos at it and let the AI figure it out?

Right now we still collect by hand up to a threshold, then the AI training runs. Roughly 60 to 120 demos each time.

Wanted to share what we've been working on: the Alicia-M, a semi-humanoid robot we built, running VR teleoperation. The operator wears a VR rig, moves naturally, and the robot mirrors the motion. No scripting, no coded trajectories. In the demo it picks up a cup, pours, and sets it back.

The part worth talking about: people assume the hard problem is the grasp. It isn't. The hard part is that one good demo doesn't generalize. Move the cup two inches and the same arm motion that worked now overshoots the wrist angle, drifts the trajectory, and the pour runs too fast. Same intent, different outcome.

That's the thing teleop surfaces clearly: robot control is less "repeat a perfect move" and more "adapt to where the world actually is." Shift the cup and the wrist angle, arm path, and pour all need to change with it. VR makes that legible because you feel the mismatch between your motion and the robot's in real time.

We're treating these human demos as seed data for embodied learning, not just a control scheme. Curious how others here handle the demo-to-policy or sim-to-real gap. Are you collecting teleop demos, or going straight to reinforcement learning?

Happy to answer questions about the rig, the kinematic mapping, or why we went semi-humanoid instead of full.

Hey everyone,

Just wanted to highlight a community pull request we received on our LeRobot fork (v6.1.1-beta branch). A user identified and fixed two issues in lerobot-teleoperate:

Bug 1 — Missing alicia_d_leader in teleop.type: When trying to teleoperate with an Alicia-D Leader + Alicia-M Follower pair, the CLI would reject alicia_d_leader as an invalid choice. The fix adds it back to the valid options list in lerobot_teleoperate.py.

Bug 2 — Missing teleop.directly_controls_robot support: When the teleoperator directly controls the robot via hardware (e.g., the leader arm is physically connected to the follower), the computer shouldn't re-send the action command — otherwise it duplicates. The flag existed in config but wasn't actually implemented in the teleoperate script. The PR adds the skip logic.

PR here:

https://github.com/Synria-Robotics/lerobot/pull/10

Big thanks to the contributor for the clean, well-documented fix. If you're running v6.1.1-beta with Alicia hardware, this PR is worth watching. And as always, issues and PRs are welcome!

I spent the last year building a 6-axis desktop robot arm from scratch, and inverse kinematics was the hardest concept for me to internalize. Here’s what finally helped.

Forward kinematics felt relatively straightforward. Given the joint angles, I could compute the end-effector pose by chaining homogeneous transformation matrices using a consistent frame convention. Denavit–Hartenberg parameters made the process systematic, and I had the basic idea working within a weekend.

Inverse kinematics was much harder. Given a desired end-effector pose, which joint configurations reach it? There may be multiple solutions, or none at all. The elbow-up vs. elbow-down configurations alone took me days to understand and debug.

Three things finally made it click:

1. Build geometric intuition before deriving equations.​

I watched each joint move independently in a 3D simulator. In my arm, joint 1 mainly changes the base azimuth, while joints 2 and 3 determine the reach in a radial-height plane. Because the arm uses a conventional wrist structure, joints 4–6 mainly control orientation. Seeing the workspace gave the equations a physical meaning.

2. Start with a 2-DOF planar arm.​

Forget the 6-axis arm for a week. A simple 2-link arm makes the cosine-law derivation and the elbow-up/elbow-down solutions easy to visualize. Then add a third link while explicitly accounting for end-effector orientation, and add more joints one at a time.

3. Numerical methods aren’t cheating.​

I implemented a small Jacobian-based solver in Python. It worked surprisingly well, although it still depended on the initial guess and could struggle near singularities or unreachable targets.

My biggest mistake was trying to derive closed-form IK equations before understanding the workspace geometry. If you can’t visualize where the arm can reach, the equations feel almost meaningless.

What approach worked for you when learning IK? Did you start with analytical methods, numerical methods, or a combination of both?