Re: [simspark-devel] Countdown for Atlanta

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

Hi Joschka and all,



> The question is now, how we should proceed.

Yes, if I know what we need to do, things will become easier.
However, we may know what to do after do some experiments.

> We could use different timers for the effectors and perceptors (something Yuan proposed in the beginning when he started working on these things), and just do a single loop, or use the threaded version. Since the threaded version is more complicated and doesn't seem to bring too much performance gain, it seems more feasible to use a single runloop in the server. However, I'm not sure about this. Yuan, could you please let us know what you think about these issues?
>

The fact is that, all the threads should be executed in the right order.
There are only one scene in the server, the agent-manager thread and
monitor-manager thread often have to wait the physic thread. On the
other hand, the physic thread can not run before the other thread
finish their loops. I think if we want to make them running
simultaneously, a copy of scene is needed.
I draw a graphic to explain my idea, please see
http://picasaweb.google.com/xuyuan.cn/C75/photo#5065569456434569362
And the cached scene and the action queue can make some delay to the
perception and action, the delay is the factor the real robot should
face.
However the scene copying is costing, so I can not make sure this will
be better.

And there are also some problem of the ruby in mulit-thread.
So the single thread is more simple and feasible, but there are also
some work need to do.
We have to make a choice early.
I will try the buffered thread implementation, and report the result
as soon as I can.



> P.S.: if you think something vital is missing in the list of necessary
> features, please let me know ASAP. Thanks :-)

After installed the rcssserver3d-0.5.4, I noticed the usleep is used
to slow down the logfile,
the better solution may be do not save messages with the same simtime again.
However if the timer works, this is no needed.

I think the joints can rotate in 360 degrees is not realistic!
The joint should be restricted in a range.
Otherwise the agent can do something impossible in real:
In the round 1 of Iran Open, some agents use their hands and foots as wheels!
And I think this is not hard to implement, the ODE can set the motor
parameters: dParamLoStop and dParamHiStop.


--
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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