Robotics and ROS 2 Essentials

Original Article ↗ Hacker News Discussion ↗

Robotics engineers and hobbyists weigh the value of learning ROS and ROS 2, noting that while these frameworks are deeply entrenched in academia and useful for rapid prototyping, they are often brittle, overengineered, and problematic in production at scale. Commenters describe ROS as a “good enough” standard for research that provides messaging, simulation, and robotics algorithms, but emphasize that many successful companies either wrap it with thin layers or eventually replace it with custom stacks using tools like gRPC, DDS, or other pub/sub systems. The thread also explores robotics as a career path—highlighting strong long‑term demand, the importance of specialization (e.g., perception, controls, mapping), and the tradeoffs between formal programs like a CMU robotics master’s and self‑directed learning with cheaper hardware.

Robotics Career & Education

  • Robotics is seen as a strong growth area over the next 10–15 years: automotive, defense, manufacturing, and space are cited as big drivers.
  • An MS in robotics (e.g., CMU) is described as very practical and hardware‑rich, with exposure to many topics not covered in a CS PhD.
  • Some argue a motivated PhD can self‑teach from books and used hardware; others say access to facilities and diverse platforms is hard to replicate.
  • Specialization is emphasized: systems, vision, controls, tracking, mapping/prediction, planning, proprioception/exteroception, and simulation are suggested tracks.

Value of ROS Experience

  • Multiple commenters say ROS experience is important for getting into robotics; even companies with custom stacks find ROS concepts transferable.
  • ROS is framed as a lingua franca that helps understand other frameworks and industry design decisions.

ROS/ROS2 in Production vs Prototyping

  • Broad agreement: ROS is very useful for research, teaching, hobby projects, and early startup prototyping.
  • Many report painful experiences using ROS/ROS2 in production: scaling issues, performance problems, networking brittleness, and heavy build/deploy pipelines.
  • Common pattern: thin ROS layer on top of a non‑ROS core, or starting with ROS then planning a migration off once products ship.

Technical Critiques of ROS/ROS2

  • Complaints include:
    • Multiple custom build systems (rosbuild, catkin, ament, colcon) on top of CMake; long builds and complex tooling.
    • Overuse of network pub/sub for everything, including control loops; adds latency, non‑determinism, and debugging difficulty.
    • ROS1→ROS2 discontinuity and “regressions” (e.g., ROS2 launch system).
    • Message IDL and APIs seen as weak for versioning and expressiveness; algorithms often tightly coupled to ROS types.
    • ROS2’s approach to multi‑package builds criticized as harming parallelism.

Alternatives and Custom Stacks

  • Many companies reportedly build in‑house frameworks using:
    • Pub/sub or RPC primitives (DDS directly, ZeroMQ, zenoh, gRPC, custom shared‑memory systems).
    • Message formats like protobuf, flatbuffers, CBOR, JSON, or raw C structs.
  • Example tools mentioned: Foxglove (can be used without ROS), PlotJuggler, nvblox, MRPT, YARP, OROCOS, and newer Rust‑based frameworks (Copper, Dora, Basis, RoboPLC).
  • Advice: if you know ROS, it’s easier to design and implement your own better‑fitting stack.

Beginners, Teens, and Learning Paths

  • Several warn ROS/ROS2 is too heavy and frustrating for most teenagers; recommend Raspberry Pi + Python‑based robots instead.
  • For SLAM learners, suggested approach: use existing back‑end libraries (g2o, Ceres), focus on sensor choices and front‑end, rather than reinventing everything.
  • For broader “real‑world” robotics understanding, industrial expos, mechanical engineering concepts (materials, actuation, manufacturing), and hardcore SDKs (e.g., NVIDIA) are recommended.

Governance and Community Concerns

  • One thread discusses perceived poor governance and groupthink in the ROS community, especially around build systems.
  • A counterpoint claims moderation actions are due to repeated code‑of‑conduct violations, not suppression of criticism.
  • Overall, governance quality and future direction (including the Google/Intrinsic acquisition) are raised as concerns but remain unresolved in the thread.