"FollowPath" Did not work.

[maxprzemo]

Expected Behavior

Working "FollowPath"

Actual Behavior

A week ago everything worked (I have not used a bot by week) . No changes to the settings (I do not see the changes to be introduced in config.json).

FULL config.json

http://hastebin.com/wuduwiqaci.js

Output when issue occurred

[2016-09-10 09:49:07] [MainThread] [FollowPath] [INFO] Great job, lot of calories burned! Taking a break now for 0:27:15, will resume at 10:16:22.

The first point of "path_file" It is the end of the loop. I cleaned folder /PokemonGo-Bot/data , I cleaned files cells-XXXXX.json, last-location-XXXXXX.json, XXX.db, mqtt_client_id

"MoveToFort" works correctly

Other Information

OS: Debian 8.5 Branch: master Git Commit: ./setup.sh -r today morning

[Lntnam]

How do you define "not working".

You didn't provide any problem statement in your post.

[maxprzemo]

I wrote The first point of "path_file" It is the end of the loop. [INFO] Great job, lot of calories burned! Taking a break now for 0:27:15, will resume at 10:16:22

Bot should visit over a dozen points. And not only the first. I do not see error in the file .json

[ {"location": "51.649248, 17.815931"}, {"location": "51.649298, 17.817352"}, {"location": "51.650875, 17.817767"}, {"location": "51.650092, 17.821311"}, {"location": "51.648132, 17.821406"}, {"location": "51.647845, 17.819335"}, {"location": "51.647224, 17.817184"}, {"location": "51.647391, 17.814938"}, {"location": "51.645923, 17.814339"}, {"location": "51.643867, 17.814540"}, {"location": "51.644918, 17.813323"}, {"location": "51.647485, 17.811350"}, {"location": "51.649158, 17.811037"}, {"location": "51.648709, 17.812522"} ] A week ago everything worked. I do not see in the documentation of changes.

[julienlavergne]

Need more log, giving us only the last line is not going to help a lot. Where are the lines "Walking from..." and every other logs output by the FoolowPath task ?

[maxprzemo]

http://hastebin.com/ucefotejef.vbs

Edit: "StepWalker" Works correctly. Something is broken on the line "FollowPath" -> "PolylineWalker"

[julienlavergne]

It only looks like you are already at he final location but cannot confirm because you removed your starting position.. Maybe put more loop than only one in your config.

[maxprzemo]

"MoveToFort" -> "walker": "StepWalker" It works "MoveToFort" -> "walker": "PolylineWalker" It works "FollowPath" -> "walker": "StepWalker" It works "FollowPath" -> "walker": "PolylineWalker" Does not want to work

I'm sorry that it did not immediately turned off "walker_limit_output": false, Now you can see in the log much more http://hastebin.com/hiwalaredu.coffee

See "distance left:" Each step is another target. 13 steps to 13 targets with my file path.json Bot has walked only a few meters

[julienlavergne]

Should be fine now after my PR is merged

[th3w4y]

@maxprzemo your output seems correct in regards to increase decrease in distances...

See "distance left:" Each step is another target. 13 steps to 13 targets with my file path.json Bot has walked only a few meters

We don't handle yet displaying of the real walking distances when using PolylineWalker What you see there as an increase and decrease in distance is the fact that you took a corner....

For display the point-to-point distance is used which is smaller then the polyline distance for the walking path....

Now you can see in the log much more http://hastebin.com/hiwalaredu.coffee

[th3w4y]

Was this here?.. as I see you took a corner....

[julienlavergne]

I fix the issue, his problem comes from the dist < 1 in FollowPath task.

[th3w4y]

@Anakin5 yes you fixed it i confirm!

I was providing a comment regarding the decrease-increase in the displayed distance

See "distance left:"

We still have a issue there In all PolylineWalker tasks.. but to fix that... Tasks would need a step_walker.get_remaining_dist() instead of calculating the distances themselves or something...

but since he was only side-mentioning this... I consider it low priority thus I would possibly close this bug as fixed... (having in mind that a huge refactor would be needed to fix that display issue... and weighting the value against work involved)

[th3w4y]

Wait a second... http://hastebin.com/hiwalaredu.coffee

The walking speed is hugely strange... 70-200m/s

Don't want to zoom yet... @Anakin5 you probably have the code still fresh in your mind... was that related with the bug you fixed... is there any possibility that the bug would have manifested as these speed bumps as below?

[2016-09-10 18:52:33] [MainThread] [FollowPath] [INFO] Walking from (51.649009968668885, 17.817190031250046, 135.2562561035156) to (51.645923, 17.814339, 8.0), distance left: (0.40 km) ..
[2016-09-10 18:52:34] [MainThread] [FollowPath] [INFO] Walking from (51.64898998661595, 17.81721003114866, 135.2562561035156) to (51.643867, 17.81454, 8.0), distance left: (0.60 km) ..
[2016-09-10 18:52:35] [MainThread] [FollowPath] [INFO] Walking from (51.64897092415763, 17.81725439513088, 135.4530792236328) to (51.644918, 17.813323, 8.0), distance left: (0.53 km) ..
[2016-09-10 18:52:36] [MainThread] [FollowPath] [INFO] Walking from (51.648959984976194, 17.817280059939826, 135.5178833007812) to (51.647485, 17.81135, 8.0), distance left: (0.44 km) ..

[julienlavergne]

@th3w4y I have still 2 issues to fix in a commit PR. One is related to the fact that we don't always sleep 1 second between step(). The effect is that we can have sudden speed bump because step is called several times per second. The second issue is that there is a scenario in which we never converge to the final destination.

[th3w4y]

@Anakin5

1) I though the sleep one was fixed... in dev

One is related to the fact that we don't always sleep 1 second between step().

now it all makes sense... he is using master...

OS: Debian 8.5 Branch: master Git Commit: ./setup.sh -r today morning

2) we don't get close enough to return True you mean? That is strange... This one should also have been fixed in dev.... [the whole rewrite of PolylineWalker and StepWalker are not in master yet i believe...]

The second issue is that there is a scenario in which we never converge to the final destination.

[th3w4y]

@solderzzc when do we plan to merge dev into master?

[julienlavergne]

@th3w4y When we do not converge, it is not because we do not get close enough. I do not have yet the source of the problem but at some point and under certain conditions, the get_next_position enter an infinite loop and repeatedly make us navigate in a very small area without getting closer to the destination, ever.

[th3w4y]

@Anakin5 is dev right?

It is in stepWalker?

because i don't see the offset_angle formula anymore... offset_angle = (100/self.speed)*(precision/1.74) where did that one disappeared?

[th3w4y]

random_azi = uniform(inverse["azi1"] - 90, inverse["azi1"] + 90) is much more then precision + epsilon https://github.com/PokemonGoF/PokemonGo-Bot/commit/755ef56d6c123a3ee5fcc76ed5120b30c7aa6746#commitcomment-18983106

[julienlavergne]

It is an angle, precision is a distance

[th3w4y]

you are calculated the theoretical distance then offset by and angle.... (if that is more then offset_angle it can tick back....)

you are getting close then tick back... then tick back.... then distance is alway > precision + epsilon

[julienlavergne]

The important thing to see in this block is next_lat, next_lng

random_azi = uniform(line.azi1 - 90, line.azi1 + 90)
random_dist = uniform(0.0, self.precision)
direct = Geodesic.WGS84.Direct(next_lat, next_lng, random_azi, random_dist)

Anyway, I think the issue comes from the MoveToFort task. I have a scenario in which the MoveToFort makes us switch between 2 forts forever.

[th3w4y]

offset_angle was making sure that the azimuth modification were towards the direction of walking.... +/- x degrees to the current azimuth in such a way that the arrival destination was only one "precission" away from the theoretical... but towards the final destination...

[julienlavergne]

I let you read it and draw it on paper. You will see that the angle between origin and the final computed next is always towards the destination.

[th3w4y]

you have +/- 90

if angle is 90 degrees... distancetodest**2 = 2(precission+eps**2) distancetodest > precission+eps

or actually to generalize for any angle > +/- 60 degrees distancetodest > precission+eps

[julienlavergne]

[th3w4y]

When random azimuth is +/-90

In the destination vicinity.... (precision distance from destination...)

You will never converge... for angles > +/- 60 degrees

[julienlavergne]

I don't see the problem on your graph, Starting from origin, any point in the red area is a valid point and contribute to go toward the destination. The starting point is Origin, it is not 1st next. I highlighted 1st next because we compute two next_point in the get_next_destination function.

[th3w4y]

check my update on your graph... https://github.com/PokemonGoF/PokemonGo-Bot/issues/5362#issuecomment-246324525

Green areas have a potential to not converge... in precision vicinity from destination...

[julienlavergne]

Can you put a legend ? I don't understand what is the new black line and the new black point.

[th3w4y]

new black point is the final destination....!!!!!

black line was distance to the most extreme point to destination...

Check update above... https://github.com/PokemonGoF/PokemonGo-Bot/issues/5362#issuecomment-246325429

[julienlavergne]

so the red half circle is around it like that:

[th3w4y]

Ohh i see so is self correcting in next step you mean...

[julienlavergne]

You are never more that precision away from the theoretical path, and you move along the theoretical path. So mathematically, at some point, your are less than precision away from your destination.

You can, in extreme random cases, get a bit further from your destination than you were at previous point, but that is giving you more chance to get closer at the next step.

[th3w4y]

Yes.. i see i was missing that it will self correct on next step...

[julienlavergne]

The center of the red circle is not the origin point (the previous step point). It is the next calculated point along the theoretical path.

[th3w4y]

Hey I am thinking that if you change that angle to +/- 60 you will converge directly... and would be safer....

Otherwise you might have a worker Task that does not receive the proper awaited "True" and does not do its stuff at destination...

WorkerTask():

1. identifyDestinations_based_on_distance()!!! but discarding the too close ones...
2. create_step_walker()
3. step_walker.step()
4. wait _for_true()
5. do stuff if True... (at destination...)

When such a Task loops... it will select a new destination at part (1.) but never did received True in ( 4.) thus would have not ever executed (5.)

[julienlavergne]

You are supposed to call step() until it is true. You cannot predict the fact that the walker might be a polyline and thus might go away from your destination because that is how the road is. So even if you choose a destination at 10 meters from you and your speed is 10, it is not a guarantee that the next step will return true.

[th3w4y]

I am referring to smaller distances... around precission...

But in principle if +/- 60 degrees should be safer and still correct why not use that? why would you want to have few extra steps (at random times....) until it converges?

Look in follow_cluster... it can make the difference between this message being displayed or not ""Arrived at cluster. {num_points} {forts} pokestops are in a range of {radius}m radius."" ... while SpinFort spins the fort and removes if from the fort list.

(follow_cluster is probably the most non-standard code anyway... :) no WorkerStatus.RUNNING nor SUCCESS :) most probably the SpinFort remove the closest fort way before being close to destination... since MAX_DISTANCE_FORT_IS_REACHABLE = 38... but i was giving that as an close enough example to illustrate what one extra step could result in.... )

[julienlavergne]

Can you describe the scenario in which you see it diverging ? Is it a bit more than precision or a bit less ?

[th3w4y]

Or this one if not step_walker.step()

        if pokemon['is_vip'] or nearest_fort is None:
            # lock catching(with pokemon_id specified) while moving to vip pokemon or no fort around
            self.bot.capture_locked = pokemon['pokemon_id']
            step_walker = self._move_to(pokemon)
            if not step_walker.step():

                if pokemon['dist'] < Constants.MAX_DISTANCE_POKEMON_IS_REACHABLE:
                    self._encountered(pokemon)
                    self.bot.capture_locked = False  # unlock catch_worker
                    self.inspect(pokemon)
                    return WorkerResult.SUCCESS
                else:
                    return WorkerResult.RUNNING

        else:
            step_walker = self._move_to_pokemon_througt_fort(nearest_fort, pokemon)
            if not step_walker or not step_walker.step():
                return WorkerResult.RUNNING

If i look deep i also think we might have broke movetomap while refactoring StepWalker... https://github.com/PokemonGoF/PokemonGo-Bot/issues/4540

[julienlavergne]

Which part do you think is broken ? What is the scenario ?

[avexus]

Question, what is the diameter with in the path will the bot spin the poke stop? I have a path file too. copied from some map that i know of. when i copied those coordinates from google map, and put them into the path file, only half of the stops are spun.