D · Interactive tool · Module 05
CPU/GPU Resource Estimator
Sensor throughput, memory and link fit are arithmetic. CPU and GPU load come from per-frame times that you measure on the target.
Preliminary engineering guidance. This tool does not predict how fast your CPU or GPU runs any algorithm. Throughput and memory are exact arithmetic on the numbers you enter; compute utilisation only multiplies the per-frame times you measured by the frame rate.
Camera
Only if the camera streams compressed images.
LiDAR (0 points/s to omit)
From the datasheet; use the mode you will run.
PointCloud2 point_step: 12 for XYZ float32, 16 with intensity; more with ring/time fields.
IMU (0 to omit)
Pipeline
Each is another copy over the transport.
Map (volume 0 to omit)
Depends on your map data structure.
Stages: measured time per frame
Measure on the target (for example with ros2 topic hz and node timing, or the stage’s own timer), then enter ms per frame on one core, or on the GPU.
| Stage | ms per frame | Frames/s | Runs on | Remove |
|---|
Result
Assumptions and limitations
- Camera bytes = width × height × bytes per pixel (raw ROS encoding) ÷ compression ratio × frame rate. Compressed streams vary frame to frame; the ratio is an input, not a prediction.
- LiDAR bytes = points per second × bytes per point. Use the point rate of the mode you will actually run.
- IMU message size is approximated as 320 bytes (
sensor_msgs/Imufixed fields are 296 bytes plus the header). - Transport = sensor total × (1 + extra subscribers): a simplification that assumes each extra subscriber in another process receives another copy. Shared memory or intra-process transport reduces this.
- Link capacities are nominal (USB 3.x signalling 5 Gbit/s with 8b/10b leaves 80 % for data; Ethernet and USB 2.0 nominal). The tool plans on 70 % of nominal as a rule of thumb for protocol overhead and other traffic. It is a heuristic, not a standard.
- Memory = buffering × data rate + map voxels × bytes per voxel + (nothing else). Add your own figure for the OS, ROS 2 and application processes; real use is usually higher.
- Utilisation = ms per frame × frames per second ÷ 1000, as a fraction of one core (or the GPU). It ignores memory-bandwidth contention, thermal throttling, scheduling jitter and frequency scaling, and assumes the time you measured will not change under load, which is often optimistic.
References
- sensor_msgs/PointCloud2 and Image message definitions: ros2/common_interfaces, jazzy branch (repository).