[Robotics] Middlewares

Paul Fitzpatrick paulfitz at alum.mit.edu
Mon Aug 31 17:43:22 CEST 2009


Stefaan michielsen wrote:
> Hi
>
> I've been looking at some middleware for blender robotics  the past 
> few days and i'm wondering whether there is a middleware without 
> having to write parsers for every junction in the system.
>
> On first hand, Verse seems like a good middleware. It brings out the 
> structures of blender. So no need for parsing. But  on the other hand, 
> it's an deserted project, and not every data structure of blender has 
> the support needed by us (for instance armatures are non-existent)
>
> At LAAS, yarp is used. I've been exploring the way yarp can help. But 
> it seems as though you have to write your own parser, for everything 
> you want to be able to do. As well I don't understand why yarp has 
> robotic in the name. Is there some bones data structure, or any other 
> robotic related data set? Or are bottles used as data containers.

No, I don't think anyone has written a bones data structure for YARP.  
YARP has built-in support for transporting fairly generic types of data 
-- images, audio, vectors, matrices, and s-expressions ("Bottles").  
Layered on top of that there are plenty of interfaces for physical 
robots, but they are all relatively low-level, and operate in joint 
space (so there's nothing like bones at this level).  People have done 
work on higher-level control, but would read the model of the robot from 
a configuration file rather than querying the robot itself.  The robot 
would just be queried for its current state.  See for example Ugo 
Pattacini's "iKin" project for the iCub humanoid:
  http://eris.liralab.it/iCub/dox/html/group__iKinSlv.html

It could definitely be useful to have a bones-like data structure.  If 
this were defined e.g. by this group, then I'd be happy to provide a 
YARP implementation of it.  It would be good to define such things in 
terms that are independent of a particular middleware.

> Are there middleware for blender that don't need parsing and are alive?

I don't know if anyone has used ROS yet with Blender, but it has an 
IDL-like language, see:
  http://www.ros.org/wiki/msg
You'd still need to write a list of the data you want sent, but the 
serialization code would get written for you.

> If not we should definitly start proposals for what data is to be 
> represented towards the middleware.
>
> Since i'm focusing on the *game engine*,  channels are the point of 
> interest.  These contain the information about the pose of a robot. So 
> this one should be accessible. This is my proposal for data 
> structure/management:
> - Each joint has it's channel.
> - Since location/size are not to be altered in a robot model while 
> running, these values are not to be transported.
> - Quaternion should be transported,as 4 floats
>
> Since the setChannel() of the BX_actionactuator doesn't seem to have a 
> read ability, I suggest using the channelEditor as wrapper. This 
> permits to retrieve info about a pose, while in game.
>
>  
> The list of channels are initialized the 1st iteration of the Game 
> Engine in a setup routine.
> Putting them in a dictionary in the GameLogic seems the proper way of 
> making them universally available. Example:
>
> def setup(self):
>     # Define your channelEditors here. This function will be called 
> only once
>     #   "key" : Value
>     # The channels should be changed through this variables.
>     # The changes come into effect only after a channel run() is executed
>    
>     GameLogic.channels = {"act1.axis1":ChannelEditor("act1","axis1"),
>                           "act1.axis2":ChannelEditor("act1","axis2"),
>                           "act1.axis3":ChannelEditor("act1","axis3"),
>                           "act1.axis4":ChannelEditor("act1","axis4"),
>                           "act1.axis5":ChannelEditor("act1","axis5")
>                          }
>
> Now you can access the pose rather easily. Each Middleware, can have 
> access to each channel simultaneously.

Wonderful!  I couldn't figure out how to do this.  Thanks Stefaan!

Cheers,
Paul



More information about the Robotics mailing list