Concept to Market

Concept to Market – definition

Concept to Market is the engineering path that turns an initial robotics idea into a deployable product, research platform, or field-ready subsystem. In mobile robotics, this path starts with a technical concept such as an autonomous UGV for inspection, mapping, or education. It ends when the system is manufacturable, testable, documented, and usable by an end user or research team. The term is not a ROS standard, IEEE protocol, or formal REP. It is a product development framework used in engineering practice.

In the context of UGV platforms, Concept to Market covers requirement capture, mechanical and electrical architecture, software stack selection, prototype integration, verification, safety review, and preparation for repeatable deployment. For Fictionlab platforms such as Leo Rover and Raph Rover, this usually means translating a mission profile into a working mobile robot configuration. That configuration may include a compute unit, LiDAR, IMU, depth camera, GNSS receiver, ROS 2 nodes, URDF model, navigation stack, and test procedures.

For an engineer, the important point is scope. Concept to Market is not only industrial design or commercialization. It includes system definition, interface contracts, ROS topic architecture, power budget, compute budget, environmental limits, and validation criteria. In mobile robotics, weak definition at the concept stage usually leads to integration problems later. Typical failures include insufficient payload margin, unstable odometry, poor sensor placement, thermal throttling on embedded compute, and navigation stacks that do not match terrain conditions.

How Concept to Market is applied in mobile robotics

In a UGV project, Concept to Market is usually executed as a staged process. Each stage reduces uncertainty and converts assumptions into measurable system properties. On ROS-based platforms, this process should produce concrete interfaces early, because software and hardware co-evolve.

A typical sequence looks like this:

Concept definition – mission, terrain, autonomy level, payload, endurance, ingress protection, communication range.
System architecture – drive type, compute platform, sensor suite, power system, enclosure, network topology.
ROS 2 interface design – topics, frames, message types, QoS policies, diagnostics, logging.
Prototype integration – bring-up of drivers, calibration, URDF, teleoperation, odometry, perception.
Verification – repeatability tests, runtime stability, localization drift, obstacle detection coverage, thermal and battery tests.
Deployment readiness – installation scripts, containers, update path, CI/CD, service documentation, spare parts and revision tracking.

For Leo Rover, the process often starts with an educational or research concept and a moderate payload. Since Leo Rover typically uses an onboard Raspberry Pi class compute path and supports ROS 2, the concept must match realistic compute limits. If the use case needs dense 3D perception, multiple camera streams, and high-rate SLAM, an external companion computer may be required. For Raph Rover, the same process often shifts toward larger payloads, wider sensor baselines, more battery capacity, and heavier compute.

Key engineering outputs

A useful Concept to Market process creates engineering artifacts, not only presentations. In robotics, these outputs define what can be integrated and tested. Without them, prototype work becomes ad hoc.

Output	Purpose	Example in a UGV project
Requirements specification	Defines measurable targets	Max speed, payload, runtime, IP rating, localization accuracy
Interface definition	Stabilizes hardware-software integration	ROS 2 topics, CAN/UART interfaces, frame tree, diagnostics
System model	Supports simulation and planning	URDF/Xacro, wheelbase, sensor extrinsics, mass properties
Verification plan	Defines pass/fail criteria	Odometry drift test, Nav2 waypoint repeatability, packet loss under Wi-Fi load
Deployment package	Makes rollout repeatable	Docker image, launch files, parameter YAML, versioned firmware

These outputs align well with ROS conventions. For example, frame definitions should follow REP 103 for standard units and conventions, and REP 105 for mobile platform coordinate frames such as base_link, odom, and map. If GNSS is integrated, the transform chain must be explicitly defined. If differential drive is used, odometry assumptions must match the kinematic model.

ROS 2 implications

On ROS 2 systems, Concept to Market has a practical meaning: design choices must map cleanly to nodes, messages, and deployment tooling. A concept that cannot be represented in a stable ROS graph is usually still underdefined. This is especially visible on mobile robots where perception, control, and localization interact at runtime.

Typical ROS 2 elements specified during the process include:

sensor_msgs/msg/LaserScan or sensor_msgs/msg/PointCloud2 for LiDAR input
sensor_msgs/msg/Imu for inertial data
nav_msgs/msg/Odometry for wheel or fused odometry
geometry_msgs/msg/Twist on /cmd_vel for motion control
tf2 transforms following REP 105
Nav2 configuration for the selected ROS 2 distribution

Even at concept stage, it is useful to define expected rates and data quality. Example values in a small UGV project may include IMU at 100-200 Hz, wheel odometry at 30-50 Hz, 2D LiDAR at 5-15 Hz, and depth camera at 15-30 fps. Actual values depend on the selected sensor model and driver configuration, and must be verified against manufacturer specifications.

robot_bringup:
  ros__parameters:
    use_sim_time: false
    base_frame: base_link
    odom_frame: odom
    map_frame: map
    lidar_topic: /scan
    imu_topic: /imu/data
    cmd_vel_topic: /cmd_vel
    publish_rate_hz: 30.0

Use on Leo Rover and Raph Rover

On Leo Rover, Concept to Market often starts from a constrained platform and expands through modular integration. The platform is suitable for education, prototyping, and field experiments, but it is not an autonomous vehicle out-of-the-box. A complete autonomy stack must be integrated, calibrated, and validated by the user. This affects schedule and architecture from day one.

A realistic Leo Rover path may include teleoperation first, then wheel odometry and IMU fusion, then 2D LiDAR mapping, then Nav2 waypoint navigation, and finally optional depth perception. The concept should account for the platform’s ingress protection constraints, differential drive behavior on loose terrain, and compute headroom on the embedded system.

For Raph Rover, the Concept to Market path usually addresses larger payload sensors, stronger compute, and outdoor missions with longer runtime. That can justify GNSS/RTK integration, larger LiDAR units, and multi-sensor fusion. However, Raph Rover is not a replacement for Leo Rover in laboratory and educational workflows. The concept should fit the platform scale, testing environment, and deployment cost.

Limitations and trade-offs

Concept to Market does not remove uncertainty. It structures it. In robotics, the main trade-offs are between performance, cost, complexity, and time to integration. A concept with many sensors may improve observability, but it also increases synchronization effort, calibration burden, power draw, and failure modes.

Common trade-offs include:

2D LiDAR SLAM versus RGB-D SLAM – lower complexity versus richer geometry
Embedded compute versus companion computer – lower power versus higher perception throughput
Pure wheel odometry versus fused localization – simplicity versus better drift behavior
Open-source stack reuse versus custom development – faster bring-up versus tighter optimization

Normative references and standards

Concept to Market itself is not a normative robotics standard, but its execution should use normative sources and stable technical references. For ROS-based UGVs, the most relevant references are ROS 2 documentation, REP 103 for standard units and coordinate conventions, REP 105 for coordinate frames on mobile platforms, URDF documentation, and hardware specifications from component manufacturers. For sensor fusion and navigation, the exact driver version, ROS distribution, and firmware revision matter and should be recorded in the project baseline.

Concept to Market