Notifications
Clear all
Topic starter
2019-06-29 9:22 pm
While mowing the lawn I was thinking about what I wish I knew when I start learning about ROS. This is a first draft of the first section, History and Evolution.
I have a second section drafted in my head that might help clarify the theoretical goal of ROS for new users.
As alway, If people find this type of article a useful addition to to forum I can continue...
--
If you are into building robots, an often talked about but little understood topic is the Robot Operating System (ROS). One of the current challenges for learning about ROS is that most people who write about the system spend much of their life developing it. Their perspective and language is a bit different that of a robot builder.
In this article I will try to describe the Robot Operating System(ROS) in terms of a Computer Operating System (OS).
An operating system is often the most complex part of a modern computer. When working smoothly the OS is nearly invisible to most users. As a result they take it for granted. When something goes wrong, it takes a deep understanding of how different systems within the computer interact to identify and fix the problem.
--
First let’s look at the evolution and goals and of a computer Operating System. From there we will look at how ROS is evolving in a similar manner.
In the 1940 and 1950 computers were rare and unique enough that software was written to do a specific task on a specific set of hardware. As customers realized that they were spending a significant portion of their budget rewriting software to do different task, they started to identify commonly used code to interact with IO devices and memory.
In the early 1960s, IBM created System/360 which provide access to common OS services across their entire product line. Over the next several years many different players tried to create a competitive edge for their company by creating the best Operating System which was tied to their hardware.
As knowledge of Computer Operating Systems grew they began to provide a similar set of services.
1 Program execution
2 Interrupts
3 Modes
4 Memory management
5 Virtual memory
6 Multitasking
7 Disk access and file systems
8 Device drivers
9 Networking
10 Security
11 User interface
Customers pushed the next phase of Operating System development. They wanted a way to run their user level software on any of their equipment without rewriting. In the late 1970 modular ‘UNIX’ based systems allowed customers to run on various systems by recompiling it using various flags.
This trend has continued for the last several decades. Hardware manufactures design their equipment to work with one of more of the common Operating Systems. Users don’t need to worry about what hardware they are running as long as the OS supports it.
-
Robotic systems are evolving much like computer systems. Early models were often created and programmed as single units in a laboratory.
The most common robots today are expensive devices used for very specific manufacturing tasks. Once set up, a robot will often perform the exact same task for years if not decades.
Manufactures prefer to have total control over how their robots run. It is both cheaper for them to develop the software and it ‘locks’ the customer into their particular software and hardware.
Customers are starting to squawk. Ideally they would like to pick and choose between various hardware vendors. They would also like their engineers to be able to transfer their knowledge between various vendors. They would like to run the same software across all the devices.
Autonomous vehicle developers don’t want to be locked into a specific brand of hardware. They want to pick the combination of sensors, motors, controllers, and processor which work best for them.
An example of this can be seen in the various DARPA challenges. The high performing robots are rarely from the big vendors. The winners are smaller teams who are free to pick and chose the most suitable sensors, actuators and processor for the task. The winning teams are able combine them into a system which can run the most effective algorithms.
It is interesting to see which DARPA Challenge winners use ROS, which write their own framework and which create bespoke software for each individual robot.
In the current evolution there are pros and cons for each approach with no clear favorites.
Development of both Computer Systems and Robotic Systems were initially driven by the hardware. Over time the importance shifted to the software. For computer systems, the goal has been for software developers to run their code on a wide variety of hardware with little to no intervention on their part. Robotic systems are still in the early stages of that evolution.
2019-06-29 10:09 pm
Excelent!!! Please, please continue your essay. Thiss is the information about ROS that most people need to help them understand the promise of ROS. We talk about ROS as if it will make bulding robots easier. While this is true, it is so only in conjunction with the development of APIs, device drivers, and other hardware/software devices/services. As you succently described, it is this supporting development that made application development in modern computer OSs. This is necessary, in the robotics arena, before we can realize similar ease of development. Interestigly (to me anyway 🙂 that we speak of ROS as I remember speaking of CPM. There are likely to be many more robot OSs in the near future.
Thanks again. Dale
--
Dale
2019-06-29 10:28 pm
If you are using ROS on a robot system and could give a concrete example of where it came in useful, that would certainly be educational. Nothing educates better than a concrete example. ?
DroneBot Workshop Robotics Engineer
James
2019-06-30 2:55 am
I started playing around with robotics about a year ago and my first thought was that maybe there’s an operating system for that? I soon came across the Robot Operating System and have made it the basis for all of my projects since then. I have the ROS server installed on a Raspberry Pi with Ubuntu Mate, and use the ROS Arduino library on ESP32 processors. I prefer the ESP32 for projects since it has much more power than an Arduino for the same price, plus built in WiFi. ROS comes with a robust publish and subscribe protocol for communicating between controllers and robots with every data structure that you’d need for robotics. There are dozens of libraries to perform robotic manipulation and mobile navigation, or almost anything else that you’d need to do. I really encourage you to continue your articles since I think it would be of great benefit to this forum. I’m already a big fan of ROS and would like to find out how other hobbyists are using it.
2019-06-30 4:20 am
I soon came across the Robot Operating System and have made it the basis for all of my projects since then.
Could you share a specific concrete example of how you used ROS in one of your robot projects?
DroneBot Workshop Robotics Engineer
James
Topic starter
2019-06-30 6:07 am
Thanks for the feedback.
As you can probably see, I have felt there was a need for this type of robotics web resource for awhile. I am more than willing to add content to help foster the notion of community contributions in addition to Bill's work.
I'll try to add a 1000 word section every week or so. I am still learning so providing a context for what ROS does and does not do is a useful exercise for me as well. Please correct me if you see any mistakes or additions.
@robo-pi the challenge with trying to provide an example without any context is that the terse commands make almost no sense. For example
$ roscore
$ roslaunch turtlebot3_bringup turtlebot3_robot.launch
$ export TURTLEBOT3_MODEL=${TB3_MODEL}
$ roslaunch turtlebot3_bringup turtlebot3_remote.launch
$ rosrun rviz rviz -d`rospack find turtlebot3_description`/rviz/model.rviz
That was the first part of yesterday's project 🙂 The goal yesterday was to bring up the turtlebot and control its movement with the arrow keys from a remote keyboard.
Today, I am hoping to get the lidar to start spinning and test various models for viewing the local environment with Rvis the visualization tool.
I was kind of thinking that a good way to take this aspect of the project forward would be to develop a ROS version of DB1 in parallel with Bill's version.
2019-06-30 10:46 am
I was kind of thinking that a good way to take this aspect of the project forward would be to develop a ROS version of DB1 in parallel with Bill's version.
That would be great. Then we could not only understand what ROS is used for but we could then also see how Bill is accomplishing similar tasks without ROS.
DroneBot Workshop Robotics Engineer
James
2019-07-01 12:28 am
I'm using the Robot Operating System for a two-wheeled robot project that uses the ESP32 as its controller. I have ROS installed on a Raspberry Pi with Ubuntu Mate. I do all of my development with the Arduino IDE which includes the ROS library for Arduino plus some ESP32 specific libraries. There are several online tutorials that show you how to setup the Arduino IDE for ROS. In order to connect to ROS you’ll need to specify the network address of the machine on which the ROS server is hosted (the Raspberry Pi in my case) together with the port that it’s listening on. You also have to create a node handle to manage the connection between your control program and the ROS server. I won't go into detail about setting up the ROS server since there's detailed documentation on the ros.org website.
#include <ros.h> // RaspberryPi host address. Default ROS port is 11411 IPAddress server(192,168,0,ROS_HOST); // Set the ros server IP address const uint16_t serverPort = ROS_PORT; // Set the ros server port // Define the node handle to roscore ros::NodeHandle nh; bool nodeHandleCreated = false;
I then include the ROS message type Pose. The format of the Pose message looks like this:
It has two sets of parameters for passing position and orientation. For a wheeled robot you only need to use three of these parameters: position x, y, and orientation y. This will form the command vector for requesting a new reference pose. The reference pose is the final position and orientation that you want the robot to end up in. The pose error vector will hold the difference between the robot’s current pose and its reference pose.
// Include the Pose message
#include <geometry_msgs/Pose.h>
// Define a variable to hold the Pose message
geometry_msgs::Pose pose_msg;
// Subscriber definition
ros::Subscriber *sub_pose;
// Create vector to hold the command input
// X position, Y position, Orientation
float refPose[3] = {0.0, 0.0, 0.0};
const byte X_POS = 0;
const byte Y_POS = 1;
const byte PSI = 2;
// Error vector for control feedback loop
float poseError[3] = {0.0, 0.0, 0.0};
// Set callback flag
bool commandCalled = false;
In the setup() you first have to connect to WiFi. The way in which you do this is dependent on the micro controller that you’re using so I'll just put a function here. I then initialize and start a node handle that manages communication with the ROS server. The ROS server is a publish/subscribe protocol (basically the ROS version of MQTT). It has a very rich collection of data structures, called message types, that you can use within topics. The Pose message that I described earlier is just one of these message types. A subscribed topic holds the message that your program is interested in.
When you subscribe to a topic you need to provide a callback function to process the received message. In my case, the message is a command to move the robot to a new position and orientation. After subscribing to the pose command topic I create an instance of a two-wheeled robot. This is a C++ model that implements all of the functionality of the robot. The code I’m showing here is just the program to control the robot. The model is a work-in-progress and I intend to build on it over time to make it a fully autonomous wheeled robot. Right now the model just implements the code for motion control.
//--------------------------------------------//
// Setup
//--------------------------------------------//
void setup() {
// Connect to WiFi
connectWiFi();
// Initialize the ROS nodehandle.
nh.getHardware()->setConnection(server, serverPort);
// Starting node
nh.initNode();
nodeHandleCreated = true;
delay(1000);
// Setup subscriber with callback function to receive the command
sub_pose = new ros::Subscriber("/pose_cmd", commandCb);
nh.subscribe(*sub_pose);
// Create a robot. Pass the ROS node handle.
robot = new TwoWheeledRobot(&nh);
}
The callback function receives a message to move the robot to a new position and orientation. I get the robot’s current pose and add the new reference pose to it. This is used within a control loop to apply power to the motors to move the robot. A flag is set to tell the main loop that a command has been received. The ROSLOGx lines are home grown debug statements that print out to the ROS console. If anyone is interested in how these are implemented please let me know.
//--------------------------------------------//
// Command callback
//--------------------------------------------//
void commandCb( const geometry_msgs::Pose& cmd) {
// Print the new pose command message to the ROS console
ROSLOGString("Received X, Y, Psi");
ROSLOG3F(cmd.position.x, cmd.position.y, cmd.orientation.y);
// Get the robot's current pose
float *currentPose = robot->getLocalPose();
// Assign new target pose. Current state + new pose.
refPose[X_POS] = currentPose[X_POS] + cmd.position.x;
refPose[Y_POS] = currentPose[Y_POS] + cmd.position.y;
refPose[PSI] = currentPose[PSI] + cmd.orientation.y / (180/PI); // in radians
// Print target pose to the ROS console
ROSLOGString("Target Pose X, Y, Psi");
ROSLOG3F(refPose[X_POS], refPose[Y_POS], refPose[PSI]);
// Set the commandCalled flag
commandCalled = true;
}
The main loop simply waits for a command to be received via the subscribe protocol. The nh.spinOnce() statement polls the ROS server for new messages. Once the command is received and the new reference pose is computed it's sent to the control loop that’s responsible for moving the robot. Here’s a diagram of the command control loop:
And here's the code:
//-------------------------------------------------//
// Main command loop
//-------------------------------------------------//
void loop() {
// Loop until command is sent.
if (commandCalled) {
// Position control loop
poseController(refPose);
// Reset commandCalled flag
commandCalled = false;
}
// Wait for subscribed messages
if (nodeHandleCreated) {nh.spinOnce();}
delay(1000);
}
So I’m not sure how long a post should be. I’m in the process of documenting the entire wheeled robot project and intend to put it up on a Wordpress site. It would be great if I could post it all here and benefit from the comments and feedback, although some of the articles may get a little long. I can describe the C++ robot model together with the control loop that drives the robot to its new destination. I would only focus on the software side of things since that’s my main skill set. I’m very new to the electronics and mechanics so I think I should leave that to more talented people like Bill.
Topic starter
2019-07-01 10:17 am
A build series about this robot would be a great addition to the Project Corner. Many of us would love to learn about how you are designing and implementing of your robot.
The build series combined with feedback/kibitzing could serve as a great place to draft your thought on paper... so to speak.
I think your article is around 1000 words. As long as there are plenty of pictures and diagrams, that seems appropriate for this type of information. I skimmed the article in about five minutes to get the gist.
Once I get this initial feedback done, I'll sit down with a cup of coffee and open two side by side browser windows, one with your article and the other for googling topics you bring up which I would like to learn more about.
Looking forward to learning more please include plenty of pictures. Coffee is ready:)
2019-07-01 5:53 pm
Thanks for pointing out the Robot Projects part of the forum. I'll start posting my project articles there. Keeping them below a 1000 words.
2019-07-01 6:14 pm
Very interesting info. I would also like to see a build series about your robot. I'm putting my robot project on hold for a while (its not proceeding with any haste in any case) whilst you and twobits hopefully feed in some more good information on ROS in case I feel I would like to go down the ROS route.
I will probably put ROS on a spare rpi to help follow along. Is ROS Melodic Morenia the installation you are using?
Topic starter
2019-07-01 7:00 pm
Currently, I am using Ros Kinetic on Ubuntu 16.04. That is the officially supported version for the TurtleBot3.
Versioning tends to be a total pain in the but for these type of projects. Most of the industrial users are on ROS Indigo Igloo released in the middle of 2014. Once they learn the quirks of a particular version of something they like to run it forever.
Smaller Commercial users and academic labs seem to use ROS Kinetic Kame released in Spring of 2016. They prefer to let a release age for a couple of years before they invest the time and effort to update their entire team to the new release.
Early adopter tend to like ROS Melodic Morenia released in spring of 2018. One challenge with the new release is the industrial, commercial, and academic organizations don't always update their packages on the ROS repository. Some key packages are not yet fully supported on Melodic.
Developers would like you to use Dashing Diademata release in spring of 2019 which is from the ROS2 set of releases.
For the DB1 variant I will probably use Dashing on the latest version of Raspbian and/or Tegra4Linux. SBC hardware and people's understanding of how to get the most of that new hardware is improving rapidly enough to make it worth the hassle of being on the bleeding edge.
It should not require an additional RPI to play with ROS. You can just swap in a new SD card that is set up for ROS when you want to experiment.
2019-07-01 7:37 pm
It should not require an additional RPI to play with ROS. You can just swap in a new SD card that is set up for ROS when you want to experiment.
That's an interesting thought. I never really thought of it that way. I could just devote an SD card for the study of ROS and not have to worry about it becoming bloatware on my current system. ?
I might give that a shot.
DroneBot Workshop Robotics Engineer
James
2019-07-08 9:51 pm
Currently, I am using Ros Kinetic on Ubuntu 16.04. That is the officially supported version for the TurtleBot3.
Versioning tends to be a total pain in the but for these type of projects. Most of the industrial users are on ROS Indigo Igloo released in the middle of 2014. Once they learn the quirks of a particular version of something they like to run it forever.
I hadn't thought of that. I kept looking at the End Of Life dates, and kept trying to get the latest and greatest, which is why I originally bought the Atomic Pi. The description said that it wouldn't run on ARM, but it would on X86. I might have saved myself some trouble and started with an older, tested version, which is what I think I'm going to do
Thank you
Page 1 / 2
Next