What Makes a Product Robotic

A product becomes a robot when it closes a loop: it senses something about the physical world, decides what to do, and moves, without a person supervising each step. A remote-controlled toy is not a robot. A vacuum that maps a room, avoids a chair leg, and returns to its dock when the battery drops is.

That definition matters commercially because each of those three verbs is a separate engineering discipline with its own cost, its own team, and its own failure modes. Consumer robotics projects rarely fail on any single one. They fail because the layers were developed in the wrong order.

The Motion Layer

Everything downstream depends on the machine actually moving the way the software believes it moved. Start with a real torque budget, not a guess: worst-case grade, worst-case surface, worst-case payload, plus acceleration, plus a margin for a carpet edge or a wet leaf. The method is in how to calculate the motor torque your product needs, and undersizing here shows up as a robot that stalls in exactly the situations customers post videos about.

Brushless motors with field-oriented control cost roughly $8 to $18 more in bill of materials than brushed motors and a simple driver, and they are almost always worth it in a product that runs for years. They are quieter, more efficient, and they give you motor current as a free force sensor, which is how a robot knows it has hit something without adding a bumper.

Two mechanical realities dominate. Wheel odometry lies, because wheels slip differently on carpet and tile, so it must be fused with an inertial sensor. And consumer floors are hostile in ways lab floors are not: hair around axles, water, pet accidents. Seal the drive, make brushes and wheels removable without tools, and get the mechanics boring before you write navigation code, following the staging in how to build a prototype for a robotic product.

The Perception Layer and the Compute Split

Sensor choice sets both cost and customer expectation. Rough per-unit costs at consumer volume:

  • Mechanical bumpers and cliff sensors: a few dollars total. Non-negotiable as a last line of defense even on a sophisticated robot.
  • Single-point time-of-flight rangers: $2 to $6 each, excellent for cliff detection and short-range obstacles, blind to dark or angled surfaces.
  • Spinning 2D LiDAR: $20 to $60. Turns a wandering robot into a mapping robot, which is what reviewers now expect above a certain price point. It has a moving part with a finite lifetime, so specify the bearing rating against your service life.
  • Cameras with on-device vision: the image sensor is cheap; the compute and the software are not. Object recognition that reliably avoids a phone charging cable is a multi-engineer-year problem, discussed in computer vision in a connected product.
  • Inertial measurement unit: $1 to $4, and essentially mandatory for heading, tilt, and lift detection.

Resist the urge to add sensors to cover software weakness. Each one adds calibration, a failure mode, and a factory test step.

Split the compute. Almost every successful consumer robot uses two processors: a microcontroller running the motion and safety loop at a fixed rate with deterministic timing, and an application processor running Linux for mapping, vision, and connectivity. The split costs a few dollars and guarantees that a hung perception process cannot leave the motors energized. Settle it with microcontroller vs embedded Linux before committing to a board architecture, because moving that boundary later is a six-month setback.

The Decision Layer Is Mostly Recovery

Engineers new to robotics budget their time for path planning and coverage. In shipped products, the overwhelming majority of the behavior code and nearly all the field failures live in recovery: the robot is wedged under a couch, one wheel is off the floor, the dock is occupied, a cable is wrapped around a brush, the map no longer matches the room because someone moved the furniture.

Structure this as an explicit hierarchy of behaviors with hard timeouts and defined escalation, rather than as conditionals scattered through the navigation code. The patterns in state machines in firmware apply directly. Then instrument every recovery event with telemetry, because your beta fleet's stuck-events log is the single most valuable dataset the project will produce.

Safety Is Architecture, Not a Section of the Manual

A consumer robot operates unsupervised in a home with children and pets, and it holds energy in a battery and momentum in a drivetrain. Safety cannot be a software check inside the same process that might crash.

Build it in hardware: an independent watchdog that removes motor power if the control loop stops servicing it; a current limit in the driver, not only in firmware; lift and tilt detection that cuts any cutting or brushing mechanism within a defined time measured in tens of milliseconds; and a physical stop control that is a real switch in the power path. Anything with a blade, a heater, or a pinch point needs a formal hazard analysis and third-party testing, and the landscape of what applies is summarized in product safety testing requirements. If the product will be marketed to or used by children, the applicable requirements tighten considerably.

Energy Sets the Product Definition

Runtime is a headline spec and a hard constraint. Budget it by subsystem: drive motors typically consume 50 to 70 percent, application compute and radios 15 to 30 percent, and sensors and auxiliary actuators the remainder. Add the reserve the robot must hold to reach its dock from the far corner of the largest supported space, since a robot that dies mid-room is perceived as broken.

The pack is a subproject of its own: cell selection, protection circuitry, charge management at dock contacts that corrode, cycle life, and lithium shipping qualification. Treat it as one using battery pack design for a product, and never let a packaging decision fix the cell count before the power budget exists.

The Expensive Mistake

It is scoping full autonomy into version one. Teams commit to unmapped free navigation in arbitrary environments, spend two years on perception, and ship a product whose mechanics were never hardened. The alternative is constrained autonomy: a boundary marker, a docking beacon, a defined operating area, a user-drawn zone in the app. Customers accept constraints they understand far more readily than they accept a robot that behaves unpredictably.

Plan realistically: 18 to 30 months and $600,000 to $2.5 million to production, with the second year spent almost entirely on reliability. Ship the constrained version, collect fleet data, and expand autonomy over the air.

Scoping a Robotic Product

Projects House develops robotic consumer products across all four layers: drivetrain and mechanics, sensor selection, compute architecture, behavior software, and the hardware safety chain underneath them. Describe what your product needs to do unattended in the contact form and we will tell you what it takes to build.