Unfinished Machinery
Unfinished Machinery – definition
In mobile robotics, unfinished machinery is a term used in machinery safety regulations for equipment that is not able to perform a specific application on its own and is intended to be incorporated into other machinery. The formal wording comes from the EU Machinery Directive 2006/42/EC, where unfinished machinery is defined as an assembly that is almost machinery, but cannot by itself perform a specific application. A drive system is given as a typical example. In practice, many robotic subsystems used on UGV platforms fit this category: motor-drive assemblies, sensor masts, power distribution units, compute modules, or partially integrated rover bases that still require safety, control, and application-level integration.
For UGV development, the term matters because a mobile robot platform is often built from components with different compliance status. A rover base, a LiDAR module, a Jetson carrier, or a custom actuator pack may each be supplied with different documentation. Some parts may be CE-marked as complete products. Others may be delivered as unfinished machinery with assembly instructions and a Declaration of Incorporation rather than a full EU Declaration of Conformity. This distinction affects system integration, risk assessment, documentation, and who is responsible for the final compliance of the robot.
In the context of Leo Rover and Raph Rover, unfinished machinery should be understood as a legal and engineering classification, not as a statement about software maturity. A rover used for ROS 2 experiments may be technically operational, but once it is modified with custom payloads, additional power systems, external compute, or autonomous functions, the final integrator is responsible for verifying that the complete UGV meets applicable safety and EMC requirements.
Why the term matters in UGV system integration
Mobile robots are usually assembled from subsystems produced by multiple vendors. The final machine behavior depends on mechanical integration, electrical protection, software architecture, and the operational environment. Because of that, compliance cannot be assumed from component datasheets alone.
For a UGV project, the unfinished machinery concept typically appears in these situations:
- a wheeled base is delivered without the final application-specific payload
- a motor controller and drivetrain are integrated by an engineering team into a custom chassis
- a rover receives a sensor mast, RTK receiver, emergency stop chain, and external computer after purchase
- a research platform is converted into a field robot for inspection or agriculture
In all of these cases, the final system may become a complete machine only after integration. At that stage, the integrator must evaluate hazards such as loss of braking, unexpected motion, cable strain, sharp edges, overheating, insufficient ingress protection, or software faults in autonomy functions.
Normative basis and documentation
The primary normative reference in Europe has been Directive 2006/42/EC, which distinguishes complete machinery from unfinished machinery and defines required documentation. Under the newer Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027, the same distinction is retained with updated requirements. For unfinished machinery, the supplier typically provides assembly instructions and a Declaration of Incorporation. The product must not be put into service until the final machinery into which it is incorporated has been declared compliant.
For robotic UGV projects, the documentation set often includes:
- mechanical drawings and mounting constraints
- electrical ratings – voltage, current, fuse sizing, connector pinout
- safe operating limits – payload, slope, ambient temperature, ingress rating
- software interface definitions – ROS 2 topics, services, emergency stop behavior
- assembly instructions and residual risk information
ROS itself is not a machinery safety standard. ROS 2 documentation at docs.ros.org and design.ros2.org defines communication, middleware, lifecycle, and interface mechanisms, but it does not certify a robot as safe. For example, a topic such as /cmd_vel of type geometry_msgs/msg/Twist is a control interface, not a safety function. Safety-relevant stopping functions should be implemented in hardware or in validated low-level controllers, not only in high-level ROS nodes.
How unfinished machinery appears in ROS 2-based robots
On a ROS 2 UGV, unfinished machinery usually maps to subsystems that expose interfaces but require a larger system to operate correctly. A motor controller may publish wheel odometry and accept velocity setpoints, yet still depend on external power isolation, watchdogs, and emergency stop wiring. A sensor pod may publish point clouds, but still need a mechanically stable mount and environmental sealing.
A typical integration stack on a research rover includes:
- base controller node for differential drive
- sensor drivers for LiDAR, IMU, camera, and GNSS
- state estimation with
robot_localization - navigation with Nav2 on ROS 2 Humble or newer
- custom safety supervision outside the navigation stack
The following example shows a simplified ROS 2 launch pattern for a drivetrain that is functional but still part of a larger integrated machine:
from launch import LaunchDescription
from launch_ros.actions import Node
def generate_launch_description():
return LaunchDescription([
Node(
package='robot_state_publisher',
executable='robot_state_publisher',
parameters=[{'robot_description': '<urdf content>'}]
),
Node(
package='controller_manager',
executable='spawner',
arguments=['diff_drive_controller']
),
Node(
package='twist_mux',
executable='twist_mux',
parameters=['config/twist_mux.yaml']
)
])This launch file enables motion control, but it does not by itself make the rover a complete compliant machine. The final system still needs power protection, stop functions, operating procedures, and risk reduction measures.
Key technical attributes to verify
When a subsystem is treated as unfinished machinery, the integrator should verify both specification-level and system-level parameters. This is especially important on outdoor UGVs where shock, dust, moisture, and communication latency are common.
| Attribute | Typical value or interface | Why it matters |
|---|---|---|
| Supply voltage | 12 V / 24 V DC | Mismatched power can damage drives or sensors |
| Control interface | CAN, UART, Ethernet, ROS 2 topic | Defines integration path and failure modes |
| Command rate | 10 Hz – 50 Hz for base velocity control | Affects drive smoothness and watchdog design |
| Odometry output | nav_msgs/msg/Odometry |
Needed for localization and Nav2 |
| Ingress protection | Example: vendor-specific, often IP54-class or similar on outdoor rover platforms | Limits field deployment conditions |
| Payload and mounting | Vendor-specific | Impacts stability and vibration transfer |
Command timeout is a practical example. If a differential-drive base accepts /cmd_vel at 20 Hz, a watchdog timeout of 200 ms to 500 ms is common in mobile robotics. The exact value depends on controller design and communication jitter. The integrator must validate that loss of network or process crash leads to a defined stop behavior.
Practical context for Leo Rover and Raph Rover
Leo Rover is a compact four-wheel differential-drive UGV with ROS support, typically based on an integrated Raspberry Pi compute unit. It is suitable for laboratory, education, and light field research, but it is not an autonomous vehicle out of the box. If a user adds Nav2, LiDAR, depth camera, GNSS, and custom mission logic, the resulting system becomes a new integrated machine from a compliance perspective.
Raph Rover is a larger platform intended for heavier payloads and more demanding terrain. In this case the unfinished machinery concept becomes even more important, because payload mass, power distribution, braking distance, and emergency stop architecture have larger consequences. A heavy sensor mast, an RTK receiver, or an edge GPU enclosure can shift the center of gravity and change rollover risk.
For both platforms, examples of subsystems that may be treated as unfinished machinery in a project include:
- custom battery and DC-DC conversion assemblies
- sensor brackets and pan-tilt payload carriers
- third-party drive modules or external motor controllers
- application-specific tools for inspection or field measurement
Common misconceptions
The term is often misunderstood. It does not mean that the robot is defective, experimental, or badly engineered. It means that the delivered assembly is not yet the final machine for legal and safety purposes.
It is also different from software completeness. A ROS 2 package can be stable and production-ready while the hardware assembly it controls is still unfinished machinery. Conversely, a CE-marked complete product can still have immature application software.