simspark-devel — Discussion about Spark development

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

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

Hi Sander,


/*Sander van Dijk <sgv...@gm...>*/ wrote on Sun, 9 Jun 2013 
18:55:44 +0100:
> Hi Hedayat,
>
> My idea was indeed to have the yellow/red selection made in RoboViz, 
> where non-penalized fouls are shown with yellow, penalized with red. 
> If you think it's easier, I can integrate them; would be able to do 
> that tomorrow.
Yes, it'd be great if you integrate them. :)

Regards,
Hedayat


>
> I don't have any further pending changes.
>
> Sander
>
>
> On 8 June 2013 20:37, Hedayat Vatankhah <hed...@gm... 
> <mailto:hed...@gm...>> wrote:
>
>     Hi Sander,
>
>
>
>     /*Sander van Dijk <sgv...@gm...>
>     <mailto:sgv...@gm...>*/ wrote on Wed, 22 May 2013 16:25:20
>     +0100:
>>     Hey all,
>>
>>     With just over a month to go, I guess it's time to put a release
>>     together for the simulator version for Eindhoven. I just
>>     committed something I wanted in there: the ability to send foul
>>     information to the monitor. Attached is a quick (and a bit dirty)
>>     patch to make this information visible in RoboViz; you should get
>>     a list underneath the top bar showing fouls for 10 seconds.
>>
>>     With this, my suggestion is to put Patrick's rule implementations
>>     into the new version, but have no automatic penalization on them.
>>     Instead, the foul is shown in the monitor (with a yellow card
>>     instead of a red card), and the human referee can decide on the
>>     action to take. Even if we ignore them in the end, it should
>>     still give us an idea of how reasonable the calls are in a
>>     tournament.
>     I had a quick look to your changes in rcssserver3d, but I don't
>     know how the color of the card is determined. How should we do it
>     in rcssserver3d? Do you propose to decide about the color inside
>     the monitor (e.g. Roboviz) by sending foul type but not adding an
>     agent's foul counter?
>     I wanted to integrate Patrick's implementation but I'm not sure
>     about the details.
>
>     P.S. I'd like to prepare the release in a few days (hopefully
>     2-3). Please let me know if there are any pending changes.
>
>
>     Regards,
>     Hedayat
>
>
>>
>>     Looking forward to your opinins.
>>
>>     @Hedayat: you have the most experience putting a release
>>     together, would you have time to do this in the near future?
>>
>>     Sander
>>
>>
>>     -- 
>>     Adaptive Systems Research Group
>>     Department of Computer Science
>>     University of Hertfordshire
>>     United Kingdom
>>
>>
>>     _______________________________________________
>>     rc-ss3d-tc mailing list
>>     rc-...@li...  <mailto:rc-...@li...>
>>     http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>
>
>
> -- 
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Sander v. D. <sgv...@gm...>]

Hi Hedayat,

My idea was indeed to have the yellow/red selection made in RoboViz, where
non-penalized fouls are shown with yellow, penalized with red. If you think
it's easier, I can integrate them; would be able to do that tomorrow.

I don't have any further pending changes.

Sander


On 8 June 2013 20:37, Hedayat Vatankhah <hed...@gm...> wrote:

>  Hi Sander,
>
>
>
> *Sander van Dijk <sgv...@gm...> <sgv...@gm...>* wrote on
> Wed, 22 May 2013 16:25:20 +0100:
>
>   Hey all,
>
>  With just over a month to go, I guess it's time to put a release together
> for the simulator version for Eindhoven. I just committed something I
> wanted in there: the ability to send foul information to the monitor.
> Attached is a quick (and a bit dirty) patch to make this information
> visible in RoboViz; you should get a list underneath the top bar showing
> fouls for 10 seconds.
>
>  With this, my suggestion is to put Patrick's rule implementations into
> the new version, but have no automatic penalization on them. Instead, the
> foul is shown in the monitor (with a yellow card instead of a red card),
> and the human referee can decide on the action to take. Even if we ignore
> them in the end, it should still give us an idea of how reasonable the
> calls are in a tournament.
>
> I had a quick look to your changes in rcssserver3d, but I don't know how
> the color of the card is determined. How should we do it in rcssserver3d?
> Do you propose to decide about the color inside the monitor (e.g. Roboviz)
> by sending foul type but not adding an agent's foul counter?
> I wanted to integrate Patrick's implementation but I'm not sure about the
> details.
>
> P.S. I'd like to prepare the release in a few days (hopefully 2-3). Please
> let me know if there are any pending changes.
>
>
> Regards,
> Hedayat
>
>
>
>  Looking forward to your opinins.
>
>  @Hedayat: you have the most experience putting a release together, would
> you have time to do this in the near future?
>
>  Sander
>
>
> --
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> _______________________________________________
> rc-ss3d-tc mailing lis...@li...http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>
>


-- 
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

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

Hi Sander,


/*Sander van Dijk <sgv...@gm...>*/ wrote on Wed, 22 May 2013 
16:25:20 +0100:
> Hey all,
>
> With just over a month to go, I guess it's time to put a release 
> together for the simulator version for Eindhoven. I just committed 
> something I wanted in there: the ability to send foul information to 
> the monitor. Attached is a quick (and a bit dirty) patch to make this 
> information visible in RoboViz; you should get a list underneath the 
> top bar showing fouls for 10 seconds.
>
> With this, my suggestion is to put Patrick's rule implementations into 
> the new version, but have no automatic penalization on them. Instead, 
> the foul is shown in the monitor (with a yellow card instead of a red 
> card), and the human referee can decide on the action to take. Even if 
> we ignore them in the end, it should still give us an idea of how 
> reasonable the calls are in a tournament.
I had a quick look to your changes in rcssserver3d, but I don't know how 
the color of the card is determined. How should we do it in 
rcssserver3d? Do you propose to decide about the color inside the 
monitor (e.g. Roboviz) by sending foul type but not adding an agent's 
foul counter?
I wanted to integrate Patrick's implementation but I'm not sure about 
the details.

P.S. I'd like to prepare the release in a few days (hopefully 2-3). 
Please let me know if there are any pending changes.


Regards,
Hedayat


>
> Looking forward to your opinins.
>
> @Hedayat: you have the most experience putting a release together, 
> would you have time to do this in the near future?
>
> Sander
>
>
> -- 
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> _______________________________________________
> rc-ss3d-tc mailing list
> rc-...@li...
> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Klaus D. <kla...@hs...>]

Hello all,

I have committet two Nao type suggestions to the sourceforge repository.
Type1 (LongLeg) is a slightly changed type compared to what has been 
committed steming from observations at the German Open. The enlengthment 
of the legs is now split into two parts at the hip (as has been) and at 
the ankle. This should make sure that inverse kinematics based walks 
should work more easily with this type. In addition, now also the arms 
are longer, simplifying e.g. getup behaviors.
Type2 (FastFoot) is unchanged a Nao with faster ankle pitch, but slower 
ankle roll.

My suggestions for the value areas (min change, max change) are as follows:
LongLeg (2cm, 6cm) (split in half at the hip, half at the Ankle)
FastFoot (1 deg/s, 3 deg/s), meaning instead of a value of 6.1395 at 
least 7.13 and at most 9.13 for pitch and 5.13 to 3.13 for roll.

Below the naorobottypes.rb
# Type 0 (Standard Nao)
{'ThighRelHip2_Z' => -0.04, 'AnkleRelShank_Z' => -0.055, 
'lj5_max_abs_speed' => 6.1395, 'lj6_max_abs_speed' => 6.1395, 
'ElbowRelUpperArm_Y' => 0.07},

# Type 1
{'ThighRelHip2_Z' => -0.06, 'AnkleRelShank_Z' => -0.075, 
'lj5_max_abs_speed' => 6.1395, 'lj6_max_abs_speed' => 6.1395, 
'ElbowRelUpperArm_Y' => 0.11},

# Type 2
{'ThighRelHip2_Z' => -0.04, 'AnkleRelShank_Z' => -0.055, 
'lj5_max_abs_speed' => 9.21,   'lj6_max_abs_speed' => 4.605, 
'ElbowRelUpperArm_Y' => 0.07}

Other type suggestions are still welcome.

Greetings
Klaus

Am 22.05.2013 20:48, schrieb Hedayat Vatankhah:
> Hi Sander,
> I'll add Patrick's code, and a small code to check the rules for 
> heterogeneous players. However, what are the rules for 2013? Is there 
> a limitation on the number of hetero agents of each type? What about 
> the total number of hetero players for a team?
>
> About the release, sure I'll do it.
>
> Regards,
> Hedayat
>
>
> /*Sander van Dijk <sgv...@gm...>*/ wrote on Wed, 22 May 2013 
> 16:25:20 +0100:
>> Hey all,
>>
>> With just over a month to go, I guess it's time to put a release 
>> together for the simulator version for Eindhoven. I just committed 
>> something I wanted in there: the ability to send foul information to 
>> the monitor. Attached is a quick (and a bit dirty) patch to make this 
>> information visible in RoboViz; you should get a list underneath the 
>> top bar showing fouls for 10 seconds.
>>
>> With this, my suggestion is to put Patrick's rule implementations 
>> into the new version, but have no automatic penalization on them. 
>> Instead, the foul is shown in the monitor (with a yellow card instead 
>> of a red card), and the human referee can decide on the action to 
>> take. Even if we ignore them in the end, it should still give us an 
>> idea of how reasonable the calls are in a tournament.
>>
>> Looking forward to your opinins.
>>
>> @Hedayat: you have the most experience putting a release together, 
>> would you have time to do this in the near future?
>>
>> Sander
>>
>>
>> -- 
>> Adaptive Systems Research Group
>> Department of Computer Science
>> University of Hertfordshire
>> United Kingdom
>>
>>
>> _______________________________________________
>> rc-ss3d-tc mailing list
>> rc-...@li...
>> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>
>
> _______________________________________________
> rc-ss3d-tc mailing list
> rc-...@li...
> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Sajjad H. <sh...@gm...>]

Agreed.

Since I haven't worked on the server so don't know how difficult it would
be but if we get the time on the last day or during the demonstration day
then we can play some friendly matches with the new rules to see the impact
of it on team's performance.

Regards,
Sajjad

On Fri, May 24, 2013 at 3:38 PM, Nuno Lau <nu...@ua...> wrote:

>  Hi,
>
> I also agree on both points.
>
> Cheers,
> Nuno
>
> PS: I did not receive Patrick's last message.
>
>  ------------------------------
> *From:* rc-...@li... [
> rc-...@li...] on behalf of Klaus Dorer [
> kla...@hs...]
> *Sent:* Friday, May 24, 2013 06:44
> *To:* Patrick MacAlpine
> *Cc:* RC 3D OC; Sajjad Haider; 3D TC; Simspark Devel ML; Justin Stoecker;
> Sander van Dijk
>
> *Subject:* Re: [Rc-ss3d-tc] Simulator version Eindhoven
>
>  Agree on both points.
> No new foul rules applied, just visualization.
> Two weeks announcement is also fine with me.
>
> Greetings
> Klaus
>
> Am 23.05.2013 08:44, schrieb Patrick MacAlpine:
>
>  The penalty detection stuff I put together was a quick prototype of the
> system that Klaus had suggested and should probably be looked at a little
> and tuned before using it in a competition.  While I think it's fine to
> show possible fouls, I might be hesitant to have referees acting on them --
> as a likely referee at this year's competition I'd rather not have to be
> making such judgment calls myself:)
>
>  I like the suggestions for new Nao types.  I doubt many teams will use
> them however if only given them a week in advance.  I think it might be
> better to give them out closer to two weeks before the competition in order
> to give teams more time to experiment with them and possibly integrate them
> into their teams.
>
>  Regards,
> Patrick
>
>
> On Thu, May 23, 2013 at 12:52 AM, Klaus Dorer <kla...@hs...
> > wrote:
>
>> Hello Sander,
>>
>> good to see things develop :-)
>>
>> The TC has decided to postpone the rule changes to next year, since they
>> had not been tested early enough.
>> But as you say, we could add the changes to only display how the rules
>> would be applied, at least in the early rounds of the tournament. This will
>> give a good impression as to whether the current implementation is too
>> rigid or too loose or just fitting.
>>
>> Of course this makes me greedy. Since you are in that matter now: would
>> it be easy to make an extension that allows us to distinguish heterogeneous
>> players in roboviz. E.g. by changing the leg or feet colors slightly?
>>
>> Hedayat is right that we have not finally decided on the number of
>> heterogeneous players. I suggest to allow at most 3 players of each new
>> type and at most 11 standard Naos as has been the case. Also I suggest to
>> have no more than 3 new types, so that at least 2 standard Naos have to be
>> used. So far I know of only two suggestions for alternate types, the two we
>> tested at the German Open. One with faster ankle pitch, but slower ankle
>> roll. The other with longer upper leg and, as a result from the test at
>> German Open, also longer upper arms. Any other type suggestions?
>> We should announce the final types roughly one week ahead of the
>> competition say the 17th of June?
>> Since our team is planning to use them I further suggest that this is
>> done by someone else. Hedayat? I think the types should be used as
>> suggested, but the actual values for the deviations should be randomly
>> generated. The values should be generated so that they are at least x%
>> higher than standard but at most y%. I can specify reasonable x and y
>> values for the two types above, but am happy to have your suggestions.
>>
>> Greetings
>> Klaus
>>
>>
>> Am 22.05.2013 20:48, schrieb Hedayat Vatankhah:
>>
>> Hi Sander,
>> I'll add Patrick's code, and a small code to check the rules for
>> heterogeneous players. However, what are the rules for 2013? Is there a
>> limitation on the number of hetero agents of each type? What about the
>> total number of hetero players for a team?
>>
>> About the release, sure I'll do it.
>>
>> Regards,
>> Hedayat
>>
>>
>> *Sander van Dijk <sgv...@gm...> <sgv...@gm...>* wrote on
>> Wed, 22 May 2013 16:25:20 +0100:
>>
>>   Hey all,
>>
>>  With just over a month to go, I guess it's time to put a release
>> together for the simulator version for Eindhoven. I just committed
>> something I wanted in there: the ability to send foul information to the
>> monitor. Attached is a quick (and a bit dirty) patch to make this
>> information visible in RoboViz; you should get a list underneath the top
>> bar showing fouls for 10 seconds.
>>
>>  With this, my suggestion is to put Patrick's rule implementations into
>> the new version, but have no automatic penalization on them. Instead, the
>> foul is shown in the monitor (with a yellow card instead of a red card),
>> and the human referee can decide on the action to take. Even if we ignore
>> them in the end, it should still give us an idea of how reasonable the
>> calls are in a tournament.
>>
>>  Looking forward to your opinins.
>>
>>  @Hedayat: you have the most experience putting a release together, would
>> you have time to do this in the near future?
>>
>>  Sander
>>
>>
>> --
>> Adaptive Systems Research Group
>> Department of Computer Science
>> University of Hertfordshire
>> United Kingdom
>>
>>
>> _______________________________________________
>> rc-ss3d-tc mailing lis...@li...http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>>
>>
>>
>>
>> _______________________________________________
>> rc-ss3d-tc mailing lis...@li...http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>>
>>
>>
>
>

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Nuno L. <nu...@ua...>]

Hi,

I also agree on both points.

Cheers,
Nuno

PS: I did not receive Patrick's last message.

________________________________
From: rc-...@li... [rc-...@li...] on behalf of Klaus Dorer [kla...@hs...]
Sent: Friday, May 24, 2013 06:44
To: Patrick MacAlpine
Cc: RC 3D OC; Sajjad Haider; 3D TC; Simspark Devel ML; Justin Stoecker; Sander van Dijk
Subject: Re: [Rc-ss3d-tc] Simulator version Eindhoven

Agree on both points.
No new foul rules applied, just visualization.
Two weeks announcement is also fine with me.

Greetings
Klaus

Am 23.05.2013 08:44, schrieb Patrick MacAlpine:
The penalty detection stuff I put together was a quick prototype of the system that Klaus had suggested and should probably be looked at a little and tuned before using it in a competition.  While I think it's fine to show possible fouls, I might be hesitant to have referees acting on them -- as a likely referee at this year's competition I'd rather not have to be making such judgment calls myself:)

I like the suggestions for new Nao types.  I doubt many teams will use them however if only given them a week in advance.  I think it might be better to give them out closer to two weeks before the competition in order to give teams more time to experiment with them and possibly integrate them into their teams.

Regards,
Patrick


On Thu, May 23, 2013 at 12:52 AM, Klaus Dorer <kla...@hs...<mailto:kla...@hs...>> wrote:
Hello Sander,

good to see things develop :-)

The TC has decided to postpone the rule changes to next year, since they had not been tested early enough.
But as you say, we could add the changes to only display how the rules would be applied, at least in the early rounds of the tournament. This will give a good impression as to whether the current implementation is too rigid or too loose or just fitting.

Of course this makes me greedy. Since you are in that matter now: would it be easy to make an extension that allows us to distinguish heterogeneous players in roboviz. E.g. by changing the leg or feet colors slightly?

Hedayat is right that we have not finally decided on the number of heterogeneous players. I suggest to allow at most 3 players of each new type and at most 11 standard Naos as has been the case. Also I suggest to have no more than 3 new types, so that at least 2 standard Naos have to be used. So far I know of only two suggestions for alternate types, the two we tested at the German Open. One with faster ankle pitch, but slower ankle roll. The other with longer upper leg and, as a result from the test at German Open, also longer upper arms. Any other type suggestions?
We should announce the final types roughly one week ahead of the competition say the 17th of June?
Since our team is planning to use them I further suggest that this is done by someone else. Hedayat? I think the types should be used as suggested, but the actual values for the deviations should be randomly generated. The values should be generated so that they are at least x% higher than standard but at most y%. I can specify reasonable x and y values for the two types above, but am happy to have your suggestions.

Greetings
Klaus


Am 22.05.2013 20:48, schrieb Hedayat Vatankhah:
Hi Sander,
I'll add Patrick's code, and a small code to check the rules for heterogeneous players. However, what are the rules for 2013? Is there a limitation on the number of hetero agents of each type? What about the total number of hetero players for a team?

About the release, sure I'll do it.

Regards,
Hedayat


Sander van Dijk <sgv...@gm...><mailto:sgv...@gm...> wrote on Wed, 22 May 2013 16:25:20 +0100:
Hey all,

With just over a month to go, I guess it's time to put a release together for the simulator version for Eindhoven. I just committed something I wanted in there: the ability to send foul information to the monitor. Attached is a quick (and a bit dirty) patch to make this information visible in RoboViz; you should get a list underneath the top bar showing fouls for 10 seconds.

With this, my suggestion is to put Patrick's rule implementations into the new version, but have no automatic penalization on them. Instead, the foul is shown in the monitor (with a yellow card instead of a red card), and the human referee can decide on the action to take. Even if we ignore them in the end, it should still give us an idea of how reasonable the calls are in a tournament.

Looking forward to your opinins.

@Hedayat: you have the most experience putting a release together, would you have time to do this in the near future?

Sander


--
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom



_______________________________________________
rc-ss3d-tc mailing list
rc-...@li...<mailto:rc-...@li...>
http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org





_______________________________________________
rc-ss3d-tc mailing list
rc-...@li...<mailto:rc-...@li...>
http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Klaus D. <kla...@hs...>]

Agree on both points.
No new foul rules applied, just visualization.
Two weeks announcement is also fine with me.

Greetings
Klaus

Am 23.05.2013 08:44, schrieb Patrick MacAlpine:
> The penalty detection stuff I put together was a quick prototype of 
> the system that Klaus had suggested and should probably be looked at a 
> little and tuned before using it in a competition.  While I think it's 
> fine to show possible fouls, I might be hesitant to have referees 
> acting on them -- as a likely referee at this year's competition I'd 
> rather not have to be making such judgment calls myself:)
>
> I like the suggestions for new Nao types.  I doubt many teams will use 
> them however if only given them a week in advance.  I think it might 
> be better to give them out closer to two weeks before the competition 
> in order to give teams more time to experiment with them and possibly 
> integrate them into their teams.
>
> Regards,
> Patrick
>
>
> On Thu, May 23, 2013 at 12:52 AM, Klaus Dorer 
> <kla...@hs... <mailto:kla...@hs...>> wrote:
>
>     Hello Sander,
>
>     good to see things develop :-)
>
>     The TC has decided to postpone the rule changes to next year,
>     since they had not been tested early enough.
>     But as you say, we could add the changes to only display how the
>     rules would be applied, at least in the early rounds of the
>     tournament. This will give a good impression as to whether the
>     current implementation is too rigid or too loose or just fitting.
>
>     Of course this makes me greedy. Since you are in that matter now:
>     would it be easy to make an extension that allows us to
>     distinguish heterogeneous players in roboviz. E.g. by changing the
>     leg or feet colors slightly?
>
>     Hedayat is right that we have not finally decided on the number of
>     heterogeneous players. I suggest to allow at most 3 players of
>     each new type and at most 11 standard Naos as has been the case.
>     Also I suggest to have no more than 3 new types, so that at least
>     2 standard Naos have to be used. So far I know of only two
>     suggestions for alternate types, the two we tested at the German
>     Open. One with faster ankle pitch, but slower ankle roll. The
>     other with longer upper leg and, as a result from the test at
>     German Open, also longer upper arms. Any other type suggestions?
>     We should announce the final types roughly one week ahead of the
>     competition say the 17th of June?
>     Since our team is planning to use them I further suggest that this
>     is done by someone else. Hedayat? I think the types should be used
>     as suggested, but the actual values for the deviations should be
>     randomly generated. The values should be generated so that they
>     are at least x% higher than standard but at most y%. I can specify
>     reasonable x and y values for the two types above, but am happy to
>     have your suggestions.
>
>     Greetings
>     Klaus
>
>
>     Am 22.05.2013 20:48, schrieb Hedayat Vatankhah:
>>     Hi Sander,
>>     I'll add Patrick's code, and a small code to check the rules for
>>     heterogeneous players. However, what are the rules for 2013? Is
>>     there a limitation on the number of hetero agents of each type?
>>     What about the total number of hetero players for a team?
>>
>>     About the release, sure I'll do it.
>>
>>     Regards,
>>     Hedayat
>>
>>
>>     /*Sander van Dijk <sgv...@gm...>
>>     <mailto:sgv...@gm...>*/ wrote on Wed, 22 May 2013 16:25:20
>>     +0100:
>>>     Hey all,
>>>
>>>     With just over a month to go, I guess it's time to put a release
>>>     together for the simulator version for Eindhoven. I just
>>>     committed something I wanted in there: the ability to send foul
>>>     information to the monitor. Attached is a quick (and a bit
>>>     dirty) patch to make this information visible in RoboViz; you
>>>     should get a list underneath the top bar showing fouls for 10
>>>     seconds.
>>>
>>>     With this, my suggestion is to put Patrick's rule
>>>     implementations into the new version, but have no automatic
>>>     penalization on them. Instead, the foul is shown in the monitor
>>>     (with a yellow card instead of a red card), and the human
>>>     referee can decide on the action to take. Even if we ignore them
>>>     in the end, it should still give us an idea of how reasonable
>>>     the calls are in a tournament.
>>>
>>>     Looking forward to your opinins.
>>>
>>>     @Hedayat: you have the most experience putting a release
>>>     together, would you have time to do this in the near future?
>>>
>>>     Sander
>>>
>>>
>>>     -- 
>>>     Adaptive Systems Research Group
>>>     Department of Computer Science
>>>     University of Hertfordshire
>>>     United Kingdom
>>>
>>>
>>>     _______________________________________________
>>>     rc-ss3d-tc mailing list
>>>     rc-...@li...  <mailto:rc-...@li...>
>>>     http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>>
>>
>>
>>     _______________________________________________
>>     rc-ss3d-tc mailing list
>>     rc-...@li...  <mailto:rc-...@li...>
>>     http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Patrick M. <pa...@gm...>]

The penalty detection stuff I put together was a quick prototype of the
system that Klaus had suggested and should probably be looked at a little
and tuned before using it in a competition.  While I think it's fine to
show possible fouls, I might be hesitant to have referees acting on them --
as a likely referee at this year's competition I'd rather not have to be
making such judgment calls myself:)

I like the suggestions for new Nao types.  I doubt many teams will use them
however if only given them a week in advance.  I think it might be better
to give them out closer to two weeks before the competition in order to
give teams more time to experiment with them and possibly integrate them
into their teams.

Regards,
Patrick


On Thu, May 23, 2013 at 12:52 AM, Klaus Dorer
<kla...@hs...>wrote:

>  Hello Sander,
>
> good to see things develop :-)
>
> The TC has decided to postpone the rule changes to next year, since they
> had not been tested early enough.
> But as you say, we could add the changes to only display how the rules
> would be applied, at least in the early rounds of the tournament. This will
> give a good impression as to whether the current implementation is too
> rigid or too loose or just fitting.
>
> Of course this makes me greedy. Since you are in that matter now: would it
> be easy to make an extension that allows us to distinguish heterogeneous
> players in roboviz. E.g. by changing the leg or feet colors slightly?
>
> Hedayat is right that we have not finally decided on the number of
> heterogeneous players. I suggest to allow at most 3 players of each new
> type and at most 11 standard Naos as has been the case. Also I suggest to
> have no more than 3 new types, so that at least 2 standard Naos have to be
> used. So far I know of only two suggestions for alternate types, the two we
> tested at the German Open. One with faster ankle pitch, but slower ankle
> roll. The other with longer upper leg and, as a result from the test at
> German Open, also longer upper arms. Any other type suggestions?
> We should announce the final types roughly one week ahead of the
> competition say the 17th of June?
> Since our team is planning to use them I further suggest that this is done
> by someone else. Hedayat? I think the types should be used as suggested,
> but the actual values for the deviations should be randomly generated. The
> values should be generated so that they are at least x% higher than
> standard but at most y%. I can specify reasonable x and y values for the
> two types above, but am happy to have your suggestions.
>
> Greetings
> Klaus
>
>
> Am 22.05.2013 20:48, schrieb Hedayat Vatankhah:
>
> Hi Sander,
> I'll add Patrick's code, and a small code to check the rules for
> heterogeneous players. However, what are the rules for 2013? Is there a
> limitation on the number of hetero agents of each type? What about the
> total number of hetero players for a team?
>
> About the release, sure I'll do it.
>
> Regards,
> Hedayat
>
>
> *Sander van Dijk <sgv...@gm...> <sgv...@gm...>* wrote on
> Wed, 22 May 2013 16:25:20 +0100:
>
>   Hey all,
>
>  With just over a month to go, I guess it's time to put a release together
> for the simulator version for Eindhoven. I just committed something I
> wanted in there: the ability to send foul information to the monitor.
> Attached is a quick (and a bit dirty) patch to make this information
> visible in RoboViz; you should get a list underneath the top bar showing
> fouls for 10 seconds.
>
>  With this, my suggestion is to put Patrick's rule implementations into
> the new version, but have no automatic penalization on them. Instead, the
> foul is shown in the monitor (with a yellow card instead of a red card),
> and the human referee can decide on the action to take. Even if we ignore
> them in the end, it should still give us an idea of how reasonable the
> calls are in a tournament.
>
>  Looking forward to your opinins.
>
>  @Hedayat: you have the most experience putting a release together, would
> you have time to do this in the near future?
>
>  Sander
>
>
> --
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> _______________________________________________
> rc-ss3d-tc mailing lis...@li...http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>
>
>
> _______________________________________________
> rc-ss3d-tc mailing lis...@li...http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>
>

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

[Klaus D. <kla...@hs...>]

Hello Sander,

good to see things develop :-)

The TC has decided to postpone the rule changes to next year, since they 
had not been tested early enough.
But as you say, we could add the changes to only display how the rules 
would be applied, at least in the early rounds of the tournament. This 
will give a good impression as to whether the current implementation is 
too rigid or too loose or just fitting.

Of course this makes me greedy. Since you are in that matter now: would 
it be easy to make an extension that allows us to distinguish 
heterogeneous players in roboviz. E.g. by changing the leg or feet 
colors slightly?

Hedayat is right that we have not finally decided on the number of 
heterogeneous players. I suggest to allow at most 3 players of each new 
type and at most 11 standard Naos as has been the case. Also I suggest 
to have no more than 3 new types, so that at least 2 standard Naos have 
to be used. So far I know of only two suggestions for alternate types, 
the two we tested at the German Open. One with faster ankle pitch, but 
slower ankle roll. The other with longer upper leg and, as a result from 
the test at German Open, also longer upper arms. Any other type suggestions?
We should announce the final types roughly one week ahead of the 
competition say the 17th of June?
Since our team is planning to use them I further suggest that this is 
done by someone else. Hedayat? I think the types should be used as 
suggested, but the actual values for the deviations should be randomly 
generated. The values should be generated so that they are at least x% 
higher than standard but at most y%. I can specify reasonable x and y 
values for the two types above, but am happy to have your suggestions.

Greetings
Klaus


Am 22.05.2013 20:48, schrieb Hedayat Vatankhah:
> Hi Sander,
> I'll add Patrick's code, and a small code to check the rules for 
> heterogeneous players. However, what are the rules for 2013? Is there 
> a limitation on the number of hetero agents of each type? What about 
> the total number of hetero players for a team?
>
> About the release, sure I'll do it.
>
> Regards,
> Hedayat
>
>
> /*Sander van Dijk <sgv...@gm...>*/ wrote on Wed, 22 May 2013 
> 16:25:20 +0100:
>> Hey all,
>>
>> With just over a month to go, I guess it's time to put a release 
>> together for the simulator version for Eindhoven. I just committed 
>> something I wanted in there: the ability to send foul information to 
>> the monitor. Attached is a quick (and a bit dirty) patch to make this 
>> information visible in RoboViz; you should get a list underneath the 
>> top bar showing fouls for 10 seconds.
>>
>> With this, my suggestion is to put Patrick's rule implementations 
>> into the new version, but have no automatic penalization on them. 
>> Instead, the foul is shown in the monitor (with a yellow card instead 
>> of a red card), and the human referee can decide on the action to 
>> take. Even if we ignore them in the end, it should still give us an 
>> idea of how reasonable the calls are in a tournament.
>>
>> Looking forward to your opinins.
>>
>> @Hedayat: you have the most experience putting a release together, 
>> would you have time to do this in the near future?
>>
>> Sander
>>
>>
>> -- 
>> Adaptive Systems Research Group
>> Department of Computer Science
>> University of Hertfordshire
>> United Kingdom
>>
>>
>> _______________________________________________
>> rc-ss3d-tc mailing list
>> rc-...@li...
>> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org
>
>
>
> _______________________________________________
> rc-ss3d-tc mailing list
> rc-...@li...
> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org

Re: [simspark-devel] [Rc-ss3d-tc] Simulator version Eindhoven

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

Hi Sander,
I'll add Patrick's code, and a small code to check the rules for 
heterogeneous players. However, what are the rules for 2013? Is there a 
limitation on the number of hetero agents of each type? What about the 
total number of hetero players for a team?

About the release, sure I'll do it.

Regards,
Hedayat


/*Sander van Dijk <sgv...@gm...>*/ wrote on Wed, 22 May 2013 
16:25:20 +0100:
> Hey all,
>
> With just over a month to go, I guess it's time to put a release 
> together for the simulator version for Eindhoven. I just committed 
> something I wanted in there: the ability to send foul information to 
> the monitor. Attached is a quick (and a bit dirty) patch to make this 
> information visible in RoboViz; you should get a list underneath the 
> top bar showing fouls for 10 seconds.
>
> With this, my suggestion is to put Patrick's rule implementations into 
> the new version, but have no automatic penalization on them. Instead, 
> the foul is shown in the monitor (with a yellow card instead of a red 
> card), and the human referee can decide on the action to take. Even if 
> we ignore them in the end, it should still give us an idea of how 
> reasonable the calls are in a tournament.
>
> Looking forward to your opinins.
>
> @Hedayat: you have the most experience putting a release together, 
> would you have time to do this in the near future?
>
> Sander
>
>
> -- 
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> _______________________________________________
> rc-ss3d-tc mailing list
> rc-...@li...
> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org

Re: [simspark-devel] Simspark Proxy Implementation

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

Hi!
Oops, I'll look into this. We can send the scores at the beginning and 
also when they change.
No, agents must not connect to the monitor, and I always setup firewall 
to block such access in competitions.

Thanks,
Hedayat


/*Patrick MacAlpine <pa...@gm...>*/ wrote on Tue, 19 Mar 2013 
16:17:44 -0500:
> Hi Hedayat,
>
> I don't believe the server ever reports the score to agents.  The 
> place where it would most make sense to do this would be in the 
> GameState perceptor but this is not currently done 
> (http://simspark.sourceforge.net/wiki/index.php/Perceptors#GameState_Perceptor). 
>  The score is sent to the monitor 
> (http://simspark.sourceforge.net/wiki/index.php/Network_Protocol#GameState_Message), 
> but I don't think agents should be allowed to connect to the monitor 
> port during competitions -- if they were it would allow them to unduly 
> influence the game through the training command parser such as putting 
> a velocity on the ball causing it to fly into the opponent's goal:)
>
> Regards,
> Patrick
>
>
>
> On Tue, Mar 19, 2013 at 3:33 AM, Hedayat Vatankhah <hed...@gm... 
> <mailto:hed...@gm...>> wrote:
>
>     Hi Patrick,
>     If you are talking about the score of the current game, it should
>     be already reported correctly to the agents. Even when the server
>     is stopped and started again, the league manager is supposed to
>     set the correct scores for the second half (and it usually works).
>     (Recently I held a competition and found out that the league
>     manager doesn't do it correctly with ruby 1.9, and I fixed that).
>     I just don't remember when the server reports the scores to the
>     agents?!
>
>     About your patch, that's certainly great and I'll commit it to SVN.
>
>     Regards,
>     Hedayat
>
>
>
>     On ۱۳/۰۳/۱۹ 12:16, Patrick MacAlpine wrote:
>>     Hi all,
>>
>>     Just to add my own thoughts to this conversation...for score reporting
>>     I would really like to see the server report the score of the current
>>     game being played to all agents in the same way that other important
>>     aspects of the game such as time and play mode are sent (I believe
>>     this information is already sent to the monitor).  This was my
>>     original idea when suggesting this feature as it is otherwise
>>     impossible to know the current score of a game when the server is
>>     stopped and restarted after halftime.  While it might be nice to have
>>     the complete results of the tournament so far existing in an external
>>     RSG file that the agent can parse, I doubt many teams will use this
>>     information as it will only exist during the tournament and won't be
>>     something they will have in front of them when designing and testing
>>     their agents.  It seems to only make sense to me that if in a real
>>     soccer game a player can just look up at a score board to see the
>>     current score and time remaining, that an agent should be able to get
>>     this information in real time as well.
>>
>>     As an aside I find it really useful to have ground truth information
>>     about the agent's current orientation in the x-y place for both
>>     debugging purposes as well as for helping to guide the agent during
>>     optimization tasks.  This is something I've implemented locally in my
>>     own build of the server, but think it might be useful to the community
>>     to have added to the next release of the server.  I've attached my
>>     changed files for this feature should someone want to add it to the
>>     repository.  Basically one sets the setSenseMyOrien value to true in
>>     naoneckhead.rsg, and then the agent's camera's absolute orientation in
>>     the x-y plane is reported in degrees through a "myorien" message from
>>     the server.
>>
>>     - Patrick
>>
>>
>>
>>
>>     On Tue, Feb 26, 2013 at 3:18 PM, Hedayat Vatankhah<hed...@gm...>  <mailto:hed...@gm...>  wrote:
>>>     Hi,
>>>
>>>
>>>     Sander van Dijk<sgv...@gm...>  <mailto:sgv...@gm...>  wrote on Sun, 24 Feb 2013 16:56:35
>>>     +0000:
>>>
>>>
>>>
>>>
>>>     On Sun, Feb 24, 2013 at 3:26 PM, Stefan Glaser<gla...@gm...>  <mailto:gla...@gm...>
>>>     wrote:
>>>>     Hey all,
>>>>
>>>>     first of all, great to see some discussion going on again! Thank you for
>>>>     your great input!
>>>>
>>>>     About security:
>>>>     [...]
>>>>
>>>     Though I agree it is important to think about security, what is the benefit
>>>     for a team in bypassing the proxy? It's purpose is to not disadvantage a
>>>     team in case of severe network delays and keep timing constant, if a team
>>>     circumvents it it only exposes itself to random timing. In any case if it is
>>>     an issue we can make the server (or the firewall) enforce a maximum amount
>>>     of connections, and have the proxy open that amount when it starts.
>>>
>>>     Since the server will be running in sync mode, the timing would be
>>>     completely controlled by the agent.
>>>
>>>
>>>     �
>>>>     About providing results to the agents:
>>>>     What about holding the result file in the standard robocup user home
>>>>     (where it is probably written) and put a sym link to it in each home
>>>>     directory? So each agent should always find the actual result file in their
>>>>     home directory. Or are there restrictions/drawbacks in accessing such a file
>>>>     in the robocup user home?
>>>     That is an option. Maybe giving direct read access to the file would be
>>>     easier, as teams sometimes delete the symlinks from their directory on
>>>     accident.
>>>
>>>     Even if we use symlinks, we should give direct read access to the file. So,
>>>     teams can access both the symlink and the file. Therefore, we can creates
>>>     symlinks as a convenience and teams should either access the original file
>>>     or be careful to not delete the symlink.
>>>
>>>
>>>     Regards,
>>>     Hedayat
>>>
>>>
>>>
>>>     ------------------------------------------------------------------------------
>>>     Everyone hates slow websites. So do we.
>>>     Make your web apps faster with AppDynamics
>>>     Download AppDynamics Lite for free today:
>>>     http://p.sf.net/sfu/appdyn_d2d_feb
>>>     _______________________________________________
>>>     Simspark Generic Physical MAS Simulator
>>>     simspark-devel mailing list
>>>     sim...@li...  <mailto:sim...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/simspark-devel
>>     >
>
>

Re: [simspark-devel] Simspark Proxy Implementation

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

Hi Patrick,
If you are talking about the score of the current game, it should be 
already reported correctly to the agents. Even when the server is 
stopped and started again, the league manager is supposed to set the 
correct scores for the second half (and it usually works). (Recently I 
held a competition and found out that the league manager doesn't do it 
correctly with ruby 1.9, and I fixed that). I just don't remember when 
the server reports the scores to the agents?!

About your patch, that's certainly great and I'll commit it to SVN.

Regards,
Hedayat


On ۱۳/۰۳/۱۹ 12:16, Patrick MacAlpine wrote:
> Hi all,
>
> Just to add my own thoughts to this conversation...for score reporting
> I would really like to see the server report the score of the current
> game being played to all agents in the same way that other important
> aspects of the game such as time and play mode are sent (I believe
> this information is already sent to the monitor).  This was my
> original idea when suggesting this feature as it is otherwise
> impossible to know the current score of a game when the server is
> stopped and restarted after halftime.  While it might be nice to have
> the complete results of the tournament so far existing in an external
> RSG file that the agent can parse, I doubt many teams will use this
> information as it will only exist during the tournament and won't be
> something they will have in front of them when designing and testing
> their agents.  It seems to only make sense to me that if in a real
> soccer game a player can just look up at a score board to see the
> current score and time remaining, that an agent should be able to get
> this information in real time as well.
>
> As an aside I find it really useful to have ground truth information
> about the agent's current orientation in the x-y place for both
> debugging purposes as well as for helping to guide the agent during
> optimization tasks.  This is something I've implemented locally in my
> own build of the server, but think it might be useful to the community
> to have added to the next release of the server.  I've attached my
> changed files for this feature should someone want to add it to the
> repository.  Basically one sets the setSenseMyOrien value to true in
> naoneckhead.rsg, and then the agent's camera's absolute orientation in
> the x-y plane is reported in degrees through a "myorien" message from
> the server.
>
> - Patrick
>
>
>
>
> On Tue, Feb 26, 2013 at 3:18 PM, Hedayat Vatankhah <hed...@gm...> wrote:
>> Hi,
>>
>>
>> Sander van Dijk <sgv...@gm...> wrote on Sun, 24 Feb 2013 16:56:35
>> +0000:
>>
>>
>>
>>
>> On Sun, Feb 24, 2013 at 3:26 PM, Stefan Glaser <gla...@gm...>
>> wrote:
>>> Hey all,
>>>
>>> first of all, great to see some discussion going on again! Thank you for
>>> your great input!
>>>
>>> About security:
>>> [...]
>>>
>> Though I agree it is important to think about security, what is the benefit
>> for a team in bypassing the proxy? It's purpose is to not disadvantage a
>> team in case of severe network delays and keep timing constant, if a team
>> circumvents it it only exposes itself to random timing. In any case if it is
>> an issue we can make the server (or the firewall) enforce a maximum amount
>> of connections, and have the proxy open that amount when it starts.
>>
>> Since the server will be running in sync mode, the timing would be
>> completely controlled by the agent.
>>
>>
>> �
>>> About providing results to the agents:
>>> What about holding the result file in the standard robocup user home
>>> (where it is probably written) and put a sym link to it in each home
>>> directory? So each agent should always find the actual result file in their
>>> home directory. Or are there restrictions/drawbacks in accessing such a file
>>> in the robocup user home?
>>
>> That is an option. Maybe giving direct read access to the file would be
>> easier, as teams sometimes delete the symlinks from their directory on
>> accident.
>>
>> Even if we use symlinks, we should give direct read access to the file. So,
>> teams can access both the symlink and the file. Therefore, we can creates
>> symlinks as a convenience and teams should either access the original file
>> or be careful to not delete the symlink.
>>
>>
>> Regards,
>> Hedayat
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Simspark Generic Physical MAS Simulator
>> simspark-devel mailing list
>> sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
> >

Re: [simspark-devel] Simspark Proxy Implementation

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

Hi,


/*Sander van Dijk <sgv...@gm...>*/ wrote on Sun, 24 Feb 2013 
16:56:35 +0000:
>
>
>
> On Sun, Feb 24, 2013 at 3:26 PM, Stefan Glaser <gla...@gm... 
> <mailto:gla...@gm...>> wrote:
>
>     Hey all,
>
>     first of all, great to see some discussion going on again! Thank
>     you for your great input!
>
>     About security:
>     [...]
>
> Though I agree it is important to think about security, what is the 
> benefit for a team in bypassing the proxy? It's purpose is to not 
> disadvantage a team in case of severe network delays and keep timing 
> constant, if a team circumvents it it only exposes itself to random 
> timing. In any case if it is an issue we can make the server (or the 
> firewall) enforce a maximum amount of connections, and have the proxy 
> open that amount when it starts.
Since the server will be running in sync mode, the timing would be 
completely controlled by the agent.


> �
>
>     About providing results to the agents:
>     What about holding the result file in the standard robocup user
>     home (where it is probably written) and put a sym link to it in
>     each home directory? So each agent should always find the actual
>     result file in their home directory. Or are there
>     restrictions/drawbacks in accessing such a file in the robocup
>     user home?
>
>
> That is an option. Maybe giving direct read access to the file would 
> be easier, as teams sometimes delete the symlinks from their directory 
> on accident.
Even if we use symlinks, we should give direct read access to the file. 
So, teams can access both the symlink and the file. Therefore, we can 
creates symlinks as a convenience and teams should either access the 
original file or be careful to not delete the symlink.


Regards,
Hedayat

Re: [simspark-devel] Simspark Proxy Implementation

[Sander v. D. <sgv...@gm...>]

On Sun, Feb 24, 2013 at 3:26 PM, Stefan Glaser <gla...@gm...>wrote:

> Hey all,
>
> first of all, great to see some discussion going on again! Thank you for
> your great input!
>
> About security:
> [...]
>
> Though I agree it is important to think about security, what is the
benefit for a team in bypassing the proxy? It's purpose is to not
disadvantage a team in case of severe network delays and keep timing
constant, if a team circumvents it it only exposes itself to random timing.
In any case if it is an issue we can make the server (or the firewall)
enforce a maximum amount of connections, and have the proxy open that
amount when it starts.


> About providing results to the agents:
> What about holding the result file in the standard robocup user home
> (where it is probably written) and put a sym link to it in each home
> directory? So each agent should always find the actual result file in their
> home directory. Or are there restrictions/drawbacks in accessing such a
> file in the robocup user home?
>

That is an option. Maybe giving direct read access to the file would be
easier, as teams sometimes delete the symlinks from their directory on
accident.


> The only valid argument in my opinion for the RSG-format is that teams
> already have a parser. When using xml for example, it could be better
> visualized (e.g. via xsl as html-page), one could have validation of the
> document via DTD or Schema and there exist a lot of visual editors,
> enforcing and suggesting tags according to the DTD/Schema. On the other
> hand it may be a bit harder to edit directly from command line. But as
> Hedayat mentioned, we can provide different result formats later, also with
> respect to the Score Board Sander mentioned. Don't get me wrong, I don't
> want to exclude the RSG-format. I just wanted to mention, that it is not
> neccessarily the best choice for consistency and administration.
>

If something generates it as XML, we can also use XSLT to generate RSG from
it. What I wanted to say is, we just have to guarantee RSG will be there,
regardless of how it is generated. With that said, I do agree with the
benefits of XML. I'd also put JSON or YAML in the considerations, but any
can be generated from the other.


> Sander, do you have any documentation with respect to the RCSimControl?
>

Unfortunately not more than the in-code documentation at the moment. I am
working on it a bit more atm, I'll in any case make it so that Doxygen
generates something useful.


> Regards,
> Stefan
>
>
>
> Am 23.02.2013 18:58, schrieb Sander van Dijk:
>
>> Hey all,
>>
>> Few things from me to add to the discussion:
>>
>> - Regardless from implementation and discussion about which program should
>> be responsible, let's tackle first how teams access it. I for now am in
>> favour of files written somewhere that are accessible to all teams, e.g. a
>> special user's ('results') home dir that is readable for everybody. I
>> agree
>> with Hedayat that they should be in any case RSG. This would be the
>> easiest
>> for teams to implement, and we could even make them by hand in case we
>> don't manage to create the automated tools in time, which as OC makes me
>> most comfortable :).
>>
>> - Just FYI before too much redundant work is done, the organization for
>> Eindhoven is looking into using some competition wide centralized 'Score
>> Board' application that has been developed. I am awaiting more details on
>> what it actually is, but it looks like something that makes the gathering
>> and publication of results automatic, and perhaps we can plug into it.
>>
>> - Finally, I'd just like to point RCSimControl (
>> http://launchpad.net/**rcsimcontrol <http://launchpad.net/rcsimcontrol>),
>> which I developed during the RoboCup
>> funded project in which I also created the TBB multithreading for the
>> server. I always planned to use it to create a more advanced league
>> manager
>> as well (it controls multiple parallel instances; I use it to run a small
>> scale tournament for qualification on our super cluster). But development
>> of any other tools by somebody who actually has the time to invest in it
>> is
>> of course always welcome ;).
>>
>> Cheers,
>> Sander
>>
>>
>> On Mon, Feb 18, 2013 at 7:39 PM, Hedayat Vatankhah <hed...@gm...
>> >wrote:
>>
>>    Hi Stefan & Klaus,
>>> (and others! I thought that it is better to add this discussion to
>>> simspark-devel, hope that you don't mind!)
>>> About monitor, yes actually in all games that I'm in OC I do setup
>>> firewall rules to close all connections except the expected ones as
>>> Stefan
>>> said. But no, I didn't anything for communication between agents through
>>> sockets (however, I have tried some other restrictions like making the
>>> log
>>> files and directories write-only).
>>> I was not trying to imply that our security is perfect now, but security
>>> should be considered anyway. Also, the problem with the proxy could be
>>> probably much more 'useful' than communication between agents. I also
>>> didn't want to imply that we should not use proxy until it is completely
>>> secure. Even having a plan for security is great.
>>>
>>> Anyway, the security aspect is not necessarily complex. Stefan provided
>>> an
>>> idea, and actually it derived me to think of an even simpler idea... or
>>> actually that it is probably already secure enough! :P :D How? Well, we
>>> will run the proxy before the agents anyway, right? So, the proxy can
>>> make
>>> the expected number of connections to the simulator before running the
>>> agents. Now, we know that no more connections should be made to the
>>> simulator, so agents cannot connect to the simulator anyway. We can have
>>> a
>>> simple method to monitor the number of agents connected to proxies too
>>> (for
>>> example, league manager might query the number of agents and print them
>>> on
>>> screen or something). This probably have a little implementation work for
>>> the proxy too. However, Stefan ideas are great too, specially about the
>>> competition manager.
>>>
>>> About providing the results, RSG format is selected (I guess!) because
>>> agents already have an RSG parser, so they can easily parse them. Using
>>> another format for the agents mean that they should implement yet another
>>> parser. Therefore, I'm actually in favor of using RSG format for that.
>>> However, the results might be generated also in another format for other
>>> purposes.
>>>
>>> But, no, simspark should not be responsible for providing the results,
>>> and
>>> even if it is, it should get the results from another place. Actually,
>>> I've
>>> said previously (probably in TC ML or simspark-devel) that ideally we
>>> would
>>> need a kind of 'results server'. Since we run games in parallel, teams
>>> should be actually informed about all results not just the ones played in
>>> that cluster. There are even considerations such as the order and time of
>>> playing games in different clusters (there should be probably a
>>> 'schedule',
>>> and teams are informed about the results of the games which are past in
>>> schedule even if we were actually able to play some more games in the
>>> other
>>> cluster; or we should really run the games according to the schedule).
>>> Teams might query the results from the result server themselves, or
>>> rcssserver3d (which is certainly about competitions) can query them and
>>> provide it to agents. The results server can generate results in other
>>> formats usable for publishing, like using XML and XSL as Stefan
>>> mentioned.
>>>
>>> Finally, it might be more interesting if the competition manager can
>>> manage all games rather than the games running on a single cluster (in
>>> that
>>> case, it can actually play the role of the results server too). Consider
>>> each cluster as a soccer field, competition manager can schedule the
>>> games
>>> and then start the games on the selected fields. Or we might not consider
>>> clusters as fields and consider them completely equal, and dispatch each
>>> game when any cluster is available. Another policy could be to run all
>>> games of a single group on the same cluster to make sure that conditions
>>> are equal for each group. Anyway, when it dispatches a game, it might
>>> also
>>> provide the results for that game too. Well, this idea should not
>>> necessarily be implemented in the initial versions, but might be a goal
>>> which should be considered in design.
>>>
>>> Regards,
>>> Hedayat
>>>
>>>
>>> *Stefan Glaser <gla...@gm...> <gla...@gm...>* wrote on
>>>
>>> Mon, 18 Feb 2013 13:28:57 +0100:
>>>
>>> Hello together,
>>>
>>> sorry that I jump into the discussion, but I also spend some time in
>>> thinking of these problems.
>>>
>>> In general, the monitor issue you mentioned is not really a problem.
>>> Since
>>> the agent teams and the monitor usually run on different machines and the
>>> monitor port is fixed, a simple firewall rule should be sufficient to
>>> prevent this situation. The intermediate communication between agents
>>> though is tough.
>>>
>>> Now the proxy. The main target for me with the first version was simply
>>> to
>>> have a proxy. Since the proxy is only needed for competitions, I felt it
>>> should be transparent to both sides. Given this and that the current
>>> implementation uses random port assignments, there is no possibility for
>>> the server to distinguish connections from a proxy and connections coming
>>> directly from an agent. On the other hand, the current proxy
>>> implementation
>>> simply accepty new connections in an endless loop and has no information
>>> about the competition at all.
>>> In order to not touch the server code, I came up with the following idea.
>>> Extend the proxy to run (and maybe monitoring) the agent processes. If an
>>> agent is started by the proxy, the proxy can expect to get a connection
>>> request for each agent it started and can already reserve a connection to
>>> the server for it. If it doesn't get a connection request together with
>>> an
>>> init-message within let's say 10 seconds, the proxy simply kills the
>>> previously started agent again and prompts a warning. This way the game
>>> wouldn't start up and someone would notice that something is wrong.
>>> We could use the same starting scripts for the agents (just not starting
>>> a
>>> whole team, instead only one agent), but we would need to run a proxy
>>> instance for each match, with some more parameters. Should be not too
>>> much
>>> of a change in the depending scripts.
>>>
>>>
>>> In case I find time to develop the competition manager GUI I have in mind
>>> (an advanced version of the league manager), my target is to use an own
>>> interface to the proxy server to run/stop/monitor agent processes and
>>> their
>>> network statistics. This way a proxy can stay running the whole day and
>>> is
>>> instructed directly from the competition manager GUI.
>>> When talking about the competition manager GUI, I also thought about
>>> providing the current results of the competition to the agents. I wonder
>>> why the SimSpark server should take care of this and why the RSG format
>>> should be used in this case. When thinking of the SimSpark server as a
>>> tool
>>> for research, providing competition abilities is just not needed and
>>> irrelevant i.e. for learning. In my opinion, if we play a competition,
>>> the
>>> server is only responsible for simulating the games, not for organizing
>>> them. If we intend to have a central file, containing the whole
>>> competition
>>> results, why not using an xml-file, which can be easily published and
>>> displayed as html-page to humans, using xsl? And if this file already
>>> exists, why not publishing it over the internet?
>>> All this could be addressed by a separate application, providing a nice
>>> GUI to manage and monitor competitions. This GUI can also be used to
>>> display the results for visitors at Robocup events. By integrating i.e.
>>> RoboViz, we could even watch the games directly in the competition
>>> manager
>>> and play logfiles of the best scenes to amuse visitors. And, think about
>>> a
>>> team which want to test their new agent binary at a competition. They
>>> open
>>> the competition manager in training mode and can either start a game
>>> against another own binary, or ask other teams to enter their user
>>> password
>>> in order to allow the use of their binary for one test match. Test
>>> matches
>>> are then automatically played under competition conditions. This would
>>> speed up test-time of teams when setting up things on the competition
>>> machines for test games.
>>>
>>> I'm really looking forward to develop such a competition manager. I think
>>> this would be a great contribution to the Robocup events, which I can
>>> easily provide, since I'm familiar with most technical stuff involved.
>>> With
>>> this I could take care of providing the actual results of the competition
>>> to the agents.
>>> I'm not sure yet how I'll find time. But I'm kind of eager to start ;)
>>>
>>> What do you think?
>>>
>>> Sorry, got quite a long mail meanwhile. I intend to put a description of
>>> my thoughts into the wiki, too.
>>>
>>> Wish you all the best,
>>> Stefan
>>>
>>>
>>>
>>>
>>>
>>> Am 18.02.2013 08:53, schrieb Klaus Dorer:
>>>
>>> Hi Hedayat,
>>>
>>> hmmm, security aspects are important. But are we checking that no agent
>>> is
>>> connecting as monitor? Or are we checking that no agent opens a socket to
>>> another agent? I think no. Therefore I wonder if we have to be more
>>> strict
>>> here. If yes, is this something we have to do on application level, or
>>> can
>>> we do it on a different level, e.g. opening that port only for a specific
>>> application?
>>>
>>> Greetings
>>> Klaus
>>>
>>> Am 16.02.2013 19:20, schrieb Hedayat Vatankhah:
>>>
>>> Hi Stefan,
>>> Sorry for my lack of response. I'm still planning to put some time to
>>> answer your first email (but in brief, the security aspects look more
>>> complicated than the proxy itself. For example, agents must be unable to
>>> impersonate themselves as the proxy(ies)).
>>> And thank you a lot for reporting on the progress. I'll certainly look
>>> into the wiki page and will provide my comments (if any!). :)
>>>
>>> Thanks a lot.
>>> Hedayat
>>>
>>>
>>> /*Stefan Glaser <gla...@gm...> <gla...@gm...>*/ wrote
>>>
>>> on Sat, 16 Feb 2013 19:13:50 +0100:
>>>
>>> Hello Hedayat,
>>>
>>> I was eager to implement something, so I spend some time implementing the
>>> proxy server for SimSpark.
>>> It was quite simple and straight forward to implement and first tests
>>> look
>>> good. We intend to test the proxy over the internet, just to get a
>>> subjective impression ;) In addition we also want to test it on a local
>>> network, monitoring the traffic to the server with wireshark, to get some
>>> numbers. Once that is done, I would try to release it somehow.
>>>
>>> If you are interested in the concept and want to get some information
>>> until we release the source code, I already put a description into the
>>> wiki:
>>> http://simspark.sourceforge.**net/wiki/index.php/Agent_Proxy<http://simspark.sourceforge.net/wiki/index.php/Agent_Proxy>
>>>
>>> Wish you all the best,
>>> Stefan
>>>
>>>
>>> Am 13.02.2013 14:10, schrieb Stefan Glaser:
>>>
>>> Hello Hedayat,
>>>
>>> as Klaus mentioned, we would take care of implementing the proxy approach
>>> for the next competitions.
>>>
>>> We would realize it in Java - I hope that doesn't result in any
>>> problem...
>>>
>>> Now, appart from informing you about that we would take care of the
>>> implementation, I wanted to ask you about some thoughts with respect to
>>> the
>>> proxy. The basic idea is clear, having an intermediate component,
>>> measuring
>>> the time on the client machines. But I wonder, is there anything else
>>> critical, which one has to be aware of in the implementation? E.g. some
>>> situation which a team can explore in order to gain benefits over other
>>> teams?
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> The Go Parallel Website, sponsored by Intel - in partnership with
>>> Geeknet,
>>> is your hub for all things parallel software development, from weekly
>>> thought
>>> leadership blogs to news, videos, case studies, tutorials, tech docs,
>>> whitepapers, evaluation guides, and opinion stories. Check out the most
>>> recent posts - join the conversation now.
>>> http://goparallel.sourceforge.**net/<http://goparallel.sourceforge.net/>
>>> ______________________________**_________________
>>> Simspark Generic Physical MAS Simulator
>>> simspark-devel mailing list
>>> simspark-devel@lists.**sourceforge.net<sim...@li...>
>>> https://lists.sourceforge.net/**lists/listinfo/simspark-devel<https://lists.sourceforge.net/lists/listinfo/simspark-devel>
>>>
>>>
>>>
>>
>


-- 
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom

Re: [simspark-devel] Simspark Proxy Implementation

[Stefan G. <gla...@gm...>]

Hey all,

first of all, great to see some discussion going on again! Thank you for 
your great input!

About security:
When I implemented the proxy, I had the feeling that agents which 
haven't send an init-message yet, are not considered in the simulation 
and also in the sync mode. Thus one agent could connect to the proxy and 
send nothing at all and in addition directly connect to the server as 
normal agent. Since I don't think that the server limits the amount of 
connections in general, this may be a potential bypass.
That's why I came up with the suggested idea.
I also think having a monitoring interface for the proxy is a good idea. 
I'll definitely consider this feature for version 0.2 or what ever 
number the second release will have ;)

About providing results to the agents:
What about holding the result file in the standard robocup user home 
(where it is probably written) and put a sym link to it in each home 
directory? So each agent should always find the actual result file in 
their home directory. Or are there restrictions/drawbacks in accessing 
such a file in the robocup user home?
The only valid argument in my opinion for the RSG-format is that teams 
already have a parser. When using xml for example, it could be better 
visualized (e.g. via xsl as html-page), one could have validation of the 
document via DTD or Schema and there exist a lot of visual editors, 
enforcing and suggesting tags according to the DTD/Schema. On the other 
hand it may be a bit harder to edit directly from command line. But as 
Hedayat mentioned, we can provide different result formats later, also 
with respect to the Score Board Sander mentioned. Don't get me wrong, I 
don't want to exclude the RSG-format. I just wanted to mention, that it 
is not neccessarily the best choice for consistency and administration.

Sander, do you have any documentation with respect to the RCSimControl?

As I sad, I'll try to put my thoughts about a competition manager into 
the wiki-development page and if it is considered worth a try, I may 
start to implement it. It certainly is about managing the whole 
competition, probably even more than what you expect. But we'll see...

Regards,
Stefan



Am 23.02.2013 18:58, schrieb Sander van Dijk:
> Hey all,
>
> Few things from me to add to the discussion:
>
> - Regardless from implementation and discussion about which program should
> be responsible, let's tackle first how teams access it. I for now am in
> favour of files written somewhere that are accessible to all teams, e.g. a
> special user's ('results') home dir that is readable for everybody. I agree
> with Hedayat that they should be in any case RSG. This would be the easiest
> for teams to implement, and we could even make them by hand in case we
> don't manage to create the automated tools in time, which as OC makes me
> most comfortable :).
>
> - Just FYI before too much redundant work is done, the organization for
> Eindhoven is looking into using some competition wide centralized 'Score
> Board' application that has been developed. I am awaiting more details on
> what it actually is, but it looks like something that makes the gathering
> and publication of results automatic, and perhaps we can plug into it.
>
> - Finally, I'd just like to point RCSimControl (
> http://launchpad.net/rcsimcontrol), which I developed during the RoboCup
> funded project in which I also created the TBB multithreading for the
> server. I always planned to use it to create a more advanced league manager
> as well (it controls multiple parallel instances; I use it to run a small
> scale tournament for qualification on our super cluster). But development
> of any other tools by somebody who actually has the time to invest in it is
> of course always welcome ;).
>
> Cheers,
> Sander
>
>
> On Mon, Feb 18, 2013 at 7:39 PM, Hedayat Vatankhah <hed...@gm...>wrote:
>
>>   Hi Stefan & Klaus,
>> (and others! I thought that it is better to add this discussion to
>> simspark-devel, hope that you don't mind!)
>> About monitor, yes actually in all games that I'm in OC I do setup
>> firewall rules to close all connections except the expected ones as Stefan
>> said. But no, I didn't anything for communication between agents through
>> sockets (however, I have tried some other restrictions like making the log
>> files and directories write-only).
>> I was not trying to imply that our security is perfect now, but security
>> should be considered anyway. Also, the problem with the proxy could be
>> probably much more 'useful' than communication between agents. I also
>> didn't want to imply that we should not use proxy until it is completely
>> secure. Even having a plan for security is great.
>>
>> Anyway, the security aspect is not necessarily complex. Stefan provided an
>> idea, and actually it derived me to think of an even simpler idea... or
>> actually that it is probably already secure enough! :P :D How? Well, we
>> will run the proxy before the agents anyway, right? So, the proxy can make
>> the expected number of connections to the simulator before running the
>> agents. Now, we know that no more connections should be made to the
>> simulator, so agents cannot connect to the simulator anyway. We can have a
>> simple method to monitor the number of agents connected to proxies too (for
>> example, league manager might query the number of agents and print them on
>> screen or something). This probably have a little implementation work for
>> the proxy too. However, Stefan ideas are great too, specially about the
>> competition manager.
>>
>> About providing the results, RSG format is selected (I guess!) because
>> agents already have an RSG parser, so they can easily parse them. Using
>> another format for the agents mean that they should implement yet another
>> parser. Therefore, I'm actually in favor of using RSG format for that.
>> However, the results might be generated also in another format for other
>> purposes.
>>
>> But, no, simspark should not be responsible for providing the results, and
>> even if it is, it should get the results from another place. Actually, I've
>> said previously (probably in TC ML or simspark-devel) that ideally we would
>> need a kind of 'results server'. Since we run games in parallel, teams
>> should be actually informed about all results not just the ones played in
>> that cluster. There are even considerations such as the order and time of
>> playing games in different clusters (there should be probably a 'schedule',
>> and teams are informed about the results of the games which are past in
>> schedule even if we were actually able to play some more games in the other
>> cluster; or we should really run the games according to the schedule).
>> Teams might query the results from the result server themselves, or
>> rcssserver3d (which is certainly about competitions) can query them and
>> provide it to agents. The results server can generate results in other
>> formats usable for publishing, like using XML and XSL as Stefan mentioned.
>>
>> Finally, it might be more interesting if the competition manager can
>> manage all games rather than the games running on a single cluster (in that
>> case, it can actually play the role of the results server too). Consider
>> each cluster as a soccer field, competition manager can schedule the games
>> and then start the games on the selected fields. Or we might not consider
>> clusters as fields and consider them completely equal, and dispatch each
>> game when any cluster is available. Another policy could be to run all
>> games of a single group on the same cluster to make sure that conditions
>> are equal for each group. Anyway, when it dispatches a game, it might also
>> provide the results for that game too. Well, this idea should not
>> necessarily be implemented in the initial versions, but might be a goal
>> which should be considered in design.
>>
>> Regards,
>> Hedayat
>>
>>
>> *Stefan Glaser <gla...@gm...> <gla...@gm...>* wrote on
>> Mon, 18 Feb 2013 13:28:57 +0100:
>>
>> Hello together,
>>
>> sorry that I jump into the discussion, but I also spend some time in
>> thinking of these problems.
>>
>> In general, the monitor issue you mentioned is not really a problem. Since
>> the agent teams and the monitor usually run on different machines and the
>> monitor port is fixed, a simple firewall rule should be sufficient to
>> prevent this situation. The intermediate communication between agents
>> though is tough.
>>
>> Now the proxy. The main target for me with the first version was simply to
>> have a proxy. Since the proxy is only needed for competitions, I felt it
>> should be transparent to both sides. Given this and that the current
>> implementation uses random port assignments, there is no possibility for
>> the server to distinguish connections from a proxy and connections coming
>> directly from an agent. On the other hand, the current proxy implementation
>> simply accepty new connections in an endless loop and has no information
>> about the competition at all.
>> In order to not touch the server code, I came up with the following idea.
>> Extend the proxy to run (and maybe monitoring) the agent processes. If an
>> agent is started by the proxy, the proxy can expect to get a connection
>> request for each agent it started and can already reserve a connection to
>> the server for it. If it doesn't get a connection request together with an
>> init-message within let's say 10 seconds, the proxy simply kills the
>> previously started agent again and prompts a warning. This way the game
>> wouldn't start up and someone would notice that something is wrong.
>> We could use the same starting scripts for the agents (just not starting a
>> whole team, instead only one agent), but we would need to run a proxy
>> instance for each match, with some more parameters. Should be not too much
>> of a change in the depending scripts.
>>
>>
>> In case I find time to develop the competition manager GUI I have in mind
>> (an advanced version of the league manager), my target is to use an own
>> interface to the proxy server to run/stop/monitor agent processes and their
>> network statistics. This way a proxy can stay running the whole day and is
>> instructed directly from the competition manager GUI.
>> When talking about the competition manager GUI, I also thought about
>> providing the current results of the competition to the agents. I wonder
>> why the SimSpark server should take care of this and why the RSG format
>> should be used in this case. When thinking of the SimSpark server as a tool
>> for research, providing competition abilities is just not needed and
>> irrelevant i.e. for learning. In my opinion, if we play a competition, the
>> server is only responsible for simulating the games, not for organizing
>> them. If we intend to have a central file, containing the whole competition
>> results, why not using an xml-file, which can be easily published and
>> displayed as html-page to humans, using xsl? And if this file already
>> exists, why not publishing it over the internet?
>> All this could be addressed by a separate application, providing a nice
>> GUI to manage and monitor competitions. This GUI can also be used to
>> display the results for visitors at Robocup events. By integrating i.e.
>> RoboViz, we could even watch the games directly in the competition manager
>> and play logfiles of the best scenes to amuse visitors. And, think about a
>> team which want to test their new agent binary at a competition. They open
>> the competition manager in training mode and can either start a game
>> against another own binary, or ask other teams to enter their user password
>> in order to allow the use of their binary for one test match. Test matches
>> are then automatically played under competition conditions. This would
>> speed up test-time of teams when setting up things on the competition
>> machines for test games.
>>
>> I'm really looking forward to develop such a competition manager. I think
>> this would be a great contribution to the Robocup events, which I can
>> easily provide, since I'm familiar with most technical stuff involved. With
>> this I could take care of providing the actual results of the competition
>> to the agents.
>> I'm not sure yet how I'll find time. But I'm kind of eager to start ;)
>>
>> What do you think?
>>
>> Sorry, got quite a long mail meanwhile. I intend to put a description of
>> my thoughts into the wiki, too.
>>
>> Wish you all the best,
>> Stefan
>>
>>
>>
>>
>>
>> Am 18.02.2013 08:53, schrieb Klaus Dorer:
>>
>> Hi Hedayat,
>>
>> hmmm, security aspects are important. But are we checking that no agent is
>> connecting as monitor? Or are we checking that no agent opens a socket to
>> another agent? I think no. Therefore I wonder if we have to be more strict
>> here. If yes, is this something we have to do on application level, or can
>> we do it on a different level, e.g. opening that port only for a specific
>> application?
>>
>> Greetings
>> Klaus
>>
>> Am 16.02.2013 19:20, schrieb Hedayat Vatankhah:
>>
>> Hi Stefan,
>> Sorry for my lack of response. I'm still planning to put some time to
>> answer your first email (but in brief, the security aspects look more
>> complicated than the proxy itself. For example, agents must be unable to
>> impersonate themselves as the proxy(ies)).
>> And thank you a lot for reporting on the progress. I'll certainly look
>> into the wiki page and will provide my comments (if any!). :)
>>
>> Thanks a lot.
>> Hedayat
>>
>>
>> /*Stefan Glaser <gla...@gm...> <gla...@gm...>*/ wrote
>> on Sat, 16 Feb 2013 19:13:50 +0100:
>>
>> Hello Hedayat,
>>
>> I was eager to implement something, so I spend some time implementing the
>> proxy server for SimSpark.
>> It was quite simple and straight forward to implement and first tests look
>> good. We intend to test the proxy over the internet, just to get a
>> subjective impression ;) In addition we also want to test it on a local
>> network, monitoring the traffic to the server with wireshark, to get some
>> numbers. Once that is done, I would try to release it somehow.
>>
>> If you are interested in the concept and want to get some information
>> until we release the source code, I already put a description into the
>> wiki:
>> http://simspark.sourceforge.net/wiki/index.php/Agent_Proxy
>>
>> Wish you all the best,
>> Stefan
>>
>>
>> Am 13.02.2013 14:10, schrieb Stefan Glaser:
>>
>> Hello Hedayat,
>>
>> as Klaus mentioned, we would take care of implementing the proxy approach
>> for the next competitions.
>>
>> We would realize it in Java - I hope that doesn't result in any problem...
>>
>> Now, appart from informing you about that we would take care of the
>> implementation, I wanted to ask you about some thoughts with respect to the
>> proxy. The basic idea is clear, having an intermediate component, measuring
>> the time on the client machines. But I wonder, is there anything else
>> critical, which one has to be aware of in the implementation? E.g. some
>> situation which a team can explore in order to gain benefits over other
>> teams?
>>
>> Cheers,
>> Stefan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
>> is your hub for all things parallel software development, from weekly
>> thought
>> leadership blogs to news, videos, case studies, tutorials, tech docs,
>> whitepapers, evaluation guides, and opinion stories. Check out the most
>> recent posts - join the conversation now.
>> http://goparallel.sourceforge.net/
>> _______________________________________________
>> Simspark Generic Physical MAS Simulator
>> simspark-devel mailing list
>> sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>>
>>
>

Re: [simspark-devel] Simspark Proxy Implementation

[Sander v. D. <sgv...@gm...>]

Hey all,

Few things from me to add to the discussion:

- Regardless from implementation and discussion about which program should
be responsible, let's tackle first how teams access it. I for now am in
favour of files written somewhere that are accessible to all teams, e.g. a
special user's ('results') home dir that is readable for everybody. I agree
with Hedayat that they should be in any case RSG. This would be the easiest
for teams to implement, and we could even make them by hand in case we
don't manage to create the automated tools in time, which as OC makes me
most comfortable :).

- Just FYI before too much redundant work is done, the organization for
Eindhoven is looking into using some competition wide centralized 'Score
Board' application that has been developed. I am awaiting more details on
what it actually is, but it looks like something that makes the gathering
and publication of results automatic, and perhaps we can plug into it.

- Finally, I'd just like to point RCSimControl (
http://launchpad.net/rcsimcontrol), which I developed during the RoboCup
funded project in which I also created the TBB multithreading for the
server. I always planned to use it to create a more advanced league manager
as well (it controls multiple parallel instances; I use it to run a small
scale tournament for qualification on our super cluster). But development
of any other tools by somebody who actually has the time to invest in it is
of course always welcome ;).

Cheers,
Sander


On Mon, Feb 18, 2013 at 7:39 PM, Hedayat Vatankhah <hed...@gm...>wrote:

>  Hi Stefan & Klaus,
> (and others! I thought that it is better to add this discussion to
> simspark-devel, hope that you don't mind!)
> About monitor, yes actually in all games that I'm in OC I do setup
> firewall rules to close all connections except the expected ones as Stefan
> said. But no, I didn't anything for communication between agents through
> sockets (however, I have tried some other restrictions like making the log
> files and directories write-only).
> I was not trying to imply that our security is perfect now, but security
> should be considered anyway. Also, the problem with the proxy could be
> probably much more 'useful' than communication between agents. I also
> didn't want to imply that we should not use proxy until it is completely
> secure. Even having a plan for security is great.
>
> Anyway, the security aspect is not necessarily complex. Stefan provided an
> idea, and actually it derived me to think of an even simpler idea... or
> actually that it is probably already secure enough! :P :D How? Well, we
> will run the proxy before the agents anyway, right? So, the proxy can make
> the expected number of connections to the simulator before running the
> agents. Now, we know that no more connections should be made to the
> simulator, so agents cannot connect to the simulator anyway. We can have a
> simple method to monitor the number of agents connected to proxies too (for
> example, league manager might query the number of agents and print them on
> screen or something). This probably have a little implementation work for
> the proxy too. However, Stefan ideas are great too, specially about the
> competition manager.
>
> About providing the results, RSG format is selected (I guess!) because
> agents already have an RSG parser, so they can easily parse them. Using
> another format for the agents mean that they should implement yet another
> parser. Therefore, I'm actually in favor of using RSG format for that.
> However, the results might be generated also in another format for other
> purposes.
>
> But, no, simspark should not be responsible for providing the results, and
> even if it is, it should get the results from another place. Actually, I've
> said previously (probably in TC ML or simspark-devel) that ideally we would
> need a kind of 'results server'. Since we run games in parallel, teams
> should be actually informed about all results not just the ones played in
> that cluster. There are even considerations such as the order and time of
> playing games in different clusters (there should be probably a 'schedule',
> and teams are informed about the results of the games which are past in
> schedule even if we were actually able to play some more games in the other
> cluster; or we should really run the games according to the schedule).
> Teams might query the results from the result server themselves, or
> rcssserver3d (which is certainly about competitions) can query them and
> provide it to agents. The results server can generate results in other
> formats usable for publishing, like using XML and XSL as Stefan mentioned.
>
> Finally, it might be more interesting if the competition manager can
> manage all games rather than the games running on a single cluster (in that
> case, it can actually play the role of the results server too). Consider
> each cluster as a soccer field, competition manager can schedule the games
> and then start the games on the selected fields. Or we might not consider
> clusters as fields and consider them completely equal, and dispatch each
> game when any cluster is available. Another policy could be to run all
> games of a single group on the same cluster to make sure that conditions
> are equal for each group. Anyway, when it dispatches a game, it might also
> provide the results for that game too. Well, this idea should not
> necessarily be implemented in the initial versions, but might be a goal
> which should be considered in design.
>
> Regards,
> Hedayat
>
>
> *Stefan Glaser <gla...@gm...> <gla...@gm...>* wrote on
> Mon, 18 Feb 2013 13:28:57 +0100:
>
> Hello together,
>
> sorry that I jump into the discussion, but I also spend some time in
> thinking of these problems.
>
> In general, the monitor issue you mentioned is not really a problem. Since
> the agent teams and the monitor usually run on different machines and the
> monitor port is fixed, a simple firewall rule should be sufficient to
> prevent this situation. The intermediate communication between agents
> though is tough.
>
> Now the proxy. The main target for me with the first version was simply to
> have a proxy. Since the proxy is only needed for competitions, I felt it
> should be transparent to both sides. Given this and that the current
> implementation uses random port assignments, there is no possibility for
> the server to distinguish connections from a proxy and connections coming
> directly from an agent. On the other hand, the current proxy implementation
> simply accepty new connections in an endless loop and has no information
> about the competition at all.
> In order to not touch the server code, I came up with the following idea.
> Extend the proxy to run (and maybe monitoring) the agent processes. If an
> agent is started by the proxy, the proxy can expect to get a connection
> request for each agent it started and can already reserve a connection to
> the server for it. If it doesn't get a connection request together with an
> init-message within let's say 10 seconds, the proxy simply kills the
> previously started agent again and prompts a warning. This way the game
> wouldn't start up and someone would notice that something is wrong.
> We could use the same starting scripts for the agents (just not starting a
> whole team, instead only one agent), but we would need to run a proxy
> instance for each match, with some more parameters. Should be not too much
> of a change in the depending scripts.
>
>
> In case I find time to develop the competition manager GUI I have in mind
> (an advanced version of the league manager), my target is to use an own
> interface to the proxy server to run/stop/monitor agent processes and their
> network statistics. This way a proxy can stay running the whole day and is
> instructed directly from the competition manager GUI.
> When talking about the competition manager GUI, I also thought about
> providing the current results of the competition to the agents. I wonder
> why the SimSpark server should take care of this and why the RSG format
> should be used in this case. When thinking of the SimSpark server as a tool
> for research, providing competition abilities is just not needed and
> irrelevant i.e. for learning. In my opinion, if we play a competition, the
> server is only responsible for simulating the games, not for organizing
> them. If we intend to have a central file, containing the whole competition
> results, why not using an xml-file, which can be easily published and
> displayed as html-page to humans, using xsl? And if this file already
> exists, why not publishing it over the internet?
> All this could be addressed by a separate application, providing a nice
> GUI to manage and monitor competitions. This GUI can also be used to
> display the results for visitors at Robocup events. By integrating i.e.
> RoboViz, we could even watch the games directly in the competition manager
> and play logfiles of the best scenes to amuse visitors. And, think about a
> team which want to test their new agent binary at a competition. They open
> the competition manager in training mode and can either start a game
> against another own binary, or ask other teams to enter their user password
> in order to allow the use of their binary for one test match. Test matches
> are then automatically played under competition conditions. This would
> speed up test-time of teams when setting up things on the competition
> machines for test games.
>
> I'm really looking forward to develop such a competition manager. I think
> this would be a great contribution to the Robocup events, which I can
> easily provide, since I'm familiar with most technical stuff involved. With
> this I could take care of providing the actual results of the competition
> to the agents.
> I'm not sure yet how I'll find time. But I'm kind of eager to start ;)
>
> What do you think?
>
> Sorry, got quite a long mail meanwhile. I intend to put a description of
> my thoughts into the wiki, too.
>
> Wish you all the best,
> Stefan
>
>
>
>
>
> Am 18.02.2013 08:53, schrieb Klaus Dorer:
>
> Hi Hedayat,
>
> hmmm, security aspects are important. But are we checking that no agent is
> connecting as monitor? Or are we checking that no agent opens a socket to
> another agent? I think no. Therefore I wonder if we have to be more strict
> here. If yes, is this something we have to do on application level, or can
> we do it on a different level, e.g. opening that port only for a specific
> application?
>
> Greetings
> Klaus
>
> Am 16.02.2013 19:20, schrieb Hedayat Vatankhah:
>
> Hi Stefan,
> Sorry for my lack of response. I'm still planning to put some time to
> answer your first email (but in brief, the security aspects look more
> complicated than the proxy itself. For example, agents must be unable to
> impersonate themselves as the proxy(ies)).
> And thank you a lot for reporting on the progress. I'll certainly look
> into the wiki page and will provide my comments (if any!). :)
>
> Thanks a lot.
> Hedayat
>
>
> /*Stefan Glaser <gla...@gm...> <gla...@gm...>*/ wrote
> on Sat, 16 Feb 2013 19:13:50 +0100:
>
> Hello Hedayat,
>
> I was eager to implement something, so I spend some time implementing the
> proxy server for SimSpark.
> It was quite simple and straight forward to implement and first tests look
> good. We intend to test the proxy over the internet, just to get a
> subjective impression ;) In addition we also want to test it on a local
> network, monitoring the traffic to the server with wireshark, to get some
> numbers. Once that is done, I would try to release it somehow.
>
> If you are interested in the concept and want to get some information
> until we release the source code, I already put a description into the
> wiki:
> http://simspark.sourceforge.net/wiki/index.php/Agent_Proxy
>
> Wish you all the best,
> Stefan
>
>
> Am 13.02.2013 14:10, schrieb Stefan Glaser:
>
> Hello Hedayat,
>
> as Klaus mentioned, we would take care of implementing the proxy approach
> for the next competitions.
>
> We would realize it in Java - I hope that doesn't result in any problem...
>
> Now, appart from informing you about that we would take care of the
> implementation, I wanted to ask you about some thoughts with respect to the
> proxy. The basic idea is clear, having an intermediate component, measuring
> the time on the client machines. But I wonder, is there anything else
> critical, which one has to be aware of in the implementation? E.g. some
> situation which a team can explore in order to gain benefits over other
> teams?
>
> Cheers,
> Stefan
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>


-- 
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom

Re: [simspark-devel] Simspark Proxy Implementation

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

Hi Stefan & Klaus,
(and others! I thought that it is better to add this discussion to 
simspark-devel, hope that you don't mind!)
About monitor, yes actually in all games that I'm in OC I do setup 
firewall rules to close all connections except the expected ones as 
Stefan said. But no, I didn't anything for communication between agents 
through sockets (however, I have tried some other restrictions like 
making the log files and directories write-only).
I was not trying to imply that our security is perfect now, but security 
should be considered anyway. Also, the problem with the proxy could be 
probably much more 'useful' than communication between agents. I also 
didn't want to imply that we should not use proxy until it is completely 
secure. Even having a plan for security is great.

Anyway, the security aspect is not necessarily complex. Stefan provided 
an idea, and actually it derived me to think of an even simpler idea... 
or actually that it is probably already secure enough! :P :D How? Well, 
we will run the proxy before the agents anyway, right? So, the proxy can 
make the expected number of connections to the simulator before running 
the agents. Now, we know that no more connections should be made to the 
simulator, so agents cannot connect to the simulator anyway. We can have 
a simple method to monitor the number of agents connected to proxies too 
(for example, league manager might query the number of agents and print 
them on screen or something). This probably have a little implementation 
work for the proxy too. However, Stefan ideas are great too, specially 
about the competition manager.

About providing the results, RSG format is selected (I guess!) because 
agents already have an RSG parser, so they can easily parse them. Using 
another format for the agents mean that they should implement yet 
another parser. Therefore, I'm actually in favor of using RSG format for 
that. However, the results might be generated also in another format for 
other purposes.

But, no, simspark should not be responsible for providing the results, 
and even if it is, it should get the results from another place. 
Actually, I've said previously (probably in TC ML or simspark-devel) 
that ideally we would need a kind of 'results server'. Since we run 
games in parallel, teams should be actually informed about all results 
not just the ones played in that cluster. There are even considerations 
such as the order and time of playing games in different clusters (there 
should be probably a 'schedule', and teams are informed about the 
results of the games which are past in schedule even if we were actually 
able to play some more games in the other cluster; or we should really 
run the games according to the schedule).
Teams might query the results from the result server themselves, or 
rcssserver3d (which is certainly about competitions) can query them and 
provide it to agents. The results server can generate results in other 
formats usable for publishing, like using XML and XSL as Stefan mentioned.

Finally, it might be more interesting if the competition manager can 
manage all games rather than the games running on a single cluster (in 
that case, it can actually play the role of the results server too). 
Consider each cluster as a soccer field, competition manager can 
schedule the games and then start the games on the selected fields. Or 
we might not consider clusters as fields and consider them completely 
equal, and dispatch each game when any cluster is available. Another 
policy could be to run all games of a single group on the same cluster 
to make sure that conditions are equal for each group. Anyway, when it 
dispatches a game, it might also provide the results for that game too. 
Well, this idea should not necessarily be implemented in the initial 
versions, but might be a goal which should be considered in design.

Regards,
Hedayat


/*Stefan Glaser <gla...@gm...>*/ wrote on Mon, 18 Feb 2013 
13:28:57 +0100:
> Hello together,
>
> sorry that I jump into the discussion, but I also spend some time in 
> thinking of these problems.
>
> In general, the monitor issue you mentioned is not really a problem. 
> Since the agent teams and the monitor usually run on different 
> machines and the monitor port is fixed, a simple firewall rule should 
> be sufficient to prevent this situation. The intermediate 
> communication between agents though is tough.
>
> Now the proxy. The main target for me with the first version was 
> simply to have a proxy. Since the proxy is only needed for 
> competitions, I felt it should be transparent to both sides. Given 
> this and that the current implementation uses random port assignments, 
> there is no possibility for the server to distinguish connections from 
> a proxy and connections coming directly from an agent. On the other 
> hand, the current proxy implementation simply accepty new connections 
> in an endless loop and has no information about the competition at all.
> In order to not touch the server code, I came up with the following 
> idea. Extend the proxy to run (and maybe monitoring) the agent 
> processes. If an agent is started by the proxy, the proxy can expect 
> to get a connection request for each agent it started and can already 
> reserve a connection to the server for it. If it doesn't get a 
> connection request together with an init-message within let's say 10 
> seconds, the proxy simply kills the previously started agent again and 
> prompts a warning. This way the game wouldn't start up and someone 
> would notice that something is wrong.
> We could use the same starting scripts for the agents (just not 
> starting a whole team, instead only one agent), but we would need to 
> run a proxy instance for each match, with some more parameters. Should 
> be not too much of a change in the depending scripts.
>
>
> In case I find time to develop the competition manager GUI I have in 
> mind (an advanced version of the league manager), my target is to use 
> an own interface to the proxy server to run/stop/monitor agent 
> processes and their network statistics. This way a proxy can stay 
> running the whole day and is instructed directly from the competition 
> manager GUI.
> When talking about the competition manager GUI, I also thought about 
> providing the current results of the competition to the agents. I 
> wonder why the SimSpark server should take care of this and why the 
> RSG format should be used in this case. When thinking of the SimSpark 
> server as a tool for research, providing competition abilities is just 
> not needed and irrelevant i.e. for learning. In my opinion, if we play 
> a competition, the server is only responsible for simulating the 
> games, not for organizing them. If we intend to have a central file, 
> containing the whole competition results, why not using an xml-file, 
> which can be easily published and displayed as html-page to humans, 
> using xsl? And if this file already exists, why not publishing it over 
> the internet?
> All this could be addressed by a separate application, providing a 
> nice GUI to manage and monitor competitions. This GUI can also be used 
> to display the results for visitors at Robocup events. By integrating 
> i.e. RoboViz, we could even watch the games directly in the 
> competition manager and play logfiles of the best scenes to amuse 
> visitors. And, think about a team which want to test their new agent 
> binary at a competition. They open the competition manager in training 
> mode and can either start a game against another own binary, or ask 
> other teams to enter their user password in order to allow the use of 
> their binary for one test match. Test matches are then automatically 
> played under competition conditions. This would speed up test-time of 
> teams when setting up things on the competition machines for test games.
>
> I'm really looking forward to develop such a competition manager. I 
> think this would be a great contribution to the Robocup events, which 
> I can easily provide, since I'm familiar with most technical stuff 
> involved. With this I could take care of providing the actual results 
> of the competition to the agents.
> I'm not sure yet how I'll find time. But I'm kind of eager to start ;)
>
> What do you think?
>
> Sorry, got quite a long mail meanwhile. I intend to put a description 
> of my thoughts into the wiki, too.
>
> Wish you all the best,
> Stefan
>
>
>
>
>
> Am 18.02.2013 08:53, schrieb Klaus Dorer:
>> Hi Hedayat,
>>
>> hmmm, security aspects are important. But are we checking that no 
>> agent is connecting as monitor? Or are we checking that no agent 
>> opens a socket to another agent? I think no. Therefore I wonder if we 
>> have to be more strict here. If yes, is this something we have to do 
>> on application level, or can we do it on a different level, e.g. 
>> opening that port only for a specific application?
>>
>> Greetings
>> Klaus
>>
>> Am 16.02.2013 19:20, schrieb Hedayat Vatankhah:
>>> Hi Stefan,
>>> Sorry for my lack of response. I'm still planning to put some time 
>>> to answer your first email (but in brief, the security aspects look 
>>> more complicated than the proxy itself. For example, agents must be 
>>> unable to impersonate themselves as the proxy(ies)).
>>> And thank you a lot for reporting on the progress. I'll certainly 
>>> look into the wiki page and will provide my comments (if any!). :)
>>>
>>> Thanks a lot.
>>> Hedayat
>>>
>>>
>>> /*Stefan Glaser <gla...@gm...>*/ wrote on Sat, 16 Feb 2013 
>>> 19:13:50 +0100:
>>>> Hello Hedayat,
>>>>
>>>> I was eager to implement something, so I spend some time 
>>>> implementing the proxy server for SimSpark.
>>>> It was quite simple and straight forward to implement and first 
>>>> tests look good. We intend to test the proxy over the internet, 
>>>> just to get a subjective impression ;) In addition we also want to 
>>>> test it on a local network, monitoring the traffic to the server 
>>>> with wireshark, to get some numbers. Once that is done, I would try 
>>>> to release it somehow.
>>>>
>>>> If you are interested in the concept and want to get some 
>>>> information until we release the source code, I already put a 
>>>> description into the wiki:
>>>> http://simspark.sourceforge.net/wiki/index.php/Agent_Proxy
>>>>
>>>> Wish you all the best,
>>>> Stefan
>>>>
>>>>
>>>> Am 13.02.2013 14:10, schrieb Stefan Glaser:
>>>>> Hello Hedayat,
>>>>>
>>>>> as Klaus mentioned, we would take care of implementing the proxy 
>>>>> approach for the next competitions.
>>>>>
>>>>> We would realize it in Java - I hope that doesn't result in any 
>>>>> problem...
>>>>>
>>>>> Now, appart from informing you about that we would take care of 
>>>>> the implementation, I wanted to ask you about some thoughts with 
>>>>> respect to the proxy. The basic idea is clear, having an 
>>>>> intermediate component, measuring the time on the client machines. 
>>>>> But I wonder, is there anything else critical, which one has to be 
>>>>> aware of in the implementation? E.g. some situation which a team 
>>>>> can explore in order to gain benefits over other teams?
>>>>>
>>>>> Cheers,
>>>>> Stefan
>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Re: [simspark-devel] Open Source Track in RoboCup Symposium 2013

[Yuan Xu <xu...@in...>]

Hi Hedayat,

Great!

according to CFP: "They should include evidence of impact of the released
component to the RoboCup community. Review of these contributions will be
based on technical contribution and benefit for the RoboCup community."

I think the content looks like [1] and [2], but focuses more on the recent
improvement and current state. We can also invite the authors of [1,2] to
help us.


[1] O. Obst and M. Rollmann. Spark - A  generic simulator for physical
multi-agent simulations. Computer Systems Science and Engineering, 20(5),
Sep. 2005. http://www.oliverobst.eu/publications/2005/spark-OR05.pdf

[2] J. Boedecker and M. Asada. SimSpark - Concepts and Application in the
RoboCup 3D Soccer Simulation League. Workshop Proceedings of *SIMPAR 2008. *
http://monicareggiani.net/simpar2008/RoboCupSimulators/SIMPAR_simspark.pdf

Best Regards,

Xu, Yuan


On Mon, Jan 28, 2013 at 8:37 PM, Hedayat Vatankhah <hed...@gm...>wrote:

>  Hi Yuan,
>
>
> *Yuan Xu <xu...@in...> <xu...@in...>* wrote
> on Mon, 28 Jan 2013 17:52:56 +0100:
>
> Hi all,
>
> There is a new track on open-source developments will be included in the
> 2013 RoboCup International Symposium. The last paper about SimSpark was
> published years ago (the one listed in the home page of project was
> published in 2005).
>
>  I think we should submit a paper about SimSpark there, and promote it to
> the whole RoboCup community.
> Is anybody interested in?
>
> Sounds interesting. I don't have any ideas about what we can write about
> right now, but I am interested if I can help until the deadlines. :P
>
> Regards,
> Hedayat
>
>
>
> Best Regards,
>
> Xu, Yuan
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:http://p.sf.net/sfu/learnnow-d2d
>
>
>
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>

Re: [simspark-devel] Open Source Track in RoboCup Symposium 2013

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

Hi Yuan,


/*Yuan Xu <xu...@in...>*/ wrote on Mon, 28 Jan 2013 
17:52:56 +0100:
> Hi all,
>
> There is a new track on open-source developments will be included in 
> the 2013 RoboCup International Symposium. The last paper about 
> SimSpark was published years ago (the one listed in the home page of 
> project was published in 2005).
>
> I think we should submit a paper about SimSpark there, and promote it 
> to the whole RoboCup community.
> Is anybody interested in?
Sounds interesting. I don't have any ideas about what we can write about 
right now, but I am interested if I can help until the deadlines. :P

Regards,
Hedayat


>
> Best Regards,
>
> Xu, Yuan
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
>
>
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel

[simspark-devel] Open Source Track in RoboCup Symposium 2013

[Yuan Xu <xu...@in...>]

Hi all,

There is a new track on open-source developments will be included in the
2013 RoboCup International Symposium. The last paper about SimSpark was
published years ago (the one listed in the home page of project was
published in 2005).

I think we should submit a paper about SimSpark there, and promote it to
the whole RoboCup community.
Is anybody interested in?

Best Regards,

Xu, Yuan

Re: [simspark-devel] Development of Rcssserver3d

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

Hi Jimmy,
You can find some documentation in our wiki[1, 2], but beside that and 
documents already available in the archives there are no other 
documentation AFAIK.

Regards
Hedayat

[1] http://simspark.sourceforge.net/wiki/index.php/Main_Page
[2] http://simspark.sourceforge.net/wiki/index.php/Developers_Manual


/*Wenbin Wang <wi...@gm...>*/ wrote on Wed, 23 Jan 2013 20:59:37 +0800:
> Hi Hedayatv,
> �����
> �������� Is there any document for learning Server?Reading documents 
> is much more effiecient than reading code.Now the only document I 
> possess are the documents attached in Simspark-0.2.3 and Rcssserve-0.6.6.
> ��������
> ��������� Also,I'm prepared and eager to do some attribution to the 
> development of simspark.
>
> Best regards,
> Jimmy

Re: [simspark-devel] Call for volunteers for RoboCup Soccer Simulator development in 2013

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

Hi Stefan,
Sorry for the delay!


/*Stefan Glaser <gla...@gm...>*/ wrote on Mon, 17 Dec 2012 
13:14:18 +0100:
> Hey Hedayat,
>
> nice to hear from you again!
Thanks :), you too

> I also planed to contribute a bit to the community this season, but 
> I'm not sure yet, what I will be able to do.
> I certainly want to put some effort to the wiki and pdf manual again. 
> I just implemented the monitor protocol on my own and recognized some 
> differences to the wiki, which I'll document soon. Furthermore I also 
> want to put some new section to the wiki introducing to terms like 
> "How to use the simulator for machine learning" and also nail down the 
> configuration files of the simulatior, add the new percrptors and 
> effectors for stiffness control, etc.
> So if you don't have anyone taking care of some documentation, I may 
> be the one. Also feel free to give me a hint where documentation is 
> still missing. In general, I think the wiki is not too bad any more. 
> We never removed finished points of the todo-list, maybe I should 
> spend some time on this as well ;)
That's great. Event if somebody else is also willing to help, it would 
be great to have you there too. :) I've already added your name to 2013 
MC page.


>
> The next point may be the monitor protocol. As I just sad, I 
> implemented it and I'm currently also working on an application, 
> described in the next paragraph. While doing so, I recognized that it 
> is not very network efficient. Given that the logfile of an 5-6 minute 
> game is around 120MB with 5 frames per second, I calculated something 
> around 0.4MB/sec, which is 3.2MBit/s. Given that we have a stream to 
> the monitor of 25 frames per second, this results in 16MBit/s network 
> load alone for the monitor protocol. Is this correct? Sounds quite a 
> lot for me... Given that I at some point want to provide a better 
> media support in the league and want to use the full 50 frames per 
> second to create some slow motion video scenes, this would result in 
> 32MBit/s load with the current protocol. And even worse, if the 
> application I'm currently programming will be used in future 
> competitions, we always have 2 monitors connected to one server.
> We will need to discuss this point again once I have time to take care 
> of it and my ideas are good enough to implement them. Or do you 
> already have an idea how to improve this?
I cannot comment on the numbers. But the load increases with the number 
of players. However, if your application is ready, the monitors can 
connect to your application rather than the main server. I had some 
ideas, but I should check the latest in robotics software world to see 
if they are outdated. So, I agree that we should discuss it soon.


>
> The program mentioned above I'm currently implementing is a streaming 
> server and client. I have a lot of friends at home which are 
> interested at the competitions, but never have time to join them at 
> place. Or e.g. you this year had no chance to watch the games live. So 
> I decided to programm a streaming server/client. The idea is quite 
> simple. The first version of the streaming-server will connect to a 
> simpark server as monitor and so to say just forward the messages to 
> the connected streaming clients in bundles. The streaming client 
> connects to the streaming server and outputs the server messages on a 
> local port in real time. This way one can connect any common monitor 
> to the local streaming client and opperate the camera, etc. control 
> commands are of course not forwarded. This way we are able to build a 
> stream server hierarchie and stream to interested universities. 
> Furthermore we can provide further local viewing stations on the 
> campionchips. Last year for example at the Dutch Open there was a 
> second monitor connected because the public area was several meters 
> away from the real competition. I think I will finish and publish the 
> streaming server and client the end of this year. This may also be a 
> good time to discuss about the monitor protocol in order to reduce 
> network load.
That's great, specially if it works for slow or unreliable connections too!



>
> The last point in my list is a training mode of the server in which an 
> agent is able to beam itself and the ball freely, perceives ground 
> truth data, etc. Currently a lot of this options are already somehow 
> available. But the big point is that if we realy want to open up the 
> simulator for machine learing, we should allow theese options with one 
> parameter, maybe even a command line parameter.
Yes, this is certainly an area in need of improvements and more user 
friendliness.


>
> I will write you another email when I have some time to spend on the 
> server. I will definetly need some help to get startet.
Great. Send it to simspark-devel so that others will see it too. They 
can also provide valuable input.

Regards,
Hedayat

>
> Cheers,
> Stefan
>
>
>
>
>
> Am 16.12.2012 21:37, schrieb Hedayat Vatankhah:
>> Hi all!
>> Like previous years, we are going to create a roadmap for the 
>> development of our soccer simulator till RoboCup 2013 competitions 
>> specially since TC decisions are already announced. I've create a 
>> stub at [1], which is going to be used to coordinate our 2013 
>> development efforts. Also notice that the development of the 
>> simulator is NOT restricted to TC decisions and everybody can 
>> implement new ideas and contribute to the simulator.
>>
>> Therefore, I invite everyone to join us in MC and contribute in the 
>> development of the simulator. You can pick up any of the tasks, or 
>> even propose new ones and work on them. Please contact me if you are 
>> interested in helping us in the development of the simulator.
>>
>> However, if you cannot help us in the development or documentation of 
>> the simulator, you still can help. There are a number of open issues 
>> in TC proposal, which should be addressed as early as possible so 
>> that we will have a usable design and implementation. Please read the 
>> proposal carefully and send your feedback.
>>
>> Regards,
>> Hedayat
>>
>> [1] 
>> http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2013
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>>
>>
>> _______________________________________________
>> Simspark Generic Physical MAS Simulator
>> simspark-devel mailing list
>> sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>

[simspark-devel] Call for volunteers for RoboCup Soccer Simulator development in 2013

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

Hi all!
Like previous years, we are going to create a roadmap for the 
development of our soccer simulator till RoboCup 2013 competitions 
specially since TC decisions are already announced. I've create a stub 
at [1], which is going to be used to coordinate our 2013 development 
efforts. Also notice that the development of the simulator is NOT 
restricted to TC decisions and everybody can implement new ideas and 
contribute to the simulator.

Therefore, I invite everyone to join us in MC and contribute in the 
development of the simulator. You can pick up any of the tasks, or even 
propose new ones and work on them. Please contact me if you are 
interested in helping us in the development of the simulator.

However, if you cannot help us in the development or documentation of 
the simulator, you still can help. There are a number of open issues in 
TC proposal, which should be addressed as early as possible so that we 
will have a usable design and implementation. Please read the proposal 
carefully and send your feedback.

Regards,
Hedayat

[1] 
http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2013

Re: [simspark-devel] [Sserver-three-d] Feature discussions

[Yuan Xu <xu...@in...>]

Hi all,

I have put the implementation of realistic motor in the svn branch
'realistic_motor ',
you can check out and test the code by:
    svn co https://simspark.svn.sourceforge.net/svnroot/simspark/branches/realistic_motor
simspark_realistic_motor
or simply review the code in
http://simspark.svn.sourceforge.net/viewvc/simspark/branches/realistic_motor/

The main changes are:
* stiffness of motor is controllable by StiffnessEffector (the name of
effectors are name of joint effector + 's', e.g. 'laj1s' for
controlling stiffness of 'laj1')
* the power consumption is modeled, the battery status is given by
BatteryPerceptor, the robot is not able to move when the battery is
empty
* the internal temperature of motor is modeled, and the overheating
protection is enabled when the motor is too hot.
* the temperature of motor is reported by AngularMotorPerceptor

The new effector and perceptors are documented in user manual as well.
All parameters are determined by experiments on real NAO, and we can
change them for competition.

Any comments and feedback is welcome!

Best Regards,

Xu, Yuan


On Thu, Sep 6, 2012 at 2:13 PM, Hans-Dieter Burkhard
<hd...@in...> wrote:
> Hello all,
>
>
> Am 05.09.12 17:37, schrieb Stefan Glaser:
>
> Hello Dieter,
>
> Am 05.09.2012 09:59, schrieb Hans-Dieter Burkhard:
>
> Dear Stefan, dear all
>
> thank you Stefan for your explanations and plans - I am looking forward to
> hear more
> (by the way, in the community I am simply "Dieter").
>
> you are very welcome.
> For turning off the soccer rules, simply comment out the line:
>
> 	gameControlServer.initControlAspect('SoccerRuleAspect')
>
> in the "naosoccersim.rb" file in "/usr/local/share/rcssserver3d" folder.
>
>
> Thank you, I did and it works in principle well
> (but it still does not allow to beam players at arbitrary position at
> beginning).
>
>
>
> As a repeated statement, I think that the simulator has a great potential
> for both, teaching and research.
> If we can manage to lower down the barriers for entrance, it could be of use
> for many purposes, not only
> RoboCup - but maybe to make people interested in RoboCup. We had just a
> course in Macedonia on
> "Robotics and Mathematics" (funded by DAAD), where we used the simulator
> together with an agent
> framework. It worked really well and we are going to extend the framework
> etc.
>
> For such work (and also for intended usage at high schools), a simple
> handling is recommendable.
> The usage for Machine Learning etc. leads to similar recommendations - if we
> dont think only about RoboCup
> people.
>
> How this is achieved best can be discussed (for the moment I would like some
> simple "switches", but it is also
> possible to distribute the programs with predefined configurations).
>
> That's great! I think the community is happy to hear that the server is
> further applied beyond the RoboCup competitions. We also discussed at the
> previous competitions that we want to simplify development with the server
> and make it easier to use for researchers. In order to do so, I decided to
> address the documentation gap first, since I know that the server already
> provides most/all of the functionality needed. After that I will start a
> discussion about improvements.
>
>
> Actually, the installation of the server is not so easy. So we used a
> windows-version compiled by and thanks to Yuan.
> For usage outside RoboCup we might need a "stable version" - while for
> RoboCup we want to extend it step by step.
> Dont know how to overcome this conflict. We have compiled a tutorial
> material about the server. We could provide
> it to the community (but it is not up to date because it was related to our
> server version from Spring, but needed
> changes should be not too much).
>
> At the other side, we will provide some easy understandable agent, which can
> be modified and extended without
> much efforts. Actually, the first version (written in JAVA with credits to
> MAGMA) is already under test. We will report
> about further progress and hope to present it at RoboCup in Eindhoven.
>
> Best regards
>
> Dieter
>
>
>
> According to low level control and close relations to reality, I am also
> looking forward to introduce stiffness,
> torque, power consumption etc. if possible - may be not for competition but
> for some "research modes".
> As I understood, something is already done in this direction? Can it be made
> available?
>
> I was also advertising the torque control topic over the previous
> competitions with moderate success. By looking into the server files I
> somewhere found that one can turn on torque feedback to joints. According to
> Sander, there were some problems with a crashing server when using this
> feedback, which should be fixed by now. So perceiving the torque may be
> possible, but as usual it is not documented how. Furthermore I also had a
> discussion with Hedayat and he meant that ode suggests controlling motors by
> speeds. But he also suggested to bring up a discussion on the mailing list
> about this, because he also was not completely sure about it.
> Since I'm not a developer of the server, I would suggest to write to the
> simspark mailing list for more information about this topic.
>
> Best regards,
> Stefan
>
> Best regards
>
> Dieter
>
>
>
>
>
>
>
>
>
> Am 04.09.12 13:21, schrieb Stefan Glaser:
>
> Hello Mr. Burkhard,
>
> nice to hear, that you took advantage in using our code. I'm always eager to
> get some feedback to our framework.
>
> As Klaus and Yuan pointed out, you can use the trainer/monitor protocol to
> control the players, the ball and the playmodes of the server. Since it is
> the monitor protocol, you should be able to get any position and orientation
> to any object on the server by parsing incoming messages to the trainer. If
> you just need the own position, "setSenseMyPos = true" as Yuan described
> could also be an option. Furthermore there is a possibility to turn off
> specific soccer rules. Unfortunately I can't remember where, yet.
>
> In my opinion an "exercise mode" doesn't make much sense. I don't like
> mixing up the agent code with the learning code. The
> trainer/monitor-protocol in combination with a special server configuration
> provides a very generic and independent interface for learning. Different
> learning scenarios need different setups. E.g. for walk-learning I may want
> to have a bigger field, to connect multiple agents in parallel, while for
> learning how to kick, I need the ball.
> I'm planing to put a list of all possible configuration parameters of the
> server and their meaning, as well as how to use the server in learning
> scenarios into the simspark-wiki. The time slot for this starts end of this
> month. In combination I may also try to improve configuration possibilities
> of the server with respect to learning. You will find news about this in the
> mailing list.
>
> Adding stiffness control would be very nice to have.
> I'm still looking forward to just have a torque control. Setting intended
> forces instead of target angular speeds. But I'm not sure if there is still
> development towards force-control.
>
> Wish you all the best,
> Stefan
>
>
> Am 04.09.2012 10:31, schrieb Yuan Xu:
>
> Dear Dieter and all,
>
> On Tue, Sep 4, 2012 at 10:08 AM, Hans-Dieter Burkhard <
> hd...@in...> wrote:
>
> Dear Klaus,
>
> thanks for the answers and the code - we will try it out! Hopefully you
> will
> hear still more from me :-)
>
>
> Thanks for your code, but I think 'excise mode' in server will help all
> other teams ( which do not use java), and it would be easy to use and
> functional out box.
>
>
> GPS even during work would make evaluation (e.g. fitness) easier. Maybe
> someone knows
> more about status?
>
> The vision perceptor can provide the global position, (setSenseMyPos in
> rsg/agent/nao/naoneckhead.rsg) I think it works similar as GPS, but it
> doesn't provide the direction of robot, which is also useful for evaluation.
>
>
> I cannot estimate the efforts for stiffness. It would bring simulation
> closer to reality at the lower
> levels (body control). Another approach in this direction would be
> measurement of energy consumption
> by the individual joints (how much force is needed). But may be that is
> even more complicated to simulate.
>
> We can simulate the stiffness by setting the maximum force of joint (this
> is easy in ODE), because the maximum currency of motor is determined by
> stiffness in real NAO, and for DC motor, output torque t = K * I, where I
> is currency and K is torque constant of the motor,  it can be found in the
> specification from manufacture.
>
>
>
> Battery simulation is nice as well for the higher control aspects (as we
> have it in 2D).
> Actually, for real robots the energy consumption depends not only on the
> amount of movements in general,
> but on clever designed energy saving motions (which may lead back to
> measurement of energy consumption at the joints).
>
>
> Actually I have already implemented stiffness and energy consumption of
> motors for my thesis. If you are interested in, I can make a branch for
> testing.
>
>
>
> Thank you once again and greetings from Croatia,
>
>
> Wish you nice days!
>
>
> Dieter
>
>
>
>
>
>
> Am 03.09.12 15:28, schrieb Klaus Dorer:
>
>   Dear Hans-Dieter,
>
> good to hear from you again!
>
> Some of the features you are asking for are already achievable with the
> trainer(monitor) protocol. We have implemented it this season and use it
> for machine learning purposes. I have attached the Java class doing the
> stuff. I think it should work with the ServerConnection class we published
> in our last source code release. A little usage example is attached below.
>
> With that you have access to what a referee can do through the monitor.
> I.e.
> - placing a player at any position at any time
> - placing the ball to any position at any time
> - dropping the ball to start a game (make sure to first drop ball and
> then beam a player close to it)
> - change playmode
>
> With respect to the "GPS" I weakly remember that it can be configured in
> the server to be added to player information in training mode. May be
> Stefan knows where exactly? At least after trainer beaming you know exactly
> where a player is.
>
> With respect to stiffness I am a bit uncertain. It sounds to me like
> being quite computational expensive although I really have no good insight
> into server simulation. When it comes to features that bring simulation
> closer to reality I would prefer things like energy simulation that also
> add value with respect to strategy.
>
> Greetings
> Klaus
>
> protected boolean tryToConnect()
> {
>      tce = new TrainerCommandExecutor(**IServerConnection.SERVER_IP);
>      if (!tce.isConnected()) {
>          return false;
>      }
>      return super.tryToConnect();
> }
>
> tce.beamBall(0, 0);
> tce.dropBall();
> tce.movePlayer(Team.LEFT, 2, x, y, 0.65f);
>
>
>
>
>
> Am 03.09.2012 14:07, schrieb Hans-Dieter Burkhard:
>
> Dear Klaus and Yuan,
>
> we at Humboldt University are interested to use the server for teaching
> at different levels
> of complexity, including Machine Learning. I have discussed it already
> with Yuan. Our
> first approach based on our Nao-Code ("Simple Soccer Agent") appeared to
> be of limited use
> because to many details were hidden for unexperienced users.
> Now we are preparing a new agent in JAVA (were some credits are given to
> Magma Offenburg),
> and first tests are very promising.
>
> It would be comfortable to have some “exercise mode” in the server with
> features like that:
> -    players can start immediately without any restrictions, i.e. no
> kick-off, no time limit, no kick-in etc.
> -    players can beam at any time
> -    a coach can place the ball to  any position
> -    a “GPS” informs about exact locations of players and ball (may be
> only the coach has access to the GPS)
> -    (what more?)
> I don’t know, how far such features can be already realized by
> configurations. Anyway it would be nice
> to have it “at once” as a special mode.
>
> What do you think?
>
>
> Another topic:
> To come closer to real robots, it would be nice to control stiffness –
> what about that?
>
> Best regards
>
> Dieter
>
>
>
>
>
> Am 03.09.12 11:40, schrieb Yuan Xu:
>
> Hi Klaus,
>
> I have one more suggestion, hope it is not too late.
>
> I would like to include the battery and power consuming (I have
> already implemented),
> since limited resource exists in all real world application,
> and furthermore it will (hopefully) restricts the ability of one
> robot, e.g. dribbling ball all the time.
>
> On Fri, Aug 31, 2012 at 4:08 PM, Klaus Dorer
> <kla...@hs...
> <mailto:klaus.dorer@hs-**offenburg.de<kla...@hs...>>>
> wrote:
>
>      Hello,
>
>      thanks to those who have contributed to the discussion of new
> features
>      for 2013 3D simulation league. If you want to add anything you
>      should do
>      so within the very next days.
>
>      The technical committee is then starting internal discussion on
>      which of
>      the suggested features to use. We try to have decisions and
>      specifications ready in October.
>
>      Greetings
>      Klaus
>
> ------------------------------**------------------------------**
> ------------------
>      Live Security Virtual Conference
>      Exclusive live event will cover all the ways today's security and
>      threat landscape has changed and how IT managers can respond.
>      Discussions
>      will include endpoint security, mobile security and the latest in
>      malware
>      threats. http://www.accelacomm.com/jaw/**
> sfrnl04242012/114/50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>      ______________________________**_________________
>      Sserver-three-d mailing list
> Sserver-three-d@lists.**sourceforge.net<Sse...@li...>
> <mailto:Sserver-three-d@lists.**sourceforge.net<Sse...@li...>
> https://lists.sourceforge.net/**lists/listinfo/sserver-three-d<https://lists.sourceforge.net/lists/listinfo/sserver-three-d>
>
>
>
>
> --
> Best Regards,
>
> Xu, Yuan
>
>
> ------------------------------**------------------------------**------------------
>
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions
> will include endpoint security, mobile security and the latest in
> malware
> threats.http://www.accelacomm.**com/jaw/sfrnl04242012/114/**50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>
>
> ______________________________**_________________
> Sserver-three-d mailing list
> Sserver-three-d@lists.**sourceforge.net<Sse...@li...>
> https://lists.sourceforge.net/**lists/listinfo/sserver-three-d<https://lists.sourceforge.net/lists/listinfo/sserver-three-d>
>
>
>
>
>
>
>

[simspark-devel] SimSpark 0.2.3 and RCSSServer3D 0.6.6 are available now!

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

Dear all,
Simspark 0.2.3 and rcssserver3d 0.6.6 are released and you can
download them from [1]. Since these packages are going to be used in
RoboCup 2012, please use them as soon as possible.

Please note that rcssserver3d 0.6.6 requires simspark 0.2.3 and will 
*not* work with previous versions of simspark. Therefore, you should 
install simspark 0.2.3 and then rcssserver3d 0.6.6.
It is highly recommended to remove previous versions
of simspark and rcssserver3d before installing the latest versions.
Also, remove your ~/.simspark directory before running the latest
version. Notice that, since simspark 0.2.2, spark.rb is copied to
~/.simspark in the first run, and ~/.simspark/spark.rb is used in
subsequent runs.

More detailed release notes of rcssserver3d and simspark follows:

SimSpark 0.2.3
==================
Finally, a new release of simspark has come! The most exciting feature 
of this
release is probably the multi-threaded agent control (thanks to Andreas from
RoboCanes for the initial patch). Previously, this part of the code was
sequential even in multi-threaded mode, but now it can manage several 
agnets in
parallel which should (hopefully!) increase performance. Besides, there are
a number of compilation and bug fixes here and there and also better Windows
support. Small enhancements are also available. You can find more 
details below:

- Multi-threaded Agent Control
  -- AgentControl multi-threaded implementation added and enabled by 
default.
     It can be disabled using $threadedAgentControl variable inside 
spark.rb.
- OpenGL System can now request the end of simulation (makes it possible to
   close spark monitor's window to quit!
- The location of init scripts (e.g. zeitgeist.rb) can now be specified 
using
   --init-script-prefix (you still can put most of the scripts and data 
files
   like rsg/ directory inside your ~/.simspark/ instead).
- Compilation fixes
- Support more recent Ruby versions
- Windows Compilation fixes, and few enhancements for better Windows support
- Support for building Windows binary in GNU/Linux using Mingw32
  -- Notice: Windows related changes were already used in 0.2.2 simspark
     installer
- Several bug fixes

Thanks to Yuan Xu and Sander van Dijk for their contributions in this 
release.

RCSSServer3D 0.6.6
====================
It's time for a new release! This release comes with a number of bug 
fixes and
several minor enhancements here and there. Now, you can run the server for
two complete halves. Teams now change their sides in the second half. Also,
automatic kick off and automatic quit modes are added. Field dimensions are
also increased to 20x30 meters, and free kick distance is 2.0 meters now.
More detailed information about this release follows:

* Rule Changes:
  - automatic referee now enforces rules whenever players are permitted to
    play, rather than only in playon play mode.
  - it is no longer possible to score directly from kick off, the ball 
should
    at least touch another player before going into the goal
  - in kickoff playmode, the kicker cannot touch the ball again until 
another
    player touches it.

* Field/Dimension Changes:
  - New dimensions: 20x30
  - Free kick distance: 2.0
  - Corner kick position: in the middle point between goal and corner of 
the
    field, to facilitate faster corner kicks.
  - Nao's foot height is now 0.02 rather than 0.03. Ankle's position 
changed
    accordingly

* Several Bug fixes. Some notable ones are:
  - Penalty lines and middle circle are now visible at their actual position
    (Thanks to Marcus for his bug report, and Sander).
  - Fixed a small bug in parsing move paramter (Thanks to Andreas 
Seekircher)
  - Fixed a mistake which prevented from touch group rules to be applied 
at all
  - Fixed a small bug in goal counting which cause this function to always
    count a goal when ball moved out of the field

* Enhance Automatic Kickoff Support:
  - Changed default value of 'WaitBeforeKickOff' to 30, since 5 seconds
    is too small for any team to start.
  - WaitBeforeKickOff is now calculated from when the first agent connects
    rather than from the beginning of the before kickoff playmode (when the
    simulator is started)
  - A game can be started with kick off for the left team, or using 
'coin toss'
    to determine which team should start the game. CoinTossForKickOff 
variable
    in naosoccersim.rb can be used to change the behavior. It is disabled
    by default.

* Enhance Support for 'Second Half':
  - Automatic Kick Off mode assigns Kick off to the correct team in the 
second
     half
  - Change teams' sides in the second half if enabled (enabled by 
default). It
     can be disabled using ChangeSidesInSecondHalf variable in 
naosoccersim.rb.

* Automatic Quit:
  - In Automatic Quit mode rcsssever3d shuts down automatically when the 
game
    is over. It is disabled by default but can be enabled using 
'AutomaticQuit'
    variable in naosoccersim.rb

* Other Enhancements:
  - The location of init scripts (e.g. zeitgeist.rb) can now be 
specified using
   --init-script-prefix (you still can put most of the scripts and data 
files
   like rsg/ directory inside your ~/.simspark/ instead).
  - Better Windows support
  - Support creating Windows binaries under Linux using MinGW

Thanks to all MC members who contributed to this release,
Hedayat Vatankhah
RCSServer3D Maintenance Committee

[1] http://sourceforge.net/projects/simspark/files