How to Lay Out a Robot Work Cell in Your Browser — No CAD, No RTX GPU
You can rough out a robot cell layout in your browser before you open a single CAD file. Pick the robots, drop in grippers and conveyors, position them on a floor, and check reach by dragging the joints — all from a URL, on an ordinary laptop with no RTX GPU. This guide walks through robot work cell design online as a concepting step: fast enough to do live on a sales call, and honest about where it stops.
# Why robot work cell concepting is slow
The early "what if we put the arm here" phase inherits the cost and latency of tooling built for a much later job:
- The feasibility path is heavy. Standing up a cell in ROS with MoveIt to answer "can this arm reach every pick" is days or weeks of setup — URDFs, planning scenes, IK solvers, and collision meshes, all before you learn anything.
- The sim seats are expensive. Enterprise offline-programming and simulation suites run roughly €16,000 to €48,000 per seat. GPU-accelerated simulators expect a workstation-class card — an RTX 4080 or better — before they run smoothly at all.
- Concepting pays that bill too early. The cheap, exploratory layout question does not need a solver farm or a licensed seat, but the usual tools force you to bring both to the table.
# What you can do in a browser instead
Concepting is a different job from validation. At the concept stage you are answering layout questions: which robot, where it sits, whether the reach looks plausible, whether the cell fits the footprint, and whether the customer can picture it. None of that requires a solver, a license, or a discrete GPU. A browser scene graph handles it, and — because it is just a URL — it travels straight into the conversation.
At the concept stage, a browser layout is enough to answer the questions that actually decide the proposal:
- Which robot fits. Compare arm envelopes and payloads from the catalog side by side in the same scene, at real scale.
- Where each machine sits. Place the arm, conveyor, and cobot on the floor and read the footprint at a glance.
- Whether the reach looks plausible. Pose each robot through its range and eyeball coverage of the pick and place points.
- How to explain it. Hand the customer a link they can orbit and pose, instead of a static top-down drawing they have to interpret.
# Lay out a robot work cell in your browser: step-by-step
- Open the studio. Yugma Studio runs in any browser. No CAD license, no install, no RTX GPU.
- Describe the cell in plain English, or pick the parts. Type something like "a two-robot pick-and-place cell with a six-axis arm over an infeed conveyor and a cobot at the outfeed," and the AI Director places catalog parts for you. Or build it by hand from the 1,315-model catalog — choose robots, grippers, conveyors, and fixtures by category or manufacturer.
- Position everything. Move, rotate, and space the parts on the floor. Set the arm on its pedestal, line the conveyor to the infeed, and drop the cobot at the outfeed until the arrangement reads right.
- Check reach visually. Open the Joints panel and drag each robot through its range. Because the browser runs forward kinematics live, you can see whether an arm plausibly covers its pick-and-place points and whether two robots overlap.
- Share an interactive link. Export a viewer URL and send it to the customer or your team. They open it in a browser, orbit the cell, and pose the robots themselves — a far stronger proposal artifact than a slide, and it often wins the room.
# Honest scope: what this is and what it is not
Read this before you quote a cycle time. Browser cell layout is concept, layout, and visualization. It is not constraint-correct reachability, collision, or clearance analysis — that is on the roadmap, not shipping today. It is not discrete-event (DES) cycle-time simulation, and it does not generate robot code. Treat it as the sketch you win the room with, then export the concept to your offline-programming or simulation tool for real validation.
Being upfront about that boundary is the whole point. A visual reach check tells you an arm looks reachable; it does not prove the arm can hit every pose without collision, singularity, or exceeding a joint limit under load. Those answers come from MoveIt, RoboDK, Visual Components, or a physics sim — and you should still get them before anyone cuts steel.
# Where this fits your workflow
- Concept in the browser. Lay out the cell, check reach by eye, and get buy-in on the arrangement.
- Share to align. Send the interactive link so stakeholders and the customer agree on the layout before anyone spends solver time.
- Export to validate. Move the agreed concept into your OLP (offline-programming) or DES tool to prove collision-free reach and estimate cycle time.
This keeps the expensive tools for the job only they can do, and takes the slow, license-gated setup out of the early conversation. If those seats are the real bottleneck, see why teams route around €16k+ simulation seats. And if you want to get comfortable posing a single robot first, start with viewing a URDF robot in the browser.
# FAQ
Do I need CAD or a powerful GPU?
No. It runs in a browser on ordinary hardware — a laptop, even a Chromebook. There is no CAD license to buy and no RTX card to rent just to sketch a layout and share it.
Can I trust the reach check for a real quote?
Treat it as a visual sanity check, not a guarantee. It shows whether the geometry looks plausible. Before you commit to a cycle time or a footprint, validate reach, collision, and clearance in a constraint-correct tool.
Can the customer open the layout without an account?
Yes. A shared viewer link opens read-only in any browser, so a customer can orbit the cell and pose the robots without installing anything or signing up. That interactivity is what separates a concept link from a rendered image — the customer explores the layout on their own and arrives at the next meeting already sold on the arrangement.