Re: [simspark-devel] Countdown for Atlanta

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

Hi Yuan,

Yuan Xu wrote:

>
>>
>> Timing problems? Sometimes the mouse movements have an effect after some
>> time, ie. you move the mouse, nothing happens, but some time later the
>> camera suddenly jerks somewhere (you usually don't want it to be).
>>
>
> I do a test, I logged some information in InputControl::StartCycle().
> When the monitor do not respond the keyboard and mouse, the simulation
> runs smoothly,
> but can not get any other input from the SDL, except the SDLTimer.
> I think the reason is the SDL can not create the event in real time
> when the system is very busy.
> And the SDLTimer does not work like other SDL devices( set the
> callback by SDL_SetEventFilter ),
> so it still works.
> This can explain why you can see the 6 agents and server works
> properly if you do not change the camera.
>
>

Thanks for the report. I was suspecting something along these lines, but 
of course it's better to check ;-) During a game, we should have 
auto-cam mode enabled (which is not implemented yet), so this shouldn't 
be a problem, but of course we need to be able to interfere with the 
game, e.g., to do a "drop ball" or to initiate kick off. If the 
application is too busy for SDL to create appropriate events, do you 
think it would make sense to have an other application ("referee") that 
connects to the server as a monitor and sends commands using the trainer 
protocol? This way we could make the game kick of and do drop ball at 
least...

> About the server crash problem while agent connecting,
> I think we can save the action firstly, and then in method
> PrePhysicsUpdateInternal realize the action.
> It just like the DriveEffector do.
> I changed the InitEffector and SingleMatInitEffector in this way,
> the crash problem do not happen again.
> However, other effectors, such like hingEffector and
> UniversalJointEffector, calls the ODE functions directly, they are
> seems OK.
> It is better that all the effectors save the action firstly, I think.
> Do you agree with me? and then I can make a new patch.
>

Sounds like a good idea. :-)

>>
>> I agree with the proposal. It makes the model more realistic.
>> (In addition we may use it to get rid of the fixed joint connecting the
>> head to the torso.)
>>
>
> Yeah,and maybe the vision perceptor can be placed in the head.
> :-)
>

In general, I agree of course, but I think it might be already too late 
to restrict the joint angles. I know that several teams have built their 
skills (like, e.g. getting up) relying on this feature, and there is not 
much time to program new skills. After the competition, however, the 
joint angles should be restricted to more realistic values.

To place the vision perceptor in the head might cause similar problems 
for localization, but I'm not sure about that. We could maybe ask teams 
what they think about both of these changes. If people don't mind, we 
could go ahead and do it, I guess ;-)

One more issue is that we have to make a definite decision about which 
version of the timer to use in Atlanta soon. To be able to do that, I'd 
like to hear your opinion on the following issues, Yuan.

Ideal scenario
=========

We have a mechanism that allows different cycle speeds for different 
effectors and sensors. The control loop should run at 50 Hz, so all the 
joint effectors and the joint perceptors, plus the gyro rate and the 
touch sensor run at this speed, too. Vision percepts are generated at 15 
Hz.  Furthermore, the visualization runs at a fixed 25 frames/sec.

Options
=====

The above can be implemented using threads or just in a single run loop 
having different timing values for the different perceptors/effectors.

***

I think you implemented both options already (correct me if I'm wrong). 
In my opinion, if the threaded version runs stably, this would be the 
preferred option since it really boosts performance. However, if we 
can't be sure that it runs stably, we should go with the single-threaded 
version. Stability is more important than performance for the competition.

We should make a decision about this on Saturday of this week (06/02). 
On Monday of next week (06/04), we should try to release RC1 for 
Atlanta, and shortly after that (maybe 06/09), we should make a final 
release.

Do you think we can keep this schedule? Please let me know what you think.

Also, as soon as you have a new patch for the latest CVS version, could 
you please send it to me so that I can create a branch in the CVS?

Thanks a lot in advance!

Cheers,
Joschka