Administration Console on RTI Connext DDS running on PI

14 posts / 0 new
Last post
Offline
Last seen: 4 years 7 months ago
Joined: 07/09/2019
Posts: 9
Administration Console on RTI Connext DDS running on PI

I create a publisher on Raspberry PI that receives data from external sensors and sends its data to subscribers located on the same Raspberry PI (I I connected with Raspberry Pi via SSH). Everything is going well. However, I am wondering if there is a way to use the administration console on RTI connext DDS running on Raspberry PI? That way, I can more easily monitor the data sent or received on the Raspberry PI. Thank you.

AttachmentSize
Image icon dds-swd.jpg364.25 KB
irwin's picture
Offline
Last seen: 3 years 8 months ago
Joined: 08/14/2010
Posts: 42

The Raspberry Pi product is set up as a embedded target. As such, we do not provide the normal host based productes like Monitor and Admin console. However, if you also have one of our host/target products you can run it on them and as long as you have connectivity and you can monitor al data sent and received.

 

                                    Irwin

Offline
Last seen: 4 years 7 months ago
Joined: 07/09/2019
Posts: 9

Okay, thanks for your information.

Can we create a subscriber in different hosts (for example Windows / Linux) that will subscribe to publisher in remote devices (Raspberry PI)?

ken
ken's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 04/13/2011
Posts: 64

Hi,

   Yes,  you can subscribe to any Topics in your DDS system from Admin Console no matter where you run it...provided that it will have access to the data. By that I mean that Admin Console (running remotely), will need to be able to communicate with the Pi...if  you've configured it to -only- use shared memory, for example, then remote hosts/applications will not be able to communicate with it. But that doesn't sound like your configuration so you should be fine (just wanted to ensure you knew about the transport selection and how it could affect your system).

Thanks,
Ken

Offline
Last seen: 4 years 7 months ago
Joined: 07/09/2019
Posts: 9

Can you tell me how to make the Admin Console able to communicate with raspberry PI? I still don't understand how my local device can connect to Raspberry PI on a different network (Raspberry PI is accessed remotely).

ken
ken's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 04/13/2011
Posts: 64

Hi,

   You are connecting to the RaspberryPI through a network (ssh)...that same network can be used by DDS to exchange data between your application and Admin Console...provided that it is configured to do so. Without knowing your setup, I can't offer specific recommendations on configuration. What I would recommend, however, is to run RTI DDS Ping on the RapsberryPI (as publisher) and on your Windows/Linux/Mac machine (as a subscriber) to get these applications communicating first. Take a look at configuring the peer list through the command-line options Ping supports and that will tell you how to get started with your application and Admin Console.

Thanks,
Ken

Offline
Last seen: 4 years 7 months ago
Joined: 07/09/2019
Posts: 9

Thanks for your response Ken,

Actually I followed this tutorial (https://community.rti.com/content/forum-topic/howto-run-rti-connext-dds-raspberry-pi) to run DDS in my Raspberry PI, modified some code and added a little function so that it can retrieve data from the dispenser. So, I think the subscriber that I made is also on the same host, raspberry PI. Do you have any recommendations on how to create a subscriber from different hosts?

Thanks

ken
ken's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 04/13/2011
Posts: 64

afathurizk1,

   To get a subscriber running on other hosts, you have a few options. RTI ships a couple of products that can subscribe and show your Topics, rtiddsspy and RTI Admin Console (both are the subject of earlier posts). If you want a "Hello World" type of subscriber, then you can use rtiddsgen to create an example from your IDL just like you did for the RaspberryPI but for another architecture.

Thanks,
Ken

Offline
Last seen: 4 years 7 months ago
Joined: 07/09/2019
Posts: 9

Ken,

What if I create a subscriber with architecture for my local host (x64Linux3gcc5.4.0) and a publisher with architecture for Raspberry PI (armv6vfphLinux3.xgcc4.7.2), can the two be connected / communicate?

Thanks

Offline
Last seen: 3 years 11 months ago
Joined: 08/11/2019
Posts: 28

Hello ken,afathurizki1,

I also want to implement an IoT network that publishes data through multiple Raspberry PIs and subscribes via a local PC.

Can you give me some advice on how to implement this using DDS? 

Currently, I only use DDS to publish and subscribe on the same device.

Thanks

ken
ken's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 04/13/2011
Posts: 64

Hi afathurizki1, Kay Wu,

   DDS supports many architectures, operating systems, and endianess all without you having to do anything special. So, a Rapsberry PI can talk/listen to any of our other supported architectures without worrying about their what OS is in use, whether it is 32 or 64 bit, if it uses big or little endian, or what compiler was used to build the application. DDS handles all of those details for you through the code which is generated from the IDL file. DDS also handles different programming languages, again through the generated code, so that is also not a problem. I hope this helps.

Thanks,
Ken

Offline
Last seen: 4 years 7 months ago
Joined: 07/09/2019
Posts: 9

Hi Ken,

When the two IP addresses are different, how can they communicate with each other? Maybe the picture below will further explain my question. thank you & I apologise for the inconvenience.

ken
ken's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 04/13/2011
Posts: 64

Hi afathurizki1,

   Yes, this is a standard use case that we solve. The mechanism behind how DDS works (in a very simplified way) is that peers (any DDS application, like yours or Admin Console) exchange data through a process called Discovery. The Discovery process, by default, uses a multicast address where each peer announces their presence. Part of this announcement is a set of locators which includes both shared memory and unicast UDP addresses. The peers then determine if they have a match or not. A match is done by ensuring that one side has a DataWriter and the other a DataReader along with checking that they agree on the data type and Quality of Service. If a match is made, then the DataWriter sends data to the DataReader's locators (normally, shared memory for the local machine and a UDP unicast address for remote machines). I hope that helps.

Thanks,
Ken

Offline
Last seen: 3 years 11 months ago
Joined: 08/11/2019
Posts: 28

Hi ken,

Excuse me, do you have related sample code or documents?

Could you provide us?