The Mythical Non-Roboticist

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.