A computer science professor of mine, “back in the day,” once said that the greatest challenge in the future of software development will rest in the realm of integration. This is certainly true in robotics, if nowhere else. Due to the complexity involved with robotics, developers typically focus on very specific problems and develop very specific solutions to meet those challenges, accordingly. Path planning, SLAM, edge finding, handle manipulation, road recognition, planning with resource constraints, pattern and object recognition, D*, data mining algorithms, reinforcement learning, Kalman and particle filters are just some examples of “specialty” subjects in robotics and AI which people have developed pivotal software solutions to. An immense opportunity has existed, and will continue to exist, in bringing these together into more generalized solutions which are able to reap the benefits of the more specialized solutions within a cohesive whole.

An obstinate challenge in doing just that has been the technical complexities involved with integrating the plethora of solutions into a grouping which facilitates seamless communications among these solutions. If someone were to attempt at integrating more than a handful of specialized solutions and frameworks, the time involved would be nearly prohibitive to accomplishing the desired goal. Robot Operating System (ROS) seems to be changing the game a bit to allow just such an endeavor to be more tractable. Now that core ROS development has stabilized, a large number of groups have been feverishly working on providing their “specialty” solutions as packages which seamlessly integrate with ROS. And that means that they are then much more inter-operable with just about any other package that works with ROS.

There is truly a dizzying number of packages that have been provided for ROS (navigable at http://www.ros.org/browse/list.php). The packages range from algorithms for SLAM to hardware communication packages to wrappers for programming languages to wrappers for off the shelf systems and other existing software. It is this last category that gets me really jazzed. With such wrappers being introduced (not to be confused with “rappers,” a slightly different breed) , we’re now able to leverage a number of very solid and mature tools and frameworks without being bogged down with low level integration and communication issues. I’d like to briefly highlight a few ROS packages which provide just such accessibility to existing tools and frameworks:

• trex_ros for trex-autonomy: The Teleo-Reactive Executive (T-REX) is a hybrid executive combining goal-driven and event-driven behavior in a unified framework based on temporal plans and temporal planning. (I’ve been tearing through the documentation here and here with the hopes of trying it out soon on my home projects.) A cool did-ya-know about T-REX is that it leverages the europa-pso planning framework available from NASA Ames Research Center.
• antlr for ANTLR: ANTLR is a language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions containing actions. There’s a mouthfull! Really what ANTLR provides is a means to formalize and create your own domain-specific language…imagine a language specifically geared towards commanding your robot in a particular domain, ANTLR enables you to do just that.
• rosglue for RL-Glue: Recently highlighted via ROS News, RL-Glue (Reinforcement Learning Glue) provides a standard interface that allows you to connect reinforcement learning agents, environments, and experiment programs together, even if they are written in different languages.
• openrave for OpenRAVE: OpenRAVE is targeted for real-world autonomous robot applications, and includes a seamless integration of 3-D simulation, visualization, planning, scripting and control. OpenRAVE is particularly useful for planning movements for robotic arms and manipulators.
• thea for Thea OWL Parser: Thea is an Prolog library that provides complete support for querying and processing OWL2 ontologies directly from within Prolog programs. (Honestly, I can’t say that I know much about this, but I keep reading more and more about OWL2…it seems that this is gaining and maintaining widespread interest in AI and autonomous robotics.)
• karto for Karto Mapping: Karto has been around for a while and came around to open sourcing their mapping libraries earlier this year. The karto ROS package provides a means to leverage this solid library with ROS.
• vision_opencv for OpenCV: I don’t think I need to say much about this…just use it!
• gmapping for GMapping: GMapping is a SLAM (Simultaneous Localization and Mapping) solution using particle filters; the gmapping ROS package wraps the entire application for use within ROS. (If you’d like to learn more about SLAM, there’s no better resource that Sebastian Thrun’s Probabilistic Robotics.)
• While I’ve been focusing on integration with software packages, I’ve got to mention nxt for Lego NXT: Recently announced on ROS News, this stack provides a number of tools for integrating NXT with ROS along with a novel use of NXT’s Lego Digital Designer for use within the rviz simulator…very slick.

The sampling above highlights just a few of the efforts by various groups to facilitate the integration of solid, existing tools and frameworks into ROS for easier communications with other packages and custom development. Ultimately, these efforts are lowering the barrier to integrate many great ideas and solutions into a more cohesive whole. This seems like a great indication of the current state of robotics…a sign that the industry is finally maturing enough that we’re now working towards integrating existing solutions – rather than re-inventing the wheel – in order to more aggressively push the envelope of what’s attainable and what’s imaginable.

Billy McCafferty

I was presented with the following discussion opener concerning the management of complexity via the introduction of abstraction…

How do we handle complexity? I asked a few software architects I know and all of them answered, “Abstraction.” Basically they’re right, but being a math major in college, there is a principal I believe that software architects and designers miss – complexity is constant. In other words, if you’re designing a system that is inherently complex, you can’t reduce it. In chemistry I remember learning that energy is constant, it can’t be created or destroyed, it’s just there. In software, if the solution to a problem is complex, the complexity is always going to be there.

What about abstraction? Abstraction basically hides complexity. This is good, right? The problem is, in a lot of designs, once abstraction hides complexity the designers tend to forget about it. If you work hard at a good design to hide the complexity and forget about it, it will come back and haunt you some day. So what does one do?

I love this discussion! The heart of this is determining if the introduction of abstractions, for the sake of hiding complexity, is truly an overall benefit. In robotics, we’re ever dealing with increasing levels of abstraction for this very reason. For example, in Architectural Paradigms of Robotic Control, I briefly discussed the 3T architecture which has three separate layers, implemented as increasing levels of abstraction. E.g., the skill/servo layer would likely be implemented in C++, the sequencing/execution layer might be implemented as a sequence modeling language, such as ESL or NDDL, while the planning/deliberative layer might be implemented with a higher abstraction yet, such as with the Planning Domain Definition Language or Ontology with Polymorphic Types (Opt).

In response to the concerns put forth, I would tend to agree that abstraction hides complexity and that it does make it more likely that you may be bitten by the hiding of the complexity. With that said, encapsulation of complexity into well formed abstractions is an inevitable step to facilitate taking on increasingly complex problems. For example, in the .NET world of data access, Fluent NHibernate is really just a way of hiding the complexities of NHibernate. NHibernate is really just a way of hiding the complexities of ADO.NET. ADO.NET is really just a way of hiding the complexities of communicating to a database via TCP/IP sockets, or whatever underlying mechanism is employed. Along the same vein, tools such as Herbal, NDDL, and ESL are similarly provided as a means to provide an abstraction for hiding complexity.

Because these layers of complexity have been encapsulated in a manageable fashion, we’re now able to take on project work which would be far too complex to manage if we were using a lower level of implementation, e.g., pure C++, or Assembly for that matter. Indeed, there will be times when the added layers of abstraction will make it more difficult to tweak a low level capability, but the improved complexity management that the abstractions provide should far outweigh the sacrifice of losing some low level capabilities.

I think the crux for determining if an abstraction is worthwhile:

• Does the abstraction reduce complexity of interacting with the underlying layer that it encapsulates?
• Does the abstraction make it easier to tackle increasingly complex problems?
• Does the abstraction provide enough tweak points to accommodate the 5-10% of times that more low level control is needed?
• Does the abstraction increase maintainability and ease of understanding of the overall goals of the system?

If the answers to the above are yes, then I believe that the encapsulation of complexity, codified as a new layer of abstraction, is pulling its weight. Otherwise, you might not want to throw that Assembly language reference away just yet.

Billy McCafferty

While I wait for my $200K grant, my Darpa project award, Aldebaran to send me a few Nao’s, or Willow Garage to mail a PR2 my way (please contact me for shipping details), I spend much of my research time on the simulation side of robotics. In addition to being far less costly than purchasing hardware, working via simulators actually provides a number of benefits:

• One need not spend time hacking a hardware platform together. Instead, simulators allow the robot to be completely available, in perfect working condition, before the first line of code is written. The time trade off enables a much greater amount of effort to be spent on algorithmic development…assuming that’s your interest.
• One need not worry as much about hardware obsolescence. A vexing challenge for roboticists is deciding when to invest in new hardware. It always seems that the moment hardware arrives in the mail, announcements are made concerning the availability of even better options.
• As a positive side effect of the time and cost savings that simulators typically provide, the simulation route also enables one to try out many more platforms and segments of the robotics industry in a shorter amount of time. For example, instead of putting all your eggs in one basket, it becomes far less costly to abandon a platform for another when you can simply install a new simulation environment or simulated platform.
• Simulators enable researches to perform otherwise impractical research; such as evolutionary development, robotic injury recovery, or simulation within dangerous or hard-to-replicate environments, such as mines, nuclear waste facilities and natural disaster sites.

Obviously, it’s difficult to replace the experiences of working on real robots in real environments with real-world sensor errors, data fusion that doesn’t agree, and unpredictable dynamics, but simulators certainly provide a convenient means to try out new ideas or experiment in new areas.

Along those lines, I’d like to highlight a few simulators for mobile robotics which may pique your interest:

• Microsoft Robotics Developer Studio (RDS): In addition to being a complete robotic operating system, Microsoft RDS includes a powerful simulation environment with a large number of robotic platforms readily available for use. Beyond the Microsoft provided content, an amazing breadth of tutorials and guidance for using the RDS simulator may be found here.
• Player: Player is a very popular and widely used robotic software platform which is actually three tools in one. The first tool is Player itself; Player is the server component of the robotic platform which facilitates communications to sensors and actuators over network communications. The next two tools provide the simulation capabilities. Stage is a 2D simulation environment supporting multiple agents supporting sensor feedback. Gazebo is a 3D simulation environment with sensor support as well as a physics engine for simulating object interaction in the 3D context. A great tutorial for getting started with Player/Stage is found here. Luckily, running your code between the Stage and Gazebo environments requires very little changes at all; accordingly, once you learn one, you’re already quite familiar with other.
• Robot Operating System (ROS): Like Microsoft RDS, ROS is far more than just a simulation environment; indeed, ROS is a full robot operating system providing messaging infrastructure as well as a means to easily develop and share solutions with other users. For the subject at hand, ROS leverages the Stage 2D simulator and Gazebo 3D simulator for many of its simulation oriented packages. You can find a lot more about ROS’ use of Gazebo for robotic simulation, and learn how to try it out yourself, with these tutorials. For a Stage tutorial, be sure to also check out this tutorial.
• Webots: Webots is completely geared towards robotic simulation. Offering plenty of physics options for modeling the real world along with many available sensors and actuators makes Webots a very solid and mature simulation platform. The Webots overview page does a very concise job of describing the software’s capabilities, which I need not repeat here. Webots has a well organized introduction within the documentation; many user generated tutorials are also readily available online, such as this one.
• RoboCup Soccer Simulator: While the previously discussed packaged are geared towards being “one size fits all,” the RoboCup Soccer Simulator is honed to just that, allowing developers to participate in the RoboCup Soccer Simulation league via a standard platform. This platform is made up of a number of elements: the Server which runs the simulation and acts as a host for participating clients to send commands and receive sensor feedback information, the Monitor which facilitates viewing the simulation in real time, and the Log Player which provides the ability to replay games at a later time. While official documentation may be found here, its 2003 last-modified date makes me concerned that it may have fallen out of synch with the software itself, which is still being actively maintained. While the online manual is much more current, it is missing quite a few pieces.
• RoboCup Rescue: This more seriously toned simulation environment provides a platform for researching topics such as modeling disaster environments and robotic assistance in disaster recovery. The Agents Simulation league models the disaster environment including dynamics such as traffic, fire, and civilian movements. Agents are then developed to take on the role of police and other recovery participants. The Virtual Robotics league, facilitates the development of autonomous robots with sensors and actuators to assist in the disaster recovery effort. Although I’ve found the documentation for RoboCup Rescue to be a bit less approachable than for the other simulation environments, there is good content to be found on the project’s wiki

The above list is certainly not exhaustive, but should give a good introduction of available simulation environments. Other environments not mentioned which also have support for mobile robotics development in simulated environments include MapleSim, Simbad, Carmen, Urbi (compatible with Webots) lpzrobots, Moby, and OpenSim. Finally, robot competitions occasionally include simulated environments in their challenges; robots.net keeps a terrific listing of available competitions at http://robots.net/rcfaq.html; the AAAI conferences and competitions are particularly good at coming up with novel hardware and simulation challenges which truly push the envelope of progress.

Certainly enough to keep you busy for a while…not bad when you consider the many projects you can carry out before committing to buying a single piece of hardware!

Enjoy!
Billy McCafferty

Part VI: Adding a UI Layer to the Package

As the last and final chapter to this series of posts (Part I, II, III, IV, V), we’ll be adding a basic UI layer to facilitate user interaction with the underlying layers of our package. Specifically, a UI will be developed to allow the user (e.g., you) to start and stop the laser reporting application service via a wxWidgets interface. If you’re new to wxWidgets, it really is a terrific open-source UI package with very helpful online tutorials, a thriving community, and a very helpful book, Cross-Platform GUI Programming with wxWidgets – certainly a good reference to add to the bookshelf. Arguably, the sample code discussed below is very simplistic and only touches upon wxWidgets; with that said, it should demonstrate how to put the basics in place and to see how the UI layer interacts with the other layers of the package.

Developing a UI layer with wxWidgets is quite straight forward; the UI itself is made up of two primary elements: a wxApp which is used to initialize the UI and a wxFrame which serves as the primary window. For the task at hand, the wxApp in the UI layer will be used to perform three primary tasks, in the order listed:

1. Initialize ROS,
2. Initialize application services and dependencies for those services (e.g., message endpoints), and
3. Create the initial frame/window; application services will be passed to the frame to enable wiring up UI events to the respective application service functions.

As a rule of thumb, the UI layer should only communicate to the rest of the package elements via the application services layer. E.g., the UI layer should not be invoking functions directly on domain objects found within ladar_reporter_core; instead, it should call tasks exposed by the application services layer which then coordinates and delegates activity to lower levels.

Before we delve deeper, as a reminder of what the overall class diagram looks like, as developed over the previous posts, review the class diagram found within Part V. The current objective will be to add the UI layer, as illustrated in the package diagram found within Part I. To cut to the chase and download the end result of this post, click here.

Show me the code!

1. Setup the Package Skeleton, Domain Layer, Application Services Layer, and Message Endpoint Layer

If not done already, follow the steps in Part II, III, IV, and V to get everything in place. (Or simply download the source from Part V to skip all the action packed steps leading up to this post.)

2. Install wxWidgets

Download and install wxWidgets. Instructions for Ubuntu and Debian may be found at http://wiki.wxpython.org/InstallingOnUbuntuOrDebian.

3. Define the UI events that the user may raise

Create an enum class at src/ui/UiEvents.hpp to define UI events as follows:

// UiEvents.hpp
 
#ifndef GUARD_UiEvents
#define GUARD_UiEvents
 
namespace ladar_reporter_ui
{
  enum UiEventType
  {
    UI_EVENT_Quit = 1,
    UI_EVENT_StartReporting = 2,
    UI_EVENT_StopReporting = 3
  };
}
 
#endif /* GUARD_UiEvents */

As suggested by the enum values, the user will be able to start the reporting process, stop it, and quit the application altogether.

4. Create the wxWidgets application header class

Create src/ui/LadarReporterApp.hpp containing the following code:

// LadarReporterApp.hpp
 
#include <boost/shared_ptr.hpp>
#include <ros/ros.h>
#include "LaserScanEndpoint.hpp"
#include "LaserScanReportingService.hpp"
 
namespace ladar_reporter_ui
{
  class LadarReporterApp : public wxApp
  {
    public:
      virtual bool OnInit();
      virtual int OnExit();
 
    private:
      void InitializeRos();
      void InitializeApplicationServices();
      void CreateMainWindow();
 
      char** _argvForRos;
      ros::NodeHandlePtr _nodeHandlePtr;
 
      // Application services and dependencies.
      // Stored as pointers to postpone creation until ready to initialize.
      boost::shared_ptr<ladar_reporter_core::ILaserScanEndpoint> _laserScanEndpoint;
      boost::shared_ptr<ladar_reporter_application_services::LaserScanReportingService> _laserScanReportingService;
  };
}

A few notes:

• LadarReporterApp inherits from wxApp to create the “main” equivalent for wxWidgets.
• OnInit() and OnExit() are events called by wxWidgets when the UI is created and upon exiting (obviously).
• InitializeRos(), InitializeApplicationServices(), and CreateMainWindow() lay out the three primary tasks previously described.
• _nodeHandlePtr will hold our initialized reference to ROS during the lifetime of the UI.
• Finally, the application services and dependencies which will be leveraged by the UI are declared. While _laserScanEndpoint won’t be used by the UI directly, it’ll need to be injected into the constructor of _laserScanReportingService and will need to be kept alive so as to continue advertising on its respective topic.

5. Create the wxWidgets application implementation class

Create src/ui/LadarReporterApp.cpp containing the following code:

// LadarReporterApp.cpp
 
#include <wx/wx.h>
#include "LadarReporterApp.hpp"
#include "LadarReporterFrame.hpp"
#include "LaserScanEndpoint.hpp"
#include "UiEvents.hpp"
 
using namespace ladar_reporter_application_services;
using namespace ladar_reporter_core;
using namespace ladar_reporter_message_endpoints;
 
// Inform wxWidgets what to use as the wxApp
IMPLEMENT_APP(ladar_reporter_ui::LadarReporterApp);
// Implements LadarReporterApp& wxGetApp() globally
DECLARE_APP(ladar_reporter_ui::LadarReporterApp);
 
namespace ladar_reporter_ui
{
  bool LadarReporterApp::OnInit() {
    // Order of initialization functions is critical:
    // 1) ROS must be initialized before message endpoint(s) can advertise
    InitializeRos();
 
    // 2) Application services must be initialized before being passed to UI
    InitializeApplicationServices();
 
    // 3) UI can be created with properly initialized ROS and application services
    CreateMainWindow();
 
    return true;
  }
 
  int LadarReporterApp::OnExit() {
    for (int i = 0; i < argc; ++i) {
      free(_argvForRos[i]);
    }
 
    delete [] _argvForRos;
 
    return 0;
  }
 
  void LadarReporterApp::InitializeRos() {
    // create our own copy of argv, with regular char*s.
    _argvForRos =  new char*[argc];
 
    for (int i = 0; i < argc; ++i) {
      _argvForRos[i] = strdup( wxString( argv[i] ).mb_str() );
    }
 
    ros::init(argc, _argvForRos, "ladar_reporter");
    _nodeHandlePtr.reset(new ros::NodeHandle);
  }
 
  void LadarReporterApp::InitializeApplicationServices() {
    _laserScanEndpoint = boost::shared_ptr<ILaserScanEndpoint>(
      new LaserScanEndpoint());
 
    _laserScanReportingService = boost::shared_ptr<LaserScanReportingService>(
      new LaserScanReportingService(_laserScanEndpoint));
  }
 
  void LadarReporterApp::CreateMainWindow() {
    LadarReporterFrame * frame = new LadarReporterFrame(
      _laserScanReportingService, _("Ladar Reporter"), wxPoint(50, 50), wxSize(450, 200));
 
    frame->Connect( ladar_reporter_ui::UI_EVENT_Quit, wxEVT_COMMAND_MENU_SELECTED,
      (wxObjectEventFunction) &LadarReporterFrame::OnQuit );
    frame->Connect( ladar_reporter_ui::UI_EVENT_StartReporting, wxEVT_COMMAND_MENU_SELECTED,
      (wxObjectEventFunction) &LadarReporterFrame::OnStartReporting );
    frame->Connect( ladar_reporter_ui::UI_EVENT_StopReporting, wxEVT_COMMAND_MENU_SELECTED,
      (wxObjectEventFunction) &LadarReporterFrame::OnStopReporting );
 
    frame->Show();
    SetTopWindow(frame);
  }
}

The direction for this class was taken from wxWidgets online tutorials along with reviewing the ROS turtlesim package, which is a real treasure trove for seeing how a much more sophisticated ROS UI is put together. (If you have not already, I strongly suggest you review the turtlesim code in detail.)

6. Create the wxWidgets frame header class

Now that the wxWidgets application is in place, the frame, representing the UI window itself, needs to be developed. Accordingly, create src/ui/LadarReporterFrame.hpp containing the following code:

// LadarReporterFrame.hpp
 
#ifndef GUARD_LadarReporterFrame
#define GUARD_LadarReporterFrame
 
#include <wx/wx.h>
#include "LaserScanReportingService.hpp"
 
namespace ladar_reporter_ui
{  
  class LadarReporterFrame : public wxFrame
  {
    public:
        LadarReporterFrame(
          boost::shared_ptr<ladar_reporter_application_services::LaserScanReportingService> laserScanReportingService, 
          const wxString& title, const wxPoint& pos, const wxSize& size);
        void OnQuit(wxCommandEvent& event);
        void OnStartReporting(wxCommandEvent& event);
        void OnStopReporting(wxCommandEvent& event);
 
    private:
        boost::shared_ptr<ladar_reporter_application_services::LaserScanReportingService> _laserScanReportingService;
  };
}
 
#endif /* GUARD_LadarReporterFrame */

There are a couple of interesting bits in the header:

• The frame header declares the events which will be handled; e.g., OnQuit.
• It accepts and stores an instance of the LaserScanReportingService in order to invoke the application service layer in response to user interaction.

7. Create the wxWidgets frame implementation class

Create src/ui/LadarReporterFrame.cpp containing the following code:

// LadarReporterFrame.cpp
 
#include "LadarReporterFrame.hpp"
#include "UiEvents.hpp"
 
using namespace ladar_reporter_application_services;
 
namespace ladar_reporter_ui
{
  LadarReporterFrame::LadarReporterFrame(
    boost::shared_ptr<LaserScanReportingService> laserScanReportingService, 
    const wxString& title, const wxPoint& pos, const wxSize& size)
      : wxFrame( NULL, -1, title, pos, size ), _laserScanReportingService(laserScanReportingService)
  {
    wxMenuBar *menuBar = new wxMenuBar;
    wxMenu *menuAction = new wxMenu;
 
    menuAction->Append( UI_EVENT_StartReporting, _("&Start Reporting") );
    menuAction->AppendSeparator();
    menuAction->Append( UI_EVENT_StopReporting, _("S&top Reporting") );
    menuAction->AppendSeparator();
    menuAction->Append( UI_EVENT_Quit, _("E&xit") );
 
    menuBar->Append(menuAction, _("&Action") );
 
    SetMenuBar(menuBar);
    CreateStatusBar();
    SetStatusText( _("Ready to begin reporting") );
  }
 
  void LadarReporterFrame::OnStartReporting(wxCommandEvent& WXUNUSED(event)) {
    _laserScanReportingService->beginReporting();
 
    SetStatusText( _("Laser scan reporting is running") );
  }
 
  void LadarReporterFrame::OnStopReporting(wxCommandEvent& WXUNUSED(event)) {
    _laserScanReportingService->stopReporting();
 
    SetStatusText( _("Laser scan reporting has been stopped") );
  }
 
  void LadarReporterFrame::OnQuit(wxCommandEvent& WXUNUSED(event)) {
    Close(true);
  }
}

A few implementation notes:

• The LadarReporterFrame() constructor initializes the menubar for the window along with other rendering details.
• Each of the respective events are defined, invoking the application services layer when applicable. As discussed previously, the UI should interact with the rest of the package layers via the application services, as demonstrated above.

There’s obviously a lot of wxWidgets related information which I am glossing over which is beyond the scope of these posts. The wxWidgets documentation referenced earlier should fill in any remaining gaps.

8. Configure CMake to Include the Header and Implementation

With the header and implementation classes completed for the both the wxWidgets application and frame, we need to make a couple of minor modifications to CMake for their inclusion in the build.

1. Open /ladar_reporter/CMakeLists.txt. Under the commented line #rosbuild_gensrv(), add inclusions for wxWidgets as follows:

   find_package(wxWidgets REQUIRED)
   include(${wxWidgets_USE_FILE})
   include_directories( ${wxWidgets_INCLUDE_DIRS} )

2. With /ladar_reporter/CMakeLists.txt still open, add a line to the include_directories statement for the following directory in order to include the wxWidgets application and frame headers:

   "src/ui"

3. Open /ladar_reporter/src/CMakeLists.txt. Add an inclusion for the ui directory at the end of the file:

   add_subdirectory(ui)

4. Now, in order to create the UI executable itself, a new CMake file is needed under /ladar_reporter/src/ui. Accordingly, create a new CMakeLists.txt under /ladar_reporter/src/ui, containing the following:

   rosbuild_add_executable(
     ladar_reporter_node
     LadarReporterApp.cpp
     LadarReporterFrame.cpp
   )
   
   target_link_libraries(
     ladar_reporter_node
     ladar_reporter_application_services
     ladar_reporter_message_endpoints
     # Important that core comes after application_services due to direction of dependencies
     ladar_reporter_core
     ${wxWidgets_LIBRARIES}
   )

9. Add a ROS wxWidgets Dependency to manifest.xml

Since the package will be leveraging wxWidgets, a dependency needs to be added for the package to find and use this, accordingly:

• Under /ladar_reporter, open manifest.xml and add the following line just before the closing </package> tag:

  <rosdep name="wxwidgets"/>

10. Build and try out the UI Functionality

We are now ready to try everything out. While it is generally possible to write unit tests for the UI layer, personal experience has shown that the UI changes too frequently to make such unit tests worth while. UI unit tests quickly become a maintenance headache and do not provide much more value than what the existing unit tests have already proven; i.e., we’ve already verified through unit tests that the heart of our package – the domain objects, the message endpoints, and the application services – are all working as expected…the UI is now “simply” the final touch. Enough babble, let’s see this baby in action:

1. Build the application by running make within a terminal at the root of the package (at /ladar_reporter).
2. Open a new terminal and run roscore to begin ROS
3. Open a third terminal window and run rostopic echo /laser_report to observe any laser reports published to ROS
4. In the terminal that you’ve been building in…

   make
   cd bin
   ./ladar_reporter_tests

   Wait a second, that’s not showing anything new…that’s right! Always run your unit tests after making changes, even if you haven’t added any new tests, to make sure that you haven’t broken any existing code.

5. Still within the bin folder – in the terminal – run ./ladar_reporter_node. A window should pop-up allowing you to select an “Action” menu to start and stop the reporting service along with quitting the application altogether. You can see the laser reports going out to ROS via the third terminal window that was opened.
6. Click the “Quit” menu item when you just can’t handle any more excitement.

Well, that about wraps it up, we started by laying out our architecture and systematically tackling each layer of the package with proper separation of concerns and unit testing to make sure we were doing what we said we were doing. As demonstrated with the layering approach that we developed, higher layers (e.g., application services and core) didn’t depend on lower layers (e.g., message endpoints and the ROS API). In fact, when possible, the lower layers actually depended on interfaces defined in the higher layers; e.g., the message endpoint implemented an interface defined in the higher core layer. (Although the class diagrams show core on the bottom, it’s actually reflecting the dependency inversion that was introduced.) This dependency inversion enabled a clean separation of concerns while allowing us to unit test the various layers in isolation of each other.

I sincerely hope that this series has shed some light on how to properly architect a ROS package. While this series did not go into a granular level of detail with respect to using ROS and wxWidgets, it should have provided a good starting point for developing a solid package. The techniques described in this series have been honed over many years by demi-gods of development (e.g., Martin Fowler, Robert Martin, Kent Beck, Ward Cunningham, and many others) and continue to prove their value in enabling the development of maintainable, extensible applications which are enjoyable to work on. While ROS may be relatively new, the tried and trued lessons of professional development are quite timeless indeed.

As always, your feedback, questions, comments, suggestions, and even rebuttals are most welcome. To delve a bit further into many of the patterns oriented topics discussed, I recommend reading Gregor Hohpe’s Enterprise Integration Patterns and Robert Martin’s Agile Software Development, Principles, Patterns, and Practices. And obviously, for anything ROS related, you’ll want to keep reading everything you can at http://www.ros.org/wiki/ (and here at sharprobotica.com, of course)!

Enjoy!
Billy McCafferty

Download the source for this article.

Part V: Developing and Testing the ROS Message Endpoint

[Author's note, July 28, 2010: Introduced Boost::shared_ptr to manage reference to message endpoint so as to enable postponed construction, as will be required in Part VI.]

While this series (Part I, II, III, IV) has been specifically written to address writing well-designed packages for ROS, we’ve actually seen very little of ROS itself thus far. In fact, outside of the use of roscreate to generate the package basics and sensor_msgs::LaserScan for communicating laser scan data from the reader up to the application services layer, there’s been no indication that this application was actually intended to work with ROS now or ever. Ironically, this is exactly what we’d expect to see in a well designed ROS package.

Each layer that we’ve developed – as initially outlined in Part I – is logically separated from each other’s context of responsibility. To illustrate, the upper layers do not directly depend on “service” layers, such as message endpoints. Instead, the lower layers depend on abstract service interfaces declared in the upper layers. This dependency inversion was enabled in Part IV with the creation of ILaserScanEndpoint, a separated interface. If all of this dependency inversion and separated interface mumbo-jumbo has your head spinning at all, take some time to delve deeper into this subject in Dependency Injection 101.

While the actual message endpoint interface was created, only a test double was developed for testing the application service layer’s functionality. Accordingly, in this post, the concrete message endpoint “service,” which implements its separated interface, will be developed and tested. That’s right…we’ll finally actually talk to ROS! You can skip to the chase and download the source for this post.

Before digging into the code, it’s important to take a moment to better understand the purpose and usefulness of the message endpoint. The message endpoint encapsulates communications to the messaging middleware similarly to how a data repository encapsulates communications to a database. By encapsulating such communications, the rest of the application (ROS package, in our case) may remain blissfully oblivious to details such as how to publish messages to a topic or translate between messages and domain layer objects.

This separation of concerns helps to keep the application cleanly decoupled from the messaging middleware. Another benefit of this approach is enabling the development and testing of nearly the entirety of the application/package before “wiring” it up to the messaging middleware itself. This typically results in more reusable and readable code. If you haven’t already, I would encourage you to read the article Message-Based Systems for Maintainable, Asynchronous Development for a more complete discussion on message endpoints.

Onward!

Target Class Diagram

The following diagram shows what the package will look like after completing the steps in this post…it’s beginning to look oddly familiar to the package diagram discussed in Part I of this series, isn’t it? If you’ve been following along, most of the elements have already been completed; only the concrete LaserScanEndpoint and LaserScanEndpointTests will need to be introduced along with a slight modification to the TestRunner.

1. Setup the Package Skeleton, Domain Layer and Application Services Layer

If not done already, follow the steps in Part II, Part III, and Part IV to create the package and develop/test the domain and application service layers. (Or just download the code from Part IV as a starting point to save some time.)

2. Create the message endpoint header class.

Create src/message_endpoints/LaserScanEndpoint.hpp containing the following code:

// LaserScanEndpoint.hpp
 
#ifndef GUARD_LaserScanEndpoint
#define GUARD_LaserScanEndpoint
 
#include <ros/ros.h>
#include "sensor_msgs/LaserScan.h"
#include "ILaserScanEndpoint.hpp"
 
namespace ladar_reporter_message_endpoints
{
  class LaserScanEndpoint : public ladar_reporter_core::ILaserScanEndpoint
  { 
    public:
      LaserScanEndpoint();
 
      void publish(const sensor_msgs::LaserScan& laserScan) const;
 
    private:
      // Create handle to node
      ros::NodeHandle _ladarReporterNode;
 
      ros::Publisher _laserReportPublisher;
  };
}
 
#endif /* GUARD_LaserScanEndpoint */

The message endpoint header simply implements ILaserScanEndpoint and sets up handlers for holding the ROS NodeHandle and Publisher. The more interesting bits are found in the implementation details…

3. Create the message endpoint implementation class.

Create src/message_endpoints/LaserScanEndpoint.cpp containing the following code:

// LaserScanEndpoint.cpp
 
#include <ros/ros.h>
#include "sensor_msgs/LaserScan.h"
#include "LaserScanEndpoint.hpp"
 
namespace ladar_reporter_message_endpoints
{
  LaserScanEndpoint::LaserScanEndpoint() 
    // Setup topic for publishing laser scans to
    : _laserReportPublisher(
      _ladarReporterNode.advertise<sensor_msgs::LaserScan>("laser_report", 100)) { }
 
  void LaserScanEndpoint::publish(const sensor_msgs::LaserScan& laserScan) const {
    _laserReportPublisher.publish(laserScan);
    ros::spinOnce();
    ROS_INFO("Published laser scan to laser_report topic with angle_min of: %f", laserScan.angle_min);
  };
}

As you can see, there’s really not much to the actual publication process…which is what we were hoping for. The message endpoint should simply be a light way means to send and receive messages to/from the messaging middleware. This message endpoint does so as follows:

• The constructor initializes the publisher by advertising on a topic with the name of “laser_report.”
• The publish() function simply takes the received laserSan and moves it along to be published via ROS. Although not necessary for this specific package code, the call to spinOnce() will be important when the package has callbacks based on messages received. (See http://www.ros.org/wiki/ROS/Tutorials/WritingPublisherSubscriber(c%2B%2B) for more details.)

4. Configure CMake to Include the Header and Implementation

With the header and implementation classes completed, we need to make a couple of minor modifications to CMake for their inclusion in the build.

1. Open /ladar_reporter/CMakeLists.txt. Within the include_directories statement, add an include for the following directory to include the concrete message endpoint header:

   "src/message_endpoints"

2. Open /ladar_reporter/src/CMakeLists.txt. Add an inclusion for the message_endpoints directory at the end of the file:

   add_subdirectory(message_endpoints)

3. Now, in order to create the message endpoints class library itself, a new CMake file is needed under /ladar_reporter/src/message_endpoints. Accordingly, create a new CMakeLists.txt under /ladar_reporter/src/message_endpoints, containing the following:

   # Create the library
   add_library(
     ladar_reporter_message_endpoints
     LaserScanEndpoint.cpp
   )

5. Build the message endpoints Class Library

In a terminal window, cd to /ladar_reporter and run make. The class library should build and link successfully.

Like with everything else thus far…it’s now time to test our new functionality.

6. Unit Test the LaserScanEndpoint Functionality

While testing up to this point has been pretty straight-forward, we now need to incorporate ROS package initialization within the test itself.

1. Our package is going to act as a single ROS node; accordingly, we need to modify /ladar_reporter/test/TestRunner.cpp to initialize ROS within the package and to register itself as a node which we’ll call “ladar_reporter.” While I’m hard-coding the node name within the test itself, you may want to consider putting the name into a config file as it’ll likely be referenced in multiple places; having it centralized within a config file gets rid of the magic string, making it easier to change while reducing the likelihood of typing it wrong in some hard-to-track-down spot.

   Open /ladar_reporter/test/TestRunner.cpp and modify the code to reflect the following:

   #include <gtest/gtest.h>
   #include <ros/ros.h>
    
   // Run all the tests that were declared with TEST()
   int main(int argc, char **argv){
     testing::InitGoogleTest(&argc, argv);
    
     // Initialize ROS and set node name
     ros::init(argc, argv, "ladar_reporter");
    
     return RUN_ALL_TESTS();
   }

2. Create a new testing class, /ladar_reporter/test/message_endpoints/LaserScanEndpointTests.cpp:

   // LaserScanEndpointTests.cpp
    
   #include <gtest/gtest.h>
   #include "sensor_msgs/LaserScan.h"
   #include "LaserScanEndpoint.hpp"
   #include "LaserScanReportingService.hpp"
    
   using namespace ladar_reporter_application_services;
   using namespace ladar_reporter_message_endpoints;
    
   namespace ladar_reporter_test_message_endpoints
   {
     // Define unit test to verify ability to publish laser scans 
     // to ROS using the concrete message endpoint.
     TEST(LaserScanEndpointTests, canPublishLaserScanWithEndpoint) {
       // Establish Context
       LaserScanEndpoint laserScanEndpoint;
       sensor_msgs::LaserScan laserScan;
    
       // Give ROS time to fully initialize and for the laserScanEndpoint to advertise
       sleep(1);
    
       // Act
       laserScan.angle_min = 1;
       laserScanEndpoint.publish(laserScan);
    
       laserScan.angle_min = 2;
       laserScanEndpoint.publish(laserScan);
    
       // Assert
       // Nothing to assert other than using terminal windows to 
       // watch publication activity. Alternatively, for better testing, 
       // you could create a subscriber and subscribe to the reports 
       // You could then track how many reports were received and 
       // assert checks, accordingly.
     }
    
     // Define unit test to verify ability to leverage the reporting 
     // service using the concrete message endpoint. This is more of a 
     // package integration test than a unit test, making sure that all 
     // of the pieces are playing together nicely within the package.
     TEST(LaserScanEndpointTests, canStartAndStopLaserScanReportingServiceWithEndpoint) {
       // Establish Context
       boost::shared_ptr<LaserScanEndpoint> laserScanEndpoint =
         boost::shared_ptr<LaserScanEndpoint>(new LaserScanEndpoint());
       LaserScanReportingService laserScanReportingService(laserScanEndpoint);
    
       // Give ROS time to fully initialize and for the laserScanEndpoint to advertise
       sleep(1);
    
       // Act
       laserScanReportingService.beginReporting();
       sleep(4);
       laserScanReportingService.stopReporting();
    
       // Assert
       // See assertion note above from 
       // LaserScanEndpointTests.canPublishLaserScanWithEndpoint
     }
   }

   The comments within the test class above should clarify what is occurring. But in summary, the canPublishLaserScanWithEndpoint test bypasses all of the layers and tests the publishing of messages directly via the message endpoint. The canStartAndStopLaserScanReportingServiceWithEndpoint test takes this much further and injects the LaserScanEndpoint message endpoint into the LaserScanReportingService application service and starts/stops the laser scan reprorting, accordingly. This latter test should be seen more as an integration test rather than a unit test as it tests the results of all of the layers working together.

3. Open /ladar_reporter/test/CMakeLists.txt. Within the rosbuild_add_executable statement, add the following to include the message endpoint tests in the build:

   ./message_endpoints/LaserScanEndpointTests.cpp

4. While we’re at it, we’ll also need to link the new message_endpoints class library to the unit testing executable; accordingly, also within /ladar_reporter/test/CMakeLists.txt, modify target_link_libraries to reflect the following:

   # Link the libraries
   target_link_libraries(
     ladar_reporter_tests
     ladar_reporter_application_services
     ladar_reporter_message_endpoints
     # Important that core comes after application_services due to direction of dependencies
     ladar_reporter_core
   )

5. Verify that everything builds OK by running make within a terminal from the root folder, /ladar_reporter.
6. Now for the fun part…time to run our tests with ROS running. The steps will follow closely to those described in the ROS tutorial, Examining Pulisher/Subscriber:
   1. Open a new terminal and run roscore to begin ROS
   2. In the terminal that you’ve been building in…

      make
      cd bin
      ./ladar_reporter_tests

   With a little luck, you should see a few messaging being published to ROS while running the unit tests. And just to prove it…

   1. With roscore still running, open a third terminal window and run rostopic echo /laser_report. You’ll likely be warned that the topic is not publishing yet…let’s change that.
   2. Back in your original terminal, the one you ran the unit tests in, rerun ./ladar_reporter_tests. You should now being seeing laser scans being echoed to the third terminal window for the LaserScanEndpointTests canPublishLaserScanWithEndpoint and canStartAndStopLaserScanReportingServiceWithEndpoint. Seriously now, how cool is that?

The first five parts of this series conclude the primary elements of developing well-designed packages for Robot Operating System (ROS) using proven design patterns and proper separation of concerns. Obviously, this is not a trivially simple approach to developing ROS packages; indeed, it would be overkill for very simple packages. But as packages grow in size, scope, and complexity, techniques described in this series should help to establish a maintainable, extensible package which doesn’t get too unruly as it evolves. In Part VI, the final part in this series, we’ll look at adding a simple UI layer, using wxWidgets, to interact with the package functionality.

Enjoy!
Billy McCafferty

Download the source for this post.

For decades, since the dawn of Shakey, the software side of robotics was primarily constrained to the world of hardware-limited embedded systems which needed to be redeveloped from the ground up with every new robot. This approach limits code reuse, is painfully tricky to debug, and becomes a serious time sink with each hardware upgrade. Accordingly, increasing efforts have been made to create an operating system for robots to provide better hardware abstraction, enable greater code reuse and maintainability, and to facilitate the development of software regardless of the robotic platform that it will be run on. Does this sound similar to what DOS and Windows enabled for the PC revolution to occur? (I don’t think I need to try to convince you of what an impact that approach had in the PC world.) Accordingly, the hope is that a similar effect, if not monetarily, will occur in the robotics world. Indeed, it is likely that such a step must be taken to catalyze the world of robotics to become a true game changer, on par with the PC movement and the introduction of the internet itself.

We seem to be an a moment in time that a practical robot OS is ready to be more fully embraced and leveraged. While there are a number on the market, time will tell if one will win out or if niches will exist to support a number of OSes concurrently within the robotics world. In the meantime, the work of organizations to introduce a common robot OS is making it exceedingly easier for software geeks (such as myself) to get deeper into robotics without having to put on our hardware-hacker hat as often. A few robot OSes which are making an impact in this direction include Microsoft Robotics Developer Studio (RDS), CARMEN, Player, Robot Operating System (which incidentally leverages Player), YARP (used by RobotCub), Orca, and Urbi. I’d like to share with you a little more information about one of these in particular, Urbi.

Jean-Christophe Baillie, the CEO of Gostai (the company behind Urbi), took some time to share with me some Q&A concerning Urbi and information concerning why they decided to open source Urbi (a terrific move in my opinion). While I have not yet experimented with Urbi, I have found this information very helpful in understanding more of what Urbi is all about (and in piquing my interest to try it out):

• What is Urbi?

  Urbi is complete open source software platform to control robots, a kind of Operating System for robotics. It includes a C++ distributed components architecture called UObject, and an orchestration script language called urbiscript. The urbiscript language is innovative because it integrates new ways to handle parallel and event-based programming, which are two essential issues in robot programming. Recently, Urbi is also integrating ROS support to be able to integrate ROS nodes inside an Urbi project, and benefit from the best of both worlds.

• What kind of robots can it control?

  Any kind of robot, from Lego NXT, Bioloid and Spykee, to Aibo, Nao, Segway RMP or Spykee. There is a complete list on urbiforge.org, and they are all available for free.

  We believe that Urbi is also suitable to control not only robots but also complex systems in general, involving multiple components highly interacting, like video games, simulations or factory/process management.

• Can you tell more about urbiscript and its relationship to the Gostai C++ support.

  urbiscript is an orchestration language, which means that its role it to coordinate various components, organize their interactions, the data they exchange, etc. All this in realtime, with a dynamic approach (you can reconfigure everything at runtime), and with advanced parallel and event-based control capabilities. This last part really distinguishes Urbi from other script languages like python for example, where you have to handle parallelism or events in a more traditional way. And it saves a lot of time.

  The way C++ and urbiscript talk together is via UObject, which is a C++ library capable to transparently bind any C++ object to urbiscript. With UObject, you take your favorite C++ class and it will appear as a native class of urbiscript, except that it is in fact C++ behind the scene. You can then connect this C++ class to other C++ classes using the orchestration capabilities of urbiscript.

• What makes Urbi unique?

  The parallel orchestration approach that comes with urbiscript is quite unique. We are also the only one to provide with Gostai Studio a graphical programming suite that handles hierarchical finite state machines (most other graphical approaches offered are flow charts). On a more technical side, the way UObject is bound to urbiscript provide very interesting asynchronous possibilities on the side of C++, which kind of enhances C++ itself with abstractions inherited from urbiscript. This makes UObject a little bit more than a traditional component architecture.

  Finally, I know it is not very convincing because almost everyone claims it for itself, but our users really support the fact that Urbi is amazingly simple to master, intuitive and well designed. You will have to make your own opinion on this, but we consider it a big difference with other competing alternatives. It just works, and we like it when we we can keep it simple.

• How does Urbi fit within a distribute and remote control environment?

  A nice feature that comes with UObject is that you can plug your C++ class into urbiscript in two ways: first in plugin mode, where the C++ class is physically bound to the Urbi engine that integrates the urbiscript interpreter. Everything is tightly connected then, shared memory, etc. The second way is to connect it in remote mode, where your C++ class becomes an executable program that will connect itself to the Urbi engine over the network. From within urbiscript, there is no difference, in both cases you will see that your C++ class appears inside urbiscript and you will get a transparent access to all its methods/variables. But behind the scene you have either direct memory access, or TCP/IP relaying. This means that you can very easily distribute a project simply by selecting certain UObject to run in remote mode, some of them on remote machines, some of them locally on the robot.

• Urbi has gone open source. Why did Gotsai take this step?

  I think it is the right move in 2010. You see how Android and other open source initiatives gain a tremendous momentum and add value to their underlying companies by creating a community, and I believe this is a model that has a future. We can have more community, more users, more feedback and ultimately perhaps more customers for our GostaiNet cloud based technologies, or Gostai Studio programming IDE. This commercial activity increase will allow us to reinvest more money into Urbi and the community will benefit back from it. This is a virtuous circle.

• What is Gostai RTC?

  Gostai RTC is the first commercial implementation of the RTC robotics standard. It is based on Urbi underneath, and you can benefit from the urbiscript orchestration layer together with RTC. Of course, you can also simply just use RTC without Urbi, and benefit from Gostai’s support. Gostai RTC is a product for the industry, so we sell it together with support and maintenance contracts.

• What is the difference between the full RTC implementation and the one supported by the openRTM open source version?

  The openRTM version of RTC is based on CORBA and, to my opinion, is much more complex to master. Also, the big difference is that we offer support, which matters the most for our industrial clients.

• What operating platforms do the various versions support?

  GostaiRTC is working on all platforms where you can run Urbi, which means a lot! We have support for almost all flavors of Linux, Windows or MacOSX, plus a few more exotic platforms and processors. GostaiRTC provides also support for the realtime operating system Xenomai, which we don’t offer with Urbi at the moment.

• What needs to be done to support a new, custom robot?

  Basically, you will develop drivers for your robots by creating appropriate UObjects in C++ to bridge the robot API with urbiscript. The procedure is described at http://www.urbiforge.org/index.php/Robots/Custom

  For example, you might create a ‘headYaw’ C++ object, with a ‘val’ attribute, and use callbacks on read/write on ‘val’ to trigger the appropriate robot API messages to actually move the robot head. All this is heavily documented and relatively easy to do. Of course, you also have existing examples that you could use as a starting point to adapt on your robot, and most common bus interfaces (CAN or i2c) are already supported.

• What is Gostai Studio?

  Gostai Studio Suite is a set of two graphical programming tools: Gostai Studio and Gostai Lab. Gostai Studio is an editor for hierarchical finite state machines (HFSM), which is a very common way to represent a robot behavior as a series of states connected by transitions, which are associated to conditions. For example, you can be in a ’search the ball’ state, and move to the ‘follow the ball’ state through a transition that is attached to the ’see the ball’ condition. Gostai Studio includes a debugger, and since it is based on urbiscript underneath, it is able to do some very sophisticated things, like pause the execution, trace the current state in realtime, and of course run many things in parallel. It’s really a unique implementation of the classical HFSM approach, which is standing apart.

  Gostai Lab is a user interface (UI) generator. You can create a UI by drag&dropping widgets on a blank sheet, each widget being associated to a variable in urbiscript that you want to monitor. You can create a widget for a camera, another for a numerical value, seen as a slider, another one could be a button that you associate to some urbiscript code to execute, etc. At the end, you can design a complete application in a completely graphical way. It saves a lot of time, and since it is based on a client/server approach, you can have many instances running in parallel and monitoring different aspects of your robot or algorithms.

• What is GostaiNet?

  GostaiNet is a cloud architecture for robotics. It allows to manage and remotely execute services for robots on distant servers, lowering the need for powerful and expensive CPU inside robots, and opening the door to web-based services and interactions.

  GostaiNet is operational and used by selected clients and also internally for some of Gostai’s own projects.

• Where can developers get Urbi?

  The community site is on www.urbiforge.org, where you can get Urbi for free, plus many modules, components, help on the forum, etc. You can also go to www.gostai.com to get a trial version of Gostai Studio, which is a product that we sell.

I hope this helps to provide a basic introduction to what Urbi and its creator, Gostai, are all about. Although I have not yet used Urbi in my own research efforts, I plan to give it a try and will post my experiences when I get further into it.

Enjoy!
Billy McCafferty

So far, I have found ROS to be logical, concise and easy to use (after going through all of the tutorials and practicing with it a bit). Honestly, I’ve found it to be more intuitive and tractable (i.e., more enjoyable to work with) than Microsoft Robotics Developer Studio; albeit, I have not yet used the 2008 R3 release and intend on giving Microsoft RDS a more concerted and focused go around. While both RDS and ROS support messaging design patterns, so far I’m leaning towards ROS as a better enabler for cleanly separating components (e.g., ROS package) from the messaging middleware.

One of the most daunting tasks of getting up to speed with ROS is learning and understanding the plethora of available commands and sequences of commands for performing common tasks. Fortunately, the ROS documentation – which is continually improving at a very fast rate – now includes a comprehensive cheat sheet for referencing ROS commands. Since I began using ROS, I’ve been maintaining my own cheat sheet which describes (my) most commonly used commands, descriptions of use, and example invocations (unsurprisingly, there is a lot of overlap with ROS’ cheat sheet).

With my spreadsheet, I’ve also begun keeping track of common sequences of commands within my cheat sheet as a quick means to look up what series of commands are necessary to perform a common task, such as creating a new service from an existing one. This kind of information is certainly available via the ROS documentation, but keeping it consolidated has been a great help in reducing searching around for it. Finally, I also like to keep track of a glossary of common terms and other useful ROS info.

As it has for me, you may find my ROS cheat sheet (an OpenOffice spreadsheet) as a useful starting point for maintaining your own list of common-sequences-of-commands and other at-your-finger-tips information for quickly navigating through ROS capabilities.

Enjoy!
Billy McCafferty

In Architectural Paradigms of Robotic Control, I discussed a number of control architectures with a bias towards a hybrid approach, for facilitating reactive behaviors without precluding proper planning. With 3T, a common hybrid approach, the three layers include a skill layer for reactive behavior and actuator control, a sequencing (or execution) layer for sequencing behaviors based on relevant conditions, and a planning (or deliberative) layer for making plans for future actions.

While the skill layer is typically developed in a low level language such as C++, the sequencing and planning layers frequently require a “higher” language to manage complexity and required flexibility. (E.g., a language using XML to express and execute first-order predicate logic without worrying about the low level implementation details of C++ control structure could be considered a “higher” language.) Indeed, Douglas Hofstadter, in his classic work Gödel, Escher, Bach, suggests that such higher level languages will most certainly be a prerequisite for developing more intelligent machines.

ESL (Execution Support Language), developed by Ron Garret (the artist formerly known as Erann Gat), is one such higher language, built on Lisp, for the implementation of the sequencing layer of a hybrid control architecture. ESL is discussed in both Artificial Intelligence and Mobile Robotics and Springer Handbook of Robotics as being a language which:

• Supports hierarchical decomposition of tasks into subtasks
• Supports design by contract (pre/post conditions)
• Supports signaling of state changes
• Supports clean-up procedures
• Exhibits robust execution monitoring and exception handling
• Includes symbolic database (world model) for linking environment to behavior layer

After looking around for an implementation of ESL, I contacted Dr. Garret to find out where I might be able to find it. Amiably, Ron has made ESL available for download from his site. While I admit that I have not yet used ESL, I look forward to digging into Ron’s code to learn more about this seemingly solid approach to developing and managing a proper sequencing layer.

While I am also familiar with Task Description Language (TDL) as an alternative to ESL, I am quite interested in hearing about any other approaches actively being taken to managing the sequencing/execution layer. I’ll certainly post more about ESL or other options as I research more on this topic. Incidentally, I’m also looking forward to digging into Herbal for the planning layer…but that’s for another post altogether!

Enjoy!
Billy McCafferty

Part IV: Developing and Testing the Application Services

[Author's note, July 28, 2010: Introduced Boost::shared_ptr to manage reference to message endpoint so as to enable postponed construction, as will be required in Part VI.]

Ah, we’ve made it to the application services layer.  After defining the architecture, setting up the package, and implementing the core layer which contains the domain logic of the application, we’re ready to take on developing the application services layer.  In short, the service layer provides the external API to the underlying domain layer.  Ideally, one should be able to develop the entirety of the “non-UI” portions of an application and have it exposed via the application services layer.  In other words, one should be able to swap out the front end – say from a web front end to a Flash front end – without having the application services layer effected. If you’d like to go ahead and download the source for this article, click here.

The application services layer is analogous to a task or coordination manager; i.e., it doesn’t know how to carry out the low level details of a particular action but it does know who is responsible for carrying out particular tasks.  Accordingly, the application services layer of the package (or any application for that matter) is mostly made up of a number of publicly accessible methods which, in turn, pass responsibilities on to external service dependencies (e.g., a message endpoint) and the domain layer for execution.

With that said, the services layer should still eschew direct dependencies on external services, such as communications with a messaging framework (e.g., ROS).  Accordingly, in this post, we’ll materialize the application services layer of our package and give it two responsibilities:

• Coordinate with the domain layer to begin laser report reading and handle the raised reports, accordingly;
• Forward laser reports on to the appropriate message endpoint(s) to have the information disseminated over the message based system.

But (there’s always a “but” isn’t there), while the application services layer should be responsible for passing messages received from the domain layer on to the messaging middleware, it should not have a direct dependency on that messaging middleware itself.  This decoupling facilitates testing of the application services layer with test doubles, keeps a clean separation of concerns between task coordination and messaging, and provides greater flexibility with being able to modify/upgrade the messaging layer without affecting the application services layer.

A moment needs to be taken to clarify the differences among application services, domain services, and “external resource” services.

• Application services are our current concern.  The word “services” in their convoluted title is misleading and should not be inferred as being web services, RESTful services, or the like.  A better name for describing the application services responsibilities is “task coordination layer,” “workflow management layer,” or “not-real-services application services layer.”  We’ll examine a bit in this post exactly how the application services layer can be properly leveraged.
• Domain services are really utility classes used by the core layer (the concern of our previous post) for processing data or encapsulating a specific, reusable task or behavior.  Domain services almost never have state (i.e., properties) and sometimes expose behavior as static methods.  A good example of a domain service would be a calculator class (e.g., Kalman filter calculator) or a string utility class.
• External resource services are what we typically think of when we hear the word “service.”  An external resource service is any class which depends upon…well…an external resource.  Examples of an external resource include databases, resource files (e.g., maps), messaging middleware, third party web services, and even the laser reading class that we simulated in Part II of this series.  Ideally, external resource services should be abstracted, allowing consumers of the services to interact with them via interfaces or abstract classes.  In this way, layers remain decoupled from the implementation details of the services, reflecting the benefits of proper OOP design.  Proper abstraction of service layers usually involves separated interface and dependency injection.  We’ll see in this post how these techniques are leveraged to decouple the application services layer from the message endpoints (which are indeed external resource services).

Before we delve in, let’s briefly review what we plan to accomplish:

• An application service class – LaserScanReportingService – will be developed to provide a public API for starting and stopping the laser reader.  In addition to exposing this behavior, the class will also listen for laser scan reads and pass the laser scans onto a message endpoint for publication to ROS.
• A message endpoint interface will be introduced to provide an abstraction to the implementation details of the concrete message endpoint itself.  The application service class will communicate with the message endpoint via this abstraction to allow for unit testing the application services layer in isolation of the messaging middleware.
• Unit tests will be written to verify the functionality of the application service class.  Furthermore, a message endpoint test double, a stub in this case, will be added to simulate communications with the messaging middleware.  Again, this will allow us to verify the task coordination behavior of the application services layer without concerning ourselves with messaging middleware integration details.

Enough with the chatter, let’s see some code!

Target Class Diagram

The following diagram shows what the package will look like after completing the steps in this post. While the individual elements will be discussed in more detail; the class diagram should serve as a good bird’s eye view of the current objectives. The elements with green check marks were completed in previous posts.

1. Setup the Package Skeleton and Domain Layer

If not done already, follow the steps in Part II and Part III to create the package and develop/test the domain layer.

2. Create an interface for the message endpoint service which the application service layer will leverage to communicate with ROS.

Create src/core/message_endpoint_interfaces/ILaserScanEndpoint.hpp containing the following code:

// ILaserScanEndpoint.hpp
 
#ifndef GUARD_ILaserScanEndpoint
#define GUARD_ILaserScanEndpoint
 
#include "sensor_msgs/LaserScan.h"
 
namespace ladar_reporter_core
{
  class ILaserScanEndpoint
  {
    public:
      // Virtual destructor to pass pointer ownership without exposing base class [Meyers, 2005, Item 7]
      virtual ~ILaserScanEndpoint() {}
      virtual void publish(const sensor_msgs::LaserScan& laserScan) const = 0;
  };
}
 
#endif /* GUARD_ILaserScanEndpoint */

There shouldn’t be anything too surprising in this interface.  It simply exposes a method to publish a laser scan to the underlying messaging middleware.  Why not put the interface in the application services layer, which intends to use it?  A couple of good reasons come to mind: 1) since it’s a pure interface, having elements within core aware of it (or even directly dependent upon it) does not introduce any further coupling to the underlying external resource, the messaging middleware, and 2) in very simply packages, an application services layer might be overkill, so keeping the “external resource service interface” (there’s a mouthful) in the core layer facilitates either approach without having to move anything around if the selected approach changes during development.

3. Create the application service header class.

Create src/application_services/LaserScanReportingService.hpp containing the following code:

// LaserScanReportingService.hpp
 
#ifndef GUARD_LaserScanReportingService
#define GUARD_LaserScanReportingService
 
#include <boost/shared_ptr.hpp>
#include "ILaserScanEndpoint.hpp"
 
namespace ladar_reporter_application_services
{
  class LaserScanReportingService
  {
    public:
      explicit LaserScanReportingService(boost::shared_ptr<ladar_reporter_core::ILaserScanEndpoint> laserScanEndpoint);
 
      void beginReporting() const;
      void stopReporting() const;
 
    private:
      // Forward declare the implementation class
      class LaserScanReportingServiceImpl;
      boost::shared_ptr<LaserScanReportingServiceImpl> _pImpl;
  };
}
 
#endif /* GUARD_LaserScanReportingService */

A few notes:

• Line 7:  Includes the previously defined message endpoint interface.
• Line 14:  Provides a constructor for the application service class, accepting an implementation of ILaserScanEndpoint, accordingly.
• Lines 16-17:  Exposes methods for exposing behavior found within the core layer.
• Lines 21-22:  Declaration for a pImpl (private implementation) that will allow the application service class to be updated frequently while minimizing the rebuilding of other class libraries which depend upon it.  Using the pImpl pattern will likely be overkill in smaller packages, but can be an appreciable timesaver as packages grow in size. It has been included in the sample code here as a example reference for when it might be more appropriately required.

4.  Create the application service implementation class.

Create src/application_services/LaserScanReportingService.cpp containing the following code:

// LaserScanReportingService.cpp
 
#include "sensor_msgs/LaserScan.h"
#include "ILaserScanListener.hpp"
#include "LaserScanReader.hpp"
#include "LaserScanReportingService.hpp"
 
using namespace ladar_reporter_core;
 
namespace ladar_reporter_application_services
{
  // Private implementation of LaserScanReportingService
  class LaserScanReportingService::LaserScanReportingServiceImpl : public ladar_reporter_core::ILaserScanListener
  {
    public:
      explicit LaserScanReportingServiceImpl(boost::shared_ptr<ILaserScanEndpoint> laserScanEndpoint);
 
      void onLaserScanAvailableEvent(const sensor_msgs::LaserScan& laserScan) const;
      LaserScanReader laserScanReader;
 
    private:
      boost::shared_ptr<ILaserScanEndpoint> _laserScanEndpoint;
  };
 
  LaserScanReportingService::LaserScanReportingService(boost::shared_ptr<ILaserScanEndpoint> laserScanEndpoint)
    : _pImpl(new LaserScanReportingServiceImpl(laserScanEndpoint)) {
 
    // Wire up the reader to the handler of laser scan reports
    _pImpl->laserScanReader.attach(*_pImpl);
 }
 
  LaserScanReportingService::LaserScanReportingServiceImpl::LaserScanReportingServiceImpl(boost::shared_ptr<ILaserScanEndpoint> laserScanEndpoint)
    : _laserScanEndpoint(laserScanEndpoint) { }
 
  void LaserScanReportingService::beginReporting() const {
    _pImpl->laserScanReader.beginReading();
  }
 
  void LaserScanReportingService::stopReporting() const {
    _pImpl->laserScanReader.stopReading();
  }
 
  void LaserScanReportingService::LaserScanReportingServiceImpl::onLaserScanAvailableEvent(const sensor_msgs::LaserScan& laserScan) const {
    // Send laserScan to the message end point
    _laserScanEndpoint->publish(laserScan);
  };
}

A few notes:

• LaserScanReportingService::LaserScanReportingServiceImpl defines the pImpl implementation.  As shown, this pImpl implementation accepts a ILaserScanEndpoint via its constructor and also adds members for communicating with LaserScanReader and with the provided message end point.  As discussed earlier in this post, it’s preferable to abstract dependencies on external resource services using interfaces or abstract classes, as was done with ILaserScanEndpoint.  Quite arguably, LaserScanReader is also an external resource service.  But since the core of our package is in providing a means to read laser scans from a particular laser range finder, I made a purity concession, if you will, allowing the application services layer to have a direct dependency on the reader itself.  Alternatively, an interface could be introduced for the LaserScanReader; but since the very heart of this package is in reading and reporting laser scans, I felt this concession to be warranted…or at least justifiably defendable.  With that said, concessions such as this should be carefully thought out and discussed with the project team to determine the pros and cons of either approach and to ensure that everyone has a clear understanding of the motivations of the decision.  (If the team – or yourself – does not understand or can explain why an architectural decision was made, it’s a good chance that the architectural decision will not be adhered to or may become a source of code rot.)

  The other item to note is that the pImpl class implements ILaserScanListener; accordingly, this class will act as the observer for receiving and handling laser scan reports raised from LaserScanReader.

• The constructor of LaserScanReportingService accepts a reference to ILaserScanEndpoint, passes that reference on to the constructor of LaserScanReportingServiceImpl and attaches the observer to LaserScanReader to listen for raised laser scans.
• The constructor of LaserScanReportingServiceImpl accepts a reference to ILaserScanEndpoint and initializes the laserScanEndpoint member to that reference, accordingly.
• beginReporting and stopReporting provide pass through methods to the underlying behavior exposed by laserScanReader.
• Finally, onLaserScanAvailableEvent provides an event handler to accept a laser scan from LaserScanReader and pass it on to laserScanEndpoint’s publish function.

As mentioned previously, the above implementation could be done without a private implementation design pattern, but this serves to illustrate how such a pattern may be leveraged when warranted.

5. Configure CMake to Include the Header and Implementation

With the header and implementation classes completed, we need to make a couple of minor modifications to CMake for their inclusion in the build.

1. Open /ladar_reporter/CMakeLists.txt. Within the include_directories statement, add an include for the following directory to include the message endpoint and application service headers:

   "src/core/message_endpoint_interfaces"
   "src/application_services"

2. Open /ladar_reporter/src/CMakeLists.txt. Add an inclusion for the application_services directory at the end of the file:

   add_subdirectory(application_services)

3. Now, in order to create the application services class library itself, a new CMake file is needed under /ladar_reporter/src/application_services. Accordingly, create a new CMakeLists.txt under /ladar_reporter/src/application_services, containing the following:

   # Create the library
   add_library(
     ladar_reporter_application_services
     LaserScanReportingService.cpp
   )

6. Build the application services Class Library

In a terminal window, cd to /ladar_reporter and run make. The class library should build and link successfully.

Like before, we’re not done yet…it’s now time to test our new functionality.

7. Unit Test the LaserScanReportingService Functionality

When we go to test the functionality of the laser scan reporting application service, it will likely be quickly noticed that there’s a missing dependency which will be needed to test the functionality of this class: a concrete implementation of ILaserScanEndpoint.hpp. The job of the message endpoint class will be to take laser scans and publish them to the appropriate topic on ROS. But we’re just not there yet…what we’d really like to do is to be able to test the functionality of the application service layer – LaserScanReportingService.cpp to be specific – without necessitating the presence of the message endpoint and ROS itself. While we’ll have to cross that bridge eventually (in Part V to be exact), we’re not currently interested in doing integration tests. Instead, we’re only interested in testing the behavior of the application service regardless of its integration with ROS.

Accordingly, a “stub” object will be employed to stand in for an actual message endpoint. In this case, the stub object is nothing more than a concrete implementation of ILaserScanEndpoint.hpp; but instead of publishing the laser scan to ROS, it’ll do something testable, such as keep a tally, or possibly a temporary queue, of laser scans “published” which can then be verified with testing asserts. If you’re new to unit testing, you’ll want to read about test doubles, Martin Fowler’s Mocks Aren’t Stubs, and XUnit Test Patterns for a more comprehensive treatment of the subject.

Onward with testing…

1. Create /ladar_reporter/test/message_endpoints/test_doubles/LaserScanEndpointStub.hpp containing the following code to declare and define the message endpoint stub:

   // LaserScanEndpointStub.hpp
    
   #ifndef GUARD_LaserScanEndpointStub
   #define GUARD_LaserScanEndpointStub
    
   #include "sensor_msgs/LaserScan.h"
   #include "ILaserScanEndpoint.hpp"
    
   namespace ladar_reporter_test_message_endpoints_test_doubles
   {
     class LaserScanEndpointStub : public ladar_reporter_core::ILaserScanEndpoint
     { 
       public:
         LaserScanEndpointStub()
           : countOfLaserScansPublished(0) { }
    
         void publish(const sensor_msgs::LaserScan& laserScan) const {
           countOfLaserScansPublished++;
    
           // Output the laser scan seq number to the terminal; this isn't the
           // unit test, but merely a helpful means to show what's going on.
           std::cout << "Laser scan sent to LaserScanReceiver with angle_min of: " << laserScan.angle_min << std::endl;
         };
    
         // Extend ILaserScanEndpoint for unit testing needs.
         // May be modified by const functions but maintains logical constness [Meyers, 2005, Item 3].
         mutable int countOfLaserScansPublished;
     };
   }
    
   #endif /* GUARD_LaserScanEndpointStub */

   If you’re paying attention (of course you are!), you’ll notice that this code looks very similar to the code used within the LaserScanReaderTests.cpp class’ fake event handler from Part III. In fact, it’s the exact same code but now it’s encapsulated within a message endpoint stub. Admittedly, this is not a very good testing endpoint (since it won’t make it easier to verify that the laser scans have been “published” via testing asserts), but it does provide an easy means to visually note, while the tests are running, how the message endpoint stub is behaving. More importantly, seeing the laser scans output to the screen will show the application service layer is interacting with the message endpoint appropriately…which is exactly what we’re trying to verify.

   While the LaserScanEndpointStub class could have been coded inline within the unit test class (discussed next), encapsulating it within an external class allows the stub to be reused by other tests as well. This may not be necessary in all cases – in which coding it inline would be just fine – but I typically find myself reusing stubs and mocks to avoid duplicated code in my testing layer; besides, keeping it within an external test double keeps the code arguably cleaner.

2. Create /ladar_reporter/test/application_services/LaserScanReportingServiceTests.cpp containing the following testing code:

   // LaserScanReportingServiceTests.cpp
    
   #include <gtest/gtest.h>
   #include "LaserScanEndpointStub.hpp"
   #include "LaserScanReportingService.hpp"
    
   using namespace ladar_reporter_application_services;
   using namespace ladar_reporter_test_message_endpoints_test_doubles;
    
   namespace ladar_reporter_test_application_services
   {
     // Define the unit test to verify ability to leverage the reporting service using the messege endpoint stub
     TEST(LaserScanReportingServiceTests, canStartAndStopLaserScanReportingService) {
       // Establish Context
       boost::shared_ptr<LaserScanEndpointStub> laserScanEndpointStub =
         boost::shared_ptr<LaserScanEndpointStub>(new LaserScanEndpointStub());
       LaserScanReportingService laserScanReportingService(laserScanEndpointStub);
    
       // Act
       laserScanReportingService.beginReporting();
       sleep(2);
       laserScanReportingService.stopReporting();
    
       // Assert
    
       // Since we just ran the reader for 2 seconds, we should expect a few readings.
       // Arguably, this test is a bit light but makes sure laser scans are being pushed 
       // to the message endpoint for publication.
       EXPECT_TRUE(laserScanEndpointStub->countOfLaserScansPublished > 0 &&
         laserScanEndpointStub->countOfLaserScansPublished <= 10);
     }
   }

3. Open /ladar_reporter/test/CMakeLists.txt. Modify the contents to reflect the following:

   include_directories(
     "message_endpoints/test_doubles"
   )
   
   rosbuild_add_executable(
     ladar_reporter_tests
     TestRunner.cpp
     ./core/LaserScanReaderTests.cpp
     ./application_services/LaserScanReportingServiceTests.cpp
   )
   
   rosbuild_add_gtest_build_flags(ladar_reporter_tests)
   
   # Link the libraries
   target_link_libraries(
     ladar_reporter_tests
     ladar_reporter_application_services
     # Important that core comes after application_services due to direction of dependencies
     ladar_reporter_core
   )

4. With everything in place, head back to the terminal and run:

   make
   cd bin
   ./ladar_reporter_tests

While running the tests, you should see a few messages published to the message endpoint stub. This demonstrates that all of the interactions among our core and application service layers are occurring exactly as expected. Now for the fun part…

In Part V, we’ll finally take a look at using all of these pieces together in order to publish messages to a ROS topic via a message endpoint.

Enjoy!
Billy McCafferty

Download the source for this article.

Whether ROS and other recent moves have had a direct impact on the decision or not, it looks like Microsoft is getting the message that professional robotics software isn’t just the realm of licensed, proprietary software, but frequently supported by world class software solutions which are often free and open source. In a step in this direction, Microsoft has released Microsoft 2008 Robotics Developer Studio (RDS), making it available completely free of charge with all of the bells and whistles provided with the previous standard edition.

http://www.microsoft.com/robotics/

Enjoy!
Billy McCafferty