Community:Science/Robotics/GameEngineFeaturesForRobotics

Game engine capabilities

The game engine has already quite a lot of functions and capabilities that are useful in a robotics context. To start with, the game engine is built around the concepts of sensor, controller and actuator, which is already a perfect with what we are used to in robotics.

The list of sensors, controllers and actuators as in Blender 2.42 is here: http://wiki.blender.org/index.php/Doc:Tutorials/Game_Engine/BSoD/Sensors,_Controllers,_Actuators Newer versions have some new features that will be discussed below.

First of all, you can already program a robot to do its required actions with the built-in primitives, via the 'pacman' button on the buttons panel. You can add controllers as well. As of Blender 2.48a, this controller is a Finite State Machine (FSM). With the 30 available states, you can certainly realise already impressively complex behaviours.

FSM capability

Each object has 30 states available. These states contain controller logic (logic gates or a Python script). States can be enabled or disabled with the state's Actuator. There are four options:

• add - activates the indicated states to the controller of the next run, but keeps those that are on activated.
• sub - deactivates the indicated states from the controller if they were previously activated.
• cpy - activates the indicated states and deactivates the non-indicated states.
• inv - inverts the states.

The state actuator can be driven through a Python script, so huge amounts of possibilities arise.

Note that editing a sensor or actuator for one state, also changes it in all other states. For instance, I have a keyboard sensor for the uparrow in one state, and I need a sensor for the downarrow in another state. You can't reuse that sensor because the controller is state dependent!

Adding robots together

Once you completed modeling your robots and there needed actions in the game engine, you might want to test the interaction of multiple robots. (Importing .blend files into another .blend files is done through Shift-F1). Since robots can have different scales (since the Blender unit is not standardized...), or are differently oriented, you might have to scale one to the other or turn it. You should check the orientation of your sensors and actuators at this point. Since sometimes they are relative to the world, and sometimes they are relative to the object. (Note Herman: we should probably come up with a standard policy.)

Message passing

Since all your robots interact with the environment, changing the environment with one robot can change the actions by the other robot. In this way the robots can already interact.

In addition, there is an explicit message passing infrastructure already included in the game engine, since there are message sensors and message actuators. At a certain trigger point, a message actuator can be enabled. For example: an always-on-sensor enables a Python script that reads data external to Blender, and at the desired moment the message is broadcast to all Blender objects. In this way, events could already be simulated without the Event infrastructure in the new 2.5 Blender.

Scripting in the Game Engine

The moment you start the game engine. The world needs to be accessed through the Game Engine API. This changes every action needed to manipulate the world. In first place you want to access the armature joints. So you could easily pose it. This needs to be done with quite some care. An example is available at: http://users.vtk.be/~s0180879/rx130-message.blend (You need Blender 2.49 for opening this file)

So how to do it:

1. First set up your model.
2. Add an action Actuator. The name of this action actuator is important later.
3. Open the action Menu.
4. Set a keyframe on the object you want to modify.
5. Give the action a name (In the action header)
6. Link it through in the action Actuator.
7. Get the ChannelEditor.py
8. http://users.vtk.be/~s0180879/channelEditor.py
9. Make a controller module in the logic panel for the object you wish to manipulate
10. Make it a Python MODULE.
11. Make a setup script. Best to adjust the example to your needs (see MiddleWareAccess.py)
12. Add the channelEditors to a GameLogic Dictionnaire attribute (for easy access later on)
13. Set the changePose() for all channels to their starting conditions.
14. Add a script to start making your actual movements!

It's still quite some work. In the future we could add YARP or ROS or other middleware capabilities and control.