Ask Your Question

how ros abstract away the underlying hardware and work with generic messages instead

asked 2017-01-14 22:21:42 -0500

shawnysh gravatar image

updated 2017-01-14 22:23:15 -0500

I read the below passage on book, ROS-by-Example Vol1,CH4.14

Once you get used to this style of programming, there are some significant advantages. As we have already mentioned, many nodes can be reused without modification in other applications. Indeed, some ROS applications are little more than launch files combining existing nodes in new ways or using different values for the parameters. Furthermore, many of the nodes in a ROS application can run on different robots without modification. For example, the TurtleBot follower application can run on any robot that uses a depth camera and a mobile base. This is because ROS allows us to abstract away the underlying hardware and work with more generic messages instead.

I think this situation might only be suitable for something like artibox-powered robot, which is well supported by ROS thanks to packages like artibox_python, other than other controller-powered robot without ros package's support, am I right?

If so, then if I want to build a real robot, do I have to purchase artibox driver or sth like that in avoid to write low-lever code to control servo on my own?

I think I might be wrong because missing some basic concept about how ros controls a real robot in a low-level not a simulated one. Any recommended link? I really want to know more about how the last sentence in the above passage works.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2017-01-14 23:40:57 -0500

ahendrix gravatar image

One example of this happening in the real world is the Turtlebot, where they switched from the Microsoft Kinect (no longer produced) to the Orbbec Astra: . They had to develop a new driver for the new sensor, but once they did, they were able to run all of the existing turtlebot apps like follower, SLAM and navigation without rewriting them.

The general idea here is that ROS reduces the work required to run the same software on many robots.

In the example of the follower app, it can run on any robot with a depth sensor and a mobile base.

If you buy a robot that already has ROS support for its depth sensor and mobile base, the only work you have to do in order to run the follower is to configure the follower app for your robot.

If you buy a mobile base that doesn't have ROS support, and add a depth sensor that has ROS support, you only need to write the ROS node that converts mobile base commands into the specific commands for your base, and configure the follower app.

The point here, and the power of ROS, is that you don't need to rewrite the follower app or the depth sensor driver in either case.

So yes, if you buy a mobile base that doesn't have ROS support, you'll have to add it, but once you do, you'll be able to run existing ROS software like the follower app, SLAM, and navigation.

edit flag offensive delete link more


Very clear explanation! I strongly recommend that this explanation should be added to ROS overview!

shawnysh gravatar image shawnysh  ( 2017-01-15 09:07:14 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2017-01-14 22:21:42 -0500

Seen: 97 times

Last updated: Jan 14 '17