Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Open the C++ example up and the first thing I see:

    ```cpp std::cout << "Received ReportCoordinateFrameSettings" << std::endl; ```

    Generally, I've heard `std::endl` instead of \n has bad performance because it forces the statement to print immediately. And because cout is guaranteed to flush anyways when the program ends, you're adding a delay for no reason.

    I wonder if there's something I'm not seeing that led to them adopting this rule. e.g. "abnormal program termination" caused by the weapon blowing itself up circumventing a buffer flush?

  • Cool I did not know that.

    Your comment is a bit salty, but I learned something from it, so I don’t think you deserve the downvotes

  • > And because cout is guaranteed to flush anyways when the program ends, you're adding a delay for no reason.

    I mean... If your command line utility doesn't print anything til it's done, that is going to be, _at best_, an annoying user experience.

  • > cout is guaranteed to flush anyways when the program ends

    This is not always true in the case the program crashes. I've had case where `std::endl` was necessary.

  • For a long time, std::endl demonstrated that you were a proper C++ programmer, not some neckbeard C apologist. It wasn’t until C++ had „won“ that it became acceptable to use \n again.
    by __d
  • The modern C++ idiom is std::println() anyways...

    https://en.cppreference.com/cpp/io/println

  • This seems like an incredibly unimportant quibble... I would imagine they just used std::endl b/c that's what most random tutorials used in the 2000s and that's how the engineer learned. If you are printing a debug string, you probably don't care that much about perf in the first place.
  • Nah, they haven't open sourced anything: https://github.com/rheinmetall. They just published the documentation. Really weird, what's the point?
  • Theres probably some tender that says it must be a "open platform" "open ecosystem" "modular vendor independent" whatever. So you upload some slop to GitHub and tick the box.
  • I think that’s what the “protcol” (sic) in the title was supposed to indicate. I agree it’s misleading.
  • They've got the IDL files as well for the APIs, but you can't use them without their libs:

    > The data model is defined using a custom format .rmodel based on the ddkit > framework (rmodel-api).

    > Please note that the .rmodel data model is for documentation purposes only and > does not reflect the actual interface used on the communication layer. Network > communication is only possible through the provided libraries.

  • Are they trying to recreate DIS (IEEE1278) and HLA (IEEE1516) — like they‘re replicating the FOM architecture from distributed simulations for their weapons to integrate.
  • I have not heard about HLA for a looong time !
  • Sounds like the Land Data Model (LDM) of the Generic Vehicle Architecture (GVA) [1] that the UK MOD has. GVA is closed source however.

    [1] https://en.wikipedia.org/wiki/Generic_Vehicle_Architecture

  • First I was excited, then I saw that it's based on DDS.
    by j-pb
  • why the hate on DDS?

    seems like a perfect fit.

  • Oh boy, just what the world needs right now. Open source weapons APIs!
  • MCP is 100% already in the works.

    > Claude, please execute the insurgents. Make no mistakes.

  • MAVLink has been open source for over a dozen years and with better tooling and apis.
  • Reminds me a lot of the Tactical Microgrid Standard (aka TMS aka MIL-STD-3071) [1], probably just because TMS uses DDS as well. I would really like to know if there is a protocol that functions like DDS but caters to real-time guarantees and prioritizes (at a "simple protocol" level) usability on embedded systems with no dynamic memory allocation. It would also need to be just-as-functional with non-real-time systems. One problem with DDS is that it is too heavy-handed to implement well on an embedded system.

    [1] https://battery.army.mil/system-integrator-hub/tms/

  • TIL there are people using DDS for non-realtime
  • Zenoh (https://zenoh.io/) is a good alternative to DDS in many cases - it scales down to microcontrollers with most features still intact, but scales up to a routed hybrid mesh if needed.

    It does move the schema enforcement out of the middleware layer, so it’s a bit different. But it’s now a first-class alternative middleware implementation for ROS2 as an alternative to DDS.

  • Pretty sure there are DDS implementations that provide most of that, maybe with memory pools instead of no-allocations.

    Other than that, PX4 uses an in-memory only pub/sub for internal data bus, somewhat inspired by DDS

    by p_l
  • There's a range of DDS implementations, definitely a number that are compatible with embedded and spaceflight applications that don't require dynamic memory allocations. You're going to take a hit on some DDS features, but then again you aren't going to need to handle a large queue of large dynamically-sized messages on some small embedded platform.

    I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.

  • Off-topic, but "Rheinmetall" is one of the coolest company names. It's like what a company that builds mechs would be called in an anime.
  •     Missouri Metalworks :-|
        Rheinmetal :-O
    
    Literal "Thing, Japan" expect s/Japan/Germany
  • It will be exhilarating when their robots are pointing guns at us
  • Happy to see the uses of standard C++ including std::shared_ptr etc. in C++.
  • I wonder if someone just got super annoyed at having to ask legal to share their documentation with a cooperation partner for export control clearance, that they decided getting it open sourced would be less of a hassle.

    Now they can freely link anyone to the document.