Load Cells for Food Delivery Robots: The Tray Is the Robot’s Eye

1. Why a delivery robot does not need a scale

I sell load cells for food delivery robots to the people who build the robots — not to the restaurants that rent them. My customers are the factories: the ones that weld the mast, cut the tray plates, write the navigation stack, and then discover that the last unsolved problem on the whole machine is a small metal part sitting under a tray.

Almost every enquiry starts the same way. Somebody has been burned by infrared tray sensors, or has read that they have blind spots, and has decided to “put a load cell on each tray instead.” That instinct is right. What is almost always wrong is the specification that arrives with it, because the specification is written as if the tray were a kitchen scale. It is not. A tray on a moving robot is the only weighing platform I supply that spends its entire working life on a vehicle, in public, with strangers touching it.

So let me state my side of the drawing before anything else, because it decides what you should even ask me for. I make the sensing chain: load cells, force sensors, junction boxes and weighing indicators. I do not build the robot, the mast, the tray plate, the drive train, or the navigation stack. I do not hold machine certification for your product, and I will not sign your risk assessment. What I can do is tell you, with arithmetic, which cell belongs on that tray, what it will and will not see, and where the honest limit of the measurement sits. Everything above that line — the CE marking, the safety functions, the site assessment — belongs to you and your notified body, and I will say so again in section 13.

The reason a robot factory calls me at all is that the tray is doing four different jobs at once, and they have all been given to one sensor without anybody writing the list down:

One load cell can answer all four questions. It cannot answer all four at the same time, and it cannot answer them at the same accuracy. The rest of this article is about deciding which one you are allowed to get wrong, because that decision costs nothing and it is the difference between a tray sensor that works for three years and one that generates a support ticket every afternoon.

2. Infrared is blind in space. Weight is blind in time.

Here is the problem that put tray weighing on the roadmap of nearly every robot builder I work with, and I can state it from the source material my own industry circulates rather than from a customer’s complaint form.

Most delivery robots on the market detect whether something is on a tray with infrared proximity sensors. Infrared is a beam with a cone. Put a small plate down, or put the plate near the edge of the tray instead of in the middle, and the beam never crosses it. The tray is full and the robot reports empty. The robot then refuses to leave the pass, or leaves without the dish, or drives back to the kitchen to be reloaded. Either way, a human is pulled off another job to fix something a sensor got wrong. The failure is not random — it happens on exactly the objects a restaurant actually uses: a soup bowl, a sauce dish, a child’s plate, a tray of cutlery.

Weight sensing fixes that completely. Load a cell under the tray plate and it does not care where the bowl is, how small it is, or whether it is porcelain or glass. It sums. That is the whole pitch, and it is a good pitch, which is why I get asked for it.

But I have to be honest about what you have traded away, because the trade is not “bad sensor for good sensor.” It is a blind spot in space for a blind spot in time.

The row in red is the row I sell, and I have written it in the same table as the others on purpose. If you are choosing between these four because you want one of them to be obviously right, you will make a worse decision than if you choose two of them and make them disagree on purpose. The robots I see succeed use weight for quantity and a beam or a camera for identity, and they are wired so that a disagreement raises a flag instead of being silently resolved. If you want to see how that division of labour is done in unattended retail, where the same problem was solved years ago, the vending machine guide and the smart shelf guide are the two I hand out most often for this.

3. Four trays are not four scales

This is the first thing I check, and it is the thing that has cost my customers the most money. It is a mechanical question with a firmware symptom, and it arrives in my inbox described as a sensor fault.

Look at the class of machine you are building. The BellaBot carries four trays and 40 kg, so 10 kg per tray. Bear Robotics quotes the Servi Plus at 88 lb over three trays, or about 12 kg per tray. The Keenon T8 carries 20 kg across three trays, so roughly 6.7 kg per tray. Now the question that decides your entire sensor architecture:

Do the four trays sit on four independent load paths, or do they hang off one column?

On most of the robots I have been given drawings for, the trays are cantilevered off a single central mast. That is a sensible mechanical choice: it is stiff, it is cheap, it is easy to keep the trays level, and it puts the mass low. It is also a decision that means tray 3’s sensor is measuring tray 3 plus everything above it. Put a cell under each tray of that machine and you have not built four scales. You have built one scale with four windows onto the same number, and every one of those windows has a different leverage, a different cable, and a different zero.

I have watched architecture C cost a customer a full hardware revision. The symptom was described to me as “the lower sensors are noisy” and the request was for a tighter tolerance part. The request was wrong. The lower sensors were reading correctly — they were reporting a load change, because a load change really had occurred at the top of the machine, and the mast was transferring it. No tolerance I can hold on a strain gauge changes that.

There is one more version of this trap that nobody expects, and it shows up when the trays are right. If your top tray is removable and docks into a bracket, then the bracket is a second load path the moment the tray is slightly twisted or the locating pin is worn. The cell underneath then measures a fraction of the tray, and the fraction changes as the dock wears. The zero-cost test for that is in section 10, and it takes about thirty seconds.

The same stacking logic governs a great many machines that are not robots at all. If you want to see it worked through on a locker bank, a shelf, or a set of drawers where each compartment has its own cell and they all share a frame, the smart locker guide covers the same failure with the same arithmetic.

4. The range is set by the door threshold

Ask a robot builder what the tray has to carry and you will get a menu. Ask them what the tray has to survive and you will get a pause. Those are two different numbers, and the second one is bigger. Here is the arithmetic I do on a call, out loud, because it is faster than waiting for a reply.

A four-cover tray in a mid-market restaurant: a 26 cm porcelain dinner plate at about 600 g, a rice bowl at 450 g including contents, a glass at 250 g, and a wrapped cutlery set at 80 g. That is 1,380 g per cover. Four covers is 5,520 g, and the tray plate itself — the aluminium or ABS panel the cups actually sit on — adds about 1,200 g. So a loaded tray in my design case is 6,720 g, which is 44.8 % of a 15 kg cell. Comfortably inside the 30–60 % working band I like, with room for a coffee pot on top.

Now the number that actually sizes the part. Your robot weighs it does not matter how much; what matters is that it rolls. A caster crossing a 10 mm threshold at walking speed is a small vehicle falling off a small kerb, and the tray experiences it as a vertical acceleration pulse. The impact speed is 0.443 m/s — that part is fixed by the height. What you control is how far the machine takes to absorb it, and that is where the cell’s fate is decided.

Read the last column again, because it is the whole point of this section. A 15 kg cell lives comfortably at 20 mm of compliance and dies at 2 mm, on exactly the same tray, carrying exactly the same dinner. The part number did not change. The bumper did. If you want the 15 kg cell to stay inside its 150 % safe overload through a 10 mm threshold, you need at least 20 mm of absorption somewhere between the wheel and the load axis. That is a design instruction, not a sensor specification, and it costs a few euros of elastomer.

There is also a free fix, and I push it harder than any part number. Your navigation stack already knows, to the millisecond, when the robot is moving and when it has settled. Do not read the tray while it is moving, and do not act on a reading taken during the first second after it stops. That single rule removes the entire shock table above from your error budget, because the impact only exists while the wheels are turning. I have watched it turn a tray sensor that “jumps constantly” into one that never misses a plate. Nothing was purchased.

5. Your guest’s hand is heavier than the plate

The question the robot is trying to answer at the table is “did something leave the tray?” The sensor does not see a departure. It sees a number go down. And there are at least three different things in a dining room that make the number go down:

Somebody took the plate. Somebody rested a hand on the tray and then took it off. Or the tray cooled by two degrees because the robot has been standing near a window. The first two produce amplitudes in the same range. The third produces a drift that is smaller than either, which sounds reassuring until you remember it accumulates over a shift.

Look at rows two and three. A hand and a plate produce amplitudes that overlap: a relaxed hand is 400 g, half of what a plate weighs, and a person steadying themselves is twenty times a plate. There is no threshold you can set on amplitude that separates “took a plate” from “put a hand down,” because the hand can be lighter than the plate and heavier than the plate, depending on the guest. This is the point where a lot of builders go shopping for a better sensor, and it is the wrong shopping trip.

One more thing about the hand, and it comes up on every single project. If your tray logic removes the hand’s weight by using a moving average or a slow filter, you will also be removing the plate, because the plate’s change is not much faster than the hand’s. Filtering is a trade, not a setting. I have seen a robot that reported a perfectly smooth tray weight all evening and never once noticed that the plates had left, because the filter time constant was longer than the guest’s visit. If your stability looks beautiful, check whether it is still telling the truth — that specific failure is written up in more detail in the fault-finding walkthrough.

6. You will see the plate. Not the napkin.

This is the most valuable calculation in the article and it takes ninety seconds. The question is never “how accurate is the sensor.” It is “how small a change can this sensor see, given everything else that is moving.” That number is a floor, and it has three parts.

Add the three rows and you get 7.5 + 4.5 + 3.75 = 15.75 g. I round that up to 16 g on purpose, because a floor is a worst case and it should never be quoted optimistically to a customer who is about to write firmware against it.

Now put the actual objects against that 16 g floor. This is the table I send back when somebody asks me for a tray sensor that can detect a napkin.

The mirror image of this is the one that costs real money, so it is worth stating plainly. Over-sizing the cell makes the floor worse, not better. Take the same 0.05 % F.S part and buy it in 30 kg instead of 15: the floor goes from about 16 g to about 31.5 g, and the cutlery set drops from 5× the floor to 2.5×. You paid more and bought a tray that can no longer see a spoon. This is the same trap I have written about for hopper scales and for mixer cradles, and it is the reason I keep a plain-language selection guide rather than a catalogue on my desk.

7. The only number that matters is a difference

Now I am going to give you the single largest improvement available to your tray system, and it is a change of question rather than a change of hardware. It comes from the fact that nobody pays for the meal by the kilogram. Your robot does not price anything. It is not a legal measuring instrument, it will never be inspected as one, and the absolute mass on the tray is a number that no customer, no accountant and no regulator ever asks you for.

What the robot actually needs is this: what did I leave the kitchen with, and what came back? Two readings, taken on the same tray, minutes apart. Everything interesting lives in the difference between them.

There is one condition on that improvement, and it is the reason this section exists.

The two readings must share the same zero. The moment your firmware performs an automatic zero-set between them, you have broken the only thing that made the subtraction good. Every product I have seen with a mysterious “weight creep” complaint has had an auto-zero somewhere in it, and every one of them had it for a defensible reason: settling after boot, saving a service call, handling a bumped tray.

The version of this rule I now recommend by default has three conditions, and all three have to be true before the zero moves:

1. The tray reads empty — below a low threshold that is comfortably above the 16 g floor, say 100 g.
2. The robot reports settled — it is not moving and has not moved for at least one second.
3. Nothing has changed for five seconds — no removal, no hand, no impact.

With those three conditions, the auto-zero can only fire on an empty, still, undisturbed tray, which is exactly the only state in which the reading you are overwriting is known to be meaningless. The rule is free, it is entirely yours, and it removes a whole class of customer complaint that would otherwise land on my desk.

The machines that have solved this problem most cleanly are not robots. They are refrigerated cabinets and appliance panels, which have to survive exactly the same argument — a slow thermal drift, a lid opening and closing, and a user who expects the number to be right. The connected home weighing guide and the tank weighing guide both spend most of their length on zero policy rather than on accuracy, and that is not an accident.

8. The three degrees between kitchen and table

A delivery robot has the most varied thermal life of any machine I sell into. It starts in a cold service corridor, passes through a pass where heat lamps are running at 60 °C, waits under a lift’s air conditioning, then stands next to a diner’s table in a warm room. None of that is dramatic. All of it moves the zero, because the zero moves with temperature on any strain gauge cell, and the amount is published in percent of full scale per ten degrees.

Read the digital row against the WST1101 row and you will find the trap in this table, because it nearly caught me. In datasheet units the digital cell is the best part here — 0.002 % of full scale per degree is 0.02 % per ten degrees, two and a half times tighter than WST1101’s 0.05 %. In grams it is not, because the smallest WST1204 I build is a 60 kg cell and the cell it is being compared against is a 15 kg cell: 7.2 g against 4.5 g over the same six degrees. Percent of full scale is the wrong unit when the full scales differ by four. If you buy the tighter specification and keep the bigger capacity, you buy the better datasheet and the worse tray.

Then look at the ratio between WST1101 and WST103, which is the comparison that actually changes a design. WST103 looks like the cheaper, smaller, more appropriate part for a light tray, and mechanically it is. But its zero drifts 5.3× as much as WST1101’s over the same temperature change, and on a 20 kg tray that is 24 g of movement against 4.5 g. If your tray logic is looking for a glass, that difference matters more than any consideration of price. If you only ever need to know “is the tray loaded, yes or no,” it does not matter at all. This is the same trade I describe for coffee machine shot scales, where the quantity being measured is smaller than the quantity drifting.

One honest refinement, because it changes how you should use the table rather than how much you should fear it. Thermal drift has a time constant. A 12.7 mm aluminium beam plus a 1.2 kg tray plate plus a steel frame does not reach a new equilibrium in ninety seconds; it takes minutes. So within a single 90-second delivery, the tray sees only a fraction of the steady-state figure. Across a shift, from a 22 °C morning to a 28 °C lunch service, it sees all of it. That is why the zero policy in section 7 distinguishes between “zero at boot” — which removes the shift-level offset — and “zero on a timer” — which does not help and destroys your differences.

If your robot works across floors, add the lift to that picture. Lift cars are air-conditioned to a different set point than a service corridor, so a multi-floor robot can accumulate a real thermal cycle on every trip rather than once a shift. On the machines I have helped with, this showed up exactly as you would predict: the first deliveries after a change of floor were slightly off, and then everything settled. It was never a sensor fault, and no part change would have fixed it. If your tray is holding a patient’s meal or a medicine tray instead of a restaurant order — the hospital version of this same machine — the tolerance conversation gets stricter and the medical device notes are the better starting point than this article.

9. A plausible number, or no number at all

Every tray sensor I have discussed so far is an analog strain gauge bridge. You power it, it returns a couple of millivolts, and somebody downstream has to convert that into a number. On a bench that is trivial. On a service robot it is the hardest part of the job, and it has nothing to do with the sensor.

Here is what that analog chain looks like on a real machine. Four cells, one per tray. Four sets of signal wires, each a few hundred millimetres long, routed from a tray that moves to a chassis that holds the electronics. Those four signals have to be summed, corner-matched and then digitised, and the digitiser has to live somewhere on the robot. On almost every robot I have seen, “somewhere” is the main electronics bay, which is also where the motor drives are. A brushless drive switching at 20 kHz is a radio transmitter sitting a few centimetres from a 1 mV signal. The cell is innocent. The layout is the fault. When that goes wrong, you get a reading that is plausible and wrong — and an analog cell has no way at all to tell you it is being lied to.

There is a second family of part that removes that entire problem, and it is why I am proposing WST1204 in this article even though it is a bigger, more expensive cell than the tray needs. In a digital cell, the amplifier, the analogue-to-digital converter, the calibration and the protocol stack all live inside the sensor housing. What comes out of the sensor is not millivolts. It is an RS485 or RS232 frame.

It is worth being precise about where the digital cell wins and where it does not, because I would rather you bought the right one than the impressive one.

Two practical notes on the digital route, from projects rather than from the datasheet. First, the digital cell is a bigger part — a 60 kg platform cell is not something you tuck under a single dinner tray, so this is a whole-machine decision, not a per-tray one. Second, because it outputs a number rather than a voltage, your acceptance test changes: you can no longer put a scope on it, so you want the sensor’s own diagnostics and a documented protocol from day one. If you are building the sort of machine where sensors are read over a bus and logged centrally, the same architecture appears in warehouse and AMR weighing systems and in packaging lines, and both of those write-ups deal with the wiring discipline in more depth than I can here.

10. One cell in the middle, or four at the corners

Section 3 was about the tray stack. This one is about a single tray, and it is the question asked immediately after the stack question is settled. There are only two sane answers, and a great many machines are built with an accidental third one.

There is a slower version of the same fault, and it is specific to robots because a robot tray gets removed and refitted constantly. If the tray docks into a bracket with a locating pin, the pin and its hole wear. Over a few thousand cycles the tray sits a fraction of a millimetre differently, which means the fraction of the load going through the bracket versus through the cell changes, which means your zero moves a little every week and your sensitivity moves with it. The symptom is a machine that needed recalibration every service visit and nobody could say why. The fix is to make the bracket idempotent — a taper, a positive stop, a dowel rather than a slot — or to stop having a removable tray in the load path at all.

And the cable. It is the part of a tray system that fails first, it is never in the datasheet, and it is worth a paragraph because it is entirely within your control:

A hundred thousand to a million cycles is the order of magnitude a properly routed multi-strand cable handles at ten times its diameter bend radius, so 270,000 cycles is a design you can ship — but not one you can ship with the cable hanging loose. Everything about tray weighing that goes wrong after eighteen months goes wrong at the cable or at the bracket, and both are cheap to fix on the drawing and expensive to fix in the field.

11. The datasheet promises minutes. The trip is 90 seconds.

Every cell I sell publishes a creep figure, and every one of those figures is quoted over a time base. When I first started quoting these parts to robot builders, I would put the creep numbers in a table and rank them, and I was wrong to do it. Look at what the three analog models in this article actually promise:

Four parts, three different time bases — three minutes, five minutes, thirty minutes. The percentage figures cannot be ranked against each other, because creep is not linear and a part measured over thirty minutes is not being held to a looser standard, it is being described over a longer window. A 0.018 % over thirty minutes is not the same promise as a 0.02 % over thirty minutes in the same way that 0.05 % over three minutes is a tighter restraint per minute. This is the third time in this series that I have had to warn a customer about comparing numbers across my own pages, and it is the reason I now convert everything to grams at the actual dwell time before I let anybody look at a table.

The one place creep does appear on a robot is the case that looks like creep and is not. A tray that reads a few grams heavy for the first ten minutes after a shift change, and then settles, is usually not creeping — it is the tray plate warming up, or the caster suspension taking a set after being parked overnight, or the pass heat lamp doing what heat lamps do. This is why the diagnostic I keep asking for is a tray log with nothing on the tray. Twenty-four hours of an empty tray tells you the entire zero behaviour of the machine: the thermal cycle, the settle time after boot, the effect of the robot going outside, and whether anything is genuinely creeping. I have never seen a customer produce that log and still disagree with me about the cause.

12. Nine questions that pick the cell

These are the questions I ask, in the order I ask them, because the earlier answers change the later ones. The first four decide about eighty percent of the specification. If you can answer them, I can quote you a part and an overload case in the same reply.

Question 9 is the one I will not let go, because it turns the honest frame of this whole article upside down. Everywhere else I have told you the absolute value does not matter. If a robot is weighing food that a customer pays for by weight — a buffet robot that charges for what you took, a self-service machine that bills per hundred grams — then the number is the price, an error in it is a trade dispute, and none of the “threshold and timing” logic in sections 5 to 11 is a defence. That is a different machine with a different legal framework, and I would rather you found that out during specification than during certification.

13. Standards: what applies, what does not

Food delivery robots are machinery, and in Europe the machinery rules changed recently. This section is what the framework looks like from where I sit — which is at the component level, supplying a sensing element. I am not your compliance route and I will not pretend to be, but I do want you to know which documents you are going to be asked for, because the conversation almost always starts with the wrong one.

Two things about ISO 3691-4 that catch people out. First, it is a floor and not a ceiling — it names a list of hazards it does not cover, noise and vibration and explosive atmospheres among them, and your integrator is expected to layer the rest on top. Second, the machine’s CE marking does not cover the site. As soon as your robot calls a lift or drives through an automatic door, that interface becomes a safety question about the building, and somebody has to own it. Neither of those is a load cell problem, and both of them are the reason a tray sensing project can be perfectly specified and still stall for a quarter at the handover.

14. What I supply, and what I do not

The right-hand column is not a list of things I am apologising for. It is the reason the left-hand column is worth anything.

That last row on the right matters more than it looks, because trays and food are in contact for eight hours a day and somebody will eventually ask you about cleanability. A load cell sits behind the tray plate; it is not a food-contact surface and it never should be. If your tray surface has to meet a food-contact requirement, that is a question for the plate material and the supplier of the plate, not for the cell under it. What I can do is tell you what protection the cell itself has, so that washdown and steam cleaning do not quietly destroy the sensing element. Which brings me to something I would rather say here than have you find in a returns report.

15. Questions I get from robot builders

16. Five load cells for food delivery robots I would shortlist

These are the parts I would actually put in front of a food delivery robot builder, with the limitation each one carries stated next to it. When I am quoting load cells for food delivery robots the spread below is what I am choosing between, and if you want a single load cell for food delivery robots rather than four per machine, the digital one is what I would send first. They are not five alternatives to the same question — two of them belong to different architectures, and one of them is a whole-machine decision rather than a tray decision.

One note on that last point, because it applies to the whole list. I can compute the bridge current for WST1101 (1090 Ω, so about 4.6 mA at 5 V) and for WST201 (406 Ω, about 12.3 mA at 5 V) — a factor of 2.7× between two parts that look almost identical on a specification table, and a real consideration on a battery-powered machine. For WST101 and WST103 I cannot, because neither of my own product pages publishes bridge resistance. If you need a defensible power budget for a tray design, ask me for it and I will get it from the factory in writing rather than estimate it for you.

If you want more background before you choose, three of my other pages go deeper on the parts of this problem I have only sketched here: the working-principles guide covers strain gauge construction and why creep and zero drift behave the way they do; the reverse vending guide deals with machines that must decide what arrived, which is the same judgement problem as a tray; and the drone payload guide works through a weighing platform on a vehicle that is far more violent than yours. If your tray is on a street-side machine instead of a dining-room one, the smart bin notes cover the public-interaction overload cases in more detail, and if the machine is portable and gets recalibrated on site, the refrigerant scale selection guide is the closest analogue to a tray that lives on a trolley.

Market figures in this article are drawn from the Worldwide Food Delivery Robots Market study and the restaurant robots market analysis; the Machinery Regulation that the table in section 13 refers to is set out by the European Commission’s machinery pages. Sources differ on market size; the direction is consistent.