DDS SkeletonNode - Distributed Systems Programming



Shout out to spiderkeys, since this was modeled from his inspiration and example code. In trying to up my software game, I decided to try my hand at Object Computing Inc.'s OpenDDS implementation to create a skeleton application (wink) such that developers can wrap applications up and have various bits communicating to other various bits over DDS. (Data Distribution Service) protocol. The code is a disaster, not optimal, and needs a ridiculous amount of work, however it now exists on github. I’ll post a link ounce it’s in a more usable state and I create the install, requirements, and usage documentation. This is how I spend my holidays, lol.

If anyone is interested, here are a few links:



DDS Protocol:

ROS is moving to DDS, and any framework that speaks DDS can communicate to any other framework that speaks DDS. Beautiful.


Hey Jim!

Don’t know if you were aware, but I also have a semi-functional DDS skeleton node available on github as well that uses RTI DDS. We’re definitely interested in exploring pub/sub architectures for interprocess, LAN, and WAN communications, but we’re sort of still in the review and research process to decide which one will work best for us in terms of licensing, community, support, etc. RTI DDS is definitely one of the most powerful and mature implementations, but I’m still a bit iffy on the terms attached to their open source community license. We are also wondering whether or not using DDS will be advantageous from the point of view of creating a development environment that has a healthy community behind it.

We’re really interested in seeing where ROS ends up going with it, but it looks like they are still in the research phase as well. Was thinking of contacting Jackie Kay, who seems to be at the lead of developing that interface and seeing how the overall progress is going.

It uses the XML app creation method, but the framework of the code might prove useful for getting your code structured.


Yeah, that was my model, lol. Thanks man. Really just want to dive into DDS to learn. Figured it may or may not be of benefit. I’m going to polish it up, make file it, etc, all the stuff we talked about and doing some of it internally but also want it out and about so I can use it in my own projects. I couldn’t find anything on RTI’s stite that mentioned free developer licensing. Just trail periods so I said forget them for now and try out this OpenDDS impl. It’s really just a playground to improve my coding and c++ knowledge/usage. And prep for what you guys might move to.

I also need to follow up on the order. GQ was the lead on the order so I have to follow up to see what he was able to get through. He was also approved to stand up a maker space on center. It’s gonna be pretty awesome. Laser cutters, printers, dev board tools oh my. They modeled it after Ames’ maker space.


RTI’s DDS implementation (Connext sp?) is a great product. It’s freakishly similar to Microsoft’s CCR & DSS technologies within their (now discontinued) Robotics Developer Studio product suite (albeit CCR survived to become what is now .NET Parallel Extensions and some of DSS morphed into .NET Rx Extensions). I used RTI’s Connext extensively for an automated manufacturing solution developed for the Boeing 777 wing skin fabrication by Mitsubishi Heavy Industries in Nagoya, Japan. RTI is a legit, professional company that provides real support. I’m not certain about OpenDDS; sounds very “openy”. If you’re just playing around and have unlimited time to spare, by all means give OpenDDS a shot. But if you’re a professional who needs to get things done, I would recommend RTI Connext. Is it free? No. But generally my experience has been this: you usually get what your pay for; you almost never get what you don’t pay for. Just being honest here, folks.


Sure. We actually implement RTI’s flavor at work. But the point here in regards to OpenRov and the researcher community who can’t afford the 10’s of k to get an RTI license nor have the time to understand their vague interpretation of ‘free’ Dev license can benefit far more by introducing themselvess to the power of the DDS protocol via an Open Source development channel. Open ROV is about democratizing exploration and robotics. OpenDDS happens to play well with that for the moment. If RTI wants to offer licenses for developers on the cheap them by all means go with them, we love it. But at the level of dev and investigation with ROV/auv in the maker community, the difference between OCI and RTI in my opinion doesn’t justify spending a few grand for personel dev. Besides as long as you build to best practices OCI Imps and RTI impels should play well together. So far I haven’t seen much difference between the two.

One additional point, I am speaking to the community. I do not know where OpenROV as an organization is going in regards to DDS aside from what Charles mentioned above. For internal, non-open source, yeah, RTI all the way. But, that’s not the world, at least I think, OpenROV is in yet, or currently plan to be.


Interesting to hear more support for RTI DDS from someone in industry. I’ve got some system diagrams that show some of my proposed ideas for a potential new architecture for OpenROV that would be based on it, and it would actually be nice to get some discussions going about how people would feel interfacing via DDS or if there are other potential alternatives that can fulfill the same needs laid out in the architecture (like ZeroMQ, MQTT, other pub/subs, etc). DDS is a pretty niche technology at the moment, and I’m not sure if it will ever get adopted by casual developers, though it enjoys widespread use in industry and government applications. My thoughts are that RTI Connext and Connext Micro could be used to design the core infrastructure of the system (which community developers would tend never to modify) and we could expose that infrastructure to other technologies using RTI Connector and other bridge technologies. Having worked with Jim in the past, we designed our entire system framework around RTI Connext, which turned out to be very successful. However, that was in a closed-source situation where only a small core team worked with the infrastructure source, so I am still iffy on whether or not it will be a good fit for OpenROV and don’t want my biases weighing too heavily on that decision.

I think this will make for very interesting discussion, and I would really like anyone in our community with experience in these techs to weigh in with their opinions. I’ll put together those materials and supporting rationale and make a thread dedicated to exploring technologies for a distributed OpenROV design.


Additionally, I’ve got an e-mail discussion going with RTI about licensing needs and clarifying whether we can maintain a completely open source or partially open source (including their headers and obj files, but not direct source), so hopefully we’ll get some insight about viability from that soon.


Messages have been hidden that were off topic. Please keep the conversation focused on the topic or move it a new topic.


Here’s the link for the OpenDDS Impl node. it’s rough, but we learn as we go.

The example sends an receives a text message on a test topic. But that does little but show that it’s possible to do such a thing. We already knew this. Thus, two branches have been created. imu-node, and rtimu-app-node. The imu-node will publish imu data over dds, and the rtimu-app node, which wraps the RTIMU demo app in a dds framework, recieves the data and displays with in the 3rd party gui. The imu-node lives on a raspberry-pi (my prototype CTD to be exact) and publishes the IMU data via the “imu-data” topic. On a base station computer, the "imu-data_ topic is subscribed to by the rtimu-app-node and thusly passes the read data from the topic to the GUI application.

I’ve just created the two branches of the skeleton node and hope to have both the imu-node and rtimu-app-node finished by middle of next week. The imu-node is almost trivial, but wrapping the RTIMU demp app my be more involved. I’ll post completed status as a.s.a.p. and include a demo video.


Greetings enthusiasts,

Given new projects recently, I’ve decided to wrap up the demo apps using dds and abandoned the GUI wrapper for a simple subscriber and writer of the IMU data (a subset - fused Euler angle pose) It’s enough to get the point across. I’ve updated the OpenDDS main and demo branches. There are issues listed and I will wrap them up over the next month. I hope this was useful, albeit it somewhat esoteric…dds tends to be. Might check out ZeroMQ in the near future, will have to see. The px4 guys have been working with it and uORB on their flavor of the pixhawk, so maybe some interest there.


Check out the C rewrite of ZeroMW, nanomsg. I’m planning on exploring it as a potential local pub/sub interface for extensions.

Article the author wrote (there is also a part 2):


For embedded stuff, it’s nice to not have to depend on the C++ std library as a dependency. Doesn’t make too much of a difference on the beaglebone, but if we add MCUs in the future that have IP stack communications, it could be well suited.


Also, I’ve pretty much written off using DDS at this point. RTI never really gave me satisfactory answers concerning licensing and it seems like they are reluctant to talk much about open source applications which are massively distributed, as opposed to distributed within a limited group of people, especially when you start talking about wanting to do an open source implementation on an embedded platform.


interesting indeed. zeromq is also used by the px4 cats as well. i’ll dive into it when i come up for air…been crazy fun busy. more to come soon…