$100 robot kit running ROS2 and Navigation2

So, if you really want to learn ROS, I recommend the classes at the Construct (no affiliation): https://www.theconstructsim.com/robotigniteacademy_learnros/... While not “free”, they have been the best I found to date.

That said, as said elsewhere, you should ask why you are trying to learn ROS. For research and academia, it’s great as you get a solid collection of tools/tooling that mostly works out of the box.

However, when looking at creating a product from it... think through the benefits. Much like any framework, even if there is no “cost”, there will always be a real cost in dealing with its complexity. So think through your use case, and design to that.

What are the opportunities for a UI/UX designer, willing to work on improving ROS? It semms to be in pretty terrible state tbh.

(Disclaimer: I contribute to ROS in my day job) As someone who has been working on ROS for a living and spent the past 3 years in research labs ROS does seem very scary. The ROS website itself is in need of an overhaul with better tutorials. Part of the reason why a beginner coming in may also get lost is that there are many very advanced tools and libraries for concepts which are foreign to software engineers. Take the TF library for instance which you mention - its goal is to calculate transforms, but unless you are deep into robotics you may find it difficult to understand why it is used in so many places. The fact is ROS provides an extremely comprehensive set of APIs, but why those APIs are useful is not immdiately clear unless you actually build robots.

If you are an absolute beginner here are some tips:

The core of ros is a message bus. Its aim is to provide a messaging layer, not unlike what one would get with mqtt. However, ros's message bus has been designed to be distributed and quite frankly has better performance than mqtt on an edge device. It also has a good set of tools that allows you to visualize errors.

Each ros program is called a node. Think of it like microservices. Why do we do this? Well first of all it provides modularity so we can swap out components. It also provides a certain amount of resiliency to your robot. So suppose one node on your robot dies, the whole thing will not come crashing down.

In addition to the ros messaging bus, there are tools like rosbag, which provides users with a super simple way to log sensor data and share it across runs. There are also tools like rviz which help you visuallize the robot's data. These tools are very useful when you are dealing with 3D data coming from LiDARs or depth cameras, however it probably is not needed when your robot is a simple line follower.

Once your familiar with these you should look at the TF library which deals with transforms. Transforms are central to robotics however it does take time to get a good grasp on them. At this point I recommend you take some MOOC to help fill the gap in knowledge.

MoveIT! is designed for robots with multiple joints like robot arms.

For wheeled robots and obstacle avoidance you probably want to look at move_base and nav2 packages. Movebase is the old package for obstacle avoidance on ground robots. It is a bit of a pain to work with. I strongly recommend you use Nav2 instead which is far superior and better documented and the successor to move_base.

tl; dr: Robotics is hard. There is no royal road to it.

I agree from my own painful experience, which makes the OP more impressive. I once tried to get the navigation stack running on a raspberry pi based robot to test out a gps driver, and was shocked that I had to include massive libraries for lidar and point clouds that I had no intention of using to get anything to build. In the end everything ran but the nav stack ate up so many resources that my robot wasn’t able to move reliably.

Another perspective on the question "what is ROS?", having worked with countless ROS nodes:

In a nutshell, ROS is a library that allows you to send and receive messages.

The two most used methods in the API are Subscriber.subscribe(message_topic, callback) and Publisher.publish(message)

For example, a sensor driver will publish a message containing a camera image, then a node will receive a message, detect the people in it, and send another message with their positions. Another node will receive the positions message and calculate a desired action, and send that as a message. You can write your own node which captures any kind of message and publishes any other kind, making things very modular.

So ROS also contains a million tools to help you process the messages, for example the Time tools allow you to set timers and convert time stamps, the rosbag tools allow you to store the messages and replay them later, the tf tools allow you to transform geometrical objects between message reference frames, and so on...

Many of the tools do their job well, the main issue is documentation. In some cases, the best way to figure out what can/should be done is to look at existing code.