simspark-devel — Discussion about Spark development

Re: [simspark-devel] vision perceptor

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

Hey,


> > Nice ;-)
> > Because of limited bandwidth of network, and there are more robots,
> > I think the vision perceptor should be restrict by:
> > - frequency: maybe one vision sense per 3-5 cycles is enough (it is
> > already implemented, just set a parameter in .rsg file),
>
> A vision message every 4 cycles would mean 12.5 frames per second,
> right? It's not very much, but somewhat realistic I'd say (anybody
> know the frame rate of Nao?). Let's start with that and increase the
> frame rate in case there are problems (if the network and the server
> can handle it).


I'm not sure yet whether I agree on this. On one side I think it's
reasonable to say a Nao can't acquire images and process them to the high
level information our vision perceptor gives in more than 12.5 fps. But on
the other side I think 3D sim should be able to do things that are not
possible yet in the real leagues and we can asume that in a few years
humanoid robots will be able to do this processing. However when network
bandwidth is really running out of course it's an important point (although
then switching to a far more efficient/binary communication method may be a
better solution). Does anybody have any data on this, e.g. mb/sec sent by
the server?

> - distance: the robot can not be seen or can not be seen clearly
> > (i.e. can not see its arms and legs) if it is far away.
> > What do you think about it?
>
> In principal it's a nice idea, but given our relatively small field
> size (sth. between 6mx4m and 12mx8m, to be decided), I'm not sure
> whether this is realistic. Other opinions? Should we wait with this
> until we're playing on bigger fields?


The same holds here. I think a Nao with the current level of real time
computer vision methods may have a hard time to figure out another agent's
pose over more than a few meters. However a human player (the standard to
achieve in 2050) can do so from across a real size football field.

Though if it is really necesary for bandwidth reasons, these are good
restrictions for now, which probably won't make too big a difference for
game play considering the current level and speed of games.

>
> >> I've proposed these changes to the TC and those members who have
> >> joined the discussion were (mostly) in favor of their implementation
> >> for RC08 _if_ it can be done within the next two weeks. Therefore I'd
> >> like to ask for volunteers for this task. If you think you could help
> >> with this, please contact me as soon as possible.
> >
> > That is very hurry schedule, does anyone like to try?
>
> Yes, unfortunately :-( But it seems necessary since this is quite a
> big change, so teams need time to adapt.
>
> One more thing: it was mentioned that information about the lines
> should be included in the vision messages if the field of vision is
> restricted since we only have a few flags for orientation. What do you
> think about that?


It would be a nice extra, especially if noise is used again and definatly
with the distance restriction suggested by Yuan also applied to goal posts
and flags. But maybe not a necesary one, in the spheres age teams didn't
have problems doing localization without line information either. In light
of the tight schedule I think this can be on the bottom of the vision TODO
list.

Cheers,

Sander

Re: [simspark-devel] Simspark Todo

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

Hey everybody,

Due to my notebook being away for repair (and the task of getting my master
thesis finally finished) I am not able to do much MC work at the moment, but
I'll comment anyway :)

> * no camera error (maybe just on my own machine?)
>
> The output is the same here, but it seems no problem to run the simulation.
> @Sander, do you know what does it mean?


Sorry, this was meant as debug output. I will remove it. If anybody hasn't
seen it yet, it is now possible to put a camera in an agent's head and
rotate through the cameras in the monitor using the , and . keys. It's fun
to watch the game from an agent's perspective :-) I was planning to use this
to make a CustomRender which displays first person view as a
picture-in-picture, like the webots simulator does, but haven't come to it
yet. And perhaps there are more urgent things to focus on.


> > * read camera positions for the monitor from configuration file
>
> I think we may add variables in the .rb files, right?


Ran in that too, should indeed be in [nao]soccersim.rb.

> * adjust field size (right now, it seems we'll have 12mx8m field size),
> > including colliders, etc.
>
> What kind of size should we have, the size of Humanoid League ?


12x8 looks good, nice and big to promote team play

> Can you think of anything else that needs to be addressed?
>
> There are some ODE parameters about robot are need to adjust, such as
> joint motor max force, etc.
> @Feng, would you take this?


This is high priority I think. The agent's power should be toned down
greatly. Teams are already working on gaits/kicks/strategy based on the
current settings, getting to the absurd ways of getting up/walking/kicking
as seen with soccerbot. Strategies like scoring straight from a goal kick,
on which most teams seemed to focus in recent competitions, though legal
according to current rules and the official FIFA rules, should be beatable.
For this the agent's power must be decreased significantly and this should
be done soon, so teams can adapt to it. So if anybody has the official Nao
motor specs available..

Cheers,

Sander

[simspark-devel] [Fwd: Re: Simspark Todo]

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"   cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>Re: [simspark-devel] Simspark Todo</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Fri, 16 May 2008 19:36:51 +0430</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>Hedayat Vatankhah <a class="moz-txt-link-rfc2396E" href="mailto:hed...@ai...">&lt;hed...@ai...&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td>Yuan Xu <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">References: </th>
      <td><a class="moz-txt-link-rfc2396E" href="mailto:243...@am...">&lt;243...@am...&gt;</a>
<a class="moz-txt-link-rfc2396E" href="mailto:18a...@ma...">&lt;18a...@ma...&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<span><br>
<br>
<style type="text/css">blockquote {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 {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>"Yuan
Xu" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"   href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i>
wrote on 05/16/2008 07:06:46 AM:</span><br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">Hi Joschka,
...
  </pre>
  <blockquote type="cite">
    <pre wrap="">* crash of simspark when started outside of local directory
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I have not encounter this problem, is there anyone who want to trace
the problem?
  </pre>
</blockquote>
Hi Yuan, Joschka and all!<br>
First, sorry for being off for a while. And also for not testing CVS
version (and 0.5.8 preview) recently. We (our team) still don't know if
we can register and participate in the competitions, and we are
struggling about some issues... :(. That's too bad, we hoped to be able
to participate this year. Anyway, I'm just a bit tired and it takes me
some time to refresh.<br>
I've fixed this problem. <br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">...
  <blockquote type="cite">
    <pre wrap="">* read camera positions for the monitor from configuration file
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think we may add variables in the .rb files, right?
  </pre>
</blockquote>
I think so. Adding variables and using them if they are hard-coded now.<br>
<br>
(And something off topic:<br>
Recently I saw this: <a moz-do-not-send="true"   class="moz-txt-link-freetext"   href="http://fedoraproject.org/wiki/SIGs/Robotics">http://fedoraproject.org/wiki/SIGs/Robotics</a>.
They
are interested in our server, so I decided to go for it. Hopefully (if
everything goes well), rcssserver3d will become a part of Fedora - an
official Fedora package :) )<br>
<br>
Bye for now,<br>
Hedayat<br>
</body>
</html>

Re: [simspark-devel] vision perceptor

[Joschka B. <jos...@am...>]

Hi Yuan,

thanks for the quick reply :-)

On May 16, 2008, at 11:48 AM, Yuan Xu wrote:

>
>> a while ago, we started discussions about a new vision perceptor for
>> the agents which would be restricted in its field of view, and tied  
>> to
>> the orientation of it's parent body. Furthermore, we talked a bit
>> about extending the vision messages for the agents (include
>> information about position of hands and feet of other agents).
>>
>
> Nice ;-)
> Because of limited bandwidth of network, and there are more robots,
> I think the vision perceptor should be restrict by:
> - frequency: maybe one vision sense per 3-5 cycles is enough (it is
> already implemented, just set a parameter in .rsg file),

A vision message every 4 cycles would mean 12.5 frames per second,  
right? It's not very much, but somewhat realistic I'd say (anybody  
know the frame rate of Nao?). Let's start with that and increase the  
frame rate in case there are problems (if the network and the server  
can handle it).

> - distance: the robot can not be seen or can not be seen clearly
> (i.e. can not see its arms and legs) if it is far away.
> What do you think about it?

In principal it's a nice idea, but given our relatively small field  
size (sth. between 6mx4m and 12mx8m, to be decided), I'm not sure  
whether this is realistic. Other opinions? Should we wait with this  
until we're playing on bigger fields?

>
>> I've proposed these changes to the TC and those members who have
>> joined the discussion were (mostly) in favor of their implementation
>> for RC08 _if_ it can be done within the next two weeks. Therefore I'd
>> like to ask for volunteers for this task. If you think you could help
>> with this, please contact me as soon as possible.
>
> That is very hurry schedule, does anyone like to try?

Yes, unfortunately :-( But it seems necessary since this is quite a  
big change, so teams need time to adapt.

One more thing: it was mentioned that information about the lines  
should be included in the vision messages if the field of vision is  
restricted since we only have a few flags for orientation. What do you  
think about that?

> If you are all too busy, I would like to have a try.
>

That's great! Thanks a lot, Yuan. If there's anybody else who would  
like to help, I'm sure Yuan would wouldn't mind ;-)

Cheers,
Joschka

Re: [simspark-devel] vision perceptor

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

Hi Joschka,


> a while ago, we started discussions about a new vision perceptor for
> the agents which would be restricted in its field of view, and tied to
> the orientation of it's parent body. Furthermore, we talked a bit
> about extending the vision messages for the agents (include
> information about position of hands and feet of other agents).
>

Nice ;-)
Because of limited bandwidth of network, and there are more robots,
I think the vision perceptor should be restrict by:
 - frequency: maybe one vision sense per 3-5 cycles is enough (it is
already implemented, just set a parameter in .rsg file),
 - distance: the robot can not be seen or can not be seen clearly
(i.e. can not see its arms and legs) if it is far away.
What do you think about it?

> I've proposed these changes to the TC and those members who have
> joined the discussion were (mostly) in favor of their implementation
> for RC08 _if_ it can be done within the next two weeks. Therefore I'd
> like to ask for volunteers for this task. If you think you could help
> with this, please contact me as soon as possible.

That is very hurry schedule, does anyone like to try?
If you are all too busy, I would like to have a 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] Simspark Todo

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

Hi Joschka,


> from the messages on the mailing lists, I've compiled a short list of todo
> items that (if possible) should be addressed for the final release of
> rcssserver3d for RC08. Could you please have a look at them and try to find
> people that take of them?

Thanks for getting them together.
I think we may finished them in rcssserver3d-0.5.9.
@All: If you are interesting with some task, please go down to it and
let us know ;-)

> * crash of simspark when started outside of local directory

I have not encounter this problem, is there anyone who want to trace
the problem?

> * InitEffector: needs to deal with several materials

We have discussed it already. I think I can work on this.

> * usemtl null in torso .obj file of Nao

Sorry, I will check what wrong with the .blender file.

> * no camera error (maybe just on my own machine?)

The output is the same here, but it seems no problem to run the simulation.
@Sander, do you know what does it mean?

> * read camera positions for the monitor from configuration file

I think we may add variables in the .rb files, right?

> * restricted vision perceptor and changes in the vision message (see my last
> mail to simspark-devel)

It is very important, let's discuss in that mail.

> * unify material names used in the different .blend files (e.g. naowhite,
> naoblue, naoread, etc., maybe this is fixed already, but a while ago I
> noticed that there were many different names resulting in many different
> materials being created unnecessarily)

Yes, I will deal it.

> Later, we'll also need:
>
> * integrate Soccerbot meshes (as soon as I get them from Heni)

Great!

> * 3D model of the goal for the Nao simulation (I'll try to model this in
> Blender, but I'm too busy right now)

Do not hurry.

> * adjust field size (right now, it seems we'll have 12mx8m field size),
> including colliders, etc.

What kind of size should we have, the size of Humanoid League ?

> * try to get a model of either: a skybox around the pitch, or a kind of hall
> (like in RoboCup ;-) ), but this is just for having nice visuals ;-)

Nice idea.

> * ball parameters (do we need to change them?)

@Feng, I think you have already to adjust them, would try to make it better?

> Can you think of anything else that needs to be addressed?

There are some ODE parameters about robot are need to adjust, such as
joint motor max force, etc.
@Feng, would you take this?

I hope we can have the preview of rcssserver3d-0.5.9 in the next weekend.
What do you think about it?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

[simspark-devel] vision perceptor

[Joschka B. <jos...@am...>]

Hi all,

a while ago, we started discussions about a new vision perceptor for  
the agents which would be restricted in its field of view, and tied to  
the orientation of it's parent body. Furthermore, we talked a bit  
about extending the vision messages for the agents (include  
information about position of hands and feet of other agents).

I've proposed these changes to the TC and those members who have  
joined the discussion were (mostly) in favor of their implementation  
for RC08 _if_ it can be done within the next two weeks. Therefore I'd  
like to ask for volunteers for this task. If you think you could help  
with this, please contact me as soon as possible.

Thanks a lot in advance!

Joschka

Re: [simspark-devel] preview of rcssserver3d-0.5.8

[Feng X. <hen...@ma...>]

Hi all,

It is great!

According to the time schedule, nearly all the features are included now, though the version is 0.5.8 instead of 0.6rc1. We nearly catch up with the schedule now! I hope we will have the final release 0.6 at 05/14.

Best Regards,
Feng Xue
2008-05-05



Sent By： Yuan Xu
Sent At： 2008-05-05 22:14:52
Sent To： Joschka Boedecker; Mosalam Ebrahimi
CC To： simspark-devel
Topic： [simspark-devel] preview of rcssserver3d-0.5.8

Hi all,
The rcssserver3d-0.5.8 is ready ;-)
You can get it from
http://xuyuan.cn.googlepages.com/rcssserver3d-0.5.8-preview.tar.gz
Could you test this package? Thanks!
 In this release, we have a simulator which is much more like the
 RoboCup Humanoid League: The smaller size, the smaller robot and
 ball. The integrated agent is added as a new feature. Furthermore,
 the external monitor works now.
* New Robot Models:
 - Nao: robot from Aldebaran Robotics, see rsg/agent/nao/nao.rsg. The
 robot looks great with textures.
 - soccerbot058: robot based on soccerbotcomp with joint limits, and
   its size are scaled ( default 0.1 ), see
   rsg/agent/soccerbot058/soccerbot.rsg.
* New Nao Soccer Simulation:
 The simulator start naosoccersim.rb in default now, the new field
 size is the same as RoboCup Standard Platform League, please see
 naosoccersim.rb for details. The old soccersim.rb are still there,
 you can switch between naosoccersim and soccersim in simspark.rb.
* New Feature:
 - Integrated Feature: The agent can run internally now, in this case
 it is easier to debug the skill that you have designed, since it can
 get the simulation information directly. Note that the action is
 performed with a delay of one cycle (This is just like external
 agent). There is an example in plugin/soccer/integration. To run the
 demo just enable two lines in the simspark.rb:
 sparkSetupTrain()
 addIntegratedAgent('SoccerbotBehavior',1)
* Important Fixes:
 - the external monitor works now, you can run to monitor remotely(set
 $monitorServer in spark.rb). And also, the internal monitor can be
 disabled by setting $enableInternalMonitor to false in simspark.rb.
 - the OBJ importer is extended, we have really good 3D graphics now.
 - joint limits: the simulation runs stably with joint limits.
For details have a look into the ChangeLog coming with the package.
-- 
Best wishes!
Xu Yuan
School of Automation
Southeast University, Nanjing, China
mail: xuy...@gm...
 xy...@ya...
web: http://xuyuan.cn.googlepages.com
--------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
sim...@li...
https://lists.sourceforge.net/lists/listinfo/simspark-devel

[simspark-devel] preview of rcssserver3d-0.5.8

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

Hi all,

The rcssserver3d-0.5.8 is ready ;-)
You can get it from
http://xuyuan.cn.googlepages.com/rcssserver3d-0.5.8-preview.tar.gz
Could you test this package? Thanks!

 In this release, we have a simulator which is much more like the
 RoboCup Humanoid League: The smaller size, the smaller robot and
 ball. The integrated agent is added as a new feature. Furthermore,
 the external monitor works now.

* New Robot Models:
 - Nao: robot from Aldebaran Robotics, see rsg/agent/nao/nao.rsg. The
 robot looks great with textures.
 - soccerbot058: robot based on soccerbotcomp with joint limits, and
   its size are scaled ( default 0.1 ), see
   rsg/agent/soccerbot058/soccerbot.rsg.

* New Nao Soccer Simulation:
 The simulator start naosoccersim.rb in default now, the new field
 size is the same as RoboCup Standard Platform League, please see
 naosoccersim.rb for details. The old soccersim.rb are still there,
 you can switch between naosoccersim and soccersim in simspark.rb.

* New Feature:
 - Integrated Feature: The agent can run internally now, in this case
 it is easier to debug the skill that you have designed, since it can
 get the simulation information directly. Note that the action is
 performed with a delay of one cycle (This is just like external
 agent). There is an example in plugin/soccer/integration. To run the
 demo just enable two lines in the simspark.rb:
 sparkSetupTrain()
 addIntegratedAgent('SoccerbotBehavior',1)

* Important Fixes:
 - the external monitor works now, you can run to monitor remotely(set
 $monitorServer in spark.rb). And also, the internal monitor can be
 disabled by setting $enableInternalMonitor to false in simspark.rb.
 - the OBJ importer is extended, we have really good 3D graphics now.
 - joint limits: the simulation runs stably with joint limits.

For details have a look into the ChangeLog coming with the package.

-- 
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] releasing rcssserver3d-0.5.8 ?

[Joschka B. <jos...@am...>]

Hi all,

On Apr 18, 2008, at 11:25 PM, Hedayat Vatankhah wrote:

>
> I think we can have 0.5.8 even earlier. Nao textures can be prepared  
> for 0.5.9,

I agree.

> and I don't know if a smaller soccerbot is needed.

Even though it's true that we desired a smaller Soccerbot from the  
beginning, I would not give this a high priority for now. I think in  
case the TC decides it is too late for changes, the Soccerbot (comp)  
will be used (and we'll have a great demo of the Nao simulation);  
otherwise, we could use Nao right away.

> If the current soccerbot model is going to be omitted, I think it's  
> best to have 0.5.8 ASAP so that teams will start experimenting with  
> real sized models sooner.

Right.

> I think we should resize the pitch and camera acceleration. However,  
> since OC/TC has not decided yet, we should retain compatibility as  
> you mentioned.
> Finally, we need a smaller ball too!

I think a new soccer pitch for the Nao robot in addition to the old  
one is the way to go (maybe soccersim058 like Yuan suggested). It's  
not decided yet which robot will be used in RC08, so we should be  
prepared to support both (and also in order to use older binaries).

Cheers,
Joschka

>
>
> "Yuan Xu" <xuy...@gm...> wrote on 04/18/2008 01:40:33 PM:
>> Hi Joschka, Hesham and all,
>>
>> Hope everyone have a good weekend !
>>
>> Teams are asking for the model and rule now.
>> We are really far away from our schedule.
>> I hope we can have the final version fro RoboCup 2008.
>> There will be a demo game in Hefei, May 2.
>> So I think it is an good opportunity to test the new feature of  
>> server
>> in this game.
>> Do you think it is possible that releasing rcssserver3d-0.5.8 at the
>> end of this month?
>>
>> I think the new release should contains:
>>  * done:
>>  - Nao model ( thanks Feng for your great work! )
>>  - external monitor works now
>>  - joint limitation
>>  - Extended OBJ importer ( Joschka, correct me if wrong )
>>  - and some other fixing
>>  * to do:
>>  - textures for Nao
>>  - resize the soccerbot and pitch ( Need Open Discussion )
>>
>> Open Discussion:
>> Do you think we need to resize the soccerbot and pitch?
>> I think it is useful to resize them: firstly they are should be  
>> that size,
>> secondly, Nao can work after the pitch resized.
>> Note that simulating different types robot is a good feature of our  
>> simulator.
>> Last year, we have to enlarge the size due the stability of ODE.
>> Joschka, do you think we can resize the robot without problem?
>> However, we also should consider the compatibility,
>> so I think we should creat the soccerbot058 and soccersim058.
>> Then teams and game in May can test this new configuration.
>> What do you think?
>>
>>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel

Re: [simspark-devel] Textures of Nao ?

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

Hi Joschka,

Thanks for your guide!
I have created the head of Nao, ( see the attached files ).
It is really an art work, it costs me nearly the whole day.
And I want to know if there is anything wrong.



>
>  My recommendation would be to start with tutorials on the web, e.g. [1]
> would be very suitable I think. Maybe you found some good ones yourself
> meanwhile, but I learned a lot from this "Blender 3D: Noob to Pro" Wikibook.
> Also great (especially for robot modeling) is the first issue of the
> BlenderArt magazine [2]. They have a tutorial on how to model the "Papero"
> robot from NEC :-) It's a rather simple robot compared to the Nao, but it's
> a good start. Just keep in mind not to use the SubSurf modifiers for the Nao
> model, because it creates too many polygons for our purposes. If you use the
> "Set smooth" button in Blender (in the "Link and Materials" panel), it
> should look good even though you're using just a low number of polygons.
>
>  We also need to create a new soccer pitch and goals for Nao. I started with
> this and I have attached what I did so far (not very much ;-) ). I also
> modeled the goal, but I had trouble with the texture for the goal net, so I
> want to improve it before I send it to you. By the way, I use "Gimp" [3] for
> the texture stuff, and "Inkscape" [4] for vector graphics (like lines, for
> instance). You'll find these as packages in your Linux distribution I think.
> You can open the .xcf files with Gimp and the .svg files with Inkscape.
>
>  Once you have a model in Blender that you would like to export, please
> export it with the Wavefront .obj exporter. Make sure that you select
> "Normals" and "Triangulate" because the importer needs this information.
> Everything else can be left as default values. Put the .obj file into
> app/simspark/models and the .mtl file in app/simspark/materials. When you
> import an .obj file (have a look into the soccerbot RSG files, e.g. for the
> torso), you most likely need to rotate it to have the right orientation (see
> for instance the soccerbotcomp torso, I think I use a Transform node and
> than setLocalRotation 90 180 0 or sth. like that). I'll try to make a short
> article in the Wiki about this soon (or we can create one together, please
> try to share what you learn in the process :-) ).
>
>
> > After all, we hope you can find time to do it.
> >
>
>  Yes, I would like to, but I really can't promise right now. Unfortunately,
> my time is very limited at the moment. :-(
>
>  For now, I hope this information can help to get you started. Please keep
> me posted on your progress and feel free to ask if you have any questions.
>
>  Cheers,
>  Joschka
>
>  [1]
> http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Modeling_a_Simple_Person
>  [2] http://www.blenderart.org/issues/
>  [3] http://www.gimp.org/
>  [4] http://www.inkscape.org/
>
>
>
>
>
>


-- 
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] releasing rcssserver3d-0.5.8 ?

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

Hi Yuan and all,

:) I hope good weekend too!

I think we can have 0.5.8 even earlier. Nao textures can be prepared for 
0.5.9, and I don't know if a smaller soccerbot is needed. If the current 
soccerbot model is going to be omitted, I think it's best to have 0.5.8 
ASAP so that teams will start experimenting with real sized models 
sooner. I think we should resize the pitch and camera acceleration. 
However, since OC/TC has not decided yet, we should retain compatibility 
as you mentioned.
Finally, we need a smaller ball too!

Thanks,
Hedayat

/*"Yuan Xu" <xuy...@gm...>*/ wrote on 04/18/2008 01:40:33 PM:
> Hi Joschka, Hesham and all,
>
> Hope everyone have a good weekend !
>
> Teams are asking for the model and rule now.
> We are really far away from our schedule.
> I hope we can have the final version fro RoboCup 2008.
> There will be a demo game in Hefei, May 2.
> So I think it is an good opportunity to test the new feature of server
> in this game.
> Do you think it is possible that releasing rcssserver3d-0.5.8 at the
> end of this month?
>
> I think the new release should contains:
>  * done:
>  - Nao model ( thanks Feng for your great work! )
>  - external monitor works now
>  - joint limitation
>  - Extended OBJ importer ( Joschka, correct me if wrong )
>  - and some other fixing
>  * to do:
>  - textures for Nao
>  - resize the soccerbot and pitch ( Need Open Discussion )
>
> Open Discussion:
> Do you think we need to resize the soccerbot and pitch?
> I think it is useful to resize them: firstly they are should be that size,
> secondly, Nao can work after the pitch resized.
> Note that simulating different types robot is a good feature of our simulator.
> Last year, we have to enlarge the size due the stability of ODE.
> Joschka, do you think we can resize the robot without problem?
> However, we also should consider the compatibility,
> so I think we should creat the soccerbot058 and soccersim058.
> Then teams and game in May can test this new configuration.
> What do you think?
>
>   

[simspark-devel] releasing rcssserver3d-0.5.8 ?

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

Hi Joschka, Hesham and all,

Hope everyone have a good weekend !

Teams are asking for the model and rule now.
We are really far away from our schedule.
I hope we can have the final version fro RoboCup 2008.
There will be a demo game in Hefei, May 2.
So I think it is an good opportunity to test the new feature of server
in this game.
Do you think it is possible that releasing rcssserver3d-0.5.8 at the
end of this month?

I think the new release should contains:
 * done:
 - Nao model ( thanks Feng for your great work! )
 - external monitor works now
 - joint limitation
 - Extended OBJ importer ( Joschka, correct me if wrong )
 - and some other fixing
 * to do:
 - textures for Nao
 - resize the soccerbot and pitch ( Need Open Discussion )

Open Discussion:
Do you think we need to resize the soccerbot and pitch?
I think it is useful to resize them: firstly they are should be that size,
secondly, Nao can work after the pitch resized.
Note that simulating different types robot is a good feature of our simulator.
Last year, we have to enlarge the size due the stability of ODE.
Joschka, do you think we can resize the robot without problem?
However, we also should consider the compatibility,
so I think we should creat the soccerbot058 and soccersim058.
Then teams and game in May can test this new configuration.
What do you think?

-- 
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] Fixed joint limit issue, nao model V1.0

[Feng X. <hen...@ma...>]

Hi Joschka,

    The current joint limit of leg joint 3:
    left: [-25, 45], right: [-45, 25], and its axis is y.

    So, this phenomena will happen: one leg in in part of the other leg. 

    And such kind of phenomena will happen too when arm joint 1 is -90 and right arm joint 4 is 90(left arm joint 4 is -90), that is lowerarm is in torso!

    So, I think, add these pairs of collision will solve these situation:
    First pair:  left shank and right shank
    Second pair: left lowerarm and torso
    Third pair:  right lowerarm and torso

    Maybe there is another better solution :-D

Cheers!



Feng Xue
2008-04-17



Sent By： Joschka Boedecker
Sent At： 2008-04-17 15:04:10
Sent To： Feng Xue
CC To： simspark-devel
Topic： Re: Fixed joint limit issue, nao model V1.0

Hi Feng,


On Apr 16, 2008, at 10:33 PM, Feng Xue wrote:

Hi all,

    I have fixed the joint limit issue. 


Great :-)


Please see my latest rsg files. I tested all the joints from the speed 0.1 to 10, and it seemed that those parameters are good for the joint limit. 


I'll take a look as soon as I'm free.


So we have a V1.0 nao model now :-D


:-D

   Thanks Sander and Yuan's help!

    By the way, I have those questions to ask:
    1. Where should the vision perceptor be installed. On the head?


Yes, I would say definitely in the head. That's where it belongs ;-)


    2. Should we add some collide such as(two shank collide) to make it more realistic?


I'm not sure I understand what you mean. Can you explain this in more detail please?


Cheers,
Joschka

Re: [simspark-devel] Fixed joint limit issue, nao model V1.0

[Joschka B. <jos...@am...>]

Hi Feng,

On Apr 16, 2008, at 10:33 PM, Feng Xue wrote:

> Hi all,
>
>     I have fixed the joint limit issue.

Great :-)

> Please see my latest rsg files. I tested all the joints from the  
> speed 0.1 to 10, and it seemed that those parameters are good for  
> the joint limit.

I'll take a look as soon as I'm free.

> So we have a V1.0 nao model now :-D

:-D
>    Thanks Sander and Yuan's help!
>
>     By the way, I have those questions to ask:
>     1. Where should the vision perceptor be installed. On the head?

Yes, I would say definitely in the head. That's where it belongs ;-)

>     2. Should we add some collide such as(two shank collide) to make  
> it more realistic?

I'm not sure I understand what you mean. Can you explain this in more  
detail please?

Cheers,
Joschka

Re: [simspark-devel] pixel camera perceptor

[Joschka B. <jos...@am...>]

Hi,

On Apr 17, 2008, at 2:54 AM, Markus Rollmann wrote:

> Hi,
>
> Sander van Dijk wrote:
>> I think there are three main ways to do this:
>>
>> - Fix the single Camera in the scene to an agent's vision perceptor
>> - Add multiple Camera objects, one for each agent and change the
>> RenderServer so we can switch between cameras and select to render to
>> texture
>> - Create a new extension of BaseRenderServer that can render from a
>> VisionPerceptor (or maybe any other object in the scene graph)  
>> point of
>> view and is specialized in rendering to texture.
>>
>> The first would be the easiest probably. But I think the latter two
>> would be more useful when we want to extend it to the pixel camera
>> perceptor for the agents. However, the single camera can just be  
>> cycled
>> through all agents to render the view of each agent.. To me the last
>> idea seems the most appealing, so the rendering of agent views is
>> clearly separated from the normal view. What do you think.
>
> I prefer your second proposal. The library already supports the
> necessary abstractions to support multiple viewports, i.e. camera
> Objects and the concept of an active Camera.
>
> We should explicitly put a Camera object in the agent .rsg and allow  
> the
> user to select and/or cycle between the available cameras in the  
> scene.
>

I think I also prefer the second proposal (that was what I had in  
mind), but maybe it's because I don't understand the advantages of the  
third possibility yet :-/

> Currently the topmost camera below usr/scene is implicitly the default
> camera (see kerosin\renderserver\renderserver.cpp
> RenderServer::Render()). This camera is passed to
> RenderServer::BindCamera() to setup the necessary OpenGl  
> transformations.
>
> So implementing an explicit mechanism to select an active camera would
> be the first step. This allows to change the camera for the whole
> rendered window. Together with a key binding to cycle the view makes  
> for
>  a usable first step in the monitor.
>

Right.

> The second step is to support multiple parallel viewports in the
> monitor. This is either possible with multiple passes in one OpenGl
> context (each time setting a different viewport size and position) or
> with the help of multiple OpenGL contexts (in different windows).
>
> I'd prefer the second version as this allows for an easy modification
> later on to support 'render to texture'
>

Once the render to texture is implemented, you don't  need multiple  
viewports in the monitor, since you can simply display the textures on  
quads in front of the camera (kind of like a 2D overlay). So maybe we  
could even skip the second step and move directly to rendering to  
texture? It doesn't look so difficult and you can get some sample code  
e.g. at [1] (code for chapter 18 or 19). The code uses the Framebuffer  
object (FBO) extension to render to texture which seems to be the  
preferred way right now (you can directly render to texture without  
even having to copy any pixels from offscreen buffers into an OpenGL  
texture). There are some subtleties however, for instance whether to  
use several FBOs or just use one and attach several textures and  
switch between them (better performance I believe). We have a new  
graphics programming guru (former PS3 developer at SONY) in the lab  
now, I'll ask him for directions.

@Sander: thanks for taking over this task :-) I can't ignore Oliver's  
instructions about not working on it since he's currently sitting next  
to me here in Osaka ;-)

Cheers,
Joschka

[1] http://www.opengl.org/sdk/docs/books/SuperBible/

Re: [simspark-devel] pixel camera perceptor

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

Hi,

Sander van Dijk wrote:
> - Create a new extension of BaseRenderServer that can render from a 
>> VisionPerceptor (or maybe any other object in the scene graph) point of 
>> view and is specialized in rendering to texture.
[...]

> To me the last 
> idea seems the most appealing, so the rendering of agent views is 
> clearly separated from the normal view. What do you think.
[...]

... I think you're right that we need to distinguish between cameras 
with a different purpose. But this is a second step. The first thing 
should be to support different cameras at all.

Making this distinction based on the 'VisionPercpetor' class requires us 
to put this class into one of the base libraries (oxygen, kerosin...) in 
order to be able to test for it (using the C++ rtti you cannot test for 
a base class declared in a plugin as it is not know at compile time). 
Currently the Visionperceptor is Soccer specific and should stay it imo.

I think labeling cameras using the default node name (i.e. rsg SetName 
function) is sufficient. If the user cycles through the cameras he can 
either cycles through all cameras or choose an individual camera based 
on the node name or other context information.

If a camera shoild serve as a viewpoint for a percpetor node (e.g. the 
VisionPerceptor) it is the responsibility of this perceptor node to 
register/enable the cameras for 'render to texture' and 'serialization' 
to the agent (directly or indirectly via a render proxy as proposed by 
Yuan).

This could be done in it's OnLink() methode if it has a direct camera 
child. In this way we can avoid any hard/special dependencies between 
the base libraries and percpetor nodes.

cheers,
Markus

Re: [simspark-devel] pixel camera perceptor

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

Hi,

Sander van Dijk wrote:
> I think there are three main ways to do this:
> 
> - Fix the single Camera in the scene to an agent's vision perceptor
> - Add multiple Camera objects, one for each agent and change the 
> RenderServer so we can switch between cameras and select to render to 
> texture
> - Create a new extension of BaseRenderServer that can render from a 
> VisionPerceptor (or maybe any other object in the scene graph) point of 
> view and is specialized in rendering to texture.
> 
> The first would be the easiest probably. But I think the latter two 
> would be more useful when we want to extend it to the pixel camera 
> perceptor for the agents. However, the single camera can just be cycled 
> through all agents to render the view of each agent.. To me the last 
> idea seems the most appealing, so the rendering of agent views is 
> clearly separated from the normal view. What do you think.

I prefer your second proposal. The library already supports the 
necessary abstractions to support multiple viewports, i.e. camera 
Objects and the concept of an active Camera.

We should explicitly put a Camera object in the agent .rsg and allow the 
user to select and/or cycle between the available cameras in the scene.

Currently the topmost camera below usr/scene is implicitly the default 
camera (see kerosin\renderserver\renderserver.cpp 
RenderServer::Render()). This camera is passed to 
RenderServer::BindCamera() to setup the necessary OpenGl transformations.

So implementing an explicit mechanism to select an active camera would 
be the first step. This allows to change the camera for the whole 
rendered window. Together with a key binding to cycle the view makes for 
  a usable first step in the monitor.

The second step is to support multiple parallel viewports in the 
monitor. This is either possible with multiple passes in one OpenGl 
context (each time setting a different viewport size and position) or 
with the help of multiple OpenGL contexts (in different windows).

I'd prefer the second version as this allows for an easy modification 
later on to support 'render to texture'

cheers,
Markus

Re: [simspark-devel] integrated_agent_v3

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

Ben wrote:
[...]
> I use '#define SHARED_LIB_COMPILE' in 'windows/sparkconfig.h',
> add 'CLASS_EXPORT' before all the classes needed, and It works.
> There is only one technical issue:
> when there is a static member in a class(to be export), for example,
> in salt::Matrix (mIdentity), salt.dll is produced, but when zeitgeist links
> to salt, there is a unresovled symbol of 'mIdentity'.
> I have to add an additional file like this to define it:
[...]
> Is there any other solution?

It should be possible to compile salt/oxygen/kerosin and spark as one 
single dll. In this case we don't have the dependency issues between our 
libraries. SimSpark would then link to the 'bundle' dll that contains 
all our base libraries.

cheers,
Markus

[simspark-devel] Fixed joint limit issue, nao model V1.0

[Feng X. <hen...@ma...>]

Hi all,

    I have fixed the joint limit issue. Please see my latest rsg files. I tested all the joints from the speed 0.1 to 10, and it seemed that those parameters are good for the joint limit. So we have a V1.0 nao model now :-D   Thanks Sander and Yuan's help!

    By the way, I have those questions to ask:
    1. Where should the vision perceptor be installed. On the head?
    2. Should we add some collide such as(two shank collide) to make it more realistic?

Best Regards!



Feng Xue
2008-04-16

Re: [simspark-devel] pixel camera perceptor

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

Hey Sander,

On 16/04/2008, at 8:52 PM, Sander van Dijk wrote:
> Joschka, have you already started working on this? If not I'd like  
> to try and give it a go :-) As Markus mentioned, at least the first  
> person view in the monitor shouldn't be to hard to do. I think there  
> are three main ways to do this:


please go for it. I didn't give permission to Joschka to working on  
the simulator for this week ;-) -- he has to work on his  
publications.  :-)

cheers
Oliver

Re: [simspark-devel] pixel camera perceptor

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

Hey,

Joschka, have you already started working on this? If not I'd like to try
and give it a go :-) As Markus mentioned, at least the first person view in
the monitor shouldn't be to hard to do. I think there are three main ways to
do this:

- Fix the single Camera in the scene to an agent's vision perceptor
- Add multiple Camera objects, one for each agent and change the
RenderServer so we can switch between cameras and select to render to
texture
- Create a new extension of BaseRenderServer that can render from a
VisionPerceptor (or maybe any other object in the scene graph) point of view
and is specialized in rendering to texture.

The first would be the easiest probably. But I think the latter two would be
more useful when we want to extend it to the pixel camera perceptor for the
agents. However, the single camera can just be cycled through all agents to
render the view of each agent.. To me the last idea seems the most
appealing, so the rendering of agent views is clearly separated from the
normal view. What do you think.

Sander

On Mon, Apr 14, 2008 at 7:04 AM, Joschka Boedecker <
jos...@am...> wrote:

> Hi Yuan,
>
> On Apr 10, 2008, at 10:07 PM, Yuan Xu wrote:
>
> >
> > I think we may implement the 'pixel camera perceptors server' which
> > receives scene messages from simspark (just likes the external
> > monitor) and renders images for connected robots.
> > Then we can run a 'pixel camera perceptors server' in machines that
> > runs robots.
> > In this case, the simulation runs in multi-machines.
> > What do you think about it?
>
> Yes, that's a nice idea :-) I think they are using a similar setup in
> the RoboCup Rescue virtual robots competition (using USARSim). But
> first I'll have to get started on the camera implementation anyways
> which will probably take some time (can't spare much time on this
> right now) ;-)
>
> Cheers,
> Joschka
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>

Re: [simspark-devel] Textures of Nao ?

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

Hi Joschka,


>
>  Thank you for your offer, I appreciate it :-)
>

You are welcome. We are both interesting in this, and thanks for your
information about how to do it.

The RoboCup 2008 Exercise Competitions(
http://www.robocup-cn.org/exercise/ ) will be held in May 2-3,
we hope the Nao robot can play a demo in the game.
It would be great if the textures can be finished before that.
I think you can finish the work in time as an veteran ;-)
However, if you are too busy to get down to it, we are happy to try.

After all, we hope you can find time to do it.


-- 
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] Textures of Nao ?

[Joschka B. <jos...@am...>]

Hi Yuan and Feng,

On Apr 16, 2008, at 4:17 PM, Yuan Xu wrote:

> Hi Joschka,
>
> Feng told me that you are working on textures for Nao.
> It will be great if the robot have the same looking as webots!
> I know you are very busy on your research working,
> can we ( Feng and me ) do something help about it?

Thank you for your offer, I appreciate it :-)

I'm afraid modeling the robot shapes requires some work in a 3D  
program like 3D Studio MAX, Maya, Lightwave, or Blender [1] (which I  
prefer because it's free :-) ). Learning a tool like that requires  
some time (I'm still learning myself), but if you have some skills in  
using one of these tools, or if you have some time and would be  
willing to learn: I'm happy to get help on this :-)

I can give more information on how to get started with Blender if  
you're interested. Please let me know.

Cheers,
Joschka

[1] http://www.blender.org/

Re: [simspark-devel] Joint limit implement

[Feng X. <hen...@ma...>]

Hi Joschka,

    I will test some other parameters today to look for another solution. If failed, I will make a patch file of this solution for your convenience.

Best Regards!



Feng Xue
2008-04-16



Sent By： Joschka Boedecker
Sent At： 2008-04-16 14:53:20
Sent To： Feng Xue
CC To： Markus Rollmann; simspark-devel
Topic： Re: Joint limit implement

Hi Feng,


On Apr 15, 2008, at 10:15 PM, Feng Xue wrote:

Hi Joschka,

    I decide to do the joint limit in this way:

    First, When setting the min and max angles, add a buffer in it. Then the min and max angles that really set in ode are [min-buf, max+buf].

    Second, in hingeeffector.cpp, function Realize(..), check the required speed, if the speed will make the angle go out of the range [min, max], then the required speed will be ignored or replaced by a reasonable speed.



This sounds like a reasonable solution.


    Now, the idea will not make effect if min is -180 or max is 180. Luckily, the max abs value of all the limited angles of nao is below 120.
   
    I have test it in my machine. It seems good. Because it will violate the "kernel code" and the "generic thing", so I ask for your advice


Could you maybe post your code, or upload it somewhere for review if it is too long to include in an email? It would make it easier to examine your solution.


Thank you,
Joschka