-
Notifications
You must be signed in to change notification settings - Fork 5
Network Configuration
At this point, we should have a functional TX2 and RPI4, but we need to configure the networks of each device so that they can communicate with one another. Additionally, we should configure a laptop to use for tethered and bench operations. This laptop is referred to as the OCU (operational command unit) from this point forward.
Our TX2 and RPI are connected directly via their Ethernet ports. This makes connections between them relatively straightforward. However, LoCO does not currently have space for an Ethernet switch, meaning that the connection to the OCU is managed through one computer using a USB-Ethernet adaptor. In our case, we use the RPI. So essentially, we have to manage the connection between the RPI and TX2, the RPI and OCU, and forwarding between the TX2 and OCU via the RPI.
The IPs current in use are as follows:
- OCU (external): 192.168.150.14
- RPI (external): 192.168.150.43
- RPI (internal): 192.168.210.43
- TX2 (internal): 192.168.210.44
We use the 192.168.150 subnet for addresses that are external to LoCO, the 192.168.150 subnet for internal addresses. The RPI is .43, the TX2 is .44, and the OCU .14. Other addresses are not currently claimed, but if you do use another last address number for anything, be aware that that address may suddenly become used.
A bit of trivia: the final numbers are holdovers from the McGill MRF's AQUA control and vision stack last octet addresses, while the subnets (.210 and .150) are the room numbers of the IRV Lab's two lab spaces during the development of LoCO.
Examples of the files required for each system can be found in the loco_config repository. We'll go through the files and the general process of setting this up now.
The following sections have instructions for each device to configure their network setup.
To test, ping the RPI and TX2 from one another, and ping them both from the OCU. Once this has been confirmed, ssh between all machines. Consider setting up ssh keys to reduce the amount of password typing you'll have to do. Please do your testing with Ethernet cables that are known to be working, and do this testing before putting the TX2 or RPI in the robot. Make sure that your network setup is working before trying to assemble, having a broken network setup and trying to debug with devices in the robot is annoying.
This part's simple. In /etc/hosts
on the OCU, edit the file to have the following lines:
127.0.0.1 localhost
127.0.1.1 katla
192.168.150.43 rpi-external rpi
192.168.210.43 rpi-internal
192.168.210.44 jetson tx2
This associates the given IPs with names. In our case, we use rpi-external to refer to the externally facing IP of the RPI, rpi-internal to refer to its internally facing IP, and we use jetson or tx2 to refer to the Jetson's IP. Note that rpi-external has the alias of rpi, and jetson has the alias of tx2. Feel free to change names as you wish, just make sure that you're consistent.
Now we have to set up the OCU's ethernet interface to communicate with the RPI. This goes in your /etc/network/interfaces
file (assuming you're using Ubuntu prior to mandatory netplan usage). This defines a static IP on the 192.168.150 subnet, the same subnet used for the external-facing RPI IP address.
auto eth-loco
iface eth-loco inet static
address 192.168.150.14
netmask 255.255.255.0
post-up /home/irvlab/loco-routing.bash 192.168.150.14 192.168.150.43 wlo1 eth-loco 192.168.150.0
One critical part to notice is that we're running a script on post-up. This script manages the routing to forward general internet traffic from the RPI to the broader internet, by forwarding packets from eth-loco to the WiFi interface. Note that you'll need to replace wlo1 with whatever your WiFi interface is named. You'll also need to make sure you put that script (available in loco_config/ocu_config_files) in a known path (that you'll need to put into the interfaces file) and make it executable (chmod +x loco-routing.bash)
If you are using netplan, look at the example provided for the RPI, but use the IPs and interface names described here.
As mentioned, we manage the routing on the OCU end with a script (writing scripts for the TX2 and RPI should happen at some point). Please make sure your OCU routing table looks like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default ebm-rc-1-be501- 0.0.0.0 UG 600 0 0 wlo1
10.131.0.0 0.0.0.0 255.255.0.0 U 600 0 0 wlo1
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 eth-minibot
192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 eth-minibot
rpi-internal rpi-external 255.255.255.255 UGH 0 0 0 eth-minibot
jetson rpi-external 255.255.255.255 UGH 0 0 0 eth-minibot
Lastly, in order to ensure that the network interface that we've defined is brought up when the computer is booted, we add a line similar to the following to /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="54:bf:64:32:fd:f8", ATTR{type}=="1", NAME="eth-loco"
The address will have to be switched out for the physical MAC address of your Ethernet device. This is also useful if you're using a USB-Ethernet adaptor on your OCU, because you can use the MAC address of that device, add the line allow-hotplug
to your interfaces file for the eth-loco interface, and the interface will automatically be brought up when the device is plugged in.
Our hosts file looks very similar to that of the OCU, we just need to define things as before, in /etc/hosts
127.0.0.1 localhost
127.0.1.1 rpi
192.168.210.44 tx2 jetson
192.168.150.14 ocu katla
In our case, the OCU's hostname is katla. Change it to whatever you're using.
Our RPI image is Ubuntu 18.04, so we need to use netplan. To define our netplan interfaces, we put the following text in the /etc/netplan/50-cloud-init.yaml
file.
network:
version: 2
renderer: networkd
ethernets:
eth-int:
dhcp4: no
addresses: [192.168.210.43/24]
# gateway4: 192.168.210.43
nameservers:
addresses: [8.8.8.8,8.8.4.4]
eth-ext:
dhcp4: no
addresses: [192.168.150.43/24]
gateway4: 192.168.150.14
nameservers:
addresses: [8.8.8.8,8.8.8.4]
To check the file, run sudo netplan try
. If there are no issues, run sudo netplan apply
For the RPI, we need to make sure that our network configuration passes packets between the OCU and TX2 across the eth-internal and eth-external interfaces.
Make your routing table resemble this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default ocu 0.0.0.0 UG 0 0 0 eth-ext
default ebm-rc-1-be501- 0.0.0.0 UG 600 0 0 wlan0
10.131.0.0 0.0.0.0 255.255.0.0 U 600 0 0 wlan0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 eth-ext
192.168.210.0 0.0.0.0 255.255.255.0 U 0 0 0 eth-int
Lastly, get your eth-int and eth-ext interfaces to start on boot by adding lines for them to /etc/udev/rules.d/70-persistent-net.rules
:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="dc:a6:32:30:43:1c", NAME="eth-int"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:c6:51:f0:fe", NAME="eth-ext"
Again, you'll need to update the address to the appropriate MAC address for your device.
In a process that should be familiar now, in your /etc/hosts
file, add these lines:
127.0.0.1 localhost
127.0.1.1 tx2
127.0.1.1 jetson
192.168.210.43 pi rpi
192.168.150.14 ocu katla
Again, use a different name alias for your OCU.
This is for the /etc/network/interfaces
file.
auto eth-int
iface eth-int inet static
address 192.168.210.44
netmask 255.255.255.0
gateway 192.168.210.43
#allow-hotplug eth-int
Currently, there is no extra routing being done on the TX2. If that changes (possibly to allow general internet traffic to pass to the OCU's wifi, which is currently not working), we'll add documentation here.
This line goes in your /etc/udev/rules.d/70-persistent-net.rules
file to enable on-boot raising of the internal ethernet interface:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:4b:8c:fa:39", NAME="eth-int"
Again, change your MAC address to the appropriate one for your device.
This wiki is a living document and may be updated as new information becomes available.
If you find an error in the documentation or something insufficiently explained, submit an issue on this repository.
- Design Improvements
- Parts List
- Fabricating Mounting Structures (General Instructions)
- Power System Assembly
- Thruster System Assembly
- Computing System Assembly
- Networking Assembly and Tether
- Sensor Assembly
- OLED Assembly
- Enclosure Assembly (Left)
- Enclosure Assembly (Right)
- Final Assembly