Bugzilla – Bug 892
WaypointMobilityModel incompatible with MobilityHelper::Install
Last modified: 2010-10-05 04:35:27 EDT
WaypointMobilityModel is documented as follows: * The initial position of each object corresponds to the position of * the first waypoint, and the initial velocity of each object is zero. * Upon reaching the last waypoint, object positions becomes static and * velocity is zero. However, if this model is installed with MobilityHelper, MobilityHelper will set the position via the initial PositionAllocator. Note also that SetPosition is also valid and is not the same as setting a waypoint: * Waypoints can be added at any time, and setting the current position * of an object will set its velocity to zero until the next waypoint time * (at which time the object jumps to the next waypoint), unless there are * no more waypoints in which case it will not change without user * intervention. If a user sets a Waypoint at time 0, and also the user (or helper) calls SetPosition at time 0, what should be the initial position? Note that ignoring SetPosition() is probably not going to work out well since there may be future GUIs or scripts that layout nodes at time 0, and since users are likely to use this model through MobilityHelper. I would suggest that we would want to disallow the setting of both Waypoint and SetPosition at time 0. Something like the following: - SetPosition at time 0 creates the first Waypoint (at time 0). But, if no other waypoints are explicitly created, it will sit at the initial position. - User can also create Waypoint at time 0 and avoid explicitly calling SetPosition() (i.e., do not use MobilityHelper::Install) - if user tries to create Waypoint at time 0 and also to SetPosition at time 0, program errors out - if neither SetPosition at time 0 nor a Waypoint at time 0 is created, then the time 0 position is assumed to be the origin
Tom, I agree with your suggestion and I came up with a solution that represents it; however, the order of events in the initialization of a WaypointMobilityModel becomes significant. I'm not so sure it's an issue. First, to summarize the solution since I haven't uploaded my patch yet: calling SetPosition when no mobility is yet defined (m_first == true) adds the first waypoint (which sets m_current). Otherwise, it does what the current version does. The issue here arises mostly because the first waypoint actually indicates the initial position and time for the node. Sure, we might install mobility at t = 0, but maybe the movement (or "trip") doesn't start until t = 10, when the first waypoint is scheduled. The position for 0 <= t < 10 is the same as for t = 10, but that's when the node starts moving. I'm not sure if a more elegant solution would be to have an explicit initial position for each node, thus making the first waypoint in the list a "true waypoint" in the sense of the word (the node makes progress towards it from its starting position/time). Here are the two order-dependent initialization cases. Note that due to how I implemented this, t = 0 can really be any time the model comes into existence. 1) SetPosition @ t = 0, then add first waypoint. * Assuming waypoint.time > 0, the node moves between the initial position and waypoint.position, interpolating at times in between. 2) Add first waypoint @ t = 0, then SetPosition * Position will be set and velocity zeroed, overriding the first waypoint and jumping to the subsequent waypoint. Note that (2) means the suggested case of "if user tries to create Waypoint at time 0 and also to SetPosition at time 0, program errors out" won't happed; instead, SetPosition will take precedent and behave as it currently does. So, can we say this is OK since MobilityHelper::Install will call SetPosition before we get a chance to add any waypoints (I think)? Sorry for all the text on such a simple issue, I just want to make it very clear what the solution does.
> > Here are the two order-dependent initialization cases. Note that due to how I > implemented this, t = 0 can really be any time the model comes into existence. > > 1) SetPosition @ t = 0, then add first waypoint. > * Assuming waypoint.time > 0, the node moves between the > initial position and waypoint.position, interpolating > at times in between. > > 2) Add first waypoint @ t = 0, then SetPosition > * Position will be set and velocity zeroed, overriding the > first waypoint and jumping to the subsequent waypoint. > > Note that (2) means the suggested case of "if user tries to create Waypoint at > time 0 and also to SetPosition at time 0, program errors out" won't happed; > instead, SetPosition will take precedent and behave as it currently does. > > So, can we say this is OK since MobilityHelper::Install will call SetPosition > before we get a chance to add any waypoints (I think)? > I would be fine with your proposal.
Added InitialPositionIsWaypoint to provide an option for this behavior now. Please refer to the comment at http://www.nsnam.org/bugzilla/show_bug.cgi?id=893#c6 Patch set 5: http://codereview.appspot.com/144064
changeset: c5a7581f1e9