| | 53 | |
| | 54 | == 6/21/07 - Day 14 == |
| | 55 | |
| | 56 | Today has been one of our less fruitful days. Much time was spent working on algorithms for our challenge. I believe I've perfected the Nelder Mead algorithm, except for the condition at which the robot decides it's time to stop searching. Under ideal conditions, the algorithm would cause the robot to move in constantly shrinking triangles around the center of the access point, but realistically at some point the robot has to stop and decide it is close enough. As of now, that condition is if the difference in signal strength between the Best and the Worst points is less than 1.0 Dbm. Whether or not this is a good metric is something we might not know until we can make a trial run. |
| | 57 | |
| | 58 | A second algorithm I'm working on computes the approximate gradient of the signal strength and moves in the opposite direction. The complete method has not been decided yet, but essentially the robot will move first in a triangle, taking measurements at each vertex. It will then interpolate the vertexes and signal strengths to find the equation of a plane, from which the gradient can be computed. It will then move to a position in the direction opposite the gradient from the centroid of the triangle which it interpolated. A new triangle will form using the new point and the two (geometrically) nearest previously surveyed points, and the process will repeat. As of yet I don't know how well this will work, but I intend to try it out. |
| | 59 | |
| | 60 | An important objective is to get object avoidance working. One idea I thought of follows: If we could somehow create a behavior network that uses the IR sensors to avoid obstacles, we could call that behavior from within python using ''os.system(behave obstacle_avoidance.xml &)''. Another hopeful tactic might be to find a way to call a python script (or a general system call) from a behavior network. The fear is that if we run either a behavior network or a python script, one will lock the other out of the RCM service. |
| | 61 | |
| | 62 | Once obstacle avoidance is working, an added challenge will be getting the robot to correct it's (x,y) position when it cannot reach the locations requested by our algorithms. For example, if an algorithm tells the robot to move to the point (50,50), and that point is inside a pillar, the robot will move towards the pillar and hover around it until it's ''!MoveTo'' call times out (we can set the timeout interval). At that point, hopefully the robot will be able to tell us what it's position is, because the algorithm will not know. |
| | 63 | |
| | 64 | The C++ code continues to be a headache. We are now officially convinced that many of the upper level API functions really demand that we code in C++, which is disheartening as we've made very little progress getting the code to compile. I dispatched a support request to Evolution, but have not heard from them as of yet. We really ought to get a user id and password for their support forums. |
