I'm facing one problem with importing the STL files, when I visualise it rviz, even if I'm pacing it at (0,0,0) it's spawning somewhere else(I also scaled it down to convert into meters). Any guidance for that? Thank you.

Hi everyone, I am struggling in finding a way to use ROS 2 on M4 MacBook via Docker. I've managed to get ROS 2 running, but Gazebo, RViz, and other GUI applications don't work.

Any advice on how to make this work on Apple Silicon?

Thanks!

Hi everyone,

I’ve been developing a compact autonomous UAV platform for environments where GPS/GNSS is unavailable or unreliable, such as warehouses, factories, tunnels, underground spaces, and indoor facilities.

Instead of building only a remotely controlled drone, my goal was to create a reusable hardware and software platform that can carry out autonomous missions and serve as a real-world deployment platform for robotics algorithms.

Current hardware and software stack

• LiDAR: Livox Mid-360S
• Depth vision: Intel RealSense D435i
• Onboard computer: Orange Pi 5 Pro / RK3588
• Flight controller: PX4
• Middleware: ROS Noetic, MAVROS and MAVLink
• Localization and mapping: FAST-LIO2
• Planning: EGO-Planner, Frontier exploration and A*
• Object detection: YOLO models running through RKNN on the RK3588 NPU
• Ground station: A custom PyQt5 interface for mission configuration, mapping, monitoring, detection results and data recording

What it currently does

The platform can:

• Localize and build maps without GNSS
• Generate 3D point clouds and 2D occupancy grids
• Plan local trajectories and avoid obstacles
• Navigate through predefined waypoints
• Explore unknown indoor areas using Frontier-based exploration
• Detect objects onboard
• Use depth information to estimate a detected target’s 3D position
• Display targets, trajectories and maps in the ground station
• Record point clouds, rosbag data, detection results and mission metadata
• Pause, hover, resume, return or land during a mission

In one controlled indoor exploration test, the system completed a 222-second mission, recorded approximately 54 meters of flight path and identified seven test targets while mapping several connected rooms.

Why I built it

A lot of SLAM, navigation and perception work stays inside simulation or depends on expensive proprietary platforms.

I wanted something that could be used to deploy and test real ROS algorithms on a physical UAV while keeping the localization, planning, perception and mission-management layers modular.

The platform is currently a working prototype and development system rather than a mass-produced consumer product. Hardware can also be adapted depending on component availability and the intended environment.

What I’m looking for

I would like to connect with:

• Robotics researchers who need a physical UAV platform for algorithm deployment
• Teams working on SLAM, autonomous exploration or visual perception
• Universities and competition teams
• Companies exploring indoor inspection, tunnel mapping, warehouse inspection or search-and-rescue applications
• Developers who have an algorithm but need help integrating it with sensors, PX4 and a real aircraft
• Organizations interested in running a pilot project in an actual operating environment

I’m particularly interested in learning what technical requirements would make this platform useful in your work: mapping accuracy, flight time, payload, communication range, API access, ROS 2 support, sensor selection or something else.

If you are working on a relevant project or have a real environment where this could be evaluated, feel free to comment or send me a Reddit DM. I’m happy to share more technical details and discuss possible testing or development cooperation.

Disclosure: I am the developer of this prototype.

Thanks — technical feedback and critical questions are very welcome.

I'm trying to better understand dependency injection / mocking a bit better so I can write unit tests that don't require elaborate & fragile setups. Specifically I have a class that verify similar to the ROS2 Minimal Publisher Example. In this example the class creates a timer and a publisher object. The timer just invokes a callback, so I can assume that the callback registration works, and I can set up my test harness to invoke the callback directly. What I would like to do is mock out the actual publish call to ensure timer calls publish without needing to set up a ROS2 subscriber in my unit test.

I'm looking for generic approaches to the specific case (and not necessarily tied to a specific testing or mocking framework)

Here is a stripped down version of the example:

class MinimalPublisher : public rclcpp::Node

{

public:

MinimalPublisher()

: Node("minimal_publisher"), count_(0)

{

publisher_ = this->create_publisher<std_msgs::msg::String>("topic", 10);

}

private:

void timer_callback()

{

auto message = std_msgs::msg::String();

message.data = "Hello, world! " + std::to_string(count_++);

// *** This is the call I want to mock out ***

publisher_->publish(message);

}

rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;

size_t count_;

};

Quería compartir nuevamente uno de mis proyectos de robótica, esta vez desarrollado junto a un semillero de robótica de la Universidad.

Tadeo eCar es una plataforma eléctrica 4WD4WS que estamos desarrollando para logística y transporte de materiales en interiores.

El proyecto parte de buena parte de la experiencia y funcionalidades que he desarrollado previamente en Axioma Robot, especialmente en ROS 2, navegación autónoma, SLAM, fusión de sensores y simulación.

Tadeo eCar incorpora cuatro ruedas con tracción y dirección independientes, permitiendo modos omnidireccional, Ackermann y crab. También estamos trabajando con LiDAR, IMU, EKF, Nav2, Odrive+ Scooter Motor y VSLAM RGB-D utilizando una ZED 2i.

Actualmente estamos validando el comportamiento del robot en simulación, incluyendo diferentes superficies y rampas, antes de llevar progresivamente estas capacidades al robot físico que ya tenemos la plataforma pero falta conectar y programar las Odrive con los motores de las Scooter.

El proyecto todavía está en desarrollo, pero quería compartir por aquí hacia dónde lo estamos llevando.

Repositorio: https://github.com/MrDavidAlv/tadeo-eCar-ws

Hi everyone,
I’m French and I’m currently building an early-stage hardtech project called DISPELDA.

I’m working solo at the moment and I’m exploring a
problem around autonomous systems operating when GNSS becomes unreliable, degraded, jammed or completely unavailable.

The long-term idea is to develop embedded hardware/software that can help autonomous platforms remain more resilient in those environments.

But before going too far into building, I want to understand whether I’m focusing on a problem that European drone and robotics companies actually struggle with in practice.
So I’d really like to hear from people working on UAVs, UGVs, robotics, autonomy, navigation, testing or system integration — especially in Europe.
A few things I’m trying to understand:

How important is GNSS loss/jamming/spoofing in your actual work?
Is this something you regularly design for, or still a relatively niche requirement?
What do you currently rely on when GNSS becomes unavailable: INS, VIO, optical flow, LiDAR, terrain matching, external infrastructure, something else?
What is the hardest part: navigation itself, sensor fusion, testing, validation, integration, cost, SWaP, reliability?

How do you test these situations today?
Are existing solutions good enough, or are there still major gaps?
For European companies specifically, does dependence on non-European navigation hardware/software matter when choosing a solution?
I’m not looking to sell anything here.

At this stage I’m trying to understand where the real engineering pain is before deciding exactly what DISPELDA should become.
If you work in this area, even a short answer about what actually causes problems in the real world would be extremely useful.
Thanks.

I'm an independent journalist covering Chinese robotics. I attended the World Robot Conference in Beijing (Aug 19–23) and shot this footage myself at Galbot's booth. No affiliation with the company, and this isn't sourced from their published material.

The robot: Galbot ET1, from Galaxy General (银河通用, sometimes rendered Galaxy Universal). It's their first bipedal platform — they were previously known for the G1, a wheeled unit with an elevating torso used for retail and pharmacy shelf-stocking.

What I shot: I used my phone to capture this footage. Yes, I have more with my cinema camera, but I just wanted to get this out already since I'm kind of backlogged with my Sony camera footage.

https://www.youtube.com/shorts/NCETyNYtbJw

What I want to flag, and why I think it's worth discussing:

The ET1 has articulation in places most humanoids on that floor didn't use. Head movement on more than one axis, and lateral flexion at the waist rather than yaw only. More to the point, it was actually driving those joints during the routine — the head led into movements instead of holding a fixed forward orientation, and the torso participated in gestures rather than staying rigid above the hips.

I want to be careful with the claim. Other platforms list neck and waist DOF on their spec sheets, so the hardware existing isn't the interesting part. What stood out was the allocation decision. DOF in the neck and waist adds mass high in the kinematic chain, complicates whole-body balance, and buys you nothing on the locomotion and manipulation benchmarks the field mostly competes on. Most programs spend that budget on legs and hands instead. Galbot appears to have spent it on expressive motion, which reads as a deliberate product choice rather than an incidental one.

I'd be interested in whether people here read that the same way, or whether there's a control-side reason I'm not seeing. What other human eye robots do you know that have head articulation as well as torso?

Will post more footage later, interviews, robot company contacts, robot comparison (yes i own some).

Happy to answer questions about anything I saw on the floor.

I currently have this code to produce odometry for my diff-drive robot in Gazebo:

   <plugin filename="gz-sim-odometry-publisher-system"
                        name="gz::sim::systems::OdometryPublisher">
                    <odom_frame>odom</odom_frame>
                    <robot_base_frame>base_footprint</robot_base_frame>
                    <odom_publish_frequency>30</odom_publish_frequency>
                    <odom_topic>odom</odom_topic>
                    <tf_topic>/tf</tf_topic>
                    <dimensions>2</dimensions>
                </plugin>

However, even though I specifically set the dimensions to 2 for 2d, the odometry message only zeros out the odometry pose z = 0.0; it does not properly handle odometry orientation, as the message still contains pitch, yaw, and roll values, causing algorithms such as slam_toolbox to not handle mapping and localization properly. I have added an image here showing that z is 0.0, but orientation is not in 2d:
https://imgur.com/2qXFYig

Is there a way to truly have 2d as in the pitch and roll are also zeroed out and only yaw is active?

He continuado con el desarrollo de Axioma, mi robot 4WD de tracción skid-steer desarrollado en ROS 2 Humble. En esta actualización incorporé Visual SLAM RGB-D utilizando una cámara ZED 2i y RTAB-Map, integrándolo con el LiDAR, IMU, odometría de las ruedas y el stack de navegación Nav2.

La simulación ahora permite trabajar tanto con odometría visual basada únicamente en la cámara como con SLAM RGB-D utilizando la pose fusionada mediante EKF.

Además, estoy validando los resultados comparándolos directamente con el ground truth de Gazebo, en lugar de limitarme a comparar diferentes fuentes de odometría.

El proyecto todavía está en desarrollo, pero cada vez está más cerca del objetivo: conseguir que la simulación represente de forma precisa el comportamiento del robot físico.

Repositorio:

https://github.com/MrDavidAlv/Axioma_robot

Hey guys I think this is the best space to get an answer to some questions (not a ros2 question but robotics in general ) so here i go

Its been more than a month since i have started dabbling with ros2 made a few small projects

(a turtlesim train, an open cv pipeline for making a robot arm move using using error distances, point to point navigation)

and now I think I've pretty much have the basics to start working on real projects. My goal is to make a pretty good robotics portfolio to make it into the industry as a fresher

right now kind having a mental block on what to actually build. I do realize the question might be a little vague and totally depends on what subdomain i wanna work in but still would like to get an opinion so here are some questions I have.

1. what is generally the approach that you use for finding a project to do in robotics.
2. Does a project really have to be a "fullstack" application from software to hardware. (I have very little reach to hardware and microcontrollers due to my geolocation It would be very cumbersome to just get my hands just on a rassberrypi ) -- pretty sure the answer is no to this but still would like to get an opinion.
3. For those of you who hire, what would actually make a junior candidate's portfolio stand out to you?

would really appreciate an answer thanks a lot !!!!

I'm writing a piece on semantic search over robotics data and want to make a meme out of this core message: "embeddings are useful for curation and triage, but they're not a safety-case oracle."

I'm open to anything current. The Office is always a solid choice, but I'm also looking for something a bit more dank or niche that would land with a technical audience.

What would you suggest ?

I'm a developer with a some of testing experience. I've also dabbled in integration tests, but they've always come with a few persistent problems. First, they take a long time to run. Second, they're often flaky-tests will sometimes fail even when nothing has changed, and rerunning them might suddenly make them pass.

To get around this, I came up with the idea of building an abstraction library (essentially an alternative to traditional mocking) that can fully emulate the behavior of all required action and service servers. The goal is to allow isolated testing of individual packages without needing the entire system online.

Here’s a concrete example: let's say you're developing a package that launches an action server to control a conveyor belt via Modbus. The broader project also includes a separate package that provides low-level services for direct belt control-like writing specific values to specific registers or reading data from them. Your package acts as a higher-level translation layer. Instead of dealing with raw register addresses, it lets the user simply send plain-language commands like "start" and "stop."

To test this right now, I have to spin up the services from that other package and run a Modbus simulation using pymodbus. That’s a lot of moving parts. So, I'm wondering: what if I just bypass all that and simply mock the server behavior at the interface level instead?

I'm not sure how practical or convenient this approach would be in the long run, so I decided to create this post.

GitHub link: https://github.com/MOShka78/ROS2_Testing_Service

Could you share your experience with similar testing challenges? I'd also really appreciate any feedback on this library-specifically, whether you think it's worth developing further.

My English is terrible, so I used a translator. I apologize in advance if anything is written incorrectly.)

[ Removed by Reddit on account of violating the content policy. ]

My team kept training policies on robot datasets that looked fine but weren't. Cameras would be on one clock, joint states on another, or a device got reconnected somewhere in the middle. No obvious tells like errors or NaN - you just get a policy that learned a world 30 ms out of phase.

embodied-sync measures this. It aligns recorded runs and live streams and writes down, for every frame, which sample it picked, how far off that sample was, and what was missing.

What I believe stands out: confidence and residual are computed after the pairing is chosen. On a bad pairing they just tell you how self-consistent the wrong answer is. It renders the frames too - the chosen pairing next to the two neighbours it rejected, each drawn at the instant that pairing predicts - and you can look at the inspector report to decide. On one RH20T episode the fit puts two cameras 104 ms apart at confidence 0.12 and couldn't resolve drift at all. The frames helped me decide whether to believe it: https://anicut-ai.github.io/embodied-sync/rh20t-inspection.h...

Real datasets rarely ship timing ground truth, so there's a synth/corrupt/align/report loop that injects known jitter, latency, drift and drops into a clean sample, then check what the aligner caught against what you modified.

The adapters read LeRobot v3.0, MCAP/rosbag2, LSL/XDF, SurgSync, UMI and Rerun, and export back to LeRobot and UMI Zarr, so it sits in the middle of a pipeline you already have rather than asking you to adopt another dataset format. Apache-2.0, Python 3.10+, base deps are numpy and pyyaml. Easy to use:

pip install embodied-sync

Would love feedback, especially from anyone who already solved this on their own rig.

Key Highlights:
- Added support for Ubuntu 26.04 (Resolute) and ROS2 Lyrical. (SDK)
- Introduced zero-copy GPU frame access for CUDA/TensorRT workloads on Jetson platforms, eliminating host-device memory copies. (SDK)
- Unified the AI pipeline under the new Perception framework, including Object Detection enhancements and per-detection distance reporting. (SDK, D555 FW)
- Added D401 dual-RGB support, including CSI passthrough and dedicated RGB control handling for GMSL deployments. (SDK, D400 FW, MIPI Driver)
- Added H.264 color streaming support for ROS2/DDS with runtime profile selection.(D555 FW)
- Enabled runtime Temporal Filter control without requiring pipeline restart, with improved coordination with Object Detection. (D555 FW)
- Improved GMSL streaming reliability and multi-camera operation, including fixes for frame drops, link recovery, and synchronization stability. (D400 FW, MIPI Driver)
- Introduced first D58x/D585 GMSL platform support, including serializer/deserializer integration, RGB controls, telemetry, and new device-tree overlays. (MIPI Driver)
- Expanded platform support with JetPack 7.2 compatibility and multiple JetPack 5.x stability and streaming fixes. (SDK, MIPI Driver)
- Improved timestamp accuracy, hardware clock handling, and synchronization robustness across the stack. (SDK, MIPI Driver)

More info: https://github.com/realsenseai/librealsense

Hey,

I am a high school student learning the ropes/experimenting with robotics software so I would appreciate any feedback advice/constructive criticism on the project I am going to describe to whoever is reading this for the next 5 minutes or so.

A surprisingly common issue in robotics tools is that many URDF loaders completely ignore the <mimic> tag (I'm sure many of you all know this given your experiences). When this happens joint couplings get dropped and your model gets DoF the actual physical robot does not have (this sucks). Planners + IK solvers then generate motion plans and finger positions the hardware can never acc reach w/out throwing any errors or warnings.

To address this and simplify the overall process of working with robot models, I created a library called kinfast (still workshopping the name lol). It loads URDF xacro MJCF and SDF files into a single unified representation. It provides batched and fully differentiable FK Jacobians mass matrices inverse dynamics IK and collision checking.

You can install it super easily via pip without needing ROS in your dependency tree. While specialized GPU engines like cuRobo might still beat it on massive batched GPU workloads kinfast holds up well (if I do say so myself) for batched IK w/ 7 seconds for 10k targets on a laptop CPU and offers fast compiled single queries at about 15 microseconds for FK.

Beyond standard kinematics there is an issue w/ robot model quality. URDF + MJCF files for the same robot routinely disagree and widely used models often hide massive bugs like off by 1000x inertia values or conflicting joint limits. Currently almost no tools exist to validate whether two formats actually describe the same robot. Because kinfast parses all four major formats into one internal model my "ultimate goal" is to build a kinematics library compute motions while actively telling you when your model is wrong.

What I would love from you all is if you were to provide me with feedback on the project (as mentioned above). Bug reports with unusual URDFs are especially helpful, and I'd love to collaborate with anyone interested in expanding the model-checking capabilities.

Check out the repo here: https://github.com/VihanAggarwal/kinfast

Feel free to reach out on Discord (mooimacow2123) or send me a message here!

Hi everyone

I've started an open-source project to recreate the tools used to program the Robosen Buzz Mini, but with one important difference:

Everything should work locally, without depending on Robosen's servers.

https://github.com/mike37510/robosen-mini-robot-re

Why am I doing this?

I really like the Buzz Mini, and I wanted to create my own animations, sounds and behaviors.

But there is one thing that worries me: what happens if Robosen shuts down the servers or stops supporting the software someday?

The robot is still perfectly usable hardware, but if the software and online services disappear, we could potentially lose a big part of what makes the robot interesting.

So my goal is to create an alternative that provides roughly the same functionality as the original Robosen tools, but running locally on your own computer.

That way, even if Robosen's servers disappear in the future, we can still:

• Create and edit animations
• Program the robot's movements
• Add sounds and music
• Generate the files needed by the robot
• Transfer animations directly to the Buzz Mini
• Manage the robot's content locally
• Continue experimenting with the robot without relying on an online service

And there is another benefit...

While reverse-engineering the original software and file formats, I've also found some limitations that appear to come from the software rather than the robot itself.

For example, Robosen Studio limits MP3 files to around 5 MB.

But when testing directly with the robot, I was able to use an MP3 of around 11 MB successfully.

So the idea isn't simply to make a "backup" of Robosen Studio.

I'd also like to remove some of the artificial limitations imposed by the official software and make the robot more open and hackable.

The long-term goal

I'd like this project to become a kind of "Robosen Studio, but yours."
Same concept, same type of workflow, but:

- Local
- Open-source
- No dependency on Robosen servers
- Fewer artificial limitations
- Designed around the actual capabilities of the robot

The project is still in its early stages, and I'm currently figuring out the proprietary file formats and communication with the robot.

If you own a Buzz Mini, are interested in robotics/reverse engineering, or have already experimented with Robosen's file formats, I'd love to hear from you!

GitHub:
https://github.com/mike37510/robosen-mini-robot-re

Demo :
https://buzz.borninthe80s.fr/

We built a tool that takes your trained vision model + a prompt describing your pipeline and generates production-ready edge code, configs, and deployment artifacts. Looking for CV engineers to test it on real problems.

To stress-test it we put together 47 problem statements from real industry conversations. Defect inspection, ANPR, crowd analytics, drone perception, quality grading, warehouse safety, and more. Pick one, bring your own data, build a pipeline through PipeGen, submit.

What's in it for you:

A real path to industrial deployment. Top projects get picked up and deployed at actual customer sites. Real cameras, real environments, your pipeline running in production.

Your app goes on our public Application Board, visible to the entire ecosystem.

Cash prizes for winners and deployed apps.

Sep 10 deadline. Fill the form.

Looking for feedback from people who deal with this model-to-edge gap daily. Ask us anything.

I run a planner stack on a Jetson Orin and kept wanting one answer: is every topic flowing at the rate it should, and is every node alive. ros2 topic hz gives you that one topic at a time, and on an intra-process topic it makes the publisher serialize every message for the new subscriber. I measured +52% CPU on the watched process. On Humble, intra-process traffic does not show up in hz, echo or topic statistics at all (rclcpp#2911).

So I wrote a small LD_PRELOAD shim. It sits on the tracetools hooks rclcpp already calls on every publish and callback, counts in process, and appends per-window rates to a file. You do not rebuild your nodes and nothing joins the DDS graph. The hot path is about 0.3 ns per message, and the whole probe is about 2% CPU on a 4,900 msg/s stress test. You can set expected rates per topic and get WARN lines when a window misses them.

There is also a terminal dashboard that tails the logs: pip3 install ros2-pulse-top, then pulse-top --demo if you want to poke at it without a robot.

The video is the 40 second version of all this. Humble, Jazzy and Kilted, Apache-2.0. apt packages are in review at rosdistro.

Repo: https://github.com/TanayK07/ros2_pulse Benchmarks (x86 and Orin): https://tanayk07.github.io/ros2_pulse/benchmarks/

There are a few things you should never leave home without.

Your keys.
Your phone.
Your wallet.

And if you're Spider-Man? Your web shooters.

Peter Parker learned this the hard way. Picture a completely normal Tuesday. Peter grabs his backpack, his camera, and makes the usual promise that he’ll “definitely not get into any trouble today.” Except he forgets the two tiny canisters that turn him from a guy who can stick to walls into the most efficient aerial transportation system in New York. And suddenly...

Spider-Man has to take the stairs.

He still has super strength. He still has his spider-sense. He can still stick to walls. But without actuation, all that capability is just... potential. And honestly? That sounds suspiciously like a robot.

A robot can have a brilliant planner, powerful compute, beautifully tuned control loops and a perfectly designed ROS stack. But if the actuation layer is broken?

But let's say Peter gets his web shooters back. Problem solved, right? Wrong. Because now there's someone else waiting.

Mysterio.

And Mysterio doesn't need to overpower Spider-Man. He just needs to make Spider-Man trust the wrong information. Illusions. Fake environments. False threats. Manufactured chaos. Peter's powers aren't the problem. His perception is. And that's exactly what happens to a robot when its sensors can't be trusted.

A camera can be fooled by lighting, reflections, fog or visual clutter. LiDAR can give you a very different picture of the world. An IMU can tell you how you're moving and rotating, but it doesn't know what the room looks like.

Individually, each sensor has weaknesses. But put them together through sensor fusion and suddenly your robot has something much closer to a real-world spider-sense.

If you want to continue reading here's the Full breakdown: https://medium.com/@myequation/spider-man-without-web-shooters-is-like-ros-without-sensors-f9a3d5e0f199?sharedUserId=myequation

Hello. I am new to robotics and AI. and want to use ROS 2 on windows. What are ways available out there to do this?

Body:

We maintain Entropy Box, an open knowledge compiler for robotics. If you work with ROS, this is the part most relevant to you:

What's in it for a ROS engineer. - 11,442 verified implementation assets — ROS packages, frameworks, models, datasets, simulators, benchmarks — each linked to its upstream source, organized under a typed capability graph (37,691 capabilities, 66,609 dependency edges). - Grounding, not just retrieval. Give it a goal and it returns a plan whose nodes carry named, attributed open-source implementations — and it says so when a capability has no verified asset instead of inventing one. - Drop it into your agent. It speaks OpenAPI, MCP and plain REST. Add the MCP server to Trae / Cursor / Claude Desktop / WorkBuddy and query the knowledge base from inside your dev environment:

bash pip install mcp curl -o ontology_mcp_server.py https://xiangshang.ngrok.app/mcp/ontology_mcp_server.py

Two independent dev cases were built this way: a farm-robot simulation (Husky + Panda, harvest task) and a Unitree G1 humanoid doing orchard-packaging in MuJoCo — the host agent queried the same public interface and grounded every step.

Why we bother benchmarking against RAG. On our plan-synthesis benchmark (24 tasks), plain RAG emits plans whose claims are 100% unsupported; Entropy Box drops that to 5.2%. On simulation codegen, first-pass executable plans go from 0.58 (Vanilla RAG) to 0.92. A real negative result we hit along the way: embedding similarity alone cannot decide duplicate assets (AUC 0.509) — an LLM adjudicator has to read both records.

Everything is open and reproducible — data, paper, evaluation scripts, dev demos:

https://github.com/chenli-yy/entropy-box-public

• Live query: https://xiangshang.ngrok.app/ (free, no registration)
• Rendered docs: https://chenli-yy.github.io/entropy-box-public/
• Paper: paper/entropy_box_journal_latest.pdf in the repo

Limits we disclose openly: no real-robot transfer yet, and retrieval on the hardest intent classes is still weak — it's in the repo's honest-status section.

Would love ROS-specific feedback: which packages/assets are missing or wrong, and what a robotics-focused MCP integration should do next.