The simulator uses a sonar model somewhat more simplified than the model we discussed in class. It looks at all obstacles that lie in the sonar cone and checks whether that obstacle can directly reflect the sonar pulse back to the sensor. Of the obstacles that can, the distance to the one at the shortest range (to the reflecting point on that obstacle) is returned.
This is almost the simple model that we discussed in class; the difference is that it does not do multiple reflections.
The code has been compiled and run successfully under the CS department SunOS and Mandrake Linux 9.1 with gcc 3.2.2. (I just upgraded!)
> the example world that was anded out has the coordinates -2.5 -2 1.5 > 1, but the sonar data has reading positions (Rx, Ry, Rth) well outside > this bbox. should we just modify the Problem1 file to be roughly > 0,0,10,10, or is this part of the challenge?
To keep things simple, let's say that you can assume that the robot stays within the world bounds. However, you should not assume that the entire sonar cone will lie within the world bounds.
>How is the sonar simulator supposed to be used? I've compiled it and >ran it, but I'm somewhat confused. Does it output the sonar data to a >file? or do we have to take the output of the program and place it in >a file? Ah yes, it does not output the data into a file. You have to redirect the output to a file. (Just hold down 'n' until the screen stops changing.) You'll then need to go back and take out the things in the file that aren't sonar data and the prepend the appropriate header so it's in the correct format for the sonar file. Maybe I'll have a deluxe version of the simulator someday...
>Have there been any code updates since the (first?) windowsized >version of the code came out? This is the version of the code that i >have. There was an update over the weekend (4/6) in which I added || c == '\r' to the mapproblem.cpp file.
>Isn't the robot supposed to move around? When I run the code, the >robot stays in one place and takes sensor readings but doesn't move. >Are we supposed to instruct the robot to move through the enviroment as >part of the assignment? or is this supposed to be taken care of with the >support code? I suppose this was an oversight of mine in the support code. You should either make it move around or draw a dot at the robot location. You can set the state using a method from the robot class; there is a pointer to the robot class instance in the mapProblem class.
> for the certainty grid: under normalization, theres no way of me > setting Occ_k to a value so that the sum of all Occ_k's are 1. This > is because Occ_k can only hold unsigned chars, which cannot be > decimals. Ive implement the assignment using 128 as the middle > value, in which case I should have it so the sum of all Occ_k's are > 128 (instead of 1). However this also cannot be done. In my own > specific example, I found the sum of Occ_k to be 22906, so any value > in between 0 and 127 would get stored in Occ_k as a 0. I do no know > what to do about this.
If you can't implement in with 8 bit integers, then use larger integers or floating point numbers.
Of course, the underlying data representation in drawableImage is an unsigned char, and this cannot be changed. Therefore, if you need to use some other data representation, you will have to maintain it in parallel with the {Empty,Full}{Map,Reading} drawableImages. Rather than modify the drawableImage class, I suggest creating either a separate data structure or a derived class.
In the handout description of incorporating SONAR readings into the current map it lists as step 1 to Reset the map to not knowing whether the cell is empty or occupied. Should this be done once in the beginning? Or before every sonar scan? Right now I reset it once in the beginning, and by the end, my Empty certainty is very high for nearly every cell by the end of several sonar scans. However, if I were to zero the empty certainty everytime I do a sonar scan, I dont' think the past data would be incorporated into combined map - it seems that each time I create a combined map it overwrites the previous information.
The empty and full maps are reset only at the beginning --- if you reset them before every reading, you would never actually build up a map of the area.
Most likely, your problem is in the "merging" process (i.e. step 2). If you have rounding/truncation errors (see the Q&A above), this could be causing the problem too.