> For the complete documentation index, see [llms.txt](https://docs.rtkdata.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rtkdata.com/integration-hub/robotics/unitree-go2-rtk.md). # Unitree Go2 RTK: Add RTK GPS to the Go2 EDU with ROS 2 Unitree lists GPS but no RTK for the Go2. Add an RTK GNSS receiver to a Go2 EDU and stream RTKdata NTRIP corrections to it with the ROS 2 NTRIP client. According to Unitree's specification, the **Unitree Go2** robot dog has no RTK: the Go2 PRO, X and EDU list a "4G Module(with GPS)", and Unitree documents neither RTK nor a developer interface for that GPS. A Unitree Go2 RTK setup uses an external RTK GNSS receiver on a **Go2 EDU**: connect the receiver by USB to a Linux companion computer with ROS 2 Humble (or Jazzy), run the receiver driver and the ROS 2 NTRIP client (`ntrip_client`) there, and connect `ntrip_client` to RTKdata with the host for your region (`rtk.rtkdata.com` for North America, `eu.rtkdata.com` for Europe or `aus.rtkdata.com` for Australia), port `2101`, the `AUTO` mountpoint and your RTK credentials. `ntrip_client` sends the receiver's own GGA sentences to the caster and publishes the corrections on `/rtcm`, where the driver passes them to the receiver. The Go2 statements on this page follow Unitree's Go2 developer documentation (About Go2, FAQ, Payload, Quick Start and Network, plus the pages on the expansion dock, SLAM, ROS 2, the Go2-W and Unitree's Industrial-grade Navigation, read in September 2026). The ROS 2 steps follow the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide, which has the complete parameter files, and the source code of `ntrip_client` 1.4.1 and of the `ublox` driver on its `ros2` branch (release 3.0.0), the current versions in September 2026. These are the values for `ntrip_client` on the computer that runs the GNSS stack; the names in code format are its parameters. Choose the server closest to your work area. All three servers share the same base station network; the difference is routing latency, see [NTRIP Server Settings](/get-started/network.md). {% tabs %} {% tab title="North America" %} * **Host (domain)** in `host`: `rtk.rtkdata.com` * **Host (IP fallback):** `13.56.117.10`, only if the computer cannot resolve the hostname * **Port:** `2101`, in `port` * **Username / Password:** From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/), not your website login, in `username` and `password` with `authenticate: true` * **Mountpoint (ALL CAPS):** `AUTO` (recommended), or `AUTO_WGS84`, `AUTO_ITRF2020`, `AUTO_ITRF2014`, in `mountpoint` {% endtab %} {% tab title="Europe" %} * **Host (domain)** in `host`: `eu.rtkdata.com` * **Host (IP fallback):** `3.73.41.96`, only if the computer cannot resolve the hostname * **Port:** `2101`, in `port` * **Username / Password:** From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/), not your website login, in `username` and `password` with `authenticate: true` * **Mountpoint (ALL CAPS):** `AUTO` (recommended), or `AUTO_WGS84`, `AUTO_ITRF2020`, `AUTO_ITRF2014`, in `mountpoint` {% endtab %} {% tab title="Australia" %} * **Host (domain)** in `host`: `aus.rtkdata.com` * **Host (IP fallback):** `54.206.56.130`, only if the computer cannot resolve the hostname * **Port:** `2101`, in `port` * **Username / Password:** From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/), not your website login, in `username` and `password` with `authenticate: true` * **Mountpoint (ALL CAPS):** `AUTO` (recommended), or `AUTO_WGS84`, `AUTO_ITRF2020`, `AUTO_ITRF2014`, in `mountpoint` {% endtab %} {% endtabs %} | Field | Value | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `host`, North America | `rtk.rtkdata.com`, IP fallback `13.56.117.10` | | `host`, Europe | `eu.rtkdata.com`, IP fallback `3.73.41.96` | | `host`, Australia | `aus.rtkdata.com`, IP fallback `54.206.56.130` | | `port` | `2101` | | `mountpoint` | `AUTO` (recommended), or `AUTO_ITRF2020`, `AUTO_ITRF2014`, `AUTO_WGS84` | | `authenticate` | `true` | | `username` and `password` | From *RTK Credentials* in your [account dashboard](https://rtkdata.com/my-account/rtk-credentials/). The username starts with `rtk` and is not your website login. | | `rtcm_message_package` | `rtcm_msgs`, the message type the `ublox` driver reads on `/rtcm` | | GGA to the caster | The receiver's own NMEA sentences on `/nmea`, from `ublox_gps` with `publish.nmea: true` and `rate: 1.0` | | Computer address on the Go2 network | An address in `192.168.123.x`, for example `192.168.123.222`, never `192.168.123.161` | * Enter only the hostname or the IP address in `host`, without `http://` and without `:2101`. `ntrip_client` opens a TCP connection to `host` on `port`. * Mountpoint names are case sensitive: `AUTO` in capitals. * One data stream allows one connection at a time. A second robot, a drone or a rover running at the same time needs its own data stream, see [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices). ## Requirements * **Unitree Go2 EDU.** Unitree states: "Only EDU or above versions can be developed". The optional expansion dock is not needed for this setup. * **RTK GNSS receiver with a USB port** that accepts RTCM 3 corrections with MSM4 messages and 1005. RTKdata streams RTCM 3.2 with MSM4 messages (1074, 1084, 1094, 1114, 1124, 1134) and 1005. Example: the u-blox ZED-F9P; u-blox states that its rover needs base station observations as MSM4 or MSM7 messages and the station position as 1005 or 1006 to attempt ambiguity fixes (ZED-F9P Integration Manual, section 3.1.5.4). The same section adds that GLONASS ambiguities need RTCM 1230 or 1033. 1230 comes from the base station, and most RTKdata base stations do not send it, so GLONASS does not contribute to the RTK fix. GPS, Galileo and BeiDou are not affected. * **Multi-frequency GNSS antenna** with the ground plane its manufacturer specifies * **Linux companion computer** with Ubuntu 22.04 and ROS 2 Humble, which Unitree's `unitree_ros2` marks as recommended, or Ubuntu 24.04 and ROS 2 Jazzy, with a USB port for the receiver and an Ethernet port for the Go2 * **Internet for the companion computer** with outbound TCP on port `2101`, for example over a USB Wi-Fi adapter or an LTE modem * **RTKdata account** with active RTK credentials (username starts with `rtk`), with one data stream per robot connected at the same time * **RTKdata coverage** at your site: check the [coverage map](/get-started/coverage-map.md) before you go out {% hint style="info" %} Don't have an RTKdata.com account yet? [Start 30-day Free Trial](https://rtkdata.com/try-rtk-corrections-free-for-30-days/) or [View Pricing](https://rtkdata.com/pricing/) {% endhint %} ## Does the Unitree Go2 have RTK? No: according to Unitree's Go2 specification, no Go2 model has RTK; the PRO, X and EDU have a "4G Module(with GPS)", Unitree documents no RTK and no developer interface for the Go2 GPS, and RTK with RTKdata corrections needs an external RTK GNSS receiver on a Go2 EDU. * Unitree's About Go2 product list shows the "4G Module(with GPS)" as "No" on the AIR and "Yes, CN/GB" on the PRO, X and EDU. The list has no RTK entry for any Go2 model. * Unitree's SDK and ROS 2 package define no GNSS message type: the Go2 message types in `unitree_sdk2` (`include/unitree/idl/go2`) and in the `unitree_go` package of `unitree_ros2` include no GNSS type. There is therefore no documented Go2 topic with a GNSS position, such as a `sensor_msgs/msg/NavSatFix`, that could give `ntrip_client` a position for GGA. * Unitree's own RTK is an optional "dual-antenna RTK module" for its Industrial-grade Navigation software, together with a 5G module, a "differential account (provided by the user or Unitree)" and a data SIM card. The software's list of compatible robot models names the B2, B2W, G1-EDU, A2 PRO and A2-W PRO as currently supported and the As2-EDU under extended support, and its specification table lists RTK-integrated positioning for the B2/B2W and A2/A2W. The Go2 is on neither list. For RTK on a Go2, add an external RTK receiver with its own antenna, as described on this page. ## Which Go2 models can take an external RTK receiver? Of the Go2 AIR, PRO, X and EDU, only the Go2 EDU has documented interfaces for an external RTK receiver: Unitree reserves the RJ45, DC 28.8V and SBUS interfaces for the EDU, offers the optional NVIDIA Jetson Orin module only on the EDU, and lists secondary development as "Support" for the EDU and as "Basic support" for the X. The Go2-W has the same interfaces, but this guide does not cover it. | Unitree specification | AIR | PRO | X | EDU | | ---------------------------------- | --- | ---------- | ------------------------ | -------------------------------------------- | | Secondary development | No | No | Basic support | Support | | RJ45, DC 28.8V and SBUS interfaces | No | No | No, exclusive to the EDU | Yes | | High computing power module | No | No | No | Optional NVIDIA Jetson Orin (40 to 100 Tops) | | 4G Module(with GPS) | No | Yes, CN/GB | Yes, CN/GB | Yes, CN/GB | Unitree's note on the electrical interfaces reads: "The Go2 Pro and Go2 Air versions do not support any of the extended electrical interfaces, including the SBUS port, DC 28.8V power output, and the Ethernet (RJ45) interface. These interfaces are exclusive to the Go2 EDU version." * The Unitree FAQ states: "Only EDU or above versions can be developed, other versions such as PRO and AIR versions do not open the secondary development interface". * For the X, the product list shows "Basic support" for secondary development but no computing module, and the note above names the extended interfaces as exclusive to the EDU. * For the Go2-W, Unitree's About Go2-W page lists "Secondary development" as "Yes" and the same RJ45, DC 28.8V and SBUS interfaces. ## Where should the GNSS stack run: expansion dock or companion computer? Run the receiver driver and `ntrip_client` for RTKdata on a companion computer with ROS 2 Humble or Jazzy that is connected to the Go2 EDU by Ethernet, because Unitree's documentation shows the expansion dock with Ubuntu 20.04 and ROS 2 Foxy, and the Foxy packages in the ROS package repository include no u-blox driver that takes corrections from a ROS topic. * Unitree's screenshot of the dock login shows "Ubuntu 20.04.6 LTS" on "aarch64" and the prompt `ros:foxy(1) noetic(2) ?`. * For Foxy, the ROS package repository has `ntrip_client` 1.2.0, which publishes corrections only as `mavros_msgs/RTCM` and takes GGA only from `nmea`, and `ublox_gps` 2.1.0, which has no RTCM input. `ublox_dgnss` is not available for Foxy. * On a companion computer with Humble or Jazzy, `ntrip_client` 1.4.1 installs from apt, and the `ublox` driver built from its `ros2` branch subscribes to `/rtcm`. * If the same computer also talks to the Go2 through `unitree_ros2`, prefer Humble: Unitree lists Ubuntu 20.04 with Foxy and Ubuntu 22.04 with Humble as the tested systems for its ROS 2 package and marks Humble as recommended. * Connect the companion computer to the Go2 by Ethernet cable. The Unitree FAQ states: "Go2 only supports wired connection for development." Use the RJ45 interface on the back of the Go2 EDU or, with the expansion dock fitted, the dock's second RJ45 port, which Unitree describes as "externally connected to the user". * Give the computer's Ethernet adapter an address in the `192.168.123.x` subnet, for example `192.168.123.222`. Unitree does not allow `192.168.123.161` on the computer, because it is the address of the Go2's built-in computer. `ping 192.168.123.161` tests the link. **Without the ROS 2 NTRIP client:** use a receiver with its own NTRIP client and its own internet connection; the robot computer then only reads the position from the receiver. For example, enter the RTKdata values in the NTRIP client of a Septentrio receiver through its web interface, as described in the [Septentrio mosaic-X5](/integration-hub/gnss-rovers-and-receivers/septentrio-mosaic-x5.md) guide. On ROS 2, `septentrio_gnss_driver` can write them into the receiver through `rtk_settings.ntrip_1` instead. Set `send_gga` to `sec1` there, because in `auto` mode the receiver sends GGA only if the caster requests it, according to the driver documentation. The Septentrio tab of the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide covers driver version 1.4.8 for Humble and Jazzy. For Foxy, which the expansion dock runs, apt has version 1.2.3, which starts with other launch files: its README gives `ros2 launch septentrio_gnss_driver rover_node.py`, and the launch file takes the full path of your parameter file in `path_to_config`. {% hint style="warning" %} **Only if you use the expansion dock:** do not activate a ROS environment in a terminal where you run Unitree's SLAM or SDK2 tools. Unitree states that these tools "require CycloneDDS and cannot be launched in an environment where ROS/ROS2 has been initialized". Press Enter at the prompt `ros:foxy(1) noetic(2) ?` in that terminal, and run ROS 2 nodes in a separate terminal. {% endhint %} ## How do you mount and power the RTK receiver on the Go2? Mount the antenna at the highest point of the Go2 with open sky, on the ground plane its manufacturer specifies and away from the computer, cameras, LiDAR and radios, and power the receiver over USB from the companion computer or from a 12 V or 5 V output of the expansion dock, not from the DC 28.8V back output. ### Antenna position * Place the antenna where nothing on the robot blocks the sky. The best conditions have no obstructions above 15 degrees elevation, see [Accuracy Expectations](/get-started/accuracy-expectations.md). * Use the ground plane the antenna manufacturer specifies. For example, u-blox measures the ANN-MB antenna on a 15 cm ground plane, gives its phase center offset for a circular ground plane of 120 mm diameter and states: "Any change in ground plane size or shape may affect the phase center offset." * Keep the antenna away from the dock computer, the cameras, the LiDAR and the Go2's 4G and Wi-Fi radios. u-blox warns that "all types of digital equipment, such as PCs, digital cameras, LCD screens, etc. tend to emit a broad frequency spectrum up to several GHz", and that wireless systems such as LTE, WLAN and Bluetooth close to the GNSS antenna can interfere (ZED-F9P Integration Manual, section 4.6.1). * Mounting points: the expansion dock has guide rails, with the dimensions under "Rail size" on Unitree's Payload page, and Unitree fixes its servo arm to these rails with a square nut and "M4\*10 internal hexagon screws". The Go2 EDU back has load mounting holes, shown in Unitree's "Back load installation hole map". * Weight: Unitree gives the Go2 EDU a load of about 8 kg, with a limit of about 12 kg. The receiver, antenna, mounts, companion computer and LTE modem on the robot all count toward it. ### Power and data | Power source (Unitree specification) | Output | Use for a receiver | | -------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Expansion dock, XT30U-F power interface | 12 V, 3 A and 5 V, 3 A, one output each for the user | Receivers with a 12 V or 5 V power input | | Expansion dock, USB-Type A and the two USB-C ports | 5 V/1 A on USB-Type A ("Only USB host"), 5 V/3 A and 5 V/2 A on the USB-C ports | Not for this setup: a receiver on these ports connects to the dock computer, not to the companion computer that runs the driver | | Go2 EDU back, power interface | DC 28.8V, the battery voltage (Go2 supply voltage 28 V to 33.6 V) | Only devices rated for this input range | * Connect the receiver by USB to the companion computer, which runs its driver. `ublox_gps` opens `/dev/ttyACM0` by default (parameter `device`). * If you power a companion computer from the Go2, the same applies: the back output carries the battery voltage. ## How does the Go2 get internet for RTK corrections? Give the computer that runs `ntrip_client` its own internet connection to RTKdata, for example over a USB Wi-Fi adapter or an LTE modem, with outbound TCP on port `2101`, because Unitree does not document that the expansion dock or a companion computer can use the Go2's Wi-Fi or 4G connection. * The expansion dock has Wi-Fi only with an "additional wireless network card", according to Unitree's SLAM documentation. * On the Go2's 4G channel, "some restrictions are placed on accessing domain names to prevent traffic consumption", according to Unitree's network documentation. * For the "non-Chinese mainland version" of the Go2, Unitree states that the 4G function "will only support 43 European countries (except Ukraine), and some Asian regions". * RTKdata needs outbound TCP on port `2101`. Firewalls, VPNs and some mobile carriers can block this port, see [Troubleshooting & FAQ](/support/troubleshooting-and-faq.md). * Use a stable connection: RTKdata recommends a stable 4G or 5G connection and no public Wi-Fi or VPN, see [Accuracy Expectations](/get-started/accuracy-expectations.md). ## How do you set up RTKdata on a Go2 EDU with ROS 2? Mount the receiver on a Go2 EDU, connect it by USB to a companion computer with internet, install `ntrip_client` and the `ublox` driver there, create the two parameter files from the ROS 2 NTRIP Client guide, connect `ntrip_client` to RTKdata with the host for your region, port `2101` and `AUTO`, start both nodes and check `/nmea`, `/rtcm` and the fix status. The steps use a u-blox ZED-F9P and ROS 2 Humble as the example. {% stepper %} {% step %} ### Check the Go2 model Check that the robot is a Go2 EDU: the RJ45, DC 28.8V and SBUS interfaces on its back exist only on the EDU. On the AIR and PRO, Unitree opens no secondary development interface. {% endstep %} {% step %} ### Mount the receiver and antenna Fit the receiver to the dock rails or the back mounting holes, and the antenna at the highest point with its ground plane, away from the computer, cameras, LiDAR and radios, as described in *How do you mount and power the RTK receiver on the Go2?* above. {% endstep %} {% step %} ### Connect USB, power and Ethernet 1. Connect the receiver by USB to the companion computer. `ublox_gps` expects it at `/dev/ttyACM0` unless you set another `device`. 2. If the receiver needs its own supply, use a 12 V or 5 V output of the expansion dock, not the DC 28.8V back output. 3. Connect the companion computer to the Go2 by Ethernet cable, set its adapter to an address such as `192.168.123.222` and test the link: ```bash ping 192.168.123.161 ``` {% endstep %} {% step %} ### Give the computer internet Connect the companion computer to the internet over its own uplink, for example a USB Wi-Fi adapter or an LTE modem, and make sure that outbound TCP on port `2101` is open. {% endstep %} {% step %} ### Install ntrip\_client and the ublox driver Install `ntrip_client` from the ROS 2 package repository (on Jazzy, the package is `ros-jazzy-ntrip-client`): ```bash sudo apt install ros-humble-ntrip-client ``` Build the `ublox` driver from its `ros2` branch in a ROS 2 workspace at `~/ros2_ws`. The `ros-humble-ublox-gps` package from apt (2.3.0) has no RTCM input; the `ros2` branch (release 3.0.0) subscribes to `/rtcm` and publishes the receiver's NMEA sentences on `/nmea`. If the computer has no ROS 2 build tools yet, install them and set up `rosdep` once: ```bash sudo apt install ros-dev-tools sudo rosdep init rosdep update ``` Then create the workspace and build the driver. On Jazzy, source `/opt/ros/jazzy/setup.bash` instead: ```bash source /opt/ros/humble/setup.bash mkdir -p ~/ros2_ws/src cd ~/ros2_ws/src git clone --branch ros2 https://github.com/KumarRobotics/ublox.git cd ~/ros2_ws rosdep install --from-paths src --ignore-src -r -y colcon build source install/setup.bash ``` {% endstep %} {% step %} ### Create the two parameter files Create `~/ublox_rover.yaml` for the receiver driver and `~/rtkdata_ntrip.yaml` for `ntrip_client` with the content from the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide: `ublox_rover.yaml` from its tab *u-blox ZED-F9P (ublox\_gps)* and `rtkdata_ntrip.yaml` from its step *Create the parameter file*, for your region. The guide also explains why these values differ from the defaults. The values that matter: | File | Parameter | Value | | -------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `ublox_rover.yaml` | `tmode3` | `0`, rover mode. The `zed_f9p.yaml` that comes with the driver sets `1`, survey-in, which makes the receiver a base | | `ublox_rover.yaml` | `gnss.gps`, `gnss.glonass`, `gnss.galileo`, `gnss.beidou`, `gnss.qzss` | `true`. With `config_on_startup` on, the driver writes these values to the receiver, and only `gnss.gps` defaults to `true` | | `ublox_rover.yaml` | `rate` | `1.0` (Hz), in line with the GGA rate of 1 Hz that RTKdata recommends | | `ublox_rover.yaml` | `publish.nmea` | `true`, the GGA source for `ntrip_client` | | `rtkdata_ntrip.yaml` | `host`, `port`, `mountpoint` | The host for your region, `2101`, `AUTO` | | `rtkdata_ntrip.yaml` | `authenticate`, `username`, `password` | `true` and your RTK credentials | | `rtkdata_ntrip.yaml` | `rtcm_message_package` | `rtcm_msgs` | | `rtkdata_ntrip.yaml` | `nmea_max_length` | `128` | | `rtkdata_ntrip.yaml` | `rtcm_timeout_seconds` | `15` | | {% endstep %} | | | {% step %} ### Start both nodes and check the fix Start each node in its own terminal with the workspace sourced (`source ~/ros2_ws/install/setup.bash`). If the computer also talks to the Go2 through `unitree_ros2`, source `~/unitree_ros2/setup.sh` before the workspace, see *ROS 2 distribution, RMW and time stamps* below. Start the driver first and wait until the receiver has a position (`status.status` on `/ublox_gps_node/fix` is no longer `-1`), then start `ntrip_client`: ```bash ros2 run ublox_gps ublox_gps_node --ros-args --params-file ~/ublox_rover.yaml ``` ```bash ros2 run ntrip_client ntrip_ros.py --ros-args --params-file ~/rtkdata_ntrip.yaml ``` Then check the three stages: ```bash ros2 topic echo /nmea ros2 topic info /rtcm --verbose ros2 topic echo /ublox_gps_node/fix ``` 1. `/nmea` shows GGA sentences from the receiver. Without them, `AUTO` has no position and sends no corrections. 2. `ntrip_client` logs `Connected to http://eu.rtkdata.com:2101/AUTO` (with your host) once the login works. `ros2 topic info /rtcm --verbose` lists `ntrip_client` as a publisher and `ublox_gps_node` as a subscriber. 3. On `/ublox_gps_node/fix`, `status.status` is `2` (`STATUS_GBAS_FIX`) when the receiver has a fixed carrier phase solution, which is RTK Fixed. `0` is a fix without fixed ambiguities, which includes RTK Float, and `-1` is no fix. {% hint style="info" %} **AUTO needs your position.** The `AUTO` mountpoint chooses the base station from the position the receiver sends as NMEA GGA. On the Go2, only the external receiver can provide it: `ntrip_client` sends the sentences that arrive on `/nmea` to the caster, and the Go2 has no documented GNSS topic. Without a position, the login works but no corrections arrive, see [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md). Wait outside with open sky until the receiver has a position of its own. {% endhint %} {% endstep %} {% endstepper %} ## How do you use RTK positions for Go2 navigation? Keep waypoints and maps in the datum that your RTKdata mountpoint delivers, plan a source of absolute heading, and run the GNSS nodes with the same ROS 2 distribution and RMW implementation as the nodes that talk to the Go2. ### Datum and heights with AUTO * `AUTO` delivers your region's datum, chosen from your GGA position: for example NAD83(2011), epoch 2010.0, in the USA; NAD83(CSRS)v7, epoch 2010.0, in Canada; ETRS89 (realization ETRF2000), epoch 2010.0, in Europe; and GDA2020, epoch 2020.0, in Australia. For regions not listed, `AUTO` falls back to WGS84(G2139) at the mid-year epoch. The datum for every region is listed in [Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md). * `AUTO_ITRF2020` and `AUTO_ITRF2014` deliver ITRF2020 and ITRF2014 at the current epoch, and `AUTO_WGS84` delivers WGS84(G2139) at the mid-year epoch. * u-blox states that the rover coordinates "will be expressed in the datum used by the RTCM correction provider". With `AUTO`, latitude and longitude on `/ublox_gps_node/fix` are therefore in the regional datum, although `sensor_msgs/msg/NavSatFix` is "Specified using the WGS 84 reference ellipsoid" and has no datum field. * For waypoints from web maps or other WGS 84 sources, use `AUTO_WGS84` or `AUTO_ITRF2020`. For waypoints surveyed with RTK on `AUTO`, stay on `AUTO`. A steady offset of 50 cm to 1 m usually means mixed datums, see [Why Your Coordinates May Be Offset](/get-started/coordinate-systems-and-datums.md#why-your-coordinates-may-be-offset). * Heights are ellipsoidal, see [Understanding Heights](/get-started/understanding-heights.md). * u-blox states that the ZED-F9P stops using RTCM corrections older than 60 s (the default, set with `CFG-NAVSPG-CONSTR_DGNSSTO`) and drops back to a 3D or 3D/DGNSS mode, and that the reference frame of the output position then switches from that of the correction data to that of the standard position solution. With `AUTO`, the position can then shift by the datum difference, so use a position for navigation only while `status.status` is `2`. ### Absolute heading and robot\_localization * The Nav2 documentation states: "When using robot\_localization with GPS, measuring absolute orientation is mandatory." * The Go2 IMU message `unitree_go/msg/IMUState` has the fields `quaternion`, `gyroscope`, `accelerometer`, `rpy` and `temperature`, and no magnetometer field. Plan a source of absolute heading; Nav2 names "IMUs with magnetometers, dual GPS systems or matching techniques over a known map". * In its source code (`robot_localization` 3.5.4 on Humble, 3.8.3 on Jazzy), `navsat_transform_node` subscribes to `gps/fix` (`sensor_msgs/msg/NavSatFix`), `odometry/filtered` (`nav_msgs/msg/Odometry`) and, with its default parameters, `imu` (`sensor_msgs/msg/Imu`) for the heading. Remap `gps/fix` to `/ublox_gps_node/fix`. * The Go2 state topics that Unitree documents for ROS 2, `sportmodestate` and `lowstate`, carry Unitree's own messages `unitree_go/msg/SportModeState` and `unitree_go/msg/LowState`, not `sensor_msgs/msg/Imu` or `nav_msgs/msg/Odometry`. To use Go2 data in `robot_localization`, convert it with a node of your own first. ### ROS 2 distribution, RMW and time stamps * Unitree's `unitree_ros2` talks to the Go2 over CycloneDDS: its `setup.sh` sets `RMW_IMPLEMENTATION=rmw_cyclonedds_cpp` and a `CYCLONEDDS_URI` with the network interface that is connected to the Go2. * The ROS 2 documentation states: "Nodes are not guaranteed to be able to communicate across distributions", and communication across RMW vendors within one distribution is not guaranteed either. Run the GNSS nodes with the same distribution and RMW implementation as the Go2 connection. * If the companion computer talks to the Go2 through `unitree_ros2`, run the GNSS nodes in terminals with the same environment as the Go2 connection. As the `unitree_ros2` README describes, replace `foxy` with your ROS 2 distribution and `enp3s0` with the network interface connected to the Go2 in `~/unitree_ros2/setup.sh`. Then source it before the GNSS workspace in each terminal: ```bash source ~/unitree_ros2/setup.sh source ~/ros2_ws/install/setup.bash ``` * `ublox_gps` stamps `/ublox_gps_node/fix` with the receiver's UTC time when it is valid and with the computer's ROS time otherwise. Before you fuse the fix with Go2 odometry, for example in `robot_localization`, check that the time stamps of the Go2 topics and of the fix agree. ## Troubleshooting | Problem | Cause | Fix | | -------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | No GPS, GNSS or fix topic from the Go2 | Unitree's SDK and ROS 2 package define no GNSS message type, and Unitree documents no developer interface for the Go2 GPS | Add an external RTK receiver with its own ROS 2 driver, as described on this page | | `Unable to connect socket to server at http://:2101` in the `ntrip_client` log | The computer that runs `ntrip_client` has no internet, cannot resolve the hostname, or port 2101 is blocked | Give the computer its own uplink (USB Wi-Fi adapter or LTE modem), allow outbound TCP on port 2101, and try the IP fallback for your region in `host`. `ntrip_client` exits after a failed first connection: start it again once the uplink is up, or start it from a launch file with `respawn=True` as shown in the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide | | On the expansion dock, apt installs `ros-foxy-ntrip-client` 1.2.0 and `ros-foxy-ublox-gps` 2.1.0, and the receiver gets no corrections | The dock runs Ubuntu 20.04 with ROS 2 Foxy. `ntrip_client` 1.2.0 publishes only `mavros_msgs/RTCM`, and `ublox_gps` 2.1.0 has no RTCM input | Run the GNSS stack on a companion computer with Humble or Jazzy, or use a receiver with its own NTRIP client | | `ping 192.168.123.161` fails from the companion computer | The Ethernet adapter has no address in the `192.168.123.x` subnet, or the cable is not connected | Set an address such as `192.168.123.222` on the adapter connected to the Go2 and check the cable. Never set `192.168.123.161` on the computer | | Receiver connected to the DC 28.8V back output | This output carries the battery voltage, 28 V to 33.6 V | Power the receiver over USB from the companion computer or from a 12 V or 5 V output of the expansion dock, unless it is rated for this input range | | Corrections drop again and again while a second robot or a drone is running | Both devices share one data stream, for example through the same RTK credentials | One data stream per device connected at the same time, see [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices) | | `ntrip_client` logs `Connected to ...`, but no corrections arrive on `/rtcm` | No GGA reaches the caster: `/nmea` stays empty, for example because `publish.nmea` is off or the receiver outputs no NMEA | Check `ros2 topic echo /nmea`, then the troubleshooting table of the [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md) guide | | `/rtcm` carries data, but `status.status` never reaches `2` | The driver does not subscribe to `/rtcm`, for example `ublox_gps` 2.3.0 from apt, or constellations are switched off | Check that `ros2 topic info /rtcm --verbose` lists the driver as a subscriber, use the `ros2` branch of `ublox` and set all `gnss.*` values to `true` | | Position offset against waypoints from a web map | `AUTO` delivers the regional datum, while the web map uses WGS 84 | Use `AUTO_WGS84` or `AUTO_ITRF2020` for WGS 84 waypoints, or survey the waypoints on `AUTO` | | No Wi-Fi on the expansion dock | The dock needs an "additional wireless network card" | Add a USB Wi-Fi adapter or use an LTE modem | | Unitree SLAM or SDK2 tools on the dock do not start | A ROS environment is active in that terminal. Unitree: these tools "cannot be launched in an environment where ROS/ROS2 has been initialized" | Press Enter at `ros:foxy(1) noetic(2) ?` in that terminal and run ROS 2 nodes in another one | | Position shifts after a longer loss of corrections | The ZED-F9P stops using corrections older than 60 s, drops back to a 3D or 3D/DGNSS mode and outputs its position in the reference frame of the standard solution | Keep a stable uplink, and use a position for navigation only while `status.status` is `2` | For connection problems that are not specific to the Go2, see [Common Connection Issues](/support/common-connection-issues.md). ## Frequently asked questions ### Can the Go2's built-in GPS be used for RTK? No, not with any documented interface: the Unitree Go2 GPS is part of the "4G Module(with GPS)" of the PRO, X and EDU, and Unitree documents no RTK and no developer interface for it. Unitree's SDK and ROS 2 package define no GNSS message type, so there is no documented Go2 topic that could give `ntrip_client` a position for GGA or pass RTK corrections to the GPS. Use an external RTK receiver with its own antenna and connect it to RTKdata as described on this page. ### Does the Go2 Air or Pro work with an external RTK receiver? Not through a documented interface: Unitree states that "Only EDU or above versions can be developed" and that the PRO and AIR "do not open the secondary development interface". According to Unitree, the RJ45, DC 28.8V and SBUS interfaces are exclusive to the Go2 EDU. This guide covers RTKdata corrections on the Go2 EDU. ### Can I run the ROS 2 NTRIP client on the Go2 expansion dock? Not for the RTKdata setup on this page: Unitree's documentation shows the dock with Ubuntu 20.04 and ROS 2 Foxy, where the ROS package repository offers `ntrip_client` 1.2.0, which publishes corrections only as `mavros_msgs/RTCM`, and `ublox_gps` 2.1.0, which has no RTCM input. This guide runs the GNSS stack on a companion computer with Humble or Jazzy instead, where `ntrip_client` 1.4.1 connects to RTKdata on port `2101` with the `AUTO` mountpoint, and does not cover building newer versions on the dock. On the dock, a receiver with its own NTRIP client is the alternative, for example a Septentrio receiver set up in its web interface or with `septentrio_gnss_driver` 1.2.3, see *Without the ROS 2 NTRIP client* above. ### Does Unitree offer an RTK module for the Go2? Not according to Unitree's documentation: Unitree's optional "dual-antenna RTK module" belongs to its Industrial-grade Navigation software, whose list of currently supported robot models names the B2, B2W, G1-EDU, A2 PRO and A2-W PRO, not the Go2. For RTK on a Go2 EDU, add an external RTK receiver and stream RTKdata corrections to it with the ROS 2 NTRIP client. ### Do I need one RTKdata data stream per robot? Yes, one RTKdata data stream for each robot that is connected at the same time. One data stream allows one connection at a time, and two devices on the same data stream keep disconnecting each other, so the fix status keeps cycling between FIX, FLOAT and SINGLE. Robots that run one after another can share one set of credentials. Depending on how the account was provisioned, extra data streams come as separate credentials or as one set of credentials with several connections, see [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices). ## Quick reference 1. Go2 EDU only. Add an external RTK receiver with USB and a multi-frequency antenna, for example a u-blox ZED-F9P, with the antenna at the highest point on a ground plane, away from computers, cameras and radios. 2. Power the receiver over USB from the companion computer or from a 12 V or 5 V output of the expansion dock, not from the DC 28.8V back output. 3. Companion computer with Ubuntu 22.04 and ROS 2 Humble (or 24.04 and Jazzy), connected to the Go2 by Ethernet with an address such as `192.168.123.222` (never `192.168.123.161`, the address of the Go2's built-in computer), and its own internet with outbound TCP on port `2101`. 4. `sudo apt install ros-humble-ntrip-client`, and the `ublox` driver from its `ros2` branch, built with `colcon`. 5. `ublox_rover.yaml`: `tmode3: 0`, all `gnss.*` values `true`, `rate: 1.0`, `publish.nmea: true`. 6. `rtkdata_ntrip.yaml`: `host` `rtk.rtkdata.com`, `eu.rtkdata.com` or `aus.rtkdata.com` (IP fallback `13.56.117.10`, `3.73.41.96` or `54.206.56.130`), `port: 2101`, `mountpoint: AUTO`, `authenticate: true`, your RTK credentials, `rtcm_message_package: rtcm_msgs`, `nmea_max_length: 128`, `rtcm_timeout_seconds: 15`. 7. Start the driver, wait for a position, then start `ntrip_client`. Check GGA on `/nmea`, the driver as a subscriber in `ros2 topic info /rtcm --verbose`, and `status.status` `2` on `/ublox_gps_node/fix` for RTK Fixed. 8. For navigation, keep waypoints and fixes in one datum and add a source of absolute heading. If the computer also uses `unitree_ros2`, start the GNSS nodes after `source ~/unitree_ros2/setup.sh`. ## Related Guides * [ROS 2 NTRIP Client](/integration-hub/ntrip-clients-and-field-software/ros2-ntrip-client.md): the complete parameter files, other GNSS drivers and the `ntrip_client` log messages * [Robotics](/integration-hub/robotics.md): how RTK corrections reach a robot and which robots have an RTKdata guide * [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md): why the caster needs your position before it sends corrections * [u-center (u-blox F9)](/integration-hub/ntrip-clients-and-field-software/u-center-u-blox-f9.md): configure and bench-test a ZED-F9P on a Windows PC before it goes on the robot * [ArduSimple simpleRTK2B / simpleRTK3B](/integration-hub/gnss-rovers-and-receivers/ardusimple-simplertk2b.md): RTKdata setup for the ArduSimple boards with the u-blox ZED-F9P * [Septentrio mosaic-X5](/integration-hub/gnss-rovers-and-receivers/septentrio-mosaic-x5.md): the NTRIP client in the receiver, for a setup without `ntrip_client` * [NTRIP Server Settings](/get-started/network.md): the regional hosts, IP fallbacks, port and mountpoints in one reference * [Account & Credentials](/get-started/account-and-credentials.md#using-one-subscription-with-several-devices): where to find your RTK credentials and why each robot connected at the same time needs its own data stream * [Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md): which datum `AUTO` and its variants deliver in each region * [Understanding Heights](/get-started/understanding-heights.md): ellipsoidal and orthometric heights, and how to apply a geoid * [Accuracy Expectations](/get-started/accuracy-expectations.md): what sky view, internet latency and distance to the base station do to the fix * [Coverage Map](/get-started/coverage-map.md): check the station coverage at your site before you go out * [Common Connection Issues](/support/common-connection-issues.md): what to check when corrections do not arrive or the fix stays on Float * [Troubleshooting & FAQ](/support/troubleshooting-and-faq.md): port 2101, firewalls and carrier restrictions ## Related Industry Solutions * [Robotics](https://rtkdata.com/robotics/) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rtkdata.com/integration-hub/robotics/unitree-go2-rtk.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.