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.

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 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.

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)

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.