Absurd altitude variation while it could be read from .gpx track file

[faegan]

Expected Behavior

The bot reads information from the .gpx track file, including altitude. When moving towards a waypoint, the "moving from" altitude should always match the altitude of the provided "to" location OR get altitude information from google maps.

Actual Behavior

The bot generates a random altitude between alt_min and alt_max and varies that every step taken and passes it as "from" location. This results in absurd altitude variation within 2 seconds.

Your FULL config.json (remove your username, password, gmapkey and any other private info)

http://pastebin.com/k74tJBss

Output when issue occurred

http://pastebin.com/96r5fiTN

Steps to Reproduce

fill in alt_min = 500 and alt_max = 1000 in config.json (these are default values)

Other Information

OS: Windows 10

Branch: DEV

Git Commit: 8276a33

Python Version: Python 2.7.12

Any other relevant files/configs (eg: path files)

[faegan]

Also, the following is silly for The Netherlands:
pokecli.py: error: --alt_min is out of range! (should be >= 0.0)

Most of our country is < 0.0

[mjmadsen]

Sorry about this @faegan. The initial altitude changes were added a bit willy nilly so we would stop sending 0 at all times. I can alter the alt_min value to better represent land altitudes.

As far as why other portions are not grabbing the alt when available, I'm not sure. Current work around is alter the min/max range to somewhere proportional to the area in which you are in.

[faegan]

Thank you @mjmadsen I've changed it to represent somewhat valid altitudes. I'd still like to see it use known altitude information from the track path file. I do not know if all .gpx files have this, but I used an export from gpsies and it contains this:

<gpsies:minHeightMeter>-7.0</gpsies:minHeightMeter> <gpsies:maxHeightMeter>1.0</gpsies:maxHeightMeter>

Could we override alt_min and alt_max when this information is in the path/track file?

[mjmadsen]

commit 4411b93 for your min_alt problem.

I haven't looked at those files too much yet. I'll put it on the list. Ideally, gpsies should rule everything except noise/jitter - I don't think we're close to that yet.

[mjmadsen]

While what is up is not perfect, at least you can put a min max for the area you're actually trying to bot in. I've been working on debugging pokemon catch bits of late, as well as misc. bugs. I'm hoping someone who is more familiar with those particular files will see this and put up a PR.

[faegan]

it's not to do with the files, I've narrowed it down to the StepWalker;

self.alt = uniform(self.bot.config.alt_min, self.bot.config.alt_max)

it seems it generates an altitude for each step instead of accepting it from the call in follow_path.py.

[mjmadsen]

Ah. Probably need to add in an alt parameter with a default value. If we're at default, we generate random. Something like that...

[faegan]

I kinda made it work for myself now, but I'll leave the coding to others.
I have edited the following files to make it work:
follow_path.py if statement in line 141:
step_walker = StepWalker( self.bot, lat, lng )

changed to:

step_walker = StepWalker( self.bot, lat, lng, alt )

and step_walker.py line 10:

`def init(self, bot, dest_lat, dest_lng, dest_alt=None):
self.bot = bot
self.api = bot.api

    self.initLat, self.initLng = self.bot.position[0:2]

    self.dist = distance(
        self.initLat,
        self.initLng,
        dest_lat,
        dest_lng
    )

    self.alt = dest_alt
    if dest_alt is None:
        self.alt = uniform(self.bot.config.alt_min, self.bot.config.alt_max)`

[mjmadsen]

That's great. Would you want to take a look at the other follow_ files and make the same changes and put up a PR?

[faegan]

@mjmadsen I have no idea how to do what you just said :)

I looked at the follow_spiral and follow_cluster files, and they also seem to use the random generation between alt_min and alt_max. Someone qualified (=not me) could look in to using requested GPS information from Google Maps and use altitude from that. But this could create issues with walking in spirals because it would just walk over buildings resulting in strange altitude variations again (just imagine NYC, one minute you're on a sidewalk, the other step you're on top of a high-rise)
In both cluster and spiral you'd be better off using an offset GPS (default in config) or a random one like now.

[mjmadsen]

To be you pretty much did it in your comment! While it won't fix all issues, passing the alt grabbed from each walker and having our stepwalker accept and apply it is the first step.

This is part of what I love about this community - I have barely used github before this and while I have some programming experience (I am not a professional) and, I've never used python. Now I'm learning both!

[mjmadsen]

Does #4581 satisfy what you're looking for?

[mjmadsen]

Closing, if there is an issue after #4599, it's probably with a specific walker that we haven't updated to send/get alt (new issue).