[rck]

Get an arduino kit and learn a little electronics. The kit likely comes with a brushed motor and a servo. Learn how motors works and how to write code to make motors spin. Then get a stepper motor and an arduino-compatible motor shield or CNC shield and spend some time getting multiple motors to move. Once you understand those basics, you can hook motors together in a rigid frame and you have a robot (2 motors with wheels is mobile, 3 or 4 motors with links is an arm). The kit will also come with some simple sensors which you can use to do things like measure light and distance, which you can use to start playing with feedback control (look up Braitenberg vehicles for a project idea).

Seconding all the people who said avoid ROS - it's not worth the effort for hobby-level stuff. It's barely worth the effort for "professional" robotics.

Also don't worry about physics too much - build your physical intuition by playing with working systems of increasing complexity.

[dmonitor]

I'd also suggest starting with Arduino, but also recommend moving towards STM32 for doing more advanced stuff. The hardware abstractions Arduino imposes can get really annoying once you start doing more advanced timing dependent stuff.

[jacquesm]

Before you run into the limitations of the Arduino platform you will likely have decided to make this your career. You can get very far with very little in that world and Arduino's are incredibly powerful for their size and cost and there are many pin compatible options available if you want to scale up within the platform. Once you hit the wall on that you will have to change the toolchain but by then you will be building extremely complex stuff.

[irishcoffee]

Nth-ing the ROS thing. That garbage needs to gracefully back itself into a pool of lava.

[rck]

The thing that most people don't appreciate is that ROS was co-designed with the PR2, which had a very idiosyncratic architecture: two separate computers in the base, ethercat for comms, not at all modular, and very high end parts (for 2010ish). Most of the weirdness of ROS looks less weird in light of the design of the PR2, and most of the evolution of ROS was to get away from the PR2 model for more general platforms.

If you were in robotics prior to 2010, you probably would have used something called Player/Stage (by some of the same people who developed ROS). Believe it or not, another big motivation for ROS was solving the (many) problems that popped up as people tried to get Player/Stage running with robots like the Pioneer 3-DX.

[Xmd5a]

I'd enjoy if someone could elaborate, in the style of Erik Naggum ideally.

[the__alchemist]

It is wild to me out the embedded engineering and robotics communities are isolated. Robotics includes mechanical engineering not part of embedded, but it seems the tools, outlook, and approaches between the two are different.

Starting, but not limited to a "T".(ROS: Robotics community; RTOS: Embedded community)

Involving anything managed by a GPOS (e.g. Linux) in robotics is something I would use with extreme caution, and for limited cases like a CV module.

[Teknoman117]

As someone who works in the datacenter hardware / system software space who does robotics as a hobby - the craziest thing to me about ROS is how tied it is to Linux and how Linux-illiterate half the people using it seem to be.

It was like pulling teeth trying to explain to someone that they couldn’t use the Linux GPIO subsystem from python to accurately measure sub-millisecond events…

Linux is a general purpose OS, it’s typically tuned for throughput not precise timing. Sure there’s PREMPT_RT but it only buys you so much.

[globalnode]

good advice, im yet to take the plunge into robotics but it seems like the way you make things move is with motors so best to learn about those, how to power them, how to control them, then stick a bunch of them together in a coordinated way and you have a robot!