User:Jvazquez

From jderobot

Jump to: navigation, search

Contents

Project card

  • Project Name: Collaboration in JDEROBOT 5.0 migration.
  • Authors: Javier Vázquez (javiervazper [at] yahoo [dot] es) and Jose María Cañas Plaza (jmplaza [at] gsyc [dot] es)
  • Academic Year: 2009-2010
  • Degree: Master
  • SVN Repository:
  • Tags: VFF
  • Technology: C, C++, JdeRobot, OpenGL, OpenCV, GTK, ICE
  • State: Developing
  • Schemas:

Jderobot collaboration grant

Improving FAQ

2010.2.5. How do I upload files?

JDErobot 5.0

2010.2.28 Installing JDErobot 5.0 on Linux Ubuntu 9.04

2010.3.5 JDErobot SVN folder organization

JDErobot 5.0 Migration

Introduction

(2010.3.5) The main target of TFM is to collaborate on jde-developers community for migrating the current version 4.3 to new 5.0. The aim of this change is to enable the execution of JDErobot on a distributed system architecture. ICE middleware is a key factor to achieve this target. It's make possible to implement previous drivers and schemans components as a individual software artefacts with communication interfaces across a TCP/IP computers network. ICE allows JDErobot components to easily set-up their server and client interfaces.

An additional benefic for using ICE platform is the fact of components can be implemented in different programming languages supported by ICE-translator package. At this moment, C/C++, Java, Python and some others are on the scope.

This collaboration activity will consist of incremental phases:

  • Engagement: To understand JDErobot 5.0 architecture based on new ICE middleware. Get depper on several 4.3 driver and schemas implementation details (i.e: gazebo driver).
  • Initial migration collaboration: To migrate part of a 4.3 driver component on the new version & architecture. To be complaint with global architecture design decissions.
  • JDERobot 5.0 component development: To take part on entire driver components examples migration.

Identified tasks for next weeks

(2010.6.30)

  • Implement introrob canvas area with laser and encoders visualization.
  • Documentation for TFM.
  • Support 2 cameras in gazeboserver.

JDERobot 5.0 component development

(2010.6.30) Implement introrob canvas area with laser and encoders visualization.

Canvas area was finally implemented as part of introrobgui interface. From this area, it's posible so show the robot, sonar and laser signals, grid area and reference coordinates. Any of them can be individually activated/desactivated. It's also possible to focos robot's position as center of canvas area or disable this option and select a different focus by using the canvas sroll bars. Finally, zoom capability is also exixsting and makes posible to precise the visualization area dimension.

This is an example of the result:


(2010.6.5) Add gazeboserver and introrob introduction in JDErobot 5.0 Manual

A brief introduction to these two components have been written in 5.0 Manual. The introductions also explain which are the provided/required interfaces (ICE/non-ICE), how they can be set up from their configuration files and what are the following improvements.

In the case of introrob, it's said how to use the graphical interface and how navigation logic can be changed, updating nagetación method, at navega class.

(2010.6.2) Implementation of 2D map on Introrob canvas area

At this moment, there is no yet a finished canvas area representing robot, laser and sonars, due to it's difficult to intregate gnome::Canvas component into introrob glade interface. This is due to currrent version of Glade, 3.7, doesn't support this and other gnome library component but only gkt ones. During two weeks, the author, has being investigating how this components can be used, from a c++ library called "libgnomecanvasmm" and trying to implement a grid representation. It has been also difficult to integrate gnome canvas with a ScrolledWindow, modelated in in Glade to achieve a final integrated representation.

It has been implemented a derivated version of Gnome::Canvas::Canvas class, called "introrobcanvas", in order to manage any robot ilustation on canvas area and to manage this elements from introrobgui class.

At this moment, canvas component is integrated withing introrob interface but there are two main tasks to be completed:

  • Solve "Segmentation Fault" issue when a introrobcanvas methed is invoked from introrobgui object. I don't understand yet why I get a segmentation abort when trying to call a specific method for representing the robot or move it across the grid. This problem is under investigation.
  • Implement the logic for representing laser, sonar and move focus of canvas area.

(2010.5.18) Upload gazeboserver and introrob to SVN repository

The components, new ICE interfaces and several changes on Makefile.am files and configure.in were sucessfully commited.

(2010.5.15) Re-Integrate introrob and gazeboserver with last JDErobot 5.0 version (download SVN)

The target of this activity is verify, before uploading gazeboserver, introrob components and several new interfaces to SVN repository, that the las JDE 5.0 version doesn't impact on my current developments.

However, just after synchronize my local repository and launch the compilation, I get the following error with gazeboserver component: 

gazeboserver.cpp: In member function ‘virtual void gazeboserver::Component::start()’:
gazeboserver.cpp:685: error: cannot allocate an object of abstract type ‘gazeboserver::CameraI’
gazeboserver.cpp:65: note:   because the following virtual functions are pure within ‘gazeboserver::CameraI’:
../../../src/interfaces/cpp/jderobot/camera.h:716: note: 	virtual std::string jderobot::Camera::startCameraStreaming(const Ice::Current&)
../../../src/interfaces/cpp/jderobot/camera.h:719: note: 	virtual void jderobot::Camera::stopCameraStreaming(const Ice::Current&)

It's due to one of the interfaces supported by gazeboserver is "camera", also used by other JDE 5.0 components such us cameraserver or cameraview. It seems some changes where added to camera interface definition and "startCameraStreaming" and startCameraStreaming" operations are not implemented in my gazeboserver code.

We added its definition with no logic but that's was enogh to solve the problem.

(2010.5.15) Extend gazeboserver component with "ptencoders", "ptmotors" and sonars interfaces

These three interfaces have been defined with the following operations and data classes:

  • PTMotors
    • Classes: 
class PTMotorsData
  {
  	float latitude;
  	float longitude;
  };
    • Operations: 
int setPTMotorsData(PTMotorsData data);
  • PTEncoders
    • Classes: 
class PTEncodersData
  {
  	float panAngle;
	float tiltAngle;
  };
    • Operations: 
idempotent PTEncodersData getPTEncodersData();
  • Sonars
    • Classes: 
  class SonarsData
  {
    IntSeq us;
	int numSonars;
  };
    • Operations: 
idempotent SonarsData getSonarsData();

Then, the three interfaces to gazebo sensors were implemented on gazeboserver's logic.

(2010.5.6) Develop "sigue pasillos" practise on JDErobot 5.0

In this development, introrobt and gazeboserver components are used. The navigation logic of pioneer robt only uses camera as sensor and motors as actuatos. It's a reactive algorithm based to measure some areas of the input image and decide what is the action to perform (translated to linear and radial speed orders).

To be more specific, an horizontal line, located at 3/4 of the image was splited into 3 segments (left, central and right). The lateral segments has 1/4 width of the image width, while the cetntral segment was 1/2 width. Additionally, the central pixel of this line (belogn to central segment) was monitorized.

The basic check consist of validate yellow percentage at lateral segments and yellow value at central line pixel. With these three data, it was possible to decide small ajudsments, while the robot is running within the corridor and to detect when a front wall is close (robot's is in a corner) and decide the spin sense.

(2010.5.4) Extend gazeboserver with rest of actuatos/sensors

Encoders interface is also added in gazeboserver component. The EncodersData class is implemented in order to support encoders data providing across this interface's functions. In the fisrt version of this interface, the same data available in 4.3 gazebo driver is contained, that means: robotx, roboty, robottheta, robotcos and robotsin.


(2010.5.2) Migrate "gato y raton" practise from JDERobot 4.3 to JDERobot 5.0

Once gazeboserver supports gazebo laser, camera and motors interfaces, it was posible to migrate "gato y raton" practise, from 4.3 to 5.0, as I did with "sigue linea roja". The only significat difficulty on this task was to identify my functions and variables, to support the navigation, and the interfaces with 4.3 camera, motors and laser. Then, perform the adaptation to C++ object design.

This is a capture of the result (also integrated in introrobot):


(2010.4.29) Implement "Laser" interface in gazeboserver component.


"Laser" interface is implemented on gazeboserver component as well. It was developed in two attemps: during the first, a simple interface "Laser" was specified, with one operation "getLaser", which just returned the distance, form the robot to the obstacle, in one angle. This solutions was poor in terms of performance due to for a 180º distances read (usually need by robot navigation algorithm on each iteration), required 180 remote method invocations. The fisrt tests, using an auxiliary client for that purpouse, were very bad.

During the second attempt, a class "LaserData" was defined. One of the attributes inside was an integer sequence, representing the different distances from robot to obstacles for each angle. The previous function "getLaser" was improved to return an object of this class. In this case, one one method incocation was enogh to receive 180 distances mesures. The new performance tests were acceptable.

Below, you can see a screen capture of introrobot GUI an stdoutput on console, were distances at 0º, 90º and 179º are written. They are obtained by calling to this service.

introrob component was also improved to instanciate an onject of Laser interface and have data available on each iteration.



(2010.4.25) Migrate "siguelinearoja" practise from JDERobot 4.3 to JDERobot 5.0, using introrob component


At this time, we had enogh infrastructure to import "sigue linea" logic into the new introrob component. Therefore, the target of this activity, was to migrate this practise and validate it in the new platform.

These are the results:



(2010.4.20) Version 1 of introrob component


At this point, it was very important to integrate camera view capability and motors actuatos interaction from a graphical interface. Moreover, the graphical interface could be design also to run robot navigation logic, which only depends of camera sensor and motors actuator.

Taking into account that JDERbotos 4.3 had an schema with this target (introrob), it was decided to migrate some capabilities of introrob 4.3 to 5.0 platform.

One of the changes, in term of GUI design, has been the graphical interface tecnology used. introrob 4.3 was implemented with FDesign, while, Glade and GTK libraries were selected in the new version.

The initial version keeps most of the buttons and panels but only implements the logic for camera visualization and Motors controlling. It's posponed, for a future release, the extension with player map visualization and scale and positions on the map.

As introrob made in the 4.3 version, the new component can switch the manual motors controlling to a automated mode, called "your code". When this option is pressed, introrob, launch some logic methods contained in "navigation" class, where the navigation and control logic is supposed to be.

Below, you can see a video capture where introrob is used on "manual" mode.


(2010.4.13) Development of gazebomotorsclient component


Before developing a graphical interface to access Motors interface, I developed an easy component called "gazebomotorsclient", which can be executed by commend line and it connects to gazeboserver, Motors interface, in order to retrievel V and W values of modified them.

Command line execution is very simple, due to no arguments could be specified for getting current V and W values and 2 real values could be written as arguments one and two, in order to update the speeds.

You can play the following video in order to see how it works and check the robots movement with cameraview component:

(2010.4.10) Extend gazeboserver component with Motors interface

One of the challengues of my next gazeboserver improvement was to extend it with a second interface for "motors" actuator of robot1. At this point, several ICE documentation articles were read in order to clarify how can be it done.

During this milestone archievement, a new ICE interface, called "Motors" was defines. In the initial version, it support four operations:

  • getV
  • getW
  • setV
  • setW

They will support the linear and radial speeds modification and status retrival.

Several tests were perform after its integration in gazeboserver component to validate that camera already worked and Motors was serving at the same time.


(2010.4.1) Finish version 1 of gazeboserver component


A new component has been developed, called "gazeboserver". The purpouse of this component is to server different gazebo platform interfaces for different robot's sensers and actuators. In the initial versión, gaseboserver focus on Pioneer robot and it sensor "camera".

In order to make this "camera" interface compatible with other JDERobot 5.0 components, such us, cameraview, the current "camera" interface used by "cameraserver" component was used in this case.

The result is a server component able to server gazebo robot1 camera to any "cameraview" process, pointing to this service.

Heareafte there is a video capture of gazeboserver and cameraview running:

Initial migration collaboration

(2010.3.23) Incorporate gazebocamera to JDErobot 5.0 project

One of the important activities has been to understand how JDErobot 5.0 is compiled by using autoconf tools and how to update its configuration in order to add additional componentes or options to the compilation process.

As an example of the learn lesson, these are the list of tasks that were necessary to incorporate gazebocamera to the project:

  • Additions to "m4" folder: This folder is used for auto tools configuration. The new component requirements have to be expresend at this locations by follows
    • Create file "libgazebo.m4": Due to gazebocamera calls some gazebo library functionalities, libgazebo becomes considered a required component in JDErobot 5.0. This file expreses what "configure" script has to ensure for this library. It enables the option "--with-gazebo" in the configuration process.
    • Create "component_gazebocamera.m4" with requirements. In includes gstreamer and libgazebo libraries check. Both are needed during the compilation.
  • Additions to "/" folder: At root folder, "configure.in" is keeping the global configuration for the version. Three references had to be added in this file:
    • add line "m4_include([m4/libgazebo.m4])" to libraries check section.
    • add "m4_include([m4/component_gazebocamera.m4])" to components check section.
    • add "src/components/gazebocamera/Makefile \" to components Makefiles generation section.
  • Additions to "src/components/": There is a file "Makefile.am" with references to the list of subdirectories that have to be processed by make utility.
    • Update the file "Makefile.am" with the reference to the new subfolder "gazebocamera"
      • "src/components/gazebocamera/" content organization: Apart of gazebocamera.cpp and gazebocamera.cfg files, a Makefile.am was created, in order to expecify the compilation rules and dependencies with dome libraries.


Content of "libgazebo.m4": 

dnl# Checks for gazebo

AC_ARG_WITH([gazebo],
    [AS_HELP_STRING([--with-gazebo=<path>],[gazebo library prefix path. Default /usr])],
    [],
    [with_gazebo="/usr"])

if test "x$with_gazebo" != xno; then
    GAZEBO_PREFIX=$with_gstreamer
    GAZEBO_INCLUDE="$GAZEBO_PREFIX/include"
    GAZEBO_CPPFLAGS="-I$GAZEBO_INCLUDE"
    AC_SUBST([GAZEBO_PREFIX])
    AC_SUBST([GAZEBO_INCLUDE])
    AC_SUBST([GAZEBO_CPPFLAGS])
                       
    _SAVE_CPPFLAGS=$CPPFLAGS
    CFLAGS="$CFLAGS $GAZEBO_CFLAGS"
    CPPFLAGS="$CPPFLAGS $GAZEBO_CPPFLAGS"

    AC_MSG_NOTICE([**** Checking gazebo support:])
    PKG_CHECK_MODULES(
	[GAZEBO],[gazebo],
	[
	    GAZEBO_CPPFLAGS=$GAZEBO_CFLAGS
	],
	[
	    AC_MSG_NOTICE([Errors found checking gazebo support: $GAZEBO_PKG_ERRORS. Try setting --with-gazebo])
	    with_gazebo="no"
	])

    CPPFLAGS=$_SAVE_CPPFLAGS
fi


Content of "component_gazebocamera.m4": 

dnl # Requirements for component gazebocamera
dnl # GStreamer, Gazebo

AC_ARG_ENABLE([component-gazebocamera],
    [AS_HELP_STRING([--disable-component-gazebocamera],
	    [disable gazebocamera component compilation])],
    [],
    [enable_component_gazebocamera=yes])


if test "x$enable_component_gazebocamera" != xno; then
    AC_MSG_NOTICE([**** Checking gazebocamera component requirements:])
    if test "x$with_gstreamer" = xno; then
	ERRORS="$ERRORS, gstreamer support not found. Try setting --with-gstreamer"
    fi
    if test "x$with_gazebo" = xno; then
	ERRORS="$ERRORS, gazebo support not found. Try setting --with-gazebo"
    fi
    if test "$ERRORS"; then
        AC_MSG_NOTICE([Errors found checking gazebocamera requirements: $ERRORS. Component disabled])
	AM_CONDITIONAL([ENABLE_COMPONENT_GAZEBOCAMERA],[false])
    else
	AC_MSG_NOTICE([Component enabled])
	ENABLED_COMPONENTS="$ENABLED_COMPONENTS gazebocamera"
	AM_CONDITIONAL([ENABLE_COMPONENT_GAZEBOCAMERA],[true])
    fi
fi


Content of "Makefile.am" (at gazebocamera folder): 

if ENABLE_COMPONENT_GAZEBOCAMERA
bin_PROGRAMS = gazebocamera
endif


gazebocamera_SOURCES = gazebocamera.cpp
gazebocamera_CPPFLAGS = $(LIBJDEROBOTICE_CPPFLAGS) \
				-I$(top_srcdir)/src/libs -I$(top_srcdir)/src/interfaces/cpp
gazebocamera_LDFLAGS = $(GAZEBO_LIBS)
gazebocamera_LDADD = $(top_srcdir)/src/libs/jderobotice/libJderobotIce.la \
			$(top_srcdir)/src/libs/jderobotutil/libJderobotUtil.la \
			$(top_srcdir)/src/libs/colorspaces/libcolorspacesmm.la \
			$(top_srcdir)/src/interfaces/cpp/jderobot/libJderobotInterfaces.la

dist_conf_DATA = gazebocamera.cfg

(2010.3.21) gazebocamera development and testing

Taking "cameraserver" component as a 5.0 reference, and "gazebo" jderobot 4.3 driver as logic implementation for accesing diferent sensors and actuators of pioneer robot in gazebo infrastructure, our first step was to develop a simple "gazebocamera" component with the following requisites:

  • Implement a server interface to access first gazebo camera.
  • Be compaint with jderobot 5.0 architecture design, where camera interface is used in the same way than cameraserver does.
  • Be able to test gazebocamera component with cameraview one.

During the design and implementation, the following considateration were taken into account:

  • Study design of cameraserver component in term of jderobot interfaces and common definitions usage (4 hours)
  • Analyze how cameraserver code could be reused for gazebocamera adaptation: remove gst and pipeline references, where to initialize and retrive camera data from gazebo, etc. (8 hours)
  • Study gazebo driver in jderobot 4.3 version and extract logic to access first camera (4 hours)
  • Implement new component reusing previous code (8 hours)
  • Clean up non-used cameraserver references to libraries, functions and objects such us pipeline. (2 hours)
  • Compile and testing with cameraview (3 hours)
  • Upload new code to SVN repository (jderobot 5.0 branch plus personal SVN repository) (2 hours)
  • Brieflty documentation at this page (1 hour).

Hereafter, there is a video of how gazebo, gazebocamera and cameraview can be launched at different terminals and communicate each other throw shared memory (gazebo - gazebocamera) and ICE (gazebocamera-cameraview).

Engagement

(2010.3.5) cameraserver-cameraview components compilation and testing

At the moment of this note, only cameraserver and cameraview components are developed and available at JDErobot 5.0 branch. As initial touchdown to 5.0, both elements are compiled and customized for testing. cameraserver code is also studied to understand how, 'Camera' interface is used. That's an important task due to the following activity will consist of creating gazeboserver component including just camera interface. Gazebo's Camera interface must be complaint with cameraserver one, that means, with Camera definition.

First step to compile cameraserver-cameraview is to produce c++ code from camera ICE interface definition: 

jvazquez@ubuntu:~/workspace/jderobot_5.0/src/interfaces/slice/jderobot$ echo $ICE_HOME
/home/jvazquez/workspace/jderobot_5.0/src/interfaces/slice
jvazquez@ubuntu:~/workspace/jderobot_5.0/src/interfaces/slice/jderobot$ slice2cpp -I$ICE_HOME camera.ice
jvazquez@ubuntu:~/workspace/jderobot_5.0/src/interfaces/slice/jderobot$ ls -ltr camera*
-rw-r--r-- 1 jvazquez jderobot  1180 2010-02-25 16:22 camera.ice
-rw-r--r-- 1 jvazquez jderobot 23134 2010-03-05 11:35 camera.h
-rw-r--r-- 1 jvazquez jderobot 16113 2010-03-05 11:35 camera.cpp

Second,

(2010.3.1) ICE Platform understanding

During several days, ICE online documentation have been studied to obtain a general understaing of how this middleware works and try to foresee how 4.3 elements can be adapted on this.

During this self-training activity, several guided exampled have been tested to consolidate the concepts. Some of these code examples were checked-in at my personal trunk folder.

Visual navigation: Follow the mouse

(2010.2.22)

The purpose of this programming exercise is to implement a visual identification of a known object trying to identify it by its colors pattern and morphological appearance. Additionally, the target object be identified can be moving. On the other hand, once the object has been identified, the robot logic has to use its motors actuators in order to follow the target and approximate to it (but not crashing with it)

Basically, the problem has been segregated into several sequential steps:

1. (warm-up) Investigate how to access imangenA display in introbot schema's gui. This allow us to paint some annotations over robot's camera display and, therefore, be able to trace the logic behavior afterwards. In this sense, it was basically set up some functions to access imangenA_buf variable from navegacion.c file. imangeA_buf was exported from introrob.c. These functions allow us to paint points, lines and squares, of different colors, over the display.

2. Filter input video image to keep just target object's colors. This allows the following step to easily identify the target in the image. Due to the object we look for in this practice is another pioneer robot, we kept blue and red colors as original and switch the rest to gray scale.

3. Identify pioneer robot by looking for some geometric patterns between blue and red spots (squares approximation). In this case, we made the assumtion, a pioneer robot is formed by a red base with bigger width that height and a blue square on top of the base with a short distance in between and smaller that the base.

4. Calculate target angle and distance. Target angle is obtained from visual processing while, for distance, we use laser sensor. We use laser values in a restricted angle area when robot is aligned with the target. Thus, this data are used to fix linear (v) and angular (w) speeds.

Hereafter, I attached several screen captures, ordered from final result to initial tests. As remark for these video, it's important to say that I'm using a emulated linux platform with VMWare. Although, physical PC has good computation capacity (T8300) and VMware was tuned for providing the maximum resource to its virtual instance, we observe it's not always enough to run gazebo. In any case, I ensure it's not due to a bad robots algorithm performance. :-)

Final result video (1/2).


Final result video (2/2).


Intermediate status video: Identify full spots on the image.


Initial video: After color filtering, identify small colored boxed.

Visual navigation: Follow red line

(2010.2.11)

Pioneer robot is able to go forward in one direction following a red line drawn in the floor. As previous practises, we use a simulated environment but, in this case, 2D platform (Player & Stage) and replaced by 3D (Gazebo). SonyVID30 Camera is use as unique input passive sensor.

The main goal of this algorithm consisted of check if red line is in front of the camera and aligned to robot’s direction. Additionally, the logic must be able to recognize little deviations while running in a straight corridor and approximations to red line corners where robot has to perform a force direction change. Due to working with crude input video stream makes difficult to achieve previous tasks, a previous video signal processing has been implemented. This processing phase, is able to focus on the content of bottom-center rectangle (90X60 pixels) and subdivide it in 9 rectangles as a 3x3 matrix of 30x20 pixel dimension. One by one, image processing algorithm checks red colour percentage in this cells and store this information in a float matrix variable.

Thus, linear and radial speeds are adjusted based of different status cases over matrix colour results. I.e. When upper-centre and center-center rectangle’s values are over 50%, “v” is ser to 500 and “w” set to “0”.

The following video shows the result obtained.


VFF: Deliberative-Reactive navigation in a circuit (CHESTE)

Adaptation of pure reactive schema

(2010.2.6)

Introbot schema has been adapted (in navigation.c file) to take into account a list of intermediate destinations. The new algorithm processes the list of destinations sequentially instead of change it dynamically when user picks a new point with the mouse. As result, a deliberative-reactive navigation is implemented.

The following demonstration video could be improve by increasing linear speed and selecting better intermediate points (some of them are very in the external corner of the curve).


VFF: Reactive navigation between obstacles

Improvement on robot's navigation behaviour

(2010.2.1)

Several adaptations were included in the code in order to improve the navigation results:

  • Pure VFF algorithm codification (previous attempt didn't calculate the rejection force correctly).
  • Security window implementation. A virtual square has been defined at robot's front-end. When an obstacle appears inside the security box, linear and radial speed control logic updates the values in order to put away the object asap.
  • Improvement of linear and radial control logic. The different cases have been reviewed.


Warming up with first version

(2010.1.22)

First implementation of VFF algorithm for navigating a squared area with several obstacles. Some issues aren't solved yet, such as, collisions with obstacle's corners, direction balancing while running in a corridor, speed limitation, collision when the atraction and rejection forces are opposite.


Retrieved from "http://jderobot.org/index.php/User:Jvazquez"
Personal tools