Bug 1219

Summary: ns-2-mobility helper does not handle midway course correction in input traces
Product: ns-3 Reporter: Anirudh <sk.anirudh>
Component: mobility modelsAssignee: Pavel Boyko <boyko>
Status: RESOLVED FIXED    
Severity: normal CC: andreev, ns-bugs
Priority: P5    
Version: ns-3.11   
Hardware: All   
OS: All   
Attachments: Proposed fix

Description Anirudh 2011-07-15 21:51:00 UTC
Hi

The ns-2 mobility helper does not handle midway course correction in the input trace file.

Eg:

Consider this trace :

$ns_ at 5 $node_(1) set X_ 5
$ns_ at 5 $node_(1) set Y_ 4
$ns_ at 6 $node_(1) setdest 5 5  1
$ns_ at 6.9999 $node_(1) setdest 5 3 1

Now, according to this trace, $node_(1) must move towards (5,3) at time 6.9999 starting from wherever it is. Looking at the previous lines, it follows that at time 6 $node_(1) moves towards 5,5 which it reaches at time 7. So in effect, asking the node to move towards (5,3) at time 6.9999 is asking it to change course.

I think this is allowed by the semantics of setdest in the original ns-2 spec.

However the output from ns-2-mobility-reader when run on this trace shows that 
ns-2-mobility-helper does not handle this correctly. Here is the output:

+5000000000.0ns POS: x=5, y=0, z=0; VEL:0, y=0, z=0
+5000000000.0ns POS: x=5, y=4, z=0; VEL:0, y=0, z=0
+6000000000.0ns POS: x=5, y=4, z=0; VEL:0, y=1, z=0
+6999900000.0ns POS: x=5, y=4.9999, z=0; VEL:0, y=-1, z=0
+7000000000.0ns POS: x=5, y=4.9998, z=0; VEL:0, y=0, z=0                                                              
+8999900000.0ns POS: x=5, y=4.9998, z=0; VEL:0, y=0, z=0 

The last line indicates the problem: at 8.9 seconds the node should be at (5,3) and not (5,4.8) 

If the course isn't corrected midway, ie if I replace the last line in my trace : $ns_ at 6.9 $node_(1) setdest 5 3 1  with the following :
$ns_ at 7.0 $node_(1) setdest 5 3 1,

the output is correct and the last line in the output is :
+9000000000.0ns POS: x=5, y=3, z=0; VEL:0, y=0, z=0  

 meaning the node is at position (5,3) after 9 seconds and not (5,4.9998)

This error could just ripple to subsequent lines of the file and is also likely to happen due to floating point imprecision ( ie is the trace is generated from some other source, and 7.000 is written out as 6.9998).

Anirudh
Comment 1 Kirill Andreev 2011-11-23 08:00:42 UTC
Created attachment 1275 [details]
Proposed fix

Patch contains a testcase, which is passed only with a fix provided.
Comment 2 Pavel Boyko 2011-11-23 10:26:59 UTC
Checked, ship it.

(In reply to comment #1)
> Created attachment 1275 [details]
> Proposed fix
> 
> Patch contains a testcase, which is passed only with a fix provided.
Comment 3 Kirill Andreev 2011-11-23 11:11:17 UTC
Fixed. Changeset 50350f5998e8