Grant Braught wrote:
Hi everyone,
We have been trying to evolve a NN based brain for a pioneer using pyro
with the techniques Doug describes for using PyroFromPython
(http://emergent.brynmawr.edu/emergent/PyroFromPython) and have run into
an interesting issue. In particular, we find that the results of
simulations run using the technique using engine.pleaseRun() (as at the
top of the PyroFromPython page) differ from those in which
simulator.step() is called explicitly (as in section 1.1 Running Faster
on the PyroFromPython page).
In particular, when directly calling simulator.step() it appears that
every time step is exactly 100 ms long, while when running under control
of the engine (or from the pyrobot gui) there is some non-determinism in
the length of the time step. This means that with simulator.step() the
brain can rely on precise timing between control opportunities that
don't exist in the other modes or on a real robot. Thus, when evaluating
fitness using simulations that run the faster modes the evolving brains
exploit the reliability of the fixed length time steps and as a result
perform very poorly when run in with the pyrobot gui (or on a real robot).
Has anyone else encountered this issue?
Grant,
You're absolutely correct about your analysis. When you use the
pleaseRun interface, you are talking to the simulator via threads and
possibly over sockets, too. Both threads and sockets allow places for
non-determinism to enter into the process.
Has anyone found a work around
other than running the simulations at real-time speed using the engine
or pyrobot interface?
When you say "work around", you wish to work around the determinism,
correct? BTW, determinism can be nice in some (simulated) situations
(for example, for watching a run over and over again for analysis or
debugging). Maybe you would like pseudo-random determinism? If you work
over threads then you have real, honest-to-goodness non-determinism:
there is no way to replicate a run as the timing differences are real.
One possibility that I can think of would be to add noise to the amount
of translation or rotation that actually occurs during one time step of
the simulation. Has anyone had any experience with doing that?
Yes, that is one possibility. Another is to add noise in the movement of
the robot. Currently, when you say robot.move(.5, .5), the simulator
will move exactly that much. You could add some variance to that. A full
model of noise is something that would be nice in the Pyrobot Simulator
(and one that I have requested for the Stage simulator as well).
Let us know what you find that works for you.
-Doug
Thanks for any insights.
Grant
_______________________________________________
Pyro-users mailing list
Pyro-users@pyrorobotics.org
http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
_______________________________________________
Pyro-users mailing list
Pyro-users@pyrorobotics.org
http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
