Is one slow weeding pass better than several fast ones, and does treating on the move change that?
research/osrobot-weedpass
A laser-weeding robot that drives three fast passes (4 km/h) kills 0.780 of the weeds in 75 min, against 0.607 in 83 min for one slow pass (1 km/h), and treating on the move instead of stopping cuts time by 6% at 0.3 weeds/m² and 39% at 3 weeds/m²; the ranking survives 30% of weeds being invisible to the detector
What it found
osrobot-fieldreal left two next steps: a second pass over missed weeds and treating on the move. This project adds both to its sourced-constant weeding model (2 m swath, 0.73 s per weed, 99.2% kill from laser-weeding literature; 60×30 m field, 20 seeds per row). At 1 weed/m², three passes at 4 km/h kill 0.780 of the weeds in 75.1 min, against 0.607 in 82.8 min for one pass at 1 km/h; two passes at 2 km/h reach 0.778 in 90.5 min. Because the assumed detector loses hits as speed rises, the second pass recovers more than speed costs. Treating on the move rather than stopping cuts time by 6% at 0.3 weeds/m² and 39% at 3 weeds/m² (1 km/h) with identical kill, and is bounded by laser throughput at 10 weeds/m². If 30% of weeds are never seen by the detector, kill falls (three passes at 2 km/h: 0.894 to 0.627) but the pass-count ranking is unchanged. Stylised and preliminary: detector hit rate (0.7, swept 0.5 to 0.9) and blur law, false positives, mud, energy per metre and beam steering are assumed; passes are independent except for the swept hidden share; no weed-density source was found; simulation only.
A figure from its own output
Paper, code and results
More in Open-source purpose-built robots
- Do several fast laser-weeding passes still beat one slow pass when the detector's hit rate comes from published field trials?With a detector fitted to two published field detection rates (88.9% at 0.2 m/s, 86.2% at 0.425 m/s), two laser-weeding passes at 4 km/h kill 0.952 in 40 min against 0.875 in 68 min for one pass at 1 km/h; the ranking holds, and the share of weeds the detector never sees (3 passes cap at 0.897 with 10% hidden) now sets the ceiling
- When does a purpose-built gantry beat a general two-link arm at tray pick-and-place?When does a purpose-built gantry beat a general two-link arm at tray pick-and-place? At 2 mm tolerance the arm wins only between 0.36 and 0.99 m of work area, and the band depends on assumed costs (stylised).
- Does co-designing an arm's link lengths and controller beat tuning the controller on a fixed body?Does co-designing an arm's link split and controller beat tuning the controller on a fixed body? Co-design gained 1.9% in held-out move time (0.283 against 0.289 s), within three-seed noise; tuning the controller mattered about 37%. Stylised, preliminary, mostly negative.
- Can a small twin of a liquid-handling bench catch protocol errors before they run, and how much pipetting error does a serial dilution tolerate?Can a small twin of a liquid-handling bench catch protocol errors before they run, and how much pipetting error does a serial dilution tolerate? It flags 366 of 522 injected faults against 100 for a syntax-only baseline, and an assumed error curve gives a final-well CV of 0.187 at 10 µL and 0.035 at 100 µL transfers (stylised, circular fault set).
- Does the real Opentrons simulator catch the protocol faults a small stdlib liquid-handling twin catches?Does the real Opentrons simulator catch the faults the stdlib liquid-handling twin catches? On the same 522 seeded faults it raises on 270 and the twin flags 366; everything the simulator catches the twin catches too, while tip reuse, a 5 µL dispense and a half-empty source pass the simulator. Mostly policy differences; the fault set was written for the twin (stylised).
- Does searching an arm’s joint count, link lengths and mount, with its controller tuned in the loop, beat a fixed three-link body at the same cost?Does searching a planar arm's joint count, links and mount, with its controller tuned, beat a fixed three-link body at equal cost? On a shelf task with a tool-down constraint, 0.95 held-out success against 0.26; on a long position-only reach, no gain (stylised, kinematic).
All 44 Open-source purpose-built robots projects →
Other research topics
Proper scoring & elicitation28Effort & peer prediction9Verification games & slashing19Detection & tolerances14Markets as routers13Prediction-market design9Paying contributors8Decentralised training systems23Digital twins & sim-to-real164LLM chip design loops40Robot manufacturing loops53Ambient AI assistant46Self-replicating manufacturing34Simulation-first design64Engineered clothing45Task-specific AI accelerators40Algorithmic chip-design loops42Open-source purpose-built robots44The software-engineering loop43Adversarial human imitation41Open-source residential construction41Autonomous multi-angle capture34Sensing, imaging and 3D31Energy supply and dense energy storage39Robot societies among people31Agentic co-design of low-cost robots27Laundry-hanging robots25Machine learning on qualitative data23Robots on the building site27Civilizations & group psychology1History & human sciences1
Produced with AI assistance (Claude). Results are from the code in this repository and are simulated or stylised unless the abstract says otherwise; nothing here implies affiliation with or endorsement by any lab, researcher or company cited. MIT licensed.