Need help in doing edge computing using jetson nano

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hello everyone,

I have a Jetson Nano (4GB RAM Developer Kit), an Intel RealSense D455 camera, and an Acer PC (8GB RAM). I’m trying to offload the D455 camera data to my PC to perform computations for localization of an aerial robot using SLAM. However, the camera topics and frames are not reaching the PC.

When I run the camera directly on the Jetson, the frames work fine. But when I connect the Jetson to the PC using ROS_DOMAIN_ID=0 (both devices are on the same network), the connection is established. However, when I run the RealSense node on the Jetson and try to visualize the video on the PC, the stream only runs for about 3 seconds before freezing.

I checked the ping latency: initially, it was around 3.5 ms, but after running the RealSense node, it jumped to 100+ ms. I would appreciate your guidance on resolving this issue.

2

What L4T release are you using? See “head -n 1 /etc/nv_tegra_release”. Is this a dev kit, or is the carrier board from a third party (which changes firmware)?

I know nothing about the device, I’m only looking at this from the network side. Before starting try running “dmesg --follow” (this includes both the working and failing circumstances). This is a live feed of kernel logs. Start with the working condition, and start the camera. See what the logs should look like. Then start again and watch “dmesg --follow” again. This time watch the result as the failing condition runs. If there is a difference, then post what occurs for the working condition, and then also post the failing condition logs.

It sounds like this runs on Ethernet for the failing case. For that case, prior to starting, but after the Jetson has had a short time to run random network traffic (e.g., 30 seconds; a DHCP request/response counts as minimal traffic), run “ifconfig” (or “ip -s -a addr” if you don’t have ifconfig). You can identify which network interface has the camera on it if you want to watch a smaller amount of output data. Then, after the failure, run ifconfig (or “ip -s -a addr”) again and post the data for that one interface here from the failure case.

The above is all for looking for driver complaints and network errors. If that shows nothing, then it will be a different issue.

3

it is a dev kit sir, the output of head -n 1 /etc/nv_tegra_release came as follow sir.
shivayya@shivayya-desktop:~$ head -n 1 /etc/nv_tegra_release

R32 (release), REVISION: 7.6, GCID: 38171779, BOARD: t210ref, EABI: aarch64, DATE: Tue Nov 5 07:46:14 UTC 2024

the below log came when the ping was about 3.5ms
kernal log when ping was at 3.pdf (73.4 KB)

below file log came when the ping gave >100ms.

kernal log when ping was at >100ms.pdf (73.9 KB)

ifconfig data at normal case.

shivayya@shivayya-desktop:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:35:21:ba:e5 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.4 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::d2c8:3aec:3696:4566 prefixlen 64 scopeid 0x20
ether 48:b0:2d:ec:2f:11 txqueuelen 1000 (Ethernet)
RX packets 347703 bytes 279689623 (279.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8087816 bytes 11897413668 (11.8 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 151 base 0xd000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 20025 bytes 4975110 (4.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20025 bytes 4975110 (4.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 92:96:9b:51:18:6d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 92:96:9b:51:18:6f txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ifconfig at failing case:

shivayya@shivayya-desktop:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:35:21:ba:e5 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.4 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::d2c8:3aec:3696:4566 prefixlen 64 scopeid 0x20
ether 48:b0:2d:ec:2f:11 txqueuelen 1000 (Ethernet)
RX packets 347855 bytes 279714164 (279.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8308859 bytes 12226614262 (12.2 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 151 base 0xd000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 20031 bytes 4976958 (4.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20031 bytes 4976958 (4.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 92:96:9b:51:18:6d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 92:96:9b:51:18:6f txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

i want say other info also sir, whenever i wish to see the frequency of the produced topics that visible on pc the ping jumping from 3ms to 100ms.
and another problem is my camera runs actually on 30fps and i should also expect to see the data with ~30 but i only getting below 10 when i run the camera ros2 topic hz /camera/camera/color/image_raw.. we have been facing this issue from days sir. please help us.

5

Hi,
The issue may be due to network bandwidth. Please check if you can set up RTSP or UDP and try again. There are examples in
Jetson Nano FAQ

6

What is the exact layout of any USB device connected, and is there any USB change between the two cases? I ask because of what follows; you will probably want to add the output of “lsusb -tv” in both the working case and failing case.

Is device tree modified in any way? This can change USB. Also, is this a developer kit, and not a third party carrier board? This too can change device tree and USB.

Incidentally, you have a USB issue when ping is low or high (this is universal in both logs):

  • [ 5548.964352] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
  • [ 6260.991483] hid-sensor-hub 0003:8086:0B5C.0004: No report with id 0xffffffff found

Also, what power model do you use? Is it the max power, or something else? This could have an effect on available bandwidth. Plus, I saw this in the “working case” (and this is not necessarily heat…this can simply be a lower power model’s setting to not consume more than some certain power level):
[ 5588.736318] soctherm: OC ALARM 0x00000001

The failing case does show a kernel stack trace. Here is an excerpt (other than this much of the log is no different than the “working” case):

[12661.430994] sysfs group 'power' not found for kobject 'media2'
[12661.436931] ------------[ cut here ]------------
[12661.441545] WARNING: CPU: 2 PID: 12991 at
/dvs/git/dirty/git-master_linux/kernel/kernel-4.9/fs/sysfs/group.c:237
sysfs_remove_group+0x98/0xa0
...
[12661.458992] Call trace:
[12661.458997] [<00000000510a6ca7>] sysfs_remove_group+0x98/0xa0
[12661.459004] [<000000004e93045c>] dpm_sysfs_remove+0x60/0x70
[12661.459009] [<0000000013e10548>] device_del+0x48/0x248
[12661.459015] [<00000000208a0158>] media_devnode_unregister+0x48/0x68
[12661.459020] [<00000000e6109cac>] media_device_unregister+0x158/0x190
[12661.459035] [<000000008216527a>] 0xffffff800139b518
[12661.459047] [<00000000eb797b96>] 0xffffff800139b640
[12661.459051] [<000000007b369594>] v4l2_device_release+0xd0/0x110
[12661.459055] [<00000000ec3e4a2f>] device_release+0x3c/0x98
[12661.459062] [<00000000ce04b2f7>] kobject_put+0x94/0x1e8
[12661.459065] [<00000000c7e593e7>] put_device+0x24/0x30
[12661.459068] [<000000002a98a977>] v4l2_release+0x60/0xa0
[12661.459074] [<00000000c03039dd>] __fput+0x90/0x1d0
[12661.459078] [<00000000bc1ffc70>] ____fput+0x20/0x30
[12661.459084] [<000000007f624009>] task_work_run+0xbc/0xd8
[12661.459089] [<000000000e870257>] do_notify_resume+0xf8/0x100
[12661.459092] [<0000000092120339>] work_pending+0x8/0x10
[12663.464264] sysfs group 'power' not found for kobject 'event5'
[12663.470748] ------------[ cut here ]------------

I don’t know if it is correct, but I could easily see a trace such as this occurring when USB issues a command to a device and the device either has an error or does not respond. Perhaps the failing case is from some added load? Don’t know.

I see no outright network errors in either case. I do not think this is related to networking at all, but is instead related to the USB Video Class (UVC) driver and USB. This does not mean it isn’t related to network bandwidth. I’m speaking only of errors which drop packets, corrupt packets, packets colliding, so on. It is quite possible that there is still a bandwidth issue on wired Ethernet, and I have no idea what USB errors might be showing up if there is a bandwidth problem; Ethernet and USB bandwidth could easily interact with each other and errors could occur on one part when the other part starts losing data or something similar.

Note that “lsusb -tv” would also show what the USB bandwidth/standard is set at on each device, and also would show which parts of USB share data with other parts (they can compete for bandwidth). Please post “lsusb -tv” for both the working and failing cases.