Python API and the mobility() arriving station at the stop position earlier than expect when running 2nd time

[crbertoldo]

Hello,

I'm not sure if a bug or a wrong implementation due to misunderstanding, but the following code exploring the Python API and the mobility() is not behaving as I expect.

https://gist.github.com/crbertoldo/b2d21d54606f6b397f0bf92973f82335

The first mobility code block (from line 40 to 45) works as expected, i.e,. the 'sta1' takes 10 seconds to arrive at the final position='31.0,10.0,0.0', but the second one (from 49 to 54) - same as previous - takes only 5 seconds.

The net.stop() at line 47 takes no effect. Starting the second mobility in time=12 and then starting moving 'sta1' in time=13, stoping it in time=22 and stoping the mobility itself in time=23 also doesn't solve.

My goal is to implement a full tracing from point A to B (not straight) thru many straights.

[ramonfontes]

Hello Claudio,

If I understood you correctly you can use the parameter repetitions, for example: net.startMobility(time=0, repetitions=1)

You can also try: net.startMobility(time=0, repetitions=2, reverse=True)

Still regarding the mobility and traces, you may want to take a look at this short video: https://www.youtube.com/watch?v=nywoltaRVSE - the telemetry stuff should work with any mobility approach.

I also recommend you to take a look at examples/replaying/replayingMobility.py

[crbertoldo]

Hi @ramonfontes ,

Thanks for the quick reply.

I was seeing a related question on https://github.com/intrig-unicamp/mininet-wifi/issues/245 and applied https://github.com/intrig-unicamp/mininet-wifi/commit/1a65dc0745296b33723e7a0d1602f0742144fd77. The behavior has changed: now the second block (from line 49 to 54) doesn't move 'sta1'. BTW, now I think I can use sta1.coord = [start_a, stop_a_start_b, stop_b_start_c ...], but there is another little issue: for instance here (https://gist.github.com/crbertoldo/d22258be331e5294b84d72285e3487f8), the speed is 1.67 (50m/30s), but at each 1 second, the position increment by 1 and not by 1.67, so at 30 seconds (end), the position will be (30, 0.0, 0) instead of (50, 0.0, 0). The 'position' is being updated as int, but I could not find where in code. Note: neither 30 nor 50 has '.0', what reinforces it's being returned as int. In fact, node.points has only int for x in this example, so will just run well when speed is also int.

[ramonfontes]

now the second block (from line 49 to 54) doesn't move 'sta1'

The second block won't work, because the code is currently using threads for mobility.

but there is another little issue

Fixed with https://github.com/intrig-unicamp/mininet-wifi/commit/40aa5279c65bda3f38209ee16987ee17654c7ad5 ;) You can do git pull and sudo make install to apply the changes.

[crbertoldo]

Hi @ramonfontes ,

Thanks a lot. It has worked as expected. BTW, just another point for discussion (if you think I should open another thread, please let me know):

Concerning the following:

sta1.coord = ['0.0,0.0,0.0', '50.0,0.0,0.0', '75.0,0.0,0.0'] net.mobility(sta1, 'start', time=1) net.mobility(sta1, 'stop', time=30)

'sta1' will run the first segment (50 meters, horizontally) within 15 seconds, i.e., at 3,33 m/s, and the second one (25 meters, still horizontally) within the remaining 15 seconds, i.e, at 1.67 m/s. For the whole path, sta1.params['speed'] returns 1.67, but this isn't my point yet.

Conclusion: it divides the time (stop minus start) by the number of segments (2) and then adjusts the speed at each one (even params['speed'] not being updated - ok so).

But I think it makes sense to calculate the total length of sta1.coord (in my example: 75 meters) and then keep a constant speed (e.g.: 75/30 = 2.5 m/s) during the whole path. This way, still in my example, sta1 would reach 50.0,0.0,0.0 at time = 20 sec instead of time = 15 sec. Please, what do you think?

P.S.: as a workaround for my application, I'm putting all coordinates in 'sta1.coord' with a difference of 10 meters to each other, no matter the direction, so I keep a constant speed and adjust it thru the stop time.

[ramonfontes]

Hi @crbertoldo ,

Thanks for the tests and for your suggestion. Yes, that's make sense.

Please try https://github.com/intrig-unicamp/mininet-wifi/commit/e3b939f6fb8c9888c4ca6c6bee059ad8a900a230 and let me know whether it works now.

[crbertoldo]

Hi @ramonfontes ,

Thanks a lot. I just suggest to float(pos_src[n]) in Node.get_distance_to() to avoid "TypeError: unsupported operand type(s) for -: 'str' and 'float'"

[ramonfontes]

Done! https://github.com/intrig-unicamp/mininet-wifi/commit/652a5b8fc24624b044a3243d1d06beda8bb6f09e

[ramonfontes]

@crbertoldo ,

I released last week a new feature in which can be used for the purpose of this issue too. You can set the position via sockets (https://www.youtube.com/watch?v=k69t9Xkb0nU) by programming your own code in basically any programming language. You can, for example, run the client script in each node and then the node moves according to your own logic. This new feature can be very useful in topics such as self-driving cars.

[crbertoldo]

@ramonfontes, many thanks. I am going to play with the new sockets feature.