Comms

Author:

• Max Pacheco Ramírez

Set symlinks for device modularization

Because of the number of USB devices connected to the Jetson and the OGS, maintaining an order in which they must be plugged in can be confusing, and when dealing with the competition and all the hurries, this can result in a source for failures. That’s what symlinks are for!

For serial usb devices

Udev rules are set so the custom getty service to access to the boat’s terminal points to a Holybro radio device, to make on-site testings faster. These work by binding a usb device with a specific vendor and product id unique to each device. In this case, as only one Holybro radio (at most) will be connected to either the OGS or the boat, both radios are bound to the /dev/ttyHOLY identifier. This also makes it so it doesn’t matter which radio you have, you will always refer to the device on /dev/ttyHOLY. The same is done for the XBee radios (here, which radio you connect matters, because each runs a different ROS 2 node, and there are cases in which you want to connect both XBees to your computer, like when debugging for the USV’s web interface. Also the IMU is configured this way, for the same reason that plugging order shouldn’t matter.

To implement this, add this lines to the udev rule file /etc/udev/rules.d/99-dev.rules both in the Jetson and in your device:

# /etc/udev/rules.d/99-dev.rules

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="00000000", SYMLINK+="ttyXBEESTATION"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="D30DS1HZ", SYMLINK+="ttyXBEEBOAT"

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="D30GM3SB", SYMLINK+="ttyHOLY"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="D30GJX3L", SYMLINK+="ttyHOLY"

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FT0C9STB", SYMLINK+="ttyIMU"

Next, reset your device’s udev rules with the following command:

sudo udevadm control --reload-rules && sudo udevadm trigger

For network devices

For the usb canable adapter, a similar approach is followed. Add the following lines to the file /etc/systemd/network/10-can.link in the Jetson and your OGS, so both our Geschwister Schneider CAN type adapters are linked to the same interface in case we switch between one or another.

# /etc/systemd/network/10-can.link

[Match]
Driver=gs_usb

[Link]
Name=can_vtec

Next, update the interface links:

sudo update-initramfs -u
sudo reboot

Also, you should consider adding the following script to an accessible file so that you can easily enable the can interface on your computers:

#!/bin/bash
sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan

sudo ip link set down can_vtec
sudo ip link set can_vtec type can bitrate 125000
sudo ip link set up can_vtec

Enable remote access to boat’s terminal

In order to control global, important, or not necessarily ROS-related commands on the remote computer, Getty services are implemented.

Set RF Modules

Holybro SiK Telemetry Radios are used for this task, configured at 115,200 kbps on a separate channel to avoid interference with the RTK information being sent from another pair of the same radios, or the radios from other teams.

Getty

Based on this blog detailing instructions for getty service configurations, the following lines are added to a new file /etc/systemd/system/custom-getty@.service in the Jetson:

# /etc/systemd/system/custom-getty@.service
[Unit]
Description=Custom Serial Getty on %I
Documentation=man:agetty(8)
After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

[Service]
ExecStart=-/sbin/agetty -L 115200 %I vt220
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/ttyHOLY%I
TTYReset=yes
TTYVHangup=yes

[Install]
WantedBy=multi-user.target

To enable this service (every time before you’re starting the autonomy challenge), use the bash scripts on the .setup directory in vanttec_usv repository (if not in main branch, in branch develop). Also, if you’re having trouble with the service, see the README.md file on that hidden directory for debugging.

Connect!

Wowie! You should now be able to access the Jetson’s login prompt connecting to your XBee device using minicom on CLI:

sudo minicom -D /dev/ttyHOLY -b 115200 -c on

Remote access to ROS 2 topics

In order to have a visualization of the autonomous system’s status, because just doing a topic echo on the transparent mode from getty services isn’t as visually understandable as RViz, ROS 2 topics are sent on separate serial devices: the XBee S3B RF Modules.

XBee radios configuration

Using the XCTU Software, both XBee devices are set to a baud rate of 230,400 kbps and in API mode. The configuration parameters include:

• AP (API Enable) = API Mode with Escapes [2]

• BD (Interface Data Rate) = 230400 [7]

• NI (Node Identifier) = BOAT_XBEE for boat device, STATION_XBEE for ground station

• ID (Network ID) = Same value for both devices to ensure communication

ROS 2 nodes

In order to send the relevant variables for debugging from the remote device to the ground station, a ROS 2 interface through 2 nodes was developed. The logics for the XBee ROS 2 interface are:

• Configuration

  • Uses a YAML configuration file to specify:

    • Topic names and message types

    • XBee port configurations

    • Update rates

    • Enabled/disabled topics

  • Allows easy modification of transmitted data without code changes

• Boat Node (xbee_boat_node)

  • Subscribes to selected ROS 2 topics on the USV

  • Processes incoming messages into transmittable data

  • Packs data efficiently with message IDs and size information

  • Sends data chunks through XBee radio

  • Supports both numeric and string data types

  • Uses configurable update rate (default 10Hz)

• Station Node (xbee_station_node)

  • Receives packed data from boat node

  • Unpacks data based on message type

  • Republishes data to corresponding ROS 2 topics with /usv_comms prefix

  • Handles different message types appropriately:

    • Standard messages (pose, velocity, etc.)

    • Object lists with mixed data types

  • Provides error handling and logging

• Message Protocol

  • Efficient binary protocol for data transmission

  • Message structure:

    • Message ID (1 byte)

    • Message Size (2 bytes)

    • Packed data (variable length)

  • Type-aware packing for both numbers and strings

  • Error detection and validation

• Key Features

  • Modular design with base class for common functionality

  • Configuration-driven topic selection

  • Robust error handling and logging

  • Automatic network discovery

  • Bandwidth-efficient message packing

  • Support for complex message types (like object lists)

• Usage

  • Start nodes:

    # On the boat:
    ros2 run usv_comms xbee_boat_node
    
    # On the ground station:
    ros2 run usv_comms xbee_station_node
    

  • Monitor topics:

    # View republished topics
    ros2 topic list | grep "/usv_comms"
    

This implementation provides a reliable and configurable way to monitor the autonomous system’s state remotely, enabling better debugging and visualization through tools like RViz while maintaining efficient bandwidth usage through careful message packing and topic selection.