Robotics ยท Our Approach
How We Build a Robot Cell
A robotics project has many moving parts. We work in a clear order so the project does not get stuck. First we finalize the requirements. Then we pick the hardware. Then we build the software stack. Then we bring the cell up on real hardware.
- 01Finalize the Requirements
- 02Select the Hardware
- 03Build the Software Stack
- 04Integrate and Bring Up
The Four Phases of a Robot Cell
We walk every robotics project through the same four phases. Each phase has a clear output that the next phase needs. Skipping a phase usually means going back and redoing earlier work.
Finalize the Requirements
Write down what the robot has to do, before buying anything.
Most robotics projects fail because the team starts shopping for hardware before they have agreed on the task. We start the other way around. We sit down with you, write the task in one sentence, and answer the basic questions that decide everything else.
What we do
- Pick the exact task and the limits of v1.
- Decide the working area, payload, and reach.
- Pick the accuracy needed (millimetre, sub-millimetre, or coarse).
- Decide how the robot talks to people and other systems.
- List the safety and audit needs of the lab or factory.
Output of this phase
A short, clear written spec. Used as the input for every later choice.
Goes into the next phase
Select the Hardware
Pick the arm, gripper, sensors, and compute the spec actually needs.
With the spec written, hardware choices become small and clear instead of big and political. We work through each piece one at a time, pick the most common, well-supported option that fits, and write down why.
What we do
- Choose the arm class. Cobot, industrial, or research arm.
- Choose the gripper. Parallel-jaw, suction, or a custom top-down tool.
- Choose the sensors. RGB-D camera, force/torque, contact, encoders.
- Choose compute and power. Jetson or NUC, mains or 24 V supply.
- Choose mounting, safety equipment, and the operator interface.
Output of this phase
A bill of materials with vendors, prices, and the reason for each choice.
Goes into the next phase
Build the Software Stack
Pick the open-source layers that fit the hardware and the task.
Most projects use the same software layers. We choose the version that fits your hardware and task, and we wire them together so the cell behaves the same way in simulation and on the real robot.
What we do
- Operating system and runtime. Ubuntu LTS, ros2_control.
- Middleware. ROS 2 (Humble or Jazzy) with Cyclone DDS.
- Motion planning. MoveIt 2 with OMPL, OMPL planners, or CHOMP.
- Perception. OpenCV, Open3D, and modern vision foundation models.
- Task orchestration. Behavior trees so the workflow is easy to read.
Output of this phase
A working ROS 2 stack we can run in Gazebo before any hardware arrives.
Goes into the next phase
Integrate and Bring Up
Move from simulation to real hardware in small, safe steps.
Once the cell works end-to-end in simulation, we move to hardware in small steps. The goal is to find every problem on the bench, not in production. We finish with acceptance tests, operator runbooks, and Day-2 monitoring.
What we do
- Simulation-first end-to-end run in Gazebo or Isaac Sim.
- Calibration (camera, hand-eye) on the real hardware.
- Bring-up of each subsystem before running the full task.
- Pilot run with the technician in the room.
- Acceptance tests, runbooks, and monitoring for the long run.
Output of this phase
A working robot cell you can run, audit, and maintain.
Goes into the next phase
Principles We Hold To
These four ideas show up in every project we run. They are how we keep a robotics project from drifting into a hardware-shopping project.
Simulation-First
We do not buy hardware to find a bug. Every motion, every grasp, every behavior is tested in Gazebo or Isaac Sim first. Real hardware lands on a known-working stack.
Open Source by Default
ROS 2, MoveIt 2, Gazebo, OpenCV, PyTorch. We pick well-supported open layers so your team can read, fix, and extend the stack later.
Safety in the Spec
Collaborative arm, force limits, e-stops, status lights, and a clear safety story. We treat safety as part of the requirements, not an add-on.
Audit by Default
Every action the robot takes is logged with a timestamp. For pharma, clinical, and food QC labs, this turns a long audit into a short one.
See our approach in action
Our flagship robotics project is an HPLC autosampler arm for chemistry labs. The case study walks through the same four phases on a real lab workflow.