Networking setup on robot with multiple debian SBCs

GoogleGroups
1

I have designed a mobile robot with a BeagleBone blue handling the low level motor control and sensor interfacing and a RPi4 to handle the higher level vision, localization, mapping & path planning. Communication between the Pi and Beaglebone needs to happen over a network connection using a messaging system called LCM (similar to ROS messages), and ideally that network needs to be accessible from my laptop nearby the robot. Also it would be great if all three (RPi, BBBlue, laptop) could connect the internet at the same time.

The current setup I have is this:

The Beaglebone creates its default SoftAP and connects to a WiFi router that has internet. By default, computers connecting to the SoftAP get the internet forwarded to them so both the laptop and the RPi can connect to the internet and I can ssh and remote desktop into the RPi from the laptop and ssh into the Beaglebone as well. All three appear on the same LAN (192.168.8.0) and all the LCM traffic is visible on the network.

The problem I have is this. I would rather have the network connection between the Pi and BBBlue be over USB so there is higher bandwidth/lower latency connection between them because ultimately the largest share of data is going to be produced on the Pi (video / LIDAR messages / maps etc.), not the Beaglebone and I would like to be able to decode it on the laptop with as little latency as possible.

Should I achieve this by bridging some of the interfaces? Should this be done using NAT? Perhaps the best option is to scrap the SoftAP on the Beaglebone and implement it on the RPi instead?

Basically I want to configure the RPi and BBBlue in such a way that I don’t need to attach a standalone wireless router on the robot, and I feel like I shouldn’t need to.

-p

2

The Beaglebone creates its default SoftAP and connects to a WiFi router
that has internet. By default, computers connecting to the SoftAP get the
internet forwarded to them so both the laptop and the RPi can connect to
the internet and I can ssh and remote desktop into the RPi from the laptop
and ssh into the Beaglebone as well. All three appear on the same LAN
(192.168.8.0) and all the LCM traffic is visible on the network.

  Personally, to reduce interference I'd have all the devices connect to
the router... If I understand your description, you have the BBbl running
as an access point for other WiFi clients, and also connecting to the
router -- so every WiFi packet it receives from a client has to be resent
to the router. But...

The problem I have is this. I would rather have the network connection
between the Pi and BBBlue be over USB so there is higher bandwidth/lower
latency connection between them because ultimately the largest share of
data is going to be produced on the Pi (video / LIDAR messages / maps
etc.), not the Beaglebone and I would like to be able to decode it on the
laptop with as little latency as possible.

... I wouldn't even use WiFi between the R-Pi and the BBbl. While the BBx
USB client port does set up a USB network gadget (rndis on 192.168.7.x), I
don't know what it would take to have an R-Pi set up a matching USB gadget
on its host port (plug them together and see if a new network device
appears on the R-Pi?).

  Simpler might be to use a USB<>Ethernet adapter on the BBbl, and a
short length of CAT-5/6 cable to connect to the R-Pi. Since I doubt either
machine is running a DHCPd, you'd have to manually configure the
hostname/IP #s to make a two-node network.

  Once the two nodes are talking, you'd have to configure the BBbl to use
the R-Pi as the gateway, and configure the R-Pi to route traffic from the
BBbl port to the WiFi port, which is connected to your router. You'd have
the laptop connect to the router also -- the R-Pi should appear on your LAN
list, and you can talk between them. With luck, the BBbl will be reachable
too -- if the R-Pi passes hostname information from it to the router.

  The only way to reduce the latency further would maybe be to use a
small four-port switch and CABLE the BBbl, R-Pi, AND laptop through the
switch (and maybe run DHCP on one of the nodes, so it can assign IP #s to
the other two). After all, the R-Pi4 has gigabit ethernet -- which probably
out-performs WiFi, and would be the fastest connection between the R-Pi and
laptop (unless the laptop only has 100 speed).

3

There does not seem to be any mention of a BBAI in the original post, but a BBBlue is which does not have a wired Ethernet port.

However, it should be possible, that is if there are the necessary drivers, to connect the RasPi and the BBBlue via USB network and then the Pi to other devices via the wired ethernet port, but this does require some sort of wired network in your config and/or a device acting as an AP, such as the BBBlue, if it is a mobile platform.

The other option I suppose would be to do something similar to ROS Serial between the RasPi and the BBBlue to avoid any network stuff between the two.

Jon

4

Just tried an experiment... Powered the BBB from a 5V barrel supply
(since an R-Pi USB probably can't power it), then connected the BBB client
port to the R-Pi host port...

pi@rpi3bplus-1:~$ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
        ether b8:27:eb:fb:d8:30 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

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::d22b:73ea:8bef:c781 prefixlen 64 scopeid 0x20<link>
        ether d0:39:72:18:3e:ea txqueuelen 1000 (Ethernet)
        RX packets 32 bytes 5556 (5.4 KiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 20 bytes 2661 (2.5 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::4f35:ad14:88b8:4a1a prefixlen 64 scopeid 0x20<link>
        ether d0:39:72:18:3e:e8 txqueuelen 1000 (Ethernet)
        RX packets 33 bytes 5376 (5.2 KiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 18 bytes 2961 (2.8 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        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

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.1.76 netmask 255.255.255.0 broadcast 192.168.1.255
        inet6 2600:1700:e630:890:e51e:f96a:9476:3412 prefixlen 64 scopeid
0x0<global>
        inet6 fe80::6471:7a90:88f3:79c0 prefixlen 64 scopeid 0x20<link>
        inet6 2600:1700:e630:890::1b prefixlen 128 scopeid 0x0<global>
        ether b8:27:eb:ae:8d:65 txqueuelen 1000 (Ethernet)
        RX packets 19022 bytes 27611083 (26.3 MiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 10635 bytes 1253318 (1.1 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

pi@rpi3bplus-1:~$

  eth1 and eth2 are IPv6 and exist while the BBB is connected, removing
the USB cable leaves the R-Pi with

pi@rpi3bplus-1:~$ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
        ether b8:27:eb:fb:d8:30 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

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<host>
        loop txqueuelen 1000 (Local Loopback)
        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

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.1.76 netmask 255.255.255.0 broadcast 192.168.1.255
        inet6 2600:1700:e630:890:e51e:f96a:9476:3412 prefixlen 64 scopeid
0x0<global>
        inet6 fe80::6471:7a90:88f3:79c0 prefixlen 64 scopeid 0x20<link>
        inet6 2600:1700:e630:890::1b prefixlen 128 scopeid 0x0<global>
        ether b8:27:eb:ae:8d:65 txqueuelen 1000 (Ethernet)
        RX packets 19047 bytes 27613467 (26.3 MiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 10660 bytes 1261140 (1.2 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

pi@rpi3bplus-1:~$

  The lack of IPv4 may be due to the lack of DHCP server. I did not try
to pass traffic (ping) between the two. Merely to demonstrate that it may
be possible to use TCP/IP between the two boards without using a
USB<>Ethernet adapter.

5

On my RPi, eth1 and eth2 get the proper IPv4 addresses (192.168.7.1 and 192.168.6.1)

Really I think I just want to route the multicast traffic between the two to the usb0/eth1 interface network but also be able to have them both on the internet and be able to “sniff” the traffic on the usb0/eth1 network by connecting to an access point on one of them. Unfortunately it seams having multicast packets go out to the wireless interfaces slows down the communication significantly.

-p

6

On my RPi, eth1 and eth2 get the proper IPv4 addresses (192.168.7.1 and
192.168.6.1)

  Interesting...

Really I think I just want to route the multicast traffic between the two
to the usb0/eth1 interface network but also be able to have them both on
the internet and be able to "sniff" the traffic on the usb0/eth1 network by
connecting to an access point on one of them. Unfortunately it seams
having multicast packets go out to the wireless interfaces slows down the
communication significantly.

  I'd have to ask why you are using multicast?

https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-01.html
"""
One of the primary problems multicast over wifi faces is that link local
802.11 doesn't necessarily support multicast, it supports broadcast. To
make make multicast over wifi work successfully we often need to modify the
multicast to instead be sent as unicast in order for it to successfully
transmit with useable quality. Multicast over wifi experiences high packet
error rates, no acknowledgements, and low data rate. This draft reviews
these problems found with multicast over wifi. While this is not a
solutions draft, common workarounds to some of the problems will be listed,
along with the impact of the workarounds.
"""
A big problem is that the 802.11 multicast channel is an afterthought and
only given 100th of the bandwidth. Multicast is basically a second class
citizen, to unicast, over wifi. Unicast may have allocated 10mb while
Multicast will be allocated 1mb.
"""

"""
Multicast has brought a lot of efficiencies to IP networks. But multicast
wasn’t designed for wireless, and especially isn’t well suited for
high-bandwidth multicast applications like video. I’ll cover the challenges
of multicast over wireless and design considerations.
"""