NuttX network configuration

[vmayoral]

In NuttX, the result of executing !!sdisc:

Domain 0 (pid=95): {1}
        GUID prefix: 6002b4df:005f0004:00060000
        RTPS Protocol version: v2.1
        Vendor Id: 1.14 - Technicolor, Inc. - Qeo
        Technicolor DDS version: 4.0-0
        Entity name: ROS 2.0 embedded
        Flags: Enabled
        Meta Multicast: 
                UDP:239.255.0.1:7400(2) {MD,MC} H:2
        Default Multicast: 
                UDP:239.255.0.1:7401(1) {UD,MC} H:1
        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(2) {MD,MC} H:2
        Discovered participants: <none>

while in Ubuntu:

Domain 0 (pid=4): {1}
    GUID prefix: 52b5027c:00040952: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:7418(4) {MD,UC} H:4
        UDP:192.168.1.185:7418(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:7419(1) {UD,UC} H:1
        UDP:192.168.1.185:7419(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: <none>

Networking setup needs to be inspected in NuttX.

[vmayoral]

My guess is that somehow, the code in the Desktop solution queries the OS for the interface and sets up a transport layer in each interface. If that's the case where is it performed? How can we hack NuttX to do so?

[vmayoral]

Network not showing any trace of packets received from the embedded platform. Next to look at:

• review udp transmissions within the DDS implementation
• try addressing UDP polling #5

[vmayoral]

Activated NuttX networking debug and getting:

udp_callback: flags: 0010
udp_callback: flags: 0010
udp_callback: flags: 0010
udp_callback: flags: 0010
...

[vmayoral]

Apparently the Unicast interfaces from DDS represent some sort of network interface within the system. In the Desktop running Tinq:

    Meta Unicast: 
        UDP:192.168.0.2:7440(4) {MD,UC} H:4
        UDP:192.168.1.185:7440(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:7441(1) {UD,UC} H:1
        UDP:192.168.1.185:7441(2) {UD,UC} H:2
    Default Multicast: 
        UDP:239.255.0.1:7401(3) {UD,MC} H:3

while in the embedded environment there're none.

[vmayoral]

In this call https://github.com/ros2/ros2_embedded_nuttx/blob/master/nuttx/net/udp/udp_callback.c#L90, conn->list seems to be 0x00 thereby devif_callback_execute doesn't execute anything.

[vmayoral]

rtps_udp_send never gets called in the embedded DDS while in the Desktop it does:

#0  rtps_udp_send (id=1, first=0x75ef54, next=0x0, msgs=0x7ffff00008c0) at ../../src/trans/ip/ri_udp.c:348
#1  0x00000000004e74c8 in rtps_ip_send (id=1, dest=0x0, dlist=0, msgs=0x7ffff00008c0) at ../../src/trans/ip/rtps_ip.c:1512
#2  0x00000000004cc4f9 in rtps_locator_send_ll (id=1, dest=0x75ef54, dlist=0, msgs=0x7ffff00008c0) at ../../src/rtps/rtps_mux.c:585
#3  0x00000000004cc547 in rtps_locator_send (id=1, dest=0x75ef54, dlist=0, msgs=0x7ffff00008c0) at ../../src/rtps/rtps_mux.c:600
#4  0x00000000004c8c77 in rtps_send_messages (id=1, dest=0x75ef54, dlist=0, mp=0x7ffff00008c0) at ../../src/rtps/rtps_main.c:3103
#5  0x00000000004c8eea in rtps_send_changes () at ../../src/rtps/rtps_main.c:3197
#6  0x0000000000408a65 in dds_work (max_wait_ms=2000) at ../../src/dds/dds.c:844
#7  0x0000000000408b2b in dds_core (arg=0x0) at ../../src/dds/dds.c:893
#8  0x00007ffff79bc182 in start_thread (arg=0x7ffff630a700) at pthread_create.c:312
#9  0x00007ffff6d4afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[vmayoral]

Apparently the embedded board gets stucked at:

#0  sock_fd_poll (poll_time=2000) at ../../../dds/src/co/sock.c:703
#1  0x0801448a in dds_work (max_wait_ms=2000) at ../../../dds/src/dds/dds.c:810
#2  0x080145d0 in dds_core (arg=0x0) at ../../../dds/src/dds/dds.c:893
#3  0x0809e16c in pthread_start () at pthread/pthread_create.c:200
#4  0x00000000 in ?? ()

Seems to be related to the issue #5.

The one causing this matter issue is https://github.com/ros2/ros2_embedded_nuttx/blob/master/dds/src/co/sock.c#L707. This seems similar to what happens in #8.

Interestingly if these locks are commented, the code seems to keep running but the dds chat application never finishes to initialize. This might indicate that there's an issue with threads and locks.

[vmayoral]

Threading works just fine in an isolated way (test code using NuttX). Tested with 0f5528c.

[vmayoral]

rtps_udp_send gets called after #8 was fixed however https://github.com/ros2/ros2_embedded_nuttx/blob/master/dds/src/trans/ip/ri_udp.c#L514 always returns NULL.

The issue seems to remain at the locators (interfaces) at the embedded board. In the Desktop i get:

!!sloc
UDP:239.255.0.1:7400(6)*12
UDP:239.255.0.1:7401(3)*2
UDP:172.23.1.215:7414(5)*10
UDP:192.168.0.2:7414(4)*10
UDP:172.23.1.215:7415(2)*2
UDP:192.168.0.2:7415(1)*2

While in the embedded board:

!!sloc
UDP:239.255.0.1:7400(2)*12
UDP:239.255.0.1:7401(1)*2

[vmayoral]

Fixed. Now NuttX creates 4 locators (two for the unicast interface and two for the multicast)