I certainly have no objection to the update step being changed, assuming
that it doesnt break something else (I don't recall the original
motivation for the current sequence). I am simply pointing out that you
will also need to change your client program if you are targeting real
robots. This is a particularly sore point with me because most of my
research is focussed on estimation, where a 100ms lag between odometry and
laser data can drive you crazy.
P.S. I suggest we move this conversation to a private channel, before we
annoy or titillate our audience too much. :-P
On Tue, 17 Feb 2004, Jefferson Provost wrote:
> I'd like to start by saying that any criticisms that I have today
> notwithstanding, I think Player and Stage are awesome, and a great
> thing for robotics, and I'm certainly a lot better off with them than
> without them, so I hope I don't come off sounding like an ungrateful
> malcontent below. ;-)
> On Feb 17, 2004, at 3:52 PM, ahoward wrote:
> > Hi Jeff:
> > This is an interesting example of "just bad enough" simulation. Yes,
> > the
> > simulator produces both deterministic and non-deterministic lags
> > between
> > the various sensors; these lags are not intentional, but are
> > side-effects
> > of the internal architecture.
> > Just like the *REAL* robot hardware.
> Forgive me if I say that this sounds like a post-hoc rationalization.
> This isn't the real reason for the backwards updating order, is it?
> This isn't a situation where the internal state of the world model is
> correct, but the process of rendering that state to the client is
> imperfect. In this case, the internal world model at any point in time
> is actually wrong.
> I don't understand why this should be inevitable. It doesn't seem to
> save in computation time or ease of programming. Functions like
> CEntity::GetGlobalPose seem to be written assuming that the parent's
> pose is up-to-date when they're called.
> > So yes, you could change the simulator to elimate these lags, but then
> > your program would be guaranteed *not* to work in real life.
> This is a very strong statement, and not really defensible, I think.
> Given the fact that the simulation is in fact better than the real
> world in other ways unrelated to sensor lags (e.g. no motor noise,
> perfect odometry, the truth device, etc) I would venture to say that
> lags or no lags, the guarantees of correctness are about the same.
> However, I don't think this is really relevant. From all appearances,
> the lag I'm referring to isn't a deliberate attempt to model sensor
> latencies, or anything else. Keeping a partially out-of-date world
> model doesn't actually make the simulation more realistic, it just
> makes it different from reality in a strange and arbitrary way. The
> fact that some hardware has strange and arbitrary idiosyncrasies
> doesn't mean that that's a desirable feature in the simulator. I
> recognize that tradeoffs have to be made in making a simulator, but I
> can't see what's being gained in this trade.
> It seems like a minimum standard of fidelity is that all rigidly
> connected entities should model themselves as being in the same place
> at the same time (modulo their relative offsets). The individual
> device model authors should get to decide how to model the latencies in
> their devices, rather than having something forced upon them by the
> architecture. I mean, even the truth device doesn't actually give the
> actual ground truth position -- it too is delayed by one timestep.
> > Having said all that, I should note that it is entirely possible that
> > the
> > lag in Stage is worse than on the real hardware; the only way to find
> > out
> > for sure is to do some empirical testing.
> Well, given that the length of the specific lag I'm talking about can
> be changed by changing the -v setting of the simulator on startup, and
> is the same for all devices that are children of a moving device like a
> Position, I'm not sure what these tests would mean, exactly. Surely
> different actual devices have different latencies.
> I really think this should be fixed, unless fixing it will break
> something else. I'll happily do it myself and send a patch.
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> Playerstage-users mailing list
Andrew Howard email: ahoward@...
Department of Computer Science http: www-robotics.usc.edu/~ahoward
University of Southern California phone: 1 (213) 740 6416
Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696
<< Insert pithy saying here >>>