Hello,
I'd like to make an RTI pub/sub communicate with an OpenDDS pub/sub. For this I took an OpenDDS example, which includes a publisher and subscriber application and also provides an .idl file. I used this .idl file to generate the appropriate publisher and subscriber application with the RTI generator.
Now, when I start, for example, an OpenDDS subscriber and an RTI publisher, the discovery process is failing. The problem is that the OpenDDS application cannot deserialize the submessage or RTPS header for SPDP. I did contact OpenDDS support for this and we are looking into the issue, but one response so far is that RTI Connext might send something that is not in the (OMG?) specification. So my question here would be, do you have an idea what this something could be and how to turn that off on RTI side?
This problem also occures when I try to run both the RTI and the OpenDDS shapes demo applications to communicate with each other.
Alternatively, my question would be, if RTI is able to run on a linux distro with an ARM processor (Raspberry Pi)? Because in that case I just could skip the whole OpenDDS segment.
Best regards, Arthur.
Hello Arthur,
What version of OpenDDS are you running? We had a DDS Interoperability demo in March 2012 (see http://www.slideshare.net/GerardoPardo/omg-dds-interoperability-demonstration-2012) where RTI was inteoperating with OpenDDS under many scenarios. We did not find any issues there. The tests included the ShapesDemo application you mentioned.
Could it be you are using an older version of OpenDDS? Or perhaps they made some updates and they have not updated their official distribution yet.
The RTPS protocol has extensibility mechanisms built-in. Vendors are allowed to insert submessages into the stream as long as they follow the mechanisms that are in the RTPS specification. Vendors seeing these sub-messages that they do not understand are required to skip them and this should not affect inteoperability. These mechanisms are also used between revisions of RTPS (e.g. going from 2.1 to 2.2) such that the revisions are also interoperable.
Regarding support for the Arm and Raspberry Pi. Funny you asked... We recently acquired some for internal use in our research... We do have an Arm distribution but it is for the Arm7. We already tried that and it does not run on the Raspberry Pi. It appears that the Arm7 has instructions that are not supported by the Arm6 in the Pi.
When do you need the Raspberry Pi port? Currently it is not part of our official roadmad. However we are likely to have one built internally in the next several weeks and we could make it available on the community portal. It would not be "officially" supported however.
Regards
Gerardo
Dear Gerardo,
As one of Arthur's advisors here at Technische Universität Braunschweig in Germany I'd like to thank you for the quick response.
Our situation is that we are currently working with RTI DDS on a large multi-national project with several partners from academia and the industry. Hence, we have some expertise in RTI DDS that we would like to put to good use in teaching as well. In particular, we are offering a hands-on course in which the students work on an autonomous vehicle, with the Raspberry Pi being the vehicle's main processing platform. We use DDS to interconnect different vehicle components as well as for communicating with a remote control server.
It would be great if we could use RTI DDS on the Raspberry Pi in order to exploit our existing expertise. We understand that there will be no officially supported version, but the sooner we could work with your Raspberry Pi port (even if still in development status), the better.
I'm looking forward to hearing back from you.
Regards,
Julian
Hello Julian and Authur,
This is great to hear! Your projects sound very interesting we really want to help you continue using RTI for such projects as well as in your courses. I think the Raspberry Pi is really a very nice platform for this kind of mechatronic systems which is also the reason we were interested in it.
Regarding the teaching of RTI Connext DDS I do not know if you are aware of the LiveCD. We have used it for teaching some classes ourselves and find it very useful to get everyone up and running quickly and consistently. Also with Connext DDS 5.0.0 we have included a couple of new features: Application Creation via XML and RTI Prototyper that are also very helpful in teaching the concepts and getting students to have running programs quickly. Regardless, we would love your feedback as teaching and student projects was one of the primary drivers for these features.
We have now a port of RTI Connex DDS to the ARMv6 target for Linux 3.2 using the Linaro gcc 4.7.2 compiler. This matches the default Linux distribution in the Raspberry Pi (Raspbian wheezy).
The port includes all the regular core utilities: rtiddsping, rtidds, rtiddsprototyper. In addition we have updated the rtiddsgen command-line tool to also generate code for this architecture, which is called armv6leLinux3gcc4.7.2
We tested this in our Raspbian Pi (model B) and it all appears to works correctly.
We have packaged the port into a self-extracting archive. The installer requires that you have already installed RTI Connext DDS version 5.0.0. It which check whether you have NDDSHOME already installed or ask you to specify it and this directory must be the ndds.5.0.0
As mentioned this is port is not officially supported by RTI. Click on the link below to download the self extracting archive: RTI_Connext_DDS_Target-5.0.0-armv6leLinux3gcc4.7.2.run
Best regads, please keep us informed!
Gerardo
Hello, Gerardo Pardo,
First of All, I apologize for the following inappropriate information!!! I’d like to request official “RTI Open Community Source” license to make my personal research work approved. If you think my post is not allowed, please feel free to delete it.
I also did an unofficial & personal research yesterday on my own Raspberry Pi platform~
When I use the "RTI_Connext_DDS_Target-5.0.0-armv6leLinux3gcc4.7.2.run" package, I found some warnning message below:
BTW, I also appreciate your possitive work here very much!
Best Regards,
huangzhihua
Hi,
Regarding the error:
[D0000|ENABLE]NDDS_Transport_Shmem_attach_writer:incompatible shared memory segment found.It is due to the fact that the shared memory transport in RTI Connext DDS 5.0.0 does not interoperate with the shared memory transport in previous releases of RTI DDS (4.5x, 4.4x, etc.)
This issue is described in section 2.5 titled "Transport the RTI Connext DDS 5.0.0 release notes. http://community.rti.com/rti-doc/500/ndds.5.0.0/doc/pdf/RTI_CoreLibrariesAndUtilities_ReleaseNotes.pdf
What is likely happening is that the first executable you run was compiled against RTI DDS version 4.5c. This allocated a shared-memory segment using the pre 5.0.0 format. Somehow when the application terminated it did not clean up the segment. Maybe you exited with a ^C. Then when you started the application compiled against RTI DDS 5.0.0 it detected the shared memory segment and reported the format was incompatible.
If you reboot the board it will clean up the segments and you should be able to run the application compiled against 5.0.0 without errors. Alternatively you can try to find the offending shared-memory segment using 'ipcs' and remove it using 'ipcrm' to remove it.
Regarding your request for an RTI Open Community Source. You are very welcome to apply! The best is to download the software from here: http://www.rti.com/downloads/connext.html and select the "Open Community Source" in the license request section.
Gerardo
After using 'ipcrm', the problem is resolved.
Dear Gerardo,
This is great! Thank you very much for making the Raspberry Pi port available so quickly!
The installation was a little tricky, but we have deployed it to our system now and have students working on it. We are also considering to publish some of our work with RTI DDS on the Raspberry later on. I'd be happy to let you know once that happens.
With regards to the LiveCD---we've indeed been using it for quite some time now. It's a great tool to get everybody up and running quickly.
Thanks again,
Julian
Dear Julian,
I am glad to hear you have already started using our Raspberry Pi port on your system. Please, keep us posted on your work with RTI DDS.
Regarding usability, we have shipped this port using a new self-extracting run file to ease the installation process. We want to improve the user experience, so we would love some feedback on this. What made the installation tricky?
Thanks,
Fernando.
The first problem is if you click on Gerardo's link... ouch.
right-click on the link and select "save link as..." ...
:)
rip
Hi Rip,
We have added "Content-Disposition: attachment" to the metadata on Amazon S3. This should force your browser to raise a file download dialog when you click on the download link.
Thanks for reporting the issue.
Hi Fernando,
I'm a co-worker of Julian and have also tried to install the software on the Raspberry Pi. I'm not sure if I used the correct version of the ndds.5.0.0-folder, but it complained that a file was missing (rev_host_rtidds.5.0.0). A symlink from rev_host_rticonnextmsg.5.0.0 solved the problem, a student just created an empty file of that name, which made it work, too.
At first, I was unaware that the archive can be used to cross-compile software, so i installed it on the Pi itself, which means that I copied the whole ndds.5.0.0-folder from my x86_64 installation, but thats my fault ;) Cross-compiling did not work either, but that may be another issue with my compiler installation:
arm-linux-gnueabihf-g++ -o objs/armv6leLinux3gcc4.7.2/ShapeType.o -fpic -DRTI_UNIX -DRTI_LINUX -march=armv6 -mfpu=vfp -mfloat-abi=hard -mlong-calls -I. -I/home/rottmann/RTI5/RTI/ndds.5.0.0//include -I/home/rottmann/RTI5/RTI/ndds.5.0.0//include/ndds -c ShapeType.cxx
In file included from /home/rottmann/RTI5/RTI/ndds.5.0.0//include/ndds/ndds_c.h:87:0,
from /home/rottmann/RTI5/RTI/ndds.5.0.0//include/ndds/ndds_cpp.h:38,
from ShapeType.cxx:15:
/home/rottmann/RTI5/RTI/ndds.5.0.0//include/ndds/dds_c/dds_c_infrastructure.h: In Elementfunktion »bool DDS_Time_t::operator==(const DDS_Time_t&) const«:
/home/rottmann/RTI5/RTI/ndds.5.0.0//include/ndds/dds_c/dds_c_infrastructure.h:103:55: nicht implementiert: Thumb-1 hard-float VFP ABI
Version of g++ for cross-compiling is:
arm-linux-gnueabihf-g++ (crosstool-NG linaro-1.13.1-4.7-2012.10-20121022 - Linaro GCC 2012.10) 4.7.3 20121001 (prerelease)
Yours,
Stephan
I'm booting the latest Debian "Wheezy" distribution.
There are web pages that describe installing openjdk-7-jdk (hard float) and Oracle Java embedded SE (soft float).
The RTI Arm/RPi installer above doesn't have the Java JNI libraries, however, so no java yet.
@ Stephan: I'm using the 4.6.4 Linaro (gcc-linaro-4.6-2012.07) built using crosstool-NG on CentOS. I can compile the same code on the Pi directly (4.7.2) or on CentOS (i5 dual-core Win 7 host, Virtual Box VM CentOS 6.3 client...7 seconds on the VM, 67 seconds on the Pi)
The unimplemented Thumb-1 hard-float vfp abi looks suspicious. What OS are you running on the Pi, and did the gcc 4.7.2 you are using come with it?
Can you copy/paste what "arm-linux-gnueabihf-g++ -v" returns?
And uname -a?
(I'm using Wheezy:
Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux
gcc version 4.6.3 (Debian 4.6.3-8+rpil)
)
rip
Hi Stephan,
When you install a RTI Connext host, a rev_host__ file is extracted under NDDSHOME to provide information on the installed version. Our self-extracting installer looks for something familiar under NDDSHOME to decide whether it is a valid installation directory or not (in this case we check whether rev_host_rtidds.5.0.0 exists or not--that's why creating an empty file or a symbolic link makes the installer). We had only tested our installer against RTI Connext DDS hosts, which contain rev_host_rtidds.5.0.0, so we didn't realize it wouldn't work against RTI Connext Messaging (or professional edition) hosts, which contain rev_host_rticonnextmsg.5.0.0. I have generated and uploaded a new installer that solves this dependency.
Regarding your compilation errors, take a look at this thread in the Raspberry Pi forum. According to them "It seems the compiler is setup to generate thumb instructions by default and when you try and force it to build armv6 hardfloat code it tries (and fails since it's not a combination worth implementing) to build armv6 hardfloat thumb mode code". They recommend you to specify -marm when compiling, but I haven't tested it.
Could send us the output of "arm-linux-gnueabihf-g++ -v"? In our case, the output looks like this:
By the way, If you want to use the same compiler we use, you can download the toolchain here
Best,
Fernando.
Hi,
We have posted detailed instructions on how to run Connext DDS on Raspberry Pi. I hope this helps.
http://community.rti.com/content/forum-topic/howto-run-rti-connext-dds-raspberry-pi
Fernando.
Hi,
quick question here: Is the root password for the LiveCD secret? If not, where can I find it? I've installed the distribution permanently on my machine, but now I can't change the slightest thing, like the boot priority.
Best regards, Arthur.
Hello Arthur,
The password for the root user in the RTI Live CD is not a secret. I will update the download page to show it clearly.
If you are using the 4.5f or 5.0f versions of the RTI Live CD the root user is "rticonnext" (which is the one that logs in by default) and the "sudo" password for this user is the same as the user name: "rticonnext" without the quotes.
Regards,
Gerardo