ROS2 driver cannot reconnect after sensor reboot.

[aanliker]

The ros2_driver does not reconnect to the sensor after a sensor reboot.

We are using following setup: firmware: 2_2.123.5, branch: main (commit: 9f3a1d0 )

Following logs have been seen:

2025-11-06 15:58:12.116info[bash-1] [INFO] [1762441092.114944584] [fixposition_driver_ros2]: Reconnecting in 5.0 seconds...

2025-11-06 15:58:12.116warn[bash-1] [WARN] [1762441092.114798885] [fixposition_driver_ros2]: Warning: Bad stream spec: 

2025-11-06 15:58:11.420warn[bash-1] [WARN] [1762441091.419339882] [fixposition_driver_ros2]: Failed sending FP_B-MEASUREMENTS message [20x]

2025-11-06 15:58:11.420warn[bash-1] [WARN] [1762441091.419223720] [fixposition_driver_ros2]: no connection, cannot write [20x]

2025-11-06 15:58:10.410warn[bash-1] [WARN] [1762441090.408340099] [fixposition_driver_ros2]: Failed sending FP_B-MEASUREMENTS message [20x]

2025-11-06 15:58:10.409warn[bash-1] [WARN] [1762441090.408089214] [fixposition_driver_ros2]: no connection, cannot write [20x]

2025-11-06 15:58:09.398warn[bash-1] [WARN] [1762441089.396119203] [fixposition_driver_ros2]: Failed sending FP_B-MEASUREMENTS message [20x]

Even after getting a fix, the driver does not seem to connect again.

We are using following config at the moment:

/**:
    ros__parameters:
        # - TCP client (<ip_address>:<port>)
        stream: tcpcli://10.42.0.109:21000

        # Delay warning threshold [s].
        # Note that this only works if your system time is synced to the VRTK2.
        # This must be a float.
        delay_warning: 0.1

        # Messages that should be used by the driver.
        messages:
            - "FP_A-ODOMETRY"          # configuration: FP_A-ODOMETRY
            - "FP_A-ODOMSTATUS"        # configuration: FP_A-ODOMSTATUS
            - "FP_A-RAWIMU"            # configuration: FP_A-RAWIMU
            - "FP_A-CORRIMU"           # configuration: FP_A-CORRIMU
            - "FP_A-LLH"               # configuration: FP_A-LLH
            - "NOV_B-HEADING2"         # Heading and Baseline estimation
        # Driver behaviour
        fusion_epoch: true   # Enable fusion epoch output
        nmea_epoch: ""       # Choice for NMEA collection
        raw_output: false    # Enable raw messages output
        cov_warning: true    # Enable covariance warnings
        nav2_mode: false     # Enable nav2 mode
        # Node parameters
        output_ns: "/fixposition"
        speed_topic: "/fixposition/speed"        # Wheelspeed input, empty to disable
        qos_type: "sensor_short"
... 

The sensor connection is reestablished. Connecting to the GUI and pinging the sensor is successful.

Any idea how this can be solved?

[flipflip8952]

Hi. Yes, that behaviour is expected. The fixposition_driver loses the connection to the sensor if the sensor reboots (or the network cable is unplugged, or network is reconfigured on the sensor, or...). It does not automatically reconnect if the connection is taken away.

It's a valid idea to implement some automatic reconnection when connection is lost.

For now this is a "won't fix" and you'll have to restart the fixposition_driver node to re-establish the connection.

We may follow up on this at some point. See #100