Journal for CS482 Final Project

Overview:

We, the mapping group, were tasked with, after being dropped off at a predetermined location in the area, creating an algorithm to map an area around a beacon and then storing that map in memory (in a form accessible to others) until it can be read. In doing this we were to record the locations of obstacles (things that humans had to avoid) and bad spots (places where humans couldn't go without great change of severe injury or death). After mapping the area, we were to return to the drop off point so that we could be "taken" back home.

Sub Problems:

The first problem we tackled was the method by which we were going to cover the area and do so efficiently. We didn't want to be doing it all day and we needed to "conserve" battery power. Since we knew that we needed to cover an area that was an arc around the beacon, our first consideration was to follow an arc around the beacon doing our best to maintain a constant distance from the light. This seemed like a plausible solution as long as we could easily get the distance from the light from a light sensor (which previously had been determined as possible). This, ultimately was the method we chose. As it turns out, the function to go in an arc at a specified distance was not too complicated and worked very well. Another option that we came up with was traversing the area in a rectangular grid. The main problem that we saw with this is trying to find out where we were in the grid and moving in a straight line (most bots drifted left or right for whatever reason). Another potential problem with this schema is that we would potentially be storing more data than we needed since we would be traveling outside of the necessary area. A third possible solution that we came up with was to divide the space up into "equal" parts and have the bots map a portion of the area, then to combine the data back at the ACL when it was printed out. This seemed like the best solution when we first started. Then we considered how we would make the bots know what sections they were going to be mapping. This became our main drive during the first part of the project. We were planning on dividing up the area into 2 halves and then having half the bots map one half while the other mapped the other. We decided to abandon this method due to the fact that the polarized light was not enough to tell when we were at the half-way mark, and therefor should turn around. Dividing up the region any further would have taken much more accuracy in the orientation mechanism. Two things that we considered while trying to come up with a method to accomplish the task of mapping the area were were bot-to-bot communication and how we were going to manage covering too-much versus covering too-little of the area. We decided to abandon bot to bot communication due to the amount of location accuracy it would take to accomplish. I don't think that the actual act of communicating between the bots would have been a big deal, but it would have required (IMHO) that we line the bots up relatively exactly so that the IR would work. Maybe there was some other way that we could have done communication, but I think that if we would have, IR would have been the way that we chose. The issue of covering too-much vs. too-little area was why we chose not to use the "grid" method of movement. We could have been covering close to double the area we really needed to cover, and therefor potentially recording too many obstacles/bad-spots. Since memory on the Handiboard was/isn't cheap, we decided to use a method that required the least amount of memory.

Data storage was the second problem that we needed to tackle since we needed to know how much memory we had to play with and how we could use what we had. I spent several weeks working on doing research into the Handiboard's memory map and how we could use the memory that was not taken up by our program and operating system. In the end, we finally found out by writing a few lines of code which just created a huge array of integers. We determined that we could create about 2900 8 bit integers in the global space and many less in the function space. This made a little sense since the board had only about 31 ~ 32 K for ram (pcode takes up about 1 or 2 K). We figured that this (minus the amount of space our code took up) was going to be plenty to store the data in. Next we tackled the format that we were going to store the data. From the onset, we envisioned using an array to store th data. From our previous research into the size and layout of the memory, we decided that placing the array in the global memory was probably our best bet. We decided to store just the positions of the bad-spots and obstacles. In order to distinguish between obstacles and bad-spots our first choice was to use a 2 dimensional array which contained 3 sub-arrays: one for the angle, one for distance, and then one to signify obstacle or bad-spot (true/false). We abandoned this idea when we discovered the fact that IC doesn't support 2 dimensional arrays. Instead, we decided to use 2 separate arrays: one for the angle to the light, and one for the distance to the light. The way that we differentiated between a bad-spot and an obstacle was to reverse the sign of the distance to signify a bad-spot. This seemed like the best solution since storing the data in a global meant that we didn't have to pass pointers around (and didn't have to debug them). We chose to use a direct connection to the "home" ACL box as our method of getting the data back home. We chose this over the other method we thought of: passing all of the data back to one bot and then that bot goes "home." This way we didn't need to tackle the task of communicating large amounts of data back to the other bot(s). Plus, it added a sense of redundancy between all the bots since then we didn't have to guarantee that the one "com-bot" would make it back to the home safely.

The next task that I had a part in tackling was how to detect bad-spots. The main challenge here was the fact that the only way to tell if a tile was a bad-spot was to "look" at the floor. The method we agreed upon ended up consisting of a light aimed down at the floor with a CDS light sensor pointing down as well. The main difficulty was calibrating the bot so that it only detected a bad-spot when there actually was one under it. This resulted in confronting the problem that ambient light could really goof up the sensor and it would report back a false value when there was a large amount of light (like close to the beacon). Beyond solving the ambient light problem, this task was fairly simple. For most of the sensors that we used, there was a definite change/threshold that we could use to determine if the floor tile was marked or not.

Another thing was how we would avoid obstacles. This problem wasn't present for bad-spots since bad-spots were only places where Humans couldn't go, but it was possible for the bot to go into that spot. When we detected an obstacle, we needed a way to avoid it so that we could continue on its arc. There were two approaches that we came up with. The first involved just turning 90 degrees and moving a tile's length in that direction, then starting back up the arc code. This required that the arc code would have the ability to correct back to the arc without too much trouble. This made things a little more complex than we really wanted. We fell back to a solution that basically made a trip around the obstacle and then continued on the arc. For the most-part this worked just the way that we expected it to. There were a few instances where the movement was not quite enough to avoid the obstacle, but that could have been (or was) solved by increasing the forward time that the bot moved. Another issue we "ran into" was the problem of running into the wall while we were avoiding an obstacle. This was/would be a problem when the obstacle was near the wall and going around it would result in hitting the wall. This really didn't get solved successfully. Probably this would take starting up the find-obstacle code again while avoiding so that when the IR found an obstacle it would do the proper thing. More than likely this would take much more accuracy in the positioning code.

One big thing that took way longer than we thought it would was the calibration of the bot's sensors (particularly the light sensors). The main problem with the light sensors was the fact that they were not all the same. I don't know if this was/is a problem with the way that the sensors were put together, or what, but it had a big factor on how things worked. Towards the end of the project we determined that we could have added resistors to the sensors to attempt to bring up their readings to more "normal levels, but we ran out of time to do this. Maybe in the future we can "calibrate" all of the sensors this way and therefor have a whole gambit of sensors that read relatively the same thing (instead of just a few that have similar readings). The things we spent time calibrating were the light sensors that we were using on the bot (totaling 5 per bot) and the IR. Most of my interactions were with the CDS cells. The fortunate thing that we found was that even if sensor were extremely variant in what their readings were, we were able to fit the readings to a curve and get a more or less accurate adjusted value that we could use to obtain the distance from the light source. Unfortunately, this required that we have a set of (3) functions for each bot that would give back the appropriate distance. We decided that the best place to put these calibrations was in unique global files for each bot. We decided to do this over a look-up table (2d array) because of the difficulty to do 2 d arrays and the complexity of setting persistent variables on the Handiboard.

One of the easiest things that I was involved in during this project was designing and constructing the bot(s). The bot design was fairly simple and didn't involve many complex moving parts (like a bumper). After talking to the other group(s) that needed to be in the environment, we determined that we could get away with not having any touch sensors (something that I think we may have wanted in the end). Next, we determined that we were going to need 5 light sensors to see where the light was (and wasn't): one on each side, one facing front, one facing up with a polarized filter on it, and one facing down. Our first design included the use of wheels in the front, but soon changed to a marble which the bot could slide on. One concern that we had to tackle once we found the importance of blocking out abmient light was how we were going to do it. In the end, we created a small cage which contained the light sensor and LED for bad-spot detection and covered that cage with construction paper. This worked sufficiently well enough to prevent the nasty ambient light from getting in and affecting our light sensor readings. Another huge concern of ours was to keep is simple enough that we would have the necessary parts to build several bots and have them all look/behave/weight the same or close to the same.

Something that we should have considered more throughout the project was how we could get the bots to work together more and better. As it was we spent minimal time on it and as a result had a solution in which the bots worked relatively independently. In the beginning, we considered having each bot display a "ID light" which would let one bot tell if it was in front of an obstacle or another bot. We abandoned this idea because of the potential battery usage that it would require. Other than that, I don't remember coming up with any other ideas as to how to use the bots as a team except for in the fact that they were all mapping the same area and their data would be compiled and compared to make one collective map that would hopefully be more accurate than the map generated by just one bot.

Performance:

We had some really weird errors the day of the presentation. For some reason, our bot thought that the brightest area was in the direction directly opposite of what it really was... For some reason, when it was trying to find where it was, it would turn directly 180 degrees from where the light was. Beyond that, our code seemed to work just fine. We still had some major problems with the detection of walls, but I think that could have been solved with some more calibration. During our tests in our test-arrena, our code worked just the way we wanted it to. This frustrated us even more since the night (or even just hours) before the presentation our code was working and all of a sudden things stopped working.

Suggestions for improvements:

I don't think it was the case, but we probably could have come up with something that was less lab dependent. We definitely needed more testing... the night before is not the time to debug, calibrate, and test code/sensors.