Estimating sensor data throughput and memory

1. Engineering problem

Before choosing a computer, a network link or a storage device you need to know how many bytes per second the sensors produce and how much memory the pipeline holds. A 720p colour camera alone produces far more than an IMU; a wrong guess shows up later as dropped messages and latency.

2. When is this needed?

• Selecting an onboard computer (Module 5) or a network switch.
• Adding a second camera or a higher-resolution LiDAR mode.
• Debugging dropped messages on a link or on disk.

3. Selection and design decisions

Link and storage choices

Plan on at most about 70 % of a link’s nominal data rate (a rule of thumb, not a standard): protocol overhead and other traffic take the rest. USB 3.x signalling at 5 Gbit/s leaves 80 % for data after 8b/10b coding; Gigabit Ethernet is 1 Gbit/s nominal.

4. Advantages and disadvantages

• Raw images: simplest and lowest CPU, highest bandwidth. Compressed images: lower bandwidth, more CPU and variable latency, and lossy artefacts for perception.
• One computer: no network copies, but everything shares memory bandwidth. Several computers: more headroom, but the network link now carries the sensor data.
• Intra-process or shared-memory transport: avoids copies on one machine; needs components in one process or a supporting middleware setup.

5. Requirements and constraints

• Memory bandwidth and PCIe/USB controller sharing, not only link speed, can limit a pipeline.
• Every subscriber in another process receives another copy through the transport.
• Disk write speed limits recording: 90 MB/s sustained is demanding for some storage.

6. Architecture

camera ──USB3──▶ computer ─┐
lidar  ──GbE ──▶ switch  ──┼──▶ perception ─▶ SLAM ─▶ navigation
imu    ──UART/USB─────────┘                    │
                                               └─▶ recorder (disk)

7. Implementation

Worked example (executed by the site’s tests)

MB = 1e6
cam_frame = 1280 * 720 * 3                    # rgb8: 3 bytes per pixel
cam_rate = cam_frame * 30                     # 30 Hz
lidar_rate = 300_000 * 22                     # 300k points/s * 22 bytes per point
imu_rate = 200 * 320                          # 200 Hz * ~320 bytes
total = cam_rate + lidar_rate + imu_rate
print(cam_frame, cam_rate / MB, lidar_rate / MB)
print(total / MB, total * 8 / 1e6)            # MB/s and Mbit/s
print(2 * total / MB)                         # 2 s ring buffer, MB
gbe_usable = 1e9 * 0.7 / 8                    # 70 % of 1 Gbit/s, bytes/s
print(round(gbe_usable / MB, 1), total <= gbe_usable)

Printed:

2764800 82.944 6.6
89.608 716.864
179.216
87.5 False

So one 1280×720 rgb8 camera at 30 Hz (2,764,800 bytes per frame) is 82.9 MB/s, a 300 k points/s LiDAR at 22 bytes per point adds 6.6 MB/s, and the total is 89.6 MB/s ≈ 717 Mbit/s: more than 70 % of Gigabit Ethernet (87.5 MB/s), so the camera must stay on USB 3.x, be compressed, or be downscaled. A 2 s ring buffer of all three needs about 179 MB.

Measure the real system

Not executed by the site’s automated tests (they need a ROS 2 installation).

ros2 topic hz /points              # message rate
ros2 topic bw /points              # bandwidth the subscriber sees
ros2 topic echo /points --once --field point_step    # bytes per point (PointCloud2)
htop                               # per-core CPU use
top                                # processes sorted by CPU or memory
free -h                            # RAM and swap
nvidia-smi                         # NVIDIA GPU use and memory (where the NVIDIA driver provides it)
tegrastats                         # NVIDIA Jetson only: CPU, GPU, memory, temperature and power

Use tegrastats only on Jetson platforms; nvidia-smi is for NVIDIA GPUs with the driver installed and its output on Jetson can differ. Try your own numbers in the CPU/GPU Resource Estimator.

8. Real examples

1. Add a second identical camera: 166 MB/s raw. USB 3.x (5 Gbit/s signalling, 80 % usable data, 70 % plan: 350 MB/s) still fits; Gigabit Ethernet does not.
2. Switch the LiDAR to a mode with 4× the points: 26 MB/s. Fine on Gigabit Ethernet, but the point-cloud pipeline now processes 4× the points: measure its stage times.
3. Record everything: 90 MB/s to disk is 5.4 GB per minute. A 10-minute test is 54 GB.

9. Failure scenarios

• Planning for the sum of nominal link speeds and ignoring that one link carries several streams.
• Forgetting subscriber copies: three nodes receiving the image triple the transport traffic.
• Assuming a compressed stream’s average rate is its peak rate.
• Recording more than the disk can write: the bag silently loses messages.

10. Troubleshooting

1. Compute the expected rate from the formulas.
2. Measure with ros2 topic bw; a large difference means a different format, mode or compression than assumed.
3. Check the link: Ethernet counters or USB hub topology; reduce rate or resolution to see whether drops disappear.
4. Check CPU and memory with htop and free -h while the system runs at full load.
5. If drops persist, investigate QoS and executor settings (Module 17).

11. Validation

• Measured bandwidth is within 10 % of the calculated figure for each stream.
• No dropped messages over a 10-minute full-load run (compare publisher and subscriber counts).
• Memory use stays flat over the run, with headroom below 70 % of RAM.
• The arithmetic example prints the values above (executed by the site tests).

12. Engineering checklist

• Rate computed for every sensor in its actual mode
• Subscriber copies counted
• Link plan below 70 % of nominal
• Buffer and map memory estimated
• Disk write rate for recording checked
• Measured with ros2 topic bw against the estimate
• Headroom documented

13. Further references

• sensor_msgs message definitions (Image, PointCloud2, Imu): ros2/common_interfaces, jazzy branch.
• USB 3.x signalling rate (5 Gbit/s) and 8b/10b coding, and Ethernet nominal rates: published standards; the 70 % planning figure is a heuristic of this guide.

Related on FixTheRobot

• Real-Time Performance and Resource Constraints SLAM · Lesson