simspark-devel — Discussion about Spark development

Re: [simspark-devel] new problem of new server

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

Hi,

On 20/06/2007, at 12:45 PM, Joschka Boedecker wrote:

> I should not make this decision by myself I think. I'm going to ask  
> the
> other TC members about the changes under discussion (two-parts torso,
> heavier bot, joint stops, velocity restrictions, field size, goal  
> size).

I like the idea of having a robot with a two-parts torso, and  
somewhat more realistic restrictions.
For balancing, it'd probably benefical to counter-balance with the  
upper part of the body.

With the short amount of time until actual competitions, however, I  
don't think it's a good idea to introduce these changes now... give  
the teams some time to catch up. After all, it's only a few days  
left. Field-size and goal-size might be OK, though.

Also, you want to have some material left to present the community as  
a good start for Simleague 2008, so don't use up all your ammo ;-)  
When we started thinking about going over to humanoid models, we  
didn't think of exceptional good walking engines, and said that many  
kinds of movements would be OK for this year. It seems some of the  
teams have progressed real fast. So let's give them a chance to  
present what they can do with the existing system by not breaking too  
much.

There might be different issues with all that during the matches, but  
it's the first year for that kind of simulation league, so I wouldn't  
worry too much. It'll be much different next year. Thanks to  
everyones works here, the simulator seems to be in good shape and  
useable (even though it's possible to do weird things).

just my 0.02AU$ ;-)
Oliver

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

Re: [simspark-devel] new problem of new server

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

Hi Yuan,

On Wed, 2007-06-20 at 01:31 +0800, Yuan Xu wrote:
> Hi Joschka,
> 
> > Could you control the robot reliably with the restriction of 9000
> > deg/sec?
> 
> Of course ;-)
> All walking commands of our agent are less than 200 deg/sec.

Just wanted to make sure ;-)

> > Yes, I think you're right. Did you find any good value?
> 
> I recommend 0.8, in my tests, the simulation is stable.
> Except the agent request fast velocity (such as 9000 deg/sec) continuously,
> it will fly...
> ( I think it should not happen in real match, otherwise it is
> intended. where is the human referee? ;-P )
> 
> Should I commit this change?
> No time left for us...

I should not make this decision by myself I think. I'm going to ask the
other TC members about the changes under discussion (two-parts torso,
heavier bot, joint stops, velocity restrictions, field size, goal size).

Thanks,
Joschka

Re: [simspark-devel] new problem of new server

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

Hi Joschka,

> Could you control the robot reliably with the restriction of 9000
> deg/sec?

Of course ;-)
All walking commands of our agent are less than 200 deg/sec.


> Yes, I think you're right. Did you find any good value?

I recommend 0.8, in my tests, the simulation is stable.
Except the agent request fast velocity (such as 9000 deg/sec) continuously,
it will fly...
( I think it should not happen in real match, otherwise it is
intended. where is the human referee? ;-P )

Should I commit this change?
No time left for us...

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] new problem of new server

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

Hi Yuan,

On Tue, 2007-06-19 at 17:42 +0800, Yuan Xu wrote:

> I have tried on this work,
> after some testing, I think maybe we also need to restrict the max
> request joint angle velocity.

Once again, thanks for all the testing :-)

> After changes (set vel to 0 while out of range in effector ),
> the agent falls down on the ground while it requests the Rle5_6 to 9000 deg/sec,
> but the foots were twitching.
> But while the agent request 90000 deg/sec, the robot were flying, (
> not disjoint, a little better than before ).
> I think the 9000 deg/sec is the highest reasonable value ( 180deg/0.02s ),
> even more less value is acceptable, since we can not control the robot
> with such velocity properly.

That sounds still quite fast, faster than most real robots for sure. The
HOAP-2 robot has very strong motors, and in an accident, I saw it
jumping from 0 to 90 degrees almost instantly (very scary!), but it
wasn't that fast I bet. I wouldn't mind restricting to 9000 deg/sec for
now, it should certainly not be more than that. However, it's another
restriction, and some teams might not be happy about it :-/

Could you control the robot reliably with the restriction of 9000
deg/sec?

> And there is a parameter named dParamFudgeFactor in ODE relative to
> this issue. ( chapter 7 )
> Setting the value smaller will be also helpful. ( another parameter ;-\ )
> 
> What about your idea?

Yes, I think you're right. Did you find any good value?

Keep up the good work,
Joschka

Re: [simspark-devel] setBox or setBoxTotal?

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

Hi Yuan,

On Tue, 2007-06-19 at 22:29 +0800, Yuan Xu wrote:

> While debugging our robot, I noticed that the FRP force is only about
> half of the gravity.
> However, this is not the problem of FRP, but the mass set function in
> rsg/boxspheres/box.rsg and rsg/boxspheres/sphere.rsg.
> The 'setBox' and 'setSphere' which accept the density ads argument are used!
> And the correct functions ( 'setBoxTotal' and 'setSphereTotal' ) are
> commented out in the files!!
> I do not know if this is intended, why?

You're right, this is a problem I had totally forgotten about (too many
problems recently ;-) ). I put in the calls to the set..Total functions
a while ago, but they led to very instable simulations in my tests.

Have you tried to use the correct functions? What's the behavior in your
case?

Cheers,
Joschka 

[simspark-devel] setBox or setBoxTotal?

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

Hi Joschka,

While debugging our robot, I noticed that the FRP force is only about
half of the gravity.
However, this is not the problem of FRP, but the mass set function in
rsg/boxspheres/box.rsg and rsg/boxspheres/sphere.rsg.
The 'setBox' and 'setSphere' which accept the density ads argument are used!
And the correct functions ( 'setBoxTotal' and 'setSphereTotal' ) are
commented out in the files!!
I do not know if this is intended, why?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] new problem of new server

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

Hi Joschka,

I have tried on this work,
after some testing, I think maybe we also need to restrict the max
request joint angle velocity.

After changes (set vel to 0 while out of range in effector ),
the agent falls down on the ground while it requests the Rle5_6 to 9000 deg/sec,
but the foots were twitching.
But while the agent request 90000 deg/sec, the robot were flying, (
not disjoint, a little better than before ).
I think the 9000 deg/sec is the highest reasonable value ( 180deg/0.02s ),
even more less value is acceptable, since we can not control the robot
with such velocity properly.

And there is a parameter named dParamFudgeFactor in ODE relative to
this issue. ( chapter 7 )
Setting the value smaller will be also helpful. ( another parameter ;-\ )

What about your idea?

> This sounds reasonable (actually, I remember now that we implemented
> something similar in our HOAP-2 robots to protect them ;-) ). This
> should not be too hard to implement, since HingeEffector and
> UniversalJointEffector both have a reference to their respective Joint
> as a member variable. Using this, we can easily get all the information
> like current joint angle, and joint stops :-) Would you like to try?
>


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] new problem of new server

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

Hi Yuan,

On Tue, 2007-06-19 at 15:52 +0800, Yuan Xu wrote:
> Hi Joschka,
> 
> Also about the joint angle restriction,
> it seems that when the joint angle is out of range, ODE will apply a
> force to restrict it,
> but the motor is still working, then resulting the joint angle
> concussion, at last the whole robot disjointed.

:-(

> After restricting the desired joint angle in our agent (i.e. the robot
> should not try to turn an angle out of the range),
> the simulation became stable.
> However, if a robot missing the restriction itself, the simulation may
> interrupted by it...
> I think we can set the motor velocity to zero while the joint is out of range.

This sounds reasonable (actually, I remember now that we implemented
something similar in our HOAP-2 robots to protect them ;-) ). This
should not be too hard to implement, since HingeEffector and
UniversalJointEffector both have a reference to their respective Joint
as a member variable. Using this, we can easily get all the information
like current joint angle, and joint stops :-) Would you like to try?

Thanks for all your efforts,
Joschka

Re: [simspark-devel] new problem of new server

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

Hi Yuan,

On Tue, 2007-06-19 at 10:11 +0800, Yuan Xu wrote:
> Hi Joschka,
> 
> After some testing, I think it is hard to got a good balance by
> turning global parameters,
> and the results depends on many factors: such as the robot mass, robot
> control ( high or low gain ).
> 
> The ODE parameters effects the robot performance greatly, maybe teams
> do not like change at this time...

First of all, thank you for doing these tests! I know it can be very
painful and time consuming to try to tune ODE paramters :-/

After RoboCup, we might want to have a look into setting local CFM and
ERP values for each joint, but this is also difficult and doesn't help
us now. If we can't get the simulation stable with joint stops very
soon, we'll have to remove them again.

Cheers,
Joschka

Re: [simspark-devel] new problem of new server

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

Hi Joschka,

Also about the joint angle restriction,
it seems that when the joint angle is out of range, ODE will apply a
force to restrict it,
but the motor is still working, then resulting the joint angle
concussion, at last the whole robot disjointed.
After restricting the desired joint angle in our agent (i.e. the robot
should not try to turn an angle out of the range),
the simulation became stable.
However, if a robot missing the restriction itself, the simulation may
interrupted by it...
I think we can set the motor velocity to zero while the joint is out of range.

2007/6/19, Yuan Xu <xuy...@gm...>:
> Hi Joschka,
>
> After some testing, I think it is hard to got a good balance by
> turning global parameters,
> and the results depends on many factors: such as the robot mass, robot
> control ( high or low gain ).
>
> The ODE parameters effects the robot performance greatly, maybe teams
> do not like change at this time...
>
>
> [...]
> >
> > Increasing the global CFM is recommended for numerical stability, but it
> > may also result in softer joints in general, including the contact
> > joints. So if the parameter is increased too much, the ball and the
> > robots might sink into the ground! It's difficult, but it might be worth
> > playing around with the global CFM and ERP parameters, and maybe also
> > try to set local CFM and ERP values for the individual joints (or joint
> > stops). As a start, one could try sth. like
> >
> > world.setCFM(0.01)
> > world.setERP(0.9)
> >
> > in spark.rb, and see if it changes the stability of the simulation in a
> > positive way.
> >
>
>
>
> --
> Best wishes!
>
> Xu Yuan
> School of Automation
> Southeast University, Nanjing, China
>
> mail:   xuy...@gm...
>           xy...@ya...
> web:   http://xuyuan.cn.googlepages.com
> --------------------------------------------------
>


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] new problem of new server

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

Hi Joschka,

After some testing, I think it is hard to got a good balance by
turning global parameters,
and the results depends on many factors: such as the robot mass, robot
control ( high or low gain ).

The ODE parameters effects the robot performance greatly, maybe teams
do not like change at this time...


[...]
>
> Increasing the global CFM is recommended for numerical stability, but it
> may also result in softer joints in general, including the contact
> joints. So if the parameter is increased too much, the ball and the
> robots might sink into the ground! It's difficult, but it might be worth
> playing around with the global CFM and ERP parameters, and maybe also
> try to set local CFM and ERP values for the individual joints (or joint
> stops). As a start, one could try sth. like
>
> world.setCFM(0.01)
> world.setERP(0.9)
>
> in spark.rb, and see if it changes the stability of the simulation in a
> positive way.
>



-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] Agents may intersect...

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

Hi Joschka,
This problem is not restricted to the BeamEffector I think. The same 
think may happen when ClearPlayers functions are used (right?!). If so, 
number 1 is not an option at all. The ClearPlayers functions may either 
try generating random positions until a safe position is found, or find 
a safe position directly.
But for the BeamEffector, I'm agree with 2 (or even 1) since it is used 
only in before kickoff mode and beaming into the same position is 
unlikely. (Also, the agent might be confused if it is placed somewhere 
other than the requested position.)

And I think I have at least enough time to implement 2. But I'm mostly 
considered about ClearPlayer functions, the game shouldn't stop after 
kickoff.

What do you think?

Good luck,
Hedayat


/*Joschka Boedecker <jbo...@un...>*/ wrote on 06/18/2007 
12:55:47 PM:
> Hi Hedayat,
>
> On Mon, 2007-06-18 at 02:12 +0330, Hedayat Vatankhah wrote:
>
>   
>> There is a problem when MoveAgent(AndRotate) functions are used: there
>> might be another object in the destination! This happens for example
>> when two agents beam into the same place which will slow down the
>> simulation significantly. It seems that these functions should place
>> the agent into the nearest empty position to the destination point. Or
>> maybe the empty position is found before calling these functions.
>>     
>
> Yes, you're right. There are several possibilities:
>
> 1) We could say it is the teams' responsibility to avoid these kinds of
> situations. This is risky, however, and might lead to lots of games
> having to be restarted if the server is not responsive anymore. It also
> creates problems how to deal with these situations in the rules (should
> the team that caused this be punished in some way, etc).
>
> 2) We could check the position in the BeamEffector and only execute the
> command if no BoundingBoxes intersect. If there is an intersection, the
> command is simply ignored (we might think about a message to the agent
> in this case).
>
> 3) The BeamEffector does the check and also figures out a safe position
> for the agent. This might be a non-trivial task, however, depending on
> the configuration of agents.
>
> Since we don't have much time, I'd favor 2). What do you think? And
> also, do you think you'd have time to work on this? 
>
> Cheers,
> Joschka
>
>   

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi,
Yes, I'm agree! (in fact, we've used something similar in our 3D teams:))
However, the last line should be FRM....................FRO! :)

Cheers,
Hedayat

/*Joschka Boedecker <jbo...@un...>*/ wrote on 06/18/2007 
02:12:44 PM:
> Hi,
>
> On Mon, 2007-06-18 at 16:34 +0800, Yuan Xu wrote:
>   
>> Hi Hedayat,
>>
>>
>>     
>>>  There is a problem; currently the right team can't think that they are on
>>> the left because: 1. the init message says: (team right) 2. All of the game
>>> states use "right" for that team (e.g. KickOffRight). I just want to say
>>> that it would be better if we use "left" and "right" consistently.
>>>  To be more consistent, we may avoid using left and right for the flags
>>> altogether. For example, we may call: our flags and opponent flags! And we
>>> may use left and right instead of 1 and 2 which are used currently. So, we
>>> will have "our left flag(FLO), our right flag (FRO),..."!! (This is an
>>> example only).
>>>
>>>       
>> Good idea! This is what exactly my mean ;-)
>> This is useful while teams design strategy and formation, I think.
>>
>> Joschka, will we use the new flag names?
>>     
>
> I think it's a good idea. But we should choose different names from
> "our" and "opponent" (both start with 'O' ;-) ). How about "my team" (M)
> and "opponent team" (0). So it would look like:
>
> FLM....................FLO
>
> GLM....................GLO
>
> GRM....................GRO
>
> FLM....................FLO
>
> ...for the one team, and flipped for the other team, right?
>
> Cheers,
> Joschka
>
>   

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi all,


> Since I also would like to limit the changes the teams have to do (I
> actually do, hard to believe some times I guess ;-) ), I'd propose then
> to keep the names we have now and remove the flipping again. Yuan, could
> you take care of this, please?
>

Well, I am wrong ;-( this is not the work of server.
After remove flipping names, everything should be OK, I think.

BTW, another work I did may be also redundant ;-(
I rotate the angles while agent beam, so that 0 degree is face to opponent goal.
Then, should I also remove this?


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

On Mon, 2007-06-18 at 15:17 +0200, Jan Murray wrote:
[...]
> 
> >> If you label the flags with "my" / "opponent", this is a _semantic_  
> >> annotation of the flag that can't be found on the soccer field. The  
> >> vision perceptor should only deliver the syntactic label of the flag,  
> >> and the intelligence of deciding which side the flags belong to  
> >> should be in the agent, not in the simulator.
> > 
> > Wasn't there something like flipping the labels in the old simulator?
> > Maybe I'm completely wrong though, I didn't check...
> 
> I checked the visionperceptor of version 0.4. There all 
> (x/y)-coordinates were multiplied with -1 for the right team for the 
> static and dynamic axis percept. I think this goes back to the time 
> before we used the dynamic axis. In those days ;-) it was easier to say 
> the x-axis points towards the opponent goal.

Thanks for checking. I knew there was something, but I didn't remember
the details :-/

> What I didn't get from the previous discussion is whether only the 
> flag/goal labels should be flipped, or all positions should be flipped.

Yuan implemented flipping the flag/goal labels.

> >> So IMHO, flipping the labels should be removed from the perceptor,  
> >> and using "left" for the left flags of teams of either side isn't any  
> >> better than the original labels.
> 
> In this case we could perhaps replace left and right with yellow and 
> blue.  This avoids confusion if you move the camera round and the yellow 
> goal is on the right, suddenly.  ;) But then we should apply this to the 
> gamestateperceptor as well.
> 
> > OK, so we leave the old labels and remove the flipping?
> 
> This would be like 2D. IIRC the vision in the 2D simulator was exactly 
> as Oliver proposed.
> 
> I tend to agree with Oliver. It's easy for a team to implement a flip 
> based on their side, but it's (unnecessary) overhead for the simulator.

Since I also would like to limit the changes the teams have to do (I
actually do, hard to believe some times I guess ;-) ), I'd propose then
to keep the names we have now and remove the flipping again. Yuan, could
you take care of this, please?

Cheers,
Joschka

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Joschka Boedecker wrote:
> Hi,
> 
> On Mon, 2007-06-18 at 22:06 +1000, Oliver Obst wrote:
> 
>> On 18/06/2007, at 8:42 PM, Joschka Boedecker wrote:
>>
>>>>>  To be more consistent, we may avoid using left and right for the  
>>>>> flags
>>>>> altogether. For example, we may call: our flags and opponent  
>>>>> flags! And we
>>>>> may use left and right instead of 1 and 2 which are used  
>>>>> currently. So, we
>>>>> will have "our left flag(FLO), our right flag (FRO),..."!! (This  
>>>>> is an
>>>>> example only).
>>>>>
>>>> Good idea! This is what exactly my mean ;-)
>>>> This is useful while teams design strategy and formation, I think.
>>>>
>>>> Joschka, will we use the new flag names?
>>> I think it's a good idea. But we should choose different names from
>>> "our" and "opponent" (both start with 'O' ;-) ). How about "my  
>>> team" (M)
>>> and "opponent team" (0). So it would look like:
>> I'm not sure if I missed something, but as far as I understood the  
>> discussion so far, I don't agree it's a good idea.
>>
>> The flag names (with "left" and "right" for flags on the left/right  
>> side of the field) should be equally perceived by agents of both teams.
>> This is consistent with that real robots on the field see the same  
>> flag on the field in equal colors.
> 
> True.

>> If you label the flags with "my" / "opponent", this is a _semantic_  
>> annotation of the flag that can't be found on the soccer field. The  
>> vision perceptor should only deliver the syntactic label of the flag,  
>> and the intelligence of deciding which side the flags belong to  
>> should be in the agent, not in the simulator.
> 
> Wasn't there something like flipping the labels in the old simulator?
> Maybe I'm completely wrong though, I didn't check...

I checked the visionperceptor of version 0.4. There all 
(x/y)-coordinates were multiplied with -1 for the right team for the 
static and dynamic axis percept. I think this goes back to the time 
before we used the dynamic axis. In those days ;-) it was easier to say 
the x-axis points towards the opponent goal.

What I didn't get from the previous discussion is whether only the 
flag/goal labels should be flipped, or all positions should be flipped.

>> So IMHO, flipping the labels should be removed from the perceptor,  
>> and using "left" for the left flags of teams of either side isn't any  
>> better than the original labels.

In this case we could perhaps replace left and right with yellow and 
blue.  This avoids confusion if you move the camera round and the yellow 
goal is on the right, suddenly.  ;) But then we should apply this to the 
gamestateperceptor as well.

> OK, so we leave the old labels and remove the flipping?

This would be like 2D. IIRC the vision in the 2D simulator was exactly 
as Oliver proposed.

I tend to agree with Oliver. It's easy for a team to implement a flip 
based on their side, but it's (unnecessary) overhead for the simulator.

Bye,
  Jan

Re: [simspark-devel] new problem of new server

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

Hi Yuan,

On Mon, 2007-06-18 at 20:34 +0800, Yuan Xu wrote:
> Hi all,
> 
> It seems there is still a problem in joint stop ;-(
> While the robot have a fall, because of collide, some joint may out of
> the range,
> it seems that ODE add powerful external force to restrict it, then the
> robot will crash...
> I have experimented this many times ;-(

The problem might be, that we have set the joints to be too restrictive.
The ODE manual [1] lists two parameters that can be used to affect the
joint constraints: the Error Reduction Paramter (ERP) and the Constraint
Force Mixing (CFM), cf. sections 3.7 -- 3.8.2 of the manual. 

These parameters can be set globally, as we do e.g. for the CFM in
lib/spark/spark.rb (line 353), or they can be set locally for individual
joints which we don't do right now.

Increasing the global CFM is recommended for numerical stability, but it
may also result in softer joints in general, including the contact
joints. So if the parameter is increased too much, the ball and the
robots might sink into the ground! It's difficult, but it might be worth
playing around with the global CFM and ERP parameters, and maybe also
try to set local CFM and ERP values for the individual joints (or joint
stops). As a start, one could try sth. like

world.setCFM(0.01)
world.setERP(0.9)

in spark.rb, and see if it changes the stability of the simulation in a
positive way.

Yuan, do you think you could do some tests with this?

Cheers,
Joschka

[1] http://ode.org/ode-latest-userguide.html


> 2007/6/16, Yuan Xu <xuy...@gm...>:
> > Hi Jan,
> >
> > You are right!
> > After change 0 to 1, the server works well.
> > It is great that we do not disable this feature ;-)
> >
> 
> 
> 

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi,

On 18/06/2007, at 10:40 PM, Joschka Boedecker wrote:

> Wasn't there something like flipping the labels in the old simulator?
> Maybe I'm completely wrong though, I didn't check...

If I remember correctly, in rcssserver3D, there was the method  
FlipView that was used when the sensor delivered the absolute player  
coordinates (mypos ...). This information was intended for debug  
purposes only, it was required to deliver the same coordinates for  
players independent on the side they were playing on.

Flag names haven't been changed for teams of one side (I think).

> OK, so we leave the old labels and remove the flipping?

well, if you ask me, yes.
Moreover, the change isn't technically necessary, and teams have  
enough work to catch up with the current changes.

cheers
Oliver

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

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi,

On Mon, 2007-06-18 at 22:06 +1000, Oliver Obst wrote:

> On 18/06/2007, at 8:42 PM, Joschka Boedecker wrote:
> 
> >>>  To be more consistent, we may avoid using left and right for the  
> >>> flags
> >>> altogether. For example, we may call: our flags and opponent  
> >>> flags! And we
> >>> may use left and right instead of 1 and 2 which are used  
> >>> currently. So, we
> >>> will have "our left flag(FLO), our right flag (FRO),..."!! (This  
> >>> is an
> >>> example only).
> >>>
> >>
> >> Good idea! This is what exactly my mean ;-)
> >> This is useful while teams design strategy and formation, I think.
> >>
> >> Joschka, will we use the new flag names?
> >
> > I think it's a good idea. But we should choose different names from
> > "our" and "opponent" (both start with 'O' ;-) ). How about "my  
> > team" (M)
> > and "opponent team" (0). So it would look like:
> 
> I'm not sure if I missed something, but as far as I understood the  
> discussion so far, I don't agree it's a good idea.
> 
> The flag names (with "left" and "right" for flags on the left/right  
> side of the field) should be equally perceived by agents of both teams.
> This is consistent with that real robots on the field see the same  
> flag on the field in equal colors.

True.

> If you label the flags with "my" / "opponent", this is a _semantic_  
> annotation of the flag that can't be found on the soccer field. The  
> vision perceptor should only deliver the syntactic label of the flag,  
> and the intelligence of deciding which side the flags belong to  
> should be in the agent, not in the simulator.

Wasn't there something like flipping the labels in the old simulator?
Maybe I'm completely wrong though, I didn't check...

> So IMHO, flipping the labels should be removed from the perceptor,  
> and using "left" for the left flags of teams of either side isn't any  
> better than the original labels.

OK, so we leave the old labels and remove the flipping?

Cheers,
Joschka

Re: [simspark-devel] new problem of new server

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

Hi all,

It seems there is still a problem in joint stop ;-(
While the robot have a fall, because of collide, some joint may out of
the range,
it seems that ODE add powerful external force to restrict it, then the
robot will crash...
I have experimented this many times ;-(

2007/6/16, Yuan Xu <xuy...@gm...>:
> Hi Jan,
>
> You are right!
> After change 0 to 1, the server works well.
> It is great that we do not disable this feature ;-)
>



-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi,

On 18/06/2007, at 8:42 PM, Joschka Boedecker wrote:

>>>  To be more consistent, we may avoid using left and right for the  
>>> flags
>>> altogether. For example, we may call: our flags and opponent  
>>> flags! And we
>>> may use left and right instead of 1 and 2 which are used  
>>> currently. So, we
>>> will have "our left flag(FLO), our right flag (FRO),..."!! (This  
>>> is an
>>> example only).
>>>
>>
>> Good idea! This is what exactly my mean ;-)
>> This is useful while teams design strategy and formation, I think.
>>
>> Joschka, will we use the new flag names?
>
> I think it's a good idea. But we should choose different names from
> "our" and "opponent" (both start with 'O' ;-) ). How about "my  
> team" (M)
> and "opponent team" (0). So it would look like:

I'm not sure if I missed something, but as far as I understood the  
discussion so far, I don't agree it's a good idea.

The flag names (with "left" and "right" for flags on the left/right  
side of the field) should be equally perceived by agents of both teams.
This is consistent with that real robots on the field see the same  
flag on the field in equal colors.

If you label the flags with "my" / "opponent", this is a _semantic_  
annotation of the flag that can't be found on the soccer field. The  
vision perceptor should only deliver the syntactic label of the flag,  
and the intelligence of deciding which side the flags belong to  
should be in the agent, not in the simulator.

So IMHO, flipping the labels should be removed from the perceptor,  
and using "left" for the left flags of teams of either side isn't any  
better than the original labels.

cheers
Oliver

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

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi,

On Mon, 2007-06-18 at 16:34 +0800, Yuan Xu wrote:
> Hi Hedayat,
> 
> 
> >  There is a problem; currently the right team can't think that they are on
> > the left because: 1. the init message says: (team right) 2. All of the game
> > states use "right" for that team (e.g. KickOffRight). I just want to say
> > that it would be better if we use "left" and "right" consistently.
> >  To be more consistent, we may avoid using left and right for the flags
> > altogether. For example, we may call: our flags and opponent flags! And we
> > may use left and right instead of 1 and 2 which are used currently. So, we
> > will have "our left flag(FLO), our right flag (FRO),..."!! (This is an
> > example only).
> >
> 
> Good idea! This is what exactly my mean ;-)
> This is useful while teams design strategy and formation, I think.
> 
> Joschka, will we use the new flag names?

I think it's a good idea. But we should choose different names from
"our" and "opponent" (both start with 'O' ;-) ). How about "my team" (M)
and "opponent team" (0). So it would look like:

FLM....................FLO

GLM....................GLO

GRM....................GRO

FLM....................FLO

...for the one team, and flipped for the other team, right?

Cheers,
Joschka

Re: [simspark-devel] Gyro fixed!

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

Hi Hedayat,

On Mon, 2007-06-18 at 02:03 +0330, Hedayat Vatankhah wrote:
> Hi Joschka and Oliver,
> 
> I've fixed gyro rate perceptor so that the output is in local
> coordinates rather than global coordinates now. Hopefully it'll work
> correctly! ;)

Great, thank you! I had a look at the code and it looked correct to me.
I couldn't test it yet, but I asked the guys from the Virtual Werder
team if they could have a look.

> And a little question about ClearPlayers functions: is it desired (and
> it worths) to consider the whole agent body rather than one single
> point to decide if the agent should be moved?

I'm not sure about this one right now. I changed the test in the
ClearPlayers function so that the point to test is projected to the same
hight as the object of interest (usually the ball). From what I've seen,
this gives rather good results, but might need more tests. If it turns
out not to work well, we should use the BoundingBox.

Cheers,
Joschka

Re: [simspark-devel] Agents may intersect...

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

Hi Hedayat,

On Mon, 2007-06-18 at 02:12 +0330, Hedayat Vatankhah wrote:

> There is a problem when MoveAgent(AndRotate) functions are used: there
> might be another object in the destination! This happens for example
> when two agents beam into the same place which will slow down the
> simulation significantly. It seems that these functions should place
> the agent into the nearest empty position to the destination point. Or
> maybe the empty position is found before calling these functions.

Yes, you're right. There are several possibilities:

1) We could say it is the teams' responsibility to avoid these kinds of
situations. This is risky, however, and might lead to lots of games
having to be restarted if the server is not responsive anymore. It also
creates problems how to deal with these situations in the rules (should
the team that caused this be punished in some way, etc).

2) We could check the position in the BeamEffector and only execute the
command if no BoundingBoxes intersect. If there is an intersection, the
command is simply ignored (we might think about a message to the agent
in this case).

3) The BeamEffector does the check and also figures out a safe position
for the agent. This might be a non-trivial task, however, depending on
the configuration of agents.

Since we don't have much time, I'd favor 2). What do you think? And
also, do you think you'd have time to work on this? 

Cheers,
Joschka

Re: [simspark-devel] Problem with the vision perceptor (I think!)

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

Hi Hedayat,


>  There is a problem; currently the right team can't think that they are on
> the left because: 1. the init message says: (team right) 2. All of the game
> states use "right" for that team (e.g. KickOffRight). I just want to say
> that it would be better if we use "left" and "right" consistently.
>  To be more consistent, we may avoid using left and right for the flags
> altogether. For example, we may call: our flags and opponent flags! And we
> may use left and right instead of 1 and 2 which are used currently. So, we
> will have "our left flag(FLO), our right flag (FRO),..."!! (This is an
> example only).
>

Good idea! This is what exactly my mean ;-)
This is useful while teams design strategy and formation, I think.

Joschka, will we use the new flag names?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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