Re: [simspark-devel] About documents

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

Hi,

/*Markus Rollmann <rol...@un...>*/ wrote on 03/20/2008 
09:22:33 PM:
> Hi,
>
> Hedayat Vatankhah wrote:
> [...]
>> gettingstarted.tex: in Fedora, all of the simspark requirements are 
>> available in the official Fedora repository. ...
>
> yes, that would be nice. I'll include this into the 'getting started' 
> guide.
OK! But before that: Freeglut is no longer a requirement. It was used 
for the old rcssmonitor3d-lite and it is optional now (in the latest CVS 
version). So I don't include it here:

The command to install all of the requirements is:
yum install gcc-c++ ruby ruby-devel boost-devel SDL-devel freetype-devel 
libtool tetex-latex cvs libtiff-devel slang-devel ode-devel DevIL-devel

Notice that most of the above packages are available in the Fedora 
installation DVD. The only exceptions which will be downloaded from the 
internet are:
ruby-devel
ode-devel
DevIL-devel

In the above lists, I've excluded the packages which will be installed 
as requirements automatically by yum. If anybody wants to install the 
packages manually (for example if he had no internet connection in 
Linux), he should get the following RPM packages from an official Fedora 
repository (assuming that he'll install other packages from the 
installation DVD):
ruby-devel
ode
ode-devel
DevIL
DevIL-devel

To build and run rsgedit, the following command should be used:
yum install wxGTK-gl

(The packages which should be downloaded in case of manual installation 
without yum: wxGTK, wxGTK-devel, wxGTK-gl)

Finally, notice that the official ode packages do not use double 
precision. If double precision is required (I'm still using the official 
packages!), ode should be installed from source tar balls or by 
rebuilding ode rpms from it's SRPM with the required flags. (I'll create 
ODE RPM packages with double precision enabled for the coming server 
release)

>> ...
>
> that's a good question. The TouchPerceptor for example does send 'val 0'
> while no collision is detected. So this perceptor does send data when no
> collision is detected.
>
> We should decide for one behavior for all sensors. I'd say where
> possible keep silence (saving bandwith...)
Yes, it seems that it is good. Except if it can be problematic for teams 
(?!!). Specially, with more perceptors in future, the omitted portions 
could be significant. So, I won't change FRP now. Any other opinions?

> [...]
>> And for joint effectors, the unit of passed parameter is the desired
>> speed of the motor in Rads/sec (but it seems that it should be
>> changed to degrees/sec like the perceptors. right
>
> I agree that using degrees/sec might be more convenient. But changing 
> this causes trouble for existing agent implementations as they still 
> expect rads/sec, so their agent implementation fails silently (i.e. 
> without an obvious error).
>
> To change this we must also change the message format of the effector 
> to make it clear that degrees/sec are expected and still support the 
> current message format. I don't know if this is worth the trouble 
> though...
I have not any special preference here, just to make the units 
consistent with the joint perceptors.

Thanks,
Hedayat

>
> cheers,
> Markus
>