Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve nav to only use points in the middle of the hall as intermediaries. #12

Open
maxbogue opened this issue May 5, 2013 · 8 comments
Assignees

Comments

@maxbogue
Copy link
Contributor

maxbogue commented May 5, 2013

The best way to accomplish this would probably be to edit the neighbor data so that every landmark only has one neighbor: a waypoint directing away from it in the middle of the hall.

@ghost ghost assigned kberger May 5, 2013
@kberger
Copy link
Contributor

kberger commented May 6, 2013

I'm not entirely sure what you mean or how it would be an improvement over what we are doing now. Maybe sketch and attach an image of what you want?

@maxbogue
Copy link
Contributor Author

maxbogue commented May 7, 2013

hallway example

Black is the wall with doors, blue is the graph, and purple is the A* result. We never want it to go along a wall, and we wouldn't want it to cut over to the hallway waypoint in the top example. Instead we want a corresponding hall waypoint for each door landmark.

@kberger
Copy link
Contributor

kberger commented May 7, 2013

Door landmarks are not neighbors, so the top case does not occur. I talked to Zack about the inconvenience of driving between adjacent doors a while ago and he didn't seem worried about it.

I think that the hall landmarks are a little too sparse, because at the moment we kind of have somewhere in between these two cases. By that I mean we have something close to the top case, but without the door-to-door edge so the robot (in the above case) would go from the right door to the hall landmark and then back-track somewhat along the edge to the left door.

@maxbogue
Copy link
Contributor Author

maxbogue commented May 8, 2013

That's odd; I saw the robot try to go along a wall once. Maybe it just navigated directly from near the one door to the other door because it was technically visible?

@kberger
Copy link
Contributor

kberger commented May 8, 2013

I think that might be a case of overlap between the start and goal zones, so that will happen between nearby doors in the current algorithm

@maxbogue
Copy link
Contributor Author

maxbogue commented May 9, 2013

Is there any way we could prevent it that would make any sense?

@kberger
Copy link
Contributor

kberger commented May 9, 2013

If we reduce the size of the goal and start zones, that would reduce the chance of them overlapping. I think it's at 4 or 5 landmarks now, if we reduce to 3 I feel like we should still get good nav results. If you're at a door and pull the nearest 3 landmarks, you'll get the current door and at least 1 hallway I would think...but you might still get an adjacent door.

As it is, it won't go from door-to-door unless the doors or adjacent (or maybe adjacent + 1) which might be okay behavior. "Oh cool, this door is right next to me...I'll just jump over there reallllll quick!"

@kberger
Copy link
Contributor

kberger commented May 9, 2013

Zack just brought up the part of this that I was not considering. I guess it is bad to jump between doorways because we have no side-facing obstacle avoidance, so we really do want to go back into the hallway.

A clever solution as not fallen from the sky into my head yet...I'll keep thinking. Hopefully we can come up with something that doesn't result in adding a crapload of landmarks to the map...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants