2.3 RobotStudio Add-In
2.3.3 Google Protocol Buffers
Protocol buffers are Google’s language-neutral and platform-neutral libraries for serializing structured data. Once the data structure is defined, a special automatically generated source code allows to easily use the structured data for sending/receiving applications among different programming languages [27].
The specification of the structure information to serialize is defined by protocol buffer message types in .proto files. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs [28].
According to the Google Protocol Buffer Language Guide [29], two types of protocol buffer messages have been defined, one for the velocity command input (CmdVel in protobuf 2.2) transmitted via TCP, and the other for the robot pose (RobotPose in protobuf 2.3) transmitted via UDP.
Listing 2.2: Google Protobuf for CmdVel syntax = "proto3"; message CmdVel { double linear_x = 1; double linear_y = 2; double angular = 3; }
Listing 2.3: Google Protobuf for RobotPose syntax = "proto3"; message Robotpose { double x = 1; double y = 2; double theta = 3; }
Without entering into the details, once Google Protobuf is installed, it provides an exe- cutable file that accepts .proto files and generates the corresponding .cs (the extension of C#). In the .cs file, the CmdVel and RobotPose classes are defined, together with the constructor and some standard methods (for example: get(), toString()).
Finally, these are the classes that are used in the codes for the Add-In (Appendix D). Concerning the Add-In, the intention is not to bore the reader with a detailed analysis of the code itself, which is entirely reported in Appendix D, but to focus the dissertation on the graphical outcomes that are far more tangible and meaningful. Moreover, a code analysis will be performed later in the thesis, when the algorithms used for the ROS simulation will be presented.
The Add-In consists of three buttons, two of them placed in the Ribbon of the Home bar (already visible in Figure 2.1) and the other one placed in the Ribbon of the Simulation bar (already visible in Figure 2.2): the first button has the shape of a lightning and it enables the TCP/UDP communication, the second one has the shape of a gear and allows the user to change some parameters, and the last one has the shape of an “X” and stops the communication.
Figure 2.6: The Add-In buttons.
All the buttons belong to the same group that is “creatively” called “TCP/UDP” (Figure 2.6). The positioning of the buttons can be done in the Ribbon.xml file that is entirely re- ported in the Appendix D.4. On the other hand, the behavior of each button, coded in the
2.3 RobotStudio Add-In 13
Main class (Appendix D.1, by the methods RegisterCommand, button_UpdateCommandUI, button_ExecuteCommand), becomes effective only once the buttons have been registered in the CommandBarButton.xml file (Appendix D.5).
By positioning the mouse on each button, one makes the help text come out. The help text can be personalized in the CommandHelpTextButton.xml, the choice made is showed in Figure 2.7.
Figure 2.7: The Help Text of the Add-In buttons.
Finally, when selecting the Settings button, a personalized window pops up (Figure 2.8), and allows the user to manually set the following features:
- the Server IP and the Port Number of the TCP Server; - the Server IP and the Port Number of the UDP Server;
- the Camera behavior (see the corresponding class at [21]): if the option is checked, the Camera will be fixed at the origin of the axes, if not it will follow the platform; - the displaying of Debug messages in the corresponding bar. In case this option is checked, information concerning the status of the connection (IP and Port Number) and the details of the messages exchanged (the command received and the pose sent) will be displayed in the Output bar.
Figure 2.8: The Settings window of the Add-In. Again, the corresponding code is in the Main class.
This kind of work has been carried on both with RobotStudio and ROS. The ROS part was developed by a colleague and, hence, it is not presented here.
The work done in RobotStudio was intended to explore the possibilities of the Smart Com- ponent and to what extent it is possible to communicate with ROS for robot simulations. The result of this investigation is that, at the state of the art, the functionalities available in the Smart Component are not sufficient to cover all the complex tasks that intervene in navigation. This is because it has no sensors capable of retrieving informations about the environment, as required by both localization and mapping.
Concerning the Add-In, it works as intended and in general it seems to be quite a power- ful concept, as one can extend the functions already provided in Robot Studio to achieve special targets.
Chapter 3
Mobile Robotics: theoretical background and
kinematic modeling
The main goal of this chapter is to provide the readers with some preliminary background about mobile robotics, in order to help a better understanding of the content of the next chapters. Moreover, the platform used for this project is an unconventional mobile robot, a case that is usually not detailed in textbooks.
Some general definitions will be given and finally the mathematical model for the Clearpath Ridgeback robot will be derived.
Most of the content of this chapter is taken from the notes of the course of Prof. Gaëtan Garcia, Wheeled Mobile Robotics [30], except for the sections concerning the mecanum wheels.