|
Bugzilla – Full Text Bug Listing |
| Summary: | ns-2 mobility helper improvements | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
| Component: | mobility models | Assignee: | Pavel Boyko <boyko> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | loulloudes.n, mathieu.lacage, ns-bugs, wade.colson, watrous |
| Priority: | P5 | ||
| Version: | pre-release | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Tom Henderson
2011-12-16 14:51:46 EST
Hi Tom, Pavel. Please let me know if you want some test-case traces to help in the resolution of this bug. I can generated them via a number of mobility generators that I am using. Nicholas. The only way to make this work is to implement a new mobility model in ns-3 that calculates the current position without being based on a velocity vector and that is based instead on a source and destination position. (In reply to comment #2) > The only way to make this work is to implement a new mobility model in ns-3 > that calculates the current position without being based on a velocity vector > and that is based instead on a source and destination position. Why not use the WaypointMobilityModel instead of the ConstantVelocityMobilityModel? Also, I have also observed that BonnMotion does not order the waypoints by time, but by node, leading to the situation described where initial node positions are not stored at the top of the file. I have had to post-process BonnMotion scripts to get them into acceptable ns-3 format. (In reply to comment #3) > (In reply to comment #2) > > The only way to make this work is to implement a new mobility model in ns-3 > > that calculates the current position without being based on a velocity vector > > and that is based instead on a source and destination position. > > > Why not use the WaypointMobilityModel instead of the > ConstantVelocityMobilityModel? Actually, nevermind this comment; the mobility is a set of destinations and speeds. Probably the only way to try to align them is to port ns-2's calcdest to ns-3, and even then it may not align. Bug closed. Changeset: 140eea99f4f2 I closed the wrong bug. The class now allows initial nodes to appear at the end of the trace file. ns-3-dev changeset: 92405ffdac3a (In reply to comment #0) > Reported on ns-developers list on 16 Dec 2011: > > First: > For Ns2MobilityHelper to work, we need to put > the first position lines at the beginning of the file. > That is, the following lines have to be at the beginning. > Some tools generate a ns-2 TCL file with these lines > at the end. So many users will forget to move them > at the beginning of the TCL file and have an > erroneous movement for nodes. > $node_(0) set X_ <initPositionX> > $node_(0) set Y_ <initPositionY> > $node_(0) set Z_ 0.0 > > Second: > Due to rounding error, the node get away from the > movement it should do. I used the TCL file than > Nicholas sent. Here are some results for the position > from the TCL script (second column) and the > Ns2MobilityHelper (third column): > > Sim. Time ns-2 Ns2MobilityHelper > 1.0 1.65 9.35 1.65, 9.35 > 2.0 1.65 13.12 1.65, 13.12 > 3.0 1.65 20.76 1.65, 20.76 > 4.0 1.65 28.120003 1.65, 28.12 > 5.0 1.65 36.66 1.65, 36.66 > 6.0 1.65 45.04 1.65, 45.04 > 7.0 1.65 51.65 1.65, 51.64 > 8.0 1.65 60.52 1.65, 60.51 > 9.0 1.65 68.04 1.65, 68.03 > 10.0 1.65 75.44 1.65, 75.43 > > As you can see, at the beginning, Ns2MobilityHelper > is doing a good job. Just few effect of the > rounding errors. > > Look around simulation time 200.0, the node is still > not to far away from its required position. > > Sim. Time ns-2 Ns2MobilityHelper > 201.0 1.65 1547.12 1.65, 1547.05 > 202.0 1.65 1554.4302 1.65, 1554.35 > 203.0 1.65 1562.8099 1.65, 1562.74 > 204.0 1.65 1569.3 1.65, 1569.23 > 205.0 1.65 1576.04 1.65, 1575.97 > > But at simulation time 400, the node is already > far from the required position. > > Sim. Time ns-2 Ns2MobilityHelper > 401.0 1.65 3098.95 1.65, 3089.34 > 402.0 1.65 3106.38 1.65, 3096.77 > 403.0 1.65 3115.08 1.65, 3105.47 > 404.0 1.65 3123.33 1.65, 3113.72 > 405.0 1.65 3132.0898 1.65, 3122.48 > > And the situation is getting worst with time. Every > new movement starts at the COMPUTED last > position of the previous movement. It should start > at the SPECIFIED last position in the ns-2 TCL > script. So the effect of rounding error is corrected > in each movement specified in the ns-2 TCL file, and > there is no accumulation of rounding errors over time. Were these numbers created by running ns-2 and ns-3? If so, can you attach the ns-2 and ns-3 scripts that were used? These actions were taken to resolve this bug: - ns-2 mobility helper was verified to produce same output as ns-2 - sample BonnMotion trace and example program added - documentation of ns-2 mobility trace reader was improved - new test code added *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/gay-video-chat-rooms Marked for reference. Resolved as fixed @bugzilla. |