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)

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.

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]

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)

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)

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)