simspark-devel — Discussion about Spark development

Re: [simspark-devel] integrated_agent_v3

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

Hi,

Ben wrote:
> 2008-04-12£¬"Markus Rollmann" <rol...@un...>
>  > The change concerning the use of predicate lists would be nice
>  > however ;)
>  > ok, I'll work it out.

> After using predicate lists, the arms' wave action of soccerbotbehavior
> is abnormal, and I found that it's concerned about the precision.
> In SexpParser::ListToString: ss.precision(2). So in order to make
> the behavior through integration and network work the same exactly,
> there maybe need some changes.

We loose precision in the conversion from string to float?

I think the sensor should have authority about the precision. So the 
rounding should occur within the Sensor classes. We already have the 
gRound() function in gmath.h for this purpose.

> Finally, how to output the cvs commit into 'ChangeLog'?

That is a feature of the Emacs editor. Load the version control hooks 
with m-x, vc-load-vc-hooks. Open the Changelog file. And use m-x, 
vc-update-change-log to transfer your changes.

cheers,
Markus

Re: [simspark-devel] integrated_agent_v3

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

Hedayat Vatankhah wrote:
[...]
>> The downside is we cannot provide different loglevels (i.e. debug, 
>> normal etc. for one agent channel). One possibility would be to 
>> provide multiple bases like eAgentNormal, eAgentDebug etc. and offset 
>> them. This could be hidden behind a nice interface like 
>> "GetLog()->AgentDebug(agentId)"
> Or maybe each agent should have it's own LogServer instance?!

I like that idea... We could install a LogServer instance below each 
Behavior class. Further the Object::GetLog() function should become 
vritual (see zeitgeist\object.h). Called from within a behavior class it 
would return the LogServer instance assigned to the agent, (maybe a 
direct child) and return the default LogServer instance otherwise.

> Also notice that priority levels should be powers of 2. So, (at least 
> currently) we can have at most 32 priority levels.

Your're right. Id didn't notice that. I favor the idea of separate 
LogServcer instances (or a similar concept)

cheers,
Markus

Re: [simspark-devel] Question about check & init SDL

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

Hi Hedayat,


 >  Hi Yuan,
 >  I'll check it ASAP.


Thanks.


 >  And about the SDL problem, have you checked if removing all video related
 > code except it's initialization (such as SDL_SetVideoMode()) will solve the
 > problem. (Sorry I can't check it right now since I should sleep!).
 >


I just wander whether we can remove the follow codes in inputsystemsdl.cpp:

 00082     if (!SDL_WasInit(SDL_INIT_VIDEO))
 00083     {
 00084         if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE) < 0)
 00085         {
 00086             GetLog()->Error() << "ERROR: (InputSystemSDL) SDL
 not initialized!\n";
 00087             return false;
 00088         }
 00089         SDL_SetVideoMode(0,0,0,0);
 00090         static SDL_SysWMinfo pInfo;
 00091         SDL_VERSION(&pInfo.version);
 00092         SDL_GetWMInfo(&pInfo);

 It works in my system without these codes,
 but I am not sure in other system.



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

[Ben <lgp...@16...>]

Hi Markus,    

2008-04-12，"Markus Rollmann" <rol...@un...> 
> The change concerning the use of predicate lists would be nice 
> however ;)
> ok, I'll work it out.
  After using predicate lists, the arms' wave action of soccerbotbehavior
is abnormal, and I found that it's concerned about the precision.
In SexpParser::ListToString: ss.precision(2). So in order to make
the behavior through integration and network work the same exactly,
there maybe need some changes.

Finally, how to output the cvs commit into 'ChangeLog'?
Thanks.

Best wishes!
Ben

Re: [simspark-devel] integrated_agent_v3

[Ben <lgp...@16...>]

Hi Hedayat:

  It's  great!

  Why not come into my head? :)

Best wishes!
Ben

 

在2008-04-13，"Hedayat Vatankhah" <hed...@ai...> 写道：
Hi All,

Markus Rollmann <rol...@un...> wrote on 04/12/2008 03:45:22 PM:
Hi Ben, 

Ben wrote: 
1. >The most simple solution would be a single logchannel for all integrated 
 >agents. A more elaborate solution would provide a channel for each 
 >agent. Opinions? 
A channel with different kinds of streams for each agent is perfect. 
Then an agent can log itself powerfully just like the server. 

The question is how to extend the logserver to support that. Some issues are: 

Currently the Logserver supports different priority levels, i.e. normal, debug, warning, error. If we extend the logserver to provide additional channels we could add the agent channels as new priority levels (see zeitgeist/logserver/logserver.h the EPriorityLevel enum). In this case using a single new constant like 'eAgent' and offset that with the uniqe agent id would provide a channel id  for each agent (i.e. eAgent + 1, eAgent + 2 ...) 

The downside is we cannot provide different loglevels (i.e. debug, normal etc. for one agent channel). One possibility would be to provide multiple bases like eAgentNormal, eAgentDebug etc. and offset them. This could be hidden behind a nice interface like "GetLog()->AgentDebug(agentId)" 
Or maybe each agent should have it's own LogServer instance?!

Also notice that priority levels should be powers of 2. So, (at least currently) we can have at most 32 priority levels.

Cheers,
Hedayat

Re: [simspark-devel] Question about check & init SDL

[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">
Hi Yuan,<br>
I'll check it ASAP.<br>
And about the SDL problem, have you checked if removing all video
related code except it's initialization (such as SDL_SetVideoMode())
will solve the problem. (Sorry I can't check it right now since I
should sleep!).<br>
<br>
Thanks a lot,<br>
Hedayat<br>
<span><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 class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i> wrote on 04/12/2008 07:48:24 PM:</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 all,

I have made the external monitor working.
It works well in my system, would you test it if you have time? Thanks.

However, I have a problem while disabling the internal monitor,
the SDL window are still there.

After merging code from simspark repository,
the inputsdl make sure the SDL is initialized video and timer,

And without SDL video initialization (just like the code in rcssserver3d-0.5.6),
the simspark works both with and without internal monitor.

I do not know whether these new code is useful in other platforms,
can we comment them out without any problem?
Thanks!

  </pre>
</blockquote>
</body>
</html>

Re: [simspark-devel] integrated_agent_v3

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

Hi All,

/*Markus Rollmann <rol...@un...>*/ wrote on 04/12/2008 
03:45:22 PM:
> Hi Ben,
>
> Ben wrote:
>> 1. >The most simple solution would be a single logchannel for all 
>> integrated
>>  >agents. A more elaborate solution would provide a channel for each
>>  >agent. Opinions?
>> A channel with different kinds of streams for each agent is perfect.
>> Then an agent can log itself powerfully just like the server.
>
> The question is how to extend the logserver to support that. Some 
> issues are:
>
> Currently the Logserver supports different priority levels, i.e. 
> normal, debug, warning, error. If we extend the logserver to provide 
> additional channels we could add the agent channels as new priority 
> levels (see zeitgeist/logserver/logserver.h the EPriorityLevel enum). 
> In this case using a single new constant like 'eAgent' and offset that 
> with the uniqe agent id would provide a channel id  for each agent 
> (i.e. eAgent + 1, eAgent + 2 ...)
>
> The downside is we cannot provide different loglevels (i.e. debug, 
> normal etc. for one agent channel). One possibility would be to 
> provide multiple bases like eAgentNormal, eAgentDebug etc. and offset 
> them. This could be hidden behind a nice interface like 
> "GetLog()->AgentDebug(agentId)"
Or maybe each agent should have it's own LogServer instance?!

Also notice that priority levels should be powers of 2. So, (at least 
currently) we can have at most 32 priority levels.

Cheers,
Hedayat

>
>

Re: [simspark-devel] Nao process

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

Hi Feng,

Great work!!
It will be perfect with some textures.

I played the Nao simulation in webots today.
I found an advantage of our simulator except open source:
simspark can record replay, the webots only can record video.
I think the replay is very important for research analyzing.

2008/4/12, Feng Xue <hen...@ma...>:
>
>
> Hi Joschka,
>
> The nao model is 90% done and teams can do some research on it now. Do you
> think it is time to write a letter to 3d-maillist to summary my recent jobs
> and call for the tests?
>
>     By the way, there are 2 issues about nao.
>     First, the joint limits. I have sent a letter to mail-list to call for
> ideas.
>
>     Second, the implement of disable inner collision of nao. It is not
> perfect according to Markus' suggestions. I know I am in a hurry and always
> modify the codes rewritten not by me. I am fresh, so please forgive my
> precipitance.
>     My destination is building a stable model and a perfect simulator to
> against Webots and Microsoft's RoboticsStudio. They both hold a nao
> simulation for RoboCup2008! Compare 3d with them, I think we only have one
> advantage, the number of teams. Lots of complaint, please forgive again.
>
> Cheers!
>  ________________________________
>
> Feng Xue
> 2008-04-12
> -------------------------------------------------------------------------
>  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
>
>


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

[simspark-devel] Question about check & init SDL

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

Hi all,

I have made the external monitor working.
It works well in my system, would you test it if you have time? Thanks.

However, I have a problem while disabling the internal monitor,
the SDL window are still there.

After merging code from simspark repository,
the inputsdl make sure the SDL is initialized video and timer,

And without SDL video initialization (just like the code in rcssserver3d-0.5.6),
the simspark works both with and without internal monitor.

I do not know whether these new code is useful in other platforms,
can we comment them out without any problem?
Thanks!

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

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

Hi Ben,

Ben wrote:
> 1. >The most simple solution would be a single logchannel for all 
> integrated
>  >agents. A more elaborate solution would provide a channel for each
>  >agent. Opinions?
> A channel with different kinds of streams for each agent is perfect.
> Then an agent can log itself powerfully just like the server.

The question is how to extend the logserver to support that. Some issues 
are:

Currently the Logserver supports different priority levels, i.e. normal, 
debug, warning, error. If we extend the logserver to provide additional 
channels we could add the agent channels as new priority levels (see 
zeitgeist/logserver/logserver.h the EPriorityLevel enum). In this case 
using a single new constant like 'eAgent' and offset that with the uniqe 
agent id would provide a channel id  for each agent (i.e. eAgent + 1, 
eAgent + 2 ...)

The downside is we cannot provide different loglevels (i.e. debug, 
normal etc. for one agent channel). One possibility would be to provide 
multiple bases like eAgentNormal, eAgentDebug etc. and offset them. This 
could be hidden behind a nice interface like "GetLog()->AgentDebug(agentId)"

> 2. >But I looked over the last version of the integrated agent patch and 
> I'd
>  >say that it's ready for inclusion into CVS! ;)
> Where should the files be placed? A single app or as plugin?
> And how to name it is a sticky problem to me :(

I'd say the names are fine. The soccebotbehavior could become part of 
the existing soccer plugin. This class derives from the base behavior 
class, so this must be part of one core library (you cannot inherit a 
class from a base that is part of another plugin). The base behavior 
class could go into the gamecontrol directory and the traincontrol class 
into the simulationserver directory.

> 3. >The change concerning the use of predicate lists would be nice 
> however ;)
> ok, I'll work it out.

thanks.

cheers,
Markus

Re: [simspark-devel] integrated_agent_v3

[Ben <lgp...@16...>]

Hi Markus,

1. >The most simple solution would be a single logchannel for all integrated 
>agents. A more elaborate solution would provide a channel for each 
>agent. Opinions?
  A channel with different kinds of streams for each agent is perfect.
Then an agent can log itself powerfully just like the server.

2. >But I looked over the last version of the integrated agent patch and I'd 
>say that it's ready for inclusion into CVS! ;)
  Where should the files be placed? A single app or as plugin?
And how to name it is a sticky problem to me :(

3. >The change concerning the use of predicate lists would be nice however ;)
  ok, I'll work it out.

Best wishes!
Ben

[simspark-devel] Nao process

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

Hi Joschka,

The nao model is 90% done and teams can do some research on it now. Do you think it is time to write a letter to 3d-maillist to summary my recent jobs and call for the tests?

    By the way, there are 2 issues about nao.
    First, the joint limits. I have sent a letter to mail-list to call for ideas.

    Second, the implement of disable inner collision of nao. It is not perfect according to Markus' suggestions. I know I am in a hurry and always modify the codes rewritten not by me. I am fresh, so please forgive my precipitance.
    My destination is building a stable model and a perfect simulator to against Webots and Microsoft's RoboticsStudio. They both hold a nao simulation for RoboCup2008! Compare 3d with them, I think we only have one advantage, the number of teams. Lots of complaint, please forgive again.

Cheers!



Feng Xue
2008-04-12

Re: [simspark-devel] integrated_agent_v3

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

Hi,

Ben schrieb:
> 1. >I have some comments:
>  >- I wonder if it's better to give the prdicate list directly to the
>  >think method of the behavior class. In the current implementation the
>  >predicates are collected[...]
>  >The TrainControl::EndCycle() method get's the senselist from the
>  >agentaspect. This could be passed on to the behavior class directly.

> This can reduce the time of 'parse', and I think 'GameControlServer'
> should overload 'Parse()' to accept 'predicatelist'.
> but when the behavior want to print the message received, is predicate
> better?

I think using predicates list in both directions (for senses and 
actions) is better for performance. As it completely avoids the parsing 
overhead.

Overloading the GameControlServer Parse() to accept a predicate list is 
a good idea.

You are right that the internal agent might want to print the received 
senses. For this case we could provide a method in the base Behavior 
class that looks up the parser in the GameControl server and generates 
the string on demand for debug purposes. For the main game loop however 
I'd prefer the predicate lists.

This method could be refactored from TrainControl::EndCycle to lookup 
the parser and call generate with a given senselist parameter.

> 2. >- You are using cerrs and stdouts to give agent responses instead of 
> the
>  >Logserver (i.e. GetLog()->Normal() << "msg"). Maybe we should introduce
>  >a new log channel for agent responses?
> I copy it from 'agentspark'. A new log channel is appreciated.

The most simple solution would be a single logchannel for all integrated 
agents. A more elaborate solution would provide a channel for each 
agent. Opinions?

[...]
> Lastly, I've make a update here[1], and I add a 'SphereBehavior' which
> can be controlled by 'GameInput'. There is an issue: the keys should be
> pressed as soon as the simulation started, otherwise the agent can not
> be controlled, I don't know why :(

sorry, I didn't test this game.

But I looked over the last version of the integrated agent patch and I'd 
say that it's ready for inclusion into CVS! ;)

The change concerning the use of predicate lists would be nice however ;)

cheers,
Markus

[simspark-devel] The joint limits issues

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

Hi all,

    The joint limits feature in ode is not very good. If a joint angle is not between the min and max(typically caused by errors), and you are trying to make the joint angle return to the normal, then, a large force is produced and it will cause a "jumping motion". Though I used the fudgefactor to reduce the force, it is not as perfect as what I expected.
   
    So, I decide to write some codes in hingeeffector.cpp to check the velocity sent by agent so that if the velocity may cause a "out of range joint angle", I can disable it or reduce the velocity. Is there any other ideas?

Cheers!



Feng Xue
2008-04-11

Re: [simspark-devel] integrated_agent_v3

[Ben <lgp...@16...>]

Hi, Markus:

>thanks Ben for your work. I looked at the source code and it's getting 
>better ;-)
  It's a pleasure :)

1. >I have some comments:
>- I wonder if it's better to give the prdicate list directly to the 
>think method of the behavior class. In the current implementation the 
>predicates are collected[...]
>The TrainControl::EndCycle() method get's the senselist from the 
>agentaspect. This could be passed on to the behavior class directly.
  This can reduce the time of 'parse', and I think 'GameControlServer'
should overload 'Parse()' to accept 'predicatelist'.
  but when the behavior want to print the message received, is predicate
better?

2. >- You are using cerrs and stdouts to give agent responses instead of the 
>Logserver (i.e. GetLog()->Normal() << "msg"). Maybe we should introduce 
>a new log channel for agent responses?
  I copy it from 'agentspark'. A new log channel is appreciated.

3. > So declaring all required symbols as DLL-Export is quite a lot of work.
  define macro  SHARED_LIB_COMPILE, and add CLASS_EXPORT in each
function can make it work, right? This is really lots of work.

  Lastly, I've make a update here[1], and I add a 'SphereBehavior' which
can be controlled by 'GameInput'. There is an issue: the keys should be
pressed as soon as the simulation started, otherwise the agent can not
be controlled, I don't know why :(

  Thanks!

Best wishes!
Ben

[1] www.apollo3d.cn/download/sparkgame.tar.gz

Re: [simspark-devel] pixel camera perceptor

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

Hi,

Sander van Dijk wrote:
[...]
> On the other hand, a pixel camera is realistic and is good from a 
> generic simulator point of view (and perhaps an entertainment point of 
> view during matches). However for the RoboCup 3D league I'd say it's a 
> step back, why have our teams mess with a problem that all other leagues 
> are already working on.

I agree with Sander that switching to the pixel camera is a step back as 
it raises the bar for teams to do basic things like self localization. 
In order to get more strategic and interesting matches staying with the 
VisionPerceptor would be better.

But having some nice 'first robot' view would be nice nevertheless ;)

[...]
> - The pixel camera should be implemented in such a way that the pixel 
> data can be received by the agent and also by the monitor, so we can 
> show cool first person action during matches. Yuan's idea to make a 
> seperate camera server seems like a solution for this, and also I think 
> the possibility of doing this extra rendering on seperate machines is 
> nice. However, somehow it doesn't seem pretty in my head, but for the 
> moment I don't have a better idea yet :)

In order to provide some first person robot views in the monitor there 
is no need for any server support. The additional viewport can be 
entirely rendered in the monitor process.

I also like Yuans idea to offload the rendering to some external process.

cheers,
Markus

Re: [simspark-devel] pixel camera perceptor

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

Hey all,

>From the point of view of RoboCup I myself am more in favor of adding extra
information to the vision perceptor like a rotation matrix. In my view the
3D simulation should offer things that the real leagues can't handle yet. At
the moment it might be unreal for humanoid robots to perceive body posture
and orientation, but I think this should be possible in the future.

On the other hand, a pixel camera is realistic and is good from a generic
simulator point of view (and perhaps an entertainment point of view during
matches). However for the RoboCup 3D league I'd say it's a step back, why
have our teams mess with a problem that all other leagues are already
working on.

In the discussion of simspark 'vs' webots it might have a good thing to have
though, because it seemed like one of the things why webots is perceived as
more advanced.

So my ideas are as follows:
- The current vision perceptor should be expanded/restricted: restrict field
of vision and like Joschka said, make the robot's head movable. Add vision
noise again. For agents to be able to have a higher level strategy
concerning teammates and opponents, vision objects should atleast get a
rotation matrix relative to the agent and preferably the data of other
robots should be expanded. Full position of all body parts might be a bit
too much data, perhaps just torso, head, feet and hands.

- The pixel camera should be implemented in such a way that the pixel data
can be received by the agent and also by the monitor, so we can show cool
first person action during matches. Yuan's idea to make a seperate camera
server seems like a solution for this, and also I think the possibility of
doing this extra rendering on seperate machines is nice. However, somehow it
doesn't seem pretty in my head, but for the moment I don't have a better
idea yet :)

Regards,

Sander

On Thu, Apr 10, 2008 at 3:14 PM, Yuan Xu <xuy...@gm...> wrote:

> Hi again,
>
> I think the vision can not get rotation matrix, it is unreal!
> We should consider the results after vision processing in real robots.
> Then it will be easier for teams when using pixel image perceptor.
>
> > Yes, good point. I think we could have a camera that has a restricted
> field
> > of view (omni-vision cameras are banned even in the real humanoid league
> > from this year on), but that will be tied to the orientation of it's
> parent
> > body, so that it can be changed with joint effectors, and we don't need
> any
> > camera effectors for that. This is what we could use for Nao then.
> >
> > Also, there were some comments that the vision information that is sent
> to
> > the agents should be extended, but it is not clear to me yet what should
> be
> > included. Some people suggested sending a rotation matrix (or a
> quaternion)
> > for the objects that an agent sees, for instance. What do you guys think
> > would be most useful?
> >
>
> --
> 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
>

Re: [simspark-devel] pixel camera perceptor

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

Hi again,

I think the vision can not get rotation matrix, it is unreal!
We should consider the results after vision processing in real robots.
Then it will be easier for teams when using pixel image perceptor.

> Yes, good point. I think we could have a camera that has a restricted field
> of view (omni-vision cameras are banned even in the real humanoid league
> from this year on), but that will be tied to the orientation of it's parent
> body, so that it can be changed with joint effectors, and we don't need any
> camera effectors for that. This is what we could use for Nao then.
>
> Also, there were some comments that the vision information that is sent to
> the agents should be extended, but it is not clear to me yet what should be
> included. Some people suggested sending a rotation matrix (or a quaternion)
> for the objects that an agent sees, for instance. What do you guys think
> would be most useful?
>

-- 
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] pixel camera perceptor

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

Hi Joschka,

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?

2008/4/10, Joschka Boedecker <jos...@am...>:
> Hi all,
>
>  I've been thinking about how to implement a pixel camera perceptor for
>  Simspark using hardware-accelerated OpenGL Render to Texture via the
>  Frame Buffer Object extension (see, e.g. [1]). I'm not proposing we
>  should adopt this in the 3D league, but it will be handy for doing
>  research.
>
>  One problem I see is that this is a sensor, but it relies on rendering
>  also. In the multi-threading implementation, these two are seperated
>  as far as I remember, right? Maybe it is not a problem, since the
>  rendering only needs to produce the image, which can be copied in the
>  thread for the perceptors, but I'm not sure about this, so I thought
>  I'll ask for ideas here.
>
>  Another thing I've been wondering about is whether it would be worth
>  it to compress the images before sending it to the agent or not. Of
>  course this will depend on color depth and size of the image, as well
>  as network delay, but encoding (and decoding on the agent side) would
>  also take time. For small images and a fast local network without much
>  delay, it might be overkill I guess. Again, any ideas are welcome.
>
>  Cheers,
>  Joschka
>
>  [1] http://www.gamedev.net/reference/articles/article2331.asp
>
>  -------------------------------------------------------------------------
>  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
>


-- 
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] pixel camera perceptor

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

Hi Feng,

thanks for your quick reply.

On Apr 10, 2008, at 8:48 PM, Feng Xue wrote:

> It is a good idea! This makes our simulation much more realistic!
>
>     Howerever, it may be hard for teams' work. Actually, I have talked
> about this with Yuan some days ago and we both think that most of  
> the teams
> will not support this.

You're probably right. But I don't want to suggest it for the league's  
competitions anyways (at least not for this year), it's more for doing  
research with robots that need realistic vision information.

>  But, how about provide the pixel camera as a additional perceptor

Exaclty, that's what I had in mind.

> and weaken the original vision perceptor?

Yes, good point. I think we could have a camera that has a restricted  
field of view (omni-vision cameras are banned even in the real  
humanoid league from this year on), but that will be tied to the  
orientation of it's parent body, so that it can be changed with joint  
effectors, and we don't need any camera effectors for that. This is  
what we could use for Nao then.

Also, there were some comments that the vision information that is  
sent to the agents should be extended, but it is not clear to me yet  
what should be included. Some people suggested sending a rotation  
matrix (or a quaternion) for the objects that an agent sees, for  
instance. What do you guys think would be most useful?

> And next year, pure pixel camera?

>

That's something that should be discussed on the sserver-three-d list  
and in the TC, I guess. I can imagine that many people will be against  
it (even though it is easy to use standard vision solutions like  
Intel's OpenCV, etc.). This is related to a much deeper question of  
clearly defining the goals of the 3D Soccer Simulation League I  
guess ;-)

Cheers,
Joschka

Re: [simspark-devel] pixel camera perceptor

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

Hi Joschka,

    It is a good idea! This makes our simulation much more realistic!

    Howerever, it may be hard for teams' work. Actually, I have talked
about this with Yuan some days ago and we both think that most of the teams
will not support this.

    But, how about provide the pixel camera as a additional perceptor and 
weaken the original vision perceptor? And next year, pure pixel camera?

Cheers!



Feng Xue
2008-04-10



发件人： Joschka Boedecker
发送时间： 2008-04-10 19:26:21
收件人： sim...@li...
抄送： 
主题： [simspark-devel] pixel camera perceptor

Hi all,
I've been thinking about how to implement a pixel camera perceptor for  
Simspark using hardware-accelerated OpenGL Render to Texture via the  
Frame Buffer Object extension (see, e.g. [1]). I'm not proposing we  
should adopt this in the 3D league, but it will be handy for doing  
research.
One problem I see is that this is a sensor, but it relies on rendering  
also. In the multi-threading implementation, these two are seperated  
as far as I remember, right? Maybe it is not a problem, since the  
rendering only needs to produce the image, which can be copied in the  
thread for the perceptors, but I'm not sure about this, so I thought  
I'll ask for ideas here.
Another thing I've been wondering about is whether it would be worth  
it to compress the images before sending it to the agent or not. Of  
course this will depend on color depth and size of the image, as well  
as network delay, but encoding (and decoding on the agent side) would  
also take time. For small images and a fast local network without much  
delay, it might be overkill I guess. Again, any ideas are welcome.
Cheers,
Joschka
[1] http://www.gamedev.net/reference/articles/article2331.asp
-------------------------------------------------------------------------
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] pixel camera perceptor

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

Hi all,

I've been thinking about how to implement a pixel camera perceptor for  
Simspark using hardware-accelerated OpenGL Render to Texture via the  
Frame Buffer Object extension (see, e.g. [1]). I'm not proposing we  
should adopt this in the 3D league, but it will be handy for doing  
research.

One problem I see is that this is a sensor, but it relies on rendering  
also. In the multi-threading implementation, these two are seperated  
as far as I remember, right? Maybe it is not a problem, since the  
rendering only needs to produce the image, which can be copied in the  
thread for the perceptors, but I'm not sure about this, so I thought  
I'll ask for ideas here.

Another thing I've been wondering about is whether it would be worth  
it to compress the images before sending it to the agent or not. Of  
course this will depend on color depth and size of the image, as well  
as network delay, but encoding (and decoding on the agent side) would  
also take time. For small images and a fast local network without much  
delay, it might be overkill I guess. Again, any ideas are welcome.

Cheers,
Joschka

[1] http://www.gamedev.net/reference/articles/article2331.asp

Re: [simspark-devel] rcssserver3d DEB packages

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

Great!

Thanks,
Hedayat

/*Joschka Boedecker <jos...@am...>*/ wrote on 
04/09/2008 04:52:34 AM:
> Dear all,
>
> I have created two DEB packages for the current release of  
> rcssserver3D. One was built on Ubuntu 7.10, the other one on Ubuntu  
> 7.04. They are available at:
>
> http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/rcssserver3d_0.5.7-0ubuntu1_i386_gutsy.deb
>
> for 7.10, and
>
> http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/rcssserver3d_0.5.7-0ubuntu1_i386_feisty.deb
>
> for 7.04, respectively.
>
> A convenient way to install the packages in Ubuntu is using the  
> package installer (just double-click on the package icon). It should  
> automatically recognize the dependencies and download and install the  
> missing ones if possible. The package for 7.10 should work out of the  
> box, but to use the one for 7.04, you'll need to update your wxGTK  
> installation first. You can do this as follows:
>
> Please add:
>
>    deb http://apt.tt-solutions.com/ubuntu/ feisty main
>
>
> to your /etc/apt/sources.list file and add the public key used for  
> signing wxWidgets packages to the list of keys trusted by apt using  
> the command:
>
>    curl http://www.tt-solutions.com/vz/key.asc | sudo apt-key add -
>
>
> (do sudo apt-get install curl if it's missing on your system)
>
> After that, please update the wxGTK related packages, e.g. using the  
> Synaptic package manager.
>
> Once you have installed the rcssserver3d package, you should be able  
> to start applications like simspark, rsgedit, agentspark, etc. from  
> the command line.
>
> I haven't made any tests on other Debian systems, but my hope is that  
> the packages will work also on other (fairly recent) distributions.  
> Please note that I'm very new to the packaging business, and I might  
> have made mistakes, so please bear with me and give feedback about  
> what works and what doesn't. With your help, I can improve these  
> packages over time (I'm thinking about writing a post in the Wiki to  
> describe the process so that more people can help). Once I get my head  
> around how to set up the dependencies in a less strict fashion, we  
> might be able to have just one package that works for different  
> distributions and versions :-)
>
> Any comments and suggestions are welcome.
>
> 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
>   

[simspark-devel] rcssserver3d DEB packages

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

Dear all,

I have created two DEB packages for the current release of  
rcssserver3D. One was built on Ubuntu 7.10, the other one on Ubuntu  
7.04. They are available at:

http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/rcssserver3d_0.5.7-0ubuntu1_i386_gutsy.deb

for 7.10, and

http://jeap-res.ams.eng.osaka-u.ac.jp/~joschka/simspark/rcssserver3d_0.5.7-0ubuntu1_i386_feisty.deb

for 7.04, respectively.

A convenient way to install the packages in Ubuntu is using the  
package installer (just double-click on the package icon). It should  
automatically recognize the dependencies and download and install the  
missing ones if possible. The package for 7.10 should work out of the  
box, but to use the one for 7.04, you'll need to update your wxGTK  
installation first. You can do this as follows:

Please add:

   deb http://apt.tt-solutions.com/ubuntu/ feisty main


to your /etc/apt/sources.list file and add the public key used for  
signing wxWidgets packages to the list of keys trusted by apt using  
the command:

   curl http://www.tt-solutions.com/vz/key.asc | sudo apt-key add -


(do sudo apt-get install curl if it's missing on your system)

After that, please update the wxGTK related packages, e.g. using the  
Synaptic package manager.

Once you have installed the rcssserver3d package, you should be able  
to start applications like simspark, rsgedit, agentspark, etc. from  
the command line.

I haven't made any tests on other Debian systems, but my hope is that  
the packages will work also on other (fairly recent) distributions.  
Please note that I'm very new to the packaging business, and I might  
have made mistakes, so please bear with me and give feedback about  
what works and what doesn't. With your help, I can improve these  
packages over time (I'm thinking about writing a post in the Wiki to  
describe the process so that more people can help). Once I get my head  
around how to set up the dependencies in a less strict fashion, we  
might be able to have just one package that works for different  
distributions and versions :-)

Any comments and suggestions are welcome.

Cheers,
Joschka

Re: [simspark-devel] Fwd:[Sserver-three-d] Error with FRP in server 0.5.7

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

Hi
Yes, some times (for example when an agent is initialized and before 
doing anything!) there are 3 contact points with zero force! I've added 
checking for zero force in FRP.

About the agent cycle, would you please check it again? It might be 
related to the rounding error mentioned by Yuan. I've added the same fix 
for SimControlThread.

Finally, thanks a lot for the new Nao robot.

Good luck,
Hedayat

/*"Feng Xue" <hen...@ma...>*/ wrote on 03/29/2008 03:34:39 PM:
> Hi all,
>
>      The same problem happens on me too. Maybe it is a "divide 0" problem, I
> guesss.
>
>      By the way, when using multi-thread, the agent cycle is 0.04s. 
>      And I found another ode error. Yuan said it is because that if one of the
> thread trys to call ode function when another thread is doing the physics update,
> ode will fail. Typically, it happens when both of the beam command and joint speed
> command are valid in a cycle.  
>
>   
>> From: C B <kam...@ya...>
>> Reply-To: 
>> To: sse...@li...
>> Subject: [Sserver-three-d] Error with FRP in server 0.5.7
>> Date:Sat, 29 Mar 2008 05:37:12 -0500 (CDT)
>>
>>
>> Hello,
>> I am testing our agent in the new server 0.5.7 and
>> sometimes I get a wrong message in the FRP, like:
>>
>> (FRP(n lf)(c nan nan nan)(f 0.00 0.00 0.00))
>>
>> I was not receiving this message in 0.5.6.
>> Previous messages to that message are valid messages.
>>
>> Also, it seems like there is some kind of "noise"
>> in FRP, for example I am receiving this for some
>> sequential simulation steps:
>>
>> (FRP(n rf)(c -0.08 -0.10 -0.05)(f 0.28 0.42 12.27))
>> (FRP(n lf)(c 0.08 -0.10 -0.05)(f -0.28 0.41 12.27))
>>
>> (FRP(n rf)(c 0.08 0.10 -0.05)(f -0.30 -0.41 12.20))
>> (FRP(n lf)(c -0.08 0.10 -0.05)(f 0.29 -0.42 12.19))
>>
>> (FRP(n rf)(c -0.08 -0.10 -0.05)(f 0.28 0.42 12.28))
>> (FRP(n lf)(c 0.08 -0.10 -0.05)(f -0.26 0.42 12.35))
>>
>> As you can see, the sign of some numbers varies from
>> message to message, both on the point and the force.
>>
>> Best regards,
>> Carlos Bustamante
>> Borregos3D
>>     
>