simspark-devel — Discussion about Spark development

Re: [simspark-devel] discussion

[Oliver O. <fr...@ro...>]

Hi,

On 15/03/2007, at 11:19 PM, Yuan Xu wrote:

> when I let the agent control in the main thread,
> and other loops in the new thread,
> it works!
> It seems that the ruby need the initialization in the new thread,  
> is it?

Yeah, this might be the problem. I hadn't much time to try so far,  
but if it works for you, it's hopefully also the solution...

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi again,

when I let the agent control in the main thread,
and other loops in the new thread,
it works!
It seems that the ruby need the initialization in the new thread, is it?



2007/3/15, Yuan Xu <xuy...@gm...>:
> Hi all,
>
> I tried again today, but it still does not work.
>
> Firstly, I create a global mutex that all ruby functions should call
> before doing anything.
> But it will cause dead lock, because there are recursive calls between
> Ruby and C++.
>
> And then, I make the whole run loop in a single thread, but not the
> main thread, ie.
> After the initialization, the main thread create a new thread.
> The new thread run the simulation loops,
> while the main thread do nothing.
> However the strange phenomenon remains ;-(
>
> Do you have any suggestion?
>
>
> --
> Best wishes!
>
> Xu Yuan
> School of Automation
> Southeast University, Nanjing, China
>
> mail:   xuy...@gm...
>           xy...@ya...
> web:   http://xuyuan.cn.googlepages.com
> --------------------------------------------------
>
>


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi all,

I tried again today, but it still does not work.

Firstly, I create a global mutex that all ruby functions should call
before doing anything.
But it will cause dead lock, because there are recursive calls between
Ruby and C++.

And then, I make the whole run loop in a single thread, but not the
main thread, ie.
After the initialization, the main thread create a new thread.
The new thread run the simulation loops,
while the main thread do nothing.
However the strange phenomenon remains ;-(

Do you have any suggestion?


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

[simspark-devel] Win32 branch closed

[Oliver O. <fr...@ro...>]

Hi all,

I've just closed the WIN32 branch by merging everything back to the  
main trunk.
If there are problems with the main trunk now, please let me now.

You can access the version before the merge under the tag  
pre_merge_WIN32.

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] discussion

[Oliver O. <fr...@ro...>]

Hi,

On 14/03/2007, at 4:54 PM, Yuan Xu wrote:

> It seems that the rb_eval_string_protect is not thread safe,
> should I lock the thread to make sure only one thread working?
> or there is another solution?
>
> I really do not know Ruby, please help me.

I did a quick check, and it seems the whole ruby C interpreter isn't  
thread safe.
(LUA is, btw. :-).

So, we need to make sure that ruby is called only from one thread at  
a time. This makes the threading thing a lot more difficult, I guess.

At least, now I'm more unhappy about the initial choice of taking  
ruby... :-( but back at the time we started, LUA wasn't that far  
developed, if I remember correctly (I know that we talked about it).

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi all,

I have just create a new thread for agent control,
but when a agent connect, the error occurred:

#<SystemStackError: (eval):30: stack level too deep>
        from (eval):30
(RubySceneImporter) ERROR: in file 'rsg/boxspheres/box.rsg': failed to
eval expression 0 + 0.3425 + 0.06
(SceneServer) ERROR: cannot import scene file 'rsg/agent/soccerbot.rsg'

but try connect again, it is OK,
and the next agent connection is failed, next success...

It seems that the rb_eval_string_protect is not thread safe,
should I lock the thread to make sure only one thread working?
or there is another solution?

I really do not know Ruby, please help me.

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi Hesham,

Hesham wrote:
>
> Hi Joschka and Oliver,
>
> I've attached the first part of my work on the logger (Makefile.am 
> <http://Makefile.am> is for the oxygen library). I wrote a new class, 
> MonitorLogger, derived from SimControlNode. As Joschka suggested, it's 
> very similar to MonitorControl.
>

Great, thanks a lot (and sorry for the late reply)! I couldn't test the 
code yet, but I'll try it tomorrow and let you know what I found.

>
> I'm wondering if it's OK that I've included fsteam in the header file 
> of this new class. If I should change something in the code, please 
> let me know. I wanted to finish my work on monitor to play log files 
> before Monday. But I've got a busy week until Friday.
>

You probably have your own ideas about that already, but maybe you could 
implement another SimControlNode derived class for the log playback 
part. It could be similar to SparkMonitorClient, but instead of getting 
the messages from the net, it would read them from a file. You also 
might want to have a look at the implementation of the LogFileServer in 
app/rcssmonitor3d/lib, maybe you can reuse some stuff. Just some ideas.

Happy hacking :-)

Cheers,
Joschka

Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi Yuan,

Yuan Xu wrote:
> Hi Joschka,
>
>
>>
>> > And do you have the model specification graphic of soccerbot?
>> >
>> >
>>
>> I'm working on it :-)
>>
>
> I have one, and attached it. (the right shoulder not be rotated)
> hope helps ;-)

Awesome! Much better than mine :-) I'm finally going to work on some 
documentation tomorrow and I'd like to put your figure in the wiki. Is 
that okay?

Cheers,
Joschka

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi Joschka,


>
> > And do you have the model specification graphic of soccerbot?
> >
> >
>
> I'm working on it :-)
>

I have one, and attached it. (the right shoulder not be rotated)
hope helps ;-)

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

[simspark-devel] Fwd: [Fwd: [Sserver-three-d] Bug Report - Invalid messages from server]

[Yuan X. <xuy...@gm...>]

Hi all,

I think the server is OK, since our agent runs OK.
And after fixed the bug in GetMessage(), the agentspark runs OK too.

My modification is as follows:
#------------------------------
#159
unsigned int bytesRead = read(gSocket.getFD(), buffer, sizeof(buffer));
// we may read more than message one time here!
-->
unsigned int bytesRead = read(gSocket.getFD(), buffer, sizeof(unsigned int));

#190
msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - msgRead);
// we may read the data of next message
offset += msgRead;
-->
unsigned int i = read(gSocket.getFD(), offset, msgLen - msgRead);
msgRead += i;
offset += i;
#-----------------------------

It is ture that, the orginal agentspark got "large message"
while the agentspark do not send msg to server.
I think that is beacuse the server runs so fast(faster than communication),
and the agent read more message one time(see #159),
it will cause the wrong prefixed data.

Hope helps!

--
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] [Fwd: [Sserver-three-d] Bug Report - Invalid messages from server]

[Jan M. <mu...@un...>]

Joschka Boedecker wrote:
> Hi,
> 
> this message was posted by Moeen on the sserver-three-d list. Has 
> anybody come across a similar problem (those huge server messages)? I 
> don't get them, so I'm not sure what's happening... Any ideas?
> 
> Cheers,
> Joschka

I used to get them sometimes, especially when all perceptors were 
switched on, so the amount of data transferred was quite large. Somehow 
parts of the messages got lost, so that the agent received e.g.

                "ow 18.30))(See (F1L (pol..."
instead of
                "<LENGTH>(time (now 18.30))(See (F1L (pol..."

and interpreted "ow 1" as messagelength (0x6F772031), which resulted in 
segfaults. On my Laptop this behavior vanished since I added the 
artificial slow down in the simulation loop, so I guess the problem is 
related to the timer.


Bye,
  Jan

[simspark-devel] [Fwd: [Sserver-three-d] Bug Report - Invalid messages from server]

[Joschka B. <jbo...@un...>]

Hi,

this message was posted by Moeen on the sserver-three-d list. Has 
anybody come across a similar problem (those huge server messages)? I 
don't get them, so I'm not sure what's happening... Any ideas?

Cheers,
Joschka

Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi Yuan,

Yuan Xu wrote:
>
> I am working on my team now.
> I tried to draw the  model specification of soccerbot,
> I doubt about (setLocalRotation 0 0 180)
> the line 273 in soccerbot.rsg in rcssserver3d-0.5.3
> or line 249 in http://www.uni-koblenz.de/~murray/robocup/soccerbot.rsg
>
> I want to know is there need this rotation?
> Because other right joints are the same direction with the left joints.

After having a quick look, I think you're right. This rotation is not 
needed. I can't test reliably test though right now, because I kind of 
messed up my SimSpark installation. I'll try again later with a fresh 
version from the CVS.

> And do you have the model specification graphic of soccerbot?
>
>

I'm working on it :-)

> And, in app/agentspark/main.cpp "bool GetMessage(string& msg)" function,
> I think there is another bug which caused the segment fault:
>
>
> while (msgRead < msgLen)
>    {
>        if (! SelectInput())
>        {
>            return false;
>        }
>
>        msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - 
> msgRead);
>        //cerr << "msgRead = |" << msgRead << "|\n";
>        offset += msgRead; <-------------BUG?????
>    }

I think you're right again about the bug, but I think it is 2 lines 
above. In my oppinion, it should be:

msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - bytesRead);

Example: Say we got a message of 20kB, but our buffer is only 16kB. 
After the first read in that function, bytesRead will be 16384 which is 
the maximum. msgLen will be 20000. The first 4 Bytes are the length 
prefix which is subtracted from bytesRead and stored in msgRead, so it 
will be 16380. Since msgRead is less than msgLen, we will enter the 
while loop. Offset was set to the beginning of the buffer + bytesRead 
which means it's at the end of the buffer. The read inside the loop 
will, however, still read 4 Bytes if sizeof(buffer) - msgRead is used 
for the length. This will result in a segfault. Right?

Cheers,
Joschka

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi Joschka and all,



 I am working on my team now.
 I tried to draw the  model specification of soccerbot,
 I doubt about (setLocalRotation 0 0 180)
 the line 273 in soccerbot.rsg in rcssserver3d-0.5.3
 or line 249 in http://www.uni-koblenz.de/~murray/robocup/soccerbot.rsg

 I want to know is there need this rotation?
 Because other right joints are the same direction with the left joints.

 And do you have the model specification graphic of soccerbot?


And, in app/agentspark/main.cpp "bool GetMessage(string& msg)" function,
I think there is another bug which caused the segment fault:


while (msgRead < msgLen)
    {
        if (! SelectInput())
        {
            return false;
        }

        msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - msgRead);
        //cerr << "msgRead = |" << msgRead << "|\n";
        offset += msgRead; <-------------BUG?????
    }

Hope helps.

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] [announce] SimSpark Windows Port

[Markus R. <rol...@un...>]

Hi,

Markus Rollmann wrote:
> In the last couple of days I ported my SimSpark GUI 'rsgedit' to Windows 
> and extended it to support the current humanoid soccer robot. This GUI 
> allows you to start simulations and control agent processes with a 
> simple mouse click.

I received bug reports that the windows version of simspark installs but 
fails to start with an error messages similar to this:

 > C:\Program Files\simspark\rsgedit.exe
 > This application has failed to start because the application
 > configuration is incorrect. Reinstalling the application may fix the
 > problem.

this is caused by the dependency of simspark to the latest Microsoft 
C-runtime that is not installed by default with a windows installation. 
Please make sure that you install this runtime.

> [3] 
> http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=de
> 
> [4] http://www.uni-koblenz.de/~rollmark/vcredist_x86.exe

Cheers,
Markus

Re: [simspark-devel] simspark with kerosin

[Joschka B. <jbo...@un...>]

Hi,

Oliver Obst wrote:
> I've just tried to compile simspark with --enable-kerosin on Mac OS.  
> After applying a couple of fixes I was able to compile everything,  
> but then I was wondering if or why the current CVS version compiles  
> with kerosin and Linux. In particular, I had some problems with the  
> configure check for the SDL on Mac OS, because the SDLmain.m is  
> missing on the Mac OS version of the pre-compiled SDL framework (as  
> these libs are called on Mac OS), and hence the check for linking a  
> tiny SDL application fails in our configure.
>
> Even though SDLmain.m / .h may not be missing on a Linux system, they  
> still have to be compiled (which was not part of the current  
> configure script)...
>
> Anybody with compile results for the WIN32 branch (and --enable- 
> kerosin) on linux? (before I commit the changes to the SDL-test...)
>   

It doesn't compile for me currently because of problems related to 
glXGetProcAddress / glXGetProcAddressARB and my version of GLX. I didn't 
have time to have a closer look at it though...the SDL stuff doesn't 
seem to be a problem for the configure, at least it's not complaining.

Cheers,
Joschka

Re: [simspark-devel] [bug-report] rsgedit on macos

[Markus R. <rol...@un...>]

Hi,

sorry for my late replies, I'm kind of busy during the next couple of 
days.

On Wed, 28 Feb 2007, Oliver Obst wrote:
> On 28/02/2007, at 2:19 AM, Oliver Obst wrote:
> 
> > Hi,
> >
> > I get the output below when compiling rsgedit on my system (Mac OS
> > X). (I can have a look, but not now).
> 
> OK, I could fix this one. Compiles and links fine for me now. When I  
> try to start up, I see the splash for a short time, and then I get  
> many error messages of this kind:

This is probably related to two things. First the wxWidgets version you 
are using (according to your CVS messages) is an older development 
snapshot (2.5.3) the current stable version is somewhere around 2.8.2 (see 
wxwidgets.org)

Further you are using wxWidgets in a Unicode build. That leads to all kind 
of conversion errors (as I'm using a non unicode aware build of 
wxWidgets). Your explicit wxChar casts should fix these issues. Also some 
helper macros like _T() are provided from wxWidgets.

> csselaptopes208:~/Code/simspark.WIN32/contrib/rsgedit fruit$ ./rsgedit
> #<NoMethodError: undefined method `sparkSetupServer' for main:Object>
>          from (eval):19
> (Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
> (Object) ERROR: failed to get zeitgeist core for 'Node0xa0b0b924'  
> installed at '/classes/zeitgeist/Node'

sparkSetupServer is a method from spark.rb. I think something in the 
scriptserver/ruby setup does not work properly. Please try to get the 
'coretest' running first. 

Cheers,
Markus

Re: [simspark-devel] [bug-report] rsgedit on macos

[Oliver O. <Oli...@ne...>]

On 28/02/2007, at 2:19 AM, Oliver Obst wrote:

> Hi,
>
> I get the output below when compiling rsgedit on my system (Mac OS
> X). (I can have a look, but not now).

OK, I could fix this one. Compiles and links fine for me now. When I  
try to start up, I see the splash for a short time, and then I get  
many error messages of this kind:

csselaptopes208:~/Code/simspark.WIN32/contrib/rsgedit fruit$ ./rsgedit
#<NoMethodError: undefined method `sparkSetupServer' for main:Object>
         from (eval):19
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Object) ERROR: failed to get zeitgeist core for 'Node0xa0b0b924'  
installed at '/classes/zeitgeist/Node'
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Object) ERROR: failed to get zeitgeist core for 'Leaf0xa0b0b924'  
installed at '/classes/zeitgeist/Leaf'
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Object) ERROR: failed to get zeitgeist core for  
'FileServer0xa0b0b924' installed at '/classes/zeitgeist/FileServer'
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Class) ERROR: failed to get zeitgeist Core for class 'ClassClass'
(Object) ERROR: failed to get zeitgeist core for  
'FileSystem0xa0b0b924' installed at '/classes/zeitgeist/FileSystem'

anybody any idea why this could happen?

Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

[simspark-devel] [bug-report] rsgedit on macos

[Oliver O. <Oli...@ne...>]

Hi,

I get the output below when compiling rsgedit on my system (Mac OS  
X). (I can have a look, but not now).

cheers
Oliver

if g++ -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I/usr/lib/ruby/1.8/ 
universal-darwin8.0 -I/usr/lib/wx/include/mac-unicode-debug-2.5 -I/ 
usr/include/wx-2.5 -D__WXDEBUG__ -D__WXMAC__ -D_FILE_OFFSET_BITS=64 - 
D_LARGE_FILES -DNO_GCC_PRAGMA -I/opt/local/include/simspark -I/opt/ 
local/include -I/opt/local/include/simspark -I/opt/local/include -I/ 
opt/local/include/simspark -I/opt/local/include -I/opt/local/include/ 
simspark -I/opt/local/include -I/opt/local/include/simspark -I/opt/ 
local/include -I/opt/local/include  -g -O2 -MT mainframe.o -MD -MP - 
MF "$depbase.Tpo" -c -o mainframe.o mainframe.cpp; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo";  
exit 1; fi
mainframe.cpp: In member function 'void mainframe::UpdateTitle()':
mainframe.cpp:173: error: conversion from 'const char [9]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:176: error: ambiguous overload for 'operator+' in '" <"  
+ ((mainframe*)this)->mainframe::mSimFName'
/usr/include/wx-2.5/wx/string.h:1513: note: candidates are: wxString  
operator+(const wxString&, const wxString&) <near match>
/usr/include/wx-2.5/wx/string.h:1514: note:                 wxString  
operator+(const wxString&, wxChar) <near match>
/usr/include/wx-2.5/wx/string.h:1515: note:                 wxString  
operator+(wxChar, const wxString&) <near match>
/usr/include/wx-2.5/wx/string.h:1516: note:                 wxString  
operator+(const wxString&, const wxChar*) <near match>
/usr/include/wx-2.5/wx/string.h:1524: note:                 wxString  
operator+(const wxWCharBuffer&, const wxString&) <near match>
mainframe.cpp: In member function 'void mainframe::SplitHor()':
mainframe.cpp:187: error: 'class wxSplitterWindow' has no member  
named 'SetSashGravity'
mainframe.cpp: In member function 'void mainframe::SplitVert()':
mainframe.cpp:196: error: 'class wxSplitterWindow' has no member  
named 'SetSashGravity'
mainframe.cpp: In member function 'bool mainframe::OpenSimulation 
(const wxString&)':
mainframe.cpp:619: error: no matching function for call to  
'zeitgeist::ScriptServer::Run(const wxChar*)'
/opt/local/include/simspark/zeitgeist/scriptserver/scriptserver.h:84:  
note: candidates are: bool zeitgeist::ScriptServer::Run(const  
std::string&)
/opt/local/include/simspark/zeitgeist/scriptserver/scriptserver.h:87:  
note:                 bool zeitgeist::ScriptServer::Run 
(boost::shared_ptr<salt::RFile>)
mainframe.cpp: In member function 'void mainframe::OnFileOpen 
(wxCommandEvent&)':
mainframe.cpp:652: error: conversion from 'const char [28]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:653: error: conversion from 'const char [6]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:654: error: conversion from 'const char [1]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:655: error: conversion from 'const char [1]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:656: error: conversion from 'const char [25]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp: In member function 'void mainframe::OnHelpAbout 
(wxCommandEvent&)':
mainframe.cpp:682: error: conversion from 'const char [15]' to 'const  
wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp: In member function 'void mainframe::OnAgentOpen 
(wxCommandEvent&)':
mainframe.cpp:688: error: conversion from 'const char [34]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:689: error: conversion from 'const char [2]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:690: error: conversion from 'const char [1]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:691: error: conversion from 'const char [1]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
mainframe.cpp:692: error: conversion from 'const char [32]' to  
'wxString' is ambiguous
/usr/include/wx-2.5/wx/string.h:659: note: candidates are:  
wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.5/wx/string.h:649: note:                  
wxString::wxString(int) <near match>
make[2]: *** [mainframe.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

[simspark-devel] simspark with kerosin

[Oliver O. <Oli...@ne...>]

Hi,

I've just tried to compile simspark with --enable-kerosin on Mac OS.  
After applying a couple of fixes I was able to compile everything,  
but then I was wondering if or why the current CVS version compiles  
with kerosin and Linux. In particular, I had some problems with the  
configure check for the SDL on Mac OS, because the SDLmain.m is  
missing on the Mac OS version of the pre-compiled SDL framework (as  
these libs are called on Mac OS), and hence the check for linking a  
tiny SDL application fails in our configure.

Even though SDLmain.m / .h may not be missing on a Linux system, they  
still have to be compiled (which was not part of the current  
configure script)...

Anybody with compile results for the WIN32 branch (and --enable- 
kerosin) on linux? (before I commit the changes to the SDL-test...)

cheers
Oliver

P.S.
Besides the SDL stuff, there were a couple of more fixes necessary  
for Mac OS (getting the GL Extensions works differently in Mac OS,  
and some includes too; the glXGetProcAddressARB needed to be  
implemented because it didn't exist, and some other stuff). Anyway,  
it compiles now for me, but it is completely untested and needs a  
cleanup before I can commit it (I've been working on the WIN32  
branch). I will try that tomorrow.

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] [Sserver-three-d] [announce] SimSpark Windows Port

[Oliver O. <fr...@ro...>]

Hi Markus,

On 26/02/2007, at 7:08 AM, Markus Rollmann wrote:

> In the last couple of days I ported my SimSpark GUI 'rsgedit' to  
> Windows
> and extended it to support the current humanoid soccer robot. This GUI
> allows you to start simulations and control agent processes with a
> simple mouse click. Screenshot at [7]

thanks a lot and keep up the good work ;-)

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

[simspark-devel] [announce] SimSpark Windows Port

[Markus R. <rol...@un...>]

Hi all,

In the last couple of days I ported my SimSpark GUI 'rsgedit' to Windows 
and extended it to support the current humanoid soccer robot. This GUI 
allows you to start simulations and control agent processes with a 
simple mouse click. Screenshot at [7]

Rsgedit is packaged as a standard windows setup.exe installer. It is far 
from bug free but is already a useful tool and development aid ;)

Rsgedit comes prepackaged with a simple simulation that shows the arena 
known from simspark. Further a demo agent is contained that spawns the 
soccerbot and starts waving it's arm (i.e. a 'hello world behavior' ;)

The source code for the windows port of simspark is available in the 
WIN32 branch of the simspark CVS.

In order to help you develop your custom soccerbot behavior easily 
please find a minimal socceragent project for the MS Visual Studio 
compiler at [1].

Below you'll find a small guide how to setup and use rsgedit.

--8<----8<----8<--

Installation
------------

1. Rsgedit comes as prepackaged setup.exe, currently available at [2]. 
Please download this binary and start it. The setup process should be 
self explanatory.

2. The simulator depends on the latest Microsoft C-runtime. Microsoft 
distributes this runtime as a separate setup, called vcredist_x86.exe. 
It is available at [3]. For your convenience I also copied it to [4].

Using RsgEdit
---------------

1. Start rsgedit (either via it's desktop icon or the start menu). You 
should see a small splash screen and then the main application window. 
On the left half are some diagnostic windows. They show the scenegraph 
in the lower half and properties of current node in the top half. On the 
right half of the screen is the embedded OpenGL window that shows the 
simulation.

2. Open a simulation- choose File|Open in the menu or use the folder 
icon. Rsgedit depends on small ruby startup scripts to setup a 
simulation. Simple demos are 'boxpheres.rb' and 'jointtest.rb'.

3. Runnig a simulation. The simulation is in either one of two states 
'paused' or 'running'. Immediately after opening a simulation it is 
paused. You can start the simulation by choosing 'simulation|start' from 
the menu or clicking on the start icon ( |> )  You can later pause a 
simulation by choosing 'simulation|pause' from the menu or clicking the 
pause icon ( || ).

4. Resetting a simulation. If the simulation is currently paused it is 
possible to reset it, i.e. put it back to the state it was immediately 
after opening the simulation.

Starting the soccerbot
----------------------

1. Open the 'agent.rb' simulation. You should see the default arena- a 
simple boxed field.

2. Start the simulation.

3. Start the soccer agent. Choose 'File|Start Agent' from the menu or 
press the agent icon (you'll know when you see it ;) Choose 
'agentspark.exe'.

4. The .exe file is immediately started. The output of the agent is 
shown in a separate window. You should now see the humanoid appearing on 
the field, waving one arm.

5. Stopping/Restarting the agent. You can stop, i.e. kill the agent 
process by pressing the stop icon in the agent log window. You can 
restart the agent with the play icon in the agent window.

Writing your own agent
----------------------

In order to help you develop your own agent you'll find the source code 
of the demo agent at [1]. This source code is identically to the source 
in the CVS except that it is self contained, i.e. does not depend on the 
simspark libraries. The source is meant to be built with the latest 
Visual C++ from Microsoft (Version 2005).

You can get a free Version of this compiler (the vc 2005 express 
edition) from Microsoft [5].

( It would be nice if someone polishes this small howto guide and puts 
it into the Simspark Wiki [6] )

cheers,
Markus

[1] http://www.uni-koblenz.de/~rollmark/agentspark.zip

[2] http://www.uni-koblenz.de/~rollmark/setup.exe

[3] 
http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=de

[4] http://www.uni-koblenz.de/~rollmark/vcredist_x86.exe

[5] 
http://www.microsoft.com/germany/msdn/vstudio/products/express/visualc/default.mspx

[6]
http://simspark.sourceforge.net/wiki/

[7]
http://www.uni-koblenz.de/~rollmark/rsgedit.jpeg

Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi Yuan,

first of: thanks a lot for doing these tests!

Yuan Xu wrote:
> Hi Joschka, Oliver and All
>
> 2007/2/5, Oliver Obst <Oli...@ne...>:
>> Hi,
>>
>> On 04/02/2007, at 3:50 PM, Yuan Xu wrote:
>>
>
>> Well, one direction to approach that would be (1) to start using
>> threads anyway:
>> 1.a) We decide to care about inconsistencies in sensor readings.
>> We could start this by using no buffer, and for the beginning, we
>> could use locks so that no 2 threads operate on the scene graph.
>> Later on, if the threads are working, we can think about something to
>> get rid of the big locks (like the proposed buffer).
>
> I have done the 1.a) test in an individual program,
> I attached the source file.
>
> In my test program, I try to use three threads which Joschka mentioned:
> physics-thread, agent-management-thread and the monitor-agent.
>

[...]

>
> I test it in a Pentium D 2.8G , 1G RAM computer,
> you can compile the source by
>> g++ threads1.cpp -lSDL -lboost_thread-mt -Wall

On my machine (Ubuntu 6.10), I used "g++ threads1.cpp -lSDL 
-lboost_thread-gcc-mt-1_33_1 -Wall" to make it work.

> run the a.out
> and then do
>> gnuplot threads1.plt
> to generate the test result in you own computer.
>
> I think we can guarantee the correct order of events.
> see the png I attached.
>
>> From the plotting, we can see the simulation running smoothly.
>
> Is everything right?

I looks very good, indeed.

>
> Should we implement the plan 1.a) in simspark, or do more testing ?
>

It would be great if you could go ahead and work on the implementation 
of these ideas for the simspark simulator, using the three threads which 
you mentioned above. To do this, please create a new branch in the CVS. 
Once everything is finished and tested, we'll incorporate it into the head.

Please let us know in case there are any problems or you would like to 
get some feedback.

By the way, just so that I can plan a little, could you please let me 
know when you think you could have a first version ready for test? I 
know this is hard to estimate, just try to give me a rough estimate 
(like Tom Howard mentioned before, estimating is an impossible task, 
don't worry about having to correct it later).

Thanks a lot!

Cheers,
Joschka

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi Joschka, Oliver and All

2007/2/5, Oliver Obst <Oli...@ne...>:
> Hi,
>
> On 04/02/2007, at 3:50 PM, Yuan Xu wrote:
>

> Well, one direction to approach that would be (1) to start using
> threads anyway:
> 1.a) We decide to care about inconsistencies in sensor readings.
> We could start this by using no buffer, and for the beginning, we
> could use locks so that no 2 threads operate on the scene graph.
> Later on, if the threads are working, we can think about something to
> get rid of the big locks (like the proposed buffer).

I have done the 1.a) test in an individual program,
I attached the source file.

In my test program, I try to use three threads which Joschka mentioned:
physics-thread, agent-management-thread and the monitor-agent.

Although the test is simple, it contains what we want, I think.
There are some values be operated by only one thread at the same time :
`simTime', `nextTime', `nextRenderTime',
they are the `scene tree' in the test program.

The function doSomething(t) is just a delay function,
just like the program need something to do.

I assume some time ( the function with * operates the `scene tree' ):
a *simstep* needs 2ms,
parse the received msg needs 2ms,
*prepare the send msg* needs 2ms,
*save the actions to scene tree* needs 2ms,
send the msg through net needs 2ms,
*the monitor render* needs 2ms

and
physics step is 10ms,
agent step is 200ms,
monitor step is 150ms.

the format of stdout is
< [ real_start_time - wait_time ] function( simTime ) real_end_time >

I test it in a Pentium D 2.8G , 1G RAM computer,
you can compile the source by
> g++ threads1.cpp -lSDL -lboost_thread-mt -Wall
run the a.out
and then do
> gnuplot threads1.plt
to generate the test result in you own computer.

I think we can guarantee the correct order of events.
see the png I attached.

In the plotting,
the x-axis is the real time, which get from SDL,
the y-axis have different meanings:
the `x' is just a line y=x, it is a base line
the `physics.log' is the sim time in physics thread,
the `agent.log' is the sim time in agent thread,
and the `monitor.log' is the sim time in monitor thread;
the 'scene.log' denotes which thread is operating the `scene tree':
0 - no thread
100 - the physics thread
200 - the agent thread
300 - the monitor thread
lastly, the `stepWait.log' denotes which thread is locking the physics thread:
400 - no thread
500 - the agent thread
600 - the monitor thread

>From the plotting, we can see the simulation running smoothly.

Is everything right?

Should we implement the plan 1.a) in simspark, or do more testing ?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] discussion

[Oliver O. <Oli...@ne...>]

Hi Hesham ;-)

On 06/02/2007, at 2:24 PM, Hesham wrote:

> Yes, he was. Just could you please do me a favour and let me know  
> what you expect from the logger. I have just a simple idea, maybe  
> it works or maybe not. What's your opinion about LOD (level of  
> detail)? IMHO when an object (agent) is not close to the ball  
> logging its exact movement frame by frame isn't necessary.

The created logfile should be useful for somebody developing robots,  
and (if possible) also useful to show a match just to see it.

Reducing the LOD, when something is not so important, is of course  
possible, but at the moment I'm not so sure what kind of information  
you would discard when the LOD is not so high. For example, could be  
you don't update less interesting objects in between "keyframes".  
Have you been thinking of something like this?

Also, when you do experiments at home, the focus might not alway be  
on the player close to the ball, so LOD could be difficult here. At  
least, it should be easy to disable it for research and debugging  
issues.

right now, we're logging everything in text format. This is nice  
because it's still human readable, and it's not totally bad in terms  
of entropy (just using binary could be worse, especially if we don't  
need to have many (decimal) places after the dot). The format could  
also be better than text format, however, because in text format,  
we're using only a few characters out of all possible usable ones. So  
one approach would be to round the decimal numbers to, say, 2 places  
after the dot, multiply by 128 (or something which fits to the  
rounding), and transmit the number as 2 or 3 byte integer. By this it  
would be (maybe) possible to come up with a more compact format for  
logfiles. If you really want to do bitcounting, you can also use  
parts of a byte for smaller numbers (e.g. 12 bits for degrees or  
something like that), but that's maybe too much already.

A more intelligent version  of the keyframe idea would be to log only  
in between the keys when a body doesn't behave as expected, so that  
cases where you don't log an interpolation / extrapolation would do a  
good job. I guess that's a bit challenging, though.

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science