u/RoboticSir_official

I've been thinking about how beginners should approach robotics today.

There are so many ways to start — Arduino, ESP32, ROS 2, simulation, computer vision, Python, C++, CAD, sensors, and now AI tools. The amount of available material is almost overwhelming.

A common path seems to be:

Arduino → basic sensors → line follower → obstacle avoidance → ROS → bigger projects

But I'm not sure there's one "correct" progression.

For someone starting robotics from scratch, would you recommend learning things in a specific order?

For example:

- Start with electronics and microcontrollers?

- Learn Python/C++ first?

- Build physical robots immediately or start in simulation?

- Learn control systems and PID early?

- Move to ROS 2 only after understanding the basics?

- Learn computer vision separately or integrate it into projects?

- Use AI coding tools while learning, or avoid them initially?

I'm especially interested in the transition from following tutorials to actually solving problems independently .

At what point should a beginner stop following step-by-step projects and start designing their own?

And if you had to start learning robotics again today , what would you do differently ?

I think the biggest challenge isn't finding tutorials anymore — there are thousands of them. It's figuring out which skills to learn first and how to connect them into real projects .

What learning path worked best for you?

I've been thinking a lot about the sensor integration layer lately. It feels like one of the biggest, unspoken bottlenecks in robotics development.

On one hand, we have the dream of a clean, unified API. Imagine writing a sensor driver once, for a standard interface, and having it work seamlessly across your entire robot, whether it's running ROS 2, a custom DDS-based system, or something else entirely. The appeal is obvious: faster development, easier collaboration, and less vendor lock-in.

On the other hand, the reality is messy. The push for low-latency, high-bandwidth, and deterministic performance often pushes developers towards hardware-specific, highly optimized code. This is where proprietary stacks and tightly-coupled DDS implementations thrive. The "ideal" universal API can sometimes feel like it adds an abstraction layer that just isn't acceptable for a critical sensor on a fast-moving robot.

So, where does that leave us? Are we destined to keep juggling a half-dozen different driver formats and middleware solutions? Or is there a path to a de facto standard that respects both the need for open standards and the hard requirements of real-world performance?

What's your experience? Are you buried in custom drivers, or have you found a workflow that feels reasonably unified? Is the fragmentation a minor annoyance or a major time-sink?

I'm genuinely curious to hear how different people are tackling this in their own projects.

I've been looking into humanoid balancing and keep coming back to the difference between traditional model-based control and learned policies.

With inverse dynamics, you have a pretty clear model of the robot, its dynamics, contact forces, and how the joints should respond. The advantage seems to be that you can reason about why the controller is doing something and have more predictable behavior.

Learned policies are interesting for a different reason. Instead of explicitly modeling everything, the policy can learn how to react to disturbances and potentially handle situations that are difficult to capture accurately in a hand-designed controller.

But I'm curious about the practical trade-offs.

For something like a humanoid dealing with uneven ground, external pushes, or changing payloads, which approach actually works better in practice?

Is a learned policy eventually going to outperform model-based inverse dynamics, or does a hybrid approach make more sense — using physics-based control as the foundation and learned policies for the parts that are difficult to model?

I'd be interested to hear from people who have worked with humanoid control, whole-body control, MPC, inverse dynamics, or reinforcement-learning-based locomotion. What have you found works reliably outside of simulation?

I've been thinking about where the transition happens between following a robotics tutorial and actually being able to build something independently.

A lot of beginner projects follow a familiar path:

• Build a line follower
• Avoid an obstacle
• Control a servo
• Read a sensor
• Follow a step-by-step tutorial
• Upload the provided code and watch it work

There's nothing wrong with that — everyone starts somewhere.

But at some point, you need to move from “I can make this work when someone shows me how” to “I can figure out why this isn't working and decide what to do next.”

I'm curious where you think that transition happens.

For example, should a beginner be able to:

• Debug a sensor that produces noisy or inconsistent readings?
• Choose their own components instead of being given a parts list?
• Tune a PID controller without being given the values?
• Combine multiple sensors and decide how to use their data?
• Write the software architecture themselves?
• Diagnose why a robot behaves differently in the real world than it did in simulation?
• Read a datasheet and figure out how to use an unfamiliar component?
• Modify an existing project rather than starting from a tutorial?

What was the first robotics project where you felt like you weren't just following instructions anymore?

What made that project different?

Was it the difficulty, having to debug something yourself, making your own design decisions, or simply having a problem where there wasn't already a tutorial telling you exactly what to do?

I'm especially interested in hearing from people who learned robotics primarily by building and experimenting, rather than through formal coursework.

I think there's a big difference between completing a robotics project and learning how to solve robotics problems — and I'm curious where you think that difference starts.