Robotics and ROS 2 Essentials

Original Article ↗ Hacker News Discussion ↗

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.