Tamara Mahr's AI Project
Rollerblading Site Finder (RSF)

Intro

You are a fresh, wide-eyed first-year student or a new rollerblading enthusiast. You've got a pair of skates and you wonder where could you rollerblade on this wide-open expanse known as Busch Campus. The agent's task is to manage a user-friendly interface which allows users to ask specific questions and get customized answers about the Busch skating spots they're interested in. The user may check off criteria for selection and comparison among sites by a menu to build a query. The agent will access its knowledge base about the skating sites and will spit out a list of possible rollerblading "hotspots", tailored to your exact ability level.

In addition, you really don't want to drive or walk to a particular rollerblading spot (which would just defeat the purpose :p ). The computer can find a rollerblading route- tailored to your skating ability- to that destination.

The domain includes several prime locations on Busch, such as parking lots, streets, and courtyards. Busch is a pretty big place! This would be a great way to find out where exactly are the best places to skate around- from beginners to experts. You could find out if a particular site is right for you. In such a big place, it makes sense to have the robot search it's database to lessen the ouch/danger factor.

Thus, in addition to making side-by-side comparisons of various skating sites, the agent will field queries about routes between specific sites, allowing for alternative routes depending on the user's skating skills. In response, it can offer a high-level description of the route: what roads/sidewalks/grassy paths to follow, where to turn, etc.

Illustration

You would input that you're a beginner. You'd also want to know if there are any "hidden" cracks at the sites that may send you into a tumble. (Sometimes you may want to skate in the evening when it's a little hard to see some of the uneven edges that just jump out at you.) The agent searches its knowledge base for sites that meet all the criteria. This KB includes descriptions of several sites in terms of many properties: windy/straight; steep/medium/pancake flat; smooth/bumpy; grass/no grass; people factor; car factor, etc. Then it gives you a list of sites tailored for you.

For example, the user may choose a comparison menu item and enter 2 sites to compare. The user chooses Suites Courtyard and LSM. The agent now plans and constructs a response to compare the sites. It first accesses its KB to identify the similarities and differences. Then, it returns a simple, easy-to-read table to the user, listing all of the similarities and differences between the sites.

But even more interesting, the user may type in the query: ?cs(suites courtyard, lsm, beginner) to see if there is a route he can take to get from the Suites Courtyard to LSM. The agent accesses its KB:
1. Something characterized as beginner-level has certain qualities.
beginner(X):- smooth(X), flat(X), straight(X).
2. Now the agent must find segments represented in the KB that form a path to LSM.
a. It checks to see what segments are connected to each other. This is very similar to the Rutgers Routes example we did in class.
b. Not only does the agent have to find such a path leading to the LSM, but it also has to worry whether the steps along the route can be considered skatable by beginners. That is, the route is smooth, not too heavily used by cars, etc.
3. If such a route can be found, then the agent will return a high-level description of the route:
- courtyard_lotX sidewalk
- path between fiber optics & ceramic buildings
- stay right on serc paths
- sidewalk by Wright Labs
- cross Allison Road

Nitty Gritty Implementation Choices

I have chosen the domain as several sites on Busch campus. I could've chosen any location at Rutgers; but, as I have the most experience rollerblading around Busch, I have restricted the domain to this campus. In addition, I basically could've included any site imaginable as possible skating sites. I chose to stay on the realistic side. Obviously, Werblin doesn't allow in-line skating on their hardwood floors and swimming pools are out of the question. Otherwise, there'd be an infinite amount of places I'd have to delineate. The basic objects are the types of places, which I identify by the name of the site. My representation assumes that specific locales are the smallest class of skating hotspots I need to reason about. "Parking lots" would have been too general as there are quite a few parking lots on campus; we need to distinguish between them because some are smoother than others. (The alcohol studies lot is a personal favorite.)

I chose to describe the various sites using the prop predicate. From the Big Cheese project, it just makes it a lot easier to compare several sites based on a particular property. Also I could've have included any various descriptions/properties of the sites, for example color. However, I chose to concentrate on the properties that are relevant to the task at hand. Color of the pavement has no effect whatsoever on if it's easy to skate on a sidewalk! Properties, such as curviness or roughness, do!

Methods

The agent will add a segment that appears to be a part of the final route leading to the final destination. It also checks that the segment is designated as beginner level and goes through the rules and clauses in the database to verify this. If this all checks out, then we add the segment to our path list. Now what segment can we add to this previous newly added segment? We have the search problem all over again from this new starting point! We are one step closer to reaching our final destination.

If such a route can be found, then the agent will return a high-level description of the route:
- courtyard_lotX sidewalk
- path between fiber optics & ceramic buildings
- stay right on serc paths
- sidewalk by Wright Labs
- cross Allison Road

We start the search process with the empty list as the partial list solution denoting an eventual path to ARC. We start out with no assumptions. Once we add a segment to the partial solution list, we assume that that particular segment is part of the route to ARC and skatable by beginners. Similar to a depth-first search, we have a list of frontier nodes consisting of the locations directly connected to the last location we added to our partial solution list. During the search for the next segment to add, we may encounter a few different states for that segment:
1. Segment that just will not lead to our final destination. The agent will fail to find a path to ARC if we included this particular segment. cs(segment, arc) fails
2. Segment that will eventually lead to ARC but does not comply with the constraints we imposed with the user's skating ability. i.e., There is a contradiction: user is beginner-level AND segment is really steep. cs(segment, arc) succeeds but prop(segment, level, beginner) fails. It will not be added to the partial solution.
3. Segment that will eventually lead to ARC and is skatable by the user. cs(segment, arc) and prop(segment, level, beginner) succeed. It is added to the partial list solution. You just continue with the search problem from this new starting point.

For cases 1 and 2, the last assumption (the last segment we added to our partial path list) must be wrong as we don't end up in a goal state. We take the segment off the partial path list and our set of assumptions. We return to the most recent (next to last) segment that was added and attempt the search on its next neighbor (the next segment that was connected to it, if any).

I will probably use depth-first search algorithms or maybe even an heuristic search. When we add segments in state 3, it should be OK to keep on going through (depth-wise) to see if the path will lead to ARC. The search space really isn't that big. However, I may use a heuristic that says if we haven't reached our final destination in say 10 steps, then something is wrong with the path I'm pursuing. Again the search space isn't very big at all. However, often there are several different ways of getting to the same destination and basically everything at Rutgers is connected one way or another, and the agent may end up in a cycle. The heuristic would prevent us from getting solutions involving going around in circles.

You add a segment. Check out the first neighbor or it; see if it meets the ability criteria. If it doesn't, then backtrack and try the second neighbor, etc. For example, ?is_route(courtyard, arc). Suppose the agent derives that cs(courtyard, serc_suites1)- that is, the Suites Courtyard is connected to the Serc_Suites1 segment (satisfies the meet terms in the body, etc.). Before it adds the serc_suites1 segment to our growing partial solution list, the agent checks to see if it succeeds in deriving prop(serc_suites1, level, beginner) from the various rules in the KB (that is, it is smooth, flat, straight, etc.)

The agent will find a route, if there is one, from our start to final destination that is compatible with the user's skating ability.

Conclusions

This was an interesting project. During the course of hacking away at this project, I ran into quite a few stumbling blocks.

What do the various skating levels entail? Very basic beginner: who can just ride straight, flat surfaces and hasn't gotten the hang of stopping yet. Advanced: those who are ready to go and skate up and down Route 18 with steep inclines and all. Advanced skaters can skate on anythng you throw at them (beginner level and expert stuff). Most people fall between these 2 extremes, however. I didn't know how to incorporate this when the users input their skating level. Ideally, I'd like for them to be able to check off the features they can skate on, i.e., small inclines, traffic not OK, and the like. So I ended up using very, very general definitions of what it meant to be "beginner", etc. So RSF is not exactly tailored to one's skating needs, but it comes reasonably close.

I've learned to appreciate the complexity and choices involved in describing a domain. Despite my focus on a relatively small geographic area (Busch campus), there are lots of "segments" on Busch! There are quite a few paths and you have to worry about the directions they are headed. It's quite a feat (something we do everyday!) that we know that to get from the Suites to ARC, you have to veer to the right on the SERC sidewalks, for example. We do this everyday without even thinking about it! In addition, I had to divide up "areas". As a concrete example, it would be more accurate and thorough to include each segment that makes up the walkways in the middle of the Engineering/Hill/SERC complex individually. Or that you'd have to include the small portion of the parking lot you have to cross to get from the suites path to the suites_SERC path. This is certainly doable (busily studying the huge campus map on your bed and diligently including all the paths for your representation) but rather tedious!

In the same vein, I realized that there may be a lot of redundancy in the paths: there are multiple ways to get anywhere on Busch. I wasn't sure exactly how to implement a heuristic in my search to try to prevent an endless loop. Also there may be more than 1 "segment" in a given area, so which would the agent choose? For example, there is a "cobblestone" path between the suites and SERC. But one can also choose to go on the grass that follows alongside it and consider that as a real path, too.

Just thinking logically- for example, how a Prolog rule concisely explained what it means exactly "to be connected"- was kind of neat. Using logical languages involved a different way of thinking from what we are used to with C/C++, etc.

Working on this project the past few months has definitely increased my appreciation for such everyday AI applications as Mapquest and other online map direction agents. I've learned to appreciate some of the trickiest problems that arise in AI, especially in managing search and representing domain knowledge. (Honestly, if I had to write the Mapquest program... If you wanted to know how to get to Virginia from New Brunswick, well you just might end up in Canada...) Working on RSF and just thinking things through definitely allowed us to sink our teeth into AI and to gain a better understanding of the problems/questions/issues that arise and what we can and can't do about them. We got a taste of what AI is all about with domains that we could really have fun with at the same time!

Feedback