The Rosario Dataset v2: Multimodal Dataset for Agricultural Robotics

TL;DR

The Rosario Dataset v2 provides a comprehensive multimodal dataset from soybean fields to advance localization, mapping, perception, and navigation algorithms in agricultural robotics, addressing real-world environmental challenges.

Contribution

This work introduces a new multi-modal dataset with synchronized sensors and ground truth, specifically designed for agricultural robotics research and benchmarking.

Findings

State-of-the-art SLAM methods reveal limitations in agricultural environments.

Dataset captures challenging conditions like lighting variations and rough terrain.

Utilities are provided for easy adoption and benchmarking.

Abstract

We present a multi-modal dataset collected in a soybean crop field, comprising over two hours of recorded data from sensors such as stereo infrared camera, color camera, accelerometer, gyroscope, magnetometer, GNSS (Single Point Positioning, Real-Time Kinematic and Post-Processed Kinematic), and wheel odometry. This dataset captures key challenges inherent to robotics in agricultural environments, including variations in natural lighting, motion blur, rough terrain, and long, perceptually aliased sequences. By addressing these complexities, the dataset aims to support the development and benchmarking of advanced algorithms for localization, mapping, perception, and navigation in agricultural robotics. The platform and data collection system is designed to meet the key requirements for evaluating multi-modal SLAM systems, including hardware synchronization of sensors, 6-DOF ground truth and loops on long trajectories. We run multimodal state-of-the art SLAM methods on the dataset, showcasing the existing limitations in their application on agricultural settings. The dataset and utilities to work with it are released on https://cifasis.github.io/rosariov2/.

Tables

Table 1. Table 1: Publicly available datasets that target robot navigation and localization in agricultural environments (non-synthetic). A dash (-) means that information could not be obtained about that particular characteristic.

Dataset	Purpose	Environment	Crop Type	Cameras	IMU	GNSS	Odometry	Ground -Truth	Synchronization
FieldSAFE Kragh et al. (2017)	Obstacle detection	Outdoors; Over crop; Grass	Grass	Stereo RGB; 360 RGB; Thermal	Yes	IMU-Fused RTK	No	Position; Orientation	Hardware + Softwre
Sugar Beets Chebrolu et al. (2017)	Weed Detection; Localization; Mapping	Outdoors; Over crop; Crop rows	Sugar Beet	RGB; IR Depth; Multispectral	No	PPP; RTK	Yes	Position	Software
WeedMap Sa et al. (2018)	Weed Detection; Mapping	Outdoors; Over crop; Crop rows	Sugar Beet	Multispectral	Yes	Single-Point	No	Position	-
The Rosario Dataset Pire et al. (2019)	Localization; Mapping	Outdoors; Over crop; Crop rows	Soybean	Stereo RGB	Yes	RTK	Yes	Position	Software
Ladybird Cobbity Brassica Bender et al. (2020)	Localization; Mapping; Classification	Outdoors; Over crop; Crop rows	Cauliflower; Broccoli	Stereo RGB; Thermal; Multispectral	Yes	IMU-Fused RTK	No	Position; Orientation	-
RumexWeeds Güldenring et al. (2023)	Weed Detection	Outdoors; Over crop; Grass	Grass	RGB	Yes	Yes	Yes	Position	Software
ARD-VO Crocetti et al. (2023)	Localization; Mapping	Outdoors; Under crop; Trees	Localization; Mapping	Stereo RGB; Multispectral	Yes	RTK	Yes	Position; Orientation	Software
Bacchus Long-Term Polvara et al. (2023)	Localization; Mapping	Outdoors; Under crop; Trees	Grapevine	RGB; Depth	Yes	RTK	Yes	Position	Software
Terrasentia Under-Canopy Cuaran et al. (2024)	Localization; Mapping	Outdoors; Under crop; Crop rows	Corn; Soybean	Stereo RGB	Yes	Single-Point	Yes	Position	Software
MAgro Tanco et al. (2024)	Localization; Mapping	Outdoors; Under crop; Trees	Apple; Pear	Stereo RGB	Yes	RTK	Yes	Position	Software
BotanicGarden Liu et al. (2024)	Localization; Mapping; Segmentation	Outdoors; Under crop; Trees	Unspecified	Stereo RGB	Yes	No	Yes	Position; Orientation	Hardware
The GREENBOT Dataset Cañadas-Aránega et al. (2024)	Localization; Mapping	Indoors; Under crop; Crop rows	Tomato	Stereo RGB	Yes	No	No	-	-
Ours	Localization; Mapping	Outdoors; Over crop; Crop rows	Soybean	Stereo IR; RGB; Depth	Yes	Single-Point; RTK; PPK	Yes	Position; Orientation	Hardware + Software

Table 2. Table 2: List of sensors mounted on the platform and their characteristics.

Name	Sensor	Resolution / Range	Acquisition Rate
Intel Realsense D435i	Stereo IR Camera	1280px × 720px 87° × 58°	$15\mathrm{Hz}$
	Color Camera	1280px x 720px 69° × 42°	$15\mathrm{Hz}$
	6-DoF IMU	± $4g$ ± $1000\mathrm{deg}/s$	$200\mathrm{Hz}$
Emlid Reach M1	GNSS	± $2.5m$	$5\mathrm{Hz}$
	RTK-GNSS	± $0.04m$	$5\mathrm{Hz}$
	9-DoF IMU	± $8g$ ± $1000\mathrm{deg}/s$	$200\mathrm{Hz}$
Emlid Reach M2 (1)	GNSS	± $2.5m$	$5\mathrm{Hz}$
	RTK-GNSS	± $0.04m$	$5\mathrm{Hz}$
	9-DoF IMU	± $8g$ ± $1000\mathrm{deg}/s$	$200\mathrm{Hz}$
Emlid Reach M2 (2)	GNSS	± $2.5m$	$5\mathrm{Hz}$
	RTK-GNSS	± $0.04m$	$5\mathrm{Hz}$
	9-DoF IMU	± $8g$ ± $1000\mathrm{deg}/s$	$200\mathrm{Hz}$
E-Bike Wheel Odometer	Hall-Effect Odometry	± $7.5°$	$10\mathrm{Hz}$
OMRON E6CP-A	8-bit Absolute Encoder	± $1.4°$ $92°$	$10\mathrm{Hz}$

Table 3. Table 3: Characteristics of the six recorded sequences of the dataset.

Sequence	Sequence ID	Duration (\unit)	Distance (\unit)	Calibration Start (\unit)	Calibration End (\unit)
#1	2023-12-22-13-14-16	940	777	0	218
#2	2023-12-22-14-29-43	1011	904	-	-
#3	2023-12-22-16-31-08	943	950	-	-
#4	2023-12-26-13-39-43	2506	2254	0	190
#5	2023-12-26-15-10-15	796	703	-	-
#6	2023-12-26-15-48-38	1862	1744	-	-

Table 4. Table 4: Mean and standard deviation (in parentheses) of the absolute pose error (APE) of the position and orientation of the trajectories given by each method, when aligned to the ground-truth trajectory with Umeyama’s method. Values preceded by an asterisk (*) were the result of truncated trajectories as described in the text.

Method	Sequence
	#1	#2	#3	#4	#5	#6
ORB-SLAM3	$5.17m$ (2.44)	$4.27m$ (1.88)*	$7.06m$ (3.49)*	$7.91m$ (3.72)	$1m$ (0.54)*	$1.83m$ (0.88)*
	$25.05°$ (0.94)	$73.71°$ (0.36)*	$2.68°$ (0.91)*	$26.72°$ (1.94)	$11°$ (0.26)*	$1.64°$ (0.6)*
ORB-SLAM3+GNSS	$4.31m$ (1.97)	$1.83m$ (0.90)	$7.16m$ (1.22)	$7.12m$ (3.94)	$1.87m$ (0.7)	$1.86m$ (0.99)
	$40.67°$ (1.19)	$29.89°$ (0.55)	$34.96°$ (0.19)	$49.77°$ (1.62)	$9.01°$ (0.96)	$17.63°$ (0.73)
OpenVINS	$2.30m$ (1.73)	-	$4.47m$ (3.04)	$3.48m$ (2.53)	$2.37m$ (1.7)	$4.37m$ (3.11)
	$4.91°$ (0.83)	-	$18.08°$ (0.35)	$9.5°$ (0.66)	$12.43°$ (0.31)	$8.8°$ (0.34)

Table 5. Table 5: Mean and standard deviation (in parentheses) of the relative pose error (RPE) of the position and orientation of pairs of poses at a distance of 1   m 1\text{\,}\mathrm{m} for the trajectories given by each method. Values preceded by an asterisk (*) were the result of truncated trajectories as described in the text.

Method	Sequence
	#1	#2	#3	#4	#5	#6
ORB-SLAM3	$0.04m$ (0.03)	$0.09m$ (0.04)*	$0.06m$ (0.05)*	$0.04m$ (0.03)	$0.04m$ (0.02)*	$0.04m$ (0.03)*
	$0.20°$ (1.19)	$0.16°$ (0.16)*	$0.14°$ (0.12)*	$0.17°$ (1.32)	$0.12°$ (0.12)*	$0.15°$ (0.15)*
ORB-SLAM3+GNSS	$0.04m$ (0.03)	$0.08m$ (0.05)	$0.04m$ (0.06)	$0.03m$ (0.02)	$0.04m$ (0.04)	$0.04m$ (0.04)
	$0.19°$ (1.45)	$0.16°$ (1.2)	$0.16°$ (1.03)	$0.18°$ (1.14)	$0.18°$ (2.24)	$0.16°$ (0.15)
OpenVINS	$0.04m$ (0.03)	-	$0.07m$ (0.08)	$0.05m$ (0.04)	$0.05m$ (0.03)	$0.05m$ (0.04)
	$0.16°$ (0.15)	-	$0.16°$ (0.11)	$0.14°$ (0.12)	$0.13°$ (0.13)	$0.15°$ (0.11)

Table 6. Table 6: RealSense D435i camera intrinsic parameters obtained with calibration, given with a precision of 8 decimal points.

Camera	Intrinsics				Distortion
	$f_x$	$f_y$	$c_x$	$c_y$	$k_1$	$k_2$	$p_1$	$p_2$
color	$890.4202$	$895.5269$	$633.5761$	$375.3947$	$0.0511$	$-0.0881$	$-0.0011$	$-0.0004$
infra1	$645.4064$	$648.5756$	$648.7339$	$349.0376$	$0.0008$	$-0.0010$	$-0.0005$	$0.0004$
infra2	$645.9158$	$649.1492$	$647.7810$	$348.7846$	$0.0005$	$-0.0005$	$-0.0005$	$0$

Table 7. Table 7: Noise values obtained from the calibration for the different IMU units, given with a precision of 8 decimal points.

Module	Accelerometer		Gyroscope
	Noise Density	Random Walk	Noise Density	Random Walk
RealSense D435i	$0.00099438$	$0.00004750$	$0.00023249$	$0.00000182$
Emlid Reach M1	$0.00236037$	$0.00016363$	$0.00015210$	$0.00001414$
Emlid Reach M2 (1)	$0.00335015$	$0.00011784$	$0.00016841$	$0.00002311$
Emlid Reach M2 (2)	$0.00269792$	$0.00026127$	$0.00019469$	$0.00001151$

Table 8. Table 8: Rigid transformation between coordinate frames.

Frame ID	Child Frame ID	$tx\left[\text{unit}\right]$	$ty\left[\text{unit}\right]$	$tz\left[\text{unit}\right]$	$qx$	$qy$	$qz$	$qw$
base_link	sensor_box_link	$2.065$	$0$	$1.105$	$0$	$0$	$0$	$1$
sensor_box_link	reach_1	$0.04$	$0.4$	$0.263$	$0$	$0$	$0$	$1$
sensor_box_link	reach_2	$0.04$	$-0.4$	$0.263$	$0$	$0$	$0$	$1$
sensor_box_link	reach_3	$0.3825$	$0$	$0.239$	$0$	$0$	$0$	$1$
sensor_box_link	realsense_bottom_screw_frame	$0.312269$	$0$	$0.051969$	$0$	$0.1564345$	$0$	$0.9876883$
realsense_bottom_screw_frame	realsense_infra1_optical_frame	$-0.011$	$0.018$	$0.013$	$0.5$	$-0.5$	$0.5$	$-0.5$
realsense_infra1_optical_frame	realsense_infra2_optical_frame	$0.050240$	$0.000032$	$0.000181$	$0.0000482$	$-0.0006391$	$-0.0000144$	$0.99999999$
realsense_infra2_optical_frame	realsense_color_optical_frame	$-0.06363861$	$-0.00066263$	$-0.00010325$	$-0.00170204$	$-0.00387651$	$0.00520012$	$0.99997752$
realsense_infra1_optical_frame	realsense_imu_optical_frame	$0.004398$	$-0.019334$	$-0.027490$	$-0.002505$	$0.000293$	$-0.001948$	$0.999994$
realsense_imu_optical_frame	reach_1_imu	$-0.03328264$	$-0.09014729$	$-0.12951963$	$-0.41522836$	$0.42277546$	$0.57759602$	$0.56145272$
realsense_imu_optical_frame	reach_2_imu	$0.05413669$	$-0.05020996$	$-0.1210384$	$-0.4082114$	$-0.5625849$	$0.43126286$	$0.57521651$
realsense_imu_optical_frame	reach_3_imu	$-0.02761944$	$-0.04919555$	$-0.12547842$	$-0.10502215$	$-0.1182785$	$0.6993272$	$-0.69708107$

Table 9. Table 9: Recorded or post-processed topic names, their associated type, and a description of the data it contains. An asterisk implies that there are multiple topics similarly named with the same type and description.

Topic Name	Topic Type	Topic Description
/distance	wheel_odometry/Distances	Raw data from the wheel motor’s microcontroller
/odom	nav_msgs/Odometry	Wheel odometry, linear and angular velocity
/reach_*/fix	sensor_msgs/NavSatFix	Position data from the given Real-Time Kinematic GNSS (RTK)
/reach_*/vel	geometry_msgs/TwistStamped	Velocity data provided by the given GNSS module
/reach_*/imu	sensor_msgs/Imu	Inertial measurement unit data from the given GNSS module
/reach_*/imu/mag	sensor_msgs/MagneticField	Magnetometer data from the given GNSS module
/reach_*/imu/driver_t	sensor_msgs/TimeReference	Timestamps generated by the internal hardware driver corresponding to the IMU measurements
/reach_*/imu/system_t	sensor_msgs/TimeReference	Timestamps registered by the Emlid Reach module system clock corresponding to the IMU measurements
/reach_*/time_reference	sensor_msgs/TimeReference	Timestamps from NMEA sentence of GNSS solution
/realsense/infra1/camera_info	sensor_msgs/CameraInfo	IR camera parameters published by the RealSense ROS1 driver
/realsense/infra1/image_rect_raw	sensor_msgs/Image	IR camera image published by the RealSense ROS1 driver
/realsense/infra2/camera_info	sensor_msgs/CameraInfo	IR camera parameters published by the RealSense ROS1 driver
/realsense/infra2/image_rect_raw	sensor_msgs/Image	IR camera image published by the RealSense ROS1 driver
/realsense/color/camera_info	sensor_msgs/CameraInfo	Color camera parameters published by the RealSense ROS1 driver
/realsense/color/image_raw	sensor_msgs/Image	Color camera image published by the RealSense ROS1 driver
/realsense/depth/camera_info	sensor_msgs/CameraInfo	Depth camera parameters published by the RealSense ROS1 driver
/realsense/depth/image_rect_raw	sensor_msgs/Image	IR depth image published by the RealSense ROS1 driver
/realsense/accel/imu_info	realsense2_camera/IMUInfo	Accelerometer parameters published by the RealSense ROS1 driver
/realsense/gyro/imu_info	realsense2_camera/IMUInfo	Gyroscope parameters published by the RealSense ROS1 driver
/realsense/imu	sensor_msgs/Imu	Inertial measurement unit data published by the RealSense ROS1 driver
/tf	tf2_msgs/TFMessage	Dynamic transformations between coordinate frames
/tf_static	tf2_msgs/TFMessage	Static transformations between coordinate frames
/reach_*/gps/fix	sensor_msgs/NavSatFix	Single Point Positioning GNSS (SPP)
/reach_*/gps/vel	geometry_msgs/TwistStamped	Velocity data from SPP GNSS
/reach_*/ppk/fix	sensor_msgs/NavSatFix	Post-Processed Kinematic GNSS (PPK)
/reach_*/ppk/vel	geometry_msgs/TwistStamped	Velocity data from PPK GNSS

Table 10. Table 10: List of sensors mounted on the platform at the time of recording the supplementary dataset.

Name	Sensor	Resolution / Range	Acquisition Rate
Zed Camera	Stereo Color Camera	1280 × 720 and 672 x 376 $90°$ × $60°$	$15\mathrm{Hz}$
Emlid Reach M1	SPP	± $2.5m$	$5\mathrm{Hz}$
	RTK-GNSS	±$0.04m$	$5\mathrm{Hz}$
	6-DoF IMU	± $8$ g ± $1000\mathrm{deg}/s$	$200\mathrm{Hz}$
	Magnetometer	-	$40\mathrm{Hz}$
E-Bike Wheel Odometer	Hall-Effect Odometry	± $7.5°$	$10\mathrm{Hz}$
OMRON E6CP-A	8-bit Absolute Encoder	± $1.4°$ $92°$	$10\mathrm{Hz}$

Equations

$${\sigma }^2\left(\tau \right)=\frac{1}{2\left(n-1\right)}\sum _{i=1}^{N-1}{\left({\bar{x}}_{i+1}-{\bar{x}}_i\right)}^2,$$

Full text

We run multimodal state-of-the art SLAM methods on the dataset, showcasing the existing limitations in their application on agricultural settings. The dataset and utilities to work with it are released on https://cifasis.github.io/rosariov2/.

1 Introduction

World population will grow by a third by 2050, directly impacting global food demand (Fukase and Martin (2020)). In this context, the agricultural industry should increase its production to satisfy such demand. The use of autonomous robots to carry out agricultural tasks such as seeding, harvesting, weed remotion, pest control among others is an attractive solution since it can improve the production time in a sustainable manner reducing the environmental impact and pollution.

However, the implementation of autonomous robots in the agricultural field is a challenging work due the rough terrain, natural light variations, perceptual aliasing, areas with GNSS-denied signal, and the long-term robot operation required to carry out the desired applications. All these challenges cause robot localization methods to fail or perform poorly, making them impractical for real agricultural tasks, as evidenced in Cremona et al. (2022, 2023); Soncini et al. (2024); Cox et al. (2023); Bai et al. (2023); Ait et al. (2023).

In the last decade, there has been a growing trend towards the creation and public availability of agricultural datasets, enabling researchers to test new techniques and develop more sophisticated algorithms to address these challenges, such as Pire et al. (2019); Kragh et al. (2017); Tanco et al. (2024). However, none of them are properly curated for evaluating multi-modal SLAM algorithms. Effective multi-modal SLAM evaluation imposes specific requirements such as hardware-synchronized sensors, 6-DOF ground-truth, and trajectories with loops to effectively test loop closure algorithms.

In this work, we present a multi-modal dataset recorded by the weed removing robot developed at CIFASIS (CONICET-UNR) in a soybean agricultural field. The recorded data is captured by a RGB camera, stereo IR camera, a 6-Axis IMU, three 9-Axis IMU, three GNSS receivers and wheel encoders, and we provide a synchronization system for the data produced. The dataset consists of six sequences where the robots covers a total of $7.3\text{\,}\mathrm{km}$ in $2.2\text{\,}\mathrm{h}$. The recorded data captured natural light changes, image blurred, long trajectories, loop closures, rough terrain navigation. In order to illustrate the dataset challenges, we evaluate and analyze multi-modal state of the art SLAM systems on it. The dataset was conceived to facilitate the development of new multi-modal SLAM algorithms for agricultural environments. We also provide a 6-DoF ground-truth obtained by two GNSS and inertial measurements.

The main contributions of this works can be summarized in the following:

• •

Multi-sensor data captured by RGB camera, stereo IR camera, a 6-Axis IMU, three 9-Axis IMU, three GNSS receivers and wheel encoders.

• •

6-DoF pose ground-truth generated by two GNSS and inertial measurements.

• •

Trajectories with loops, which are trajectories where the robot revisits the same location after traveling along a certain path.

• •

A set of tools used to handle the data, provided as open-source.

• •

Sensor calibration sequences.

• •

Data is provided in both ROS rosbags and plain files.

The dataset and the development tools are release as open-source to facilitate the data usage and the development of new SLAM multi-modal systems.

We organize the rest of the article as follows: in Section 2 we present the most recent and relevant work related to datasets for agricultural robotics. In Section 3 we describe the physical setup of the robot used to record the present dataset as well as the software and the calibration methodology applied. In Section 4 we showcase the recorded data released in the dataset, along with information about the recording methodology and pre and post-processing of the data. In Section 5 we analyze results of running state-of-the-art algorithms for localization, mapping and 3D reconstruction on the data in an attempt to prove its worthiness and show what still remains to be addressed for enhancing these methods on agricultural environments. Finally, Section 6 summarizes the presented article and discusses future work.

2 Related Work

In the field of agriculture there are many types of crops, terrains and farming practices, each creating different visual imprints and navigation patterns. Our work continues what started in Pire et al. (2019) as it uses the same robot platform and navigates similar conditions (a soybean plantation in the form of rows), but we improve the quality and diversity of sensors, and address long-term trajectories with loops. Particularly, we have replaced the Stereolabs ZED camera, consisting of a stereo pair of rolling-shutter color cameras, for an Intel D435i RGB-D, comprising a stereo pair of infrared (IR) global-shutter cameras, a rolling-shutter color camera and an inertial measurement (IMU) unit. A set of double-band (L1/L2) GNSS modules was added as well, to enhance the positioning for ground-truth calculation and provide an estimate of platform orientation, which was missing in the previous dataset. Improvements were made to the sensor synchronization as well, which we elaborate on in coming sections.

In Table 1, we survey the most recent and relevant publicly available datasets focused on robot navigation and localization in agricultural environments. In order to put the proposed dataset in context of the state of the art, we analyzed each dataset according the type of environment, sensors captured, software/hardware synchronization and ground-truth type. Datasets like Sugar Beets (Chebrolu et al. (2017)), Ladybird Cobbity Brassica (Bender et al. (2020)) and RumexWeeds (Güldenring et al. (2023)) provide only downwards facing cameras, which makes them very convenient for weed detection and classification tasks, but very poor in terms of localization and mapping. Others like FieldSAFE (Kragh et al. (2017)) and The GREENBOT Dataset (Cañadas-Aránega et al. (2024)) contain very good multisensor data on the field, but provide no odometry information, which can be useful to compensate for IMU drift or continue the position tracking when other sensors fail to do so. Some notable datasets like Bacchus Long-Term (Polvara et al. (2023)), MAgro (Polvara et al. (2023)), BotanicGarden (Liu et al. (2024)), Terrasenta Under-Canopy (Cuaran et al. (2024)) and ARD-VO (Crocetti et al. (2023)) also contain high quality multimodal data in agricultural settings, but work in settings where the crops or plants raise higher than their sensors, which present a different set of problems than working over the crops as they form corridor-like structures around the robot. Another dataset to mention is WeedMap (Sa et al. (2018)), which captures all data from a multispectral camera mounted on a drone to generate composite images or orthomosaics and allows for crop analysis from this data. In our dataset we attempt to cover most of the weak points we mention, to provide a rich and heterogeneous set of data to further the research on these environments.

3 Platform

This section describes the physical setup of sensors and actuators in the robotic platform as well as details of the software used to capture the data and the calibration methodology applied.

3.1 The Robot

The robot consists of a mobile platform with four independently driven wheels as depicted in Figure 1. It has been designed with autonomy in agricultural settings in mind, and as such it’s powered by batteries charged by a series of solar panels in the top of the vehicle, and the distance and height of the wheels is consistent with the row distance and height of certain crops such as soy.

The aim of the robot as a whole is to automate the weeding of large crop fields. Particularly we aim to automate the robot’s traversal through a cultivated field whilst classifying the images and applying removal techniques for weeds or enriching the crops with fertilizer (things currently in testing). The robot motion is controlled by four independent brushless motors (one per wheel). For the front wheels direction, a stepper motor has been built with the appropriate reduction and encoder. For this dataset the motion of the platform was performed by a human operator on-site with a radio-frequency controller.

3.2 Data Collection System Overview

Figure 2 shows the sensor’s placement in the box mounted at the front of the robot. The exact positioning, orientation and frames of reference are available in the files of the dataset or the repository. The setup consists of the sensors listed in Table 2, which provide both exteroceptive and proprioceptive data on the platform’s environment and state.

To capture the data, the sensors are connected to a NVIDIA Jetson Orin Nano $8\text{\,}\mathrm{GB}$ Development Kit computer with the following connections:

• •

the Intel Realsense D435i is connected to a USB-A 3.0 port,

• •

the Reach GNSS modules (all three) are connected to a powered USB 3.0 hub, that in turn is connected to a USB-A 3.0 port,

• •

a single Emlid Reach GNSS module from the above (an M2 module) is connected also to a set of GPIO pins to provide a PPS (Pulse-per-second) timing capability.

A diagram of the connections can be seen in Figure 3.

We also make use of a Emlid Reach M1 GNSS module as a static base for our RTK solution, placing it close to the field we were working on. The base sends RTK corrections, transmitted to the robot’s GNSS modules through a long range Wi-Fi setup, to improve the accuracy of our GNSS positioning.

3.3 Software Environment

The data capture system is powered by ROS, where a set of ROS Nodes transform the raw sensor data into ROS Messages and then collects it into a ROS Bag.

We used the official package111https://github.com/IntelRealSense/realsense-ros provided by the manufacturer to convert the Intel Realsense D435i images and IMU measurements to ROS. For the Reach GNSS sensors, a slightly modified version of the Reach RS Driver node222https://github.com/enwaytech/reach_rs_ros_driver does the transformation from NMEA sentences into the standard ROS NavSatFix Message. There is no official software to obtain IMU data from the Reach modules, so we run RTIMULIB2333https://github.com/HongshiTan/RTIMULib2 on the modules to retrieve raw data (accelerometer, gyroscope and magnetometer) and transmit it to the host, which transforms that information into the corresponding ROS messages.

As for the odometry we record Hall effect sensor pulses for each of the four wheels and the steering system. The motors’ microcontroller transmits to the host the instant velocity of the wheels in $\mathrm{rpm}$, the angle sensed by the encoder and the movement’s direction (forward/backward). To measure the angle of rotation of the wheels, a variable of interest for vehicle control, an 8-bit absolute encoder (OMRON E6CP-A) was used, mounted on the same stepper motor. With that information the wheel odometry can be obtained by the Ackermann model Mueller (2019). The wheelbase of our robot is $1.65\text{\,}\mathrm{m}$, the steering angle $\in\left[-0.72,0.58\right]$\mathrm{rad}$$ and the wheel diameter $0.57\text{\,}\mathrm{m}$. The dataset includes the post-processed odometry, robot linear and angular velocities, and the raw data. The embedded system controls the wheel motors and their steering.

3.4 Synchronization

In isolated environments, such as agricultural fields, mobile network coverage is often unavailable. In such scenarios, it is required to time synchronize the integrated computing system with the GNSS modules in order to reference acquired sensor data with respect to a unique time source, as GNSS modules are able to converge with the satellite’s Coordinated Universal Time (UTC). The GNSS UTC time information (NMEA message) provided by one of the Emlid Reach GNSS M2 module is combined with its PPS (Pulse-per-Second) signal to set the clock of the Linux system 444Ubuntu 18.04.6 LTS (GNU/Linux 4.9.140-tegra aarch64) running in the NVIDIA Jetson module. The Linux OS uses the “Chrony” 555https://chrony-project.org/ Network Time Protocol (NTP) implementation for this purpose, which makes the system time to gradually converge with the GNSS time by slowing down or speeding up the clock as required taking into account the GNSS time, the PPS signal and transmission latency that might exist. Figure 3 depicts the described data synchronization scheme. This configuration allows precise clock synchronization that is forwarded to the entire software environment aforementioned. In this way, ROS nodes directly timestamp and record messages in UTC reference. It is worth mentioning that inertial information provided by IMUs inside the Emlid Reach modules are directly generated in UTC time reference. Furthermore, the Intel RealSense D435i sensor unit is time synchronized with the Jetson system clock making use of its “Global Time Domain” driver feature which adjusts the D435i sensor clock considering the USB transmission latency. This allows the D435i sensor to directly generate data frames timestamped in the UTC time reference. The wheel odometry sensors are the only ones whose data is only synchronized by software, this is, we timestamp the hall-effect readings when they arrive to the Jetson module and are subsequently converted into ROS messages.

This schema improves over the purely software-based synchronization present in the previous Rosario Dataset, given that it allows all sensor readings to easily be synchronized with one another and with the readings of the GNSS measurements. This also makes it straightforward to compare results obtained with a SLAM system against the ground-truth data provided by the GNSS measurements, without the need to manually adjust the timing by matching measurements of different time sources.

3.5 Calibration

3.5.1 IMU Intrinsic Calibration:

IMUs suffer from various stochastic errors, such as bias instability and random walk, which can degrade the accuracy of navigation and mapping applications. Intrinsic calibration of IMUs is required to determine internal sensor parameters like scale factors and axis misalignments, crucial for accurate motion tracking, especially in applications requiring high precision sensor performance. Allan variance is a statistical tool widely used to assess the stability of sensor measurements over time, helping to identify noise characteristics and systematic errors. The Allan variance is computed by segmenting the IMU data into $N$ clusters of a given averaging time $\tau$. Then, the average values of the signal over each segment is computed. The Allan Variance is then given by:

[TABLE]

where $\bar{x}_{i}$ are the averaged values over segments Woodman (2007). We focus on its square root, the Allan deviation $\sigma$. To identify different noise types, we plot $\sigma$ as a function of $\tau$ on a log-log scale, where distinct noise characteristics appear as specific slope patterns IEEE-Standard (1998). Figure 4 presents an example of this type of plot. We aim to extract the following parameters: gyroscope white noise (also known as gyroscope noise density or angular random walk), gyroscope random walk, accelerometer white noise (also known as accelerometer noise density or velocity random walk), and accelerometer random walk. White noise parameters are obtained by fitting a line to the region of the curve where the slope is $-\frac{1}{2}$ and reading its value at $\tau=1$. Conversely, gyroscope and accelerometer random walk parameters are determined by fitting a line in the region where the slope is $\frac{1}{2}$ and reading its value at $\tau=3$.

To accomplish this, we recorded data for $3\text{\,}\mathrm{h}$ from the three IMUs of the Emlid Reach modules as well as from the RealSense IMU. Next, we compute the Allan deviation for both the gyroscope and accelerometer using the Allan Variance ROS Toolbox (Buchanan (2021)) and extract the four key parameters from the resulting plots. Table 7 shows the results. These parameters are required to calibrate camera and IMU jointly using Kalibr.

3.5.2 Camera-IMU Calibration:

Once we obtain the aforementioned parameters from the Allan Variance method we can jointly calibrate the stereo camera and IMUs. For this step we use Kalibr (Rehder et al. (2016)). After collecting enough visual-inertial measurements to perform the calibration, we run Kalibr on this data and supply the IMU intrinsic parameters as input. As a result of the calibration, we obtained the camera intrinsic parameters and the extrinsic transformations between the stereo camera and the IMUs.

3.5.3 Odometry Calibration:

The Ackermann model parameters were manually determined for wheel diameter and wheelbase ($L$), and semi-automatically for steering angles ($\delta$). The procedure to obtain the steering angles consists of first determining the diameter of the ground-truth curves corresponding to the robot’s maximum steering angles (hard right and hard left) and then using a physics-based simulation of the robot, we perform a parameter optimization by iteratively adjusting the angle inputs to minimize the cost function defined as the difference between the simulated and ground-truth trajectories. This is depicted in Figure 5.

3.5.4 Extrinsic Calibration of Remaining Sensors:

Extrinsic measurements for the remaining sensors were taken manually. Figure 6 shows a 3D representation of the different sensors frames of reference. The robot’s base_link was set at the mid-point of the rear wheel axes, and the sensor_box_link was set at the contact point for the sensor suite box and the chassis, at the mid point of the rear bottom-most point of the box.

4 Data Collection

This section provides an overview of the dataset collected by the robot in the field, along with calibration data for the sensors. We analyze the different recorded sequences, presenting the ground-truth, statistics and environment conditions.

We recorded six separate sequences of the robot traversing a soybean plantation. The first three sequences (sequences #1 to #3) took place on the December 22nd, 2023, in a field referred to as Field#1. The remaining three sequences (sequences #4 to #6) were conducted on the December 26th, 2023, in a different field, approximately $830\text{\,}\mathrm{m}$ away from the first, which we will call Field#2. Both fields belong to the Faculty of Agronomy (National University of Rosario), located in Zavalla, Santa Fe, Argentina. On the first day’s field the rows of soybean plants were sowed with a spacing of $0.52\text{\,}\mathrm{m}$, whereas in the second day’s field the rows were spaced by $0.42\text{\,}\mathrm{m}$, both with none or minimum tilling. The plants were manually measured and had an average width of $0.30\text{\,}\mathrm{m}$ and an average height of $0.40\text{\,}\mathrm{m}$ on both dates. The plants were in a vegetative growth stage of V6 to V8 in the first day, and V3 or V4 in the second day, where a vegetative stage of V$i$ means that the plant has $i$ trifoliate leaves completely expanded. The stage of V8 precedes the plant flowering stage. Figure 7 shows close-up images of the soybean plants and the disposition of the crop rows.

Figure 8 shows the trajectories overlaid on a map, while Table 3 summarizes the key aspects of the six sequences. We recorded a total of $2.23\text{\,}\mathrm{h}$ of trajectory, with a total length of over $7.33\text{\,}\mathrm{km}$, more than four times the duration of the previous Rosario Dataset, and covering more than three times the distance.

At the beginning of sequences #1 and #4 (the first sequence for each distinct field) we performed a calibration routine. This involved maneuvering the robot forwards and backwards three times in a straight line and then making circular patterns (first turning fully clockwise and then turning fully counter-clockwise) while capturing images of two Kalibr AprilTag grids. Such initial calibration pattern guarantees to have data across all axes in the 2D plane allowing, for instance, wheel odometry and magnetometer sensor calibration and SLAM system initialization. The dataset includes metadata that marks the time when the calibration ends, allowing users to ignore this portion if they are not interested in the calibration data.

The recorded sequences were planned to contain overlapping trajectories, both in a given sequence and in between different sequences, to allow for testing of loop detection and loop closure systems in these environments. We also made sure to record on sunny days, which provides good natural illumination, an important factor for key-point detection and a good system localization. Other characteristics of the sequences are that they always move forwards, except when we perform the calibration routines, as a typical agriculture machine would do, and that the terrain is rough, which presents some naturally occurring shakiness in the camera feed and the sensor readings. Figure 9 shows sample images from the stereo IR camera and the color camera.

The robot’s movement was manually controlled by an operator with a radio-frequency controller as described in Section 3.

4.1 Ground-Truth

In addition to the GNSS-RTK positional solution, we compute GNSS-PPK (Post-Processed Kinematic) solutions for each Emlid Reach GNSS module to achieve higher precision. All raw GNSS data was saved for both the base station and the modules on board the rover. RINEX files stored by the Emlid Reach GNSS modules where post-process with the RTKLIB666https://github.com/rtklibexplorer/RTKLIB.git, a open-source library for processing GNSS data that provides tools for computing GNSS-PPK solutions. We performed this procedure for each Emlid Reach device onboard the robot using all available corrections from the base station module.

The 6-DoF inertial information provided by the Intel Realsense D435i IMU was later fused with the GNSS+PPK localization solutions using the MINS Lee et al. (2023) multisensor fusion framework. Using the two GNSS-PPK solutions from the Emlid Reach M2 modules, MINS is able to resolve a globally referenced orientation in a East-North-Up (ENU) global frame of the Intel Realsense D435i IMU coordinate frame system for every inertial reading. Measurements from the Emlid Reach M1 module were discarded from the computation due to its difficulty in acquiring a fix and its inherent limitations as a single-band receiver. During real-time operation, the M1 experienced poor SNR (signal-to-noise ratio) and struggled to maintain a fix for a few minutes, resulting in measurements that were unreliable for fusion with the data from the other sensors. Ground-truth localization information is finally generated applying the extrinsic transformation between the IMU frame and the robot body frame (base_link frame).

The estimated standard deviation of the PPK solutions, as reported in the RTKLIB output during post-processing, is approximately 5 mm in the horizontal plane and 1 cm in altitude. These values are derived from the covariance reported by the internal EKF of RTKLIB and provide a reasonable indication of internal confidence in the solution. Furthermore, both PPK solutions used as input to MINS maintained a Fix status $100\text{\,}\mathrm{\char 37\relax}$ of the time, ensuring maximum confidence in their positional accuracy. When comparing the MINS output with one of the original PPK trajectories, the mean positional difference varies across sequences, typically ranging between $4\text{\,}\mathrm{cm}$ and $8\text{\,}\mathrm{cm}$. Notably, MINS provides a reliable estimate of orientation, which is not available from PPK alone. We are releasing both the original PPK solutions and the MINS-derived trajectories as part of the dataset, this ensures that users can choose the most suitable reference for their needs and the possibility of performing their own sensor fusion and orientation estimation if desired.

5 Experimental Evaluation

To validate the proposed dataset, we evaluate and analyze state-of-the-art multi-modal SLAM systems. In particular, we assess the stereo-inertial configuration of ORB-SLAM3 (Campos et al. (2021)), the GNSS-stereo-inertial configuration of ORB-SLAM3+GNSS (Cremona et al. (2023)) and the stereo-inertial implementation of OpenVINS (Geneva et al. (2020)). For ORB-SLAM3 we set the same parameters as in Cremona et al. (2022), as they also evaluate the method on the previously released agricultural dataset “The Rosario Dataset”. Also for ORB-SLAM3+GNSS we use the default parameters provided in the implementation released by Cremona et al. (2023), which was also tested on the former dataset. In the case of OpenVINS we set similar parameters to the other methods: 1200 features extracted per image, with a state vector of 50 points and KLT tracking (as recommended by the authors). We use the RealSense D435i IR stereo camera and its IMU, and a single dual-band GNSS (an Emlid Reach M2) to run the systems. The results show that, initially, all systems estimate the robot trajectory properly, but as the robot navigates for a while, pose estimation drifts or even loses localization. Although each system has a loop detection module, we turn off the module to avoid false positive loops resulting from the perceptual aliasing nature of the environment, as reviewed in Soncini et al. (2024). To justify this decision we show an example trajectory obtained from running ORB-SLAM3 with loop closure enabled in Figure 10. In this trajectory the system closed 7 loops, with negligible translation errors and maximum rotation error of $170\text{\,}\mathrm{\SIUnitSymbolDegree}$ (when comparing to ground-truth pose differences between the selected keyframes), irreversibly corrupting the estimated trajectory.

Figure 11 shows the trajectories estimated by each system as the best alignment possible with the ground-truth trajectory via Umeyama alignment Umeyama (1991). OpenVINS did not run on sequence #2 as it failed to initialize the IMU for tracking. We omit the first few seconds for ORB-SLAM3 in sequences #2, #3, #5 and #6, as it takes some time for it to initialize correctly. In particular, sequence #2 takes the longest, at around $230\text{\,}\mathrm{s}$ to converge. ORB-SLAM3 also loses track in sequence #6 with about $300\text{\,}\mathrm{s}$ left to finish.

It can be noted in the trajectories how the different methods drift over time, with the one showing some of the best trajectories being ORB-SLAM3+GNSS, as expected given it’s the only one that fuses information from a GNSS sensor. The figures also show the start and end poses of the robot for each trajectory as a similarly colored circle and cross respectively, where some zoomed-in clippings for trajectories #1 and #4 are shown, as the path for the robot was planned in such a way that the robot started and ended in the exact same place by adding stakes with red markers on the ground where the four wheels should end up. We can see by the results that in these two trajectories none of the methods were able to perfectly start and end at the same time due to the accumulated drift. It’s our expectation that these issues could be mitigated by incorporating a loop closure system that works in agricultural fields, which is one of the motivations for releasing this dataset.

We evaluate the accuracy of the estimated trajectories of each method by calculating two standard metrics Sturm et al. (2012): the absolute pose error (APE) (also called absolute trajectory error or ATE) which compares the absolute distances between the estimated and ground-truth trajectories, and the relative pose error (RPE) which measures the local accuracy of the trajectory over a fixed interval (which in our case was set to $1\text{\,}\mathrm{m}$ displacement). Since our sensors are time-synchronized it’s easy to pair the poses of the estimated trajectories with our ground-truth, we still need to align both trajectories to a common frame of reference, which is done with Umeyama alignment Umeyama (1991).

Table 4 shows the APE results, where it can be seen that methods significantly drift on all sequences of the dataset, with particular issues when comparing the orientations of the trajectories. A small amount of drift is expected for ORB-SLAM3 and OpenVINS given that these methods don’t make use of any global information (e.g. GNSS, compass, or loop-closure systems), so as to make a fairer comparison we showcase in Table 5 the RPE metrics calculated over the SLAM trajectories and ground-truth, which only makes local comparisons over the estimated motion of the vehicle. These results shows that agricultural environments, despite its importance, are still challenging for state-of-the-art SLAM systems.

6 Summary and Future Work

We presented a calibrated, synchronized and tested dataset aimed at evaluating and progressing the scope of autonomy in agricultural environments. It is our belief that this dataset is needed due to the scarcity of agricultural data for autonomous operation on crop fields, and will help advance many areas of robotics, control, and computer vision. This is no empty claim, as we provide experimental evaluations showing that current localization and mapping methods are lackluster in these environments and need further improvement. Our results show that most of the issues pointed out in Cremona et al. (2022) are still present in the results produced by state-of-the-art SLAM systems and thus strengthens the importance of releasing the dataset and furthering the research on the subject matter.

In the future we plan to keep working on enhancing the information available on the dataset by curating pose and orientation ground-truths, enhancing the calibration results, annotating the visual cues and evaluating existing methods to further the work of autonomy on agricultural settings. We also have plans to continue recording data on the field in coming years, making an attempt to capture different conditions of lighting, weather and crop growth stages, incorporating new sensor configurations, such as lidars and radars, and enhancing the measurement tools, such as more precise imu and gnss modules.

{acks}

We specially thank Engr. Néstor Di Leo from the Land Management Chair of the Faculty of Agricultural Sciences of the National University of Rosario for giving us access to the agricultural field.

{funding}

This work was partially supported by Consejo Nacional de Investigaciones Científicas y Técnicas (Argentina) under grants PIBAA No.0042, AGENCIA I+D+i (PICT 2021‐570), and by Universidad Nacional de Rosario (PCCT‐UNR 80020220600072UR).

7 Appendix A: Calibration Parameters

For the RealSense D435i cameras we used a radial-tangential calibration model that calibrates intrinsic parameters and distortion coefficients for radial distortion and tangential distortion. The parameters are listed in Table 6 for all cameras.

For the RealSense D435i IMU and the Emlid Reach IMUs we calibrated the Allan Variance, from which the values listed on Table 7 were obtained.

8 Appendix B: Transformations

Table 8 lists the rigid transformations between the different coordinate frames involved in the system. Transformations are given by a combination of a translation vector $(tx,ty,tz)$ and a rotation quaternion $(qx,qy,qz,qw)$ (scalar-last).

The Git repository contains a convenient launch file that allows the tf module to automatically publish all these transformations for use with ROS.

9 Appendix C: Odometry

We get the raw data from the wheel motor’s microcontroller through serial communication. These messages are recorded and made available in the dataset. The serial message has the form: $((<status>:[<motornr>,<rpm>,<pulses>,<duty>,<current>]_{i:1\dots 4},<angle>,<backward>))$. Where $status$ indicates whether the robot is in manual or automatic mode (all the sequences in this dataset are manual mode), $motornr$ is an identifier of the wheel motor, $rpm$ is the linear velocity of the wheel and $pulses$ number of pulses detected by the sensors of the motors since the system is started.

10 Appendix D: Precision of PPS-Based Time Synchronization

“Chrony” 777https://chrony-project.org/, the service we use to perform PPS-based synchronization, provides precise offset measurements that allow us to evaluate synchronization performance. In this appendix, we analyze the offset variations over each sequence to assess the accuracy and stability of time synchronization. The term offset refers to the difference between the system current time and a reference time source measured by Chrony and considered to gradually converge the system clock with the reference. In this case, the source is a GNSS receiver that, after convergence, achieves the precision of an atomic clock from satellites.

Figure 12 illustrates the distribution of offset values for each sequence. Samples with values exceeding $1.5$ times the interquartile range (IQR) beyond the quartiles are shown separately, as is typically done in a box plot. It should be mentioned that these outliers, marked as red crosses, are predominantly observed in the earlier intervals, suggesting a short period of instability (less than $30\text{\,}\mathrm{s}$) before the system reaches synchronization.

Despite the presence of early outliers, the computed offsets for each sequence remain very small throughout the sequence, the mean being less than 0.32 milliseconds. This indicates that the synchronization process is performing well, considering that the fastest sensor operates at 200Hz producing measurements every 5 milliseconds. Offset mean values shown confirm that the system clock remains closely aligned with the reference GNSS satellite time effectively minimizes timing discrepancies, ensuring reliable and accurate timekeeping and stamping.

11 Appendix E: File Structure

We release the rosbags for the 6 recorded sequences, as well as some additional rosbags with postprocessed or independently recorded data, that can be easily merged or played synchronously as the timestamps line up.

• •

2023_12_22_13_14_16.compressed.bag: compressed rosbag for the first sequence of the first day (sequence #1),

• •

2023_12_22_14_29_43.compressed.bag: compressed rosbag for the second sequence of the first day (sequence #2),

• •

2023_12_22_16_31_08.compressed.bag: compressed rosbag for the third sequence of the first day (sequence #3),

• •

2023_12_26_13_39_43.compressed.bag: compressed rosbag for the first sequence of the second day (sequence #4),

• •

2023_12_26_15_10_15.compressed.bag: compressed rosbag for the second sequence of the second day (sequence #5),

• •

2023_12_26_15_48_38.compressed.bag: compressed rosbag for the third sequence of the second day (sequence #6),

• •

*_conventional_gnss.bag: rosbags with conventional GNSS data (no post-processing) for the corresponding sequence,

• •

*_ppk_gnss.bag: rosbags with post-processed (PPK) GNSS data for the corresponding sequence,

• •

*_pgt.bag: rosbags with post-processed ground-truth information as described in Section 4 for the corresponding sequence .

These rosbags contain collision-free names for the different topics, making running or merging multiple rosbags hassle free.

Scripts are provided in the linked GitHub repository that allow extracting any and all rosbags into a common file directory structure, of images and comma-separated-value files, and converting between common file representations where possible.

We also provide the rosbags recording for the calibration of the different sensors and the files resulting from running such calibrations:

• •

reach_imus_bias.bag: rosbag with a $3\text{\,}\mathrm{h}$ recording of the data produced by the IMU units of the Reach sensors when stationary, useful for calculating the biases,

• •

reach_imu_biases.tar.gz: compressed files resulting from running the Allan Variance ROS Compatible Tool888https://github.com/ori-drs/allan_variance_ros on the previously mentioned rosbag,

• •

realsense_imus_bias.bag: rosbag with a $3\text{\,}\mathrm{h}$ recording of the data produced by the IMU unit of the RealSense D435i sensor when stationary, useful for calculating its bias,

• •

reach_imu_biases.tar.gz: compressed files resulting from running the Allan Variance ROS Compatible Tool on the previously mentioned rosbag,

• •

allan_variance_config.tar.gz: compressed files used for configuration of the Allan Variance ROS Compatible Tool,

• •

aprilgrid_calibration.bag: rosbag with a calibration routine recorded with an aprilgrid board and making sure to excite all axes, useful for calibrating with Kalibr,

• •

kalibr_ir_color.tar.gz: compressed files resulting from running the Kalibr Visual-Inertial Calibration Toolbox999https://github.com/ethz-asl/kalibr on the previously mentioned rosbag. This calibration was performed using the IR stereo left camera and the color camera of the RealSense D435i only,

• •

kalibr_ir_stereo.tar.gz: compressed files resulting from running the Kalibr Visual-Inertial Calibration Toolbox on the previously mentioned rosbag, using only the IR stereo left and right cameras of the RealSense D435i,

• •

kalibr_ir_stereo_imu.tar.gz: compressed files resulting from running the Kalibr Visual-Inertial Calibration Toolbox on the previously mentioned rosbag. This calibration was performed using the IR stereo left and right cameras, along with the IMU of the RealSense D435i only,

• •

kalibr_ir_stereo_imu_imus.tar.gz: compressed files resulting from running the Kalibr Visual-Inertial Calibration Toolbox on the previously mentioned rosbag. This calibration was performed using the IR stereo left and right cameras of the RealSense D435i, its IMU, as well as the IMUs of the Reach sensors,

• •

kalibr_config.tar.gz: compressed files used for configuration of the Kalibr Visual-Inertial Calibration Toolbox,

• •

magnetic_compass.tar.gz: compressed files containing information about the magnetic compass, including magnetic declination (for different magnetic models) and calibrations generated from the trajectory sequences.

11.1 Rosbag Topics

In Table 9 we list the different topics contained in the rosbags, their message types and a short description.

12 Appendix F: Supplementary Dataset

As a preliminary step in recording this dataset, we collected a large amount of agricultural data in previous field trips. This data can be of great utility for evaluating SLAM algorithms, sensor fusion, path planning, navigation and control. For this reason we have decided to release the data captured in these field trips. In this appendix, we provide detailed information about this supplementary dataset, highlighting the differences between it and the core data presented in this article.

12.1 The Robot

The main difference with respect to The Rosario Dataset 2023 is the sensors mounted onboard the robot. Figure 13 shows the weed removing robot at the time of recording the supplementary dataset. As can be seen, the sensor layout differs here, as there is no sensor box. To capture the data, the sensors are connected to a NVIDIA Jetson TX2. The rest of the robotic platform is the same as described in Section 3.

12.2 Data Collection Systems Overview

The robot navigation and data recording stack was implemented on the ROS framework. For each sensor there is a ROS node capable of taking data from the sensor and converting it to a ROS message. If available, we use the official implementation of the node provided by the sensor manufacturer. All the messages coming from the sensors are stored in a single rosbag for each trajectory performed except for the images. Due to the size of the disk space occupied by the images, we chose to use the SVO format provided by the Zed camera and created by StereoLabs. This format compresses the images captured by the camera allowing them to be stored with significantly less disk space. Tools that allow conversion from SVO to rosbag are available.

12.3 Dataset

The tests were conducted on December 28th and 29th, 2021. Henceforth, we will refer to these working days as Day 1 and Day 2, respectively. Seven recording sessions were conducted between the two days, totalling seven data sequences. The sequences are numbered in chronological order, with sequence 1 being the first sequence recorded on Day 1 and sequence 7 the last sequence captured on Day 2. For all trajectories, data from the stereo cameras, IMU, magnetometer, GNSS-RTK, velocity from GNSS, SPP from GNSS, and wheel odometry are captured and recorded. Additionally, raw data provided by the GNSS receiver modules are stored. This data is processed offline using PPK to obtain a higher GNSS position accuracy than that achieved with RTK.

On Day 1 of the fieldwork, two distinct trajectories were performed in the soybean field, resulting in Sequences 1 and 2. At the start of Sequence 1, calibration routines were conducted, involving the robot rotating in circles in both directions, as described in Section 4 for the 2023 dataset. On Day 2 of fieldwork, five data sequences were collected (Sequences 3, 4, 5, 6, and 7). Similar to Sequence 1, Sequences 3 and 4 begin with calibration routines.

12.4 Synchronization

Each sensor measurement includes a timestamp. In this setup of the weed removing robot, the sensors were not hardware-synchronized. SLAM algorithms generally assume that input data is synchronized on a single clock, so this lack of synchronization poses a challenge when using our data with SLAM algorithms.

To implement software-based synchronization, we identify moments in the sequence where the robot remains stationary for at least $n$ seconds and then begins moving, detecting these timestamps with each sensor involved. We then select one sensor as the reference and apply an offset to each of the other sensors to align them with the reference sensor. Although the absolute timing might not be precise, our primary goal is to correct the relative timing between sensors. The IMU is chosen as the reference sensor because its high message frequency provides greater timing granularity.

12.5 Ground-Truth

Having a high-precision ground-truth is essential for evaluating SLAM systems, as it allows for comparing SLAM estimates against a reference trajectory. We planned to estimate PPK as outlined in Section 4.1. However, an issue with the base station in one recording session on Day 1 caused it to shut down and stop transmitting corrections.

With the aim of addressing this issue, we utilized a station from the RAMSAC network for receiving the corrections. RAMSAC is a network of GNSS reference stations across Argentina, managed by the Argentine National Geographic Institute (IGN), providing a precise and uniform geodetic reference framework nationwide. This network, with stations distributed across Argentina, supports real-time monitoring and correction of GNSS data and is suitable for both RTK and PPK applications. Each station in the network is equipped with high-precision GNSS receivers that record data continuously, ensuring a constant stream of information.

The nearest RAMSAC station to our fieldwork site is the UNRO station, located at National University of Rosario, approximately 25 kilometers from the soybean field. Although this distance is at the optimal range limit ($20\text{\,}\mathrm{km}$ for single-frequency receivers, according to RAMSAC website), the raw GNSS data from this station was used only to calculate PPK for the few minutes of recording when our local base station stopped transmitting. For all other data, PPK was processed using measurements from the local base station whenever available.

For orientation ground-truth, we rely on the magnetometer and IMU measurements. Specifically, we perform a 2D magnetometer calibration using data recorded during the calibration routines. We then correct the magnetic measurements and estimate the global orientation using a Madgwick filter Di Domenico and Pire (2023); Di Domenico (2024).