A 90-day playbook to stand up a new platform in a lab

Why most lab standup processes create technical debt

When a new research robot platform arrives in a lab, the natural instinct is to get it running as fast as possible. A motivated graduate student powers it on, installs the vendor's SDK on their laptop, gets something moving, and starts building the research stack on top of that initial configuration. Three months later, the lab has a working system. Six months later, when a second student joins, the first student says "I'll set up your environment"—and spends a week doing it manually, with subtle differences from the first install that cause intermittent bugs no one can diagnose.

This is not a failure of individuals. It is a failure of process. The 90-day playbook described in this article is designed to produce a different outcome: a deployment where the knowledge about how to set up and operate the platform lives in documented, version-controlled artifacts rather than in one student's head.

The platform selection process that precedes this is covered in "Matching research robot platform to research goal." The procurement and budgeting context is in "The real cost of a research platform."

Phase 0: Pre-arrival (Week -2 to 0)

The two weeks before the platform ships are not idle time. Two activities during this phase significantly reduce friction at arrival.

Set up the version-control repository. Create a repository (GitHub, GitLab, or institutional equivalent) named after the platform before it arrives. Populate it with:

• A README.md describing the platform, its research purpose, and who to contact
• A hardware/ directory for specs, calibration records, and maintenance logs
• A software/ directory for ROS packages, launch files, and configuration
• A .github/CODEOWNERS or equivalent that identifies the responsible researcher for each component

Starting the repository before the platform exists forces early decisions about organization and signals to the lab that reproducibility is a first-class concern.

Establish the ROS 2 environment baseline. Decide on the ROS 2 distribution (as of 2025, ROS 2 Humble Hawksbill LTS on Ubuntu 22.04 is the standard choice for new deployments targeting multi-year stability; Jazzy Jalisco is the current non-LTS option) and document that choice. Create a base Docker image or a documented install script that produces a clean ROS 2 environment. This becomes the ground truth for all lab members.

Document the following in a ENVIRONMENT.md in the repository:

• ROS 2 distribution and version
• Ubuntu version
• Nvidia driver version (if GPU is used for perception)
• Docker version
• Any system-level packages required (libxxx, etc.)

Phase 1: Safety review (Week 1–2)

No research experiment should run before the safety review is complete. This is not bureaucratic caution—it is the foundation on which all subsequent work stands.

What a safety review covers

Workspace hazard assessment. Identify the robot's force output, reach envelope, and potential failure modes. A manipulation arm at full extension can exert forces that cause serious injury. A mobile base can pin a person against a wall. Establish physical exclusion zones (floor tape, barriers, emergency stop placement) and document them with photographs in the hardware/ directory.

Emergency stop verification. Verify that the hardware e-stop (if present) and software e-stop work as documented by the vendor. Test them under load, not just at idle. For platforms without hardware e-stops, identify the fastest software path to zero-velocity and document the latency.

Load-in and power checklist. Many hardware failures occur in the first 48 hours of operation due to shipping damage. Follow the vendor's incoming inspection procedure if one exists; if not, create one: check all connectors, verify battery charge state, verify calibration (especially for arms—shipping can shift calibration), and run a low-velocity functional test before full-speed operation.

IRB considerations (for HRI platforms). If the platform will interact with human subjects, the IRB approval process must be initiated early—it typically takes four to twelve weeks at US universities. The safety data sheet from the vendor (including CE marking documentation, if applicable) is required input.

Deliverable

A SAFETY.md document in the repository's hardware/ directory, signed by the responsible PI, describing the exclusion zone, e-stop procedure, and any operational constraints. Every new lab member reads this before touching the platform.

Phase 2: ROS 2 environment and driver validation (Week 2–4)

The canonical environment

The environment established in Phase 0 is now instantiated and verified against the actual hardware. The goal of this phase is a Docker image or a documented install procedure that any lab member can follow to reproduce the development environment in under two hours.

Recommended structure for a containerized environment:

platform_ws/
├── Dockerfile                  # Base ROS 2 + platform dependencies
├── docker-compose.yml          # Mount host device nodes for hardware access
├── src/
│   ├── vendor_ros2_package/    # Vendor's ROS 2 package (as git submodule)
│   ├── platform_bringup/       # Lab's launch files and config
│   └── platform_description/   # URDF, meshes, Gazebo models
└── ENVIRONMENT.md              # How to build and run this workspace

Using the vendor's ROS 2 package as a git submodule (at a pinned commit) rather than a binary install allows the lab to track vendor updates deliberately rather than accidentally. If the vendor does not have a public ROS 2 package repository, document the install procedure with the exact binary version in ENVIRONMENT.md.

Driver validation checklist:

• All joint_states topics publish at expected rate
• Hardware timestamps on sensor topics are consistent and non-drifting
• E-stop via ROS 2 service works as expected
• Battery/power status accessible via ROS 2 topic
• URDF loads without errors in rviz2 and joint positions match physical robot

For platforms supporting simulation, also run the Gazebo or Isaac Sim model through this checklist to verify simulation-hardware consistency before the research team builds on the simulation.

Phase 3: Reproducibility infrastructure (Week 3–5)

Experiment versioning

Every experimental run should produce a data record that can be reproduced by a different person, on a different machine, from the repository. This requires:

Pinned dependencies. Use a requirements.txt or equivalent for Python dependencies, a package-lock.json or equivalent for JavaScript tools, and a documented exact list of ROS 2 packages with version pins. The Docker image should be reproducible from the Dockerfile without pulling latest.

Configuration as code. No experiment parameters should live in a researcher's head or in a text file on their laptop. ROS 2 launch files with YAML parameter files, committed to the repository, are the standard pattern. Every experiment should reference a specific launch file and parameter set that can be reproduced from the repository at that commit.

Bag file (rosbag2) labeling convention. ROS 2 rosbag2 recordings are the primary data artifact in most experiments. Establish a naming and storage convention before the first experiment:

bags/
├── 2025-08-15_experiment01_slam_indoor_run01.mcap
├── 2025-08-15_experiment01_slam_indoor_run02.mcap
└── experiment01_metadata.yaml   # Conditions, robot config, experimenter

The mcap format is the preferred container for rosbag2 as of 2024; it supports indexed playback and is more robust than the older SQLite-based format.

Data versioning. For datasets that grow over time, use DVC (Data Version Control) or an equivalent to track dataset versions alongside code versions. This prevents the "which version of the dataset did we use for that paper?" problem.

Simulation parity

If a simulation model is available, maintain it in the repository and run it in CI (Continuous Integration) to verify that code changes do not break the simulation-to-hardware interface. A simple CI check that launches the simulation and verifies expected topics publish catches a large fraction of regressions before they hit hardware.

Phase 4: Dataset hygiene and storage (Week 4–6)

What goes where

Research robot datasets grow quickly. A mobile platform running SLAM experiments at 10 Hz on four sensors generates roughly 200 MB/minute of bag data. Over a six-month project, this is hundreds of gigabytes. Labs that do not plan for dataset storage get into trouble.

Three-tier storage:

Establish this tiering convention before the first experiment, not after the NAS is full.

Annotation and metadata discipline

Every bag directory should have a metadata.yaml that records:

• Robot configuration (firmware version, sensor calibration dates, any hardware modifications)
• Environment description (indoor/outdoor, floor type, lighting conditions)
• Experimental condition (scripted path, free exploration, human subject present, etc.)
• Experimenter and date
• Known issues (sensor dropout, robot fault during run, etc.)

This takes five minutes per experiment session and saves hours of detective work when a reviewer asks about experimental conditions two years later.

Phase 5: First reproducible experiment (Week 6–12)

The benchmark run

The first formal experiment on a new platform should be a benchmark that can be repeated exactly—a calibration of the platform's behavior under known conditions that can be rerun by any lab member at any time to verify that the system has not drifted.

For navigation/SLAM platforms: a fixed-path traversal of a documented environment with ground truth from a MoCap system or a known map, producing a pose error metric.

For manipulation platforms: a pick-and-place of a specific object from a specific pose, repeated thirty times, reporting success rate and cycle time.

For legged platforms: a gait cycle on a flat surface at a specific speed, reporting joint tracking error and estimated contact force profile.

This benchmark run becomes the baseline. Every subsequent hardware maintenance event (battery replacement, actuator service, sensor recalibration) should be followed by the benchmark to verify system integrity.

Documentation handoff packet

At the end of the 90-day period, the deployment should produce a handoff packet in the repository that any incoming student can use to get started:

• README.md with quick-start instructions
• SAFETY.md with safety review results and operational constraints
• ENVIRONMENT.md with step-by-step environment setup
• Working Docker image or install script
• Benchmark run results with date
• Known issues log with workarounds

This packet is the lab's insurance against key-person dependency. It is worth the four hours it takes to write.

The 90-day milestone summary

What comes next

The final article in this series—"The research-robot procurement RFP"—provides a structured set of questions to ask vendors before purchase, covering SDK openness, ROS 2 support, academic pricing, spare parts, export control, and end-of-life risk. It includes a red-flag checklist for identifying procurement risks before they become lab problems.