Closed vmayoral closed 9 years ago
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?
Network not showing any trace of packets received from the embedded platform. Next to look at:
Activated NuttX networking debug and getting:
udp_callback: flags: 0010
udp_callback: flags: 0010
udp_callback: flags: 0010
udp_callback: flags: 0010
...
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.
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.
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
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.
Threading works just fine in an isolated way (test code using NuttX). Tested with https://github.com/ros2/ros2_embedded_nuttx/commit/0f5528c3b768f9b2e5a40f21a3c155a1173cc6ac.
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
Fixed. Now NuttX creates 4 locators (two for the unicast interface and two for the multicast)
In NuttX, the result of executing
!!sdisc
:while in Ubuntu:
Networking setup needs to be inspected in NuttX.