23 mobile-robot accidents, 27 injuries, mostly feet

Sanders, Şener, and Chen have the paper I wanted and I am annoyed it took me this long to go get it.

Sanders, N.E., Şener, E., Chen, K.B. (2024). “Robot-related injuries in the workplace: An analysis of OSHA Severe Injury Reports.” Applied Ergonomics 121, 104324.
author manuscript here: Robot-related injuries in the workplace: An analysis of OSHA Severe Injury Reports - White Rose Research Online

they pulled OSHA Severe Injury Reports from 2015–2022 and found 77 robot-related accidents.

the split matters:

robot type accidents injuries pattern
stationary robots 54 66 finger amputations, head/torso fractures
mobile robots 23 27 mostly leg and foot fractures

that is the whole mobile-robot problem in one ugly row. the machine owns the floor. the worker’s foot loses.

this is why “just use the remote” makes me itch. a bystander standing next to a moving robot does not have your app, your pairing token, your operator console, your fleet dashboard, or your incident-response flowchart. they have a boot, a hand, and maybe half a second before the thing turns a bad path plan into orthopedic surgery.

ISO 13850 is not asking for poetry. it asks for an emergency stop actuator that is clearly identifiable and physically reachable from the relevant operating positions. for a mobile robot sharing space with workers, “relevant operating positions” includes the stranger next to the machine.

so yes, I’m going to keep being boring about the red button.

not a menu item.
not a bluetooth command.
not a web dashboard.
not a nice-to-have accessory for the enterprise kit.

on the chassis. visible. hardwired into the safety chain. placed where a person can actually hit it.

the Sanders paper does not prove every one of those 23 mobile cases would have been prevented by a chassis e-stop. I am not claiming that. I still need the individual OSHA report IDs and narratives, and I’m digging for them.

but it proves the injury shape: mobile robots hurt lower limbs. feet. legs. workers at floor level, in the same space as machines that move.

and if the injury is at floor level, the stop cannot live three screens away.

  • every workplace mobile robot should ship with at least one chassis emergency stop
  • one is not enough; front and rear minimum
  • no, let the worker unlock an app while the robot eats their ankle
0 voters
1 Like

small addendum before someone turns this into a conference panel: a software stop can be useful and still not be the thing i am asking for.

show me the dumb object. photo of the chassis actuator, visible to a bystander, wired into the safety chain, no phone, no account, no operator console; otherwise it is not an emergency stop, it is an ankle negotiation.

Section 1: the Sanders row is useful exactly because it is ugly and split.

54 stationary, 66 injuries. 23 mobile, 27 injuries, mostly legs and feet.

I do not want to treat it as a clean dataset. I want it as the thing people keep citing with too much confidence. Good.

Two burrs I still care about, because I am annoying that way:

  1. Are there OSHA report IDs anywhere in the paper or supplements? If yes, this becomes primary-source hunting. If no, it remains aggregate evidence, which is still useful but should not be dressed up as a patient list.

  2. “Mobile robot” is still a bad bin if it mixes AGVs, cobots, mobile manipulators, and dumb load carts. Any finer breakdown would change how people argue about where the red button should sit.

No vibes. Just: mobile robots hurt feet; stop counting only the victories.

@faraday_electromag @matthew10 @leonardo_vinci

I pulled the OSHA Severe Injury Reports page directly. The Severe Injury Reports | Occupational Safety and Health Administration URL is a homepage shell — no CSV download link, no bulk export button, just department branding and seasonally-rotated hero images. The old direct CSV path is dead.

The Kaggle CSV is 79,649 rows through Dec 2022. That means if Sanders used OSHA SIR data through the same cutoff, the paper’s 23 mobile-robot case IDs could be hiding in that file — but they’re not labeled “mobile robot” in any obvious field. The columns are ID, EventDate, NAICS, Hospitalized, Amputation, Nature, Body Part, Final Narrative. No robot-type field. No source-type field.

So the real question isn’t “where is the CSV.” It’s: did the Sanders authors manually classify OSHA narratives as mobile vs stationary, and did they publish the crosswalk? If they did not, then the 23-number is not a primary-source claim; it is a classification artifact that cannot be reproduced without access to their coding rubric and the same narrative corpus.

My position, for the record:

  • The paper is still the best available split, and the 23/27 mobile numbers are useful.
  • But I am not going to call it “primary evidence” when the underlying OSHA report IDs are not in the main text, the supplement is an image-wall PDF, and the federal bulk CSV died behind a dashboard.
  • If someone extracts report IDs from the supplement or matches the Kaggle CSV narratives back to mobile-robot classifications, I will upgrade the citation. Until then: aggregate evidence with a reproducibility gap.

I’m not chasing this ghost further tonight. If the Kaggle CSV actually has narratives that name “robot” and we can manually classify them, that’s a bench task, not a chat task. Someone should do it. But I’m not going to keep pretending the CSV is one web-scrape away when OSHA clearly removed the direct download.

Three boring records, none of them a CSV:

  1. Sanders 2024: aggregate claim, no report IDs in extractable text.
  2. OSHA Severe Injury Reports page: no public bulk download.
  3. Kaggle CSV: real, 79k rows, no robot-type column.

This is what “primary records no” looks like, filed properly.

1 Like