Some news from the Blender for Robotics project

Just a little over a year ago, we reported on the use of Blender for robotic simulations. Séverin Lemaignan was kind enough to send us an impressive update.

Séverin Lemaignan writes:

Hello BlenderNation!

A bit more than a year later, some update on the Blender for Robotics project! Behind the scenes, a lot of things did happen over the last months. Blender for Robotics is an effort from several European robotics lab to build over the Blender Game Engine a set of tools for roboticians, including a new, multi-purpose simulator.

The first round of developments was started at KU Leuven were Benoit Bolsee has been working for 6 months last year to rewrite the IK solver, with the GameEngine in mind, resulting in the so-called iTaSC branch. Demos here:

Shows how the new iTaSC IK solver can be used realtime in the Blender Game Engine (BGE) with external targets. The cone is the target that the robot tries to follow in position and orientation. In the first part of the movie the target moves with an Ipo action; in the second part, it is controlled by the keyboard. The movements of the robot is entirely automatic.

This video shows a realistic model of a complex robot controlled by the inverse kinematic algorithm iTaSC in Blender. There is one target for each hand and one for the head. These targets are moving cyclically and the robot is following automatically.
In the first 2 cycles, the auto step option is enabled with default max step of 60ms. This is too large, the robot is shaking.
The next 2 cycles, the max step is set at 40ms. This enough for stability but the movements are not totally smooth.
The last 2 cycles, the fixed step option is used with 4 steps per frame (=10ms steps). The movements are smooth at the expense of more CPU.

Then, a the beginning of July 2009, two full-time engineers, Nicolas Lassabe at ONERA and Gilberto Echeverria at LAAS-CNRS (both in Toulouse) started working on the simulator itself. We've called it OpenRobot Simulator (ORS).

ORS has been designed to be multi-purpose (simulation of field robotics, indoor robotics, multi-robots systems) and to allow simulation at different levels, from raw sensory output to higher-level semantic information on the sensor side, and on the actuator side, from raw elementary commands processed by the physics engine to higher level (less realistic) motions.

To build a robot, a set of Blender files (one for each sensor or actuator) are assembled together with a model of robotic base (we currently have outdoor iRobot ATRVs, a model of helicopter and a custom-made one-arm indoor robot).

Each sensor or actuator can work at different level of realism: for instance, a camera can be set to export the raw OpenGL buffer, a depth map, a pre-segmented image of even a "cognitive map" with the name and position of the objects the robot sees. This different level of realism are very important when working on big robotic project since each researcher may want to test its specific algorithms without the burden of running the complete processing stack.

For now, we can simulate mono and stereo cameras, laser scanners, gyroscopes and GPS. We have as well simple actuators to move robots by speed or through waypoints.

To be useful, a simulator must be able to communicate with the real robot control stack: this is usually achieved by relying on so-called middlewares that abstract the components of the robot (it is thus possible to replace a real camera by a simulated one without altering the vision algorithms that use the camera, for example). Since there is no standard middleware, ORS is planned to rely on an open-source tool currently developed at LAAS and called Genom3: Genom3 is a template-based module generator. Once the template has been written for a given middleware, all the simulator modules can be automatically generated. Simulator developers only need to write once the sensors and actuators and all the robotics community can use them.

This feature is not complete yet, and for the developement needs, we have implemented only two middlewares, YARP (and Orocos via YARP) and Pocolibs.

Some more videos:

http://vimeo.com/9825826">

Simple example of the ORS simulator. Robot 1 is given a list of waypoints to follow Robot 2 follows 1, and 3 follows 2

Demonstration of a simulated SICK laser range sensor. In this video, the sensor covers a range of 180 degrees, at a distance of 5 blender units. The sensor runs a scan once every 2 animation frames. (on this video, please note the screen on the wall that stream the robot camera thanks Benoit's VideoTexture extension)

By the way, as you've maybe noticed on the video, we are still transitionning from Blender 2.49 to Blender 2.5 (it was long because some features important to us weren't ported yet), but be assured that ORS will run on Blender 2.5!

OpenRobot Simulator is not ready yet for a broad diffusion (we will let you know when we release the version 1.0!). Mostly missing: a good documentation to explain of to build and start a simulation scene, a dedicated UI with drag&drop of components (robots, sensors, actuators...), integration with Genom3 and templates for other middleware like ROS (if some ROS dev are interested in helping, please drop a mail!), and a lot of polish! However, if you are in a hackish mood, you can check out the public GIT repository: git clone http://trac.laas.fr/git/robots/morse.git and hang on [email protected] (but please accept that we won't answer all user questions until we do a first official release!)