Using Tinq for ROS 2.0 - Githubissues

@brunodebus and @mouse256, trying to use this way to reach you (e-mail didn't work so far):

This is Víctor Mayoral Vilches, working at OSRF. Esteve contacted you a while ago showing our interest in Qeo and Tinq. I am the person pushing forward the ROS 2.0 development on the embedded/deep-embedded side and we are considering using Tinq's code for this purpose.

Our goal is to use a minimal DDS implementation in plain C (ideally ANSI C11) that can run in bare-metal (cortex-m3, -m4, -m0, msp430, ...) so we can't assume a POSIX interface.

So far we have the following architecture in mind:

The Transport abstraction layer will hook up the embedded network stack (probably device dependant) with the DDS.
We are hoping that the DCSP and RTPS layers can be provided by the tinq-core will provide once it has been stripped down from the POSIX networking and RT dependencies.
The ROS client nano library API will abstract the users with a rossified API of the underlying DDS.

How does this sound to you? Would it be fine if we contributed to tinq-core to make it deep-embedded capable? If so, maybe you could clarify to me the following aspects:

As tinq-core is coded right now, it assumes it's built on top of POSIX, right? How feasible is it to remove this dependency and provide an interface that allows the networking stack to be adaptable? (POSIX could be one option)
I see that currently, libdds.so is 3.5 MB. We are targeting something around 200 KB. Do you believe it's possible stripping it down to this size?
Is the real-time implementation depending on librt and if so, could this be bypassed easily?

After having spent some time looking at the code I admit that it's a quite amazing piece of work. I think it'll be great to use Tinq as a fundamental piece of software for embedded robotics.

@vmayoral The problems you are encountering seem more to do with limitations in the NuttX kernel and having to find workarounds for these than with real shortcomings in the DDS software. A proper solution would be to implement UDP packet buffering (with a configurable bytes/packets threshold after which packets are dropped, copying multicasted packets to multiple buffers if needed) in the NuttX kernel combined with a proper poll/select() mechanism. However, if this is not feasible in the short term, an alternative is clearly needed. I would still try to hide the real workaround within emulated posix functions (poll() /select()/recvfrom()), since the alternative, i.e. rewriting the DDS I/O handling, seems to be a lot more work and a lot more risky, without giving real benefits. I would argue that using asynchronous I/O functions instead of the existing synchronous functions combined with poll/select() would be similar in efficiency in terms of internal DDS working. I see no reason why the efficiency would be improved. The problem is the lack of buffering that forces you to implement multiple worker threads, forcing everything to be a lot less efficient. Of course, it might be possible to emulate the poll/select() functions on top of the asynchronous functions (using lio_listio() and friends to implement UDP buffering). Maybe this might speed up the porting effort. Just my 2 cents ...

Thanks @jvoe. I'm debugging the implementation we did and we found out that it's locked most of the time which suggests that we are introducing a bug somewhere.

I'll keep looking it up.

@nuttx I finished the pseudo-UDP implementation using threads (four of them) https://github.com/ros2/ros2_embedded_nuttx/commit/7b0a7ceda3a3ab208e52b30017ac6016b2390460.

I carefully debugged what i coded an it seems that everything is launched as expected however the threads get blocked in the recvfrom() call and don't return.

Initially i thought this could be due to the "Round Robin timeslice" (set to 200 ms by default) so i put it in 20 ms. Nothing changed. I also played a bit with the "System timer tick period" setting it to 1000 us. Again, no response, the 4 threads are still blocked in the recvfrom() call.

In order to discard timing issuesI tried generating UDP traffic for several seconds:

sudo mz eth0 -c 1000000 -A 192.168.0.2 -B 192.168.0.3 -t udp -p 100

I can clearly see thousands of packets in the wire but my board still doesn't return from recvfrom(). I went as far as to hack the main thread to recvfrom directly there (tried with the fd of the different locators) https://github.com/ros2/ros2_embedded_nuttx/commit/d0682b972edc84d8c214dc05711b3b68d487cf60. Nothing.

!!scx

# of IP receive events   = 0
Sending UDP socket:
  UDP     0.0.0.0:0     fd:8      id:0  
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
Locators:
  UDP     192.168.0.3:7601  fd:9      id:1   USER UCAST SRC_MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     239.255.0.1:7401  fd:10      id:1   USER MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     192.168.0.3:7600  fd:11      id:1   META UCAST SRC_MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     239.255.0.1:7400  fd:12      id:1   META MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0

I tried enabling the Networking Debug Output from NuttX and i get the following:

....
udp_callback: flags: 0010
devif_callback_execute: Call event=80958c9 with flags=0010
recvfrom_udpinterrupt: flags: 0010
udp_callback: flags: 0010
devif_callback_execute: Call event=80958c9 with flags=0010
recvfrom_udpinterrupt: flags: 0010
igmp_poll: Entry
udp_callback: flags: 0010
devif_callback_execute: Call event=80958c9 with flags=0010
recvfrom_udpinterrupt: flags: 0010
udp_callback: flags: 0010
devif_callback_execute: Call event=80958c9 with flags=0010
recvfrom_udpinterrupt: flags: 0010
udp_callback: flags: 0010
devif_callback_execute: Call event=80958c9 with flags=0010
recvfrom_udpinterrupt: flags: 0010
udp_callback: flags: 0010
devif_callback_execute: Call event=80958c9 with flags=0010
recvfrom_udpinterrupt: flags: 0010
...

@nuttx @jvoe any ideas on this matter?

@vmayoral

I can clearly see thousands of packets in the wire but my board still doesn't return from recvfrom(). I went as far as to hack the main thread to recvfrom directly there (tried with the fd of the different locators) ros2/ros2_embedded_nuttx@d0682b9. Nothing.

I presume that create the threads with pthread_create() correct? I only see something called thread_create() but I assume that is some wrapper for thread_create(). Are you using the same socket descriptor for all reads? Look like not.

Perhaps you are deadlocking on some mutex?

I tried enabling the Networking Debug Output from NuttX and i get the following: .... udp_callback: flags: 0010 devif_callback_execute: Call event=80958c9 with flags=0010 recvfrom_udpinterrupt: flags: 0010 udp_callback: flags: 0010 devif_callback_execute: Call event=80958c9 with flags=0010 recvfrom_udpinterrupt: flags: 0010 igmp_poll: Entry udp_callback: flags: 0010 devif_callback_execute: Call event=80958c9 with flags=0010 recvfrom_udpinterrupt: flags: 0010 udp_callback: flags: 0010 devif_callback_execute: Call event=80958c9 with flags=0010 recvfrom_udpinterrupt: flags: 0010 udp_callback: flags: 0010 devif_callback_execute: Call event=80958c9 with flags=0010 recvfrom_udpinterrupt: flags: 0010 udp_callback: flags: 0010 devif_callback_execute: Call event=80958c9 with flags=0010 recvfrom_udpinterrupt: flags: 0010 ... The 010 event is not interesting. This is just a periodic poll (UDP_POLL), usually at 2Hz. It that is all you are seeing, the the driver is not receiving any data. When the driver receives data you will see 002 (UDP_NEWDATA). This is generated by very low level logic from the Ethernet MAC driver.

This suggests some unrelated issue. Either you are missing other poll values are you just are not receiving the packets.

Greg

@nuttx thanks for your answer.

I presume that create the threads with pthread_create() correct? I only see something called thread_create() but I assume that is some wrapper for thread_create(). Are you using the same socket descriptor for all reads? Look like not.

Yes, the threads are created with pthread_create(). Refer to https://github.com/ros2/ros2_embedded_nuttx/blob/master/dds/src/include/thread.h#L128 for the define.

And no, each thread calls recvfrom() with its own file descriptor but it always uses the same. That's the idea behind the implementation, having a separate thread reading for each locator (a locator is an abstraction within DDS that represents a network interface and a port).

As a separate test, i tried apps/examples/udp (to discard possible issues with UDP receiving) both in client and server mode and it doesn't seem to work properly (i rebased the code with your master repo yesterday). @nuttx would you mind confirming this?

@vmayoral "would you mind confirming this?"

I re-verified TCP/IP and ICMP networking using configs/stm32f4discovery/netnsh. It works correctly as you expect since there have not been any recent changes to networking.

Since there is already an older port of ROS to NuttX (under the RGMP framework), I would think that any ROS integration problems for that older port would have already been resolved. See http://sourceforge.net/p/rgmp/roscpp/ci/master/tree/

Thanks for the double-checking @nuttx. I confirm that UDP reception of packages is working just fine. I coded a simple examples/udpsimple app (taking inspiration from examples/udp) that proved it https://github.com/ros2/ros2_embedded_nuttx/commit/d9db63e40801f4d48d9d7541657ec3e4db88e20a.

From this point i tried making another prototype called udpsimple_mcast (https://github.com/ros2/ros2_embedded_nuttx/commit/9d65527b2faf4027cdbeb40b23a9dad44840444e) but then i realized at http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/TODO that:

 Title:       INTERFACES TO LEAVE/JOIN IGMP MULTICAST GROUP
  Description: The interfaces used to leave/join IGMP multicast groups is non-standard.
               RFC3678 (IGMPv3) suggests ioctl() commands to do this (SIOCSIPMSFILTER) but
               also status that those APIs are historic.  NuttX implements these ioctl
               commands, but is non-standard because:  (1) It does not support IGMPv3, and
               (2) it looks up drivers by their device name (eg., "eth0") vs IP address.

               Linux uses setsockopt() to control multicast group membership using the
               IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options.  It also looks up drivers
               using IP addresses (It would require additional logic in NuttX to look up
               drivers by IP address).  See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
  Status:      Open
  Priority:    Medium.  All standards compatibility is important to NuttX.  However, most
               the mechanism for leaving and joining groups is hidden behind a wrapper
               function so that little of this incompatibilities need be exposed.

It's not implemented which explains why i was not receiving packages in the multicast interface (the unicast interfaces work properly).

@nuttx I'd be happy to take this ticket and push it forward. Could you provide some pointers on how to start with it and/or how would you like it implemented?

For now i'm exploring the apps/examples/igmp which i guess is the ìoctl implementation that you mention at:

....
NuttX implements these ioctl commands, but is non-standard because:  (1) It does not support IGMPv3, and
               (2) it looks up drivers by their device name (eg., "eth0") vs IP address.

@vmayoral I really don't think you need to implement anything. An IP address would only be used, in conjunction with a device configuration and a routing table to select a device. Since there is only one Ethernet device, it will also decide to use "eth0" anyway.

Look at http://sourceforge.net/p/nuttx/git/ci/master/tree/apps/netutils/netlib/netlib_ipmsfilter.c I think that is all hat you need.

@nuttx I used the ioctl() (through ipmsfilter). Please refer to https://github.com/ros2/ros2_embedded_nuttx/blob/master/apps/examples/udpsimple_mcast/udpsimple_mcast.c. Briefly:

I configure eth0 with a unicast ip address (192.168.0.3)
create a socket and bind it to the multicast address (239.255.0.1) and port 5471
Join the multicast group with ipmsfilter using eth0.
recvfrom the socket

The result is that if i send udp packages (from another machine) with destiny IP 239.255.0.1 (and port 5741) the NuttX kernel doesn't process the packages but if i send them to 192.168.0.3 it does.

@vmayoral If that is true, then most likely there is a problem in with the STM32 hardware address filtering in the STM32 Ethernet driver at arch/arm/src/stm32/stm32_eth.c. That has probably never been tested. Make sure that the function stm32_addmac() is called in that file.

@nuttx thanks for the pointers. The simple example i coded (udpsimple_mcast) actually calls stm32_addmac():

#0  stm32_addmac (dev=0x20000510, mac=0x10003210 "\001") at chip/stm32_eth.c:2235
#1  0x08014bf0 in igmp_addmcastmac (dev=0x20000510, ip=0x100032b8) at igmp/igmp_mcastmac.c:110
#2  0x0802177c in igmp_joingroup (dev=0x20000510, grpaddr=0x100032b8) at igmp/igmp_join.c:155
#3  0x080215ca in netdev_imsfioctl (psock=0x10002de4, cmd=1809, imsf=0x100032b0) at netdev/netdev_ioctl.c:533
#4  0x0802166c in netdev_ioctl (sockfd=9, cmd=1809, arg=268448432) at netdev/netdev_ioctl.c:755
#5  0x08018f72 in ioctl (fd=9, req=1809, arg=268448432) at vfs/fs_ioctl.c:106
#6  0x08011218 in ipmsfilter (ifname=0x80238ac "eth0", multiaddr=0x100032e0, fmode=1)
    at netlib_ipmsfilter.c:109
#7  0x08010a78 in recv_server () at udpsimple_mcast.c:151
#8  0x08010c9a in udpsimple_mcast_main (argc=1, argv=0x10003774) at udpsimple_mcast.c:236
#9  0x080034b6 in task_start () at task/task_start.c:139
#10 0x00000000 in ?? ()

From this point, we've debugged https://github.com/ros2/ros2_embedded_nuttx/blob/master/nuttx/arch/arm/src/stm32/stm32_eth.c#L2223 and we found out that everytime we receive a multicast package the code is breaking at stm32_receive however the packet is not popping out in the application thereby there's something broken in along the way. Do you have any suggestions where this could happen?

@vmayoral The decision whether a packet is accepted by the Ethernet driver or not depends only upon how the hardware address filtering is configured. That is, by stm32_addmac(). If the address filtering is not working, then stm32_addmac() is not working.

You will need to read the STM32 data sheets and debug the STM32 hardware interface to understand why.

@vmayoral If on reception of a multicast packet the code reaches stm32_receive(), i guess it has to do with a problem while parsing the MAC frame. Maybe the code becomes confused due to the multicast MAC destination address and doesn't know how to process it properly? There is a clear relationship between IP multicast addresses and MAC multicast addresses, where multiple IP multicasts are mapped to a single MAC multicast, so the inverse operation is a bit tricky.

@nuttx I confirm that ipmsfilter works properly. The Ethernet driver of the STM32 is fine as well. The udpsimple_mcast prototype confirms it.

After this commit https://github.com/ros2/ros2_embedded_nuttx/commit/d20052473e7a142c19ea96c7bbfd22e9d369fe10 it seems that NuttX joins nicely the network (and actually other participants can see him). It also seems that it is receiving in the right interface! :+1:

# of IP receive events   = 11
Sending UDP socket:
  UDP     0.0.0.0:0     fd:8      id:0  
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:180936/0  packets Tx/Rx:2800/0
Locators:
  UDP     192.168.0.3:7601  fd:9      id:1   USER UCAST SRC_MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     239.255.0.1:7401  fd:10      id:1   USER MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     192.168.0.3:7600  fd:11      id:1   META UCAST SRC_MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:4368/0  packets Tx/Rx:14/0
  UDP     239.255.0.1:7400  fd:12      id:1   META MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/4048  packets Tx/Rx:0/11

Good news indeed however it seems that there's some sort of conflict in the communication. @jvoe, @bramstes, @brunodebus and @kriver are the following logs saying something to you from your previous experiences:

The IP address of the embedded board running Tinq is 192.168.0.3
The IP address of the Desktop machine running Tinq is 192.168.0.2

Desktop machine running Tinq

!!scx
# of IP receive events   = 314
# of DTLS server events  = 0
# of DTLS receive events = 0
Sending UDP socket:
  UDP     0.0.0.0:0     fd:3      id:0  
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:0/0  packets Tx/Rx:0/0
Locators:
  UDP     192.168.0.2:7557  fd:6      id:1   USER UCAST SRC_MCAST
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     172.23.1.215:7557  fd:7      id:1   USER UCAST SRC_MCAST
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     239.255.0.1:7401  fd:8      id:1   USER MCAST
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     192.168.0.2:7556  fd:9      id:1   META UCAST SRC_MCAST
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:57040/0  packets Tx/Rx:155/0
  UDP     172.23.1.215:7556  fd:10      id:1   META UCAST SRC_MCAST
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:57040/0  packets Tx/Rx:155/0
  UDP     239.255.0.1:7400  fd:11      id:1   META MCAST
        r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
        octets Tx/Rx:0/115328  packets Tx/Rx:0/314

!!sdisc
Domain 0 (pid=73): {1}
    GUID prefix: a37aa173:00492cb6:03e90000
    RTPS Protocol version: v2.1
    Vendor Id: 1.14 - Technicolor, Inc. - Qeo
    Technicolor DDS version: 4.0-0, Forward: 0
    SecureTransport: none
    Authorisation: Authenticated
    Entity name: Technicolor Chatroom
    Flags: Enabled
    Meta Unicast: 
        UDP:192.168.0.2:7556(4) {MD,UC} H:4
        UDP:172.23.1.215:7556(5) {MD,UC} H:5
    Meta Multicast: 
        UDP:239.255.0.1:7400(6) {MD,MC} H:6
    Default Unicast: 
        UDP:192.168.0.2:7557(1) {UD,UC} H:1
        UDP:172.23.1.215:7557(2) {UD,UC} H:2
    Default Multicast: 
        UDP:239.255.0.1:7401(3) {UD,MC} H:3
    Manual Liveliness: 0
    Lease duration: 50.000000000s
    Endpoints: 10 entries (5 readers, 5 writers).
    Security: level=Unclassified, access=any, RTPS=clear
    Resend period: 10.000000000s
    Destination Locators: 
        UDP:239.255.0.1:7400(6) {MD,MC} H:6
        TCP:239.255.0.1:7400 {MD,MC}
    Discovered participants:
        Peer #0: {25}
        GUID prefix: 601234df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        SecureTransport: remote: DDSSEC, local: DDSSEC
        Authorisation: Authenticated
        Entity name: Technicolor Chatroom
        Meta Unicast: 
            536928769?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7600 {MD,UC}
        Meta Multicast: 
            536928769?:00:00:00:00:00:00:00:00:00:00:00:00:ef:ff:00:7400 {MD,MC}
        Default Unicast: 
            536928513?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7601 {UD,UC}
        Default Multicast: 
            536928513?:00:00:00:00:00:00:00:00:00:00:00:00:ef:ff:00:7401 {UD,MC}
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 8 entries (4 readers, 4 writers).
        Source: 
            UDP:192.168.0.3:7600 {MD,UC}
        Timer = 48.35s

Embedded board running Tinq

!!scx
# of IP receive events   = 5
Sending UDP socket:
  UDP     0.0.0.0:0     fd:8      id:0  
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:154440/0  packets Tx/Rx:2386/0
Locators:
  UDP     192.168.0.3:7601  fd:9      id:1   USER UCAST SRC_MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     239.255.0.1:7401  fd:10      id:1   USER MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/0  packets Tx/Rx:0/0
  UDP     192.168.0.3:7600  fd:11      id:1   META UCAST SRC_MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:3432/0  packets Tx/Rx:11/0
  UDP     239.255.0.1:7400  fd:12      id:1   META MCAST
            r.errors:0  w.errors:0  empty:0  too_short:0  no buffers:0
            octets Tx/Rx:0/1840  packets Tx/Rx:0/5

!!sdisc
Domain 0 (pid=95): {1}
        GUID prefix: 601234df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        Entity name: Technicolor Chatroom
        Flags: Enabled
        Meta Unicast: 
                UDP:192.168.0.3:7600(3) {MD,UC} H:3
        Meta Multicast: 
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Default Unicast: 
                UDP:192.168.0.3:7601(1) {UD,UC} H:1
        Default Multicast: 
                UDP:239.255.0.1:7401(2) {UD,MC} H:2
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 10 entries (5 readers, 5 writers).
        Resend period: 10.000000000s
        Destination Locators: 
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Discovered participants: <none>

screenshot from 2014-10-16 16 32 37

screenshot from 2014-10-16 16 25 52

In short, the embedded board doesn't seem to recognize other participants. Furthermore it seems that some of the messages sent by the embedded board are malformed. Since it believes that no one else is in the multicast group, the chat application doesn't send its messages to the network either.

I'll be looking into the packages and communication but let me know if something comes to you mind. With your experience finding the culprit of this miss-communication should be easier.

For your interest, i've also recorded a Wireshark capture that may complete the description that i provided. Please find it here.

Apologies for the long message. I believe it was needed in order to picture the situation.

It seems that NuttX breaks at spdp_remote_participant_enable when it receives a package from the Desktop DDS instance:

Breakpoint 1, spdp_remote_participant_enable (dp=0x1000fac0, pp=0x20016680, hs_handle=0)
    at ../../../dds/src/disc/disc_spdp.c:754
(gdb) bt
#0  spdp_remote_participant_enable (dp=0x1000fac0, pp=0x20016680, hs_handle=0)
    at ../../../dds/src/disc/disc_spdp.c:754
#1  0x08092058 in spdp_new_participant (dp=0x1000fac0, info=0x20016538, srcs=0x20015410)
    at ../../../dds/src/disc/disc_spdp.c:959
#2  0x08092700 in spdp_event (rp=0x20010780, t=NT_DATA_AVAILABLE) at ../../../dds/src/disc/disc_spdp.c:1392
#3  0x08057f16 in disc_notify_listener (ep=0x20010780, t=NT_DATA_AVAILABLE)
    at ../../../dds/src/disc/disc_main.c:404
#4  0x080139b0 in dds_client_notify (events=0x1000f67c) at ../../../dds/src/dds/dds.c:692
#5  0x08013d56 in dds_work (max_wait_ms=2000) at ../../../dds/src/dds/dds.c:863
#6  0x08013dcc in dds_core (arg=0x0) at ../../../dds/src/dds/dds.c:893
#7  0x080a0a70 in pthread_start () at pthread/pthread_create.c:200
#8  0x00000000 in ?? ()

After that if I review the discovery information:

SPDP: Connecting builtin endpoints.
?!sdisc
?!sdisc
Domain 0 (pid=95): {1}
        GUID prefix: 6003b4df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        Entity name: Technicolor Chatroom
        Flags: Enabled
        Meta Unicast: 
                UDP:192.168.0.3:7600(3) {MD,UC} H:3
        Meta Multicast: 
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Default Unicast: 
                UDP:192.168.0.3:7601(1) {UD,UC} H:1
        Default Multicast: 
                UDP:239.255.0.1:7401(2) {UD,MC} H:2
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 10 entries (5 readers, 5 writers).
        Resend period: 10.000000000s
        Destination Locators: 
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Discovered participants:
            Peer #0: {25}
                GUID prefix: a37aa173:00492cb6:03e90000
                RTPS Protocol version: v2.1
                Vendor Id: 1.14 - Technicolor, Inc. - Qeo
                Technicolor DDS version: 4.0-0, Forward: 0
                Entity name: Technicolor Chatroom
                Meta Unicast: 
                        UDP:192.168.0.2:7556 {MD,UC}
                        UDP:172.23.1.215:7556 {MD,UC}
                Meta Multicast: 
                        UDP:239.255.0.1:7400(4) {MD,MC} H:4
                Default Unicast: 
                        UDP:192.168.0.2:7557 {UD,UC}
                        UDP:172.23.1.215:7557 {UD,UC}
                Default Multicast: 
                        UDP:239.255.0.1:7401(2) {UD,MC} H:2
                Manual Liveliness: 1
                Lease duration: 50.000000000s
                Endpoints: 6 entries (3 readers, 3 writers).
                Source: 
                        UDP:204.108.0.32:16 {MD,UC}
                Timer = 48.29s

Great! However if i send a message from the Desktop DDS instance (typing something in the chat app) i get the following in my NuttX console:

rtps_receive: unknown submessage type (0x00).

Besided this matter, it seem that NuttX looses track of other participants and then the discovery information gets erased:

!!sdisc
Domain 0 (pid=95): {1}
        GUID prefix: 600834df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        Entity name: Technicolor Chatroom
        Flags: Enabled
        Meta Unicast: 
                UDP:192.168.0.3:7600(3) {MD,UC} H:3
        Meta Multicast: 
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Default Unicast: 
                UDP:192.168.0.3:7601(1) {UD,UC} H:1
        Default Multicast: 
                UDP:239.255.0.1:7401(2) {UD,MC} H:2
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 10 entries (5 readers, 5 writers).
        Resend period: 10.000000000s
        Destination Locators: 
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Discovered participants: <none>

This could be related to the UDP polling implementation. Something interesting that i noticed is that NuttX only accepts the first participant (and only once, if it gets disconnected it doesn't recognize it anymore). If other participants are present in the multicast session NuttX doesn't see them.

Furthermore it seems like there's something wrong with the addresses that other participants receive from NuttX (e.g.: 536928769?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7600 {MD,UC}):

    Discovered participants:
        Peer #0: {25}
        GUID prefix: 6003b4df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        SecureTransport: remote: DDSSEC, local: DDSSEC
        Authorisation: Authenticated
        Entity name: Technicolor Chatroom
        Meta Unicast: 
            536928769?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7600 {MD,UC}
        Meta Multicast: 
            536928769?:00:00:00:00:00:00:00:00:00:00:00:00:ef:ff:00:7400 {MD,MC}
        Default Unicast: 
            536928513?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7601 {UD,UC}
        Default Multicast: 
            536928513?:00:00:00:00:00:00:00:00:00:00:00:00:ef:ff:00:7401 {UD,MC}
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 8 entries (4 readers, 4 writers).
        Source: 
            UDP:192.168.0.3:7600 {MD,UC}
        Timer = 47.63s
        Peer #1: {34} - Local activity: 21.09s
        GUID prefix: a37aa173:00581070:03e90000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        SecureTransport: remote: DDSSEC, local: DDSSEC
        Authorisation: Authenticated
        Entity name: Technicolor Chatroom
        Meta Unicast: 
            UDP:192.168.0.2:7586 {MD,UC}
            UDP:172.23.1.215:7586 {MD,UC}
        Meta Multicast: 
            UDP:239.255.0.1:7400(6) {MD,MC} H:6
        Default Unicast: 
            UDP:192.168.0.2:7587 {UD,UC}
            UDP:172.23.1.215:7587 {UD,UC}
        Default Multicast: 
            UDP:239.255.0.1:7401(3) {UD,MC} H:3
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 8 entries (4 readers, 4 writers).
        Source: 
            UDP:192.168.0.2:7586 {MD,UC}
            UDP:172.23.1.215:7586 {MD,UC}
        Timer = 28.04s

As it is right now, it seems to me that once the first participant gets accepted something break within the code and makes stops the usual behavior of the DDS within NuttX.

This branch confirms that the issues are not caused by the ringbuffer https://github.com/ros2/ros2_embedded_nuttx/tree/no_ringbuffer.

I noticed that the packages sent by the embedded board have size of 354 while the ones sent by the Desktop instance have 354. I'll dig this way.

@vmayoral 1. It looks like you still have the security code built in. Not that this could lead to issues since the chat program uses the open domain, but the build is a lot bigger than needs to be. Disabling security can be done by adapting the Makefile and not compiling with DDS_SECURITY, and not including the security sources and security plugin.

The embedded board doesn't have a valid MAC address. MAC address 00:00:00:00:00:00 isn't really allowed :-)
I examined the Wireshark trace. The SPDP discovery packet sent by the embedded board contains incorrect locator kinds. Packet 112 for example shows locator kinds of 0x2000e101 i.o. the expected 0x00000001{=UDPv4} (check packet offsets 0x00b6, 0x00d2, 0x00ee and 0x010a). This causes the desktop DDS to recognize the embedded board, but it isn't possible for it to start a real communication session due to these incorrect/unknown locators. The Embeddded board seems to work properly after that. It even sends correct SEDP discovery data. It looks like when you find a fix for the incorrect locator kinds your system should really start communicating properly :-) Very nice progress!

@jvoe thanks a lot for your comment! That shrinks it down quite a bit :). It totally makes sense because the Locators shown in the desktop (readed from the network) don't look good:

Domain 0 (pid=96): {1}
    GUID prefix: a37aa173:00607e44:03e90000
    RTPS Protocol version: v2.1
    Vendor Id: 1.14 - Technicolor, Inc. - Qeo
    Technicolor DDS version: 4.0-0, Forward: 0
    SecureTransport: none
    Authorisation: Authenticated
    Entity name: Technicolor Chatroom
    Flags: Enabled
    Meta Unicast: 
        UDP:192.168.0.2:7602(4) {MD,UC} H:4
        UDP:172.23.1.215:7602(5) {MD,UC} H:5
    Meta Multicast: 
        UDP:239.255.0.1:7400(6) {MD,MC} H:6
    Default Unicast: 
        UDP:192.168.0.2:7603(1) {UD,UC} H:1
        UDP:172.23.1.215:7603(2) {UD,UC} H:2
    Default Multicast: 
        UDP:239.255.0.1:7401(3) {UD,MC} H:3
    Manual Liveliness: 0
    Lease duration: 50.000000000s
    Endpoints: 10 entries (5 readers, 5 writers).
    Security: level=Unclassified, access=any, RTPS=clear
    Resend period: 10.000000000s
    Destination Locators: 
        UDP:239.255.0.1:7400(6) {MD,MC} H:6
        TCP:239.255.0.1:7400 {MD,MC}
    Discovered participants:
        Peer #0: {25}
        GUID prefix: 600334df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        SecureTransport: remote: DDSSEC, local: DDSSEC
        Authorisation: Authenticated
        Entity name: Technicolor Chatroom
        Meta Unicast: 
            536928769?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7600 {MD,UC}
        Meta Multicast: 
            536928769?:00:00:00:00:00:00:00:00:00:00:00:00:ef:ff:00:7400 {MD,MC}
        Default Unicast: 
            536928513?:00:00:00:00:00:00:00:00:00:00:00:00:c0:a8:00:7601 {UD,UC}
        Default Multicast: 
            536928513?:00:00:00:00:00:00:00:00:00:00:00:00:ef:ff:00:7401 {UD,MC}
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 6 entries (3 readers, 3 writers).
        Source: 
            UDP:192.168.0.3:7600 {MD,UC}
        Timer = 41.66s

I reviewed package 112 and looked for "locators of kind" 0x2000e101 but i don't find anywhere this bytes in the package. Would you mind pointing out exactly which field you refer to?

screenshot from 2014-10-17 15 04 01

@jvoe regarding your point 1) I'm using these flags to compile the embedded DDS implementation. As you can see DDS_SECURITY is not present. Can you suggest which one else I should add/drop to shrink the image?

@vmayoral I used Wireshark 1.12.1 which also shows the packet offsets. For packet 112, check packet offset 0xb6 for example in the lower window, which shows the byte sequence 01 E1 00 20. Click on the first byte and Wireshark shows where it belongs in the interpreted trace. Turn it around (little-endian), and you get 0x2000e101, where we expect 0x00000001. :-)

@vmayoral For point 1, I see that the compile flags are correct. I was confused by the output of 'sdisc' on the desktop, which does have the security features enabled (it shows Security: level= ... ).

@jvoe thanks a lot for the explanation. Got it and working on it now.

Also modified, the Ethernet MAC to something valid. Didn't change much, still getting thousands of ACKNACK but that should be fine now.

@jvoe i spent some time trying to figure out where exactly in the code the Unicast locators -kind gets populated but I haven't been able to track it down.

I also realized that the IPs of the unicast and multicast locators are also messed (they have a :: prefix in all cases). The closest i've got is reaching https://github.com/ros2/ros2_embedded_nuttx/blob/master/dds/src/rtps/rtps_msg.c#L321. But i still don't see where it gets populated.

Since this is performed by different events, breaking in the code when the device is about to send something doesn't help much either so i am guessing i might not be looking in the right place.

Would you mind providing a pointer? where are the messages data populated to be sent?

@vmayoral The IPs aren't really messed up. Since the kind field is corrupted, it can't display them properly.

The place where the discovery submessages are created is in the Discovery marshalling code. Marshalling is different between normal CDR marshalling (as defined in CORBA) and the variant of Parameter List CDR marshalling that Discovery uses. Mutable types marshalling, as defined in X-types is an evolutionary variant of the Discovery marshalling and is a lot more powerful.

Discovery marshalling and unmarshalling is done using the code in xtypes/pid.c and xtypes/pl_cdr.c. For marshalling the SPDP message that would be: pid_add_participant_data() calling pid_locators_add(), pid_add(), ending up in pid_locator_write().

The marshalling is done long before the rtps_msg_add_data() is called. Just put a breakpoint in pid_locator_write() and check if the kind field is still ok there. If not, it means the locators were already corrupted before the message was queued.

@jvoe thanks for the pointer. I reviewed the value of lp->kind at this point and it is indeed LOCATOR_KIND_UDPv4. As far as I can see this value is populated at the very early stages (and for each locator) of the DDS setup:

#0  pid_locator_write (dst=0x20011c38 <incomplete sequence \341>, src=0x1000ff24)
    at ../../../dds/src/xtypes/pid.c:1226
#1  0x08040892 in pid_add (buf=0x20011c38 <incomplete sequence \341>, pid=72, data=0x1000ff24)
    at ../../../dds/src/xtypes/pid.c:3388
#2  0x08041546 in pid_locators_add (p=0x20011c34 "H", pid=72, lp=0x1000ff50)
    at ../../../dds/src/xtypes/pid.c:3663
#3  0x0804166a in pid_add_participant_data (p=0x20011c34 "H", dp=0x20005540)
    at ../../../dds/src/xtypes/pid.c:3691
#4  0x0803d182 in pl_participant_marshall (dp=0x20011be4, p=0x1000fac0)
    at ../../../dds/src/xtypes/pl_cdr.c:292
#5  0x0803d392 in pl_marshall (dest=0x20011be4, data=0x20011b38, ts=0x20010308, key=0, swap=0)
    at ../../../dds/src/xtypes/pl_cdr.c:393
#6  0x08021970 in DDS_MarshallData (buffer=0x20011be0, data=0x20011b38, dynamic=0, ts=0x200102d8)
    at ../../../dds/src/xtypes/xtypecode.c:1085
#7  0x08073232 in remote_reader_new_change (rrp=0x200105f0, cp=0x20011b10, mctypes=0x10004c50, rmarshall=1, 
    no_mcast=0) at ../../../dds/src/rtps/rtps_main.c:1470
#8  0x080739b2 in rtps_writer_new_change (user=536937872, cp=0x20011b10, hci=0x20011ac0)
    at ../../../dds/src/rtps/rtps_main.c:1908
#9  0x0805bd4a in hc_add_i (hcp=0x20010520, ip=0x20011ac0, cp=0x20011b10)
    at ../../../dds/src/cache/cache.c:2868
#10 0x0805c8e6 in hc_add (hcp=0x20010520, ip=0x20011ac0, lp=0x20011ac8, cp=0x20011b10, 
    kind=NOT_ALIVE_UNREGISTERED, disp_cnt=0x20011af8, no_w_cnt=0x20011afc, rel=0)
    at ../../../dds/src/cache/cache.c:3302
#11 0x0805c9a0 in hc_add_inst (cache=0x20010520, cp=0x20011b10, hci=0x20011ac0, rel=0)
    at ../../../dds/src/cache/cache.c:3343
#12 0x08073c6c in rtps_writer_write (w=0x20010410, data=0x10004d78, length=4, h=1, hci=0x20011ac0, 
    time=0x10004d70, dests=0x0, ndests=0) at ../../../dds/src/rtps/rtps_main.c:2176
#13 0x080918ac in spdp_start (dp=0x1000fac0) at ../../../dds/src/disc/disc_spdp.c:252
#14 0x08057df4 in disc_start (domain=0x1000fac0) at ../../../dds/src/disc/disc_main.c:480
#15 0x0807248e in rtps_participant_create (dp=0x1000fac0) at ../../../dds/src/rtps/rtps_main.c:779
#16 0x080491a8 in DDS_DomainParticipant_enable (dp=0x1000fac0) at ../../../dds/src/dcps/dcps_part.c:520
#17 0x0804865a in DDS_DomainParticipantFactory_create_participant (domain=0, 
    qos=0x20000ed0 <dcps_def_participant_qos>, listener=0x0, mask=(unknown: 0))
    at ../../../dds/src/dcps/dcps_dpfact.c:196
#18 0x0801142c in dds_chat_main (argc=1, argv=0x10004f74) at main.c:573
#19 0x080034b6 in task_start () at task/task_start.c:139
#20 0x00000000 in ?? ()

After debugging the issue it seems that memcpy is just not copying anything. Please take a look at this capture which shows a debugging session picturing this issue:

screenshot from 2014-10-20 11 40 33

In the left terminal you should see a session that:

checks the address of dst
verifies the value of lp->kind
prints the memory at dst
n to go step through the code (which should copy the content)
print again memory at starting at dst

Something is clearly wrong with that memory. We tracked down the allocation at 0x1000381c and we found out that DDS is dynamically allocating in that space (which corresponds to the CCM memory). Judging from the content and results so far it seems that memory is writable but pid_locator_write() clearly can't. @nuttx is it possible that writting into CCM memory requires some sort of alignment? In your opinion is it ok to use this memory for our purposes?

We tried getting rid of this memory activating the following flags:

CONFIG_STM32_HAVE_CCM=y
# CONFIG_STM32_CCMDATARAM is not set
CONFIG_STM32_CCMEXCLUDE=y

Unfortunately it seems like this way we have not enough memory

nsh> dds_chat
Network configured, starting DDS chat:
List pools created.
String pool initialized.
Typecode pools created.
Typesupport initialized.
Socket handler initialized.
Timer pool initialized.
Data buffer pools created.
Random host identifier generated.
Unique GUID prefix created: 6004b4df:00000004:00060000
Locator pools created.
History cache pools created.
Entities: reserved=98, maximum=4294967295
Domain pools created.
RTPS Initialised.
IP: scope = link..global
IP interfaces:
    eth0     : 192.168.0.3
RTPS over IPv4 Initialised.
QoS pools initialized.
DDS: core thread created.
str_new: out of memory!
Can't register ParticipantMessageData type!
Exiting program!

@vmayoral Hmm ... I'm at a loss here. The code looks straightforward enough and seems to work properly on all the devices we've used so far. I guess there must be something wrong either with the dst memory (incorrectly mapped?) or with the generated code (compiler optimizations?). Either way, digging a bit deeper seems important here. Btw, the destination buffer is somewhere in an allocated block from the DB pool (or malloc-ed if -DFORCE_MALLOC was used) in which marshalling is done.

@vmayoral "is it possible that writting into CCM memory requires some sort of alignment? In your opinion is it ok to use this memory for our purposes?"

I am not an STM32 hardware expert. As far as I know, the memory works the same as any other SRAM, but lies on a different bus that is not accessible by certain things (like DMA).

@jvoe and @nuttx thanks for your help. We will try to work without the CCM memory for now which means that we'll have to find room for DDS within the 112K of SRAM.

@jvoe using the spool command i can see that:

....
Pool/max/xmax/used/xused memory = 8192/8192/10008/8192/9312 bytes (263 mallocs) (222%/213%)
Dynamically allocated: 2112 bytes.
malloc statistics: 57 blocks, 3405 bytes, 0 failures.
realloc statistics: 4 blocks, 136 bytes, 0 failures.
free statistics: 31 blocks, 1429 bytes.
Dynamic pool block stats: <=64K - max/used/msize/size: 2/1/248/336
                           >64K - max/used           : 0/0
Total heap memory: 18200 bytes.

I presume that the SRAM size that we are looking for is of 18200 bytes, right?

In the NuttX side, @nuttx do you know if there's any memory introspection/monitoring tool within NuttX that could be useful for this task?

@vmayoral "do you know if there's any memory introspection/monitoring tool within NuttX that could be useful for this task?"

The NSH shell supports a free command. There is a apps/system/free command as well (never used it). I don't really know what task you are talking about or what you would like this tool to do so I don't have any clear answer for you.

I think that it is proper that ROS runs in 192KiB. That is a lot of memory for an embedded platform. If you can't fit into 192KiB, then you probably don't really have a solution for the deeply embedded world.

BUT... it is also good to separate the functional development from the size reduction efforts so that you can make progress on one or the other. Have you considered using a compatible board with more memory? The STM32F407 supports external memory that can be used to extend the internal memory. The STM32F4 Discovery does not not have external memory. But this board has a similar processor and is well supported by NuttX: http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252216 . This board has 1MiB of external SRAM.

Greg

Oops..16 Mbit SRAM = 2Mbyte SRAM, not 1.

The NSH shell supports a free command. There is a apps/system/free command as well (never used it). I don't really know what task you are talking about or what you would like this tool to do so I don't have any clear answer for you.

My bad, i meant some sort of tool that allows to inspect the memory status while the software is running. I guess this can be simulated with an extra thread and the app you pointed out apps/system/free.

Also, @nuttx thanks for the suggestion about the board we will get it and continue development with it. I can see their linker script doesn't consider the extra SRAM. Do you have experience with the board so that you can recommend how to set up the memory map?

I think that it is proper that ROS runs in 192KiB. That is a lot of memory for an embedded platform. If you can't fit into 192KiB, then you probably don't really have a solution for the deeply embedded world.

In our current dev board we are using solely 128 KiB (112KiB + the 16 KiB which seem contiguous according to the datasheet). I am afraid the 64 KiB extra bring the non-writable issue (as far as we've tested.).

@nuttx I'm trying to make DDS to standalone on top of NuttX (without NSH) and for that purpose this commit pretends to create a simple hello world standalone app. However when compiling:

...
CC:  stm32_boot.c
CC:  stm32_bringup.c
CC:  stm32_spi.c
CC:  stm32_cxxinitialize.c
CC:  stm32_autoleds.c
CC:  stm32_buttons.c
CC:  stm32_nsh.c
AR:   stm32_boot.o stm32_bringup.o stm32_spi.o stm32_cxxinitialize.o stm32_autoleds.o stm32_buttons.o stm32_nsh.o
make[2]: Leaving directory `/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/configs/stm32f4discovery/src'
LD: nuttx
/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/lib/libsched.a(os_bringup.o): In function `os_do_appstart':
/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/sched/init/os_bringup.c:279: undefined reference to `hello_main'
/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/sched/init/os_bringup.c:279: undefined reference to `hello_main'
make[1]: *** [nuttx] Error 1

Besides the standalone trials, i'm trying to make sense of the output from the free command in NSH:

nsh> free
                      total       used       free    largest
Mem:         77520      15264      62256      62256

The total memory displayed is ~ 77 KiB, where are the ~ 51 KiB left (up to the 128 KiB configured in the linker script)? Is it possible that those ~ 51 KiB not displayed correspond to the memory used by the NuttX kernel? If so, do the ~ 15 KiB (displayed as used) correspond to NSH?

@vmayoral " I can see their linker script doesn't consider the extra SRAM. Do you have experience with the board so that you can recommend how to set up the memory map?"

There are two classes of RAM usage: Statically allocated RAM and dynamically allocated RAM. The linker script only addresses where you will put statically defined data and must be one contiguous region of RAM. So the external RAM has nothing to do with the linker script. It gets added to heap for dynamic memory allocation. When you do the NSH free command, you will see the extra RAM.

"The total memory displayed is ~ 77 KiB , where are the ~ 51 KiB left (up to the 128 KiB configured in the linker script)? Is it possible that those ~ 51 KiB not displayed correspond to the memory used by the NuttX kernel? If so, do the ~ 15 KiB (displayed as used) correspond to NSH? "

Almost the same discussion. The free command only shows the usage of the dynamically allocated RAM, not the statically allocated RAM. If you have 112KiB memory in use and the heap is 75KiB, then you are using up 37KiB for static data storage. NuttX typically only uses a few hundred bytes for static data storage (unless you configure large buffer sizes), so this is most likely being used by your application.

You can use the size command on the ELF file to see the static memory usage. Like:

$ size nuttx text data bss dec hex filename 40235 88 1632 41955 a3e3 nuttx

Which is for a much smaller configuration than yours. I also use this script called showsize.sh to example memory usage:

$ cat showsize.sh NM=arm-none-eabi-nm echo "TOP 10 BIG DATA" $NM --print-size --size-sort --radix dec -C nuttx | grep ' [DdBb] ' | tail -20 echo "TOP 10 BIG CODE" $NM --print-size --size-sort --radix dec -C nuttx | grep ' [TtWw] ' | tail -20

$ ./showsize.sh nuttx TOP 10 BIG DATA 536872224 00000008 B g_sigpendingirqaction 536872232 00000008 B g_sigpendingirqsignal 536872240 00000008 B g_sigpendingsignal 536870956 00000008 d g_uart0priv 536871760 00000008 B g_waitingformqnotempty 536871784 00000008 B g_waitingformqnotfull 536871768 00000008 B g_waitingforsemaphore 536871800 00000008 B g_waitingforsignal 536872260 00000008 B g_wdactivelist 536872248 00000008 B g_wdfreelist 536870964 00000024 d g_uart0config 536870912 00000044 d g_uart0port 536871064 00000064 b g_uart0rxbuffer 536871000 00000064 b g_uart0txbuffer 536871364 00000096 b g_wdpool 536871808 00000128 B g_pidhash 536871128 00000204 b g_idletcb 536871956 00000252 B g_irqvector 536871460 00000256 b g_iobuffer 536872268 00000324 B g_mmheap TOP 10 BIG CODE 00021108 00000292 T cmd_ls 00020400 00000308 T cmd_cat 00032148 00000312 T sigtimedwait 00030988 00000336 T pthread_create 00006288 00000352 T os_start 00024044 00000380 T cmd_hexdump 00019776 00000392 t ls_handler 00002132 00000392 T up_assert 00020708 00000400 T cmd_cp 00019192 00000400 t cmd_help 00008340 00000432 T sig_tcbdispatch 00037832 00000496 t g_cmdmap 00005656 00000604 T udivsi3 00015952 00000616 T cle 00021980 00000632 T cmd_dd 00012692 00000656 T lib_vsprintf 00004884 00000768 T udivdi3 00024424 00000784 t expression 00004032 00000850 T __divdi3 00017048 00001792 t nsh_parse_command

Greg

@vmayoral Also, here is way that you can recover that CCM RAM if you want to make use of it: http://www.nuttx.org/doku.php?id=wiki:howtos:stm32-ccm-alloc

@nuttx thanks for the explanation. Much appreciated. Executing showsize indeed shares some interesting information. I'll share it here:

victor@frcsim:~/Dropbox/OSRF/ros2_embedded_nuttx/nuttx$ source tools/showsize.sh nuttx
TOP 20 BIG DATA
536875176 00000128 D log_id_str
536916532 00000132 B qos_def_topic_qos
536916664 00000140 B qos_def_writer_qos
536919252 00000148 B rtps_transmitter
536872432 00000160 d td_fields
536915872 00000176 B g_mmheap
536874428 00000176 d pid_type_desc
536919532 00000192 B g_udp_connections
536875304 00000196 d common_pars
536879364 00000224 d keywords
536877348 00000224 d udp_pars
536877040 00000308 d ip_pars
536876648 00000392 d rtps_pars
536915404 00000396 B g_irqvector
536917044 00000504 B dcps_mem_blocks
536918576 00000576 B rtps_mem_blocks
536917816 00000760 B rtps_receiver
536877572 00001000 d groups
536875500 00001148 d pool_pars
536872804 00001160 d known_pids
TOP 20 BIG CODE
134290872 00002014 T DDS_get_default_pool_constraints
134425564 00002090 t dyn_value_ptr
134845288 00002100 T tcp_input
134734964 00002136 t sfr_rel_data
134747420 00002192 t sfw_rel_acknack
134442308 00002684 t cdr_generate
134612724 00002690 T debug_command
134815336 00002726 T sql_next_token
134721872 00002958 t submsg_rx_data_frag
134658848 00003288 t md5_transform
134635208 00003330 T bc_dump
134707648 00003368 T rtps_msg_add_data
134500296 00003702 t vtc_create_type
134496264 00003786 t vtc_generate
134713044 00003800 t submsg_rx_data
134454756 00003908 t cdr_parse
134504664 00004538 t vtc_equal_type
134490208 00006056 T vtc_validate
134627540 00007666 T bc_interpret
134298964 00008320 T dds_init

@vmayoral Also, here is way that you can recover that CCM RAM if you want to make use of it: http://www.nuttx.org/doku.php?id=wiki:howtos:stm32-ccm-alloc

Please refer to https://github.com/ros2/ros2_embedded_nuttx/issues/16 which is is the result of using this commit. Since i couldn't find the CONFIG_MM_MULTIHEAP option I added it manually to the .config file. I believe that i'm calling ccm_initialize() soon enough. But it seems that something else is required.

Also, is it possible to get your comments on what is wrong with the simple hello world standalone app. I recall having made something similar in previous versions of NuttX and succeed:

...
CC:  stm32_boot.c
CC:  stm32_bringup.c
CC:  stm32_spi.c
CC:  stm32_cxxinitialize.c
CC:  stm32_autoleds.c
CC:  stm32_buttons.c
CC:  stm32_nsh.c
AR:   stm32_boot.o stm32_bringup.o stm32_spi.o stm32_cxxinitialize.o stm32_autoleds.o stm32_buttons.o stm32_nsh.o
make[2]: Leaving directory `/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/configs/stm32f4discovery/src'
LD: nuttx
/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/lib/libsched.a(os_bringup.o): In function `os_do_appstart':
/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/sched/init/os_bringup.c:279: undefined reference to `hello_main'
/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/sched/init/os_bringup.c:279: undefined reference to `hello_main'
make[1]: *** [nuttx] Error 1

@vmayoral This is the only OS-related stuff in your top 10 lists:

536915872 00000176 B g_mmheap 536919532 00000192 B g_udp_connections 536915404 00000396 B g_irqvector

/home/victor/Dropbox/OSRF/ros2_embedded_nuttx/nuttx/sched/init/os_bringup.c:279: undefined reference to `hello_main'

You cannot ever reliable change the configuration without doing 'make distclean' or this will always happen (but be careful with 'make distclean' because it clobbers your .config too). So your configuration is corrupted again (that will happen VERY frequently if you hand edit the .config file). This might allow you recover:

make apps_distclean all

If not, you will need to do 'make distclean'

Greg

@nuttx thanks for the reminder. Still i believe there's some kind of issue. This is how i proceed:

make distclean
cd tools
 ./configure.sh stm32f4discovery/hello_standalone
cd ..
make

Being this file the defconfig of the hello_standalone app. Am i missing something?

@vmayoral CONFIG_EXAMPLES_HELLO is not set so, of course, the hello example that provides hello_main() will not be built.

@nuttx great, i was actually creating the apps in other directories. Good that it's clear now :).

A small query on the STM3240G-EVAL, we just received the board and set it up for development. I flashed NuttX with our DDS application and checked the SRAM available with the free command in NSH:

nsh> free
             total       used       free    largest
Mem:         78528      15184      63344      63344

Here i was expecting much more (actually 2 MB more). I see in the ChangeLog that:

* configs/stm3240g-eval/,arch/arm/src/stm32/up_allocateheap.c: Add support for the 16-mbit SRAM on-board the STM3240G-EVAL board.

Is there a specific option that i should activate in order to make use of the additional SRAM? Thanks!

Just for the record, i checked the jumpers several times according to the manual and datasheets and the memory should be available.

@nuttx i found the configuration requirements :+1:, i was missing this as well as to activate the peripheral. Although it does compile i get the following hardfault when using the free command from NSH:

up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 183
up_dumpstate: sp:         2000f860
up_dumpstate: stack base: 2000faf0
up_dumpstate: stack size: 00000fe4
up_stackdump: 2000f860: 000000b7 080011a5 080010bb c0000000 2000ea70 00000006 00000001 2000f920
up_stackdump: 2000f880: 00000000 08000d73 2000aa90 0800180b 08096bb8 08000bf5 00000000 00000001
up_stackdump: 2000f8a0: 2000ad3c 2000f924 00003b50 0800047f 2000f8f8 00000000 00000001 2000ad3c
up_stackdump: 2000f8c0: 2000f924 00003b50 2000ad40 400291f0 2000cd48 00000003 00000000 fffffff8
up_stackdump: 2000f8e0: 2000cd48 40019a80 00000000 08001bc3 0809587a 01000000 08007715 200107e0
up_stackdump: 2000f900: 2000f924 2000f954 08097248 2001083c 2000f9fc 00000001 00000000 0809581d
up_stackdump: 2000f920: 00000000 00000000 00000000 080090c7 200107e0 00000001 200107e0 08097268
up_stackdump: 2000f940: 00000001 08007721 0800090f 20000000 00000001 08001411 00000000 200107e0
up_stackdump: 2000f960: ffffffff 200107e0 2000f9fc 200107e0 08097268 0800632b 00000000 200107e0
up_stackdump: 2000f980: 00000000 00000000 ffffffff 2000f9fc 2000f9fc 0800535d 00000000 08001411
up_stackdump: 2000f9a0: 00000000 20000000 00000100 08000a9f 08000a5d 2000aa90 08096bb8 200107e0
up_stackdump: 2000f9c0: 2001083c 00000001 00000000 00000000 2000f9fc 00000000 00000000 08005def
up_stackdump: 2000f9e0: 00000000 00000000 20000000 00000000 2000fa70 20010841 00000000 2001083c
up_stackdump: 2000fa00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
up_stackdump: 2000fa20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
up_stackdump: 2000fa40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
up_stackdump: 2000fa60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
up_stackdump: 2000fa80: 00000000 00000000 00000000 00000000 00000000 00000000 2001083c 200107e0
up_stackdump: 2000faa0: 2001083c 2000e844 00000000 00000000 00000000 00000000 00000000 08007e3d
up_stackdump: 2000fac0: 200107e0 00000000 200107e0 00000000 00000000 08004a51 00000003 080049b9
up_stackdump: 2000fae0: 00000000 08001b89 00000000 00000000 10001100 2000fafc 00000000 6e6f6e3c
up_registerdump: R0: 00000000 fffffff8 2000cd48 40019a80 00000001 2000ad3c 2000f924 00003b50
up_registerdump: R8: 2000ad40 400291f0 2000cd48 00000003 00000000 2000f8f8 08001bc3 0809587a
up_registerdump: xPSR: 01000000 PRIMASK: 00000000 CONTROL: 00000000

Something analogous happens if I launch the application

Ok, the following formula did it:

  CONFIG_STM32_FSMC=y
  CONFIG_STM32_FSMC_SRAM=y
  CONFIG_HEAP1_BASE=0x64000000
  CONFIG_HEAP2_SIZE=2097152
  CONFIG_MM_REGIONS=2

(my bad, it was actually quite well explained in the README)

@nuttx we are struggling with the STM3240g-eval trying to make use of the additional memory. We have not been able to use it allocate static variables, neither to allocate dynamic memory.

dynamical memory allocation:

As far as we understand NuttX code, there's no need to modify the linker script because the memory mapping takes care of it if the CONFIG_STM32_FSMC_SRAM is activated. NSH free command indeed informs about the additional, available memory:

nsh> free
             total       used       free    largest
Mem:       2175680      15200    2160480    2097136

Using this linker script and launching the application and stepping through the code:

(gdb) p *dst
Cannot access memory at address 0x640003bc
(gdb) p dst
$1 = (unsigned char *) 0x640003bc <error: Cannot access memory at address 0x640003bc>

It seems like the memory allocator returned a pointer to the FSMC memory but gdb is not able to access it. This gets reflected in the application's behaviour setting wrong values to variables.

statically allocated memory:

Using this linker script (that creates a section for sram2 and defines it as NOLOAD, otherwise the nuttx ELF becomes 1.5 GB). This gist pictures our memory map which shows that there's one variable defined in the FSMC SRAM (starting at 64000000) but when launching the application the stack pointer just goes somewhere invalid:

nsh> dds_chat
Neup_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 183
up_dumpstate: sp:         20012610
up_dumpstate: stack base: 20012c00
up_dumpstate: stack size: 00001fe4
up_stackdump: 20012600: 08000e11 08096a84 08096a04 00001fe4 08000e11 08096a84 08096a04 00001fe4
up_stackdump: 20012620: 08000e11 08096a84 08096a04 00001fe4 00000000 08000d73 2000a9d0 0800180b
up_stackdump: 20012640: 08096bc0 08000bf5 00000000 00000004 20001f54 00000000 20001f60 0800047f
up_stackdump: 20012660: 200126a8 00000000 00000004 20001f54 00000000 20001f60 20001f6c 00000007
up_stackdump: 20012680: 20001f58 20001f6c 80000000 00000020 80000001 80000000 fffff8ff 08065de1
up_stackdump: 200126a0: 08065b64 81000000 00000020 80000001 08094389 5889000a 20001f54 20001f60
up_stackdump: 200126c0: 64000054 64000000 0000000a 080945ff 00000000 20001f58 08065dbd 08094397
up_stackdump: 200126e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
up_stackdump: 20012700: 00000000 08065e75 00000007 640000c4 20001f4c 00000007 00000000 08065e8d
up_stackdump: 20012720: 00000000 080667b7 20010a3c 08002eb7 20010a3c 08094375 08094389 08094381
up_stackdump: 20012740: 2000a9e4 08001bed 00000000 200000a0 00000000 00000004 2000009c 00000000
up_stackdump: 20012760: 00000004 08092dad 00000000 00000000 00000000 0800d3bd 2000af6c 0801470d
up_stackdump: 20012780: 2001283c 2001e674 00000100 2001e690 2001283c 2001e674 00000000 08061d95
up_stackdump: 200127a0: 080146a9 20012838 2001283c 20004de0 00000100 20004dec 20004dec 20004dec
up_stackdump: 200127c0: 08096bc0 00000000 2000af6c 0801470d 2000aaa4 0800d967 00000000 20004e30
up_stackdump: 200127e0: 2000af6c 00000004 00000000 20000000 00000100 08000a9f 00000000 20000000
up_stackdump: 20012800: 00000100 08000a9f 08000a5d 2000aa90 08096bc0 2000aa90 20012838 08000bff
up_stackdump: 20012820: 00000000 00000000 2000af6c 00000000 00000000 0800047f 20012880 00000000
up_stackdump: 20012840: 00000000 2000af6c 00000000 00000000 00000000 00000000 00000000 20000000
up_stackdump: 20012860: 00000100 08000a9f 08000a5d 2000aa90 2001289c 0801ab8b 20012898 08000bff
up_stackdump: 20012880: 00000000 20000000 200128b4 0801ab8b 00000000 00000010 20012acc 20012a38
up_stackdump: 200128a0: 20000000 00000000 00000000 00000010 20012ae4 20012a50 00000001 00000020
up_stackdump: 200128c0: 200128f0 08000d99 08096bc0 2000aa90 640063d8 08000bff 00000001 20000006
up_stackdump: 200128e0: 20010890 00000000 00000000 20000000 00000100 08000a9f 08000a5d 2000aa90
up_stackdump: 20012900: 08096bc0 2000aa90 20012928 08000bff 00000000 20000000 00000000 20010c64
up_stackdump: 20012920: 00000024 0800047f 20012970 00000000 20000000 00000000 20010c64 00000024
up_stackdump: 20012940: 00000000 2000000c 00000000 20000000 00000100 08000a9f 08000a5d 2000a9d0
up_stackdump: 20012960: 08096bc0 2000a9d0 20012988 08000bff 00000000 20000000 00000000 20010ba7
up_stackdump: 20012980: 00000027 0800047f 200129d0 00000000 20000000 00000000 20010ba7 00000027
up_stackdump: 200129a0: 00000000 2000000c 00000001 0000000a 20000000 0000004e 0000004d 0800090f
up_stackdump: 200129c0: fffff8ff 0800092f 08000944 61004000 0800090f 20000000 20000000 080011a5
up_stackdump: 200129e0: 080010bb c0000000 20010b80 00000027 00000001 20012a98 20012acc 00000000
up_stackdump: 20012a00: 00000000 0808d74f 2001097c 08002b27 08094389 0000000a 2001097c 20012acc
up_stackdump: 20012a20: 0809884a 080956ef 80000000 2001097c 2001097c 08002b27 08094381 2001097c
up_stackdump: 20012a40: 08098824 20012acc 00000000 00000004 00000000 00000004 00000001 080034a3
up_stackdump: 20012a60: 00000001 08001bed 2000a9e4 00000075 00000000 080034e9 08003509 00000001
up_stackdump: 20012a80: 00000000 20012ad0 0809884c 00000000 00000000 00000000 00000000 0803f855
up_stackdump: 20012aa0: 00000000 00000000 00000000 00000000 08003509 00000006 20012c04 00000001
up_stackdump: 20012ac0: 00000000 00000000 0800a685 00000000 00000000 0800a6c7 425b5b5b 425b425b
up_stackdump: 20012ae0: 20012c04 00000001 00ffffff 425b425b 425b425b 425b425b 425b425b 425b425b
up_stackdump: 20012b00: 425b425b 425b425b 425b425b 425b425b 425b425b 425b425b 425b425b 425b425b
up_stackdump: 20012b20: 425b425b 425b425b 2001cb88 00000000 00003cd2 08001c2d 00000000 08001c3b
up_stackdump: 20012b40: 00000014 6400644c 64006440 6400644c 00000001 64006440 00000014 08092b87
up_stackdump: 20012b60: 2000aef8 00000000 00000000 00000000 00000000 00000000 00000000 00000000
up_stackdump: 20012b80: 20000054 2000aea4 00000001 00000000 00000000 0800aa2d 00000000 00000000
up_stackdump: 20012ba0: 20012cc4 00000001 00ffffff 00000000 7fffffff 7fffffff 00000000 00000000
up_stackdump: 20012bc0: 00000000 7fffffff 7fffffff 00000000 00000000 05f5e100 00000000 00000000
up_stackdump: 20012be0: 00000000 00000000 00000000 00000000 00000000 08001b89 00000000 00000000
up_registerdump: R0: 80000000 00000020 80000001 80000000 00000004 20001f54 00000000 20001f60
up_registerdump: R8: 20001f6c 00000007 20001f58 20001f6c fffff8ff 200126a8 08065de1 08065b64
up_registerdump: xPSR: 81000000 PRIMASK: 00000000 CONTROL: 00000000

We'd appreciate if you could add some comments in both cases.

All right, after much debugging (using the dynamically allocated way) we found out that the packages in the network are being sent corrupted not because of a malfuction in the SRAM but because the kind copy is only 1 byte (an enum) while it's copying 4 bytes.

This commit fixes this aspect however the there still seems to be some issue with the embedded board since the packet interaction is not similar to the one presented by two instances of the Desktop Tinq. @jvoe would you mind advising based on this capture?.

@jvoe one quick thing that i notice is that the IGMP packages sent by the embedded board (192.168.0.3) are actually 14 bytes (all 0s) longer for no reason.

@vmayoral The C compilers we used thus far assume that sizeof(enum x) == sizeof(int) in their default setting. This has been the case for GCC, CLANG and MS Visual C++. For GCC it is possible to optimize the size using the -fshort-enums compile option, and in CLANG you can specify the underlying type, but we don't use that in order to be compatible with the older ansi C89 standard where an enum was always an int. The same reason why we don't use the // comments in DDS, btw. C compilers treat enums differently from C++ compilers. And enum isn't even a real type in C, just sugar coating, whereas it is a real distinct type in C++. We probably should have documented this 'expected behaviour ':-( ...

@vmayoral I had a look at the Wireshark trace. It looks like the RTPS messages aren't properly interpreted or might even be discarded on the embedded board (192.168.0.3). It seems to do a bit more compared to the previous problematic locator handling, but it definitely isn't ok yet. Debug commands might help a lot here: check 'sdisca' on both sides to see if all endpoints were properly discovered, 'sep' to get the full list of endpoints, and 'sproxy ' to verify which packets were properly handled on proxy level. I assume that some packets are discarded at RTPS level due to perceived message errors on the desktop side. Check 'srx' to get detailed RTPS receive processing info on the desktop side. Btw, could you restrict the number of advertised IP addresses on the desktop side to only 192.168.0.2? Having both IP addresses active leads to almost double the amount of packets in the trace, making it a bit harder to figure out what's happening ... ;-).

@jvoe thanks a lot for your support :)!

Unfortunately i'm not sure i understand what you mean by restrict the number of advertised IP addresses on the desktop side to only 192.168.0.2 neither how it could be done but i'd be happy to do it if you could provide some pointers.

It's quite interesting to note that the embedded board seems to forget about the presence of the desktop machine after about 55 seconds. I can verify this with the sdisc command. While the desktop machine shows the presence of a participant (which corresponds to the embedded board), the embedded board shows the Discovered Participants as . This capture shows exactly this behaviour. If you take a look at the packets close to the second 55, you'll appreciate that the embedded board (192.168.0.3) stops sending as many packets. May it be a buffer?

I'm also sharing the DDS debug information (apologies for the long trace):

Embedded board

sdisca

!!sdisca
Domain 0 (pid=89): {1}
        GUID prefix: f29134d9:00590002:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        Entity name: Technicolor Chatroom
        Flags: Enabled
        Meta Unicast:
                UDP:192.168.0.3:7588(3) {MD,UC} H:3
        Meta Multicast:
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Default Unicast:
                UDP:192.168.0.3:7589(1) {UD,UC} H:1
        Default Multicast:
                UDP:239.255.0.1:7401(2) {UD,MC} H:2
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 10 entries (5 readers, 5 writers).
                000001-2, {22}, InlineQoS: No, Writer, Chat/ChatMsg
                000002-7, {24}, InlineQoS: No, Reader, Chat/ChatMsg
        Topics:
            BuiltinParticipantMessageReader/ParticipantMessageData
            BuiltinParticipantMessageWriter/ParticipantMessageData
            Chat/ChatMsg
            SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData
            SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData
            SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData
            SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData
            SPDPbuiltinParticipantReader/ParticipantBuiltinTopicData
            SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData
        Resend period: 10.000000000s
        Destination Locators:
                UDP:239.255.0.1:7400(4) {MD,MC} H:4
        Discovered participants:
            Peer #0: {25}
                GUID prefix: a37aa173:00742be9:03e90000
                RTPS Protocol version: v2.1
                Vendor Id: 1.14 - Technicolor, Inc. - Qeo
                Technicolor DDS version: 4.0-0, Forward: 0
                Entity name: Technicolor Chatroom
                Meta Unicast:
                        UDP:192.168.0.2:7642 {MD,UC}
                        UDP:172.23.1.215:7642 {MD,UC}
                Meta Multicast:
                        UDP:239.255.0.1:7400(4) {MD,MC} H:4
                Default Unicast:
                        UDP:192.168.0.2:7643 {UD,UC}
                        UDP:172.23.1.215:7643 {UD,UC}
                Default Multicast:
                        UDP:239.255.0.1:7401(2) {UD,MC} H:2
                Manual Liveliness: 0
                Lease duration: 50.000000000s
                Endpoints: 6 entries (3 readers, 3 writers).
                Topics:  <none>
                Source: 
                        UDP:127.62.0.8:8 {MD,UC}
                        UDP:0.151.1.32:288 {MD,UC}
                        UDP:12.115.0.32:0 {MD,UC}
                Timer = 0.00s

sep

!!sep
DCPS:
    0/000001-02 W{22}   0/1     Chat/ChatMsg
    0/000002-07 R{24}   0/1     Chat/ChatMsg
    0/000003-c2 W{13}   1/1     SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData
    0/000003-c7 R{9}    0/0     SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData
    0/000004-c2 W{15}   1/1     SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData
    0/000004-c7 R{11}   0/0     SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData
    0/000100-c2 W{5}    1/1     SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData
    0/000100-c7 R{7}    0/0     SPDPbuiltinParticipantReader/ParticipantBuiltinTopicData
    0/000200-c2 W{19}   0/0     BuiltinParticipantMessageWriter/ParticipantMessageData
    0/000200-c7 R{17}   0/0     BuiltinParticipantMessageReader/ParticipantMessageData
RTPS:
    0/000003-c2 W{13}   0/1     SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData
    0/000003-c7 R{9}    0/0     SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData
    0/000004-c2 W{15}   0/1     SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData
    0/000004-c7 R{11}   0/0     SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData
    0/000100-c2 W{5}    1/1     SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData
                            ->  Locator: UDP:239.255.0.1:7400(4) {5}
    0/000100-c7 R{7}    0/0     SPDPbuiltinParticipantReader/ParticipantBuiltinTopicData
    0/000200-c2 W{19}   0/0     BuiltinParticipantMessageWriter/ParticipantMessageData
    0/000200-c7 R{17}   0/0     BuiltinParticipantMessageReader/ParticipantMessageData

sproxy

For starters i can see


0/000003-c2 W{13} - SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData:
    GUID: a37aa173:00762eb5:03e90000-000003-c7 {28} -
        InlineQoS=0, Reliable=1, Active=0, Marshall=1, MCast=1
        States (Control/Tx/Ack): READY/ANNOUNCING/WAITING
        Changes: : (1)
                {UNDERWAY:1     [640048c0*1:ALIVE:h=1,0.1]}
        LastAck=0
        Unicast locators:
                UDP:192.168.0.2:7646
                UDP:172.23.1.215:7646
        Multicast locators:
                UDP:239.255.0.1:7400(4)
        Direct reply locator: not set
        Last: 0.1, Nack-timer: 0.02s, local=2, remote=0
        Next GUID: 0
0/000003-c7 R{9} - SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData:
    GUID: a37aa173:00762eb5:03e90000-000003-c2 {29} -
        Reliable=1, Active=0, MCast=1
        States (Control/Ack): READY/WAITING
        Changes: : (0)
        LastHeartbeat=0
        Unicast locators:
                UDP:192.168.0.2:7646
                UDP:172.23.1.215:7646
        Multicast locators:
                UDP:239.255.0.1:7400(4)
        Direct reply locator: not set
        Next: 0.1, Heartbeat-timer: 0.02s, LocalInst=2, RemoteInst=0
        Next GUID: 0
0/000004-c2 W{15} - SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData:
    GUID: a37aa173:00762eb5:03e90000-000004-c7 {30} -
        InlineQoS=0, Reliable=1, Active=0, Marshall=1, MCast=1
        States (Control/Tx/Ack): READY/ANNOUNCING/WAITING
        Changes: : (1)
                {UNDERWAY:1     [64004e20*1:ALIVE:h=1,0.1]}
        LastAck=0
        Unicast locators:
                UDP:192.168.0.2:7646
                UDP:172.23.1.215:7646
        Multicast locators:
                UDP:239.255.0.1:7400(4)
        Direct reply locator: not set
        Last: 0.1, Nack-timer: 0.24s, local=3, remote=0
        Next GUID: 0
0/000004-c7 R{11} - SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData:
    GUID: a37aa173:00762eb5:03e90000-000004-c2 {31} -
        Reliable=1, Active=0, MCast=1
        States (Control/Ack): READY/WAITING
        Changes: : (0)
        LastHeartbeat=0
        Unicast locators:
                UDP:192.168.0.2:7646
                UDP:172.23.1.215:7646
        Multicast locators:
                UDP:239.255.0.1:7400(4)
        Direct reply locator: not set
        Next: 0.1, Heartbeat-timer: 0.11s, LocalInst=3, RemoteInst=0
        Next GUID: 0
0/000100-c2 W{5} - SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData:
    UDP:239.255.0.1:7400(4) -
        InlineQoS=0, Reliable=0, Active=0, Marshall=1, MCast=1
        States (Control/Tx/Ack): READY/IDLE/WAITING
        Changes: : (1)
                {UNDERWAY:1     [2001ce30*1:ALIVE:h=1,0.1]}
        Next GUID: 0
0/000200-c2 W{19} - BuiltinParticipantMessageWriter/ParticipantMessageData:
    GUID: a37aa173:00762eb5:03e90000-000200-c7 {26} -
        InlineQoS=0, Reliable=1, Active=0, Marshall=1, MCast=1
        States (Control/Tx/Ack): READY/IDLE/WAITING
        Changes: : (0)
        LastAck=0
        Unicast locators:
                UDP:192.168.0.2:7646
                UDP:172.23.1.215:7646
        Multicast locators:
                UDP:239.255.0.1:7400(4)
        Direct reply locator: not set
        Last: 0.1, local=1, remote=0
        Next GUID: 0
0/000200-c7 R{17} - BuiltinParticipantMessageReader/ParticipantMessageData:
    GUID: a37aa173:00762eb5:03e90000-000200-c2 {27} -
        Reliable=1, Active=0, MCast=1
        States (Control/Ack): READY/WAITING
        Changes: : (0)
        LastHeartbeat=0
        Unicast locators:
                UDP:192.168.0.2:7646
                UDP:172.23.1.215:7646
        Multicast locators:
                UDP:239.255.0.1:7400(4)
        Direct reply locator: not set
        Next: 0.1, Heartbeat-timer: 0.02s, LocalInst=1, RemoteInst=0
        Next GUID: 0

but then after about 30-50 seconds

0/000003-c2 W{13} - SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData:
0/000003-c7 R{9} - SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData:
0/000004-c2 W{15} - SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData:
0/000004-c7 R{11} - SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData:
0/000100-c2 W{5} - SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData:
    UDP:239.255.0.1:7400(4) - 
        InlineQoS=0, Reliable=0, Active=0, Marshall=1, MCast=1
        States (Control/Tx/Ack): READY/IDLE/WAITING
        Changes: : (1)
                {UNDERWAY:1     [2001ce30*1:ALIVE:h=1,0.1]}
        Next GUID: 0
0/000200-c2 W{19} - BuiltinParticipantMessageWriter/ParticipantMessageData:
0/000200-c7 R{17} - BuiltinParticipantMessageReader/ParticipantMessageData:

srx

Protocol version: {1, 0}
Src. Vendor Id: {0x0, 0x0}
Src. GUID Prefix: e91c0000:00000000:00000000
Dst. GUID Prefix: 00000000:00000000:00000000
Domain: 2001ab20
# of invalid submessages: 0
# of too short submessages: 0
# of invalid QoS errors: 0
# of out-of-memory errors: 0
# of unknown destination errors: 6
# of invalid marshalling data: 0
Last error: Unknown destination
Last MEP:
:       00 42 00 64 80 41 00 64 - 70 41 00 64 78 00 00 04   .B.d.A.dpA.dx...
        15 07 78 00 00 00 10 00 - 00 00 00 00 00 01 00 c2   ..x.............
        00 00 00 00 01 00 00 00 - 70 00 10 00 f5 79 34 d9   ........p....y4.
        00 59 00 02 00 06 00 00 - 00 00 00 00 01 00 00 00   .Y..............
        00 00 00 00 80 ce 01 20 - 70 ce 01 20 e8 00 00 0a   ....... p.. ....
        e9 1c 00 00 00 00 00 00 - 30 ce 01 20 00 00 00 00   ........0.. ....
        ef ff 00 01 32 00 18 00 - 01 00 00 00 de 1d 00 00   ....2...........
        00 00 00 00                                         ....
Last domain: 0
Last msg:
:       00 00 10 00 00 00 00 00 - 00 00 01 02 00 00 00 00   ................
        01 00 00 00                                         ....

Desktop machine

sdisca

!!sdisca
Domain 0 (pid=116): {1}
    GUID prefix: a37aa173:00742be9:03e90000
    RTPS Protocol version: v2.1
    Vendor Id: 1.14 - Technicolor, Inc. - Qeo
    Technicolor DDS version: 4.0-0, Forward: 0
    SecureTransport: none
    Authorisation: Authenticated
    Entity name: Technicolor Chatroom
    Flags: Enabled
    Meta Unicast: 
        UDP:192.168.0.2:7642(4) {MD,UC} H:4
        UDP:172.23.1.215:7642(5) {MD,UC} H:5
    Meta Multicast: 
        UDP:239.255.0.1:7400(6) {MD,MC} H:6
    Default Unicast: 
        UDP:192.168.0.2:7643(1) {UD,UC} H:1
        UDP:172.23.1.215:7643(2) {UD,UC} H:2
    Default Multicast: 
        UDP:239.255.0.1:7401(3) {UD,MC} H:3
    Manual Liveliness: 0
    Lease duration: 50.000000000s
    Endpoints: 10 entries (5 readers, 5 writers).
        000001-2, {22}, InlineQoS: No, Writer, Chat/ChatMsg
        000002-7, {24}, InlineQoS: No, Reader, Chat/ChatMsg
    Topics: 
        BuiltinParticipantMessageReader/ParticipantMessageData 
        BuiltinParticipantMessageWriter/ParticipantMessageData 
        Chat/ChatMsg 
        SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData 
        SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData 
        SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData 
        SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData 
        SPDPbuiltinParticipantReader/ParticipantBuiltinTopicData 
        SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData 
    Security: level=Unclassified, access=any, RTPS=clear
    Resend period: 10.000000000s
    Destination Locators: 
        UDP:239.255.0.1:7400(6) {MD,MC} H:6
        TCP:239.255.0.1:7400 {MD,MC}
    Discovered participants:
        Peer #0: {25} - Local activity: 8.04s
        GUID prefix: f29134d9:00590002:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0, Forward: 0
        SecureTransport: remote: DDSSEC, local: DDSSEC
        Authorisation: Authenticated
        Entity name: Technicolor Chatroom
        Meta Unicast: 
            UDP:192.168.0.3:7588 {MD,UC}
        Meta Multicast: 
            UDP:239.255.0.1:7400(6) {MD,MC} H:6
        Default Unicast: 
            UDP:192.168.0.3:7589 {UD,UC}
        Default Multicast: 
            UDP:239.255.0.1:7401(3) {UD,MC} H:3
        Manual Liveliness: 0
        Lease duration: 50.000000000s
        Endpoints: 8 entries (4 readers, 4 writers).
            000001-2, {32}, InlineQoS: No, Writer, Chat/ChatMsg
            000002-7, {33}, InlineQoS: No, Reader, Chat/ChatMsg
        Topics: 
            Chat/ChatMsg 
        Source: 
            UDP:192.168.0.3:7588 {MD,UC}
        Timer = 41.52s

sep

!!sep
DCPS:
    0/000001-02 W{22}   0/1 Chat/ChatMsg
    0/000002-07 R{24}   0/1 Chat/ChatMsg
    0/000003-c2 W{13}   1/1 SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData
    0/000003-c7 R{9}    0/0 SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData
    0/000004-c2 W{15}   1/1 SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData
    0/000004-c7 R{11}   0/0 SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData
    0/000100-c2 W{5}    1/1 SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData
    0/000100-c7 R{7}    0/0 SPDPbuiltinParticipantReader/ParticipantBuiltinTopicData
    0/000200-c2 W{19}   0/0 BuiltinParticipantMessageWriter/ParticipantMessageData
    0/000200-c7 R{17}   0/0 BuiltinParticipantMessageReader/ParticipantMessageData
RTPS:
    0/000001-02 W{22}   0/1 Chat/ChatMsg
                ->  GUID: f29134d9:00590002:00060000-000002-7 {33}
    0/000002-07 R{24}   0/1 Chat/ChatMsg
                ->  GUID: f29134d9:00590002:00060000-000001-2 {32}
    0/000003-c2 W{13}   1/1 SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData
                ->  GUID: f29134d9:00590002:00060000-000003-c7 {28}
    0/000003-c7 R{9}    0/0 SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData
                ->  GUID: f29134d9:00590002:00060000-000003-c2 {29}
    0/000004-c2 W{15}   1/1 SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData
                ->  GUID: f29134d9:00590002:00060000-000004-c7 {30}
    0/000004-c7 R{11}   0/0 SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData
                ->  GUID: f29134d9:00590002:00060000-000004-c2 {31}
    0/000100-c2 W{5}    2/1 SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData
                ->  Locator: UDP:239.255.0.1:7400(6) {5}
                ->  Locator: TCP:239.255.0.1:7400 {5}
    0/000100-c7 R{7}    0/0 SPDPbuiltinParticipantReader/ParticipantBuiltinTopicData
    0/000200-c2 W{19}   0/0 BuiltinParticipantMessageWriter/ParticipantMessageData
                ->  GUID: f29134d9:00590002:00060000-000200-c7 {26}
    0/000200-c7 R{17}   0/0 BuiltinParticipantMessageReader/ParticipantMessageData
                ->  GUID: f29134d9:00590002:00060000-000200-c2 {27}

sproxy

!!sproxy
0/000001-02 W{22} - Chat/ChatMsg:
    GUID: f29134d9:00590002:00060000-000002-7 {33} - 
    InlineQoS=0, Reliable=0, Active=0, Marshall=1, MCast=1, Tunnel=0
    States (Control/Tx/Ack): READY/IDLE/WAITING
    Changes: : (0)
    LastAck=0
    Unicast locators: 
        UDP:192.168.0.3:7589
    Multicast locators: 
        UDP:239.255.0.1:7401(3)
    # of DATA messages sent:     5
    # of DATAFRAG messages sent: 0
    Next GUID: (nil)
0/000002-07 R{24} - Chat/ChatMsg:
    GUID: f29134d9:00590002:00060000-000001-2 {32} - 
    Reliable=0, Active=0, MCast=1, Tunnel=0
    States (Control/Ack): READY/WAITING
    Changes: : (0)
    LastHeartbeat=0
    Unicast locators: 
        UDP:192.168.0.3:7589
    Multicast locators: 
        UDP:239.255.0.1:7401(3)
    # of DATA messages received: 0
    # of DATAFRAG messages recvd:0
    Next GUID: (nil)
0/000003-c2 W{13} - SEDPbuiltinPublicationsWriter/PublicationBuiltinTopicData:
    GUID: f29134d9:00590002:00060000-000003-c7 {28} - 
    InlineQoS=0, Reliable=1, Active=0, Marshall=1, MCast=1, Tunnel=0
    States (Control/Tx/Ack): READY/ANNOUNCING/WAITING
    Changes: : (1)
        {UNDERWAY:1 [0x7fb900001660*1:ALIVE:h=1,0.1]}
    LastAck=432
    Unicast locators: 
        UDP:192.168.0.3:7588
    Multicast locators: 
        UDP:239.255.0.1:7400(6)
    Direct reply locator: not set
    Last: 0.1, local=2, remote=0
    # of DATA messages sent:     1
    # of GAPs sent:              0
    # of HEARTBEATs sent:        458
    # of ACKNACKs received:      845
    # of DATAFRAG messages sent: 0
    # of HEARTBEATFRAGs sent:    0
    # of NACKFRAGs received:     0
    Next GUID: (nil)
0/000003-c7 R{9} - SEDPbuiltinPublicationsReader/PublicationBuiltinTopicData:
    GUID: f29134d9:00590002:00060000-000003-c2 {29} - 
    Reliable=1, Active=0, MCast=1, Tunnel=0
    States (Control/Ack): READY/MUST_ACK
    Changes: : (0)
    LastHeartbeat=35
    Unicast locators: 
        UDP:192.168.0.3:7588
    Multicast locators: 
        UDP:239.255.0.1:7400(6)
    Direct reply locator:
        UDP:192.168.0.3:7588
    Next: 0.2, LocalInst=2, RemoteInst=0
    # of DATA messages received: 2
    # of GAPs received:          0
    # of HEARTBEATs received:    44
    # of ACKNACKs sent:          25
    # of DATAFRAG messages recvd:0
    # of HEARTBEATFRAGs received:0
    # of NACKFRAGs sent:         0
    Next GUID: (nil)
0/000004-c2 W{15} - SEDPbuiltinSubscriptionsWriter/SubscriptionBuiltinTopicData:
    GUID: f29134d9:00590002:00060000-000004-c7 {30} - 
    InlineQoS=0, Reliable=1, Active=0, Marshall=1, MCast=1, Tunnel=0
    States (Control/Tx/Ack): READY/ANNOUNCING/WAITING
    Changes: : (1)
        {UNDERWAY:1 [0x7fb900001e20*1:ALIVE:h=1,0.1]}
    LastAck=434
    Unicast locators: 
        UDP:192.168.0.3:7588
    Multicast locators: 
        UDP:239.255.0.1:7400(6)
    Direct reply locator: not set
    Last: 0.1, local=3, remote=0
    # of DATA messages sent:     1
    # of GAPs sent:              0
    # of HEARTBEATs sent:        447
    # of ACKNACKs received:      846
    # of DATAFRAG messages sent: 0
    # of HEARTBEATFRAGs sent:    0
    # of NACKFRAGs received:     0
    Next GUID: (nil)
0/000004-c7 R{11} - SEDPbuiltinSubscriptionsReader/SubscriptionBuiltinTopicData:
    GUID: f29134d9:00590002:00060000-000004-c2 {31} - 
    Reliable=1, Active=0, MCast=1, Tunnel=0
    States (Control/Ack): READY/MUST_ACK
    Changes: : (0)
    LastHeartbeat=32
    Unicast locators: 
        UDP:192.168.0.3:7588
    Multicast locators: 
        UDP:239.255.0.1:7400(6)
    Direct reply locator:
        UDP:192.168.0.3:7588
    Next: 0.2, LocalInst=3, RemoteInst=0
    # of DATA messages received: 2
    # of GAPs received:          0
    # of HEARTBEATs received:    34
    # of ACKNACKs sent:          20
    # of DATAFRAG messages recvd:0
    # of HEARTBEATFRAGs received:0
    # of NACKFRAGs sent:         0
    Next GUID: (nil)
0/000100-c2 W{5} - SPDPbuiltinParticipantWriter/ParticipantBuiltinTopicData:
    UDP:239.255.0.1:7400(6) - 
    InlineQoS=0, Reliable=0, Active=0, Marshall=1, MCast=1, Tunnel=0
    States (Control/Tx/Ack): READY/IDLE/WAITING
    Changes: : (1)
        {UNDERWAY:1 [0xa491c0*2:ALIVE:h=1,0.1]}
    # of DATA messages sent:     51
    # of DATAFRAG messages sent: 0
    Next GUID: (nil)
    TCP:239.255.0.1:7400 - 
    InlineQoS=0, Reliable=0, Active=0, Marshall=1, MCast=1, Tunnel=0
    States (Control/Tx/Ack): READY/IDLE/WAITING
    Changes: : (1)
        {UNDERWAY:1 [0xa491c0*2:ALIVE:h=1,0.1]}
    # of DATA messages sent:     51
    # of DATAFRAG messages sent: 0
    Next GUID: (nil)
0/000200-c2 W{19} - BuiltinParticipantMessageWriter/ParticipantMessageData:
    GUID: f29134d9:00590002:00060000-000200-c7 {26} - 
    InlineQoS=0, Reliable=1, Active=0, Marshall=1, MCast=1, Tunnel=0
    States (Control/Tx/Ack): READY/IDLE/WAITING
    Changes: : (0)
    LastAck=440
    Unicast locators: 
        UDP:192.168.0.3:7588
    Multicast locators: 
        UDP:239.255.0.1:7400(6)
    Direct reply locator:
        UDP:192.168.0.3:7588
    Last: 0.1, local=1, remote=0
    # of DATA messages sent:     0
    # of GAPs sent:              0
    # of HEARTBEATs sent:        423
    # of ACKNACKs received:      846
    # of DATAFRAG messages sent: 0
    # of HEARTBEATFRAGs sent:    0
    # of NACKFRAGs received:     0
    Next GUID: (nil)
0/000200-c7 R{17} - BuiltinParticipantMessageReader/ParticipantMessageData:
    GUID: f29134d9:00590002:00060000-000200-c2 {27} - 
    Reliable=1, Active=0, MCast=1, Tunnel=0
    States (Control/Ack): READY/WAITING
    Changes: : (0)
    LastHeartbeat=0
    Unicast locators: 
        UDP:192.168.0.3:7588
    Multicast locators: 
        UDP:239.255.0.1:7400(6)
    Direct reply locator: not set
    Next: 0.1, Heartbeat-timer: 0.06s, LocalInst=1, RemoteInst=0
    # of DATA messages received: 0
    # of GAPs received:          0
    # of HEARTBEATs received:    0
    # of ACKNACKs sent:          3989
    # of DATAFRAG messages recvd:0
    # of HEARTBEATFRAGs received:0
    # of NACKFRAGs sent:         0
    Next GUID: (nil)

srx

.pid.11957: srx
!!srx
!!srx
Protocol version: {2, 1}
Src. Vendor Id: {0x1, 0xe}
Src. GUID Prefix: a37aa173:00762eb5:03e90000
Dst. GUID Prefix: a37aa173:00762eb5:03e90000
Timestamp: 1414088344.4226596304s
Domain: 0x1cc8440
# of invalid submessages: 0
# of too short submessages: 0
# of invalid QoS errors: 0
# of out-of-memory errors: 0
# of unknown destination errors: 8
# of invalid marshalling data: 0
Last error: Unknown destination
Last MEP:
:   00 00 00 00 00 00 00 00 - 90 1a 00 40 95 7f 00 00   ...........@....
    00 00 00 00 00 00 00 00 - 78 00 00 04 15 07 78 00   ........x.....x.
    00 00 10 00 00 00 00 00 - 00 00 01 02 00 00 00 00   ................
    04 00 00 00 70 00 10 00 - 67 70 ec f4 9b d4 b2 ee   ....p...gp......
    3e 0f 0e 12 65 a2 e2 9c - 01 00 00 00 00 03 00 00   >...e...........
    01 3f 08 00 9b 51 9f 02 - 08 00 00 00 04 00 00 00   .?...Q..........
    44 44 53 00 01 3f 08 00 - 06 7e 23 0e 10 00 00 00   DDS..?...~#.....
    0b 00 00 00 2e 70 69 64 - 2e 31 31 39 35 37 00 00   .....pid.11957..
    01 3f 08 00 fb d2 93 03 - 08 00 00 00 04 00 00 00   .?..............
    73 72 78 00 02 3f 00 00 - 88 00 00 40 95 7f 00 00   srx..?.....@....
Last domain: 0
Last msg:
:   00 00 10 00 00 00 00 00 - 00 00 01 02 00 00 00 00   ................
    04 00 00 00                                         ....

brunodebus / tinq-core

Using Tinq for ROS 2.0 #7

Desktop machine running Tinq

Embedded board running Tinq

dynamical memory allocation:

statically allocated memory:

Embedded board

sdisca

sep

sproxy

srx

Desktop machine

sdisca

sep

sproxy

srx