Robot Operating Sys...
 
Notifications
Clear all

Robot Operating System for the DronebotWorkshop Builders. Part 2

3 Posts
3 Users
1 Reactions
3,939 Views
(@twobits)
Member
Joined: 5 years ago
Posts: 113
Topic starter  

I spent a bit of time yesterday reviewing some of the feedback professors gave about teaching Introduction to Robotics courses with and without ROS.

There seems to be a split opinion. Those with a computer science emphasis generally preferred using ROS. They felt their students could get complex robots up and running in less time. They also stated that it was advantages to use pre-built ROS packages in lab sessions to demonstrate the state of the art theory they were teaching in lecture. Prior to ROS they felt constrained to talk about interesting material in lecture while labs were limited to very simple project.

Conversely, those with a mechanical engineering background preferred to teach without ROS. In general, they felt that too much time was required to prepare students to use ROS and not enough time was spent on the mechanical systems.

No clear winner here.

--

With this in mind, it is useful to take some time to establish foundational knowledge about operating systems from a CS perspective. While the information between Computer Operating Systems and Robot Operating Systems is not directly transferable. A general knowledge of systems will help you understand why ROS developers made the design decision they did.

For someone just getting started Operating Systems provides a good starting point.

I went though the Online course cs 162 a few years ago. Combined with the recommended reading list and poking around a Linux system you can build a good foundation for wrapping your head around ROS.

In a polished system like Linux or windows. You can get by without getting into the head’s of the developers because User Interface (UI) experts study users to understand how they think. The interface is designed for the user’s convenience. ROS is currently “By Developers, For Developers.”

--

One of the most intuitive tools for understanding any system is to study its block diagram.

Block Diagram

courtesy of Alessandro Rubini and Jonathan Corbet, Linux Device Drivers

In mjwhite’s  first build log entry he uses three block diagram to break large parts in to logical components. He can then think in terms of:

1. What does the Block do?

2. What information does the Block need to do what it is designed to do.

In ROS, a block is referred to as a NODE. While the terminology might seem odd, it is based on graph theory https://en.wikipedia.org/wiki/Vertex_(graph_theory) where the fundamental unit of a graph is a node.

The information that passes between NODE is called a MESSAGE. Nodes and Message are the fundamental idea behind ROS. By using nodes and messages, a large complicated system can be split into modules which are composed in logical manner.

You might be saying to yourself, just show me the block diagram for ROS and move things along. The challenge is robotics is new and evolving rapidly. Best practices are still a work in progress. So, Neatly arranged block diagram are still a pipe dream.

ros graph
Block Diagram

Instead of a block diagram ROS uses graphs where the shapes are nodes which do something and the edges (lines) are messages which pass between different node. The result is that ROS is much less well defined. Yet, the underlying premise that each node should be abstracted into standalone entity still stands.

As you can imagine, if you are not careful your graph can quickly grow into a gigantic mess of spaghetti.

To help provide some structure to our graphs I will try to fit each node into one of the following categories:

1. Perception. How the robot uses sensors to learn about its environment.

2. Localization/Pose. How the robot becomes aware of where it is and how its various joints are positioned.

3. Task and Route planning. How the robot determines what it is trying to do and what steps does it needs to do to achieve those goals.

4. Motion Planning and Execution. How the robot should move its various motors to achieve a step towards its goal.

Thus, ROS uses NODES and MESSAGES.

A Node is any component of the robot which needs to communicate with any other component. It doesn’t matter if a node is a physical piece of hardware such as a sensor or if it is an abstract block on a diagram.

A MESSAGE is the basic unit of communication between NODES.

These nodes and messages are combined in various way to create a (hopefully) functional robot.

By way of an analogy, a Node is just a lego building block and a message is how those blocks snap together. Someone who has never built with LEGO would just see a colorful pile of plastic pieces. Someone who has experience building with LEGO would see various sizes and shapes which can be combined to make interesting things.

Editing note. Hopefully everyone is getting plenty of hands on time at the workbench following along with Bill’s build. Mjwhite's build thread provides a good example of using ROS in practice. I will continue building a theoretical foundation so that if and when you are ready to try ROS you will have enough knowledge to understand the tutorials on the ROS wiki.

The next sections will focus on simple node graphs for DB1 type robots.


   
Quote
(@mjwhite)
Member
Joined: 5 years ago
Posts: 34
 

This is an excellent overview of ROS that helps you decide whether or not it's right for you.  When I first started learning ROS I spent hours drawing block diagrams to try and get a perceptual understanding of the software.  Even though I worked for over 30 years as a software developer, much of it on Linux, it still took me some time to learn.  So I can definitely understand the hesitation for using it.  That said, I still believe that if you're in the robotics game for the long run then you should definitely take the time to learn ROS.  twobit's articles are very helpful to that end.


   
ReplyQuote
Robo Pi
(@robo-pi)
Robotics Engineer
Joined: 5 years ago
Posts: 1669
 
Posted by: twobits

There seems to be a split opinion. Those with a computer science emphasis generally preferred using ROS. They felt their students could get complex robots up and running in less time.

For me, the key issue here is the phrase "Complex Robots".  I can certainly see where they are coming from and they may very well have a good point within the framework of that context.   However, I personally feel that this may be a bit beyond the scope of Bill's intended audience for his series on DB1.  I'll explain more below.  And of course Bill may have a different perspective on this.

Posted by: twobits

No clear winner here.

For me there is a clear winner, and that is that both camps are winners relative to their intended purpose.

Computer Science emphasis appears to me to be focused on getting programmers up and running quickly on robots that are already complex.

The Engineering emphasis appears to be more focused on designing from the ground up.  Which is what Bill is doing for us with DB1.   So I would take the Engineer's perspective relative to the DB1 project.  This is not to say that the Computer Science emphasis is wrong.  It simply may not be practically applicable, or even necessarily beneficial for the purpose of the DB1 tutorial.   Again this is just my perspective on these issues.

Posted by: twobits

To help provide some structure to our graphs I will try to fit each node into one of the following categories:

I like the categories you have listed and see where that type of organization of things can be beneficial whether using ROS or not.

Posted by: twobits

Editing note. Hopefully everyone is getting plenty of hands on time at the workbench following along with Bill’s build. Mjwhite's build thread provides a good example of using ROS in practice.

It's my hope that Bill will continue the DB1 project without depending on ROS.   This way we can see the differences between how Bill accomplishes a final result versus how ROS might be used to do it.  Seeing that contrast would itself be quite informative. 

I'm going to post this without a preview button, so stand back.  It's hard to say what might happen. ? 

 

DroneBot Workshop Robotics Engineer
James


   
hstaam reacted
ReplyQuote