yars-users — Help on YARS and YARS usage

Re: [Yars-users] Servomotors

[Keyan <ke...@us...>]

Hi,

we also used angular hinge joints. i am also currently using them in another simulation file.

could you send me your xml file offlist or via pastebin?

regards,
keyan

On 31 Aug 2010, at 16:50, Tom Walwyn wrote:

> Hi Keyan,
> 
> I checked the robots starting position and it was indeed in the ground. so i made sure to lift it out of the ground. however, the robot still disappears from the simulation. 
> 
> I changed the hinge type to velocity and the robot appears. this is good, but not really the functionality that i want to simulate (i wish for an angle-based servomotor).
> 
> What kind of hinge did you use for the aibo? 
> 
> regards,
> tom
> 
>  
> 
> On Tue, Aug 31, 2010 at 12:49 PM, Keyan <ke...@us...> wrote:
> Hi Tom,
> 
> this seems like a problem that happened to me in the beginning too. when you create your hexapod, you have to make sure that it does not touch the ground. this is important for the following reason:
> 
> if the legs touch the ground, or more precise, intersect with the ground at the beginning of the simulation, it is very likely, that forces add up, which catapult the entire hexapod into nirvana. we encountered that problem also once during the evolution of an aibo robot, in which the distance was the fitnessfunction. the controller forced the legs into the ground, until the summed forces would catapult the aibo somewhere far, far away.
> 
> to avoid this problem, it is best, when you add an initialPosition tag to the robot, and lift it a few centermeters above the ground.
> 
> regards,
> keyan
> 
> On 31 Aug 2010, at 12:40, Tom Walwyn wrote:
> 
> > Hi,
> >
> > I'm busy creating a simulation for a 12 DOF (2 for each leg) hexapod. the legs are actuated with servomotors.
> >
> > In order to simulate the servomotors, I have created a hinge connector of type angular. The anchor points for the hinges are the points around which i want the joints to rotate. This is all fine. But, as soon as I give the hinge any amount of max force, the robot disappears from the simulation. I am assuming this is because the robot explodes from the forces acting upon the joints.
> >
> > Has anybody got any advice as how to effectively make working servomotors for joints?
> >
> > Thanks in advance,
> >
> > Tom Walwyn
> >
> > --
> > Signature:
> > _____________
> > ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd_______________________________________________
> > Yars-users mailing list
> > Yar...@li...
> > https://lists.sourceforge.net/lists/listinfo/yars-users
> 
> 
> 
> 
> -- 
> Signature:
> _____________

Re: [Yars-users] Servomotors

[Tom W. <tw...@gm...>]

Hi Keyan,

I checked the robots starting position and it was indeed in the ground. so i
made sure to lift it out of the ground. however, the robot still disappears
from the simulation.

I changed the hinge type to velocity and the robot appears. this is good,
but not really the functionality that i want to simulate (i wish for an
angle-based servomotor).

What kind of hinge did you use for the aibo?

regards,
tom



On Tue, Aug 31, 2010 at 12:49 PM, Keyan <ke...@us...> wrote:

> Hi Tom,
>
> this seems like a problem that happened to me in the beginning too. when
> you create your hexapod, you have to make sure that it does not touch the
> ground. this is important for the following reason:
>
> if the legs touch the ground, or more precise, intersect with the ground at
> the beginning of the simulation, it is very likely, that forces add up,
> which catapult the entire hexapod into nirvana. we encountered that problem
> also once during the evolution of an aibo robot, in which the distance was
> the fitnessfunction. the controller forced the legs into the ground, until
> the summed forces would catapult the aibo somewhere far, far away.
>
> to avoid this problem, it is best, when you add an initialPosition tag to
> the robot, and lift it a few centermeters above the ground.
>
> regards,
> keyan
>
> On 31 Aug 2010, at 12:40, Tom Walwyn wrote:
>
> > Hi,
> >
> > I'm busy creating a simulation for a 12 DOF (2 for each leg) hexapod. the
> legs are actuated with servomotors.
> >
> > In order to simulate the servomotors, I have created a hinge connector of
> type angular. The anchor points for the hinges are the points around which i
> want the joints to rotate. This is all fine. But, as soon as I give the
> hinge any amount of max force, the robot disappears from the simulation. I
> am assuming this is because the robot explodes from the forces acting upon
> the joints.
> >
> > Has anybody got any advice as how to effectively make working servomotors
> for joints?
> >
> > Thanks in advance,
> >
> > Tom Walwyn
> >
> > --
> > Signature:
> > _____________
> >
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> >
> http://p.sf.net/sfu/intel-thread-sfd_______________________________________________
> > Yars-users mailing list
> > Yar...@li...
> > https://lists.sourceforge.net/lists/listinfo/yars-users
>
>


-- 
Signature:
_____________

Re: [Yars-users] Servomotors

[Keyan <ke...@us...>]

Hi Tom,

this seems like a problem that happened to me in the beginning too. when you create your hexapod, you have to make sure that it does not touch the ground. this is important for the following reason:

if the legs touch the ground, or more precise, intersect with the ground at the beginning of the simulation, it is very likely, that forces add up, which catapult the entire hexapod into nirvana. we encountered that problem also once during the evolution of an aibo robot, in which the distance was the fitnessfunction. the controller forced the legs into the ground, until the summed forces would catapult the aibo somewhere far, far away.

to avoid this problem, it is best, when you add an initialPosition tag to the robot, and lift it a few centermeters above the ground.

regards,
keyan

On 31 Aug 2010, at 12:40, Tom Walwyn wrote:

> Hi,
> 
> I'm busy creating a simulation for a 12 DOF (2 for each leg) hexapod. the legs are actuated with servomotors. 
> 
> In order to simulate the servomotors, I have created a hinge connector of type angular. The anchor points for the hinges are the points around which i want the joints to rotate. This is all fine. But, as soon as I give the hinge any amount of max force, the robot disappears from the simulation. I am assuming this is because the robot explodes from the forces acting upon the joints. 
> 
> Has anybody got any advice as how to effectively make working servomotors for joints?
> 
> Thanks in advance,
> 
> Tom Walwyn
> 
> -- 
> Signature:
> _____________
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd_______________________________________________
> Yars-users mailing list
> Yar...@li...
> https://lists.sourceforge.net/lists/listinfo/yars-users

[Yars-users] Servomotors

[Tom W. <tw...@gm...>]

Hi,

I'm busy creating a simulation for a 12 DOF (2 for each leg) hexapod. the
legs are actuated with servomotors.

In order to simulate the servomotors, I have created a hinge connector of
type angular. The anchor points for the hinges are the points around which i
want the joints to rotate. This is all fine. But, as soon as I give the
hinge any amount of max force, the robot disappears from the simulation. I
am assuming this is because the robot explodes from the forces acting upon
the joints.

Has anybody got any advice as how to effectively make working servomotors
for joints?

Thanks in advance,

Tom Walwyn

-- 
Signature:
_____________

[Yars-users] Can't load net into ISEE

[Tom W. <tw...@gm...>]

Hi,

i'm not sure what i'm doing wrong, but i can't seem to load a net from file.
here are the steps that i take

1. start Hinton
2. create a 2-input, 2-output net and define the values of the weights
between them.
3. in the NetEdit window, i save the net to file and close Hinton
4. start Hinton again and select 'load file' from the file load panel (the
parameters in this GUI are set to 0, 0, 0, for Population, Generation and
Individual, respectively).

at this point, hinton gives an error, saying:

"You chose to open this file:
/home/tom/isee-svn-co/branches/java/build/braitenbergControl.xml
Trying to load net (pop: 0, gen: 0, ind: 0)
In the selected Generation, we only have 0 individuals, not 0
Could not load net! Wrong segmentation or grammar...
Please Check Parameters"

what do you think could be the problem?

thank you for all your help
cheers,
tom walwyn

-- 
Signature:
_____________

[Yars-users] Using ISEE to control a YARS simulation

[Tom W. <tw...@gm...>]

Hi,

I have a question regarding the operation of YARS and ISEE.
In ISEE:

What are the exact steps one would go through to set up a simulation so that
no evolution occurs? i.e so that a robot is controlled by a predefined
neural network. I have defined a neural network (2-input neurons, 2-output
neurons) to control the braitenberg.xml robot. I can connect to the robot
from ISEE through UDP (RobotStruct is filled, I believe). However, i don't
get any graphical output from the YARS simulation window. Also every time I
select "Run Net" from Hinton, java throws a null pointer exception.

Thanks in advance for help,
Tom Walwyn

-- 
Signature:
_____________

[Yars-users] Compiling ISEE

[Tom W. <tw...@gm...>]

Hi,

i've been trying to compile ISEE, but i get a load of errors telling me that
javac cannot find the required libraries. i've put all the required
libraries in the branches/java/lib directory. i've never used ant before, so
i have no idea how to set the correct paths, etc. i'm hoping someone will
know what the solution is. i think its something to do with the classpath,
but im not sure. here is a sample of the output i get from the compiler:

compile:
    [javac] Compiling 217 source files to
/home/tom/isee-svn-co/branches/java/build
    [javac]
/home/tom/isee-svn-co/branches/java/src/cholsey/LearningRuleClassLoader.java:33:
package org.apache.log4j does not exist
    [javac] import org.apache.log4j.Logger;
    [javac]                        ^
    [javac]
/home/tom/isee-svn-co/branches/java/src/cholsey/LearningRuleClassLoader.java:40:
cannot find symbol
    [javac] symbol  : class Logger
    [javac] location: class cholsey.LearningRuleClassLoader
    [javac]   private static Logger log =
IseeLogger.getLogger(LearningRuleClassLoader.class);
    [javac]                  ^
    [javac] /home/tom/isee-svn-co/branches/java/src/beaumys/Beaumys.java:44:
package org.apache.log4j does not exist
    [javac] import org.apache.log4j.Logger;
    ........

    [javac]
/home/tom/isee-svn-co/branches/java/src/brightwell/gui/drawingplane/Chart3D.java:99:
cannot find symbol
    [javac] symbol  : class ChartPanel
    [javac] location: class brightwell.gui.drawingplane.Chart3D
    [javac]     return new ChartPanel(jfreechart);
    [javac]                ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    [javac] 100 errors

BUILD FAILED
/home/tom/isee-svn-co/branches/java/build.xml:278: Compile failed; see the
compiler error output for details.

Thanks is advance
Tom Walwyn

-- 
Signature:
_____________

[Yars-users] Building ISEE

[Tom W. <tw...@gm...>]

Hi,

I think that ISEE is built with ant. I this true? Also, I can't find the
library svninfo_task.jar. Does anybody have a copy of it that is available?

Regards,
Thomas Walwyn

-- 
Signature:
_____________

Re: [Yars-users] ISEE and YARS

[Keyan <ke...@us...>]

Hi Tom,

you can use any exmaple file in the /trunk (and braitenberg.xml in the branches) to test ISEE with YARS. you only have to change the type of the robot to "active" (from e.g. controlled). then YARS waits for ISEE. in ISEE: create a neural networks that is not empty, i.e. has at least some output neurons (better also some input neurons). when you have that done, you can connect ISEE to yars and use the analyser to play around, i.e. set some output values and see what's happening.

cheers,
keyan

On 23 Aug 2010, at 12:44, Tom Walwyn wrote:

> Hi,
> 
> Tom here. Are there any examples available of robots being controlled with ISEE using YARS? It would be great to use something already available as a platform for my own robot.
> 
> Regards,
> 
> Tom Walwyn
> 
> -- 
> Signature:
> _____________
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev _______________________________________________
> Yars-users mailing list
> Yar...@li...
> https://lists.sourceforge.net/lists/listinfo/yars-users

[Yars-users] ISEE and YARS

[Tom W. <tw...@gm...>]

Hi,

Tom here. Are there any examples available of robots being controlled with
ISEE using YARS? It would be great to use something already available as a
platform for my own robot.

Regards,

Tom Walwyn

-- 
Signature:
_____________

Re: [Yars-users] Pixel shift issue.

[Arndt T. <tw...@us...>]

Hi Robert,

Robert Märtin schrieb:
> My modification of Rendertexture.cpp screwed up the grayscale mode. To  
> be able to deal with Grayscale, RGB and single channel, I had to add  
> this fix to Rendertexture.cpp. (Around line 700):

The patch has now been merged. Sorry for the delay.

> In summary: The RGB / single channel camera now works for "low" numbers of
> sensors & effectors.  Beyond 214 sensors/effectors i either get segfaults or"-1"
> output.  The former seems to be a yars problem, the latter a client problem.
> I'll look into that.

This should also be fixed. The problem was due to udp buffer overflows
depending on the operating system configuration. Please see the latest svn
commits and the wiki.

Cheers,
  Arndt

[Yars-users] Addon: Pixel shift issue.

[Robert M. <rob...@gm...>]

Hi List,

My modification of Rendertexture.cpp screwed up the grayscale mode. To  
be able to deal with Grayscale, RGB and single channel, I had to add  
this fix to Rendertexture.cpp. (Around line 700):

	if(_colorType == GREYSCALE_TYPE)
	{
		// glCopyTexSubImage2D(_iTextureTarget, 0, 0, 0, 0, 0, _iWidth,  
_iHeight);
		glCopyTexImage2D(_iTextureTarget, 0, GL_LUMINANCE, 0, 0, _iWidth,  
_iHeight, 0);
		
		// // save image in Buffer, for giving back the Pixel-values
		
		pixelBuffer = pBuf;
		glGetTexImage(_iTextureTarget, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE,  
pBuf);
		nrChan = 1;
	}
	else
	{
		// glCopyTexSubImage2D(_iTextureTarget, 0, 0, 0, 0, 0, _iWidth,  
_iHeight);
		glCopyTexImage2D(_iTextureTarget, 0, GL_RGB, 0, 0, _iWidth,  
_iHeight, 0);
		
		// save image in Buffer, for giving back the Pixel-values
		pixelBuffer = pBuf;
		glGetTexImage(_iTextureTarget, 0, GL_RGB, GL_UNSIGNED_BYTE, pBuf);
		nrChan = 3; // RGB, RED, BLUE and GREEN modes all use three channels  
internally
	}
	_texels.resize(_bufferSize);
	int k=0;
	int n=0;
	int padding = 0;
	if (!((_iWidth*nrChan)%4 == 0))
	{
		padding = 4 - (_iWidth*nrChan)%4; // #Bytes used to pad each image  
row.
	}
	//cout << endl << endl << "---------------------- iWidth:" << (int)  
_iWidth << ". nrChan: " << (int)nrChan << ". Padding: " <<  
(int)padding << endl;
	for(int rows=0; rows<_iHeight; rows++)
	{
		for(int cols=0; cols<(_iWidth*nrChan)+padding; cols++)
		{
			if (cols < _iWidth*nrChan)
			{
				_texels[k] = (double)pBuf[n];
				//cout << " TAKEN, written to " << k+1;
				k++;
			}
			//cout << ". Row: " << (int)rows;
			//cout << ". Column Entry: " << (int)cols;
			//cout << ". Value: " << (double)pBuf[n] << endl;
			n++;
		}
	}


IN ADDITION you have to reduce the step legth in directedcamera.cpp,  
line 175:
       for(int i = 0; i< this->_allValues.size(); i++)


Best
Robert


- - - - - - - - - - - - -
Robert Märtin
University of Osnabrück,
Institute of Cognitive Science,
Neurobiopsychology
Room 31/247
Albrechtstr. 28
49069 Osnabrück
Germany

Work: 0541 969 3403
Mobile: 0176 51550153
www.cogsci.uni-osnabrueck.de/~NBP

[Yars-users] Camera Pixel shift issue resolved.

[Robert M. <rob...@gm...>]

Hello List,

OpenGL appears to store images in memory in a row-wise fashion. If the  
byte length of a row (image width * 3) is not a multiple of 4, the row  
is padded by the missing nr of bytes. In Rendertexture.cpp, line 708  
this has to be taken into account when running through the image byte- 
wise, otherwise there will be pixel/color shifts.
I replaced the for-loop at line 708 by this piece of code:

int k=0;
int n=0;
int padding = 0;
if (!((_iWidth*3)%4 == 0))
{
   padding = 4 - (_iWidth*3)%4; // #Bytes used to pad each image row.
}
for(int rows=0; rows<_iHeight; rows++)
{
   for(int cols=0; cols<(_iWidth*3)+padding; cols++)
   {
     if (cols < _iWidth*3)
	{
	  _texels[k] = (double)pBuf[n];
	  k++;
	}
	n++;
   }
}


Now the images coming out of Yars look fine in RGB and single-channel  
mode. I don't know about the luinance mode. The problem shouldn't  
occur there, as RGBA uses 4 bytes per pixel by default. But I'll have  
to check that.

In summary: The RGB / single channel camera now works for "low"  
numbers of sensors & effectors.
Beyond 2^14 sensors/effectors i either get segfaults or"-1" output.  
The former seems to be a yars problem, the latter a client problem.  
I'll look into that.

Best
Robert

- - - - - - - - - - - - -
Robert Märtin
University of Osnabrück,
Institute of Cognitive Science,
Neurobiopsychology
Room 31/247
Albrechtstr. 28
49069 Osnabrück
Germany

Work: 0541 969 3403
Mobile: 0176 51550153
www.cogsci.uni-osnabrueck.de/~NBP

[Yars-users] Additional values after each image row.

[Robert M. <rob...@gm...>]

Hi List,

The zero values at the end of each row can (at least) be tracked back  
to Gui/Rendertexture.cpp, line 705, where _texels is filled.

LG
R

[Yars-users] A new camera issue: Additional value after each row.

[Robert M. <rob...@gm...>]

Hi List,

In the double vector of the directed camera reading which is handed to  
me by the Yars Java client there is an additional value at the end of  
each image row. This is the case in both RGB and single channel mode.

Detail:
The image pixels are serialized such that the first vector entry  
corresponds to the bottom left pixel, RGB channels are coded in  
successive entries. At the end of each row, i.e. after  
channels*columns entries there is a sensor value of 0 or very close to  
0. This not only  introduces a color/position shift, but also means  
that not all pixels are represented.
This can also be seen in the debug mode of the java client.
The GUI representation of the robot does not show this effect.

I am currently trying to track this to its origin in the Yars code,  
but maybe it's a known issue. If so, please let me know.

Thanks & Best
Robert

Re: [Yars-users] Upper limit to #Sensors

[Arndt T. <tw...@us...>]

Hi Robert,

Sorry for not responding to your mails but I had some misconfigured spam filter
that "swallowed" all of your e-mails to the list, starting 22nd September. Thank
you for posting bug-fixes and test results. Nice to hear that communication
protocol extensions seem to work flawlessly for you.

Robert Märtin schrieb:
> war: in DirectedCamera.cpp fehlt am Ende von "updateSensor" ein
> "postProcessRawValues".

This has been fixed in most current svn version.

Cheers,
  Arndt

Re: [Yars-users] Upper limit to #Sensors

[Robert M. <rob...@gm...>]

Hi Arndt,

Würde gerne eine kleine Veränderung ins svn comitten. Kannst du mich  
zum Projekt hinzufügen (rmaertin)?
Alternativ sag ich dir einfach mal, was das war:
in DirectedCamera.cpp fehlt am Ende von "updateSensor" ein  
"postProcessRawValues".

Mit der Veränderung benimmt sich deine Protokollerweiterung auch mit  
der Kamera zusammen sehr gut. Viele Pixel!

LG
Robert



Best
R
On Sep 23, 2008, at 2:04 PM, Arndt Twickel wrote:

> Hi Robert,
>
> Support for an unlimited number of sensors and motors during  
> communication has
> been added and roughly tested (further testing necessary) in the  
> latest SVN
> version. Java and c++ test clients have also been updated. Feedback  
> is very welcome.
>
> Cheers,
> Arndt



- - - - - - - - - - - - -
Robert Märtin
University of Osnabrück,
Institute of Cognitive Science,
Neurobiopsychology
Room 31/247
Albrechtstr. 28
49069 Osnabrück
Germany

Work: 0541 969 3403
Mobile: 0176 51550153
www.cogsci.uni-osnabrueck.de/~NBP

Re: [Yars-users] Upper limit to #Sensors

[Arndt T. <tw...@us...>]

Hi Robert,

Support for an unlimited number of sensors and motors during communication has
been added and roughly tested (further testing necessary) in the latest SVN
version. Java and c++ test clients have also been updated. Feedback is very welcome.

Cheers,
Arndt

Re: [Yars-users] Upper limit to #Sensors

[Arndt T. <tw...@us...>]

Hi Robert,

Nice to hear that yars including the camera sensor is finally running on your
system.

Robert Märtin schrieb:
> The camera sensor appears to work fine now. Unfortunately, there  
> appears to be an upper limit to the number of sensors & effectors  
> used. Apparently this limit stems from packet size constraints. 

This is correct. The communication protocol is documented in the Wiki (which
unfortunately is down due to Sourceforge datacenter migration and which might
take a couple of days to be back up). To minimize communication time all sensor
and motor data is packed into one single UDP packet respectively. Out of my head
the limits are calculated as follows: maxUDPPacketSize = 1024 Bytes, 4 Byte per
Sensor/Motor value, minus overhead --> approx. 250 sensor and 250 motor values
upper limit. This applies to EXTENDED_COMMUNICATION method because in
STANDARD_COMMUNICATION mode additionaly the simulation structure is transmitted
during handshake in one single packet which reduces the possible number of
sensors/motors. In extended mode during handshake each sensor and motor is
communicated in its own packet because it carries a name with it.
EXTENDED_COMMUNICATION is up to know only implemented in the C++ client but
changes should be easily portable to the Java Client. Up to now no one was
working with this many sensor values, even people working with the camera
sensor, but I think the communication protocol is easily extendible. I planned
on adding some functionality to the protocol over the next couple of days anyhow
so I will take a look at adding support for more (unlimited) sensors/motors. As
soon as I know more I will let you know.

> camera with too few pixels does not make a lot of sense, I'd like to  
> know whether there is a way to bypass this constraint.

Cameras with up to 250 sensor values might already make a lot of sense but this
of course depends on the task at hand ;-)

Bypassing is possible by either using the EXTENDED_COMMUNICATION for up to 250
sensor values or by dynamic library control method and implementing your own
communication with Matlab there, or by changing the communication protocol as
explained above.

Cheers,
Arndt

[Yars-users] Upper limit to #Sensors

[Robert M. <rob...@gm...>]

Hi List,

The camera sensor appears to work fine now. Unfortunately, there  
appears to be an upper limit to the number of sensors & effectors  
used. Apparently this limit stems from packet size constraints. As a  
camera with too few pixels does not make a lot of sense, I'd like to  
know whether there is a way to bypass this constraint.

Thanks a lot & Best
Robert

[Yars-users] Directed Camera Issues - Resolved

[Robert M. <rob...@gm...>]

Hey List!

Thanks for all the feedback!
It works. The last problem appeared to be due to my ssh X-Window  
connection. If i start Yars on the computer itself, everything seems  
to be fine. There is a window with a nice 1D camera output which  
appears to be plausible.
I'll report back later.

Best
R


On Sep 16, 2008, at 11:46 AM, Robert Märtin wrote:

> Hi List,
>
> As Arndt pointed out, the last problem was due to an XML syntax
> problem. Now I seem to get closer to actually using the camera sensor.
> Still, there is an error :)
>
> rmaertin@earth:/work/rmaertin$ ./yarsbuild/bin/yars -d robots/
> cambot.xml -x yars/trunk -t yars/trunk -l yarsbuild
>
> WARNING: yars-config-file .yarsrc could not be found in:
>   .
>   /home/student/r/rmaertin
>   /etc
> Using xsd-path /work/rmaertin/yars/trunk
> Using textures-path /work/rmaertin/yars/trunk
> Using lib-path /work/rmaertin/yarsbuild
> IN XML_FILE: path_to_xsd /work/rmaertin/yars/trunk
> Using xml-sim-description /work/rmaertin/robots/cambot.xml
> sending /work/rmaertin/yars/trunk to DOMParser
> DOMParser::xsd: /work/rmaertin/yars/trunk/xsd/RoSiML.xsd
> setting simFreq  from XML --> no data
> YARS setup is now as follows:
> stepSize:   0.010000
> simFreq:    100
> updateFreq: 25
> stepTimer:  10
> freeglut (./yarsbuild/bin/yars): Unable to create direct context
> rendering for window 'YARS-Simulation'
> This may hurt performance.
> freeglut (./yarsbuild/bin/yars): Unable to create direct context
> rendering for window 'Camera'
> This may hurt performance.
> RenderTexture::Initialize() creation error: Couldn't find a suitable
> pixel format
> waiting for connection(s) ...
>
> Initing UDP-Socket-Connection...
>
> Socket port 4500 assigned,
>
> Waiting for udpClient 0 ...
>
> Connected to shodan.neurobiopsychologie.Uni-Osnabrueck.DE
> (131.173.35.184),
> port 63264
>
> ...init done
>
> ---------------------------------------------------------------
> | ### KEYS ###  (beware: might be overridden by OS)           |
> |-------------------------------------------------------------|
> |     + : speed up simulation (realtime has to be on)
> |     - : slow down simulation (realtime has to be on)
> |     0 : speed up draw update (default=1=each step)
> |     9 : slow down draw update (>1 ^= every nth step)
> |     L : toggle reload file on reset on/off
> |     P : toggle pause on/off
> |     R : reinit and reset simulation
> |     T : toggle use textures on/off
> |     V : printout camera viewport
> |     X : exit simulation
> |     c : toggle show/hide all camera windows
> |     d : toggle drawing on/off
> |     f : toggle follow camera mode (1st robot) on/off
> |     h : help (printout this text)
> |     p : toggle printout frame rate every 1000.00 [ms] on/off
> |     r : toggle realtime on/off
> |     s : do a single step (in pause mode)
> |     t : toggle traces on/off (for those configured)
> |     v : restore initial viewpoint
> |-------------------------------------------------------------|
> | S = SHIFT, C = CTRL, A = ALT                                |
> ---------------------------------------------------------------
> Restoring original viewpoint!
> handshake request (0), mode SIMPLE ...
> ...handshake sent.
>
>
> As soon as I connect to Yars, the program quits with the following
> message:
> RenderTexture::BeginCapture(): Texture is not initialized!
>
> The texture path should be okay, as I see textures in the
> vizualization Window when I use only distance sensors.
> In general, everything works fine when I don't use the camera sensor.
>
> I hope this is the final obstacle.
> Thanks a lot for your patience.
>
> Best
> Robert
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Yars-users mailing list
> Yar...@li...
> https://lists.sourceforge.net/lists/listinfo/yars-users

Re: [Yars-users] Directed Camera Issues - Some Progress

[Keyan <ke...@us...>]

Hi,

sorry for answering so late, but i was a few days off. i am currently  
working on a 64bitter with an nvidia graphics card. unfortunately i  
could not find an xml file containing a camera sensor in my  
repository. would you mind sending me your xml file, so that i can  
check it with my system?

cheers,
keyan

On 16 Sep 2008, at 11:46, Robert Märtin wrote:

> Hi List,
>
> As Arndt pointed out, the last problem was due to an XML syntax
> problem. Now I seem to get closer to actually using the camera sensor.
> Still, there is an error :)
>
> rmaertin@earth:/work/rmaertin$ ./yarsbuild/bin/yars -d robots/
> cambot.xml -x yars/trunk -t yars/trunk -l yarsbuild
>
> WARNING: yars-config-file .yarsrc could not be found in:
>  .
>  /home/student/r/rmaertin
>  /etc
> Using xsd-path /work/rmaertin/yars/trunk
> Using textures-path /work/rmaertin/yars/trunk
> Using lib-path /work/rmaertin/yarsbuild
> IN XML_FILE: path_to_xsd /work/rmaertin/yars/trunk
> Using xml-sim-description /work/rmaertin/robots/cambot.xml
> sending /work/rmaertin/yars/trunk to DOMParser
> DOMParser::xsd: /work/rmaertin/yars/trunk/xsd/RoSiML.xsd
> setting simFreq  from XML --> no data
> YARS setup is now as follows:
> stepSize:   0.010000
> simFreq:    100
> updateFreq: 25
> stepTimer:  10
> freeglut (./yarsbuild/bin/yars): Unable to create direct context
> rendering for window 'YARS-Simulation'
> This may hurt performance.
> freeglut (./yarsbuild/bin/yars): Unable to create direct context
> rendering for window 'Camera'
> This may hurt performance.
> RenderTexture::Initialize() creation error: Couldn't find a suitable
> pixel format
> waiting for connection(s) ...
>
> Initing UDP-Socket-Connection...
>
> Socket port 4500 assigned,
>
> Waiting for udpClient 0 ...
>
> Connected to shodan.neurobiopsychologie.Uni-Osnabrueck.DE
> (131.173.35.184),
> port 63264
>
> ...init done
>
> ---------------------------------------------------------------
> | ### KEYS ###  (beware: might be overridden by OS)           |
> |-------------------------------------------------------------|
> |     + : speed up simulation (realtime has to be on)
> |     - : slow down simulation (realtime has to be on)
> |     0 : speed up draw update (default=1=each step)
> |     9 : slow down draw update (>1 ^= every nth step)
> |     L : toggle reload file on reset on/off
> |     P : toggle pause on/off
> |     R : reinit and reset simulation
> |     T : toggle use textures on/off
> |     V : printout camera viewport
> |     X : exit simulation
> |     c : toggle show/hide all camera windows
> |     d : toggle drawing on/off
> |     f : toggle follow camera mode (1st robot) on/off
> |     h : help (printout this text)
> |     p : toggle printout frame rate every 1000.00 [ms] on/off
> |     r : toggle realtime on/off
> |     s : do a single step (in pause mode)
> |     t : toggle traces on/off (for those configured)
> |     v : restore initial viewpoint
> |-------------------------------------------------------------|
> | S = SHIFT, C = CTRL, A = ALT                                |
> ---------------------------------------------------------------
> Restoring original viewpoint!
> handshake request (0), mode SIMPLE ...
> ...handshake sent.
>
>
> As soon as I connect to Yars, the program quits with the following
> message:
> RenderTexture::BeginCapture(): Texture is not initialized!
>
> The texture path should be okay, as I see textures in the
> vizualization Window when I use only distance sensors.
> In general, everything works fine when I don't use the camera sensor.
>
> I hope this is the final obstacle.
> Thanks a lot for your patience.
>
> Best
> Robert
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Yars-users mailing list
> Yar...@li...
> https://lists.sourceforge.net/lists/listinfo/yars-users

Re: [Yars-users] Directed Camera Issues - Some Progress

[Mario N. <mne...@gm...>]

Oh-oh.
I am not 100%, but my two cents.

freeglut (./yarsbuild/bin/yars): Unable to create direct context
> rendering for window 'YARS-Simulation'


It seems to me that your problem starts here.

The camera sensor is actually a 'rendered projection' of the environment,
from a particular viewing angle.
This 'rendered projection' is a texture. That's the texture that has issues,
not the environment.
 The texture can't be created because the freeglut couldn't create the
'rendered projection.

It may very well be that glut does not talk to your graphics card. Which is
the problem i refered to earlier on.

That's the message:

> This may hurt performance.
> freeglut (./yarsbuild/bin/yars): Unable to create direct context
> rendering for window 'Camera'
>

If freeglut is not able to create direct context...


> This may hurt performance.
> RenderTexture::Initialize() creation error: Couldn't find a suitable
> pixel format


Then, the 'render texture that becomes camera image' does not have pixels in
it



> RenderTexture::BeginCapture(): Texture is not initialized!
>
So, the texture is the projection.

 The texture path should be okay, as I see textures in the
 vizualization Window when I use only distance sensors.

> In general, everything works fine when I don't use the camera sensor.
>
> I hope this is the final obstacle.


For me it was final. After i had it, i had to give up.
Maybe you will have to talk to verena...


A hug,

M.

[Yars-users] Directed Camera Issues - Some Progress

[Robert M. <rob...@gm...>]

Hi List,

As Arndt pointed out, the last problem was due to an XML syntax  
problem. Now I seem to get closer to actually using the camera sensor.  
Still, there is an error :)

rmaertin@earth:/work/rmaertin$ ./yarsbuild/bin/yars -d robots/ 
cambot.xml -x yars/trunk -t yars/trunk -l yarsbuild

WARNING: yars-config-file .yarsrc could not be found in:
   .
   /home/student/r/rmaertin
   /etc
Using xsd-path /work/rmaertin/yars/trunk
Using textures-path /work/rmaertin/yars/trunk
Using lib-path /work/rmaertin/yarsbuild
IN XML_FILE: path_to_xsd /work/rmaertin/yars/trunk
Using xml-sim-description /work/rmaertin/robots/cambot.xml
sending /work/rmaertin/yars/trunk to DOMParser
DOMParser::xsd: /work/rmaertin/yars/trunk/xsd/RoSiML.xsd
setting simFreq  from XML --> no data
YARS setup is now as follows:
stepSize:   0.010000
simFreq:    100
updateFreq: 25
stepTimer:  10
freeglut (./yarsbuild/bin/yars): Unable to create direct context  
rendering for window 'YARS-Simulation'
This may hurt performance.
freeglut (./yarsbuild/bin/yars): Unable to create direct context  
rendering for window 'Camera'
This may hurt performance.
RenderTexture::Initialize() creation error: Couldn't find a suitable  
pixel format
waiting for connection(s) ...

Initing UDP-Socket-Connection...

Socket port 4500 assigned,

Waiting for udpClient 0 ...

Connected to shodan.neurobiopsychologie.Uni-Osnabrueck.DE  
(131.173.35.184),
port 63264

...init done

---------------------------------------------------------------
| ### KEYS ###  (beware: might be overridden by OS)           |
|-------------------------------------------------------------|
|     + : speed up simulation (realtime has to be on)
|     - : slow down simulation (realtime has to be on)
|     0 : speed up draw update (default=1=each step)
|     9 : slow down draw update (>1 ^= every nth step)
|     L : toggle reload file on reset on/off
|     P : toggle pause on/off
|     R : reinit and reset simulation
|     T : toggle use textures on/off
|     V : printout camera viewport
|     X : exit simulation
|     c : toggle show/hide all camera windows
|     d : toggle drawing on/off
|     f : toggle follow camera mode (1st robot) on/off
|     h : help (printout this text)
|     p : toggle printout frame rate every 1000.00 [ms] on/off
|     r : toggle realtime on/off
|     s : do a single step (in pause mode)
|     t : toggle traces on/off (for those configured)
|     v : restore initial viewpoint
|-------------------------------------------------------------|
| S = SHIFT, C = CTRL, A = ALT                                |
---------------------------------------------------------------
Restoring original viewpoint!
handshake request (0), mode SIMPLE ...
...handshake sent.


As soon as I connect to Yars, the program quits with the following  
message:
RenderTexture::BeginCapture(): Texture is not initialized!

The texture path should be okay, as I see textures in the  
vizualization Window when I use only distance sensors.
In general, everything works fine when I don't use the camera sensor.

I hope this is the final obstacle.
Thanks a lot for your patience.

Best
Robert

Re: [Yars-users] Running yars on a 64 Bit machine

[Arndt T. <tw...@us...>]

Hi Robert,

Robert Märtin schrieb:
> It's in the Wiki now. But it's really just a quick fix.

Thank you for this very simple and clearly explained Matlab-Yars communication
setup description :-) I'm not an expert with Matlab but people working with it
told me that you need Simulink to get UDP communication running so I really
prefer your solution!

Arndt