𝗔𝗳𝘁𝗲𝗿 𝟭𝟬+ 𝘆𝗲𝗮𝗿𝘀 𝗶𝗻 𝗿𝗼𝗯𝗼𝘁 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴, from my PhD at Imperial to Berkeley to building the Dyson Robot Learning Lab, one frustration kept hitting me: 𝗪𝗵𝘆 𝗱𝗼 𝗜 𝗵𝗮𝘃𝗲 𝘁𝗼 𝗿𝗲𝗯𝘂𝗶𝗹𝗱 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗼𝘃𝗲𝗿 𝗮𝗻𝗱 𝗼𝘃𝗲𝗿 𝗮𝗴𝗮𝗶𝗻? 𝗧𝗵𝗲 𝗽𝗮𝘁𝘁𝗲𝗿𝗻 𝗜 𝗸𝗲𝗽𝘁 𝘀𝗲𝗲𝗶𝗻𝗴: • New robotics team starts • Spends 6 months building data collection pipeline • Spends another 3 months debugging synchronization issues • Finally starts collecting task-specific data • Realizes their infrastructure choices limit their flexibility • Starts over 𝗧𝗵𝗶𝘀 𝗶𝘀 𝘁𝗵𝗲 𝘄𝗵𝗼𝗹𝗲 𝗽𝗼𝗶𝗻𝘁 𝗼𝗳 𝗿𝗼𝗯𝗼𝘁 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴: Robot learning is fundamentally data-driven. Whether you're picking strawberries or assembling electronics, the core infrastructure needs are identical. That's actually why I was so interested in pursuing data-driven robotics over a decade ago. 𝗬𝗼𝘂 𝗮𝗹𝘄𝗮𝘆𝘀 𝗻𝗲𝗲𝗱: • Multi-sensor data synchronization across different frequencies • Flexible storage that works with future algorithms • Visualization tools to understand your data • The ability to experiment with different temporal resolutions • Robust logging that captures everything you might need later The trend towards AI in robotics is growing, with robots needing to process and analyze large amounts of sensor data to manage variability and unpredictability in real environments. 𝗕𝘂𝘁 𝗲𝘃𝗲𝗿𝘆 𝘁𝗲𝗮𝗺 𝗯𝘂𝗶𝗹𝗱𝘀 𝘁𝗵𝗶𝘀 𝗳𝗿𝗼𝗺 𝘀𝗰𝗿𝗮𝘁𝗰𝗵. Imagine if every web developer had to build their own database, web server, and deployment pipeline before writing their first line of application code. 𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝘆 𝗜 𝗳𝗼𝘂𝗻𝗱𝗲𝗱 𝗡𝗲𝘂𝗿𝗮𝗰𝗼𝗿𝗲. Instead of every robotics team spending months on infrastructure, we provide the common tools that let you go from "I have a robot" to "I'm shipping intelligent robot behaviors" in days, not months. 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗶𝗻𝗻𝗼𝘃𝗮𝘁𝗶𝗼𝗻 𝗶𝗻 𝗿𝗼𝗯𝗼𝘁𝗶𝗰𝘀 𝘄𝗼𝗻'𝘁 𝗰𝗼𝗺𝗲 𝗳𝗿𝗼𝗺 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗿𝗲𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗽𝗹𝘂𝗺𝗯𝗶𝗻𝗴. 𝗜𝘁'𝗹𝗹 𝗰𝗼𝗺𝗲 𝗳𝗿𝗼𝗺 𝘁𝗲𝗮𝗺𝘀 𝘄𝗵𝗼 𝗰𝗮𝗻 𝗳𝗼𝗰𝘂𝘀 𝗲𝗻𝘁𝗶𝗿𝗲𝗹𝘆 𝗼𝗻 𝘄𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝘁𝗵𝗲𝗶𝗿 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝘂𝗻𝗶𝗾𝘂𝗲. Robot learning shouldn't be bottlenecked by infrastructure. It should be bottlenecked by creativity. What's the longest you've spent building infrastructure before getting to the actual robotics problem you wanted to solve?

Some robot tasks are basically impossible for a human to teleoperate cleanly. Not hard, impossible. Carrying a plate across a table with two independently controlled arms, for instance. Zero percent success rate, no matter the operator. GLIDE takes an interesting approach to this. An LLM reads the task, predicts where a human will fail, and writes a filter that sits between commands and robot to prevent it. Watches the data, catches what's still failing, rewrites itself. Same task, 0 to 70 percent. Two others go from 10 and 0 up to 90 and 90. Keep the guardrail running at deployment and a policy that barely worked alone jumps from 0 to 60-70 percent too. A good reminder that a lot of "the robot can't learn this" is actually "no human could demonstrate this in the first place." Source: guardrail-policy.github.io/

Most robots need hundreds of demonstrations to learn a task, then need hundreds more the moment anything about that task changes. This one needed one, and then just kept adapting. The system is VLBiMan++, out of @ShenzhenUni and @DexForceAI. Show it a single human demo of pouring water, and it breaks the task down into reusable pieces, then uses vision-language grounding to figure out how those pieces need to shift when the situation changes. No retraining, no extra demonstrations, no fine-tuning. The range of what "changes" means here is the part worth watching. It's not just moving a cup to a new spot on the table. The same one-shot prior carries across pouring, reorienting and unscrewing a cap, spoon and funnel tool use, zipping a pen bag shut, coiling a loose cable, folding a towel. Rigid objects, articulated ones, deformable ones, all handled by the same underlying approach, each needing its own way of tracking what "the object" even means as it changes shape. Then there's the embodiment jump. Skills learned on one dual-arm platform transfer directly to a completely different humanoid-style dual-arm robot, plugging in a pen, handing off an object, pouring, unscrewing, all without a single new demonstration on the new body. And to check it isn't just lucky on the first try, they ran the same task, uprighting a bottle knocked onto its side, twenty times in a row on the new platform and it held up. Every added axis here (new tasks, new objects, new scenes, new robots) is a dimension where most systems need fresh data. This one just needs to reason more carefully about what actually changed. Video: hnuzhy.github.io/projects/VL… Paper: arxiv.org/abs/2609.14310

Link to their blog post: rhoda.ai/research/scaling-we…

Rhoda AI checked whether scaling web video pretraining actually helps real robots, using a real customer task. Unpacking 10kg boxes of bearings and sorting the packaging. Turns out yes. Bigger models do better, more pretraining compute does better, and the compute gap is widest when you don't have many robot demos. Refreshing to see a company display this amount of rigour. Rare these days.

A robot's camera predicts the future to decide what to do next. The problem is that prediction takes time, and time is the one thing a robot moving in the real world doesn't have to spare. That's the tension a team from @BAAIBeijing and collaborators went after with World Action Models, systems that use video generation to imagine what happens next before deciding how to act. The video model builds that prediction through several rounds of denoising, and each round adds latency to the control loop. The obvious fix is to cut it down to one round. The team found out why that quietly breaks things. Watching the denoising process closely, they noticed the background of a scene sharpens almost immediately. The gripper, the object it's about to touch, and how the two interact stay blurry until several steps later. Cut the process short and you keep a crisp picture of the room and lose exactly the part the robot needed to act on. Their fix, called DIDO, trains a single denoising step to hold onto that missing detail. A slower four step model acts as a teacher, and the one step model is explicitly guided to track the object, the gripper, and their interaction directly, with extra supervision pointed at exactly those regions rather than the whole frame. A pruning step then spends compute where the scene is actually changing and compresses the parts that aren't. The result is a model that predicts an action in 384 milliseconds instead of 562, while doing just as well or better on manipulation benchmarks; 99.0 percent on LIBERO, and the strongest score among methods with no embodied pretraining on RoboTwin. It also held up on a real Galbot G1 arm across four tasks, including with clutter and repositioned objects added in. It's a good reminder that not every shortcut is free. Cutting a process down to save time can end up cutting away the part that made it work in the first place, and the only way to know is to look closely enough to see what's actually happening at each step. Paper: arxiv.org/abs/2609.15570 Project page: loveju1y.github.io/DIDO/

Try holding your arm perfectly still for two minutes while someone else moves it into a sleeve. Now imagine doing that if holding still wasn't something your body could easily do in the first place. That's the gap in a lot of robot-assisted dressing research, which usually assumes a static arm. A paper currently under review takes this on directly. It fuses visual and force feedback into a single policy, trained first in simulation and then fine-tuned with real-world data, so the robot adapts to natural, uncooperative arm movement instead of requiring the person to stay put. It also handles long-sleeved garments, which add friction and occlusion that shorter sleeves don't. The results are the part that stands out. Tested across 12 participants and 264 real dressing trials, the system successfully dressed an average of 85 percent of each person's arm length, despite the arm moving throughout. This is the same principle behind a lot of the manipulation research worth watching right now. Fusing force and vision into one policy, rather than treating them as separate systems bolted together, tends to be what makes robots reliable outside a controlled lab setting. It's still under review, so treat the numbers as early rather than final, but the direction is one worth following. Paper: arxiv.org/html/2609.04759v1 Source: anonymous.4open.science/w/dr…

RT @Neuracore_AI: There's about $50-60 billion worth of electric motors in use in industrial robotics today. To make the more extreme predi…

Most of the robots sitting on factory floors right now are more capable than the tasks they're being used for. I've spent over a decade in robot learning, PhD at Imperial, postdoc at Berkeley, building the Dyson Robot Learning Lab, and the pattern hasn't changed. Every major step, from early imitation learning to today's VLAs and diffusion policies, was deployable years before most teams picked it up. The capability was never the bottleneck. The hardware in front of most companies right now can already do far more than it's doing. What's missing isn't a robot arm or a breakthrough model, it's the data and infrastructure to teach the hardware they already own new skills. That gap is what's costing teams the opportunity in front of them. Not a lack of technology, a lack of the layer that turns existing hardware into new capability. That's the layer @Neuracore_AI builds. Want to see what your hardware could actually be doing? Head to the comments to book in a demo with our team.

Teaching a quadruped robot to push an object it can't grasp is a hard RL exploration problem. The task reward stays at zero until contact happens, so a standard single-critic PPO ends up optimizing smoothness and energy penalties instead, and never finds contact at all. Members from @Unipisa, ETH Zürich & @nvidia address this with a separate exploration critic trained on a dense contact-seeking reward, guiding the end-effector toward candidate contact points, then decaying its weight over training so the policy shifts from contact-seeking to task-optimal once the physics has actually been found. Candidate points come from a general-purpose grasping algorithm, so the approach generalizes across object geometries without hand-tuning per task. Validated on a real quadrupedal mobile manipulator transporting chairs, transferring zero-shot to unseen IKEA furniture, recovering from failed contact attempts, and remaining stable under loads beyond the robot's rated capacity. A clean approach to a common problem: rather than hand-shaping one messy scalar reward, split exploration from task performance and let one decay into the other. Paper: tolomeis.github.io/contact-g… Project page: tolomeis.github.io/contact-g…

Watch the full video here: piped.video/Hq8E2aq4imU?si=Uk4z…

Skill learning is not new. At Automate Further, I briefly walked through a decade of work in this space, from early imitation learning with hundreds of thousands of grasps, through sim-to-real transfer, to reinforcement learning agents that can start improving from just a handful of demonstrations. This has been building for years, and it’s deployable today to solve real-world problems. Head to the comments for a link to the full talk. #PhysicalAI #RobotLearning

Building aircraft at scale means solving the same automation problems everyone else does, just with a lot less room for error. At Automate Further, Marco Chacin, Head of Actuators and End Effectors at @Airbus, spoke about the realities of deploying robotics in aerospace manufacturing: competing for robotics talent against tech companies, and working within strict ISO and regulatory standards to do it safely. Watch the full talk here: piped.video/yYQnzhqjoZE?si=-Q2N… #AutomateFurther #Robotics #Aerospace

Every manufacturer asks the same question before automating: will this pay for itself? At Automate Further, Ross Lacy, Sales Director at @rarukautomation, talked through why answering that question clearly, and keeping deployment simple, matters more to UK manufacturers than any new piece of robotics tech. Watch the full talk here: piped.video/Uwnp9OYYqkY?si=yaQ3… #AutomateFurther #Robotics #Automation

"The bottleneck isn't capability. The bottleneck is adoption." That's the case Laurie Barnes MIET, CTO of @theautomateuk, made at Automate Further. Not a technology problem. A skills, funding and confidence problem across UK manufacturing. Watch the full talk here: piped.video/v90uIHpJ_v4?si=0P6L… #AutomateFurther #Robotics #UKManufacturing #Automateuk

Missed out on Automate Further? Our founder and CEO, @stepjamUK, took the stage to walk through the real history of robot skill learning, from imitation learning at Google to today’s VLAs and diffusion policies. The full talk is now live on our YouTube, with the rest of the speaker presentations going live throughout the week. Watch it here: piped.video/watch?v=Hq8E2aq4… #RobotLearning #PhysicalAI #Robotics #AutomateFurther

FANUC, @ABBRobotics and @Universal_Robot arms trained on @Neuracore_AI, running autonomously all day at our first event.

We just wrapped our first event at @Neuracore_AI! Thank you to everyone who turned up and kept the conversation going long after the last talk. Make sure to follow the Neuracore page to keep in the loop for more events like this, and check out the discussion over on our YouTube, coming later this week!

Excited to be hosting our first event at @Neuracore_AI HQ next week for Automate Further! If you're working in robotics, factory automation, or looking to get more out of your production lines, this is your last chance to sign up and join us. luma.com/5a584dfd

There's a nice failure mode in inference-time steering for VLAs that most methods just don't handle: they apply the same intervention at every timestep, whether or not the policy actually needs help. Generate more candidate actions, rephrase the instruction, sample from a wider distribution, it doesn't matter, the intervention runs regardless of whether the base policy was already about to succeed or about to fail. That causes two problems. First, since all your samples come from the same underlying policy, they tend to inherit the same failure modes, so extra diversity doesn't really buy you much. Second, and this one's easy to miss, steering a policy that was already about to succeed can make things worse, because you're perturbing a good action into a worse one. RL2-VLA, from teams at NUS, University of Toronto, and Singapore Technologies Engineering, treats this as a targeting problem rather than a steering problem, which I think is the right framing. The interesting part isn't the steering mechanism itself, it's knowing when not to use it. What they did first is measure something I hadn't seen isolated before: how action error scales with sample count, tracked separately for states where the base VLA is likely to succeed versus likely to fail. Under failure, more diverse samples cut error sharply, which is what you'd hope for. Under success, though, that same diversity makes error worse, and it holds pretty consistently across every steering method they tested, not just their own. So RL2 just acts on that split directly. There's a lightweight RL policy trained on the frozen VLA's own internal latents, and it composes its flow velocity with the VLA's, but only once a failure detector flags the current state as likely to fail. If the base policy already looks like it's on track, RL2 doesn't do anything, and the VLA runs untouched. On hardware, adaptive steering beat their strongest baseline by 17.5%, same RL policy, same VLA, the only thing that changed was whether the system knew when to leave it alone. Compositional steering by itself isn't new, plenty of people are doing versions of this. What's new is that knowing when to apply it turns a method that helps on average into one that helps without costing you the cases you'd already solved. Source: rl2-vla.github.io/ Paper: arxiv.org/abs/2607.26991 Nice work from the team at @NUSingapore, @UofT, and Vietnam Singapore Technologies Engineering Aerospace Co. Ltd. (VSTEA). #RobotLearning #PhysicalAI #VLA

𝗧𝗵𝗲 𝗯𝗲𝘀𝘁 𝘁𝗲𝗹𝗲𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝘀𝘆𝘀𝘁𝗲𝗺 𝗳𝗼𝗿 𝗿𝗼𝗯𝗼𝘁 𝗱𝗮𝘁𝗮 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻. The best teleoperation system for robot data collection isn't the fanciest input device, it's the one that produces clean, synchronized, trainable teleoperation data at the throughput your project needs. 𝗧𝗵𝗲 𝘀𝗵𝗼𝗿𝘁 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 • The best teleoperation system for robot data collection is the one whose data actually trains a policy, not the one with the most impressive hardware. • Judge a teleoperation data collection system on data quality, degree-of-freedom match, throughput, and trainability, not on the input device alone. • The rig you pick and the platform that turns teleoperation data into robot training should be one pipeline, not two disconnected tools. Every learned manipulation skill starts as teleoperation data: a human drives the robot through a task while everything is recorded, and those recordings become the demonstrations a policy learns from. So the question “what is the best teleoperation system for robot data collection?” is really a question about data. A rig that feels great to drive but produces misaligned, unlabeled, or low-throughput teleoperation data is a bad data collection system, no matter how good the hardware looks in a demo. Below is what actually separates a good system, and how the common rigs compare. 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗮 𝘁𝗲𝗹𝗲𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗱𝗮𝘁𝗮 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝘀𝘆𝘀𝘁𝗲𝗺 “𝗯𝗲𝘀𝘁” Four things decide whether teleoperation data for robotics is worth training on. • Data quality and synchronization. A demonstration is several streams, camera feeds, joint positions, gripper state, and the commanded action, that must share a clock. If the action at time t doesn’t line up with the exact observation that preceded it, you’ve recorded subtly mislabeled data. Clean, synchronized capture is the single most important property of any teleoperation data collection system. • Degree-of-freedom match. The interface has to give the operator enough control authority for the task. A device that can’t express a wrist roll or a delicate finger motion caps the complexity of the skills you can demonstrate at all. • Throughput. Robot skills scale with the number of good demonstrations, so how many clean episodes an operator can collect per hour, comfortably, without fatigue, directly sets how fast you can build a skill. • Trainability. The output has to land somewhere it can be searched, tagged, versioned, and filtered. Teleoperation data for robot training is only useful if you can tell which episodes went into which policy. 𝗧𝗵𝗲 𝗺𝗮𝗶𝗻 𝘁𝗲𝗹𝗲𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝗰𝗼𝗺𝗽𝗮𝗿𝗲𝗱 There is no single winner, the right rig depends on the task’s precision and degrees of freedom, and on your budget for hardware and operator time.   • Leader-follower arms (the approach popularized by low-cost rigs like ALOHA and GELLO) use a smaller replica arm the operator moves by hand while the real robot mirrors it. Intuitive, precise, and excellent for dexterous bimanual tasks, this is the workhorse for high-quality manipulation data, at the cost of a physical replica per robot.   • VR controllers track the operator’s hand pose and map it to the end effector, as in the setup pictured above. They’re cheap, fast to set up, and give full 6-DoF control, which makes them a popular general-purpose choice for robot teleoperation data collection.   • Space mice and 3D pens are inexpensive desktop devices well suited to slower pick-and-place, where full hand tracking is overkill.   • Gloves and exoskeletons capture finger and whole-arm motion for multi-finger hands and the most dexterous tasks, at the top end of cost and setup complexity.   • Kinesthetic teaching, physically guiding the robot while it records, needs no separate interface at all and suits slow, low-force tasks, though it doesn’t capture the operator’s own view. 𝗙𝗿𝗼𝗺 𝘁𝗲𝗹𝗲𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗱𝗮𝘁𝗮 𝘁𝗼 𝘁𝗿𝗮𝗶𝗻𝗲𝗱 𝗿𝗼𝗯𝗼𝘁 𝘀𝗸𝗶𝗹𝗹𝘀 Collecting teleoperation data is the easy 20%; turning it into a policy is the rest. The demonstrations feed imitation learning, where the policy learns to reproduce the operator’s actions, and often a later reinforcement-learning stage that grinds down the failure modes imitation can’t reach. But between capture and training sits the unglamorous work that makes or breaks a dataset: dropping fumbled episodes, labeling objects and camera angles, keeping streams aligned, and tracking exactly which teleoperation data went into which model version. This is the same problem all robot data collection faces, and it’s where most home-grown pipelines quietly fall apart. 𝗪𝗵𝘆 𝘁𝗵𝗲 𝗿𝗶𝗴 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗯𝗲𝗹𝗼𝗻𝗴 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿 The best teleoperation system for robot data collection isn’t really a single device, it’s the pairing of a rig that fits your task with a platform that makes the teleoperation data trainable. If those two live in separate tools, the handoff between them becomes the bottleneck: data collection for robotics turns into a folder of videos nobody trusts, and no one can answer “what changed in the data?” when a policy regresses. On Neuracore, teleoperation data from any supported rig, leader-follower, VR, glove, or space mouse, lands in one place with its streams aligned and validated on ingest. You can search, tag, and version episodes, flag bad ones, and trace exactly which demonstrations trained a given policy, so the teleoperation data you collect today is still worth training on months from now.