sdallagasperina

10 เดือนที่ผ่านมาdiscuss

I see the LLM not as the one giving direct commands, but as suggesting a path. An arbitration layer should always check whether that suggestion is safe, and if it isn’t, the system should fall back to a deterministic, well-tested behavior. That way you get flexibility without ever compromising safety.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

Great point, I believe safety has to be layered. The real challenge is deciding which agent is responsible for judging whether a command is safe to execute. For instance, MCP could enforce permissions, rate limits, and safe defaults, while the ROS stack could add motion constraints, watchdogs, and velocity/force caps, all backed by physical interlocks as the final safeguard.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

Thanks for the comment! We see the future of human–robot collaboration as being closely tied to how LLMs can translate verbal instructions into higher-level, longer-horizon commands. The goal here isn’t to “code faster,” but to make things like diagnostics and behavior tree design more intuitive and accessible — both for developers and for operators who don’t want to dive deep into ROS internals.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

Exactly! With MCP, we’ve started to imagine a workflow where instead of digging through logs, you just ask “why isn’t the robot responding?” and get guided through the diagnostics. No need to memorize every ROS command.

This isn’t just a bridge between LLMs and robots, it can also be a bridge between non-developer operators and the ROS ecosystem.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

This is a huge point. Even if you write the perfect kernel, the reality is that XR hardware is tied up in vendor drivers and NDAs. Without access to those, you end up reinventing the easy part while still locked out of the hard parts. Curious if the team has a strategy for this, or if the kernel is mainly a sandbox for now.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

I had the same reaction! “legacy baggage” is a vague phrase. Without examples (like specific subsystems or bottlenecks), it’s hard to see how a custom kernel helps XR more than existing lightweight or RT kernels. If the team has benchmarks or case studies where Linux/Android gets in the way, that would make the argument much stronger.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

Really ambitious project, but I’m not convinced building a brand-new kernel is the best way to tackle XR. The hardest problems in AR/VR usually aren’t about the OS itself, but about latency, hardware drivers, and closed SoCs.

Saying “we’re removing legacy baggage” sounds nice, but it’d be more convincing if you could point to concrete examples where existing systems like Linux actually get in the way. Otherwise this risks becoming a never-ending side quest instead of a platform people can realistically use.

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

The price point is definitely interesting: $3k without compute feels high if you compare it to hobbyist kits, but I think the target here is more for researchers/early-stage startups who want a standardized AI-native robotics dev kit out of the box. What I find valuable is that it’s open-source and modular, which could help reduce integration overhead (often the hidden cost that dwarfs hardware).

sdallagasperina

10 เดือนที่ผ่านมาdiscuss

Great question! I’m one of the collaborators on the project. Right now, the MCP server doesn’t “correct” hallucinations itself, but it enforces a strict tool interface: the LLM can only call valid ROS topics, services, or actions that actually exist and that are explicitly exposed as safe to use. This information is provided through the MCP, so if the model hallucinates a command, the call simply fails gracefully rather than executing something unintended.

For more advanced use cases, we’re also thinking about adding validation layers and safety constraints before execution — so the MCP acts not just as a bridge, but also as a safeguard.

comments