So what features does the Ross suit framework have that helps with robotic software development?
Well, first let's look at an example robot to use as a reference.
This is a simple mobile based robot.
This robot has four wheels.
One motor controls both wheels on the left side of the robot, and another motor controls both wheels
on the right side of the robot.
This robot also has a vertically mounted camera, which also has a motorized base so the camera can
turn.
There are also sensors on board to give us information about our robot's position.
Here, the robot has a GPS sensor to give the robot's current latitude and longitude coordinates.
And here is an IMU sensor, which gives the robot's orientation and acceleration.
So what features does Ross do have to help us program the test robot I have here?
Well, the first feature is a data distribution service, also known as DDS, which is a communication
pipeline which can interface with all of our code executed code files which utilize Ross functionality
are called nodes.
Here I have two C++ files which get compiled into executable ROSS nodes which utilize the Ross two RDS
to send information between them when they're run.
The DDS Communication pipeline also allows for security configurations so that you can secure the data
you send between nodes.
Nodes have three primary ways which they can communicate with each other over deeds.
The first is through a publisher or subscriber method.
Let's say we have two nodes for our robot.
This arrow represents the data flow direction for our Ross communication.
The camera node wants to make available images from our robot's camera, so it publishes these images
to anyone who wants to listen in or subscribe to this particular data.
These individual communication pipelines are referred to as topics.
In this case, we can have a topic name of front camera.
This node publishes information which is referred to as messages.
In this case, the message type is an image.
This architecture is very scalable, such that one publisher can send messages to multiple subscribers.
A way to think of this is the way common video streaming websites are organized, such that subscribers
are sent new videos when they are published and the channel name is like a Ross topic name.
Another way to communicate between nodes is through services.
For this example, we have a survey node, which is a service client that sends a request to turn the
robot camera 45 degrees.
This request is received by the camera mover node, which is a service server which, after completing
the request, will send back a response.
In this example, our response is an image the camera took after turning the camera to the desired angle.
The third way for nodes to communicate with each other are through actions.
In this example, we have a node which wants to command our robot to travel to a certain latitude and
longitude, coordinate to take a picture.
This node acts as an action client, which sends a goal which in this case is our latitude and longitude
coordinates we want to travel to and it sends it to the action server.
The action server will then process the goal and send progress updates to the client.
In this case, we will send back data on how far away the robot is from the goal.
These progress updates are referred to as feedback.
Our action server will continue sending feedback to the client until the goal is reached.
In this example, once the goal is reached, our action server will send a picture which the robot took
at the goal location.
This is called the result of our action.
Ross nodes also have a parameter feature.
Here we have our mobile robot.
But let's say we have another version of it where the wheel size is increased.
We may need to take this change into account in our code rather than having to edit the code and recompile
our project.
We could instead utilize a node parameter which allows for configurations for specific variable values
within our node.
This parameter can be modified by a user or other nodes when needed.
In this case, we could set a node parameter called wheel radius for our code to reference.
There are going to be times when you want to collect data from your robot in which you will probably
want to create a bag file.
A bag file can subscribe to multiple topics and record the data as it comes in.
After you are done recording this data, you can play it back and have those recorded messages get published
over the same corresponding topic names.
It is worth noting that Ross code is organized as packages.
These packages will contain all the code for particular robot functionality.
These packages can then easily be copied and redistributed to other developers who want to use it.
Then they can use that same set of code for use on their own robot.
Lastly, one of the most notable features of Ross two for robotic software development is cross-platform
support.
Unlike most distributions of its predecessor, Ross, two allows for other operating systems other than
Linux to run Ross and be able to communicate with each other.
Keep in mind this cross-platform support is relatively new.
So for the best possible experience with Ross, I highly recommend using Ubuntu.
Roku also allows for integration with systems developed in ROS one.
That way you can confidently start utilising Ros too, without worrying about compatibility with previous
projects you developed in ROS one.
Och, that was a lot to take in.
So let's review what features Ross do has.
Rossouw utilizes a data distribution service which has various security configurations to allow communication
between our nodes.
Nodes are executed code which utilizes the ROS framework and can be configured via parameters.
One of the ways which nodes communicate with each other is through a publisher subscriber architecture
which nodes publish data over topics for subscribers to process.
Nodes can also communicate via services which one node sends a request for another node to process and
send a response.
Lastly, nodes can communicate via actions in which one node sends a goal for a second node to achieve.
The second node will publish feedback until the goal is reached and then we'll send back a result.
Bag files are used to save data being published by the robot, which can later be played back on the
same topics to simulate the data as it was experienced by a robot.
Our code we develop for ROS can be organized into packages which can be easily distributed for other
developers to use.
Lastly, Ross incorporates cross platform support so we can use its features on various operating systems
and still utilize code developed for the older Ross one distribution versions.