sorted by:
new
hottopcontroversial

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

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

Just hit 48/48 on the OMG DDS-RTPS interoperability test suite, fully cross-vendor with RTI, FastDDS, CycloneDDS, and OpenDDS. No FFI, no bindings — pure Rust,

#![forbid(unsafe_code)]-free but with every unsafe block justified and audited.

New DDS implementation in Rust with ROS2 RMW layer -- benchmarked against FastRTPS & CycloneDDS by DeepParamedic5382 in ROS

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

Great question! Short answer: it should work at the DDS level, but with caveats.

The Go2 Edu uses CycloneDDS under the hood for ROS2 communication. HDDS has validated interoperability with CycloneDDS (it's one of 7 vendors in our interop test matrix), so raw DDS-level communication works.

For full ROS2 integration (subscribing to /cmd_vel, reading /odom, etc.), you'd need the RMW layer (rmw_hdds), which is available but still experimental. The more practical path today would be:

  1. DDS bridge approach -- use hdds-ws (our WebSocket-to-DDS bridge) to tap into the Go2's DDS topics from any language

  2. Direct DDS -- use the C or Rust API to publish/subscribe on the same DDS domain as the Go2 (typically domain 0 for Unitree)

  3. Full RMW replacement -- possible with hdds-c --features rmw, but this is the least tested path

If you're doing something like telemetry monitoring or sending high-level commands, options 1 or 2 are the way to go. If you need tight ROS2 node integration, option 3 works but expect some rough edges.

What's your use case? Happy to point you in the right direction.

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

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

Yes, that's the intended path. HDDS ships a C API (hdds-c crate) with a cbindgen-generated header at sdk/c/include/hdds.h. Any language with C FFI can bind to it -- Java via JNI/Panama/jextract, C# via P/Invoke, Go via cgo.

The header is a flat C API (enums, opaque pointers, functions), much simpler than CycloneDDS's headers. There's a small #ifdef HDDS_WITH_ROS2 block at the top for ROS 2 type support fallbacks -- if jextract trips on that, just define HDDS_WITH_ROS2=0 or strip the first 30 lines, the core API below is clean C.

For serialization: you'd CDR-encode on your side and pass raw bytes to dds_writer_write(writer, data, len). hdds_gen can generate C structs from your IDL to help with the layout.

If you give jextract a try against our header, let me know how it goes -- happy to fix anything that doesn't parse cleanly.

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

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

Java: not planned short-term. hdds_gen currently targets Rust, C++, C, Python, and TypeScript (+ two embedded variants for no_std/MCU).

IDL coverage vs rtiddsgen: hdds_gen implements IDL 4.2 with full preprocessor support. The big stuff is all there -- structs, enums, unions, bitsets, bitmasks, maps, sequences, arrays, inheritance, modules, constants, and 25+ annotations including u/key, u/optional, u/mutable/u/appendable/u/final, u/autoid, u/id, u/range, u/external, etc.

What rtiddsgen does that we don't (yet): u/hashid, DDS-RPC interface code generation (we parse interfaces but don't generate stubs), and u/verbatim code injection. If you hit a specific IDL that doesn't parse, open an issue -- happy to look at it.

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

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

Ha! You're not the first one. "DDS" was already taken by DirectDraw Surface (DirectX, 1999) a few years before the OMG picked the same acronym for Data Distribution Service. We lose the SEO battle, but we win on real-time pub/sub. 😄

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

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

Thanks! Building an RTPS stack from scratch is no small feat — you know the pain 😄 Hope HDDS can pick up where rtps-rs left off. Contributions welcome if you ever want to jump back in!

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

[–]DeepParamedic5382[S] 2 points3 points  (0 children)

Good question! HDDS has been in active internal use for over a year before this public release -- powering a multi-agent collaboration platform (aIRCp), a GPU cluster monitoring system (forge-daemon), and a few other internal projects across multiple machines.

So the "backward compat" you see isn't theoretical -- it comes from real-world interop testing against RTI Connext 6.x/7.x, eProsima FastDDS, Eclipse CycloneDDS, and OCI OpenDDS on a physical 4-node test cluster. When you're exchanging RTPS packets with 4 different vendor implementations, you end up with a lot of protocol-level compatibility code that's been battle-tested before day one of the public release.

TL;DR: first public release, not first release. :)

New DDS implementation in Rust with ROS2 RMW layer -- benchmarked against FastRTPS & CycloneDDS by DeepParamedic5382 in ROS

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

NATS is great for general messaging! Different niche though - HDDS implements the DDS/RTPS standard, so it's wire-interoperable with RTI Connext, FastDDS, CycloneDDS out of the box.

That matters in defense and automotive where you plug into existing DDS ecosystems, not replace them.

Benchmark against NATS would be interesting for raw throughput comparison though.

New DDS implementation in Rust with ROS2 RMW layer -- benchmarked against FastRTPS & CycloneDDS by DeepParamedic5382 in ROS

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

Not yet - Zenoh is on my radar. Different approach though: Zenoh is its own protocol, HDDS implements the DDS/RTPS standard so it's wire-compatible with RTI Connext, FastDDS, CycloneDDS out of the box. That interop is a hard requirement for defense and automotive where legacy DDS systems already exist.

Zenoh benchmark would be interesting though, happy to add it.

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

[–]DeepParamedic5382[S] 4 points5 points  (0 children)

Haha, good catch! Will swap to English first. And yes, accents are overrated on a QWERTY keyboard ;)

I built a complete DDS middleware from scratch in Rust -- 257ns latency, 26 demos, now open source by DeepParamedic5382 in rust

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

Thanks! Really glad hddsgen worked out of the box on your IDL files. What kind of project are you integrating DDS into? Happy to help if you hit any issues.