Warning: strlen() expects parameter 1 to be string, array given in /home/sharpr6/public_html/wp-content/themes/starscape/code/starscape.php on line 450
Tools | SharpRobotica.com - Sharp ideas for the software side of robotics
Posts Tagged ‘Tools’

Simulation Environments for Mobile Robotics

datePosted on 05:23, August 3rd, 2010 by 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

Q&A of Urbi, a Robot OS

datePosted on 18:32, July 16th, 2010 by Billy McCafferty

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

Sequencing Layer with ESL (Execution Support Language)

datePosted on 00:06, July 13th, 2010 by 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

Microsoft RDS R3 Now Available…and free (as in beer)!

datePosted on 17:47, May 20th, 2010 by Billy McCafferty

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

Including Boost.Test in Your C++ Project

datePosted on 05:08, April 20th, 2010 by Billy McCafferty

It’s certainly hard to find much fault with the libraries of Boost.  They’re easy to include, they add a terrific amount of power to the STL, and they come with extensive documentation and a thriving community to boost your efforts.  (Awkward pun intended.)  Just about the only library (so far) that I’ve had a hard time finding clear, concise, introductory materials on is Boost.Test.  Boost.Test is a terrific library for facilitating unit testing with your C++ project.  Once you get it setup in your project, Boost.Test makes it very easy to develop and organize unit tests for your project.  But while the Boost.Test documentation will make you a guru with the library, it’s quite a bit lacking in guiding you in getting it going in your project for the very first time.  Googling for direction will lead you (er…led me anyway) down a number of paths which seemed to be overly complex…hopefully this post will help a few people in a similar situation that I was in.

What follows are the fewest steps that I was able to determine for including Boost.Test in your C++ project.  My setup was using CMake 2.8 on Ubuntu 9.04.

  1. Download and install Boost following Boost’s online documentation.
  2. Create a folder for your tests, e.g., my_project_tests and include a file in it called TestRunner.cpp containing the code below.   When compiled, this “main” class invokes Boost to generate a true main() function for your unit tests and establishes the central testing module.  TestRunner.cpp won’t actually contain any tests, it simply consolidates initialization code that would otherwise be duplicated across your test files and better allows them to be run together.
    #define BOOST_TEST_DYN_LINK
    
    #define BOOST_TEST_MODULE "my_project Unit Tests"
    #include <boost/test/unit_test.hpp>
    
  3. Create a file called ExampleTests.cpp in the same folder containing the code below.  This is taken directly from the Boost.Test tutorial with the omission of the test module #define, which was done via TestRunner.cpp.  To add any more tests, you simply create new .cpp files to hold the respective tests and include a reference to the files in your CMakeLists.txt file, as described in the next step.  But first, ExampleTests.cpp:
    #include <boost/test/unit_test.hpp>
    
    int add( int i, int j ) { return i+j; }
    
    BOOST_AUTO_TEST_CASE( my_test )
    {
      // seven ways to detect and report the same error:
      BOOST_CHECK( add( 2,2 ) == 4 );        // #1 continues on error
      BOOST_REQUIRE( add( 2,2 ) == 4 );      // #2 throws on error
    
      if( add( 2,2 ) != 4 )
         BOOST_ERROR( "Ouch..." );            // #3 continues on error
    
      if( add( 2,2 ) != 4 )
        BOOST_FAIL( "Ouch..." );             // #4 throws on error
    
      if( add( 2,2 ) != 4 ) throw "Ouch..."; // #5 throws on error
    
      BOOST_CHECK_MESSAGE( add( 2,2 ) == 4,  // #6 continues on error
        "add(..) result: " << add( 2,2 ) );
      BOOST_CHECK_EQUAL( add( 2,2 ), 4 );      // #7 continues on error
    }
  4. In the folder containing TestRunner.cpp, create a CMakeLists.txt containing the code below; this assumes that the CMake version and your project name is defined in a CMakeLists.txt in a parent folder.
    # Include subdirectories for headers
    include_directories(
     "/usr/local/boost_1_42_0"
    )
    
    # Create the unit tests executable
    add_executable(
     my_project_tests
     # Key includes for setting up Boost.Test
     TestRunner.cpp
     # Just for handy reference
     ExampleTests.cpp
    )
    
    # Link the libraries
    target_link_libraries(
     my_project_tests
    
     # "mt" designates that multi-threaded is supported with this Boost library
     boost_unit_test_framework-mt
    )
    
  5. Now, simply cmake, make and run the resulting executable to run your unit tests.

Happy testing!

Billy McCafferty

Karto Mapping Goes OSS and now Integrates with ROS!

datePosted on 23:24, April 19th, 2010 by Billy McCafferty

The past year has been very exciting watching the momentum that’s been building behind Willow Garage‘s Robot Operating System (ROS).  While ROS is going in a very good direction, its introduction to the market arguably made it just “that much harder” for developers to select which platform to use for the software backbone of their mobile robotic platform.  For example, when one looks for software options for the implementation of SLAM, there is a plethora of possibilities including numerous proprietary and open-source options.  While nodes have been specifically developed for ROS to provide SLAM capabilities, it’s terrific news to see that Karto mapping, by SRI International, has gone open-source and has worked with Willow Garage to be integrated with ROS’ navigation stack.

In addition to being integrated with ROS, going open-source opens the door for this solid SLAM component to become fully integrated with other robotics software backbones such as Orca, Carmen, and Urbi Forge, to name a few.

The original announcement may be found at http://www.ros.org/news/2010/04/karto-mapping-now-open-source-and-on-coderosorg.html.

Enjoy!
Billy McCafferty

© 2011-2014 Codai, Inc. All Rights Reserved