Bento AI — cell simulation viewer

Kernel-driven line · robot cooking measured in physics — what is real here?

Trays, pan levels and cooking come from the real Rust factory + cell kernels in wasm, every 100 ms. DESIGN floor & positions · ASSUMED cook times · MEASURED the humanoid's cooking at the wok and the fryer: the arm path, the tool it holds and the food pieces are what our physics simulation produced when the planned motions were played through it (Genesis, on our cloud GPU machine) — the spatula scrapes the wok while the wok station rocks it, the skimmer turns the tempura in the fryer basket. Arm within 15 mrad of its plan, all food stayed in its vessel. Machines do the heavy work (DESIGN): the wok station holds and rocks the wok, the fryers' auto-lift moves the baskets, and the braising pan's own mixer stirs — measured: the robot's arm reaches only the near corner of the big pan, so the robot loads, checks and unloads it. Known model limits: the simulated sauce seeps out under the pan walls at about 0.5 %/s (a solver artefact, not a spill);. Dish colour and temperature are KERNEL; the torso turn between machines is DRAWN · KERNEL pans on the feeder conveyor and in the rack · KERNEL food temperatures and colour, from a cooking model (Newton heating, ASSUMED constants — not a heat-transfer simulation); steam is DRAWN over batches above 90 °C · DRAWN the parked line arms.

factory clock 00:00:00

What if…

Humanoid hands-on speed 1.0× ASSUMED Humanoid cook stations 1

The humanoid loads, checks and unloads; the braising pan (with its own mixer) and fryers do the cooking (the wok needs it the whole batch), so speed changes its hands-on time, not the machines'. Changes apply to new batches. Only one humanoid is drawn. Menu: Niseko winter bento (example, 6 parts) — the only menu in the model so far.

Food in each pan (portions at the line, last 2 h)

Cooking KERNEL (model: Newton heating from 5 °C; ASSUMED temperatures and heating times; safe = core ≥ 75 °C for 1 min, Japan HACCP guideline)

Who is cooking

How busy each station is KERNEL (the cell's own average since factory start, so the kitchen head start pulls it down)

Kernel-driven room — what is real here?

KERNEL robot position, state, tool, load (kind, item, kg), battery, code scans, which arm move it is doing and for how long; station state, contents and time left; stock by lot; HACCP alarms; every number on the panels — the real Rust prep kernel (prep-sim) in wasm, 1 s ticks · DESIGN room, walls, doors, zones, aisles, drip strip, station footprints and heights, docks, path graph, cold room — read at run time from the spec the kernel was built from (sim/prep/prep.json) · PLANNED the arm: UR's own joint chain and link sizes; every pick, place, door, button press, pour and tool change is a collision-free move planned offline (NVIDIA cuRobo on our cloud GPU for the free moves, straight approaches on the Mac), timed within the arm's joint limits, then replayed in a collision test (MuJoCo): no contact and at least 20 mm clearance except where the tool is meant to touch. Carried crates, pans and bins and the tool hand-over at the rack follow the planned move; the fridge, freezer and blast doors and the roll-out shelves open by themselves (door operators, triggered by the robot over I/O — the arm never touches a door). The kernel's move times are these planned times (MEASURED in simulation). Moves with no collision-free path are marked on the robot and listed as layout findings (sim/prep/motions/findings.json) — the arm stays in its carry pose there · DRAWN the base heading between docks, the doors' and shelves' opening and closing, the walk-in's sliding door (opened by I/O), the scan flash. No forces here (that is PS6). · INPUTS simulation, not measurement: kitchen amounts from a chef’s recipe sheets (unverified; menu names generic and amounts rounded to 0.5 kg on this public page); machine times, costs and capacities ASSUMED or vendor claims; vegetable prices from public Sapporo wholesale-market statistics.

Day Arm room clock 06:00:00

Timeline (robot, person and the machines the robot starts; 06:00 → scenario end)

Day so far KERNEL

Stock by lot

Food-safety alarms (HACCP)

Season — the year run (PS4) KERNEL (Aug → Jul, weekly; the arm picked above; calibrated daily capacity from the day kernel)

Price year Kitchen demand

Simulation, not a measured factory — what is real here?

One facility day on one clock, every room played back from its own kernel: nothing is decided in this tab · KERNEL the prep robot (the prep day inside the chef run, prep-sim), the chef cell, machines and service robot (chef-world, that dish and rung), each tray's chiller load and times (facility-sim chill stage), the cold hold's release at 100 / 500 (FD13), the pack robot's stops, every pack's times, freezer cycles and parcels (pack-sim), the morning's deliveries and the trace (stock-sim, rungs 1 and 10) · PLANNED the G1 chef's joints and the prep arm's clips · DESIGN rooms and transfers (sim/facility/facility.json), the chef twin and the 500/day south bay (sim/chef/miura.json, shown at 500 only), the pack room (pack.json); the prep room is the PS2 room drawn at 46 % in the PREP rect (FD1 re-layout open) · ASSUMED where the 100/day reach-ins and the cold hold stand (the 500 hold's floor is not chosen), delivery at 06:30, at 1 and 10 a day a tray reaches the pass box at the chef kernel's own cool time · DRAWN the shell, cold-store shelves, a tray's 4-min glide between two places, the crates' walk, the robot beacons · dishes are numbers, ingredients categories.

Bento a day Day

Bentos

Simulation, not a measured room — what is real here?

KERNEL the robot's stops and jobs, every tray's times (ready, inspected, labelled, frozen, stored), freezer cycles, orders, HACCP checks: played back from the pack kernel's day (pack-sim, Rust, deterministic); nothing is decided in this tab · KERNEL rungs 1 and 10: the chef kernel's sealed bentos (Miura twin) arrive at the pass box; rungs 100 and 500: evenly 08:00–16:00 (ASSUMED) · DESIGN the room (the old shop X4–X6, drawn from the building reconstruction, not a survey), machine positions, robot docks · VENDOR machine sizes and capacities from the PD1 research (maker claims; most prices are quote only) · ASSUMED robot action times, people's minutes, order sizes, the 120-min chilled and 10-min out-of-freezer limits · the arm is a stand-in shape; no physics here (PD7).

Bento a day Freezer Robot room clock 06:00:00

Timeline (05:00 → 04:00 next day)

All 18 days compared (kernel summary)

Food safety + orders

Simulation, not a measured robot — what is real here?

Played back from the chef kernel's own day (chef-world, seed 7, mains): nothing is solved or decided in this tab · KERNEL machine states, batches, core temperatures, which ports a motion uses, protective stops, people in the zones, pans (unload, arrival at the well and their core ℃), bento sealed, every request on the timeline, the result · PLANNED the G1 torso's 31 joints: the planned HC7g joint paths, played as the kernel's permits released them — a simulation, not a measured robot · DESIGN the twin: cell, fence, gate, belts, ducts, footprints, aisles and zones (sim/chef/miura.json), and the swing-away module, its posts, the docking rail and the backup cook’s way in (HC-D61; when they move KERNEL, how long ASSUMED); building grid DRAWN · ASSUMED machine times, belt speed, walk / gate / gloves times · DRAWN the wok tilt and pot-lifter shapes, people figures, the service robot's straight path between stations, the backup cook’s walk · Masses UNVERIFIED; chef times PLANNED; no forces here.

Simulation, not a measured robot · KERNEL / PLANNED / DESIGN / ASSUMED / DRAWN

kernel clock 00:00:00

Timeline (key events of this run, KERNEL; click to jump)

Machines now KERNEL (cooked ≥ 75 ℃ for 1 min; hold ≥ 65 ℃)

Latest events

Status tags: KERNEL decided by the chef kernel · PLANNED planned joint paths · DESIGN twin layout · ASSUMED times · SIMULATION all of it: a simulation, not a measured robot. The safety kernel authorises every motion; an unauthorised request moves nothing.

Exported, not modelled. Every mesh here is a body in the RoboCasa365 TurnOnStove simulation (assets CC BY 4.0). Drag to orbit.

Scripted IK, not a policy. Reaches solved against the kitchen's own anchors. The agitation is a fold, not a toss.

Pre-computed physics. Joint paths solved once by the Genesis/MuJoCo cell and replayed here — this page runs no solver.

Live kernel, no physics. The real cell-sim kernel is running in this tab as WebAssembly and deciding. Nothing is solved and nothing is commanded, so the arms stay at their home pose in every case.

Arms drawn at UR20 kinematics — the arm the run was solved for. Joint origins and axes come from the UR20 model; the tubes are the viewer's own geometry, because UR's meshes are not redistributable. Rendered reach is the solved reach.

0.0s / 0.0s

sim clock 0.0s

Enqueue a ticket — the gate decides

Inject a fault

Every ticket is minted by the kernel's own fixtures with a real Ed25519 key and verified by safety-core inside wasm. The bad kinds are not flagged as bad — they fail the genuine check.