Capturing data
TL;DR
- Record every message from every sensor (such as with
rosbag record -a) - Move the robot in a figure-8 pattern very close to tall structure for 30-60 seconds
ROS Data Format (preferred)
Storage: Save data in ROS1 .bag files and/or ROS2 .mcap or .db3 files.
Message types: Use standard ROS message types whenever possible. See Wheel Encoders message type recommendation.
Rosbag requirements: Split bag files are acceptable. If multiple ROS bags are submitted, they should not contain duplicates of the same message (this will happen if multiple instances of rosbag record are subscribed to the same topic).
Non-ROS Data Format
Storage: Save all the data in a single .tar file.
Camera data: Store images in .jpg format in a directory named after the sensor, where the image filename is the exposure timestamp. For example: camera_front/1234567890.jpg.
Lidar data: Store lidar data (raw UDP packets collected with tcpdump) in a .pcap file named after the sensor. For example: lidar_front.pcap. Include relevant metadata, like metadata.json, that has information about manufacturer intrinsic calibration of lidar beam angles.
IMU data: Store IMU data in a .csv file named after the sensor. For example: main_imu.csv. Include the following header and data in these columns: send_time_s, time_s, ax_mpss, ay_mpss, az_mpss, gx_rps, gy_rps, gz_rps, where send_time_s is the recording time, and time_s is the signal capture time.
Encoder data: Store wheel encoder or wheel speed data in a .csv file named after the sensor. For example: wheel_speeds.csv. Include the following header and data in these columns: send_time_s, time_s, wheel_left_mps, wheel_right_mps, where send_time_s is the recording time, and time_s is the signal capture time.
Other data: Contact us for more details.
Cameras
Image rate: Typically >5 Hz unless your robot moves very slowly.
Image format: JPEG or PNG compressed images (ROS CompressedImage message) are preferred. Do not rectify or otherwise process images.
Image resolution: If possible, provide images at the sensor's full resolution. Minimum resolution is 600x400 pixels.
Depth Cameras
Dot projection off: Turn off dot projection for depth camera images.
Range awareness: Depth cameras produce the best data within a short range, so it's very important that they observe tall static structure within 1-2 meters during the data collection.
Lidars
Unmodified data: Store raw unmodified data as reported by the sensor. Do not transform, rotate, or apply motion compensation to lidar data.
Native output: If your lidar produces packets, record and send those if possible. Also include any topics or files like metadata.json that contain lidar configuration or manufacturer beam-angle intrinsics information.
Per-point timestamps: Record individual timestamps for each lidar point. All major lidar manufacturers support per-point timestamping. The easiest way to get per-point timestamps is to record lidar packets. To store per-point timestamps with individual points, you may need to adjust the lidar driver configuration.
Wheel Encoders
Use a ROS JointState message with position or velocity populated, plus header timestamps, for each encoder.
Timestamps
Calibration requires a timestamp associated with every sensor measurement: - All camera images individually timestamped, preferably at the mid-point of exposure - All depth images individually timestamped, preferably upon source image exposure - All lidar points individually timestamped, which may require storing the raw lidar packets - All radar points individually timestamped, which may require storing the raw radar packets - All IMU samples timestamped with time-of-measurement - All wheel encoder ticks or speeds timestamped with time-of-measurement - All GPS samples with time-of-measurement
Store time-of-measurement whenever possible.
Timestamps should be generated using clocks that are either hardware synchronized or are "somewhat synchronized" (where clocks report the same time to within ~200ms). Either makes time offset calibration possible. If sensors record timestamps from different time domains (for example, if one clock is unix time and another is time-since-startup), time-offset calibration will not be reported.
TF Tree
Optional: If you have a roughly-correct TF tree available, please share it! The TF tree will be used to aid a human who will carefully review your first data upload. It's helpful to have a starting point for understanding the sensor layout. During subsequent calibrations any TF data is ignored.
Calibration Motion
Capture data as follows:
- Start recording with the system (robot, vehicle, sensor kit, etc) stationary, positioned very close to tall static structure that fills the field of view of some sensors
- Ideally start within 1m of the static structure
- The best static structure is large and textured, including:
- Brick walls, door frames, buildings with windows
- Large trees and rocks
- Furniture
- Pallets or shelves with boxes
- Stationary vehicles or robots
- Move the system in two figure-8 patterns
- Stay as close as you can to the tall static structure the whole time!
- If the system is too large to move in a figure-8 pattern, or is constrained by the environment, perform two three-point turns
- Stop the system and then end the recording
Tips:
- Move the system manually, or via teleoperation, or autonomously
- Ensure operators don't fully obscure any sensor's view
- Move quickly enough to complete all motions within about 60 seconds
- A walking or jogging pace is usually appropriate for smaller systems (like a sensor kit or small robot), while a parking-lot-appropriate driving speed works well for larger systems (like a vehicle)
This procedure can be modified to suit your needs. Contact us to discuss complicated scenarios.
Recording Length
30-60 seconds: Minimize the recording length as much as possible. Start the recording immediately before starting the movement. Stop the recording as soon as the movement has completed. Try to complete the movement in less than 60 seconds.
Quality Check
Before submitting data:
- Check that each sensor is represented by a topic
- Check that each topic contains messages at the expected rate
If you are using ROS, rosbag info is useful for quality checks.