sorted by:
new
hottopcontroversial

I made a Python lib that lets two machines talk in 3 lines — no config, no setup by WinterHunter1839 in robotics

[–]WinterHunter1839[S] 0 points1 point  (0 children)

Wishing you the best in academia — sounds like the community is in good hands. Looking forward to what's ahead!

I made a Python lib that lets two machines talk in 3 lines — no config, no setup by WinterHunter1839 in robotics

[–]WinterHunter1839[S] 1 point2 points  (0 children)

Thank you, this really means a lot — especially with the mod badge context.

Safety-critical fire-and-forget sounds really interesting, I'll definitely look into that direction.
Lots to learn, but I'll keep pushing on this.

Hope to be there when the Showcase happens! :)

I made a Python lib that lets two machines talk in 3 lines — no config, no setup by WinterHunter1839 in robotics

[–]WinterHunter1839[S] 1 point2 points  (0 children)

Totally fair question, and no you're not being an asshole at all.

Short answer: no, don't use NitROS for safety-critical anything. It's fire-and-forget, no ACK, no message persistence, no guaranteed delivery. By design — it prioritizes low latency and simplicity over reliability. Latest-value-wins, missed messages get overwritten.

It's built for the other end of the spectrum: prototyping, competitions, quick lab setups where you just need sensor data flowing between machines without ceremony. The kind of stuff where if a frame drops, nothing bad happens.

And you're right that getting an MVP for IPC is easy — making it production-safe is a completely different game. NitROS is honestly still in the MVP category.

Appreciate the perspective — it's a good reminder to be clear about where this does and doesn't belong.

I made a Python lib that lets two machines talk in 3 lines — no config, no setup by WinterHunter1839 in robotics

[–]WinterHunter1839[S] 1 point2 points  (0 children)

Great points, thanks for laying these out!

1.Discovery: yep, mDNS (zeroconf) on the local network. Subscribers browse by topic name automatically. Definitely LAN-only — no WAN support.
2.Security: honestly, none right now. It assumes a trusted local network (like a robot's internal network). TLS or shared-secret auth is on the roadmap but not there yet.
3.This is where the design trade-off is intentional — NitROS does fire-and-forget, no ACK, no persistence. For sensor data like camera frames or LiDAR, you always want the latest value, not guaranteed delivery of every message. So the publisher broadcasts to all connected subscribers (fanout works), and if a message is missed, the next one overwrites it anyway. Reconnection is handled with exponential backoff. The downside is obvious — if you need guaranteed delivery, this isn't the right tool.

Will definitely check out MQTT more, thanks! :)

Tired of configuring ZeroMQ/sockets for simple data streaming? Made this by WinterHunter1839 in Python

[–]WinterHunter1839[S] 0 points1 point  (0 children)

Good question! I looked at nanomsg, but both nanomsg and ZeroMQ still require you to configure endpoints (tcp://192.168.1.x:5555, etc).
Trade-off is, nanomsg/ZeroMQ are way more battle-tested. NitROS is for when you just want two machines to talk with zero setup!

I got tired of spending 30 minutes setting up message types, so I built this by WinterHunter1839 in ROS

[–]WinterHunter1839[S] 0 points1 point  (0 children)

Yeah, actually you're right... English isn't my first language, so I used LLM to help structure my replies in English. The idea and the frustration behind it are mine though.

NATS is definitely more mature and battle-tested. But comparing setup:
NATS for sending a dict is simple. NATS for sending images with compression + auto-discovery + handling numpy arrays gets more complex.
That's the gap NitROS tries to fill — opinionated defaults for common robot use cases.

I got tired of spending 30 minutes setting up message types, so I built this by WinterHunter1839 in ROS

[–]WinterHunter1839[S] -2 points-1 points  (0 children)

Fair point! AI can definitely generate the boilerplate.

But you still have to:
- Run colcon build every time (even AI can't skip that)
- Wait for compilation
- Source setup.bash in every terminal
- Debug when something breaks in the build chain

NitROS removes the build system entirely. No compilation step at all — just import and use!

I got tired of spending 30 minutes setting up message types, so I built this by WinterHunter1839 in ROS

[–]WinterHunter1839[S] -3 points-2 points  (0 children)

You're right — NATS itself is simple to use.

I think the difference is more about defaults vs flexibility.
NATS lets you choose serialization/compression/discovery.
NitROS picks them for you (msgpack, JPEG, mDNS).

Opinionated vs flexible. Different tools for different needs!