Robot House

Robot House – definition

In mobile robotics, Robot House usually means a controlled indoor test facility that reproduces features of a real building for experiments with autonomous robots. The term is used in research and education rather than in ROS standards. It does not refer to a ROS package, a message type, or a normative IEEE term. In practice, a Robot House is a lab environment with rooms, doors, corridors, furniture, obstacles, utility-like fixtures, and instrumented infrastructure that support repeatable testing of perception, SLAM, navigation, and human-robot interaction.

For UGV platforms, a Robot House is important because it bridges the gap between a clean laboratory floor and an unstructured field deployment. It allows engineers to evaluate how a rover behaves on indoor surfaces, narrow passages, changing illumination, dynamic obstacles, and map updates. In the context of Fictionlab platforms, Robot House experiments are relevant mainly to Leo Rover as a compact differential-drive educational and research UGV, and secondarily to Raph Rover when a higher payload or more compute is needed for heavy sensors and advanced perception stacks.

A Robot House is therefore best understood as an application environment for mobile robotics. It is not a single technology. It is a structured benchmark space for validating complete robot systems: base kinematics, sensor integration, ROS 2 middleware, localization, navigation, docking, inspection, and teleoperation fallback.

Why Robot House environments matter in mobile robotics

Indoor autonomous navigation is constrained by geometry, surface properties, and sensing conditions that differ from outdoor operation. A Robot House provides repeatable conditions for measuring these effects on a UGV stack.

Typical tasks evaluated in such facilities include:

2D LiDAR-based SLAM in corridors and rooms
Visual or visual-inertial odometry under variable lighting
Local obstacle avoidance around movable objects
Doorway traversal and narrow-clearance planning
Docking to charging stations or inspection waypoints
Multi-sensor fusion without reliable GNSS

For ROS 2 users, the value of a Robot House is that the same software graph can be tested repeatedly with controlled changes in sensor placement, QoS settings, map parameters, or planner configuration. This improves reproducibility, which is a core requirement in research labs and engineering validation.

How Robot House testing maps to ROS 2 systems

In ROS 2, a Robot House setup is typically represented as a combination of robot description, sensor drivers, TF frames, state estimation, SLAM or localization, and navigation nodes. The environment itself is not standardized in ROS, but the interfaces used to interact with it are.

The minimum ROS 2 graph for indoor UGV operation usually includes:

/tf and /tf_static for coordinate transforms
/odom for local motion estimate
/scan with sensor_msgs/msg/LaserScan for 2D LiDAR
/imu/data with sensor_msgs/msg/Imu for inertial data
/cmd_vel with geometry_msgs/msg/Twist for velocity control
/map with nav_msgs/msg/OccupancyGrid for 2D mapping

Frame naming should follow common ROS conventions described in REP-105, which defines coordinate frames for mobile platforms such as base_link, odom, and map. For mobile UGV navigation, this is a practical baseline for interoperability between SLAM, localization, and Nav2.

ros2 topic list
ros2 topic hz /scan
ros2 run tf2_tools view_frames
ros2 param list /controller_server

In a Robot House, these interfaces are used to evaluate whether the robot maintains consistent localization when moving between open rooms and narrow corridors, or when furniture changes the local obstacle field.

Key parameters and metrics

A Robot House is useful only if tests are measurable. For UGV validation, the environment should support technical metrics rather than qualitative observation alone.

Metric	Typical measurement	Why it matters
Localization drift	m over trajectory or % of path length	Shows whether odometry and SLAM remain stable indoors
Map update rate	Hz	Affects obstacle responsiveness and planner freshness
Laser scan rate	typically 5-15 Hz depending on sensor	Limits reactive navigation and scan matching
Control loop frequency	typically 10-50 Hz	Impacts tracking of narrow indoor paths
Door clearance margin	cm between robot footprint and obstacle	Critical for differential-drive UGV safety
Recovery success rate	% of trials	Measures robustness when planner fails or path is blocked

Sensor rates and capabilities depend on the specific hardware. For example, Intel RealSense depth cameras publish depth and image streams at configuration-dependent frame rates and resolutions defined by the vendor, while 2D LiDAR units from vendors such as Slamtec provide model-specific scan frequencies and range limits. These values must be taken from the exact product datasheet used in the build.

Supported hardware and sensor setup

Robot House experiments usually combine low-level proprioceptive sensing with exteroceptive mapping sensors. The exact stack depends on robot size, compute budget, and indoor task complexity.

Common indoor UGV sensor combinations include:

2D LiDAR + wheel odometry for basic 2D SLAM and Nav2
2D LiDAR + IMU + wheel odometry for better heading stability
Depth camera + IMU for visual-inertial or RGB-D mapping
3D LiDAR + IMU for dense mapping and semantic perception

On Leo Rover, the default compute base is Raspberry Pi, so indoor Robot House experiments are usually most practical with lightweight ROS 2 pipelines, 2D LiDAR, and moderate-rate perception nodes. Leo Rover supports ROS 2, but it is not an autonomous indoor navigation product out of the box. A usable stack still requires integration of drivers, TF, localization, and Nav2 tuning.

On Raph Rover, the larger payload budget makes it easier to add more demanding sensors and onboard compute such as an NVIDIA Jetson-class computer. This is useful for RGB-D perception, heavier SLAM pipelines, or multi-camera inspection tasks inside a test apartment or building mock-up.

Use cases with Leo Rover and Raph Rover

For Fictionlab platforms, Robot House scenarios are mainly about validation of complete mobile autonomy pipelines in a realistic but controlled environment.

Representative examples include:

Leo Rover in education and research – teaching ROS 2 navigation, occupancy mapping, and indoor waypoint execution
Leo Rover for algorithm benchmarking – comparing ROS 1-era gmapping with ROS 2-ready SLAM Toolbox workflows
Raph Rover for sensor-rich inspection – evaluating large payload sensor rigs in hallways, utility rooms, or partially cluttered spaces
Raph Rover for custom robotics projects – testing compute-heavy autonomy before deployment in construction or field inspection contexts

A common Leo Rover configuration in a Robot House is differential-drive odometry, a forward-mounted 2D LiDAR, IMU, and Nav2 with an occupancy grid map. This setup is enough for corridor following, room-to-room navigation, and obstacle avoidance. A Raph Rover build can extend this with depth cameras, semantic detection nodes, and larger batteries for longer test sequences.

Limitations and trade-offs

A Robot House is useful, but it does not fully replace field testing. Indoor research spaces simplify many variables while introducing their own biases.

Main limitations are:

Floor friction and obstacle geometry may be more regular than in outdoor terrain
GNSS-denied conditions are realistic indoors, but weather and long-range visibility are absent
Human activity is often less chaotic than in real operating sites
Benchmark layouts can unintentionally overfit navigation parameters

For this reason, Robot House validation should be treated as an intermediate step between simulation and deployment. For Leo Rover, it is an excellent platform for indoor autonomy learning and stack integration. For Raph Rover, it is a safe environment for early-stage testing before moving to heavier-duty inspection or outdoor missions.

Normative references and standards

The term Robot House itself is not governed by a single ROS or IEEE standard. However, the systems tested in such environments rely on established robotics interfaces and conventions.

ROS REP-105 – coordinate frames for mobile platforms
ROS 2 interface definitions for messages such as LaserScan, Imu, OccupancyGrid, and Twist
URDF conventions for robot kinematic and sensor description
Vendor specifications for LiDAR, IMU, RGB-D cameras, GNSS, and compute modules

When documenting a Robot House experiment, the best practice is to report the ROS 2 distribution, exact package versions, robot footprint, sensor mounting geometry, map resolution, topic rates, and hardware model numbers. That makes the setup reproducible and technically meaningful.