simspark-devel — Discussion about Spark development

Re: [simspark-devel] New touch sensor

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

Hi Hedayat,

Hedayat Vatankhah wrote:
> Hi Joschka,
> I was really surprised by your fast answer!


:-)

>
> /*Joschka Boedecker <jbo...@un...>*/ wrote on ۰۷/۰۵/۳۱ 
> 06:14:32:
> [...]
>
>> Since we are trying to decrease output to the agents to a minimum 
>> currently, I would propose to output the average of the force vector 
>> magnitudes. What do you think?
> OK. I'm agree. What about the (weighted) average position? I think 
> it'll be really helpful!
>


Sounds good. I also think it can be very useful. Could you please also 
write a short documentation for this perceptor (in the style of the 
documentation in the TEXT_INSTEAD_OF_A_MANUAL file in the doc 
directory)? This would be very helpful.


Thanks,
Joschka

Re: [simspark-devel] New touch sensor

[Hedayat V. <hed...@ai...>]

Hi Joschka,
I was really surprised by your fast answer!

/*Joschka Boedecker <jbo...@un...>*/ wrote on ۰۷/۰۵/۳۱ 06:14:32:
> How about ForceResistancePerceptor instead of ExtendedTouchPerceptor? 
> There are actual sensors for robots called force resistance sensor 
> (FRS) and they measure pretty much the same thing as your perceptor :-)
That's fine. I'll rename my perceptor to ForceResistancePerceptor.

> Since we are trying to decrease output to the agents to a minimum 
> currently, I would propose to output the average of the force vector 
> magnitudes. What do you think?
OK. I'm agree. What about the (weighted) average position? I think it'll 
be really helpful!

Good luck,
Hedayat
>
> Cheers,
> Joschka

Re: [simspark-devel] New touch sensor

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

Hi Hedayat,

Hedayat Vatankhah wrote:
>
> Hi,
>
> I finished writing the base structure of a new touch perceptor and I'm 
> going to commit my code to CVS (is it wrong to to this at this stage?!).
>

Great!

> As a beginner, I've tried to make the minimum possible changes in the 
> existing sources. I've added two new classes to the collisionperceptor 
> library: TouchPerceptorHandler & ExtendedTouchPerceptor(Sorry if the 
> names are too bad! I can't find good choices for now, any suggestions 
> are highly appreciated!!).
>

How about ForceResistancePerceptor instead of ExtendedTouchPerceptor? 
There are actual sensors for robots called force resistance sensor (FRS) 
and they measure pretty much the same thing as your perceptor :-)

>
> TouchPerceptorHandler is an extension to ContactJointHandler. It 
> should be used instead of the ContactJointHandler and no extra handler 
> (PerceptorHandler) is needed.(In fact I think it should be merged with 
> the ContactJointHandler class)
>

After a test phase, we should consider to merge the two then.

>
> Currently, the ExtendedTouchPerceptor provides each contact point 
> (global coordinates of the collision) and the forceapplied to the 
> body. Each object can have up to three contact points with each object 
> (when two surfaces are completely in touch). We have accessto the 
> force and torque which is applied to the body at each contact point.
>
>
> Providing all of the contact point (which should be in local 
> coordinates) will increase flexibility, but it'll make the output much 
> longer. Instead of this, we could provide a kind of average force 
> applied to the whole part.
>
>
> Now, what is the desired output? Please answer!
>

Since we are trying to decrease output to the agents to a minimum 
currently, I would propose to output the average of the force vector 
magnitudes. What do you think?

Cheers,
Joschka

[simspark-devel] New touch sensor

[Hedayat V. <hed...@ai...>]

Hi,

I finished writing the base structure of a new touch perceptor and I'm 
going to commit my code to CVS (is it wrong to to this at this stage?!). 
As a beginner, I've tried to make the minimum possible changes in the 
existing sources. I've added two new classes to the collisionperceptor 
library: TouchPerceptorHandler & ExtendedTouchPerceptor(Sorry if the 
names are too bad! I can't find good choices for now, any suggestions 
are highly appreciated!!).


TouchPerceptorHandler is an extension to ContactJointHandler. It should 
be used instead of the ContactJointHandler and no extra handler 
(PerceptorHandler) is needed.(In fact I think it should be merged with 
the ContactJointHandler class)


Currently, the ExtendedTouchPerceptor provides each contact point 
(global coordinates of the collision) and the forceapplied to the body. 
Each object can have up to three contact points with each object (when 
two surfaces are completely in touch). We have accessto the force and 
torque which is applied to the body at each contact point.


Providing all of the contact point (which should be in local 
coordinates) will increase flexibility, but it'll make the output much 
longer. Instead of this, we could provide a kind of average force 
applied to the whole part.


Now, what is the desired output? Please answer!


Thanks,
Hedayat

Re: [simspark-devel] Countdown for Atlanta

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

Hi,

Joschka Boedecker wrote:
> [...]
> One problem that I noticed was that there is an error message repeated 
> many many times when an agent disconnects (something like 
> "AgentDisappear called for unknown agent id", I'll write more detail 
> later), both in the single-threaded and the mulit-threaded versions. 
> Other than that, the server runs very stable in both configurations for 
> me now :-)
>   

This one's fixed in the CVS already, thanks to the solution you sent 
earlier.

>   
>>   
>>     
>>> Also, as soon as you have a new patch for the latest CVS version, could
>>> you please send it to me so that I can create a branch in the CVS?
>>>
>>>     
>>>       
>> The patch is here:
>> http://xuyuan.cn.googlepages.com/rcssserver3D-timer-cvs0705310335.pat.bz2
>>   
>>     
>
> Thanks for providing the patch so quickly. I will commit some other 
> changes to the main branch now and then create a new branch for the 
> version with your timer. This should make developing and testing much 
> easier.
>   

I created the branch SIMSPARK_TIMER in the sserver CVS. You can check it 
out by using:

cvs -z3 -d:ext:<yourlogin>@sserver.cvs.sf.net:/cvsroot/sserver co -P -r 
SIMSPARK_TIMER rcssserver3D

Right now, it is in sync with the main branch, but this might change 
quickly ;-) Please try to keep your branch up to date by doing a

cvs update -j HEAD

in the local working directory of your branch regularly. This ensures 
that we can merge the changes later on.

One more thing: you'll have to get a few extra files in order to get the 
current server running correctly. This is because we started using 3D 
objects exported from modeling programs and textures in the server. We 
will make an extra package available containing these files, but for now 
please download the following files and put them into the app/simspark 
folder:

http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/soccerball.obj
http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/soccerball.tga
http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/grass.tga

If everything is correct, it should look like this:

http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/fieldwithcylinders1.jpg
http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/fieldwithcylinders2.jpg

Happy hacking,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Yuan,

Yuan Xu wrote:
> Hi Joschka,
>
>
>   
>>  .... If the
>> application is too busy for SDL to create appropriate events, do you
>> think it would make sense to have an other application ("referee") that
>> connects to the server as a monitor and sends commands using the trainer
>> protocol? This way we could make the game kick of and do drop ball at
>> least...
>>     
>
> I can try it tomorrow.
>
>   

OK, great! Please note that the TrainerCommandParser will probably have 
to be adapted to the new agent (the current version probably only moves 
one body of the agent, since the spheres only had one body).

>> .... We could maybe ask teams
>> what they think about both of these changes. If people don't mind, we
>> could go ahead and do it, I guess ;-)
>>     
>
> OK, a discussion in the mail-list?
>
>   

Yes, exactly. I can write an email to the list later today or tomorrow.

>   
>> One more issue is that we have to make a definite decision about which
>> version of the timer to use in Atlanta soon.
>>     
>
> That's right. It is very important for my work.
>
>   
>> Ideal scenario
>> =========
>> ...
>> Options
>> =====
>>
>> The above can be implemented using threads or just in a single run loop
>> having different timing values for the different perceptors/effectors.
>>
>>     
>
> I hope my patch can meet the requirement.
> In the patch,
> vision perceptor runs at 25Hz ( the perceptor interval can can be set
> in rsg by setInterval ),
> render loop and monitor loop run at 25Hz,
> others run at 50Hz.
>
>   

Perfect! :-D

>> I think you implemented both options already (correct me if I'm wrong).
>> In my opinion, if the threaded version runs stably, this would be the
>> preferred option since it really boosts performance. However, if we
>> can't be sure that it runs stably, we should go with the single-threaded
>> version. Stability is more important than performance for the competition.
>>     
>
> Yes, you are right.
> The server can be configured in threaded or single thread mode in my
> patch, by calling method SimulationServer::SetMultiThreads(bool).
> I set the server run in single thread in the
> sparkSetupMonitorLogPlayer, so that the log player can run properly.
>
>   

Wow, that's even better than I thought. Just using a switch in the 
configuration file, we can use just a single-thread or the 
multi-threaded version? Awesome!

> I hope we can make the threaded server stable.
> I have fixed the bug which happened while agent connecting/disconnectiong.
>
>   

It runs stable on my laptop now, and it's quite fast! I can run 10 
agents with the integrated monitor and the rendering is still at 
acceptable speed. The only problem is the input not being usable then 
(the problem we already discussed).

With the single-threaded version, I can now run 6 agents on my laptop, 
which is great 'cause it means we can have 3 vs 3 games for sure :-)

One problem that I noticed was that there is an error message repeated 
many many times when an agent disconnects (something like 
"AgentDisappear called for unknown agent id", I'll write more detail 
later), both in the single-threaded and the mulit-threaded versions. 
Other than that, the server runs very stable in both configurations for 
me now :-)

>> We should make a decision about this on Saturday of this week (06/02).
>> On Monday of next week (06/04), we should try to release RC1 for
>> Atlanta, and shortly after that (maybe 06/09), we should make a final
>> release.
>>
>> Do you think we can keep this schedule? Please let me know what you think.
>>     
>
> I think we can.
> I will test the server as much as I can ;-)
>   

Great, thanks a lot.

>   
>> Also, as soon as you have a new patch for the latest CVS version, could
>> you please send it to me so that I can create a branch in the CVS?
>>
>>     
>
> The patch is here:
> http://xuyuan.cn.googlepages.com/rcssserver3D-timer-cvs0705310335.pat.bz2
>   

Thanks for providing the patch so quickly. I will commit some other 
changes to the main branch now and then create a new branch for the 
version with your timer. This should make developing and testing much 
easier.

> PS: the cvs updates so quickly, 

Working hard over here, too ;-) There's still so much work to do...

> I tested the patch, there are unknown
> some materials(such as "matLeft"),
> I think it is not the matter of patch. 

Yes, I also noticed that, thanks. I'll fix this in a minute.

> I need to sleep now ;-)
>
>   

I hope you could recover a little. Thanks for your efforts and keep up 
the good work!

Cheers,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Joschka,


>  .... If the
> application is too busy for SDL to create appropriate events, do you
> think it would make sense to have an other application ("referee") that
> connects to the server as a monitor and sends commands using the trainer
> protocol? This way we could make the game kick of and do drop ball at
> least...

I can try it tomorrow.

> .... We could maybe ask teams
> what they think about both of these changes. If people don't mind, we
> could go ahead and do it, I guess ;-)

OK, a discussion in the mail-list?


> One more issue is that we have to make a definite decision about which
> version of the timer to use in Atlanta soon.

That's right. It is very important for my work.

> Ideal scenario
> =========
> ...
> Options
> =====
>
> The above can be implemented using threads or just in a single run loop
> having different timing values for the different perceptors/effectors.
>

I hope my patch can meet the requirement.
In the patch,
vision perceptor runs at 25Hz ( the perceptor interval can can be set
in rsg by setInterval ),
render loop and monitor loop run at 25Hz,
others run at 50Hz.

> I think you implemented both options already (correct me if I'm wrong).
> In my opinion, if the threaded version runs stably, this would be the
> preferred option since it really boosts performance. However, if we
> can't be sure that it runs stably, we should go with the single-threaded
> version. Stability is more important than performance for the competition.

Yes, you are right.
The server can be configured in threaded or single thread mode in my
patch, by calling method SimulationServer::SetMultiThreads(bool).
I set the server run in single thread in the
sparkSetupMonitorLogPlayer, so that the log player can run properly.

I hope we can make the threaded server stable.
I have fixed the bug which happened while agent connecting/disconnectiong.

> We should make a decision about this on Saturday of this week (06/02).
> On Monday of next week (06/04), we should try to release RC1 for
> Atlanta, and shortly after that (maybe 06/09), we should make a final
> release.
>
> Do you think we can keep this schedule? Please let me know what you think.

I think we can.
I will test the server as much as I can ;-)

> Also, as soon as you have a new patch for the latest CVS version, could
> you please send it to me so that I can create a branch in the CVS?
>

The patch is here:
http://xuyuan.cn.googlepages.com/rcssserver3D-timer-cvs0705310335.pat.bz2

PS: the cvs updates so quickly, I tested the patch, there are unknown
some materials(such as "matLeft"),
I think it is not the matter of patch. I need to sleep now ;-)


-- 
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] Countdown for Atlanta

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

Hi Yuan,

Yuan Xu wrote:

>
>>
>> Timing problems? Sometimes the mouse movements have an effect after some
>> time, ie. you move the mouse, nothing happens, but some time later the
>> camera suddenly jerks somewhere (you usually don't want it to be).
>>
>
> I do a test, I logged some information in InputControl::StartCycle().
> When the monitor do not respond the keyboard and mouse, the simulation
> runs smoothly,
> but can not get any other input from the SDL, except the SDLTimer.
> I think the reason is the SDL can not create the event in real time
> when the system is very busy.
> And the SDLTimer does not work like other SDL devices( set the
> callback by SDL_SetEventFilter ),
> so it still works.
> This can explain why you can see the 6 agents and server works
> properly if you do not change the camera.
>
>

Thanks for the report. I was suspecting something along these lines, but 
of course it's better to check ;-) During a game, we should have 
auto-cam mode enabled (which is not implemented yet), so this shouldn't 
be a problem, but of course we need to be able to interfere with the 
game, e.g., to do a "drop ball" or to initiate kick off. If the 
application is too busy for SDL to create appropriate events, do you 
think it would make sense to have an other application ("referee") that 
connects to the server as a monitor and sends commands using the trainer 
protocol? This way we could make the game kick of and do drop ball at 
least...

> About the server crash problem while agent connecting,
> I think we can save the action firstly, and then in method
> PrePhysicsUpdateInternal realize the action.
> It just like the DriveEffector do.
> I changed the InitEffector and SingleMatInitEffector in this way,
> the crash problem do not happen again.
> However, other effectors, such like hingEffector and
> UniversalJointEffector, calls the ODE functions directly, they are
> seems OK.
> It is better that all the effectors save the action firstly, I think.
> Do you agree with me? and then I can make a new patch.
>

Sounds like a good idea. :-)

>>
>> I agree with the proposal. It makes the model more realistic.
>> (In addition we may use it to get rid of the fixed joint connecting the
>> head to the torso.)
>>
>
> Yeah,and maybe the vision perceptor can be placed in the head.
> :-)
>

In general, I agree of course, but I think it might be already too late 
to restrict the joint angles. I know that several teams have built their 
skills (like, e.g. getting up) relying on this feature, and there is not 
much time to program new skills. After the competition, however, the 
joint angles should be restricted to more realistic values.

To place the vision perceptor in the head might cause similar problems 
for localization, but I'm not sure about that. We could maybe ask teams 
what they think about both of these changes. If people don't mind, we 
could go ahead and do it, I guess ;-)

One more issue is that we have to make a definite decision about which 
version of the timer to use in Atlanta soon. To be able to do that, I'd 
like to hear your opinion on the following issues, Yuan.

Ideal scenario
=========

We have a mechanism that allows different cycle speeds for different 
effectors and sensors. The control loop should run at 50 Hz, so all the 
joint effectors and the joint perceptors, plus the gyro rate and the 
touch sensor run at this speed, too. Vision percepts are generated at 15 
Hz.  Furthermore, the visualization runs at a fixed 25 frames/sec.

Options
=====

The above can be implemented using threads or just in a single run loop 
having different timing values for the different perceptors/effectors.

***

I think you implemented both options already (correct me if I'm wrong). 
In my opinion, if the threaded version runs stably, this would be the 
preferred option since it really boosts performance. However, if we 
can't be sure that it runs stably, we should go with the single-threaded 
version. Stability is more important than performance for the competition.

We should make a decision about this on Saturday of this week (06/02). 
On Monday of next week (06/04), we should try to release RC1 for 
Atlanta, and shortly after that (maybe 06/09), we should make a final 
release.

Do you think we can keep this schedule? Please let me know what you think.

Also, as soon as you have a new patch for the latest CVS version, could 
you please send it to me so that I can create a branch in the CVS?

Thanks a lot in advance!

Cheers,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Jan and all,


>
> We will only have Linux PCs (2.8GHZ, P4) in Atlanta.
>

Thanks for your information ;-)

>
> Timing problems? Sometimes the mouse movements have an effect after some
> time, ie. you move the mouse, nothing happens, but some time later the
> camera suddenly jerks somewhere (you usually don't want it to be).
>

I do a test, I logged some information in InputControl::StartCycle().
When the monitor do not respond the keyboard and mouse, the simulation
runs smoothly,
but can not get any other input from the SDL, except the SDLTimer.
I think the reason is the SDL can not create the event in real time
when the system is very busy.
And the SDLTimer does not work like other SDL devices( set the
callback by SDL_SetEventFilter ),
so it still works.
This can explain why you can see the 6 agents and server works
properly if you do not change the camera.


About the server crash problem while agent connecting,
I think we can save the action firstly, and then in method
PrePhysicsUpdateInternal realize the action.
It just like the DriveEffector do.
I changed the InitEffector and SingleMatInitEffector in this way,
the crash problem do not happen again.
However, other effectors, such like hingEffector and
UniversalJointEffector, calls the ODE functions directly, they are
seems OK.
It is better that all the effectors save the action firstly, I think.
Do you agree with me? and then I can make a new patch.

>
> I agree with the proposal. It makes the model more realistic.
> (In addition we may use it to get rid of the fixed joint connecting the
> head to the torso.)
>

Yeah,and maybe the vision perceptor can be placed in the head.
:-)


-- 
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] Countdown for Atlanta

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

Hi Yuan,

Yuan Xu wrote:

> I can only work in Linux. Maybe newer version library can solve them.
> Will only the Linux be used in Atlanta? or multi-system, such as
> windows and MacOS ?

We will only have Linux PCs (2.8GHZ, P4) in Atlanta.


> 
>> Concerning the development in the CVS, I think we will first merge the
>> projectx branch that Oliver created with the main branch, and then we
>> make a new branch for the threaded version. Do you have any idea about
>> the input problems mentioned above?

Timing problems? Sometimes the mouse movements have an effect after some 
time, ie. you move the mouse, nothing happens, but some time later the 
camera suddenly jerks somewhere (you usually don't want it to be).

>>
> 
> What about my proposal about restrict the joint angle range?

I agree with the proposal. It makes the model more realistic.
(In addition we may use it to get rid of the fixed joint connecting the 
head to the torso.)

Bye,
Jan

Re: [simspark-devel] Countdown for Atlanta

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

Hi Joschka,


>
> First, a quick comment on the patch: I noticed that probably an older
> version of sceneserver.cpp was used, as the patch removes some recent
> code in SceneServer::ImportScene (namely searching for data files in the
> local dir _and_ in the pkgdatadir).

Sorry, I worked on 0.5.4 package,and then make the patch manually,
and missed the new sceneserver.
The modifies are not conflict.


> Another problem that I had was that sometimes (not often, and
> non-deterministically), the InitEffector will cause the Server to crash
> with an ODE internal error (error message something like "dGeom was
> moved in locked space"). I have never seen this with the non-threaded
> version so far, so maybe we need a lock somewhere in the InitEffector,
> too (because it changes the Scene and uses ODE functions).

I checked the InitEffector, it calls ODE functions in Realize method
But I notice that almost every Effector's Realize methods call ODE functions,
it seems that the server doesn't work safely.
However, I only face such problem while agent connected or disconnected.
So, *maybe* calling ODE function is OK, but other methods in
connect/disconnect need be locked.

> On an Apple Mac I got some other problems, too, that did not occur in Linux:
>
> * I can not use any visualization because OpenGL is not thread-safe in
> MacOS. It seems that maybe two different threads are trying to issue
> OpenGL commands which does not work with Apple's GL implementation
> (threads can be used, but only if all the OpenGL commands for a context
> are issued in the same thread).
>
> * Ruby (version 1.8.2) would sometimes get a stack exception when I
> started several agents (over the network, only the server was running on
> the Mac).

I can only work in Linux. Maybe newer version library can solve them.
Will only the Linux be used in Atlanta? or multi-system, such as
windows and MacOS ?

> Concerning the development in the CVS, I think we will first merge the
> projectx branch that Oliver created with the main branch, and then we
> make a new branch for the threaded version. Do you have any idea about
> the input problems mentioned above?
>

What about my proposal about restrict the joint angle range?


-- 
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] Countdown for Atlanta

[Hedayat V. <hed...@ai...>]

Hi,
OK, I'll just convert the output of the gyro sensor from Radians to 
Degrees so that it would be more consistent with the rest of the
server (which has some inconsistencies yet!)

I'll try to work on the pressure/force sensor in these days (right after 
forgetting about the offending interview in the US embassy in dubai! )
Any comments?

Good luck,
Bye,
Hedayat

/*jbo...@un...*/ wrote on 05/22/2007 04:44:15 PM:
> Hi Hedayat,
>
> Hedayat Vatankhah wrote:
>
>>
>> /*jbo...@un...*/ wrote on 05/17/2007 12:24:40 PM:
>>> It might be nice to extend the current gyro sensor to also include 
>>> the angle of the corresponding body. The touch sensor in the current 
>>> release gives very simple binary information. Hedayat already 
>>> proposed to include more detailed information like e.g. pressure. 
>>> Hedayat, could you continue to work on these things?
>
>> Hi,
>> Yes, I will!
>> But I need some help about the gyro sensor extension. At first, I 
>> thought that I know what is the "angle of the body"; but I'm not sure 
>> about it!
>> How should I represent the orientation of the body?! What does 
>> (90,90,0) mean? 90 degrees of rotation around x and then y axis or 90 
>> degrees around y then x?! Or maybe I should use quaternions like ODE? 
>> (maybe I'm just completely confused! sorry if it's the case)
>>
>
> Actually, I find it a little confusing, too. But actually, to get 
> these three values, people only need to integrate the velocities over 
> time, so maybe we don't need to provide this angle information after all.
>
> So let's leave the gyro like it is for now, but if you have a nice 
> idea how to extend the touch sensor into a pressure sensor, go for it :-)
>
> Cheers,
> Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi all,

I'll try to give some more details of my tests with the threaded server 
below.

Jan Murray wrote:
> [...]
> The internal rendering
> seems to work, though. But with 6 local agents connected it doesn't
> react to mouse and keyboard any more. :-(
>
>   

First, a quick comment on the patch: I noticed that probably an older 
version of sceneserver.cpp was used, as the patch removes some recent 
code in SceneServer::ImportScene (namely searching for data files in the 
local dir _and_ in the pkgdatadir).

As I said before, I could patch and compile all files without any 
problems. The performance increase is terrific! :-D While before I could 
only use 2 agents at the same time before the simulation would become 
unusable on my laptop, I could now have 5 agents running in parallel. If 
I use 6 agents or more, however, I can not use mouse or keyboard 
anymore, just as Jan noticed above. The rendering was not having any 
problems though, it was still going very smooth, even with more than 6 
agents.

Another problem that I had was that sometimes (not often, and 
non-deterministically), the InitEffector will cause the Server to crash 
with an ODE internal error (error message something like "dGeom was 
moved in locked space"). I have never seen this with the non-threaded 
version so far, so maybe we need a lock somewhere in the InitEffector, 
too (because it changes the Scene and uses ODE functions).

On an Apple Mac I got some other problems, too, that did not occur in Linux:

* I can not use any visualization because OpenGL is not thread-safe in 
MacOS. It seems that maybe two different threads are trying to issue 
OpenGL commands which does not work with Apple's GL implementation 
(threads can be used, but only if all the OpenGL commands for a context 
are issued in the same thread).

* Ruby (version 1.8.2) would sometimes get a stack exception when I 
started several agents (over the network, only the server was running on 
the Mac).

Concerning the development in the CVS, I think we will first merge the 
projectx branch that Oliver created with the main branch, and then we 
make a new branch for the threaded version. Do you have any idea about 
the input problems mentioned above?

Cheers,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Jan and Joschka,


> > (SimulationServer) SimControlNode 'kerosin/InputControl' not found
>
> Don't know about this.

I think it may be an original mistake in the spark.cpp
the kerosin::InputControl register name is "InputControl",
so change "kerosin/InputControl" to "InputControl" in Line 136.
and a similar change is needed in Line 147: "kerosin/RenderControl"
--> "RenderControl"

>
> > (SimulationServer) SimControlNode 'kerosin/InputControl' not found
>
> Same error as with simspark.
>
> > (SimulationServer) entering runloop
> > lt-monitorspark: /usr/include/boost/shared_ptr.hpp:253: T* boost::shared_ptr<T>::operator->() const [with T = oxygen::SimControlNode]: Assertion `px != 0' failed.
> > Abgebrochen
>
> monitorspark always exits with this message. The internal rendering
> seems to work, though. But with 6 local agents connected it doesn't
> react to mouse and keyboard any more. :-(
>

I am sorry, I have not test the external monitor before.
Joschka has found the solution ;-)
I think there may be a same problem in my patch:
in SceneServer::PostPhysicsUpdate() we also need:
if ( mActiveScene.get() == 0  )
{
    return;
}

And even more I try to use the monitorspark load the logfile.
but assertion failed again.
I checked the code, and found that the SparkMonitorLogFileServer is
inheritor of SimControlNode,
and all the SimControlNodes run parallelly, but the
SparkMonitorLogFileServer modifies the scene.
So it seems that we need to lock the scene.
However, I think a better solution may be let the
SparkMonitorLogFileServer inheriting from the SimulationServer.
What about your opinion?

At last, I found sometimes the server abort when the agent disconnected.
The prints said the Ruby Segmentation fault.
The Ruby is 1.8.6, I do not know if is it matter.


-- 
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] Countdown for Atlanta

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

Hi Jan and all,

first of all, I also could apply Yuan's patch without any problems 
(great work, Yuan!). I face similar problems and I will write in more 
detail tomorrow, for now I just wanted to give the fix for the failed 
assertion below.
>> (SimulationServer) entering runloop
>> lt-monitorspark: /usr/include/boost/shared_ptr.hpp:253: T* boost::shared_ptr<T>::operator->() const [with T = oxygen::SimControlNode]: Assertion `px != 0' failed.
>> Abgebrochen
>>     
>
> monitorspark always exits with this message. The internal rendering
> seems to work, though. But with 6 local agents connected it doesn't
> react to mouse and keyboard any more. :-(
>
> Any ideas about why the assertion fails?
>   

In lib/oxygen/simulationserver/simulationserver.cpp, in Method Run, 
there is a test missing to see whether the shared pointer to the 
AgentControlNode is non-zero. So instead of

shared_ptr<SimControlNode> agentCtrNode = GetControlNode("AgentControl");
agentCtrNode->Run();

insert a quick check and you should be fine (monitorspark uses the 
simulationserver, but has no agentcontrol node...)

shared_ptr<SimControlNode> agentCtrNode = GetControlNode("AgentControl");

if (agentCtrNode.get())
        agentCtrNode->Run();

Cheers,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Yuan and all,

|On Wed, 23 May 2007 11:33:09 +0800, "Yuan Xu" <xuy...@gm...> said:

> I make a patch for the current cvs:
> http://xuyuan.cn.googlepages.com/rcssserver3D-timer-cvs20070523.patch.bz2
> Hope get more tests and feedback soon ;-)

I downloaded and applied the patch, and could compile the simulator
without problems. But I have some problems in running simspark and
especially monitorspark.

1. Simspark

> [robocup@aeonflux:simspark] $ ./simspark 
> (spark.rb) sparkEnableLog logTarget=:cerr logType=eError
> (spark.rb) sparkSetupServer
> (spark.rb) sparkSetupInput
> (spark.rb) sparkAddFPSCamera
> (bindings.rb) setting up bindings
> (spark.rb) sparkEnableLog logTarget=:cerr logType=eAll
> (ScriptServer) updating cached script variables
> (ScriptServer) Running soccersim.rb

Okay so far.

> (Core::Get) ERROR: Could not find object 'sys/server/opengl'
> (Light) ERROR: OpenGLServer not found
> (Core::Get) ERROR: Could not find object 'sys/server/opengl'
> (Light) ERROR: OpenGLServer not found

That's because I disabled internal rendering

> (GeometryServer) imported mesh 'StdUnitBox with 'oxygen/StdMeshImporter'
> (SceneServer) imported scene file 'rsg/agent/flag_no_viz.rsg with 'RubySceneImporter at /usr/scene/
[...]

> (spark.rb) sparkRegisterMonitorCmdParser TrainerCommandParser
> (MonitorServer) Registered monitor item 'GameStateItem'
> (ScriptServer) updating cached script variables
> (ScriptServer) updating cached script variables
> (SimulationServer) SimControlNode 'kerosin/InputControl' not found

Don't know about this.

> (SimulationServer) entering runloop
> (NetControl) 'MonitorControl' setting up a server on TCP:3200
> (NetControl) 'AgentControl' setting up a server on TCP:3100




-------------------------------------------------------------------------

2. monitorspark

> [robocup@aeonflux:monitorspark] $ ./monitorspark 
> (spark.rb) sparkEnableLog logTarget=:cerr logType=eError
> (spark.rb) sparkSetupRendering
> (spark.rb) sparkSetupInput
> (spark.rb) sparkSetupMonitor
> (spark.rb) sparkAddFPSCamera
> (bindings.rb) setting up bindings
> (spark.rb) sparkEnableLog logTarget=:cerr logType=eAll
> (ScriptServer) updating cached script variables
> (ScriptServer) Running soccersim.rb
> (spark.rb) sparkRegisterCustomMonitor SoccerMonitor
> (spark.rb) sparkRegisterCustomRender SoccerRender
> (ScriptServer) updating cached script variables
> (ScriptServer) updating cached script variables

> (SimulationServer) SimControlNode 'kerosin/InputControl' not found

Same error as with simspark.

> (SimulationServer) entering runloop
> lt-monitorspark: /usr/include/boost/shared_ptr.hpp:253: T* boost::shared_ptr<T>::operator->() const [with T = oxygen::SimControlNode]: Assertion `px != 0' failed.
> Abgebrochen

monitorspark always exits with this message. The internal rendering
seems to work, though. But with 6 local agents connected it doesn't
react to mouse and keyboard any more. :-(

Any ideas about why the assertion fails?


Bye,
Jan


PS: The monitorsparks from ProjectX and rcssserver3d-0.5.4 work.

Re: [simspark-devel] Countdown for Atlanta

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

Hi Joschka,


>
> How about the timing with 6 connected agents? If this runs properly, we
> could at least play 3 on 3 games :-)
>

Yeah, I have 6 agents walking at the same time!
(I changed the agentStep to 0.02s, and the timing is OK )

However, the server became very slowly when 10 agents connected.

And about the stack problem:
In the ODE user guide P.81 :
"Unix-like operating systems typically allocate stack space as it is
needed, with an upper limit that might
be in the hundreds of Mb.Windows compilers normally allocate a much
smaller stack. If you experience
crashes when running large systems, try increasing the stack size."
and the simspark only use about 64 Mb,
so I think only the windows version may face this problem.


>
> Great. Do you think you could commit your current changes to a new
> branch in the sserver CVS? Then more people could help with the testing
> :-) Alternatively, if you could provide a patch against the current CVS,
> I could open the new branch and commit your changes for you.
>

I make a patch for the current cvs:
http://xuyuan.cn.googlepages.com/rcssserver3D-timer-cvs20070523.patch.bz2
Hope get more tests and feedback soon ;-)

-- 
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] Countdown for Atlanta

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

Hi Hedayat,

Hedayat Vatankhah wrote:

>
> /*jbo...@un...*/ wrote on 05/17/2007 12:24:40 PM:
>> It might be nice to extend the current gyro sensor to also include 
>> the angle of the corresponding body. The touch sensor in the current 
>> release gives very simple binary information. Hedayat already 
>> proposed to include more detailed information like e.g. pressure. 
>> Hedayat, could you continue to work on these things?

> Hi,
> Yes, I will!
> But I need some help about the gyro sensor extension. At first, I 
> thought that I know what is the "angle of the body"; but I'm not sure 
> about it!
> How should I represent the orientation of the body?! What does 
> (90,90,0) mean? 90 degrees of rotation around x and then y axis or 90 
> degrees around y then x?! Or maybe I should use quaternions like ODE? 
> (maybe I'm just completely confused! sorry if it's the case)
>

Actually, I find it a little confusing, too. But actually, to get these 
three values, people only need to integrate the velocities over time, so 
maybe we don't need to provide this angle information after all.

So let's leave the gyro like it is for now, but if you have a nice idea 
how to extend the touch sensor into a pressure sensor, go for it :-)

Cheers,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Yuan,

Yuan Xu wrote:
> Hi Markus,
>
> Thanks for your reminder.
> After some changes, the server runs faster!
>   

That's great news :-D

> The server can keep running when 10 agents connected, but with incorrect timing.
>   

How about the timing with 6 connected agents? If this runs properly, we 
could at least play 3 on 3 games :-)

> I will do more test then, and try to have a look at stack problem.
>   

Great. Do you think you could commit your current changes to a new 
branch in the sserver CVS? Then more people could help with the testing 
:-) Alternatively, if you could provide a patch against the current CVS, 
I could open the new branch and commit your changes for you.

Cheers,
Joschka

Re: [simspark-devel] Countdown for Atlanta

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

Hi Markus,

Thanks for your reminder.
After some changes, the server runs faster!
The server can keep running when 10 agents connected, but with incorrect timing.
I will do more test then, and try to have a look at stack problem.

>
> I think we already have a full copy of the scene state that is relevant
> to physics: The ODE library itself holds all relevant state ;-)
>
> Therefore it should be possible to run the physics thread in parallel.
> Possible conflicts only arise when the new ODE state is written back to
> the scene graph. At this point we have to wait for other threads to
> become ready.
>
> The point from which the physics thread could run in parallel lies
> within the SceneServer::Update() method _after_ the call to
> PrePhysicsUpdate(). From this point on the collision handling and
> stepping of the world relies entirely on the internal ODE state.
> Therefore both steps could be run in parallel to e.g. the OpenGL thread.
>
> The collision handling runs mostly within ODE code. Excpetions are the
> collision callbacks that may modify the scene in turn. The most common
> Collisionhandler nodes are the ContactJointHandler. This nodes calls the
>   dJointAttach ODE function and should therefore be no problem.
>
> Other collision handler nodes are derived from the recorder handler that
> collects collision events for further processing within the node itself.
> The collected information is ususally only referenced after the physics
> update, e.g. from the SoccerRuleAspect or some sensor implementation.
>
> If other threads don't modify the ODE state while the physics thread
> runs, there should be no problem. However as ODE is quite stack hungry,
> we might have to increase the stack size manually in the pyhsics thread
> [1,2].
>
> Cheers,
> Markus
>
> [1] http://thread.gmane.org/gmane.comp.lib.ode/12094/focus=12095
> [2]
> http://news.gmane.org/find-root.php?message_id=%3c7dfa3e5505081812185ce79b97%40mail.gmail.com%3e
>


-- 
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] Countdown for Atlanta

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

Hi all,

Yuan Xu wrote:
[...]
> The fact is that, all the threads should be executed in the right
> order. There are only one scene in the server, the agent-manager
> thread and monitor-manager thread often have to wait the physic
> thread. On the other hand, the physic thread can not run before the
> other thread finish their loops. I think if we want to make them
> running simultaneously, a copy of scene is needed. I draw a graphic
> to explain my idea, please see 
> http://picasaweb.google.com/xuyuan.cn/C75/photo#5065569456434569362 
> And the cached scene and the action queue can make some delay to the 
> perception and action, the delay is the factor the real robot should 
> face. However the scene copying is costing, so I can not make sure
> this will be better.

I think we already have a full copy of the scene state that is relevant 
to physics: The ODE library itself holds all relevant state ;-)

Therefore it should be possible to run the physics thread in parallel. 
Possible conflicts only arise when the new ODE state is written back to 
the scene graph. At this point we have to wait for other threads to 
become ready.

The point from which the physics thread could run in parallel lies 
within the SceneServer::Update() method _after_ the call to 
PrePhysicsUpdate(). From this point on the collision handling and 
stepping of the world relies entirely on the internal ODE state. 
Therefore both steps could be run in parallel to e.g. the OpenGL thread.

The collision handling runs mostly within ODE code. Excpetions are the 
collision callbacks that may modify the scene in turn. The most common 
Collisionhandler nodes are the ContactJointHandler. This nodes calls the 
  dJointAttach ODE function and should therefore be no problem.

Other collision handler nodes are derived from the recorder handler that 
collects collision events for further processing within the node itself. 
The collected information is ususally only referenced after the physics 
update, e.g. from the SoccerRuleAspect or some sensor implementation.

If other threads don't modify the ODE state while the physics thread 
runs, there should be no problem. However as ODE is quite stack hungry, 
we might have to increase the stack size manually in the pyhsics thread 
[1,2].

Cheers,
Markus

[1] http://thread.gmane.org/gmane.comp.lib.ode/12094/focus=12095
[2] 
http://news.gmane.org/find-root.php?message_id=%3c7dfa3e5505081812185ce79b97%40mail.gmail.com%3e

Re: [simspark-devel] Countdown for Atlanta

[Hedayat V. <hed...@ai...>]

Hi,
Yes, I will!
But I need some help about the gyro sensor extension. At first, I 
thought that I know what is the "angle of the body"; but I'm not sure 
about it!
How should I represent the orientation of the body?! What does (90,90,0) 
mean? 90 degrees of rotation around x and then y axis or 90 degrees 
around y then x?! Or maybe I should use quaternions like ODE? (maybe I'm 
just completely confused! sorry if it's the case)

Good luck,
Bye,
Hedayat

/*jbo...@un...*/ wrote on 05/17/2007 12:24:40 PM:
> It might be nice to extend the current gyro sensor to also include the 
> angle of the corresponding body. The touch sensor in the current 
> release gives very simple binary information. Hedayat already proposed 
> to include more detailed information like e.g. pressure. Hedayat, 
> could you continue to work on these things?

Re: [simspark-devel] Countdown for Atlanta

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

Hi Joschka and all,



> The question is now, how we should proceed.

Yes, if I know what we need to do, things will become easier.
However, we may know what to do after do some experiments.

> We could use different timers for the effectors and perceptors (something Yuan proposed in the beginning when he started working on these things), and just do a single loop, or use the threaded version. Since the threaded version is more complicated and doesn't seem to bring too much performance gain, it seems more feasible to use a single runloop in the server. However, I'm not sure about this. Yuan, could you please let us know what you think about these issues?
>

The fact is that, all the threads should be executed in the right order.
There are only one scene in the server, the agent-manager thread and
monitor-manager thread often have to wait the physic thread. On the
other hand, the physic thread can not run before the other thread
finish their loops. I think if we want to make them running
simultaneously, a copy of scene is needed.
I draw a graphic to explain my idea, please see
http://picasaweb.google.com/xuyuan.cn/C75/photo#5065569456434569362
And the cached scene and the action queue can make some delay to the
perception and action, the delay is the factor the real robot should
face.
However the scene copying is costing, so I can not make sure this will
be better.

And there are also some problem of the ruby in mulit-thread.
So the single thread is more simple and feasible, but there are also
some work need to do.
We have to make a choice early.
I will try the buffered thread implementation, and report the result
as soon as I can.



> P.S.: if you think something vital is missing in the list of necessary
> features, please let me know ASAP. Thanks :-)

After installed the rcssserver3d-0.5.4, I noticed the usleep is used
to slow down the logfile,
the better solution may be do not save messages with the same simtime again.
However if the timer works, this is no needed.

I think the joints can rotate in 360 degrees is not realistic!
The joint should be restricted in a range.
Otherwise the agent can do something impossible in real:
In the round 1 of Iran Open, some agents use their hands and foots as wheels!
And I think this is not hard to implement, the ODE can set the motor
parameters: dParamLoStop and dParamHiStop.


--
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] Countdown for Atlanta

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

On 17/05/2007, at 6:54 PM, Joschka Boedecker wrote:

> as you know, the RoboCup 2007 competitions are advancing fast, and  
> we have a lot of work left to do. As I pointed out in my mail to  
> the mailing lists earlier, the time frame we have for getting new  
> features into the simulator is only two weeks from now. Therefore,  
> I'd like to confirm the task assignments and the progress that has  
> been made (and/or problems encountered).

thanks all for the great work so far!

As the number of developers is increasing and at the same time  
becomes more distributed over the planet, we should have a (physical)  
developer meeting during RoboCup. The focus of the meeting should be  
a bit different of the (usual) roadmap discussion: we should discuss  
how we'll organise the next year of development, and how you all  
think we should continue. At the end of the day, it's probably also  
good to just meet.
I'd like to try keeping the number of people somehow manageable. The  
detailed 'what' of the future development shouldn't be of major  
importance for this meeting, so we can keep the number of people  
restricted to current and prospective developers (of course, everyone  
else can still join in).

I guess it would be good to meet at some point before the roadmap  
discussion, maybe early at some point when everything is set up and  
running. I'll look out for a good date closer to the event (or even  
when we're in Atlanta). I know that not everyone of you will be there  
(it's not completely clear for me either - my University is  
struggling with this registration ;-)..., and those who are there are  
usually very busy, but we'll find the time somehow. :-)

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] Countdown for Atlanta

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

Dear maintenance committee members,

as you know, the RoboCup 2007 competitions are advancing fast, and we 
have a lot of work left to do. As I pointed out in my mail to the 
mailing lists earlier, the time frame we have for getting new features 
into the simulator is only two weeks from now. Therefore, I'd like to 
confirm the task assignments and the progress that has been made (and/or 
problems encountered).

Things that need to be addressed:

Timer

=====

Yuan has done great work on that, but we face several difficulties. The separation of the runloop of the SimulationServer into several threads has not resulted in the additional performance and flexibility that we had hoped for. In addition, there is the problem that Yuan hinted at in his email to the list on 05/14, namely, that we should have a high frequency loop for the control and a lower frequency loop for things like vision and other sensor information. 

The question is now, how we should proceed. We could use different timers for the effectors and perceptors (something Yuan proposed in the beginning when he started working on these things), and just do a single loop, or use the threaded version. Since the threaded version is more complicated and doesn't seem to bring too much performance gain, it seems more feasible to use a single runloop in the server. However, I'm not sure about this. Yuan, could you please let us know what you think about these issues?

Rules
=====

We have to revise the soccerruleaspect and the soccerbase code (and potentially other things in the soccer plugin bundle) to be compatible with the new agents. We should have support for counting goals, and different playmodes.

I believe that Siavash and Amin have worked on that, but I'm actually not sure since I didn't get any updates on the status for some time. Could you please let us know how far you got with this, or in case there are problems, what they are?

Collision issues
================

We now have support for ODE collision spaces. Different configurations have to be tested and the problems arising when robots are very close to each other will have to be addressed.

I can work on these things.

Monitor
=======

We need a decent auto-cam mode, improved log playing capabilities, display of game statistics (team names, goals, etc), and some way to discriminate different players (e.g. textures with player numbers)

I think we might be able to re-use some code from the old rcssmonitor3D-lite for the auto-cam mode (maybe also a 2D overlay?). Jan, do you think you can take a look at this?

Concerning the logplayer, Hesham already implemented improvements to the current version, but they need to go into the CVS. 

Jan recently found out how to do textures using kerosin, so we can think about the idea of using textures with player numbers. One problem is, however, how to get appropriate UV coordinates for the textures and the respective meshes. If no UV coordinates are specified, the texture is stretched over the whole surface and is displayed on all surfaces of the mesh. I was thinking that one possible solution might be to model a textured cube in Blender and then export this in the OBJ file format. This is a very simple file format, but it contains all the necessary information we would need. Of course, we would need an OBJ importer for simspark then. Any volunteers? :-)

Another thing is the strange disintegration of the robot if the external monitorspark is used (see screen shots in Yuan's mail from 05/03). So far, I'm not sure what's causing this, but it might be because of the speed the messages arrive and the message length. Is anybody free to take a look at this?

Message format
==============

The current messages are too long. We have to reduce the information transmitted over the network as much as possible in order to enable games with several agents.

I can take care of this.

Sensors
=======

It might be nice to extend the current gyro sensor to also include the 
angle of the corresponding body. The touch sensor in the current release 
gives very simple binary information. Hedayat already proposed to 
include more detailed information like e.g. pressure. Hedayat, could you 
continue to work on these things?

**********

I know that all of this is a lot of stuff and I'm aware that all of you 
must be very busy right now. Nevertheless, I would like to ask to to 
help as much as possible during the next two weeks so that we can 
provide the best version of the server we can for Atlanta.

In order for me to plan things, it is very important that you keep me up 
to date with the status of your work. Please send me (brief) reports, 
both about progress & problems, on a regular basis (daily would be best, 
weekly at the minimum).

I plan to make a release today (rcssserver3d-0.5.4), another one in a 
week from now, and then a release candidate for Atlanta in two weeks. 
After that, we should fix critical bugs and make a final release in 3 
weeks from now.

Thank you all in advance for your help!

Best wishes,
Joschka

P.S.: if you think something vital is missing in the list of necessary 
features, please let me know ASAP. Thanks :-)