I hope you are all well. As promised, we continue our DDS exploration. A big thanks to @Jim_Trezzo and @webhoppery for taking on the RTI DDS dive. Though RTI has some good tools, I’ve learned something about the open sources license. As I mentioned in Software Exploration - DDS and the Trident #2, the OpenSource developer license offered by RTI, though an excellent resource for application development for add-on code and kits for the Trident, does not satisfy the home developer or tinkerer that wishes to explore and interface with the Trident with some tools that support the DDS protocol. Enter OpenDDS from OCI and ROS 2.
I encourage everyone, especially @Jim_Trezzo and @webhoppery to continue the RTI investigation and familiarization with the tools supplied. However, I will be focusing on OpenDDS, that contains similar tools as from RTI, and allows for not only complete open development of DDS applications with no license requirements, but the development of stand-alone nodes that can speak with RTI implementations, as well as Prism Tech and others who have faithfully followed the DDS standard.
That being said, in this post, I introduce the OpenDDS Skeleton Node previously mentioned. NOTE: This code is in development at this time. There are 2 branches on the repo. Master is the stable release of the code, devel, is obviously, the development repo. If you wish to contribute, just do it and create a pull request. You are also welcome to email me through this forum and/or through github.
Repo: OpenDDS Skeleton Node Note: This code is old at the moment, it most likely won’t work for you with no understanding under the hood. A new branch, devel_orov will be used in future posts.
Moving on. Since we need to discuss OCI OpenDDS and the Node code, this topic will entail a few posts. I will do my best to introduce you to OCI and the Node as we move forward.
OCI OpenDDS is actually very full featured. OCI offers support to anyone, you can also purchase support and courses from OCI. Check out their page for all that they offer. They have some good documentation as well, so I encourage you to read up on their impl. You will notice that OCI also has Java bindings in addition to C++. Also note, that my tutorials are for Linux systems. I don’t own a Windows or Mac box, sorry.
Let’s get build. First go ahead and download the .zip if you have windows, or the .tar.gz for Linux/Lolaris/MacOSX. It’s easiest to drop the tar file into a high level directory such as ~/OpenDDS or ~/dev/OpenDDS just as we did with the RTI libs in previous posts. Extract the files and drop into the OpenDDS directory. Using a terminal window, go ahead and configure:
If you don’t desire the Java bindings, just forget the --java flag on the configure script execution. Note, if you make the project, you get a full working OpenDDS set of Libs, however, these aren’t installed in the /usr/libs directory of your machine. You can take a look at the INSTALL file that gives a good overview of the build process for booth windows and linux, however, they instruct the a --prefix= flag beset for your install. I’ve tried this unsuccessfully. What thie means is that after you make the libraries, you will need to manually transfer the compiled libs via cp to the /usr/libs folder. Not a big deal, and I will detail this soon. Now, you don’t need to cp the libs, but it makes if easier and maps better with the current SkeletonNode code if you do.
With ./configure complete, simply type make.
This will take some time to complete. Once finished you can follow the example code and tutorials that OCI offer. I suggest you do this to better familiarize yourself with the code base. The best description is a picture. Here’s a shot of the OpenDDS architecture:
Let’s start form the top. Application, this, of course, an application, like an IMU publisher that a developer may write with the Skeleton Node. The application can have a publisher, or subscriber, or both. DCPS, data centric publish subscribe, is the paradigm in which we are working in. We write our applications around the data types we are passing. Hence, we are data centric and not application centric. QoS, quality of service, is the power behind DDS. This allows us to determine how we interact with the data and how to handling off-normal conditions, etc. That leads us to the readers/writers. Notice CORBA, common object request broker architecture, lives between these two. CORBA facilitates the communications of systems deployed on diverse sets of architectures. CORBA is the glue in our pub/sub world. The Transport layer is exactly that, UPD, TCP/IP, etc.
Let’s pause here. Download OpenDDS, configure and make it. Run the examples and read the developers guide. You’ll notice, as with the RTI impl, that it’s not so user friendly. The API is confusing and san be very complicated for a beginner. No worries, that’s why the SkeletonNode is being developed to wrap up a good deal of the DDS functions so that you, the developer, can focus on writing applications to interface and control the trident without getting lost in the DDS drudgery. One note, no warranty of any kind is implied and certainly not offered, lol, sorry.
Note, I am in the process of updating the OpenDDS skeleton Node code on github for use with the latest OpenDDS. It will take me a few days until it is ready to use. I’ll let you know when it’s good to go here.
In the next post we will explore some tools OCI offers as well as take our first look at the SkeletonNode to read Trident IMU data.