The Mythical Non-Roboticist
Robotics engineers argue that the real barriers to broadly useful robots aren’t just mechanics or control algorithms, but messy perception, unreliable hardware, and the “low‑code fallacy” — the belief that non‑experts can safely program complex systems via simple interfaces. Commenters describe how real-world variability, brittle vision systems, and convoluted vendor APIs make even “simple” tasks like picking and putting away objects extraordinarily hard to generalize. Many see recent advances in AI and computer vision as helpful but far from solving the core problem of making robots as robust, intuitive, and dependable as human workers.
Core challenges in robotics
- Multiple commenters echo that the true hard problems are perception and funding, with jokes adding “cables/connectors/fasteners” and supply chain.
- Planning/control often fail visibly, but root causes are usually perception errors or violated world assumptions.
- Even basic notions like “object” or “put away” are seen as far from being solved in a robust, general way.
Perception, vision, and real-world messiness
- Real-time tracking of specific object instances across video frames, under varied lighting, fog, occlusions, and fast motion, remains brittle.
- APIs/models that “work most of the time” are considered insufficient once safety, reliability, and risk are analyzed.
- Simple-sounding tasks (e.g., “put away the towel”) blow up under edge cases, ambiguity, and occasional catastrophic misclassification.
- Debate on progress: some argue computer vision and depth sensing have improved dramatically (smartphone-level CV, LLM+video), others say state-of-the-art is still not “good enough” for general robots.
Low-code / non-expert programming fallacy
- Many see “robots for non-roboticists” as another instance of the low-code fallacy: complexity is in the domain and problem formulation, not syntax.
- Once someone is writing meaningful robot or analytics logic, they are effectively a roboticist/programmer; attempts to hide this usually fail or become opaque proprietary systems.
- Parallel drawn to test automation and data tools: “make it simple” often really means “make it intuitive,” which is hard without exposing real complexity.
Robotics vs automation and human benchmarks
- Industrial robots that do one repetitive task well are framed as “automation,” not the hard part of robotics.
- Multistep, flexible assembly tasks at a higher abstraction level are still unsolved in a way that end users can specify easily.
- Robots are constantly benchmarked against humans, who are far more adaptable and fault-tolerant, making robots seem worse even when they provide value.
Industry reality and APIs
- Working in robotics involves significant time on debugging, vendor issues, and fragile hardware; many field failures trace to cables or sensors.
- Salaries are often modest and dominated by early-stage startups; good if motivated by interest, not optimal for money or mobility.
- Poorly designed APIs from hardware vendors and overcomplex robotics frameworks are common pain points; commenters endorse APIs designed for smart but impatient users.