Stephen James

𝗔𝗳𝘁𝗲𝗿 𝟭𝟬+ 𝘆𝗲𝗮𝗿𝘀 𝗶𝗻 𝗿𝗼𝗯𝗼𝘁 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴, 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?

Wiring harness routing is one of those jobs that looks simple and isn't. Flexible parts, tight tolerances, no two door frames quite the same. It's exactly the kind of task that breaks scripted automation and separates a real manipulation system from a demo. Great to see the @ABBRobotics CRB 15000 being used with @Neuracore_AI put to work on it. This is the proving ground that matters. #PhysicalAI #Robotics #Manipulation #RobotLearning

Source:costream-simple.github.io Paper: arxiv.org/abs/2606.26423

Seating a GPU into a PCIe slot sounds like a trivial task for a robot. It isn't. Most manipulation systems can't do it at all. You either get a rigid pipeline that breaks the moment reality drifts from the plan, or a single policy trying to absorb every task at once. Both produce a clean pick-and-place demo. Neither holds sub-millimeter precision while reacting to contact in real time, and that second problem is the one an assembly line actually cares about. CoStream doesn't pick a side. It runs three separate behaviors, each aimed at a failure mode the others can't see. A semantic behavior grounds task-frame anchors from an LLM and VLM, handling perceptual drift. A predictive behavior pulls a motion prior out of a generated video, handling contact ambiguity. A reactive behavior closes a tactile and force loop, handling in-hand slip. What makes this work is that the behaviors stay separate. Nobody bolts tactile sensing onto a policy and hopes it learns to use it. Each behavior runs at its own rate and gets composed by right-multiplication into one pose command at every control step. That composition is the difference between a system that reacts to contact and one that just reads a sensor. The results are stark. On precision assembly, GPU and drill insertion, CoStream scored 14/15. VoxPoser and π0.5 both scored 0. On everyday tasks it climbed from 3/15 under π0.5 to 14/15. Strip out the reactive behavior on its own and drill insertion collapses from 15/15 to 3/15. I read this as an architecture result, not a scale one. A monolithic policy buys broad coverage. It doesn't buy sub-millimeter compliance, and waiting on more data doesn't seem to close that gap. Contact wants its own dedicated channel rather than being absorbed into one network alongside everything else. Worth your time if you work anywhere near real assembly. [Paper and project page link in comments] #Robotics #PhysicalAI #RobotLearning

Paper: arxiv.org/abs/2607.01212 Project page: dannymcy.github.io/furniturevla

Furniture assembly is the task everyone name-drops and nobody actually attempts at real scale. Every demo I have seen is a scaled down IKEA leg or a single arm on a toy chair. This paper does it properly, real scale, bimanual, up to 7 subtasks and 1,550 control steps per episode, and it is validated on a real Kinova Gen3, not just in sim. That real-robot number is the one that matters: only a 16 percent drop on the hardest task going from simulation to hardware. That is a small enough gap to take seriously, and it did not happen by accident. They built a VR teleoperation rig specifically for coordinated dual-arm collection, because generic single-arm teleop setups do not capture the coordination real assembly needs, and the model predicts a continuous progress signal alongside the action chunk rather than a discrete subtask label, letting it auto-transition and catch drift before it compounds into total failure. The simulation ablation is what got them there, 48 to 80 percent over baselines, with another 21 points from their perception and control design study alone, but that is groundwork, not the headline. Watch the video, there is a clip of the robot misgrasping the seat panel, reopening the gripper, and regrasping on its own. That is not scripted recovery behaviour, it emerged from training, and it emerged on hardware. Excellent work from the team from @merl_news, with Oxford and UNC Chapel Hill Clinical Laboratory Science. Video and project page in comments. #Robotics #Manipulation #VLA

This is the part of the job I find most interesting. Cable manipulation has one of the toughest sim-to-real gaps in robotics. Cables have near-infinite degrees of freedom, tangle unpredictably, and their dynamics are notoriously hard to model precisely. Even the best simulators leave a real gap, and closing it takes real-world data. Excited to share more as the team keeps pushing forward with our new @Universal_Robot hardware.

Paper: arxiv.org/abs/2606.31682 Blog: habit-dataset.github.io

Most manipulation datasets are collected in isolation. Most manipulation tasks are not. The demos you see online prove the robot can do the task. They don't prove it can do the task with a person in the workspace. Those are different problems, and most training data only covers one of them. KAIST just released HABIT, and it's built to close exactly that gap. 10,563 episodes. A co-present human in every single one. Three roles: Collaborator, Coworker, Supervisor. Each role isolates a different failure mode: precondition violations, collisions, gesture-following errors. What I like here is the method. They didn't just put a human in frame and call it interactive data. They defined the roles first, then structured collection to force the specific behaviour each role demands: yielding under Coworker, gesture grounding under Supervisor, spatiotemporal sync under Collaborator. That's the difference between data that looks realistic and data that's actually diagnostic. The results back it up. Fine-tuning π0.5 on HABIT beat a matched robot-only baseline on every comparable task, with the biggest gains on Coworker, where reactive yielding resolves path conflicts. GR00T N1.6 shows the same pattern at lower absolute numbers, which tells you the gain is coming from the dataset, not the architecture. Mid-training on HABIT compounds too: 100 task-specific demonstrations after mid-training beat 200 demonstrations of direct fine-tuning on shelf-cleaning. I've said this before about sample efficiency and I'll say it again about coordination: this isn't a scale problem, it's a data problem. If human presence changes behaviour this cleanly, a human-absent dataset isn't incomplete, it's blind to the failure modes that actually matter once the robot leaves the cell. Robot-only pre-training gets you competence. It does not get you coordination. The next generation of training data needs an independent human moving through the scene unpredictably, not another 10,000 episodes of the same skill performed alone. [Paper and dataset link in comments] Congratulations to the team at KAIST on the release. #Robotics #PhysicalAI #RobotLearning

This is what enterprise robot-learning infrastructure looks like. Behind the scenes, our integration tests run around the clock so our users don't have to think about whether things will work.. they just do. Many of the people relying on us are large enterprises running mission-critical workloads. For them, downtime isn't an inconvenience, it's not an option. That standard is exactly what we build to: every test, every check, every safeguard exists so the systems our customers depend on stay up. Reliability isn't a feature. It's the foundation.

Data scarcity. Sim-to-real gaps. Deployment timelines that stretch into months. Different people, different companies, the same bottlenecks every time. It's the exact problem we started @Neuracore_AI to solve. We're working with robot learning teams on exactly these challenges, so if that sounds like yours, get in touch or drop me a message directly.

The most common thing the team heard at @ieee_ras_icra: "we'd love to take on more learning-based projects, but we can't carry the deployment risk." That risk is exactly what we built @Neuracore_AI to remove. If that sounds familiar, drop me a message.

Looking to find us at @ieee_ras_icra? We’re right at the entrance to hall B at booth S006. If you’re a system integrator, or looking to go from demo to deployment faster than ever, come and chat with the team!

Great to see the @Neuracore_AI team in action at our first ever @ieee_ras_icra! If you're there this year come by and see the platform in action for yourself!

Neuracore is exhibiting at the @ieee_ras_icra 2026 in Vienna, Austria. Join us to see how robotics teams are eliminating the 80% of engineering time currently spent on data pipelines instead of robot learning. Come discuss the infrastructure bottlenecks killing your transition from lab prototypes to distributed fleets. Meet the team. See live demos of data recording, visualisation, training and deploying model using our infrastructure. Booth S006, June 1-5, 2026 | VIECON in Vienna, Austria #Neuracore #ICRA26

Thanks to the STIQ team for hosting last night. It was great to share what we’re building at @Neuracore_AI and discuss some of the harder questions around where robotics is headed. Also great to be sharing the stage with All3, @recycleye , and @dexoryHQ. If you’re exploring VLA, VLM, or robot learning deployments, my DMs are open - always happy to chat. #Robotics #RobotLearning #UKRobotics #STIQROBOTICS

That's a wrap on our inaugural sponsored hackathon! Congratulations to the winners of the "Best Use of Neuracore" award at the Oxford Edge and Oxford Artificial Intelligence Society Hackathon this weekend. Well done to Sarthak Das from the robot learning team at Neuracore for his effort on-site supporting teams and presenting the award!

Link: arxiv.org/abs/2512.19562 Project: martin-sedlacek.com/realm/

Most simulation benchmarks for VLAs cannot tell you whether their numbers map to reality. REALM can: p < 0.001 correlation with real-world rollouts across 7 manipulation skills and 5 perturbations. The sim-to-real gap has been the central reason I have argued for collecting real data wherever possible. Most simulation benchmarks tell you something, but you cannot tell whether that something maps to reality. REALM, from Martin Sedlacek and the team at CTU Prague and Amsterdam, takes that problem seriously. The team built a simulation environment designed to correlate with real-world performance, and then validated it. Pearson values close to identity on task progression curves. Attention maps from π0 show 0.85 cosine similarity between matched real and simulated frames. They did not skip the validation step. They led with it. That changes what the simulation results actually mean. Across 15 perturbation factors covering visual, semantic, and behavioural variation, π0, π0-FAST, and GR00T N1.5 all show noticeable performance drops under semantic perturbations despite their internet-pretrained VLM backbones. All show sensitivity to camera viewpoint despite training on DROID's unusually diverse viewpoint distribution. The hardest axis of generalisation is across objects and their properties, not across skills. Reliability under perturbation is low across all three models. If the sim correlates with reality at the level REALM demonstrates, these are not simulation artefacts. They are real failure modes that real teams should be planning around. Two things this tells us. Validated simulation has a role in evaluation that it does not yet have in training. The cost of running thousands of perturbed rollouts in the real world is prohibitive. If REALM's correlation holds up across more task families, sim-based evaluation could become a serious tool for surfacing failure modes that ad-hoc real-world testing misses. The failure pattern across all three tested models also points back at the same place it always does. Pretraining buys you semantic grounding and skill primitives. It does not buy you robustness. The next generation of training data needs to focus on demonstrations where the object, scene, and viewpoint move underneath the skill, not on more demonstrations of the same skill on the same object. Paper link in comments.

There's been some exciting new features added to @Neuracore_AI this month! Head to our YouTube to see more: youtu.be/kjQ8RWJExb4

Excited to have @Neuracore_AI powering in this weekends Hackathon hosted by The Oxford Edge and @OxfordAI!