simspark-devel — Discussion about Spark development

Re: [simspark-devel] SimSpark Gui, Re-/Initializing Spark

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

Hi Patrick,



/*Patrick Geib <Pat...@on...>*/ wrote on Fri, 20 Apr 2012 
13:29:39 +0200:
> Hi,
> Im currently on the finishing line for the project. There are only two 
> things left to do: Loading plugins als dynamic libraries and making 
> the project build like the others (besides, i named the Gui-Core 
> library "Carbon"... Apple cant keep the name forever i hope^^).
> Except for these points the Wiki documentation is quite complete right 
> now (i will add some tutorials and a video introduction to the Gui 
> though).
That's great. Specially that it is documented. :)


>
> The problem with the SimSpark handling was only avoidable, not 
> solveable... At the moment there can only be one instance of SimSpark, 
> so there is only one ruby "context". There is indeed a way to simulate 
> a second ruby context by using a wrapper that forwards every command 
> and access to a namespace in the main context... but this would 
> require a lot of changes in the core libraries... . Anyway, after a 
> few restrictions, this is not the main problem anymore. The only major 
> drawback that remains is that its impossible to reset SimSpark 
> completely so you cannot run different simulations in the Gui without 
> restarting it completely (for example a Soccer Simulation and 
> afterwards a Mars-Rover Simulation).
> I will add an entry to the Wiki that points out which parts of 
> SimSpark would need a rework to make this possible. Sadly, this would 
> be a LOT of parts, because many of the libs and objects are not safely 
> removeable from the Scene Graph.
Thanks for the description, and for adding the info to the wiki.


>
> For the final upload i have two questions:
> 1) I used the most recent C++ standard for my code, which means i for 
> example have double closing template brackets ( 
> "shared_ptr<QList<int>> myList;" ) and used the auto keyword ( " for 
> (auto it = myList.begin(); it != myList.end)=; it++)... " ). If this 
> should be a problem for older compilers i would nee to change this 
> before uploading. I hope w are not using 10years+ old compilers ;) ?
Hmmm... which version of the GCC is the first version which supports both?
Anyway, your code is completely separate from rcssserver3d and simspark, 
right? If it make simspark and rcssserver3d not supporting older 
compilers, it might be considered an issue for a while. Do you know what 
is the first Ubuntu version which supports this syntax? (since most of 
RoboCuppers are using Ubuntu AFAIK). But if it is all new code, I think 
that's fine!


> 2) To be able to control the scripts externally, i changed many of the 
> scripts (for example spark.rb). I added for example log functions in 
> the spark script and made the rcssserver3d script extendable by 
> additional scripts. I could simply upload the changed scripts as 
> replacements for the old ones (in the new branch), or upload both of 
> them with different names. For the default simulation (NaoSoccer) the 
> new versions of the scripts behave just like the old ones so replacing 
> should be no problem.
If it doesn't affect the default simulation, IMHO it is fine to update 
the current scripts.

>
> I hope ill be finished in two weeks and put it in a new branch of the 
> SVN together with the modifications and the Bullet physics 
> implementation of Peter.
It's great to hear that we have Bullet support too! :)

Good luck,
Hedayat

>
> Best Regards,
> Patrick
>
> Am 18.04.2012 21:53, schrieb Hedayat Vatankhah:
>>
>> Hi Patrick,
>>
>> Sorry for the *long* silence about your email. Can I ask what 
>> happened finally? :P
>>
>> Anyway, about the ruby script engine: AFIAK, there are no 'contexts' 
>> there, so all Ruby calls are using the same ruby context. And if I 
>> remember correctly, you should not access it at the same time from 
>> separate threads. Besides, since there is only one context (if it is 
>> correct!), you might be unable to have separate instances of the 
>> system simultaneously (consider if two different instances want to 
>> assign different values to a single variable). Therefore, you might 
>> need to somehow! run different instances of Ruby engine, or maybe 
>> using a 'namespace' concept to create separate contexts for different 
>> instances of the Spark engine inside a single Ruby context. I wonder 
>> if you've already passed this problem! :D And I'm interested to know 
>> about the final solution in that case. :)
>>
>>
>> I'll try to read all the related wiki pages you've created in a few 
>> days. :P
>>
>>
>> Regards,
>>
>> Hedayat
>>
>>
>> /*Patr ick Geib <Pat...@on...>*/ wrote on Tue, 20 Dec 2011 
>> 12:50:00 +0900:
>>> Hi,
>>>
>>> Im continuing on the SimSpark Gui Project but i think i *might* have hit
>>> a roadblock. I hope it is nothing or at least solvable without changing
>>> zeitgeist too much, so heres the problem:
>>>
>>> The Gui is currently designed to start and watch different threads that
>>> might either be internal or external monitors, agents and (one) server.
>>> The concept is meant to define new Simulation Setups containing those
>>> threads, some scripts modifying the execution of the threads (e.g.
>>> loading NaoSoccer etc.) and loading different GuiPlugins for each
>>> Simulation without having to write new compilable projects or edit
>>> script files. So i wrote a more general class SimSpark derived from
>>> Spark (just als those in rcssserver3d etc), where i add resource
>>> locations and scripts at runtime. So far, executing the server as
>>> separate thread in the gui works without a problem.
>>> But now i need to start, stop and/or restart multiple instances of
>>> SimSpark at once or after another, for example restarting the Core or
>>> initializing two SimSpark objects at the same time for a distict server
>>> and a monitor. But zeitgeist crashes when it is initialized again after
>>> being closed, because there are some static properties and leftover
>>> references to the previous Core. While rsgedit avoids this problem by
>>> never actually removing its single Spark instance (but resetting it),
>>> this wont work in my case since i need more than one instance at the
>>> same time. I can seek and replace static references and objects in
>>> zeitgeist, oxygen and kerosin, but i dont know if the script interface
>>> is able to deal with multiple simulation/script servers anyway. In the
>>> ruby wrappers there dont seem to be any distict Ruby-Contexts but only
>>> one single interface. If so, is it possible to wrap the ruby calls
>>> without changing the whole core? Or will the interface work with
>>> different Script-Servers accessing it? I just need to know this before i
>>> attempt to rewrite parts of zeitgeist and oxygen.
>>>
>>> Of course there is the possibility of integrated monitors and agents in
>>> the server itself. But i definitely want to support external processes
>>> and (gui-)internal threads first. When not relying on the direct control
>>> of the core but using the tcp/ip commands first i can cover two kinds of
>>> execution (as thread in the gui, as process observed by the gui) at the
>>> same time. I dont know if i have time to implement both server-internal
>>> and external monitors and agents right away, so i want to stick with the
>>> more important kind. This way, both observing and controlling externally
>>> started processes (rcssagent3d.exe etc..), and integrating them into the
>>> gui to display and debug them in one window would be possible.
>>>
>>> Please tell me if you have some advice on how to deal with the
>>> situation. Also, you might want to have a look at
>>> http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface
>>> . If you have concerns ideas and/or wishes, you can always comment or
>>> edit on the project page describing the main features of the gui. It is
>>> meant to be used someday after all, so feedback from those who might
>>> want to use (and extend!) it is always appreciated xD
>>>
>>> Best regards,
>>> Patrick Geib
>>>
>>> ------------------------------------------------------------------------------
>>> Write once. Port to many.
>>> Get the SDK and tools to simplify cross-platform app development. Create
>>> new or port existing apps to sell to consumers worldwide. Explore the
>>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>>> http://p.sf.net/sfu/intel-appdev
>>> _______________________________________________
>>> Simspark Generic Physical MAS Simulator
>>> simspark-devel mailing list
>>> sim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>

Re: [simspark-devel] Joint feedback with multithreaded ODE

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

Hi Sander!
Thanks a lot :)
Regards,
Hedayat

/*Sander van Dijk <sgv...@gm...>*/ wrote on Wed, 18 Apr 2012 
21:43:39 +0100:

> Hi Hedayat,
>
> I think I have been using this for a long time now and haven't had
> problems. I will double check tomorrow whether I really have (forgot
> about this a bit as we have not used the joint feedback since last
> year) and I'll let you know.
>
> Sander
>
> On Wed, Apr 18, 2012 at 9:04 PM, Hedayat Vatankhah<hed...@gm...>  wrote:
>> Hi Sander,
>>
>> Any updates on this issue? And what is the latest status? Do you still need
>> some testing?
>>
>> We are going to have a new release soon, so it should work fine with
>> multi-threaded ode.
>>
>> Regards,
>>
>> Hedayat
>>
>>
>> Sander van Dijk<sgv...@gm...>  wrote on Mon, 25 Jul 2011 20:56:32
>> +0100:
>>
>> Hello fellow developers,
>>
>> As I mentioned on the 3D mailing list, requesting joint feedback (which for
>> instance can be used to determine energy consumption) currently creates
>> instability when using multithreaded ODE. I have had a look at it, and
>> believe that with the attached file this should now work correctly. Before
>> going further, I'd like to ask you to give it a test. Replace
>> ode/src/step.cc with this file in the ode-0.11.1-tbb source directory,
>> remake and install ODE and remake and install spark. I have enabled joint
>> feedback in the SVN trunk, so perform an update of that first. If you need
>> to (re)configure ODE, make sure to use the --enable-malloc flag.
>>
>> It didn't work if you get agents exploding all over the place (with a large
>> number of agents, it won't happen with just 1). Please let me know. I will
>> then also make a SF project to maintain it.
>>
>> Sander
>>
>>
>> --
>> Adaptive Systems Research Group
>> Department of Computer Science
>> University of Hertfordshire
>> United Kingdom
>>
>>
>> ------------------------------------------------------------------------------
>> Storage Efficiency Calculator
>> This modeling tool is based on patent-pending intellectual property that
>> has been used successfully in hundreds of IBM storage optimization engage-
>> ments, worldwide.  Store less, Store more with what you own, Move data to
>> the right place. Try It Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>
>>
>>
>> _______________________________________________
>> Simspark Generic Physical MAS Simulator
>> simspark-devel mailing list
>> sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>

Re: [simspark-devel] Joint feedback with multithreaded ODE

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

Hi Hedayat,

I think I have been using this for a long time now and haven't had
problems. I will double check tomorrow whether I really have (forgot
about this a bit as we have not used the joint feedback since last
year) and I'll let you know.

Sander

On Wed, Apr 18, 2012 at 9:04 PM, Hedayat Vatankhah <hed...@gm...> wrote:
> Hi Sander,
>
> Any updates on this issue? And what is the latest status? Do you still need
> some testing?
>
> We are going to have a new release soon, so it should work fine with
> multi-threaded ode.
>
> Regards,
>
> Hedayat
>
>
> Sander van Dijk <sgv...@gm...> wrote on Mon, 25 Jul 2011 20:56:32
> +0100:
>
> Hello fellow developers,
>
> As I mentioned on the 3D mailing list, requesting joint feedback (which for
> instance can be used to determine energy consumption) currently creates
> instability when using multithreaded ODE. I have had a look at it, and
> believe that with the attached file this should now work correctly. Before
> going further, I'd like to ask you to give it a test. Replace
> ode/src/step.cc with this file in the ode-0.11.1-tbb source directory,
> remake and install ODE and remake and install spark. I have enabled joint
> feedback in the SVN trunk, so perform an update of that first. If you need
> to (re)configure ODE, make sure to use the --enable-malloc flag.
>
> It didn't work if you get agents exploding all over the place (with a large
> number of agents, it won't happen with just 1). Please let me know. I will
> then also make a SF project to maintain it.
>
> Sander
>
>
> --
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>
>
>
> _______________________________________________
> 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] Joint feedback with multithreaded ODE

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

Hi Sander,

Any updates on this issue? And what is the latest status? Do you still 
need some testing?

We are going to have a new release soon, so it should work fine with 
multi-threaded ode.

Regards,

Hedayat


/*Sander van Dijk <sgv...@gm...>*/ wrote on Mon, 25 Jul 2011 
20:56:32 +0100:
> Hello fellow developers,
>
> As I mentioned on the 3D mailing list, requesting joint feedback 
> (which for instance can be used to determine energy consumption) 
> currently creates instability when using multithreaded ODE. I have had 
> a look at it, and believe that with the attached file this should now 
> work correctly. Before going further, I'd like to ask you to give it a 
> test. Replace ode/src/step.cc with this file in the ode-0.11.1-tbb 
> source directory, remake and install ODE and remake and install spark. 
> I have enabled joint feedback in the SVN trunk, so perform an update 
> of that first. If you need to (re)configure ODE, make sure to use the 
> --enable-malloc flag.
>
> It didn't work if you get agents exploding all over the place (with a 
> large number of agents, it won't happen with just 1). Please let me 
> know. I will then also make a SF project to maintain it.
>
> Sander
>
>
> -- 
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!http://www.accelacomm.com/jaw/sfnl/114/51427378/
>
>
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel

Re: [simspark-devel] SimSpark Gui, Re-/Initializing Spark

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

Hi Patrick,

Sorry for the *long* silence about your email. Can I ask what happened 
finally? :P

Anyway, about the ruby script engine: AFIAK, there are no 'contexts' 
there, so all Ruby calls are using the same ruby context. And if I 
remember correctly, you should not access it at the same time from 
separate threads. Besides, since there is only one context (if it is 
correct!), you might be unable to have separate instances of the system 
simultaneously (consider if two different instances want to assign 
different values to a single variable). Therefore, you might need to 
somehow! run different instances of Ruby engine, or maybe using a 
'namespace' concept to create separate contexts for different instances 
of the Spark engine inside a single Ruby context. I wonder if you've 
already passed this problem! :D And I'm interested to know about the 
final solution in that case. :)


I'll try to read all the related wiki pages you've created in a few days. :P


Regards,

Hedayat


/*Patrick Geib <Pat...@on...>*/ wrote on Tue, 20 Dec 2011 
12:50:00 +0900:
> Hi,
>
> Im continuing on the SimSpark Gui Project but i think i *might* have hit
> a roadblock. I hope it is nothing or at least solvable without changing
> zeitgeist too much, so heres the problem:
>
> The Gui is currently designed to start and watch different threads that
> might either be internal or external monitors, agents and (one) server.
> The concept is meant to define new Simulation Setups containing those
> threads, some scripts modifying the execution of the threads (e.g.
> loading NaoSoccer etc.) and loading different GuiPlugins for each
> Simulation without having to write new compilable projects or edit
> script files. So i wrote a more general class SimSpark derived from
> Spark (just als those in rcssserver3d etc), where i add resource
> locations and scripts at runtime. So far, executing the server as
> separate thread in the gui works without a problem.
> But now i need to start, stop and/or restart multiple instances of
> SimSpark at once or after another, for example restarting the Core or
> initializing two SimSpark objects at the same time for a distict server
> and a monitor. But zeitgeist crashes when it is initialized again after
> being closed, because there are some static properties and leftover
> references to the previous Core. While rsgedit avoids this problem by
> never actually removing its single Spark instance (but resetting it),
> this wont work in my case since i need more than one instance at the
> same time. I can seek and replace static references and objects in
> zeitgeist, oxygen and kerosin, but i dont know if the script interface
> is able to deal with multiple simulation/script servers anyway. In the
> ruby wrappers there dont seem to be any distict Ruby-Contexts but only
> one single interface. If so, is it possible to wrap the ruby calls
> without changing the whole core? Or will the interface work with
> different Script-Servers accessing it? I just need to know this before i
> attempt to rewrite parts of zeitgeist and oxygen.
>
> Of course there is the possibility of integrated monitors and agents in
> the server itself. But i definitely want to support external processes
> and (gui-)internal threads first. When not relying on the direct control
> of the core but using the tcp/ip commands first i can cover two kinds of
> execution (as thread in the gui, as process observed by the gui) at the
> same time. I dont know if i have time to implement both server-internal
> and external monitors and agents right away, so i want to stick with the
> more important kind. This way, both observing and controlling externally
> started processes (rcssagent3d.exe etc..), and integrating them into the
> gui to display and debug them in one window would be possible.
>
> Please tell me if you have some advice on how to deal with the
> situation. Also, you might want to have a look at
> http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface
> . If you have concerns ideas and/or wishes, you can always comment or
> edit on the project page describing the main features of the gui. It is
> meant to be used someday after all, so feedback from those who might
> want to use (and extend!) it is always appreciated xD
>
> Best regards,
> Patrick Geib
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel

Re: [simspark-devel] [Rc-ss3d-tc] Immediate help is needed for preparation!

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

Hi all,

The following is a brief summary and my recommendations on proposed changes.

Increasing ball mass increases kick distance due to the ball having more
momentum and rolling farther when it hits the ground.  Increasing the ball
size seems to have a similar effect.  Decreasing the foot height also seems
to allow for a small gain in distance and added height due to it being a
little easier to get under the ball.

I'm not in favor of increasing the ball mass or size too much as things
begin to look unnatural.  With a heavier ball the effect of friction is
reduced and the ball seems to roll farther than it probably should.  As the
ball size increases it starts to look disproportionately big compared to
the robot and also rolls farther than what looks normal.  Tests I did also
suggested that a larger ball actually produced less height although I was
not optimizing for height (just distance).  If either ball mass or size is
to be increased I would only do so by a little bit, and err on the side of
caution, as such changes could produce odd looking physics and have a
negative effect on game play.

I'm not opposed to decreasing the foot height.  The foot of the simulated
Nao is already different from the real Nao as it is a box and not a curved
and sloped downward surface like the real Nao.  Aldebaran's specs
officially list the height of the foot as 45.19mm but this is the distance
from the bottom of the foot to the ankle joint.  The actual Nao foot is
sloped such that at its shortest point (located at the front and center of
the foot ) the height is only 20mm (I just measured this).  Currently the
height of the box-shaped Nao foot in simulation is 30mm.  My experiments
showed a small improvement in kicking distance and height when decreasing
the height of the foot.  As such a change doesn't potentially adversely
affect the physics of the ball I think it might be a viable option.

One question I would ask is do we really need to make changes?  My
experiments show that with the current state of the simulator one can
already kick 12m,  which is over half the length of the field, and also
kick 2.5X the height of a Nao (although this was done in a controlled
situation of beaming the ball in front of the agent).  I would expect teams
to get better at kicking for this year's upcoming competition, which is a
focus of our team, in a similar way to which walks have progressed and
become faster over the past couple of years.

Another suggestion that has been brought up is increasing the size of the
field.  I'm not really in favor of of this as such a change will make it
harder to win the ball on defense, and then transition forward to score on
offense, which I feel is an important characteristic for the sport and
excitement of soccer; especially if we are already debating ways to
possibly increase the length of kicking relative to the size of the field.
I believe the average time it takes for the ball to travel the length of
the field in the 3D simulation league is longer than many of the other
leagues (certainly longer than real soccer), and I would rather not add to
this time.  If we do increase the size of the field I think we should also
add more players to keep a similar ratio of players to open space.

Regards,
Patrick





On Tue, Mar 20, 2012 at 5:24 AM, Hedayat Vatankhah <hed...@gm...>wrote:

>  Hi Klaus, Patrick and others!
>
> Thanks a lot for your efforts. We can increase the ball size. However,
> about the foot height, I'd personally prefer to have our robot dimensions
> follow the real Nao. If I have understood correctly, decreasing the foot
> height should have the same effect as increasing the ball size. So, isn't
> it enough to slightly increase the ball size (without having an unusually
> big ball)? And it would be great if we can send the initial suggestion to
> sserver-three-d mailing list today. What do you suggest?
>
>
>  Regards,
>
> Hedayat
>
> *Klaus Dorer <kla...@hs...> <kla...@hs...>*wrote on Fri, 09 Mar 2012 07:02:14 +0100:
>
> Hi Patrick,
>
> thanks a lot for your work!
>
> Stefan has also evaluated some settings. Below his findings.
> His conclusions are quite close to yours. Increasing ball mass seems odd,
> at least as long as friction is kept the same. He also suggests only
> marginal increase in ball size.
> The only difference is with respect to foot height. He suggests to shrink
> the foot.
> In my oppinion this would allow more flexibility, i.e. the initial
> situation does not require too much precision or put in other words,
> kicking high from various ball distances and situations can be achieved.
>
>
> Greetings
> Klaus
>
> Stefan:
>
> The magmaOffenburg agent is capable of two different forward kicks, one
> that is wider, like a normal kick, and one that is faster, called FastKick,
> that is more like rising the leg while standing. It's hard to describe, but
> the FastKick should basically lift the ball up, but less wide.
>
> Results:
> 1) foot height: 1.5cm, ball radius: 4.2cm (old)
>     - 13g (old/2):
>         - Kick: ball hardly leaves the ground
>         - FastKick: shoulder to head height (relatively reliable)
>     - 26g (old):
>         - Kick: ball hardly leaves the ground
>         - FastKick: head height (reliable)
>     - 39g (old+13):
>         - Kick: ball hardly leaves the ground
>         - FastKick: head height (reliable)
> 2) foot height: 1.5cm, ball radius: 5.2cm
>     - 13g (old/2):
>         - Kick: knee to hip height - it is easily able to push the foot
> fast enough below the ball, but then the ball doesn't get much momentum and
> simply drops down again (like a trick kicker, balancing the ball)
>         - FastKick: hip height - it isn't realy able to get below the
> ball. The FastKick accelerates the leg directly at the ball and the ball
> seems to take the acceleration easier when it is leighter.
>     - 26g (old):
>         - Kick: same behavior as with 13g
>         - FastKick: head height (reliable)
>     - 39g (old*2):
>         - Kick: ball hardly leaves the ground
>         - FastKick: head height (reliable)
>
> In general with a heighter foot, like e.g. 2cm, our kicks aren't realy
> able to get below the ball. If I rise the size of the ball radius by
> another 1cm (to 6.2cm), the ball slowly is as high as the knee and it
> happens somethimes that it touches the ball with its knee. At that size our
> kicks are also not realy capable any more to kick the ball appropriately.
> With some tweaks it may well be possible to kick it better, but at that
> size it also looks strange...
>
> Overall I realized that the weight of the ball has less impact on if it's
> high kickable. On the other hand, the size of the ball has less impact on
> the kickable distance.
> The following observations were made:
> - if the ball weight is reduced, the friction has a higher impact on the
> ball's speed, reducing possible kick distances drastically. If it is
> enlarged, the friction has less impact on the ball's speed, but it quickly
> results in an odd ball movement. It is rolling very long and stopping too
> slow.
> - If the ball gets too big, it is hard to get the foot of the agent
> stretched below the ball in such a way that it kicks proper off the ground.
> But as logical consequence, it has a bit less friction and gets farer.
> - If the ball is bigger, it is easier to kick in different directions
>
> After several hours ot testing I think that both values for the ball are
> well balanced. According to wikipedia, a soccer ball has a radius of around
> 10cm. We use 4.2cm, wich is around half the size, but I think we have to
> consider more the ratio of foot height to ball radius. We have a robot that
> is 1/3 of the size of a human, so it should get around 1/3 of the foot
> height. If I take a rough estimation of the height of the box of my
> personal foot, I would say it's on average around 3cm in the front. With
> this, to change the foot height to a value between 1 to 1.5 cm sounds
> reasonable to me and the results also show that with a thinner foot around
> 1.5cm, kicking high is not the biggest problem any more, even without
> changing the ball parameter too much.
>
> The kick distance is more problematic. Wikipedia says that the
> international ball weight is above 400g. We currently have 26g... As I sad,
> rising the ball's weight is not really the best option as long the field
> friction is kept the same. We may be able to adjust the values slightly,
> e.g. a ball radius around 5cm and a weight around 30g, to make a step
> towards more distance in kicking, but I would need to make some other
> experiments to fine tune my suggestion for real values. In the above
> experiments with 5.2cm radius and 39g weight, the ball movement was already
> quite odd and the gain in distance was from initially 4.5m to around 9m -
> not even half the field.
>
> In general the results are just my opinion and other teams may well be
> able to kick higher and/or wider with the same parameters. My suggestion
> with respect to well balanced values for foot height, ball radius and
> weight are:
> - foot height: 1 to 1.5cm
> - ball radius: 4.5 to 5cm
> - ball weight: the same
>
> The suggestion to the field size is hard. I would suggest to adapt to a
> field size of 1/3 of the internaltional commen field size for humans. This
> would be around 1.75 times the current size.
>
> The extension of the HipYawPitch to a range of -120 to 60 could be an
> option, since it fits better to the human leg range. Although in my opinion
> the above range is a bit too much and a change in the HipYawPitch itself is
> not enough. If we allow for a wider range here, we also need to adjust the
> range of the other two hip joints to allow the intended leg-freedom for
> kicking. But, over the last months I also came to the conclusion that the
> Nao is allready quite flexible and this kind of leg-feedom doesn't bring
> too much benefit. We have kicks going to the right, left, front and back if
> the agent is standing still. I could also come up with kicks in e.g. 10
> degrees steps, but as long as I have to stand still, there is no real
> benefit in more kick directions. And if I can shoot while walking, I should
> walk better ;) Humans also often do a final step before kicking.
>
> So, I hope I could help you with my suggestions and thoughts to clarify
> the values for the upcomming events. If you need any further help or have
> some questions about my tests/thoughts, you are very welcome to ask.
>
>
> Am 08.03.2012 05:24, schrieb Patrick MacAlpine:
>
> Hi all,
>
> Based on the proposed changes to the 3D simulation competition,
> particularly that of kicking, I've optimized one of our kicks for
> distance through machine learning in order to create some benchmarks
> for how changes might affect things.  The following are numbers I've
> collected on optimizing a kick for which the ball is beamed to a set
> place in front of the agent.  While these numbers show what is
> possible in the server, we have made no attempt yet to integrate the
> kick into our agent such that it is able to walk up to and position
> behind the ball before kicking it.  These numbers should be considered
> a lower bound for what is possible in the server, but with the caveat
> that it may be hard to achieve their full potential without very good
> positioning.
>
> Current server: Distance = 12m with a height of 1.4m+ (2.5X height of a
> Nao)
> Ball at half mass (.013): Distance = 8m with similar height above
> Ball at double mass (.052): Distance = 17m+ with similar height above
> Ball at +50% radius (.063): Distance = 16.5m with height greater than
> Nao although lower for longer kicks
> Foot Z half value (def $FootSizeZ  0.015): Distance = 12.5m with a
> height of 1.8m (3X height of a Nao)
>
> Based on the numbers above it seems that the goals of kicking above
> the height of a Nao (which was not something that the kicks learned
> were optimized for) as well as a distance 2/3 the length of half field
> (which is 10.5m if the field is increased by 50%) are already
> attainable.  Decreasing the mass of the ball will only decrease the
> length of kicks whereas increasing the mass of the ball would
> increase kick length.  This increase in distance with more mass occurs
> because once the ball hits the ground it rolls farther due to it
> having more momentum with greater mass.  I'm not really in favor of
> increasing the size of the ball as it starts to look a little silly
> with its larger size relative to the Nao and also a larger size will
> make it harder to get the ball by a goalie and score goals.  The
> larger ball rolls farther after hitting the ground when compared to
> the regular size ball, which is the reason for longer distance kicks,
> and makes me think that increasing the ball's radius also increases
> its mass. Decreasing the height of the foot seems to add a little
> distance as well as height to kicks but not by a considerable amount.
> If there are other changes to server parameters or combinations of
> server parameters that you wish to see benchmarked let me know and I
> will try to run them (time permitting).
>
> I'm OK with changes to the field size if it makes things better match
> the ratio of the real world, however if we do this I think we should
> also match in the number of players (11).  This way the amount of open
> space and area which individual players need to cover is also similar
> to the real world.
>
> I like the idea of adding heterogeneous players and think this would
> add a really interesting component to this year's competition.  We're
> currently exploring how modifying the dimensions of the robot model
> affects aspects of play, such as an agent's walking speed and
> stability, so as to find a range of parameter values that can be
> changed to create heterogeneous robot models without unbalancing
> gameplay.
>
> Regards,
> Patrick MacAlpine (UT Austin Villa)
>
>
>
> On Fri, Mar 2, 2012 at 1:57 PM, Hedayat Vatankhah<hed...@gm...><hed...@gm...>
> wrote:
>
> Dear all,
>
> As you can find in the attached document, TC has decided for a few
> adjustments/enhancements in the simulator for 2012 competitions. It is
> really nice if we can get these changes ready ASAP, so that we can use at
> least some of these changes in upcoming open competitions (IranOpen and
> DutchOpen). Sorry for being a little late :(.
>
> Anyway, according to the document, most of the changes are some parameter
> adjustments. We need your help to find some suitable values to suggest and
> request feedback from the teams. The primary parameters to adjust are:
> - ball size
> - ball weight
> - foot height
> - possibly foot shape if that is possible
>
> And the secondary parameters to adjust is then:
> - field size
>
>
> It's great if we can have some values in less than a week and then discuss
> those values in the list with all teams. Any help is highly appreciated!
> :)
>
> Thanks
>
> Hedayat
>
>
>
> ------------------------------------------------------------------------------
>
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>  _______________________________________________
> 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
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>

Re: [simspark-devel] [Rc-ss3d-tc] Immediate help is needed for preparation!

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

Hi Hedayat,

sorry, short in time.

I think that changing the foot height does not dramatically change most 
of the behaviors except kick. All motors and joints remain the same. If 
it helps to allow high kicking I am still in favor of reducing foot 
height instead of increasing ball size, which looks unnatural quickly, 
when the ball is up to the knee.

Greetings
Klaus

Am 20.03.2012 11:24, schrieb Hedayat Vatankhah:
> Hi Klaus, Patrick and others!
>
> Thanks a lot for your efforts. We can increase the ball size. However,
> about the foot height, I'd personally prefer to have our robot
> dimensions follow the real Nao. If I have understood correctly,
> decreasing the foot height should have the same effect as increasing the
> ball size. So, isn't it enough to slightly increase the ball size
> (without having an unusually big ball)? And it would be great if we can
> send the initial suggestion to sserver-three-d mailing list today. What
> do you suggest?
>
>
> Regards,
>
> Hedayat
>
>
> /*Klaus Dorer <kla...@hs...>*/ wrote on Fri, 09 Mar 2012
> 07:02:14 +0100:
>> Hi Patrick,
>>
>> thanks a lot for your work!
>>
>> Stefan has also evaluated some settings. Below his findings.
>> His conclusions are quite close to yours. Increasing ball mass seems
>> odd, at least as long as friction is kept the same. He also suggests
>> only marginal increase in ball size.
>> The only difference is with respect to foot height. He suggests to
>> shrink the foot.
>> In my oppinion this would allow more flexibility, i.e. the initial
>> situation does not require too much precision or put in other words,
>> kicking high from various ball distances and situations can be achieved.
>>
>>
>> Greetings
>> Klaus
>>
>> Stefan:
>>
>> The magmaOffenburg agent is capable of two different forward kicks,
>> one that is wider, like a normal kick, and one that is faster, called
>> FastKick, that is more like rising the leg while standing. It's hard
>> to describe, but the FastKick should basically lift the ball up, but
>> less wide.
>>
>> Results:
>> 1) foot height: 1.5cm, ball radius: 4.2cm (old)
>>     - 13g (old/2):
>>         - Kick: ball hardly leaves the ground
>>         - FastKick: shoulder to head height (relatively reliable)
>>     - 26g (old):
>>         - Kick: ball hardly leaves the ground
>>         - FastKick: head height (reliable)
>>     - 39g (old+13):
>>         - Kick: ball hardly leaves the ground
>>         - FastKick: head height (reliable)
>> 2) foot height: 1.5cm, ball radius: 5.2cm
>>     - 13g (old/2):
>>         - Kick: knee to hip height - it is easily able to push the
>> foot fast enough below the ball, but then the ball doesn't get much
>> momentum and simply drops down again (like a trick kicker, balancing
>> the ball)
>>         - FastKick: hip height - it isn't realy able to get below the
>> ball. The FastKick accelerates the leg directly at the ball and the
>> ball seems to take the acceleration easier when it is leighter.
>>     - 26g (old):
>>         - Kick: same behavior as with 13g
>>         - FastKick: head height (reliable)
>>     - 39g (old*2):
>>         - Kick: ball hardly leaves the ground
>>         - FastKick: head height (reliable)
>>
>> In general with a heighter foot, like e.g. 2cm, our kicks aren't realy
>> able to get below the ball. If I rise the size of the ball radius by
>> another 1cm (to 6.2cm), the ball slowly is as high as the knee and it
>> happens somethimes that it touches the ball with its knee. At that
>> size our kicks are also not realy capable any more to kick the ball
>> appropriately. With some tweaks it may well be possible to kick it
>> better, but at that size it also looks strange...
>>
>> Overall I realized that the weight of the ball has less impact on if
>> it's high kickable. On the other hand, the size of the ball has less
>> impact on the kickable distance.
>> The following observations were made:
>> - if the ball weight is reduced, the friction has a higher impact on
>> the ball's speed, reducing possible kick distances drastically. If it
>> is enlarged, the friction has less impact on the ball's speed, but it
>> quickly results in an odd ball movement. It is rolling very long and
>> stopping too slow.
>> - If the ball gets too big, it is hard to get the foot of the agent
>> stretched below the ball in such a way that it kicks proper off the
>> ground. But as logical consequence, it has a bit less friction and
>> gets farer.
>> - If the ball is bigger, it is easier to kick in different directions
>>
>> After several hours ot testing I think that both values for the ball
>> are well balanced. According to wikipedia, a soccer ball has a radius
>> of around 10cm. We use 4.2cm, wich is around half the size, but I
>> think we have to consider more the ratio of foot height to ball
>> radius. We have a robot that is 1/3 of the size of a human, so it
>> should get around 1/3 of the foot height. If I take a rough estimation
>> of the height of the box of my personal foot, I would say it's on
>> average around 3cm in the front. With this, to change the foot height
>> to a value between 1 to 1.5 cm sounds reasonable to me and the results
>> also show that with a thinner foot around 1.5cm, kicking high is not
>> the biggest problem any more, even without changing the ball parameter
>> too much.
>>
>> The kick distance is more problematic. Wikipedia says that the
>> international ball weight is above 400g. We currently have 26g... As I
>> sad, rising the ball's weight is not really the best option as long
>> the field friction is kept the same. We may be able to adjust the
>> values slightly, e.g. a ball radius around 5cm and a weight around
>> 30g, to make a step towards more distance in kicking, but I would need
>> to make some other experiments to fine tune my suggestion for real
>> values. In the above experiments with 5.2cm radius and 39g weight, the
>> ball movement was already quite odd and the gain in distance was from
>> initially 4.5m to around 9m - not even half the field.
>>
>> In general the results are just my opinion and other teams may well be
>> able to kick higher and/or wider with the same parameters. My
>> suggestion with respect to well balanced values for foot height, ball
>> radius and weight are:
>> - foot height: 1 to 1.5cm
>> - ball radius: 4.5 to 5cm
>> - ball weight: the same
>>
>> The suggestion to the field size is hard. I would suggest to adapt to
>> a field size of 1/3 of the internaltional commen field size for
>> humans. This would be around 1.75 times the current size.
>>
>> The extension of the HipYawPitch to a range of -120 to 60 could be an
>> option, since it fits better to the human leg range. Although in my
>> opinion the above range is a bit too much and a change in the
>> HipYawPitch itself is not enough. If we allow for a wider range here,
>> we also need to adjust the range of the other two hip joints to allow
>> the intended leg-freedom for kicking. But, over the last months I also
>> came to the conclusion that the Nao is allready quite flexible and
>> this kind of leg-feedom doesn't bring too much benefit. We have kicks
>> going to the right, left, front and back if the agent is standing
>> still. I could also come up with kicks in e.g. 10 degrees steps, but
>> as long as I have to stand still, there is no real benefit in more
>> kick directions. And if I can shoot while walking, I should walk
>> better ;) Humans also often do a final step before kicking.
>>
>> So, I hope I could help you with my suggestions and thoughts to
>> clarify the values for the upcomming events. If you need any further
>> help or have some questions about my tests/thoughts, you are very
>> welcome to ask.
>>
>>
>> Am 08.03.2012 05:24, schrieb Patrick MacAlpine:
>>> Hi all,
>>>
>>> Based on the proposed changes to the 3D simulation competition,
>>> particularly that of kicking, I've optimized one of our kicks for
>>> distance through machine learning in order to create some benchmarks
>>> for how changes might affect things.  The following are numbers I've
>>> collected on optimizing a kick for which the ball is beamed to a set
>>> place in front of the agent.  While these numbers show what is
>>> possible in the server, we have made no attempt yet to integrate the
>>> kick into our agent such that it is able to walk up to and position
>>> behind the ball before kicking it.  These numbers should be considered
>>> a lower bound for what is possible in the server, but with the caveat
>>> that it may be hard to achieve their full potential without very good
>>> positioning.
>>>
>>> Current server: Distance = 12m with a height of 1.4m+ (2.5X height of
>>> a Nao)
>>> Ball at half mass (.013): Distance = 8m with similar height above
>>> Ball at double mass (.052): Distance = 17m+ with similar height above
>>> Ball at +50% radius (.063): Distance = 16.5m with height greater than
>>> Nao although lower for longer kicks
>>> Foot Z half value (def $FootSizeZ  0.015): Distance = 12.5m with a
>>> height of 1.8m (3X height of a Nao)
>>>
>>> Based on the numbers above it seems that the goals of kicking above
>>> the height of a Nao (which was not something that the kicks learned
>>> were optimized for) as well as a distance 2/3 the length of half field
>>> (which is 10.5m if the field is increased by 50%) are already
>>> attainable.  Decreasing the mass of the ball will only decrease the
>>> length of kicks whereas increasing the mass of the ball would
>>> increase kick length.  This increase in distance with more mass occurs
>>> because once the ball hits the ground it rolls farther due to it
>>> having more momentum with greater mass.  I'm not really in favor of
>>> increasing the size of the ball as it starts to look a little silly
>>> with its larger size relative to the Nao and also a larger size will
>>> make it harder to get the ball by a goalie and score goals.  The
>>> larger ball rolls farther after hitting the ground when compared to
>>> the regular size ball, which is the reason for longer distance kicks,
>>> and makes me think that increasing the ball's radius also increases
>>> its mass. Decreasing the height of the foot seems to add a little
>>> distance as well as height to kicks but not by a considerable amount.
>>> If there are other changes to server parameters or combinations of
>>> server parameters that you wish to see benchmarked let me know and I
>>> will try to run them (time permitting).
>>>
>>> I'm OK with changes to the field size if it makes things better match
>>> the ratio of the real world, however if we do this I think we should
>>> also match in the number of players (11).  This way the amount of open
>>> space and area which individual players need to cover is also similar
>>> to the real world.
>>>
>>> I like the idea of adding heterogeneous players and think this would
>>> add a really interesting component to this year's competition.  We're
>>> currently exploring how modifying the dimensions of the robot model
>>> affects aspects of play, such as an agent's walking speed and
>>> stability, so as to find a range of parameter values that can be
>>> changed to create heterogeneous robot models without unbalancing
>>> gameplay.
>>>
>>> Regards,
>>> Patrick MacAlpine (UT Austin Villa)
>>>
>>>
>>>
>>> On Fri, Mar 2, 2012 at 1:57 PM, Hedayat
>>> Vatankhah<hed...@gm...>  wrote:
>>>> Dear all,
>>>>
>>>> As you can find in the attached document, TC has decided for a few
>>>> adjustments/enhancements in the simulator for 2012 competitions. It is
>>>> really nice if we can get these changes ready ASAP, so that we can
>>>> use at
>>>> least some of these changes in upcoming open competitions (IranOpen and
>>>> DutchOpen). Sorry for being a little late :(.
>>>>
>>>> Anyway, according to the document, most of the changes are some
>>>> parameter
>>>> adjustments. We need your help to find some suitable values to
>>>> suggest and
>>>> request feedback from the teams. The primary parameters to adjust are:
>>>> - ball size
>>>> - ball weight
>>>> - foot height
>>>> - possibly foot shape if that is possible
>>>>
>>>> And the secondary parameters to adjust is then:
>>>> - field size
>>>>
>>>>
>>>> It's great if we can have some values in less than a week and then
>>>> discuss
>>>> those values in the list with all teams. Any help is highly
>>>> appreciated! :)
>>>>
>>>> Thanks
>>>>
>>>> Hedayat
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Virtualization&  Cloud Management Using Capacity Planning
>>>> Cloud computing makes use of virtualization - but cloud computing
>>>> also focuses on allowing computing to be delivered as a service.
>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>>> _______________________________________________
>>>> Simspark Generic Physical MAS Simulator
>>>> simspark-devel mailing list
>>>> sim...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>>>>
>>> _______________________________________________
>>> 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] Immediate help is needed for preparation!

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

Hi Klaus, Patrick and others!

Thanks a lot for your efforts. We can increase the ball size. However, 
about the foot height, I'd personally prefer to have our robot 
dimensions follow the real Nao. If I have understood correctly, 
decreasing the foot height should have the same effect as increasing the 
ball size. So, isn't it enough to slightly increase the ball size 
(without having an unusually big ball)? And it would be great if we can 
send the initial suggestion to sserver-three-d mailing list today. What 
do you suggest?


Regards,

Hedayat


/*Klaus Dorer <kla...@hs...>*/ wrote on Fri, 09 Mar 2012 
07:02:14 +0100:
> Hi Patrick,
>
> thanks a lot for your work!
>
> Stefan has also evaluated some settings. Below his findings.
> His conclusions are quite close to yours. Increasing ball mass seems 
> odd, at least as long as friction is kept the same. He also suggests 
> only marginal increase in ball size.
> The only difference is with respect to foot height. He suggests to 
> shrink the foot.
> In my oppinion this would allow more flexibility, i.e. the initial 
> situation does not require too much precision or put in other words, 
> kicking high from various ball distances and situations can be achieved.
>
>
> Greetings
> Klaus
>
> Stefan:
>
> The magmaOffenburg agent is capable of two different forward kicks, 
> one that is wider, like a normal kick, and one that is faster, called 
> FastKick, that is more like rising the leg while standing. It's hard 
> to describe, but the FastKick should basically lift the ball up, but 
> less wide.
>
> Results:
> 1) foot height: 1.5cm, ball radius: 4.2cm (old)
>     - 13g (old/2):
>         - Kick: ball hardly leaves the ground
>         - FastKick: shoulder to head height (relatively reliable)
>     - 26g (old):
>         - Kick: ball hardly leaves the ground
>         - FastKick: head height (reliable)
>     - 39g (old+13):
>         - Kick: ball hardly leaves the ground
>         - FastKick: head height (reliable)
> 2) foot height: 1.5cm, ball radius: 5.2cm
>     - 13g (old/2):
>         - Kick: knee to hip height - it is easily able to push the 
> foot fast enough below the ball, but then the ball doesn't get much 
> momentum and simply drops down again (like a trick kicker, balancing 
> the ball)
>         - FastKick: hip height - it isn't realy able to get below the 
> ball. The FastKick accelerates the leg directly at the ball and the 
> ball seems to take the acceleration easier when it is leighter.
>     - 26g (old):
>         - Kick: same behavior as with 13g
>         - FastKick: head height (reliable)
>     - 39g (old*2):
>         - Kick: ball hardly leaves the ground
>         - FastKick: head height (reliable)
>
> In general with a heighter foot, like e.g. 2cm, our kicks aren't realy 
> able to get below the ball. If I rise the size of the ball radius by 
> another 1cm (to 6.2cm), the ball slowly is as high as the knee and it 
> happens somethimes that it touches the ball with its knee. At that 
> size our kicks are also not realy capable any more to kick the ball 
> appropriately. With some tweaks it may well be possible to kick it 
> better, but at that size it also looks strange...
>
> Overall I realized that the weight of the ball has less impact on if 
> it's high kickable. On the other hand, the size of the ball has less 
> impact on the kickable distance.
> The following observations were made:
> - if the ball weight is reduced, the friction has a higher impact on 
> the ball's speed, reducing possible kick distances drastically. If it 
> is enlarged, the friction has less impact on the ball's speed, but it 
> quickly results in an odd ball movement. It is rolling very long and 
> stopping too slow.
> - If the ball gets too big, it is hard to get the foot of the agent 
> stretched below the ball in such a way that it kicks proper off the 
> ground. But as logical consequence, it has a bit less friction and 
> gets farer.
> - If the ball is bigger, it is easier to kick in different directions
>
> After several hours ot testing I think that both values for the ball 
> are well balanced. According to wikipedia, a soccer ball has a radius 
> of around 10cm. We use 4.2cm, wich is around half the size, but I 
> think we have to consider more the ratio of foot height to ball 
> radius. We have a robot that is 1/3 of the size of a human, so it 
> should get around 1/3 of the foot height. If I take a rough estimation 
> of the height of the box of my personal foot, I would say it's on 
> average around 3cm in the front. With this, to change the foot height 
> to a value between 1 to 1.5 cm sounds reasonable to me and the results 
> also show that with a thinner foot around 1.5cm, kicking high is not 
> the biggest problem any more, even without changing the ball parameter 
> too much.
>
> The kick distance is more problematic. Wikipedia says that the 
> international ball weight is above 400g. We currently have 26g... As I 
> sad, rising the ball's weight is not really the best option as long 
> the field friction is kept the same. We may be able to adjust the 
> values slightly, e.g. a ball radius around 5cm and a weight around 
> 30g, to make a step towards more distance in kicking, but I would need 
> to make some other experiments to fine tune my suggestion for real 
> values. In the above experiments with 5.2cm radius and 39g weight, the 
> ball movement was already quite odd and the gain in distance was from 
> initially 4.5m to around 9m - not even half the field.
>
> In general the results are just my opinion and other teams may well be 
> able to kick higher and/or wider with the same parameters. My 
> suggestion with respect to well balanced values for foot height, ball 
> radius and weight are:
> - foot height: 1 to 1.5cm
> - ball radius: 4.5 to 5cm
> - ball weight: the same
>
> The suggestion to the field size is hard. I would suggest to adapt to 
> a field size of 1/3 of the internaltional commen field size for 
> humans. This would be around 1.75 times the current size.
>
> The extension of the HipYawPitch to a range of -120 to 60 could be an 
> option, since it fits better to the human leg range. Although in my 
> opinion the above range is a bit too much and a change in the 
> HipYawPitch itself is not enough. If we allow for a wider range here, 
> we also need to adjust the range of the other two hip joints to allow 
> the intended leg-freedom for kicking. But, over the last months I also 
> came to the conclusion that the Nao is allready quite flexible and 
> this kind of leg-feedom doesn't bring too much benefit. We have kicks 
> going to the right, left, front and back if the agent is standing 
> still. I could also come up with kicks in e.g. 10 degrees steps, but 
> as long as I have to stand still, there is no real benefit in more 
> kick directions. And if I can shoot while walking, I should walk 
> better ;) Humans also often do a final step before kicking.
>
> So, I hope I could help you with my suggestions and thoughts to 
> clarify the values for the upcomming events. If you need any further 
> help or have some questions about my tests/thoughts, you are very 
> welcome to ask.
>
>
> Am 08.03.2012 05:24, schrieb Patrick MacAlpine:
>> Hi all,
>>
>> Based on the proposed changes to the 3D simulation competition,
>> particularly that of kicking, I've optimized one of our kicks for
>> distance through machine learning in order to create some benchmarks
>> for how changes might affect things.  The following are numbers I've
>> collected on optimizing a kick for which the ball is beamed to a set
>> place in front of the agent.  While these numbers show what is
>> possible in the server, we have made no attempt yet to integrate the
>> kick into our agent such that it is able to walk up to and position
>> behind the ball before kicking it.  These numbers should be considered
>> a lower bound for what is possible in the server, but with the caveat
>> that it may be hard to achieve their full potential without very good
>> positioning.
>>
>> Current server: Distance = 12m with a height of 1.4m+ (2.5X height of 
>> a Nao)
>> Ball at half mass (.013): Distance = 8m with similar height above
>> Ball at double mass (.052): Distance = 17m+ with similar height above
>> Ball at +50% radius (.063): Distance = 16.5m with height greater than
>> Nao although lower for longer kicks
>> Foot Z half value (def $FootSizeZ  0.015): Distance = 12.5m with a
>> height of 1.8m (3X height of a Nao)
>>
>> Based on the numbers above it seems that the goals of kicking above
>> the height of a Nao (which was not something that the kicks learned
>> were optimized for) as well as a distance 2/3 the length of half field
>> (which is 10.5m if the field is increased by 50%) are already
>> attainable.  Decreasing the mass of the ball will only decrease the
>> length of kicks whereas increasing the mass of the ball would
>> increase kick length.  This increase in distance with more mass occurs
>> because once the ball hits the ground it rolls farther due to it
>> having more momentum with greater mass.  I'm not really in favor of
>> increasing the size of the ball as it starts to look a little silly
>> with its larger size relative to the Nao and also a larger size will
>> make it harder to get the ball by a goalie and score goals.  The
>> larger ball rolls farther after hitting the ground when compared to
>> the regular size ball, which is the reason for longer distance kicks,
>> and makes me think that increasing the ball's radius also increases
>> its mass. Decreasing the height of the foot seems to add a little
>> distance as well as height to kicks but not by a considerable amount.
>> If there are other changes to server parameters or combinations of
>> server parameters that you wish to see benchmarked let me know and I
>> will try to run them (time permitting).
>>
>> I'm OK with changes to the field size if it makes things better match
>> the ratio of the real world, however if we do this I think we should
>> also match in the number of players (11).  This way the amount of open
>> space and area which individual players need to cover is also similar
>> to the real world.
>>
>> I like the idea of adding heterogeneous players and think this would
>> add a really interesting component to this year's competition.  We're
>> currently exploring how modifying the dimensions of the robot model
>> affects aspects of play, such as an agent's walking speed and
>> stability, so as to find a range of parameter values that can be
>> changed to create heterogeneous robot models without unbalancing
>> gameplay.
>>
>> Regards,
>> Patrick MacAlpine (UT Austin Villa)
>>
>>
>>
>> On Fri, Mar 2, 2012 at 1:57 PM, Hedayat 
>> Vatankhah<hed...@gm...>  wrote:
>>> Dear all,
>>>
>>> As you can find in the attached document, TC has decided for a few
>>> adjustments/enhancements in the simulator for 2012 competitions. It is
>>> really nice if we can get these changes ready ASAP, so that we can 
>>> use at
>>> least some of these changes in upcoming open competitions (IranOpen and
>>> DutchOpen). Sorry for being a little late :(.
>>>
>>> Anyway, according to the document, most of the changes are some 
>>> parameter
>>> adjustments. We need your help to find some suitable values to 
>>> suggest and
>>> request feedback from the teams. The primary parameters to adjust are:
>>> - ball size
>>> - ball weight
>>> - foot height
>>> - possibly foot shape if that is possible
>>>
>>> And the secondary parameters to adjust is then:
>>> - field size
>>>
>>>
>>> It's great if we can have some values in less than a week and then 
>>> discuss
>>> those values in the list with all teams. Any help is highly 
>>> appreciated! :)
>>>
>>> Thanks
>>>
>>> Hedayat
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> Virtualization&  Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> Simspark Generic Physical MAS Simulator
>>> simspark-devel mailing list
>>> sim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>>>
>> _______________________________________________
>> 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] Immediate help is needed for preparation!

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

Hi Patrick,

thanks a lot for your work!

Stefan has also evaluated some settings. Below his findings.
His conclusions are quite close to yours. Increasing ball mass seems 
odd, at least as long as friction is kept the same. He also suggests 
only marginal increase in ball size.
The only difference is with respect to foot height. He suggests to 
shrink the foot.
In my oppinion this would allow more flexibility, i.e. the initial 
situation does not require too much precision or put in other words, 
kicking high from various ball distances and situations can be achieved.


Greetings
Klaus

Stefan:

The magmaOffenburg agent is capable of two different forward kicks, one 
that is wider, like a normal kick, and one that is faster, called 
FastKick, that is more like rising the leg while standing. It's hard to 
describe, but the FastKick should basically lift the ball up, but less wide.

Results:
1) foot height: 1.5cm, ball radius: 4.2cm (old)
     - 13g (old/2):
         - Kick: ball hardly leaves the ground
         - FastKick: shoulder to head height (relatively reliable)
     - 26g (old):
         - Kick: ball hardly leaves the ground
         - FastKick: head height (reliable)
     - 39g (old+13):
         - Kick: ball hardly leaves the ground
         - FastKick: head height (reliable)
2) foot height: 1.5cm, ball radius: 5.2cm
     - 13g (old/2):
         - Kick: knee to hip height - it is easily able to push the foot 
fast enough below the ball, but then the ball doesn't get much momentum 
and simply drops down again (like a trick kicker, balancing the ball)
         - FastKick: hip height - it isn't realy able to get below the 
ball. The FastKick accelerates the leg directly at the ball and the ball 
seems to take the acceleration easier when it is leighter.
     - 26g (old):
         - Kick: same behavior as with 13g
         - FastKick: head height (reliable)
     - 39g (old*2):
         - Kick: ball hardly leaves the ground
         - FastKick: head height (reliable)

In general with a heighter foot, like e.g. 2cm, our kicks aren't realy 
able to get below the ball. If I rise the size of the ball radius by 
another 1cm (to 6.2cm), the ball slowly is as high as the knee and it 
happens somethimes that it touches the ball with its knee. At that size 
our kicks are also not realy capable any more to kick the ball 
appropriately. With some tweaks it may well be possible to kick it 
better, but at that size it also looks strange...

Overall I realized that the weight of the ball has less impact on if 
it's high kickable. On the other hand, the size of the ball has less 
impact on the kickable distance.
The following observations were made:
- if the ball weight is reduced, the friction has a higher impact on the 
ball's speed, reducing possible kick distances drastically. If it is 
enlarged, the friction has less impact on the ball's speed, but it 
quickly results in an odd ball movement. It is rolling very long and 
stopping too slow.
- If the ball gets too big, it is hard to get the foot of the agent 
stretched below the ball in such a way that it kicks proper off the 
ground. But as logical consequence, it has a bit less friction and gets 
farer.
- If the ball is bigger, it is easier to kick in different directions

After several hours ot testing I think that both values for the ball are 
well balanced. According to wikipedia, a soccer ball has a radius of 
around 10cm. We use 4.2cm, wich is around half the size, but I think we 
have to consider more the ratio of foot height to ball radius. We have a 
robot that is 1/3 of the size of a human, so it should get around 1/3 of 
the foot height. If I take a rough estimation of the height of the box 
of my personal foot, I would say it's on average around 3cm in the 
front. With this, to change the foot height to a value between 1 to 1.5 
cm sounds reasonable to me and the results also show that with a thinner 
foot around 1.5cm, kicking high is not the biggest problem any more, 
even without changing the ball parameter too much.

The kick distance is more problematic. Wikipedia says that the 
international ball weight is above 400g. We currently have 26g... As I 
sad, rising the ball's weight is not really the best option as long the 
field friction is kept the same. We may be able to adjust the values 
slightly, e.g. a ball radius around 5cm and a weight around 30g, to make 
a step towards more distance in kicking, but I would need to make some 
other experiments to fine tune my suggestion for real values. In the 
above experiments with 5.2cm radius and 39g weight, the ball movement 
was already quite odd and the gain in distance was from initially 4.5m 
to around 9m - not even half the field.

In general the results are just my opinion and other teams may well be 
able to kick higher and/or wider with the same parameters. My suggestion 
with respect to well balanced values for foot height, ball radius and 
weight are:
- foot height: 1 to 1.5cm
- ball radius: 4.5 to 5cm
- ball weight: the same

The suggestion to the field size is hard. I would suggest to adapt to a 
field size of 1/3 of the internaltional commen field size for humans. 
This would be around 1.75 times the current size.

The extension of the HipYawPitch to a range of -120 to 60 could be an 
option, since it fits better to the human leg range. Although in my 
opinion the above range is a bit too much and a change in the 
HipYawPitch itself is not enough. If we allow for a wider range here, we 
also need to adjust the range of the other two hip joints to allow the 
intended leg-freedom for kicking. But, over the last months I also came 
to the conclusion that the Nao is allready quite flexible and this kind 
of leg-feedom doesn't bring too much benefit. We have kicks going to the 
right, left, front and back if the agent is standing still. I could also 
come up with kicks in e.g. 10 degrees steps, but as long as I have to 
stand still, there is no real benefit in more kick directions. And if I 
can shoot while walking, I should walk better ;) Humans also often do a 
final step before kicking.

So, I hope I could help you with my suggestions and thoughts to clarify 
the values for the upcomming events. If you need any further help or 
have some questions about my tests/thoughts, you are very welcome to ask.


Am 08.03.2012 05:24, schrieb Patrick MacAlpine:
> Hi all,
>
> Based on the proposed changes to the 3D simulation competition,
> particularly that of kicking, I've optimized one of our kicks for
> distance through machine learning in order to create some benchmarks
> for how changes might affect things.  The following are numbers I've
> collected on optimizing a kick for which the ball is beamed to a set
> place in front of the agent.  While these numbers show what is
> possible in the server, we have made no attempt yet to integrate the
> kick into our agent such that it is able to walk up to and position
> behind the ball before kicking it.  These numbers should be considered
> a lower bound for what is possible in the server, but with the caveat
> that it may be hard to achieve their full potential without very good
> positioning.
>
> Current server: Distance = 12m with a height of 1.4m+ (2.5X height of a Nao)
> Ball at half mass (.013): Distance = 8m with similar height above
> Ball at double mass (.052): Distance = 17m+ with similar height above
> Ball at +50% radius (.063): Distance = 16.5m with height greater than
> Nao although lower for longer kicks
> Foot Z half value (def $FootSizeZ  0.015): Distance = 12.5m with a
> height of 1.8m (3X height of a Nao)
>
> Based on the numbers above it seems that the goals of kicking above
> the height of a Nao (which was not something that the kicks learned
> were optimized for) as well as a distance 2/3 the length of half field
> (which is 10.5m if the field is increased by 50%) are already
> attainable.  Decreasing the mass of the ball will only decrease the
> length of kicks whereas increasing the mass of the ball would
> increase kick length.  This increase in distance with more mass occurs
> because once the ball hits the ground it rolls farther due to it
> having more momentum with greater mass.  I'm not really in favor of
> increasing the size of the ball as it starts to look a little silly
> with its larger size relative to the Nao and also a larger size will
> make it harder to get the ball by a goalie and score goals.  The
> larger ball rolls farther after hitting the ground when compared to
> the regular size ball, which is the reason for longer distance kicks,
> and makes me think that increasing the ball's radius also increases
> its mass. Decreasing the height of the foot seems to add a little
> distance as well as height to kicks but not by a considerable amount.
> If there are other changes to server parameters or combinations of
> server parameters that you wish to see benchmarked let me know and I
> will try to run them (time permitting).
>
> I'm OK with changes to the field size if it makes things better match
> the ratio of the real world, however if we do this I think we should
> also match in the number of players (11).  This way the amount of open
> space and area which individual players need to cover is also similar
> to the real world.
>
> I like the idea of adding heterogeneous players and think this would
> add a really interesting component to this year's competition.  We're
> currently exploring how modifying the dimensions of the robot model
> affects aspects of play, such as an agent's walking speed and
> stability, so as to find a range of parameter values that can be
> changed to create heterogeneous robot models without unbalancing
> gameplay.
>
> Regards,
> Patrick MacAlpine (UT Austin Villa)
>
>
>
> On Fri, Mar 2, 2012 at 1:57 PM, Hedayat Vatankhah<hed...@gm...>  wrote:
>> Dear all,
>>
>> As you can find in the attached document, TC has decided for a few
>> adjustments/enhancements in the simulator for 2012 competitions. It is
>> really nice if we can get these changes ready ASAP, so that we can use at
>> least some of these changes in upcoming open competitions (IranOpen and
>> DutchOpen). Sorry for being a little late :(.
>>
>> Anyway, according to the document, most of the changes are some parameter
>> adjustments. We need your help to find some suitable values to suggest and
>> request feedback from the teams. The primary parameters to adjust are:
>> - ball size
>> - ball weight
>> - foot height
>> - possibly foot shape if that is possible
>>
>> And the secondary parameters to adjust is then:
>> - field size
>>
>>
>> It's great if we can have some values in less than a week and then discuss
>> those values in the list with all teams. Any help is highly appreciated! :)
>>
>> Thanks
>>
>> Hedayat
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization&  Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Simspark Generic Physical MAS Simulator
>> simspark-devel mailing list
>> sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>>
> _______________________________________________
> rc-ss3d-tc mailing list
> rc-...@li...
> http://lists.robocup.org/listinfo.cgi/rc-ss3d-tc-robocup.org

Re: [simspark-devel] Immediate help is needed for preparation!

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

Hi all,

Based on the proposed changes to the 3D simulation competition,
particularly that of kicking, I've optimized one of our kicks for
distance through machine learning in order to create some benchmarks
for how changes might affect things.  The following are numbers I've
collected on optimizing a kick for which the ball is beamed to a set
place in front of the agent.  While these numbers show what is
possible in the server, we have made no attempt yet to integrate the
kick into our agent such that it is able to walk up to and position
behind the ball before kicking it.  These numbers should be considered
a lower bound for what is possible in the server, but with the caveat
that it may be hard to achieve their full potential without very good
positioning.

Current server: Distance = 12m with a height of 1.4m+ (2.5X height of a Nao)
Ball at half mass (.013): Distance = 8m with similar height above
Ball at double mass (.052): Distance = 17m+ with similar height above
Ball at +50% radius (.063): Distance = 16.5m with height greater than
Nao although lower for longer kicks
Foot Z half value (def $FootSizeZ  0.015): Distance = 12.5m with a
height of 1.8m (3X height of a Nao)

Based on the numbers above it seems that the goals of kicking above
the height of a Nao (which was not something that the kicks learned
were optimized for) as well as a distance 2/3 the length of half field
(which is 10.5m if the field is increased by 50%) are already
attainable.  Decreasing the mass of the ball will only decrease the
length of kicks whereas increasing the mass of the ball would
increase kick length.  This increase in distance with more mass occurs
because once the ball hits the ground it rolls farther due to it
having more momentum with greater mass.  I'm not really in favor of
increasing the size of the ball as it starts to look a little silly
with its larger size relative to the Nao and also a larger size will
make it harder to get the ball by a goalie and score goals.  The
larger ball rolls farther after hitting the ground when compared to
the regular size ball, which is the reason for longer distance kicks,
and makes me think that increasing the ball's radius also increases
its mass. Decreasing the height of the foot seems to add a little
distance as well as height to kicks but not by a considerable amount.
If there are other changes to server parameters or combinations of
server parameters that you wish to see benchmarked let me know and I
will try to run them (time permitting).

I'm OK with changes to the field size if it makes things better match
the ratio of the real world, however if we do this I think we should
also match in the number of players (11).  This way the amount of open
space and area which individual players need to cover is also similar
to the real world.

I like the idea of adding heterogeneous players and think this would
add a really interesting component to this year's competition.  We're
currently exploring how modifying the dimensions of the robot model
affects aspects of play, such as an agent's walking speed and
stability, so as to find a range of parameter values that can be
changed to create heterogeneous robot models without unbalancing
gameplay.

Regards,
Patrick MacAlpine (UT Austin Villa)



On Fri, Mar 2, 2012 at 1:57 PM, Hedayat Vatankhah <hed...@gm...> wrote:
> Dear all,
>
> As you can find in the attached document, TC has decided for a few
> adjustments/enhancements in the simulator for 2012 competitions. It is
> really nice if we can get these changes ready ASAP, so that we can use at
> least some of these changes in upcoming open competitions (IranOpen and
> DutchOpen). Sorry for being a little late :(.
>
> Anyway, according to the document, most of the changes are some parameter
> adjustments. We need your help to find some suitable values to suggest and
> request feedback from the teams. The primary parameters to adjust are:
> - ball size
> - ball weight
> - foot height
> - possibly foot shape if that is possible
>
> And the secondary parameters to adjust is then:
> - field size
>
>
> It's great if we can have some values in less than a week and then discuss
> those values in the list with all teams. Any help is highly appreciated! :)
>
> Thanks
>
> Hedayat
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>

Re: [simspark-devel] Help: Try to use other effectors/perceptors than Hinge- and Universal-Joints

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

Hi,

thanks a lot for your instant reply, I wasn't expecting such a quick 
response ;)

So my code analysis was not that bad at all, I was also thinking that I 
need additional definitions of effectors and percoptors to this kind of 
joints in the "spark/plugin/sparkagent" folder. As far I can see, it's 
basically just a encoding/decoding of messages. And I tell the system 
about the new percptor/effector options via the export.cpp in that folder.

I found a test rsg file where slider-joint are configured, so I think 
the parsing part of the rsg-files with respect to this joints is already in.

I may try to implement the corresponding perceptors/effectors, but I may 
need some additional help to get it run, since I tried to avoid 
programming c++ so far ;)
But I will ask in this mailing list again, when I get stuck somewhere.

Btw. I tried to setup a Eclipse for developing SimSpark. So far it works 
fine - the only problem I have is that it still uses the installed 
Spark-server instead of the one in the IDE. Are there any known 
constants or something like that, which I have to adjust in order to 
take a different spark-target?

Thanks again!
Stefan


Am 01.03.2012 21:35, schrieb Yuan Xu:
> Hi,
>
> hinge joint and universal joints perceptor and actuator are located at 
> spark/plugin/sparkagent
>
> I think it is possible to configure what you want, if you can include 
> ball and slide joint from ODE.
>
> Good luck!
>
> On Thu, Mar 1, 2012 at 9:27 PM, Stefan Glaser <gla...@gm... 
> <mailto:gla...@gm...>> wrote:
>
>     Hello,
>
>     I'm trying to use SimSpark as a simulator for a student project at my
>     university. In this project we want to model some more complex
>     physical
>     bodies and develop some behaviors to it.
>
>     I'm well informed about anything related to the RCSoccer simulation. I
>     know its perceptors, effectors, its values and also something
>     about the
>     configs and the .rsg files in general.
>
>     The point I'm struggling with is that we want to use other joints
>     provided by ode than just Hinge- and Universal-Joints, e.g.
>     Ball-Joints
>     and Slider-Joints. I tried to study the source code for a while and
>     realized that on the one hand I can find the corresponding definitions
>     in the "odeimps" folder, but I'm not able yet to find anything about
>     sensing or manipulating these kind of joints in the code.
>     I also wonder if it is possible to specify cyclic connected body
>     parts.
>     For example think of a digger (earth mover) that has a stretchable arm
>     configuration with a passive hinge joint and a hydraulic cylinder
>     connected by two further passive hinge joints applying the force
>     to move
>     the configuration. Is such a configuration currently possible?
>
>     I'm still not really familiar with the SimSpark source code, maybe
>     someone can give me a pointer on where to look, or where I can get
>     information about other joints available in the simulator.
>
>     Thanks,
>     Stafan Glaser
>
>     ------------------------------------------------------------------------------
>     Virtualization & Cloud Management Using Capacity Planning
>     Cloud computing makes use of virtualization - but cloud computing
>     also focuses on allowing computing to be delivered as a service.
>     http://www.accelacomm.com/jaw/sfnl/114/51521223/
>     _______________________________________________
>     Simspark Generic Physical MAS Simulator
>     simspark-devel mailing list
>     sim...@li...
>     <mailto:sim...@li...>
>     https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>
>
>
> -- 
> Best Regards,
>
> Xu, Yuan

Re: [simspark-devel] Help: Try to use other effectors/perceptors than Hinge- and Universal-Joints

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

Hi,

hinge joint and universal joints perceptor and actuator are located at
spark/plugin/sparkagent

I think it is possible to configure what you want, if you can include ball
and slide joint from ODE.

Good luck!

On Thu, Mar 1, 2012 at 9:27 PM, Stefan Glaser <gla...@gm...> wrote:

> Hello,
>
> I'm trying to use SimSpark as a simulator for a student project at my
> university. In this project we want to model some more complex physical
> bodies and develop some behaviors to it.
>
> I'm well informed about anything related to the RCSoccer simulation. I
> know its perceptors, effectors, its values and also something about the
> configs and the .rsg files in general.
>
> The point I'm struggling with is that we want to use other joints
> provided by ode than just Hinge- and Universal-Joints, e.g. Ball-Joints
> and Slider-Joints. I tried to study the source code for a while and
> realized that on the one hand I can find the corresponding definitions
> in the "odeimps" folder, but I'm not able yet to find anything about
> sensing or manipulating these kind of joints in the code.
> I also wonder if it is possible to specify cyclic connected body parts.
> For example think of a digger (earth mover) that has a stretchable arm
> configuration with a passive hinge joint and a hydraulic cylinder
> connected by two further passive hinge joints applying the force to move
> the configuration. Is such a configuration currently possible?
>
> I'm still not really familiar with the SimSpark source code, maybe
> someone can give me a pointer on where to look, or where I can get
> information about other joints available in the simulator.
>
> Thanks,
> Stafan Glaser
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>



-- 
Best Regards,

Xu, Yuan

[simspark-devel] Help: Try to use other effectors/perceptors than Hinge- and Universal-Joints

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

Hello,

I'm trying to use SimSpark as a simulator for a student project at my 
university. In this project we want to model some more complex physical 
bodies and develop some behaviors to it.

I'm well informed about anything related to the RCSoccer simulation. I 
know its perceptors, effectors, its values and also something about the 
configs and the .rsg files in general.

The point I'm struggling with is that we want to use other joints 
provided by ode than just Hinge- and Universal-Joints, e.g. Ball-Joints 
and Slider-Joints. I tried to study the source code for a while and 
realized that on the one hand I can find the corresponding definitions 
in the "odeimps" folder, but I'm not able yet to find anything about 
sensing or manipulating these kind of joints in the code.
I also wonder if it is possible to specify cyclic connected body parts. 
For example think of a digger (earth mover) that has a stretchable arm 
configuration with a passive hinge joint and a hydraulic cylinder 
connected by two further passive hinge joints applying the force to move 
the configuration. Is such a configuration currently possible?

I'm still not really familiar with the SimSpark source code, maybe 
someone can give me a pointer on where to look, or where I can get 
information about other joints available in the simulator.

Thanks,
Stafan Glaser

Re: [simspark-devel] Simulation cycle

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

Hi Sander,


/*Sander van Dijk <sgv...@gm...>*/ wrote on Tue, 17 Jan 2012 
12:51:42 +0000:
> Hey all,
>
> I am digging through the simulation cycle life time again. If my 
> understanding is correct now (please correct me if I'm wrong, like the 
> last time I thought I had it figured out ;)), this is the order things 
> are happening now:
>
> * StartCycle
> - Read agent messages
> - Realize actions
>
> * SenseAgent
> - Send (last cycle's) sense data to agents
>
> * Step
> - Update physics and game conrol
>
> * SyncTime
> - Wait until 0.02 seconds have passed since last SyncTime
>
> * EndCycle
> - Query and prepare sensor data sent in the next cycle
>
> In this scenario, however, first all sensor data for next cycle is 
> prepared and all agent messages read and parsed, before the sense data 
> is sent to which the agent should have 0.02 seconds to reply. The time 
> these things take depend on how much sense data there is to query, 
> prepare and send, so the time left between SenseAgent and StartCycle 
> is not fixed. I don't know how much time it really is, but the fact it 
> is not constant is a problem.
>
> I think it would be a better idea to place SyncTime after 
> EndCycle/before StartCycle, such that the actual think time becomes 
> independent from how long it takes to query and prepare sensor data. 
> It then still does depend on StartCycle though, however I don't 
> believe there is much fluctuation in how long this takes during a 
> match, and this part has to be after the wait and before SenseAgent in 
> order to keep the same ordering of events from the view of an agent.
If I remember correctly, yes, this is the correct order :D. And your 
suggestion seems reasonable.


>
> If we want to make the think time more consistent not only in a single 
> match but also between matches, we will have to make the wait last 
> until 0.02 seconds after SenseAgent, though I am not sure whether that 
> is needed or not, though let me know what you think
It is related to the way we want to interpret the meaning of "real time" 
simulation. Currently, we *try* to be real-time, and therefore we want 
to have each cycle take 0.02 seconds totally. Your suggestion guarantees 
that we won't be real-time, but it could be considered more consistent 
in the view of agents. So, we should decide if we want to be real-time, 
or more consistent. I don't know which one is more interesting! It seems 
that the original authors preferred the former.

Regards,
Hedayat


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

[simspark-devel] Simulation cycle

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

Hey all,

I am digging through the simulation cycle life time again. If my
understanding is correct now (please correct me if I'm wrong, like the last
time I thought I had it figured out ;)), this is the order things are
happening now:

* StartCycle
- Read agent messages
- Realize actions

* SenseAgent
- Send (last cycle's) sense data to agents

* Step
- Update physics and game conrol

* SyncTime
- Wait until 0.02 seconds have passed since last SyncTime

* EndCycle
- Query and prepare sensor data sent in the next cycle

In this scenario, however, first all sensor data for next cycle is prepared
and all agent messages read and parsed, before the sense data is sent to
which the agent should have 0.02 seconds to reply. The time these things
take depend on how much sense data there is to query, prepare and send, so
the time left between SenseAgent and StartCycle is not fixed. I don't know
how much time it really is, but the fact it is not constant is a problem.

I think it would be a better idea to place SyncTime after EndCycle/before
StartCycle, such that the actual think time becomes independent from how
long it takes to query and prepare sensor data. It then still does depend
on StartCycle though, however I don't believe there is much fluctuation in
how long this takes during a match, and this part has to be after the wait
and before SenseAgent in order to keep the same ordering of events from the
view of an agent.

If we want to make the think time more consistent not only in a single
match but also between matches, we will have to make the wait last until
0.02 seconds after SenseAgent, though I am not sure whether that is needed
or not, though let me know what you think

Sander

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

Re: [simspark-devel] Communication with trainer

[Luca G. <giu...@ya...>]

Ok, thank you and sorry!

Luca

In data 16 gennaio 2012 alle ore 16:17:56, Hedayat Vatankhah  
<hed...@gm...> ha scritto:

> Hi Luca,
>
> Sorry, this list is for simspark (3d simulation engine) and 3d
> simulation server development. Please contact 2D mailing list.
>
>
> Thanks
>
> Hedayat
>
>
> /*Luca Giuliani <giu...@ya...>*/ wrote on Mon, 16 Jan 2012
> 11:57:17 +0100:
>> Hello,
>> I'm trying to develop an agent for 2d simulation with my team. My idea  
>> was
>> to train agents using Genetic Algorithms and i would like to use a  
>> trainer
>> connected to the server to issue simulation sessions and evaluations of
>> the fitness.
>> Now I've an issue: my trainer can communicate messages to the 15.0.1
>> server (any kind of message, commands or "say" messages) but it can't  
>> have
>> answers. I analyzed the communication by wireshark, and found that no  
>> upd
>> packets are sent back to the trainer. No error are shown by the server  
>> and
>> commands are applied.
>> It could be fine, but I need to be able to ear messages said by the
>> agents, to synchronize all the environment.
>> Did I miss something?
>>
>> Thank you very much,
>>
>> Luca Giuliani
>> Isaac Team, from Polytecnic of Turin (ITALY)
>>


-- 
Creato con il rivoluzionario client email di Opera:  
http://www.opera.com/mail/

Re: [simspark-devel] Communication with trainer

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

Hi Luca,

Sorry, this list is for simspark (3d simulation engine) and 3d 
simulation server development. Please contact 2D mailing list.


Thanks

Hedayat


/*Luca Giuliani <giu...@ya...>*/ wrote on Mon, 16 Jan 2012 
11:57:17 +0100:
> Hello,
> I'm trying to develop an agent for 2d simulation with my team. My idea was
> to train agents using Genetic Algorithms and i would like to use a trainer
> connected to the server to issue simulation sessions and evaluations of
> the fitness.
> Now I've an issue: my trainer can communicate messages to the 15.0.1
> server (any kind of message, commands or "say" messages) but it can't have
> answers. I analyzed the communication by wireshark, and found that no upd
> packets are sent back to the trainer. No error are shown by the server and
> commands are applied.
> It could be fine, but I need to be able to ear messages said by the
> agents, to synchronize all the environment.
> Did I miss something?
>
> Thank you very much,
>
> Luca Giuliani
> Isaac Team, from Polytecnic of Turin (ITALY)
>

[simspark-devel] Communication with trainer

[Luca G. <giu...@ya...>]

Hello,
I'm trying to develop an agent for 2d simulation with my team. My idea was  
to train agents using Genetic Algorithms and i would like to use a trainer  
connected to the server to issue simulation sessions and evaluations of  
the fitness.
Now I've an issue: my trainer can communicate messages to the 15.0.1  
server (any kind of message, commands or "say" messages) but it can't have  
answers. I analyzed the communication by wireshark, and found that no upd  
packets are sent back to the trainer. No error are shown by the server and  
commands are applied.
It could be fine, but I need to be able to ear messages said by the  
agents, to synchronize all the environment.
Did I miss something?

Thank you very much,

Luca Giuliani
Isaac Team, from Polytecnic of Turin (ITALY)

-- 
Creato con il rivoluzionario client email di Opera:
http://www.opera.com/mail/

[simspark-devel] Communication with trainer

[Luca G. <giu...@ya...>]

Hello,
I'm trying to develop an agent for 2d simulation with my team. My idea was  
to train agents using Genetic Algorithms and i would like to use a trainer  
connected to the server to issue simulation sessions and evaluations of  
the fitness.
Now I've an issue: my trainer can communicate messages to the 15.0.1  
server (any kind of message, commands or "say" messages) but it can't have  
answers. I analyzed the communication by wireshark, and found that no upd  
packets are sent back to the trainer. No error are shown by the server and  
commands are applied.
It could be fine, but I need to be able to ear messages said by the  
agents, to synchronize all the environment.
Did I miss something?

Thank you very much,

Luca Giuliani
Isaac Team, from Polytecnic of Turin (ITALY)

-- 
Creato con il rivoluzionario client email di Opera:
http://www.opera.com/mail/

[simspark-devel] SimSpark Gui, Re-/Initializing Spark

[Patrick G. <Pat...@on...>]

Hi,

Im continuing on the SimSpark Gui Project but i think i *might* have hit 
a roadblock. I hope it is nothing or at least solvable without changing 
zeitgeist too much, so heres the problem:

The Gui is currently designed to start and watch different threads that 
might either be internal or external monitors, agents and (one) server. 
The concept is meant to define new Simulation Setups containing those 
threads, some scripts modifying the execution of the threads (e.g. 
loading NaoSoccer etc.) and loading different GuiPlugins for each 
Simulation without having to write new compilable projects or edit 
script files. So i wrote a more general class SimSpark derived from 
Spark (just als those in rcssserver3d etc), where i add resource 
locations and scripts at runtime. So far, executing the server as 
separate thread in the gui works without a problem.
But now i need to start, stop and/or restart multiple instances of 
SimSpark at once or after another, for example restarting the Core or 
initializing two SimSpark objects at the same time for a distict server 
and a monitor. But zeitgeist crashes when it is initialized again after 
being closed, because there are some static properties and leftover 
references to the previous Core. While rsgedit avoids this problem by 
never actually removing its single Spark instance (but resetting it), 
this wont work in my case since i need more than one instance at the 
same time. I can seek and replace static references and objects in 
zeitgeist, oxygen and kerosin, but i dont know if the script interface 
is able to deal with multiple simulation/script servers anyway. In the 
ruby wrappers there dont seem to be any distict Ruby-Contexts but only 
one single interface. If so, is it possible to wrap the ruby calls 
without changing the whole core? Or will the interface work with 
different Script-Servers accessing it? I just need to know this before i 
attempt to rewrite parts of zeitgeist and oxygen.

Of course there is the possibility of integrated monitors and agents in 
the server itself. But i definitely want to support external processes 
and (gui-)internal threads first. When not relying on the direct control 
of the core but using the tcp/ip commands first i can cover two kinds of 
execution (as thread in the gui, as process observed by the gui) at the 
same time. I dont know if i have time to implement both server-internal 
and external monitors and agents right away, so i want to stick with the 
more important kind. This way, both observing and controlling externally 
started processes (rcssagent3d.exe etc..), and integrating them into the 
gui to display and debug them in one window would be possible.

Please tell me if you have some advice on how to deal with the 
situation. Also, you might want to have a look at 
http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface 
. If you have concerns ideas and/or wishes, you can always comment or 
edit on the project page describing the main features of the gui. It is 
meant to be used someday after all, so feedback from those who might 
want to use (and extend!) it is always appreciated xD

Best regards,
Patrick Geib

[simspark-devel] SimSpark Gui

[Patrick G. <Pat...@on...>]

Hi,

Im nearly finished with the main framework for the Gui and about to 
finally add content. I created a project page in the Simspark wiki at 
http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface 
where I describe the structure, the idea behind it and what i am going 
to do next.
Before I start with the main part (implementing control and view for 
SimSpark etc.), i wanted to inform you about the status. If you have any 
feedback, suggestions or ideas, please let me know via mail or simply 
comment using the wiki discussion page.

Best regards,
Patrick
<http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface>

Re: [simspark-devel] 2012!

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

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
    <style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="UTF-8" text="#000000"
    bgcolor="#FFFFFF">
    <p>Hi,</p>
    <p>Good point. I'm not sure where to put it, so I'll put it in
      Wishlist for now. <br>
    </p>
    <p>Thanks! :)<br>
    </p>
    <p> </p>
    <br>
    <span id="IDstID"><br>
      <br>
      <style type="text/css">blockquote { /*Tue, 8 Nov 2011 12:02:32 +0800*/ color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}blockquote blockquote { /*Tue, 8 Nov 2011 12:02:32 +0800*/ color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}blockquote blockquote blockquote { /*Tue, 8 Nov 2011 12:02:32 +0800*/ color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}blockquote blockquote blockquote blockquote { /*Tue, 8 Nov 2011 12:02:32 +0800*/ color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}blockquote blockquote blockquote blockquote blockquote { /*Tue, 8 Nov 2011 12:02:32 +0800*/ color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Qingyuan

          Zhang <a class="moz-txt-link-rfc2396E"
            href="mailto:mi...@gm...">&lt;mi...@gm...&gt;</a></b></i>
      wrote on Tue, 8 Nov 2011 12:02:32 +0800:</span>
    <blockquote
cite="mid:CAM...@ma..."
      type="cite">Hi, there<br>
      <br>
      Maybe we can add the function of saving current status of every
      agent. If the server crash, it can recover, and continue the
      match.<br>
      <br clear="all">
      Regards<br>
      Qingyuan<br>
      <br>
      <br>
      <br>
      <div class="gmail_quote">On Mon, Nov 7, 2011 at 10:12 PM, Hedayat
        Vatankhah <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:hed...@gm...">hed...@gm...</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex;">
          <div style="direction:ltr" text="#000000" bgcolor="#FFFFFF">
            <p>Hi all!</p>
            <p>I have created a page for organizing MC efforts for
              2012[1] based on 2011 page. Please have a look at it and
              update as appropriate. The assigned tasks are from 2011.
              Please let us know the areas you are interested to work on
              and/or pick up one or more of the tasks. TC decision for
              2012 is not finalized yet and some of the tasks are based
              on current suggestions. Hopefully the final TC decision
              for 2012 will be announced shortly. Anyway, feel free to
              pick whatever you prefer. It is certainly preferred if it
              is according to TC wishes, but you can still extent the
              simulator in anyway you prefer. And also, in many cases we
              can take the lead and propose new features. </p>
            <p>Looking forward to hear from you! :)</p>
            <p><br>
            </p>
            <p>Good luck,</p>
            <p>Hedayat<br>
            </p>
            <p><br>
            </p>
            <p>[1] <a moz-do-not-send="true"
href="http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2012"
                target="_blank">http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2012</a><br>
            </p>
          </div>
          <br>
------------------------------------------------------------------------------<br>
          RSA(R) Conference 2012<br>
          Save $700 by Nov 18<br>
          Register now<br>
          <a moz-do-not-send="true"
            href="http://p.sf.net/sfu/rsa-sfdev2dev1" target="_blank">http://p.sf.net/sfu/rsa-sfdev2dev1</a><br>
          _______________________________________________<br>
          Simspark Generic Physical MAS Simulator<br>
          simspark-devel mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:sim...@li...">sim...@li...</a><br>
          <a moz-do-not-send="true"
            href="https://lists.sourceforge.net/lists/listinfo/simspark-devel"
            target="_blank">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
  </body>
</html>

Re: [simspark-devel] 2012!

[Qingyuan Z. <mi...@gm...>]

Hi, there

Maybe we can add the function of saving current status of every agent. If
the server crash, it can recover, and continue the match.

Regards
Qingyuan



On Mon, Nov 7, 2011 at 10:12 PM, Hedayat Vatankhah <hed...@gm...>wrote:

>  Hi all!
>
> I have created a page for organizing MC efforts for 2012[1] based on 2011
> page. Please have a look at it and update as appropriate. The assigned
> tasks are from 2011. Please let us know the areas you are interested to
> work on and/or pick up one or more of the tasks. TC decision for 2012 is
> not finalized yet and some of the tasks are based on current suggestions.
> Hopefully the final TC decision for 2012 will be announced shortly. Anyway,
> feel free to pick whatever you prefer. It is certainly preferred if it is
> according to TC wishes, but you can still extent the simulator in anyway
> you prefer. And also, in many cases we can take the lead and propose new
> features.
>
> Looking forward to hear from you! :)
>
>
>  Good luck,
>
> Hedayat
>
>
>  [1]
> http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2012
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>

[simspark-devel] 2012!

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

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8"><style>body
      p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="UTF-8" text="#000000"
    bgcolor="#FFFFFF">
    <p>Hi all!</p>
    <p>I have created a page for organizing MC efforts for 2012[1] based
      on 2011 page. Please have a look at it and update as appropriate.
      The assigned tasks are from 2011. Please let us know the areas you
      are interested to work on and/or pick up one or more of the tasks.
      TC decision for 2012 is not finalized yet and some of the tasks
      are based on current suggestions. Hopefully the final TC decision
      for 2012 will be announced shortly. Anyway, feel free to pick
      whatever you prefer. It is certainly preferred if it is according
      to TC wishes, but you can still extent the simulator in anyway you
      prefer. And also, in many cases we can take the lead and propose
      new features. </p>
    <p>Looking forward to hear from you! :)</p>
    <p><br>
    </p>
    <p>Good luck,</p>
    <p>Hedayat<br>
    </p>
    <p><br>
    </p>
    <p>[1]
<a class="moz-txt-link-freetext" href="http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2012">http://simspark.sourceforge.net/wiki/index.php/Maintenance_Committee_2012</a><br>
    </p>
  </body>
</html>

Re: [simspark-devel] Fwd: 6 Months research practicum on Simspark, ideas and suggestions

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

Hi Patrick,

First of all, great to hear you are spending your project on this, welcome
to the community!

Secondly, before you continue, have a look at RoboViz[1], which is an
alternative monitor for RCSSServer3D, which was recently developed by Justin
Stoecker of team RoboCanes and is now the de facto standard monitor used in
competitions. It offers a debugging interface for agents, to be able to draw
a range of geometric forms and text into the field. If you want to focus on
visualization for 3D simulation, I would suggest getting in contact with
Justin and see if you can work on that. However, RoboViz is geared towards
the RoboCup, if you want to work on Simspark as a generic simulator, your
plans as outlined below are all good, just realize that for the specific
RoboCup implementation there is already something out there.

What I think would be most useful for us as a league, besides extending
RoboViz (and the server+protocol in order to make it all possible) with some
of the extra monitoring and control features you mentioned, is a nice way to
easily design new robots. This because we are thinking about and looking
into working with different, heterogeneous models, or models where
parameters can vary randomly, but we lack ways to easily do this. I have not
looked at RsgEditor or ZigoratAssistant in a while, but if I recall
correctly, they're broken with latest versions of SimSpark, or not fully
intuitive (again, saying this not based on much experience with them ;) ).

Another nice thing would be to have a GUI for configuring and controlling
the simulator, for setting startup parameters and change them at run time.

Good luck, looking forward to the end result!

Sander

On Tue, Oct 18, 2011 at 6:15 AM, Patrick Geib <Pat...@on...>wrote:

>  Hello, ****
>
> my name is Patrick, I'm a 24 year old Masters student from the University
> of Koblenz (Germany), currently studying at the Osaka University for 6
> months. Here I am going to work on the Simspark environment within the
> context of a "research" practicum under the watchful eyes of Joschka
> Boedecker. (Actually it wont be "researching", but I will be focusing on
> solely one project)****
>
> My major subject is Computational Visualistics, so my plans for developing
> on Simspark are mostly improving usability and/or graphical presentation.
> From the Todo- and wishlist in the Wiki I could target (or at least support)
> some of:****
> -  New interface for different rendering engines, add OGRE support****
> **** -  Enable new agent-server protocol to support using image sensor and
> other things via new rendering engine.****
> **** -  GUI for our simulator (possibly based on RsgEdit +
> ZigoratAssistant, incl. easy construction of new robots and simulations,
> moving robots on the field, etc.)****
> **** -  Support Referee enhancements and trainer enhancements: (Drop a
> player anywhere on the field. Drop the ball at any place (as drop ball, free
> kick left or right) as is possible in 2D. Play Mode Control etc..  Control
> e.g. via Monitor)****
> **** -  Nice 3D visualization, including a stadium, animated crowd,
> automatic commentator, slow-motion replay, etc.****
> **** -  Training Capabilities through agent-monitor communication****
>
> As i have about five and a half months of time I could probably connect
> some of these tasks, but of course i will have to focus. For example
> building a User Interface for Server, Monitor and Client Support (maybe like
> WeBots) along with the possibilty to connect new modules for a RsgEditor and
> new functionality would be possible.
> At the same time, Peter Tissen (a friend of mine who is working here too)
> is implementing Bullet as a pluggable Physics Engine optionally choosable
> for the Simspark Simulation.****
>
> First of all, to me it is most important to get feedback by those, who are
> already experienced with Simspark. What is needed? What would be nice to
> have/doable in this amount of time? What is definitely NOT needed? Whatever
> will be done has to be accepted and integrated by the community, so it can
> be of use and of course can be maintained and extended in the future by
> everyone. So to begin with, in the following I have a list of ideas and
> questions you may comment with whatever comes to your mind. The more
> detailed, the better.**
>
> *What should a central user interface contain*
>  - starting server, monitor and agents****
> - controlling the server (game control, message overview, physics engine,
> log control) ****
> - controlling the monitor (views, rendering engine, video captures, game
> camera)****
>  - controlling the agents (message overview, message sending?, debug
> interface?)****
> - creating and testing agents? (loading from collada?, annotating with
> receptors and effectors?, coding?, visualize behaviour? control interface?)
> ****
>  - be extendable to incorporate rsgeditor, further monitors, agent
> visualizations...****
> *
> Questions*: Is running most agents as simspark plugin possible? Or is it
> better to offer some kind of debug messaging interface? How are agents
> debugged in practice and could a central user interface working together
> with server and visualization (see next point) be of help?****
>
> My preference for an easy-to-create and -extend up-to-date GUI is
> definitely QT.****
>
> *What should an improved graphics engine/monitor be able to do?*
> **** -  Visualizing server or agent internal states? (view of agents, rule
> checking, effector usage, agent state visualization)****
> **** -  Improve Debugging/Logging by server and/or agents with a
> documentation interface (visualizing and recording on request)****
> **** -  graphics engine choosable? (currently built-in as fallback,
> Ogre/Irrlicht as improvement). e.g. bind ogre to core scene graph via bridge
> pattern.****
>     **** -  Shading, 1st alternative: GLSL Shading environment attached to
> ogre****
>     **** -  pro: multiple render targets -> realistic lighting, improved
> materials, point of view rendering for every agent, realistic sight
> detection****
>     -> implementation of Screen Space Lighting ****
>     -> implementation of Screen Space Ambient occlusion****
>     - pro: Further rendering engines besides ogre can be connected the
> same way****
>     - con: bound to Ogre. When the interface should fail somehow, there
> wouldnt be any improved shading anymore.****
> - Shading, 2nd alternative: basic GLSL Shading environment attached to the
> monitors core, improving current indepandant shading ( allowing MRT Shading
> too)****
>     - pro: lightweight, same shading options like 1st option****
>     - pro: easy and fast to implement, so i will have time for other
> things ****
>     - pro: not dependant to ogre -> one needs no knowledge about ogre****
>     - con: developing new shaders will be harder, as no combination is
> possible natively****
>     - con: lacking ogres support for Object loading, environmental
> animation, scenegraph, materials etc.****
> - Object Shadows****
>     - simple object shadows (blob under objects)-> easy, with ogre for
> free****
>     - directional shadow for each object -> easy because of flat ground, *
> ***
>     - shadow mapping (allow shadows on objects)-> time consuming).****
> - Inner Shadows (Screen Space Ambient Occlusion, SSAO): only possible with
> shader integration****
> - additional objects to render: seats, crowd, goal net, corner flags
> (further objects would be easier when using ogre)****
> - graphics improvement: textures, sky, weather****
> - environment simulation (wind on grass, changing sky...)****
>
> The main problem is how to improve the current monitor or create an
> alternative one, that is easy to use and (most important) easy to maintain.
> Various new possibilities like visual debugging and recording of server
> internal states (rcssserver3d) and the agents could be integrated into the
> visualization (or maybe better the GUI). I guess since rewriting the monitor
> from scratch could lead to discarding any new implementation with the stable
> one after im done, it my be better to make Ogre a pluggable option to the
> current monitor. New possibilities for the monitor would most likely create
> the need of extending the Server/Monitor MessageProtocol. Both implementing
> Ogre as pluggable rendering engine and simply improving the engine already
> in use are viable options. However, while creating a simple (yet good
> looking) improved rendering style for the Monitor is an easy task,
> connecting Ogre to the scene graph is not. ****
>
>  So the Question: Is it better to simply implement a better visualization,
> leaving much more time for graphical gimmicks, the GUI or
> debug/point-of-view visualization and so on, or is it preferable to create a
> flexible graphics-interface for the monitor and implement Ogre as the first
> one, even if there wont be much more time for the actual visualization and
> possibly more important tasks (central gui).****
>
> This said for the two possible development fields... Again, the most
> important thing is the acceptance in the community. I definitely dont want
> to create an interface or program that cannot be used or maintained in the
> future, should I not be able to continue. ****
> ****Please send me E-Mails with comments, ideas, suggestions and anything
> helpful you might come up with.****
>
> Thanks a lot ;)****
>
> Patrick Geib****
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> 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