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.

1. 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.

1. 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?

Built my first robot still have a lot to learn. Open to any advice on how to improve look of wires. When I built this, I lost two of the baby screws for the knee of the robot so it topples over in the middle of its dance. But it was fun to build and I learned a lot. Also, open to any ideas on other kits or sites where I can create more stuff myself following tutorials and things like that

Tatum Robotics originally expected to adapt an existing robotic hand for DeafBlind users.

The problem was that American Sign Language requires precise finger positioning, while many standard robotic hands rely on rigid linkages that can create pinch points. That does not work when a person needs to hold the hand directly to receive tactile signing.

The team instead developed a compliant, tendon-driven hand with additional degrees of freedom. DeafBlind users can place their hand on the robot and receive letters through movements designed to closely match a human hand.

Hi everyone!

I've been building a small mobile robot that uses a smartphone as its onboard computer. The phone handles the camera, networking and user interface, while an Arduino controls the motors and peripherals.

Current features:

📱 Smartphone onboard

🌐 Browser-based remote control

🎥 Live video

💡 LED lighting

🚨 Experimental security mode

🤖 BLE Follow Me (in progress)

This video shows one of today's prototype tests. Some things worked, some didn't... and some moments were just funny. 😄 That's real robotics development.

The next version will focus on:

quieter drivetrain,

better cable management,

docking station,

modular accessories.

I'd really appreciate your feedback and ideas for V2.

Two smartphones. One drives. One controls.

I really like LeRobot because of the abstraction that lets you record camera frames and proprioception at different frequencies and still get them aligned, a standardized dataset format, and CLI for training, evaluating, recording, and rollouts, with policies just being a plug and play flag value in their scripts

But not sure if its optimised and reliable for real world deployments

- If I want to train and deploy an embodiment I'm actually building (not SO-101/Aloha/Koch), I have to implement my own robot/motor/camera classes from scratch which is expected, but it does mean I'm not really getting LeRobot's abstractions for free, I'm reimplementing their interfaces every time.

- I wanted to run MolmoAct2 through their async inference setup, and it turns out async is only supports a fixed list of policies (ACT, SmolVLA, pi0, pi05, GR00T). MolmoAct2 isn't in that list, so I ended up writing my own runtime for it. This makes me dependent on LeRobot's support. I will eventually be building my own finetuned policies which I will be running on my specific embodiment

- The whole ecosystem is scoped to learned policies / VLAs. There's nothing for classical motion planning (MoveIt-style), grasp planning or segmentation before grasp, or a navigation/SLAM stack. I would ideally want a hybrid system where some dexterous tasks are being done by learned policies, but high volume, low variability tasks can be programmed without foundational models?

- I see companies like https://www.mimicrobotics.com/blog/solving-dexterity-a-full-stack-approach saying that they evaluated ROS2 and LeRobot's IPC layer for their real time control loops and found both fell short on latency and jitter, so they built their own zero copy middleware instead. They made the same call on telemetry: logging/recording has to be async and can't compete with the control loop for cycles, so they built a dedicated system for that too rather than bolting logging onto whatever was already there.

Curious to know if anyone tried using LeRobot, and either stuck to it or replaced it with their own stack?

I got HM-LD1 working for obstacle avoidance. and l will open-source once code is ready.my drone drifts backward slightly after I release the sticks.Anyone else seen this?

Most humanoid robots in factories are still being tested in pilot programs, and many are only reaching 20% to 50% effectiveness.

A3 President Jeff Burnstein told Forbes that manufacturers are not focused on whether a robot looks human. They want systems that are reliable, affordable and safe. Safety remains a major barrier because there is no dedicated humanoid robot safety standard yet, and most systems currently operate behind fences or away from workers.

Burnstein expects humanoids to find roles in factories, warehouses and logistics, but alongside traditional industrial robots, mobile robots and collaborative arms rather than replacing them.

The article also covers labor shortages, manufacturing competitiveness and the growing robotics gap between the U.S. and China.

Hey guys.

I am building a platform where you can have virtual rooms and I am currently looking for people who have skills in robotics. Virtual room allows connections to remote real world devices.

I need to find a person who can build or rent me a robot in EU (I am from Finland) or has a robot SaaS and needs to scale operations beyond 10+ robots.

Pilot Specs:

- Can drive 5-30km on one charge and can carry around a 1-4 kg payload.
- or/ a boat robot with a bit similar specs.
- can be drone too.

I have this idea where you could overlook and control 100+ robots from a single virtual room.

So, if there are like-minded people or this resonates then let me know.

Producing several future actions at once reduces how often a large policy has to run. It also commits the robot farther ahead from one observation.

The asynchronous inference described for LingBot-VA 2.0 is a timing choice, not the same thing as buffering a long action chunk. Combining both can leave the low level controller following commands that were generated before an unexpected contact.

Longer chunks make sense in free space; near contact, the horizon needs to shrink. The metric is interruption latency: how long the robot continues the old plan after a new observation says to stop. Actions per second describes throughput, not that safety property.

Hi everyone,

I’m Marvel, a computational neuroscientist at Cambridge and founder of Synexis.

We’re building infrastructure that sits between AI policies (VLA/foundation models, teleoperation, planners) and robot controllers.
Rather than replacing existing stacks, Synexis validates, constrains, and translates commands before execution to provide deterministic safety guarantees and reproducible execution across different robot platforms.
I’m currently looking to speak with robotics companies, research labs, or teams working on manipulation, humanoids, or industrial robotics that are deploying AI-driven control.

I’m interested in learning:

What are your biggest deployment bottlenecks today?
Where do command failures or unsafe actions occur most often?
Would a deterministic command-assurance layer solve a meaningful problem for your team?

If this sounds relevant or if you’d simply be willing to provide technical feedback I’d really appreciate a conversation.

Feel free to comment below or send me a DM.

Thanks!😁

Our sensor board has a mikroBUS socket, which means 1,900+ MikroElektronika Click modules fit into it: every category from IMUs to gas sensors. On paper, we support all of them. In practice, "supported" means physically compatible, and validated means someone plugged it in and watched real data come out. We've done that for seven. The rest is a queue. Going through it by hand means someone's whole job becomes plugging in Clicks, forever, so we're thinking about a harness that brings up an unknown board, figures out what it speaks (I²C, SPI, UART, analog), and confirms it's alive without a human at a scope.

If you've validated hardware at this kind of scale, device farms, protocol auto-detection, anything, how did you do it?