BOM (Bill of Materials)

BOM (Bill of Materials) – definition

A Bill of Materials (BOM) is a structured record of all items required to build, assemble, configure, or service a product. In mobile robotics, a BOM identifies the mechanical, electrical, electronic, and software-related components of an unmanned ground vehicle (UGV). It is the reference used to reproduce a specific rover configuration, verify compatibility, manage revisions, and procure replacement parts.

For a ROS 2-based UGV, a BOM is not limited to chassis parts. It normally includes the compute unit, motor controllers, battery system, sensors, cables, connectors, mounting hardware, storage media, and the exact firmware or operating-system image required by the integration. A complete BOM makes a robot configuration traceable from a CAD assembly and wiring harness to ROS 2 packages and deployed software versions.

The term is commonly divided into an engineering BOM (EBOM), based on the product design, and a manufacturing BOM (MBOM), based on the assembly process. A service BOM may additionally identify replaceable field components. These structures are used in product lifecycle management and configuration-control workflows.

BOM structure for a mobile robot

A UGV BOM should represent both the physical assembly hierarchy and the interfaces between parts. A flat purchase list is useful for procurement, but it does not adequately describe how components are installed or connected.

Field	Purpose in a UGV BOM	Example
Item number	Unique internal identifier for traceability	ELEC-IMU-001
Reference designator	Links an electronic item to a schematic or harness drawing	U3, J12, SENS-IMU
Manufacturer part number	Identifies the exact purchasable component	Vendor-specific part number
Quantity	Required count per rover assembly	1 IMU, 4 wheels, 2 motor drivers
Revision	Identifies an approved hardware or document version	Rev C
Approved substitute	Defines permitted replacement parts and constraints	Equivalent connector with matching keying
Interface specification	Documents electrical and data compatibility	USB 3, UART, CAN, Ethernet, I²C

The assembly quantity can be expressed as Q_assembly = Q_parent × Q_child. For example, if one rover contains four wheel modules and each module requires one encoder cable, the top-level BOM requires four encoder cables. This calculation becomes important when an assembly has multiple nested subassemblies.

Hardware BOM versus software BOM in ROS 2

A hardware BOM records physical components. A software BOM (SBOM) records software components, versions, dependencies, licenses, and provenance. Both are relevant to ROS 2 robots because the deployed behaviour depends on the interaction between hardware drivers, firmware, middleware configuration, and ROS packages.

ROS 2 package metadata is stored in package.xml. Package format 3 is specified by REP 149. It declares dependencies such as build, execution, and test dependencies, but it is not a complete SBOM because it does not necessarily identify the resolved version of every operating-system package, container image layer, or firmware binary.

A practical UGV release should therefore keep the following records together:

Hardware BOM with manufacturer part numbers, revisions, and quantities.
Firmware manifest for motor controllers, LiDARs, GNSS receivers, and embedded sensors.
ROS 2 workspace lockfile or version-controlled dependency manifest.
Container image digest when Docker is used for deployment.
Calibration files for cameras, IMUs, wheel parameters, and sensor transforms.

For ROS environments, dependency declarations should follow the ROS package and dependency conventions documented in REP 149 and REP 111. REP 111 specifies multiple package manager support for rosdep, the tool that maps ROS dependency keys to operating-system packages.

BOM use on Leo Rover and Raph Rover

On Leo Rover, the BOM should distinguish between the standard platform configuration and optional autonomy payloads. Leo Rover uses a Raspberry Pi as its default built-in compute unit. It can be integrated with ROS 2; the supported ROS 2 distribution depends on the installed system image and Leo Rover software release. A navigation-capable configuration may add a LiDAR, IMU, depth camera, GNSS/RTK receiver, external compute unit, or networking equipment, depending on the operating environment.

Leo Rover has a four-wheel differential-drive architecture. The BOM should therefore identify components affecting the drivetrain model, including wheel assemblies, motors, encoders, motor drivers, battery-related components, and cables. A change in wheel diameter, gear ratio, encoder resolution, or motor-controller firmware can require updated odometry parameters and validation of the ROS 2 navigation stack.

Raph Rover is intended for configurations requiring higher payload capacity. Its BOM should explicitly separate base-platform items from mission payload items. This prevents a sensor mast, inspection camera, agricultural instrument, or ruggedized compute enclosure from being treated as an undocumented platform modification.

Example BOM entry for a ROS 2 sensor payload

The following YAML fragment shows a concise BOM representation for an optional LiDAR integration. It should be stored with the relevant CAD, wiring diagram, driver version, and ROS 2 launch configuration.

assembly: leo_rover_navigation_payload
revision: A
items:
  - item_id: SENS-LIDAR-001
    description: 2D LiDAR sensor
    quantity: 1
    interface: USB or UART
    ros_package: sensor_driver_package
    ros_message: sensor_msgs/msg/LaserScan
    mounting_document: lidar_mount_rev_a.pdf
    verification: scan_topic_and_tf_check

  - item_id: CAB-USB-001
    description: USB data cable
    quantity: 1
    parent_item: SENS-LIDAR-001
    interface: USB
    verification: mechanical_strain_relief_check

The listed ROS message type is important because it links the physical part to the software interface. A two-dimensional laser scanner commonly publishes sensor_msgs/msg/LaserScan, while a three-dimensional LiDAR integration may publish sensor_msgs/msg/PointCloud2. The exact topic names, frame IDs, update rate, and driver parameters belong in the launch and configuration repository, not only in the purchasing spreadsheet.

Configuration control and verification

A BOM is useful only when it is versioned and verified against the assembled rover. Each release should have a defined baseline that links the BOM revision to mechanical drawings, electrical schematics, firmware versions, ROS 2 distribution, and test results.

For a mobile robot, verification typically includes the following checks:

Confirm that installed manufacturer part numbers match the approved BOM.
Check connector pinout, supply voltage, current rating, and cable routing against the wiring documentation.
Verify that the sensor driver publishes the expected ROS 2 message type and frame identifier.
Validate transforms in the tf2 tree against the physical sensor mounting position.
Record substitutions, unavailable parts, and firmware changes as controlled deviations.

Normative references and technical sources

The following primary references define the ROS-specific package and dependency concepts relevant to a robotics BOM and SBOM workflow.

BOM (Bill of Materials)