Archived

This topic is now archived and is closed to further replies.

slepyii

Wall Detection and FOV (With Image)

Recommended Posts

slepyii    122
Hi Guys, Just want to bounce an idea I have for Wall detection around. It seems that most everyone has gotten used to the current wall detection setup, but I think it doesn't make much sense. I may be interpreting wall detection completely wrong so this may be a completely moot point. Why can we only see one wall at any given point in time if there are actually two walls in our FOV? I think that walls should be reported at the point where they enter the FOV farthest from the Bot instead of on a perpendicular line. This will allow for two walls to be seen at any given time if you are headed towards a corner. I have a picture of what I am thinking as it can explain what I thinking better than I can in words .    The two red squares would be reported as wall locations by GetObjectInSight in the setup that I am thinking of, as that is where the wall enters the FOV at the furthest point from the bot. The red line should be ignored. Image Key ---------    - Darkest blue is the bot.    - Medium blue, FOV of closest objects (Item only visible if it has moved since last update)    - Light blue is current FOV (Approximation)    - Green arena boundaries (Walls) I know this may be asking allot and better off for the re-write of the Arena core (if and when it happens), but it makes more sense to me, and seems to follow human vision a bit better than the current setup. Feel free to include your thoughts . - Timothy S. edited for wording [edited by - slepyii on August 14, 2003 10:37:48 AM]

Share this post


Link to post
Share on other sites
Dredge-Master    175
It makes sense to me to, as we have to change alteast 10 degrees, and up to 90 to see the other blasted wall at the moment .

If it helps, ignore the walls.
If you find a wall, instead of just capping it, just make it a barrier in the bots memory. This way it can be at any orientation (lets say your bot starts look 45 degrees off to the upper left) and the walls will then all be at 45degree offsets. It won''t matter that they are there then. It''s just a fence the bot found which it won''t cross.
Works for mine anyway.

And yes, it is harder to code, but when it works, its happy.

Share this post


Link to post
Share on other sites
Dredge-Master    175
oh, btw - to add to that, my idea (makes it really easy) is to basically have gdarena return data for a point on the wall (farthest, closest or left to right, doesn''t matter) and a vector.

That way you know where the wall is and you can see multiple ones at a time.
To make it a bit more human like, you could maybe get two points instead, that way it only shows the section of the wall that you can see. The Bot has to figure out how long the complete wall is by itself, but atleast it can see all the the wall in its fov, not just the closest point.

Share this post


Link to post
Share on other sites
JohnBSmall    881
quote:
Original post by slepyii
The red line is where the current GetObjectInSight is returning a wall if I understand things correctly.

Well, if I''m understanding your diagram right, then the red line is not the line used by the arena to tell if a wall is in your FOV.

And so, my own diagram (made in Paint, so forgive the blockiness):
wall detection diagram

In that diagram, the wall on the left can be seen by the bot, because the red line (the line perpendicular to the wall, from the wall to the bot) is within the bot''s FOV. But the wall on the right cannot be seen by the bot, because a perpendicular line from the wall to the bot would not be in the bot''s FOV.

But that''s slightly irrelevant really. I do agree that there is a problem with the current system in that even if a large section of wall is in the bot''s FOV, the bot might still not be able to see it. I''m not sure what the best way of dealing with this is though. Perhaps stick with the current form of information (ie, angle to the wall normal, and distance from the wall) but provide that information whenever any part of the wall is in the bot''s FOV, instead of only when the bot can see the intersection point.

John B

Share this post


Link to post
Share on other sites
slepyii    122
Thanks. This proves that I was interpreting what Kevin was stating about wall detection as being incorrect (actually just backwards), so yes, my red line is incorrect and should be ignored.

As for the idea of giving two points on the wall, where it enters and leaves the FOV. My initial feeling is that makes things too easy as you could easily tell which wall you were looking at. If only one point on the wall is given at any one time then it would require a bit more work internally by the bot (though not much) to figure out the orientation of the wall and where the corners of the arena are.

- Timothy S.


[edited by - slepyii on August 14, 2003 10:07:55 AM]

Share this post


Link to post
Share on other sites
cman    122
without changing the arena core, the most elegant solution is storing the walls'' coordinates, and writing a position detection algorithm, and check the coordinates against that values.

Share this post


Link to post
Share on other sites
Dredge-Master    175
I''m just curious, but how many people NEED the walls to orientate their bots? I''m only using them as markers so the bot knows not to run off the edge of the map, other wise they are useless.


Just thought of something. have an out of the ring area. so instead of a wall, its an area around the map that if the bot steps into they get disqualified, or loose maybe 1 health every frame (or maybe 45 frames - ie one second).

Also means we don''t have to worry about bumping in to the walls anymore

Share this post


Link to post
Share on other sites
slepyii    122
When I get around to writing my bot, hopefully soon, I''m not planning on using the walls, though things may change. I was just stating how I thought the bot using the current interface setup should detect walls. It makes more sense to me to be able to see the walls if they are in the FOV even if you can''t draw a perpendicular line from the wall to your bot.

Figured this would also give everyone a chance to discuss the wall detection setup as I have seen a few (ok, maybe more ) posts about the current setup.

- Timothy S.

Share this post


Link to post
Share on other sites
Ready4Dis    180
quote:
Original post by Dredge-Master
I''m just curious, but how many people NEED the walls to orientate their bots? I''m only using them as markers so the bot knows not to run off the edge of the map, other wise they are useless.


Just thought of something. have an out of the ring area. so instead of a wall, its an area around the map that if the bot steps into they get disqualified, or loose maybe 1 health every frame (or maybe 45 frames - ie one second).

Also means we don''t have to worry about bumping in to the walls anymore


I have my bot detecting when there is nothing or nothing but a wall, in which case, it turns itself. The problem is, in wide areas, it won''t see the other bot between the wall and some object because my bot turns away to quickly.

Share this post


Link to post
Share on other sites
khawk    2904
I''ve said this several times.. if you have a truly better way to implement wall detection without requiring major changes to the interface, I''ll consider it. Otherwise, so far, the current implementation is the best solution I have come up with.

Share this post


Link to post
Share on other sites
slepyii    122
quote:
Original post by Khawk
I''ve said this several times.. if you have a truly better way to implement wall detection without requiring major changes to the interface, I''ll consider it. Otherwise, so far, the current implementation is the best solution I have come up with.



I understand this and was just getting thoughts out before they left my mind. I feel it is better to get them down on paper (or within the forum in this case) so that they are not forgotten later on down the road . This is also one of the main reasons that I stated this was probably asking allot and better off if/when a complete re-write is done.

Along the same lines I feel that the increase in the FOV for wall detection to 90 degrees eliminates my main point from the original post, as you should now be able to see two walls when looking directly at a corner . Thanks!

- Timothy S.

Share this post


Link to post
Share on other sites
drreagan    122
just want to make sure everyone else is seeing the same thing:

when an object is within your bot''s circular LOS radius, but not within its angular (40-degree) LOS, the direction of the observed object is always 0 degrees? This is what i''m seeing at least.

can anyone confirm this for me?

-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)

Share this post


Link to post
Share on other sites
khawk    2904
quote:
Original post by drreagan
just want to make sure everyone else is seeing the same thing:

when an object is within your bot''s circular LOS radius, but not within its angular (40-degree) LOS, the direction of the observed object is always 0 degrees? This is what i''m seeing at least.

can anyone confirm this for me?

-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)





That''s how it works.

Share this post


Link to post
Share on other sites
drreagan    122
quote:
Original post by Khawk
quote:
Original post by drreagan
just want to make sure everyone else is seeing the same thing:

when an object is within your bot's circular LOS radius, but not within its angular (40-degree) LOS, the direction of the observed object is always 0 degrees? This is what i'm seeing at least.

can anyone confirm this for me?

-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)





some definitions--
regular LOS: the 40 degree LOS that has been in effect for all the arena releases so far.
proximity LOS: the new (0.03) LOS addition of a small circle around the bot.

quote:

That's how it works.




If this is the case, I would suggest one of two things: that the regular LOS query be separate from the proximity LOS query. or: the proximity LOS query should return a unique identifier in the event that an object is detected in the proximity zone (that is fine with me that the bot doesn't know the direction to a sensed object in close proximity, but at least the bot should know that he *doesn't* know the direction to the object).

this way, we can deal with these cases separately. right now, it is impossible to handle a situation, for example, where the bot closesly passes an object, the object is then detected in the proximity LOS zone and the bot suddenly thinks he "sees" an object directly in front of it (at 0 degrees). right now, both my bot's internal mapping system and its reactive layer are totally broken because of this. he will steer to pass by an object, then when the object is detected in the proximity zone, he thinks the object is directly in front of him (0 degrees, after all...) and keeps turning to try and avoid the object, but the object stays at 0 degrees!!!

-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)



[edited by - drreagan on August 18, 2003 11:26:11 AM]

[edited by - drreagan on August 18, 2003 12:31:52 PM]

Share this post


Link to post
Share on other sites
drreagan    122
another possibility:

if an object is in the proximity LOS but not in the regular LOS, return a distance of -1. the drawback to this, of course, is that information on the distance of the object is lost.

-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)

Share this post


Link to post
Share on other sites
drreagan    122
quote:
Original post by Khawk
I''ve said this several times.. if you have a truly better way to implement wall detection without requiring major changes to the interface, I''ll consider it. Otherwise, so far, the current implementation is the best solution I have come up with.



simple (in theory; i don''t know how simple it would be in terms of the arena''s engine architecture). construct a frustum aproximation of the bot''s view angle and do a frustum/segment intersection test between the bot''s view frustum and the wall segments. if there is an intersection, return the point of intersection. the drawback: if a wall intesects with the curved part of the bot''s actual FOV, the frustum/segment test won''t detect the intersection (as the frustum is a trapezoid). i don''t believe this would be too processor intensive, as there are only 4 segments to test each update!

however, i think this is now irrelevant, as the current (v0.03) 90 degree wall FOV is a much simpler solution to the problem!

btw, thanks for the update khawk...hope you had (or are still having?) a great vacation!



-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)

Share this post


Link to post
Share on other sites
flipper76108    122
quote:
Original post by drreagan
another possibility:

if an object is in the proximity LOS but not in the regular LOS, return a distance of -1. the drawback to this, of course, is that information on the distance of the object is lost.


right now i''m able to detect the appearance of the proximity objects by checking them against previous info. if they''re not found at close to the same distance and close to 0 degrees direction then they''re tagged as proximity until they show up again with a non-zero direction and are "rediscovered". seems to work although i can''t honestly say i''ll use it for anything since the object''s direction is unknown.

if changes were to be made, i''d vote for a negative distance indicating a close proximity object, with maybe some sort of quadrant indicator so the bot would at least know if it was to the left, right, or behind. fixing the direction to be 90, -90, or 180 would work in this case.

Share this post


Link to post
Share on other sites
drreagan    122
quote:
Original post by flipper76108
quote:
Original post by drreagan
another possibility:

if an object is in the proximity LOS but not in the regular LOS, return a distance of -1. the drawback to this, of course, is that information on the distance of the object is lost.


right now i''m able to detect the appearance of the proximity objects by checking them against previous info. if they''re not found at close to the same distance and close to 0 degrees direction then they''re tagged as proximity until they show up again with a non-zero direction and are "rediscovered". seems to work although i can''t honestly say i''ll use it for anything since the object''s direction is unknown.

if changes were to be made, i''d vote for a negative distance indicating a close proximity object, with maybe some sort of quadrant indicator so the bot would at least know if it was to the left, right, or behind. fixing the direction to be 90, -90, or 180 would work in this case.


as you point out with a concrete example, i''m sure that it is possible to work around this limitation. however, this solution requires an internal mapping/object tracking mechanism...something i''m not sure should be a system that is *required* in order for someone''s bot to work (maybe the person is just interested in making a purely reactive bot that doesn''t need to worry about "changes" in the positions of supposedly static objects from frame to frame).

good idea about the inclusion of quadrant information, although i wouldn''t be opposed if kevin elected to leave this out.

-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

(author of DustBot)

Share this post


Link to post
Share on other sites
flipper76108    122
quote:
Original post by drreagan
as you point out with a concrete example, i''m sure that it is possible to work around this limitation. however, this solution requires an internal mapping/object tracking mechanism...something i''m not sure should be a system that is *required* in order for someone''s bot to work (maybe the person is just interested in making a purely reactive bot that doesn''t need to worry about "changes" in the positions of supposedly static objects from frame to frame).

actually i''m doing it without aid of a map and the only object tracking done is to keep the previous Update cycle''s info as gathered from the arena interface. the test for proximity object or valid zero degree object it done using the relative distances and directions from the arena, with the assumption that no object has "moved" relative to the bot more than the fast turn rate and/or the high forward speed.

but i agree, having the interface directly indicate proximity would definitely be cleaner. i''ve just gotten kind of used to having to write these little snippets for this app so i don''t mind too much. it''s actually kind of fun to see if a particular lack of information can be solved without having to interrogate the map.
quote:
Original post by drreagan
good idea about the inclusion of quadrant information, although i wouldn''t be opposed if kevin elected to leave this out.

thanks. quadrant info would be nice, but yeah, i could live without it too. i only seeing using this if the bot gets caught in unfamiliar territory, so for me it''s no big deal.

Share this post


Link to post
Share on other sites