Jim Rice
Robotics Journal Web Page
3/25: Our group discussed for several hours tonight. The issues we brought up included the mapping algorithm, the parts we would need for that algorithm, and the problems we would run across.
We came up with several possible solutions to the mapping problem. Both solutions assume that the bots start facing the light source, half on one side of the N-S line and half on the other. The area would be divided into halves; east and west. Each bot would then cover the entire half it is on. The first solution involved the bots travelling around the perimeter of the half, then spinning closer to the center in each successive pass, in a spiral. The second solution was to have the bots move up and down the area, covering approximately one row of tiles at a time. We didn't decide which to use.
One of the problems we believe we have solved is the problem of distinguishing bots and obstacles from the other. Our idea is to mount a colored light on each bot, and a light sensor with a color filter in a position to see the light on each other bot. If any bot detects an object and the light in the same position, the bot should know it's another bot, and not an obstacle.
Another problem is recognizing different color floor tiles. The solution we came up with for that was to shine a light onto the floor beneath the bot, and to use a colored light filter there as well to detect drastic changes in the light reflected from the floor. We are working on the assumption that the construction paper representing "bad places" will reflect light differently than the floor tiles will. Question: is it possible to detect changes in light without shining the light down? In other words, is the CDS cell, sans filter, sensitive enough to detect the change in light reflection underneath the bot without shining the light? We should experiment with that.
3/26: After another two hour discussion we've gotten some significant headway. We've resolved to combine our the mapping methods so that we go back and forth along the curve of the semicircle, kind of like the way a piece of paper falls.
We also realized that we don't need bot detection because, assuming a bot is moving, the chances that more than one bot sees a third in the exact same place twice is slim to none. So when we piece together the maps from each of the bots, when an obstacle shows up on one map that doesn't show up on any of the others, we can assume that "obstacle" was actually a bot, and that spot on the map can remain clear.
The main problem we worked on was determining a format to store the map data. After discussing several techniques, we determined that the best was probably going to be using three separate arrays, one of which stores the degree (we are using polar coordinates) and another storing the distance from the light source. The third is an array of bytes that will denote whether the corresponding point is a bad spot or an obstacle. When the maps are assembled, the program can assume that any point not marked is a safe point.
Lew had suggested that we reconsider our idea of splitting the bots into two groups of four, and to instead think about having half the bots cover all the ground and then meet the other half of the bots, who would carry the data back to home base. We gave this suggestion some consideration, but we think our idea will work better on several counts. The first is that we are concerned about the amount of space needed to map the entire area, as opposed to the memory needed to store half of it. Another reason is that it seems useless to have four bots waiting around for the others to finish mapping, just to carry the data back, when all of the bots have to go back anyway. Wouldn't it be simpler to have all the bots map the area then all of them carry their data back? That way we wouldn't have to worry about losing data during bot-bot communication. Furthermore, the more bots we have mapping, the more accurate our maps are going to be.
We finished the evening by attempting to determine how much memory was available to us, but we couldn't quite work out the code for it because of the limitations of the handiboard. We'll keep working on it and probably ask Charlie for help.
3/31: Today Trevor and I spent about an hour hammering out some pseudo code for the mapping algorithm. Hopefully we won't need to make any major changes to what we've got. Here's the link:
4/7: Finished writing code for map.c. Haven't tested it yet, but I think it's pretty good. Had to adjust some tactics; threw in some threads because I think the code will be more efficient if we're using them. Also wrote some outlines of code for detecting obstacles and bad spots; Josh T has some better code for detecting bad spots so we'll use his. He's also going to flesh out the rest of the code for find_obstacles. Link to map.c is available here and at the bottom of the page. Mental note: figure out how to stop a thread; that's going to get important. Take a look at map.c and tell me what you think.
4/14: Just finished creating sample data for communications group. Working with Trevor on finishing all the basic functions for map.c so that we can start to test it and all. Things are moving a little slower than I had wanted. The pseudo code has also been updated; the link remains the same.
4/18: We've had to undergo a pretty major revision of the mapping plan. When the bot moves through the area, we are figuring out where we need to turn around based off of knowing where the N-S line is. That knowledge requires resolving the angle on the fly. We have discovered that will be very difficult to do. So, we've decided to modify the overall plan so that the each bot will map the entire hemisphere, instead of only one quadrant. This means that we are turning around when we've hit a wall, and gets rid of the need to determine the angle on the fly. We are now only computing the angle whenever we find an obstacle or a bad spot.
Another thought: we are going to need to remember to figure out how to account for the displacement between the bot and the obstacle at the point we figure out the position of the bot when we've found an obstacle. The problem is that we can't be "on top of" the obstacle when we record it's position, due to IR short-range limitations, so we will be recording the position of the bot, not the position of the obstacle. We need to compute a formula for figuring out the actual position of the obstacle.
A third thought: Every bot will have differences in terms of hardware. We need some way to account for these differences. Josh T and I have been thinking about this, and we haven't really come with any elegant solutions. My best idea is to have a separate file for each bot (requiring naming each bot and coordinating the name of the bot with its file) and loading that file along with all the other files. The file will contain values that are needed to modify values dependant on hardware. In this way, each bot will have the same code but we can still "personalize" each bot to account for the individual differences.
4/23: Trevor and I spent the weekend trying to make sure the code would run on Tuesday. We've uncovered several problems in our algorithms, which we corrected on the fly (probably a bad idea) and then debugged just enough to make sure it runs. Right now it looks like our only problem in terms of written code is in calling a thread at an inopportune moment, so I'm going to have to look into that.
Josh is still working on get_position, so I've going to busy myself finishing the debugging. I've asked Ned to write a little function to get the bot back to the drop point, and we discussed some strategies with Josh T for that over lunch. I'm going to ask Trev to test the code that makes the bot travel in a fixed radius around the beacon, and Aaron is going to help him I think. Hanna is still working on the minimize function.