Re: [Borg-asm-devel] Input/Ouput

[<rea...@gm...>]

> As a follow-up to Thorsten's message - 

This is meant as a request to everyone. If your post is a followup to
someone else's, please hit the reply button in your mail client instead of
writing
a totally new email. The reason why you should do so is that some email
clients and the WWW archives (attempt to) display the posts in threads. They
can't
do that if every followup has a new subject. So please *reply* when you mean
it, write a *new* email if - and only if - you start a new thread.

Thank you in advance.

> I think it's best to do the sensor input using portals.

I agree. This should be a good way of ensuring that the simulation tasks are
adequately distributed between the engine (world geometry, environment data,
collision control etc.) and the bots (movement, actions, reactions to
environment).

> But if we wish the engine to run faster, we can have some built-in sensor
> types (eg: IR, UV, Encoders..) 

I think it would be sufficient if the (generic) sensor API would offer ways
to limit its output to certain bots/sensors. E. g., sensorAPI -> setLimits(
5
/* meters */, SENSOR_CONTOUR /* view */ ); (where sensorAPI is an instance
of the generic sensor and interacts directly with the sim core).
 
> What I mean is that the commands to the robot will be given
> using a machine-code set (depends on which processor).

Wouldn't this be rather uncomforable for those who want to build a virtual
robot? While real robots may be programmed in assembler or machine code, it
would, on the PC, require a simulation of the processor the code is
targetted
at plus an interface to the simulation. Additionally, the user would have to
learn yet another language - neither assembler nor machine code are really
hard to learn, but they're not the most comfortable languages or the fastest
to
write software in either.

> 1) More realistic

That would depend on how far we want the sim to become hardware-specific.

> 2) Faster than scripting of any kind
> 3) Safer than changing the source-code 

What about offering an API for writing robots in, then letting the sim
dlopen() (or whatever) the robots' DLLs? That would let the robot developers
write
their code in any language (e. g. C(++)) for which a compiler is available
which can build DLLs for the target OS. (OK, it's not that easy. But you
know
what I mean ;) )

If required, a way to integrate robot machine code in this concept would be
to create an interpreter for this code, then make the interpreter behave
like
a robot towards the sim. The interpreter would then effectively be a
macro-programmed robot, steered by the machine code.

> We can also support several processors with different machine-code set for
> each.

If the project will be as modular as has been asked for, that should be no
problem.


Erez: sorry, I meant to send this to the list right away. The webmail
interface was too dumb :(

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net