simspark-devel

[simspark-devel] new problem of new server

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

Hi Joschka,

I do some tests under the situation that one agent connected server, I
faced new problems ;-(

(1) see http://picasaweb.google.com/xuyuan.cn/RCS/photo#5076361988020790178
    * Situation: after beam action
    * Problem: the lower torso rotation is not correct

(2) see http://picasaweb.google.com/xuyuan.cn/RCS/photo#5076361988020790194
    * Situation: after first joint action, the action was "(rae1_2
-0.137532 0.623955)"
    * Problem: the body disjoint while the agent starting use joint
effector, and after that moment it seems OK.
               However this is very bad, because when the agent try to
walk, it will jump at the beginning ;-(

I hope we could fix them quickly.

-- 
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 Sat, 2007-06-16 at 02:42 +0800, Yuan Xu wrote:
> Hi Joschka,
> 
> I do some tests under the situation that one agent connected server, I
> faced new problems ;-(

Which version are you using, current CVS or the 0.5.6-preview?

> (1) see http://picasaweb.google.com/xuyuan.cn/RCS/photo#5076361988020790178
>     * Situation: after beam action
>     * Problem: the lower torso rotation is not correct

Does this happen everytime? I have never observed this as of yet...

> (2) see http://picasaweb.google.com/xuyuan.cn/RCS/photo#5076361988020790194
>     * Situation: after first joint action, the action was "(rae1_2
> -0.137532 0.623955)"
>     * Problem: the body disjoint while the agent starting use joint
> effector, and after that moment it seems OK.
>                However this is very bad, because when the agent try to
> walk, it will jump at the beginning ;-(

Could you please try to comment out the joint stops in the soccerbot.rsg
file? I suspect them to have something to do with this problem. 

The joint stops were easy to implement, but I'm afraid that some ODE
parameters might have to be adjusted to be able to use them in a stable
way. If this is the case, I have to remove the joint stops again for
now, since we don't have much time to find good parameters currently :-(

> I hope we could fix them quickly.

Me too, believe me ;-) Thanks for your help!

Joschka

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

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

Hi Joschka,

> Which version are you using, current CVS or the 0.5.6-preview?

0.5.6-preview

> > (1) see http://picasaweb.google.com/xuyuan.cn/RCS/photo#5076361988020790178
> >     * Situation: after beam action
> >     * Problem: the lower torso rotation is not correct
>
> Does this happen everytime? I have never observed this as of yet...

Yes, everytime. Since it is corrected by ODE quickly, you can got the
screen shot frame by frame with the logfile. And it is reasonable
according to the codes, all body rotations are set to only Z rotation.


>
> Could you please try to comment out the joint stops in the soccerbot.rsg
> file? I suspect them to have something to do with this problem.

Yes, it works after comment out the joint stops.

> The joint stops were easy to implement, but I'm afraid that some ODE
> parameters might have to be adjusted to be able to use them in a stable
> way. If this is the case, I have to remove the joint stops again for
> now, since we don't have much time to find good parameters currently :-(

Well, doing is usually harder than thinking.
Maybe human referee can take this responsibility ;-)


-- 
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 Sat, 2007-06-16 at 11:29 +0800, Yuan Xu wrote:
> Hi Joschka,
> 
> > Which version are you using, current CVS or the 0.5.6-preview?
> 
> 0.5.6-preview
> 
> > > (1) see http://picasaweb.google.com/xuyuan.cn/RCS/photo#5076361988020790178
> > >     * Situation: after beam action
> > >     * Problem: the lower torso rotation is not correct
> >
> > Does this happen everytime? I have never observed this as of yet...
> 
> Yes, everytime. Since it is corrected by ODE quickly, you can got the
> screen shot frame by frame with the logfile. And it is reasonable
> according to the codes, all body rotations are set to only Z rotation.

I'm sorry, I somehow thought you were referring to the movement that the
InitEffector performs. You are right, of course, the BeamEffector only
sets Z-Rotation. Since the rotation feature doesn't reliably work right
now (at least not when used several times, cf. messages on the Sserver3D
ML), I think I'll comment out the code for the rotation for the final
release. I won't have time to fix this issue, so teams will have to turn
by themselves :-(

> >
> > Could you please try to comment out the joint stops in the soccerbot.rsg
> > file? I suspect them to have something to do with this problem.
> 
> Yes, it works after comment out the joint stops.

OK, thank you for the confirmation.

> > The joint stops were easy to implement, but I'm afraid that some ODE
> > parameters might have to be adjusted to be able to use them in a stable
> > way. If this is the case, I have to remove the joint stops again for
> > now, since we don't have much time to find good parameters currently :-(
> 
> Well, doing is usually harder than thinking.
> Maybe human referee can take this responsibility ;-)

Yes, I think so, too. We'll have to have some kind of statement in the
rules that forbids, e.g. using the feet as wheels, but it's difficult to
formulate it to be "non-fuzzy".

It seems certain, though, that we can not use joint stops reliably right
now. I will comment out the joint stops for the final release.

Thanks again for doing these tests,
Joschka

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

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

Hi all,

Joschka Boedecker wrote:

>>> Could you please try to comment out the joint stops in the soccerbot.rsg
>>> file? I suspect them to have something to do with this problem.
>> Yes, it works after comment out the joint stops.
> 
> OK, thank you for the confirmation.

I made the following observation. I let the soccerbot try to do some 
squats, i.e. after the init command it only sent the fixed string
"(rle4 -0.5)(rle2_3 0.5 0)(lle4 -0.5)(lle2_3 0.5 0)". The movement 
*always* started with a little jump. Commenting out the (setHighStopDeg 
0 X) statements for rle4 and lle4 made this go away. Changing the 
allowed maxangle from 0 to 1 also made the jumping go away.  So the 
problem could be that the joints are already at a stop, when the 
movement starts.

>>> The joint stops were easy to implement, but I'm afraid that some ODE
>>> parameters might have to be adjusted to be able to use them in a stable
>>> way. If this is the case, I have to remove the joint stops again for
>>> now, since we don't have much time to find good parameters currently :-(
>> Well, doing is usually harder than thinking.
>> Maybe human referee can take this responsibility ;-)

This year the referees will probably have a lot of responsibilities, 
which usually means less volunteers.  :-(

> Yes, I think so, too. We'll have to have some kind of statement in the
> rules that forbids, e.g. using the feet as wheels, but it's difficult to
> formulate it to be "non-fuzzy".

I will add a section about using common sense to the rules, which states 
something like "even if this behavior does not violate the rules on the 
syntactic level, YOU and ME know it's wrong and therefore we are going 
to treat it as wrong".

> It seems certain, though, that we can not use joint stops reliably right
> now. I will comment out the joint stops for the final release.

:-(

Perhaps adding 1 degree to the max/min would be okay (see above).
Yuan could you test this?


Thanks,
Jan

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

[Yuan Xu <xy...@ya...>]

Hi Jan,


> 
> I made the following observation. I let the
> soccerbot try to do some 
> squats, i.e. after the init command it only sent the
> fixed string
> "(rle4 -0.5)(rle2_3 0.5 0)(lle4 -0.5)(lle2_3 0.5
> 0)". The movement 
> *always* started with a little jump. Commenting out
> the (setHighStopDeg 
> 0 X) statements for rle4 and lle4 made this go away.
> Changing the 
> allowed maxangle from 0 to 1 also made the jumping
> go away.  So the 
> problem could be that the joints are already at a
> stop, when the 
> movement starts.

Great!
That reminds me that the some values of HOAP-2
specification are 91, 31 ;-)

> 
> Perhaps adding 1 degree to the max/min would be okay
> (see above).
> Yuan could you test this?
> 

OK, I will try.

      BEST WISHES!
  
  
 Xu Yuan
 
School of Automation
Southeast University, Nanjing, China

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











	
		
___________________________________________________________ 
Mp3疯狂搜-新歌热歌高速下
http://music.yahoo.com.cn/?source=mail_mailbox_footer

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

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

SGkgSmFuLAoKWW91IGFyZSByaWdodCEKQWZ0ZXIgY2hhbmdlIDAgdG8gMSwgdGhlIHNlcnZlciB3
b3JrcyB3ZWxsLgpJdCBpcyBncmVhdCB0aGF0IHdlIGRvIG5vdCBkaXNhYmxlIHRoaXMgZmVhdHVy
ZSA7LSkKCjIwMDcvNi8xNiwgWXVhbiBYdSA8eHljaG4xNUB5YWhvby5jb20uY24+Ogo+IEhpIEph
biwKPgo+Cj4gPgo+ID4gSSBtYWRlIHRoZSBmb2xsb3dpbmcgb2JzZXJ2YXRpb24uIEkgbGV0IHRo
ZQo+ID4gc29jY2VyYm90IHRyeSB0byBkbyBzb21lCj4gPiBzcXVhdHMsIGkuZS4gYWZ0ZXIgdGhl
IGluaXQgY29tbWFuZCBpdCBvbmx5IHNlbnQgdGhlCj4gPiBmaXhlZCBzdHJpbmcKPiA+ICIocmxl
NCAtMC41KShybGUyXzMgMC41IDApKGxsZTQgLTAuNSkobGxlMl8zIDAuNQo+ID4gMCkiLiBUaGUg
bW92ZW1lbnQKPiA+ICphbHdheXMqIHN0YXJ0ZWQgd2l0aCBhIGxpdHRsZSBqdW1wLiBDb21tZW50
aW5nIG91dAo+ID4gdGhlIChzZXRIaWdoU3RvcERlZwo+ID4gMCBYKSBzdGF0ZW1lbnRzIGZvciBy
bGU0IGFuZCBsbGU0IG1hZGUgdGhpcyBnbyBhd2F5Lgo+ID4gQ2hhbmdpbmcgdGhlCj4gPiBhbGxv
d2VkIG1heGFuZ2xlIGZyb20gMCB0byAxIGFsc28gbWFkZSB0aGUganVtcGluZwo+ID4gZ28gYXdh
eS4gIFNvIHRoZQo+ID4gcHJvYmxlbSBjb3VsZCBiZSB0aGF0IHRoZSBqb2ludHMgYXJlIGFscmVh
ZHkgYXQgYQo+ID4gc3RvcCwgd2hlbiB0aGUKPiA+IG1vdmVtZW50IHN0YXJ0cy4KPgo+IEdyZWF0
IQo+IFRoYXQgcmVtaW5kcyBtZSB0aGF0IHRoZSBzb21lIHZhbHVlcyBvZiBIT0FQLTIKPiBzcGVj
aWZpY2F0aW9uIGFyZSA5MSwgMzEgOy0pCj4KPiA+Cj4gPiBQZXJoYXBzIGFkZGluZyAxIGRlZ3Jl
ZSB0byB0aGUgbWF4L21pbiB3b3VsZCBiZSBva2F5Cj4gPiAoc2VlIGFib3ZlKS4KPiA+IFl1YW4g
Y291bGQgeW91IHRlc3QgdGhpcz8KPiA+Cj4KPiBPSywgSSB3aWxsIHRyeS4KPgo+ICAgICAgIEJF
U1QgV0lTSEVTIQo+Cj4KPiAgWHUgWXVhbgo+Cj4gU2Nob29sIG9mIEF1dG9tYXRpb24KPiBTb3V0
aGVhc3QgVW5pdmVyc2l0eSwgTmFuamluZywgQ2hpbmEKPgo+IG1haWw6ICAgeHV5dWFuLmNuQGdt
YWlsLmNvbQo+ICAgICAgICAgICB4eWNobjE1QHlhaG9vLmNvbS5jbgo+IHdlYjogICBodHRwOi8v
eHV5dWFuLmNuLmdvb2dsZXBhZ2VzLmNvbQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPgo+Cj4KPgo+Cj4KPgo+Cj4KPgo+Cj4KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE1w
M+eWr+eLguaQnC3mlrDmrYzng63mrYzpq5jpgJ/kuIsKPiBodHRwOi8vbXVzaWMueWFob28uY29t
LmNuLz9zb3VyY2U9bWFpbF9tYWlsYm94X2Zvb3Rlcgo+CgoKLS0gCkJlc3Qgd2lzaGVzIQoKWHUg
WXVhbgpTY2hvb2wgb2YgQXV0b21hdGlvbgpTb3V0aGVhc3QgVW5pdmVyc2l0eSwgTmFuamluZywg
Q2hpbmEKCm1haWw6ICAgeHV5dWFuLmNuQGdtYWlsLmNvbQogICAgICAgICAgeHljaG4xNUB5YWhv
by5jb20uY24Kd2ViOiAgIGh0dHA6Ly94dXl1YW4uY24uZ29vZ2xlcGFnZXMuY29tCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCg==

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] 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] 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] 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

[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

[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 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] 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 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

[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

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

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

Hi,


> Nonetheless, it looks like your changes about effectors not moving
> joints at the angle limits and restricting the velocity will be
> accepted. Therefore, could you please commit your changes so that I can
> include them in the final release today?
>

I have just committed my changes.
But I think there still a small bug in the soccerbot.rsg line 139
(def $Lae2Min 1)
==>
(def $Lae2Min -1)

In the current setting, the 0 degree (initial angle) is not in the
allowed range.


--
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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