I am pleased to present GNao, a Nao Robot simulated in Gazebo.
I have created GNao using Gazebo and we can control it with his own library (libgazebo) or with NaoOperator(an aplication created by Francisco Rivas).
GNao has the same height, weight and degrees of freedom that real Nao.
In this link you can see some videos.
Currently I am working on supporting modular robots in JDERobot 5.0. As a first example, I have created the Servo1 component. It is a virtual Y1 module that can be moved to any position in the range [-90,90]. It has been programmed using the OpenMR plug-in for OpenRave (in C++). The client is another C++ program that just let the user to type in the desired position for the servo.
ICE is used for the communication between the client and server.
Here there is a Video demostrantion. The sources can be found in this SVN repository.
We’re glad to present the first prototype of monoSLAM working inside jdeRobot platform.
MonoSLAM is for monocular Simultaneous Location And Mapping, a computer vision technique which permits to estimate in real-time the relative position of a moving camera with respect to several landmarks extracted from the environment, using only the image sequence that provides the camera.
It is potentially helpful in visual odometry for robots, specially for those whose mechanical odometry is poor (e.g. legged robotssuch as Nao). It can also be used for augmented reality systems and scene reconstruction from video sequences.
You will always find a video of the latest prototype by following this link:
Today, it seem impossible that we can’t control anything from our mobile device. I’m using JDEROBOT software to create a video-surveillance system based in software libre and low cost hardware.
A good feature for this system is the total control from the mobile device. In this case, we use a Android device (HTC Magic) and our problem is connect both systems: JDEROBOT (linux) and SecurityApp (Android). There are many options for this as: rpc, webservice (xml+soap) or some distributed framework. We opted for ICE (Internet Communications Engine) that is a distributed system based in definition of interfaces language.
“The Internet Communications Engine (Ice) is a modern object-oriented toolkit that enables you to build distributed applications with minimal effort. Ice allows you to focus your efforts on your application logic, and it takes care of all interactions with low-level network programming interfaces. With Ice, there is no need to worry about details such as opening network connections, serializing and deserializing data for network transmission, or retrying failed connection attempts (to name but a few of dozens of such low-level details).”
· The Android/Java Code: We try show the image captured by webcam in the Android mobile.
Ice.Communicator communicator = Ice.Util.initialize();
Ice.ObjectPrx base =
communicator.stringToProxy("varcolorA:tcp -h 193.147.51.113 -p 9999");
// Varcolor and Image are interfaces defined by us.
if (base == null)
Log.e("Main","Could not create proxy");
else
{
VarColorPrx vprx = VarColorPrxHelper.checkedCast(base);
if (vprx != null) {
ImageData image;
image = vprx.getData();
// In image variable we obtain the image data.
}
}
Easy, right? 
· The Result: The next photo shows how the android mobile can show the image captured by webcam. The webcam is connected to laptop where JDEROBOT is running.
Test Android-JDEROBOT-ICE
Some days ago I gave a talk at the University of Málaga on jderobot, describing its main features as middleware for robot programming. I was invited by Cristina Urdiales, from the Robotics and Artificial Vision Group of the Department of Electronic Technology.
You can find here the slides that I used in the presentation (in Spanish) . They provide a good overview of the current state of the jderobot project, its principles, foundations and software design. They also present the collection of currently available drivers, developed components, sample applications, etc.
Some time ago I made some tests on dlopened modules, trying to find some simple autoloading mechanisms. The usual way we were using dlopen was followed by a dlsym calls collection. This way you can get functions defined inside the module. But this forces the application to know the searched symbols names.
An easy way to avoid this is letting the module to register itself, providing some registering mechanism, on loading time. So the only requirement is some kind of constructor called inmediatelly after dlopen call. gcc function atributes in C and variable initialization through functions in C++ are really easy ways to get this pourpouse.
More info can be found here.
