Planet Rockalypse

As of Wednesday(07/06/2011) we had our simulator working to where we spit out a score for the robot on how well “it did”. The score keeps track of the Lifetime of the robot (how long it was moving around in the world), along with the Odometer (the distance travelled). With this score, we are able to tell if the robot crashed into a wall, spotted the light, or if it ran out of time. If the robot either ran out of time (it’s allotted five minutes were up) or crashed into a wall, the score would not take into account the distance travelled and therefore have a lower score. If it acknowledged that the light was there, the score then takes into account the distance travelled and the Lifetime of the robot.

Our goal was to find equations that allowed us to minimize both the Lifetime of the robot and the Odometer of the robot. We did this by using to simple equations which then gave us the value for both the distance and time of the robot.

During these trials, we ran into two problems: the first, if the robot was located in the negative x-axis of the world, and “collided” into a wall, instead of colliding all the way through, the robot would bounce of, and then move towards the way again. It kept repeating this pattern until we stopped the program on our own. After an hour of debugging, we found that this was due to our code since we had turned on the setUsePhysics(true) method (part of the environment description class). This use of physics was telling the robot to bounce of the wall.

Our second problem was the light was not set to a bright enough light, which led to the robot not being able to sense it was there. We also saw that in different rooms, the attenuation of the light was different depending on the size of the room and the location of the wall from the light. We looked into the PointLight class to try to understand why this was happening. It reassured us that the brightness of the light depended on where the walls were located with respect to the light. The PointLight class has a method called setAttenuation(), which brings in three constants: the light’s constant attenuation, the light’s linear attenuation, and the light’s quadratic attenuation. We further looked into these constants and found a relative equation which calculates the lights attenuation. This has helped us to better the brightness of our light in all four rooms.

Before we can start evolving new ‘brains’ for our robot, we need to translate our occam/Plumbing code into Java using JCSP. By using JCSP we are able to create a replica of our robot in the Simbad simulator. The first step we needed to take was to make an outline the occam-pi code to make translation easier.

I created this image using iMindMap. The map shows the channel and signal connections between the different processes. Our Java code will not be completely the same – our motor control will be different in the virtual world, for example.

So far, I have been able to translate the flame.detected, above and below threshold, and much of the brain components. Dr. Goadrich helped with this process by creating a version of the adc.get.reading process so that both the light sensors and range sensors can read from above and below threshold. Our robot now avoids walls (sort of) while looking for the candle in parallel. Now I need to translate the process which makes the robot follow the right wall.

As am I getting back into the swing of writing code in java once again, I am expanding my coding skills by adding bounding boxes around all of the possible lights in each room.

At first, we wanted to create bounding polytopes again. The problem we found with using the BoundingPolytope function in java is that all the regions of the polytope have to be convex. This would have worked for some of the rooms, but then some of the regions would have not been convex if we included all possible areas outside of the room where our robot could potentially notice light coming from.

Once understanding a BoundingPolytope would not work, we then decided to just create a bounding box around the rooms themselves. This was decided because Kathryn pointed out with all the overhead lights in the arena, it would be almost impossible for the sensors we are using on the robot to detect light anywhere outside of the room.

With that said, I hard coded a file with all the possible light locations: two in each room; which did include all possibilities for the lights when one of the four rooms was flipped. These next two links will give you a visual on the flipped rooms:

After hardcoding the lights, I was able to create a general code which opened the file and read the lines. The code broke up the numbers in the line in order to read the vector which contained the light location. Also, it retrieved the location of the smaller and larger bounding boxes which are needed for the code. Taking these three pieces, the bounding boxes were created.

My name is Eren Corapcioglu. I am a senior at Centenary College with a Math major and Computer Science minor. I recently declared my Computer Science minor after I took the introductory course in the fall of 2010. As soon as I got the flow of programming in Python, I started to become even more interested in how to program code and just in the computer science world overall. As I started to explore more into the computer science world by learning new languages, such as Java, I began to learn more of what writing code can accomplish. In my data structures class, I learned how to write code using Java for Android Application. This class has become one of the most interesting courses I have taken throughout my college career. I really enjoyed writing code to produce an application; I enjoyed seeing my code made into an enjoyable game or program that anyone could use. The Data Structures class encouraged me to want to explore even more into computer science by learning new languages and seeing what else writing code could produce. This is why I wanted to take on this summer research project of building and learning about robots. I have and will continue to learn some new coding languages, along with expanding my Java programming skills. I will also be learning and creating code which will be shown through the making of a simulated robot. This research program will thoroughly expand my knowledge about programming along with giving me another example of how interesting coding and computer science truly is.

Kathryn’s last post is spot on; we’re diving into an exploration of AI this summer, specifically with respect to robotic control. Specifically, we’re interested in using genetic algorithms to evolve a process network to control our robotic firefighter.

Taking that one piece at a time:

Genetic algorithms help us search for optimal solutions. We call them “genetic” algorithms because they are implemented to mimic how evolution happens in the real world. We encode a possible solution as a “gene,” and then “mate” those genes with other possible solutions. Sometimes, we mutate a few things along the way. In this manner, we “mate” many parents together, evaluate their children, and keep the ones that seem to be the most “fit.”

Team Centegheny’s Fire-Fighting Robot

Our fire fighting robot was programmed in occam, which is a dataflow or process-oriented programming language. An occam program is made up of many independent pieces (called processes) that communicate with each-other using wires (called channels). Because each process is independent, and because its channel configuration is completely specified and fixed, we can automatically compose one process with another if their channels match up. This is much like saying “we can put LEGO blocks together because the nubs on the top of one block match the spaces underneath another.” A collection of occam processes, wired to each-other, is typically referred to as a process network.

An occam process network.

Researchers have used genetic algorithms for many purposes; we are not the first to evolving robot control code, or the first to evolve a graph-like structure. We are excited about the project because we have the ability to control the level of complexity of the evolution by controlling the expressive power of the occam processes. For example: if we only had one process type (a neuron), we would be evolving a neural-network controller for our robot. Evolving a controller using single neurons might take millennia. However, if we only had one process type (a single process that represents a complete solution to the problem), then the evolution is trivial: there is only one solution, and therefore our GA will converge on the solution instantaneously.

We are going to begin by providing the GA with the same set of processes (genes) that we used to implement an autonomous fire-fighting robot. Our hope is that the GA will be able to (easily) evolving a process network that is equivalent to our own: there are only a handful of possible ways to plug together the “top level” processes that we developed. If the GA cannot evolve the same solution we came up with using the same handful of pieces, we will know early on that something is wrong.

Once we have moved past this first phase (which will be very instructive to us all), we are going to try feeding the GA a larger set of less complex processes. The question will be whether or not a better solution to fighting fires in the Trinity robotic fire fighting context can be developed than the one we came up with. Our robot managed to place 15th out of 40+ contestants; there is plenty of room to do better. But, the complexity of the evolution grows drastically, and evaluating what makes a solution “good” involves running a simulation; it may be that there isn’t enough time left in the universe, let alone the summer, for us to evaluate this phase of our research…

But, we’ll see! The project has us exploring the evolution of graph structures with genetic algorithms, which is neither trivial nor useless—and we are applying it to a paradigm that we have good experience with at this point. It should be exciting!

The vacation part of summer is over and now let’s program some more robots! Our first robot did great at the competition in April, but now that we’ve gotten our feet wet, it’s time to dive into the more complicated aspects of robotics programming.

One of the main challenges we had was trying to figure out how to search the island room for the candle. We tried many different algorithms to search for the candle, but could never quite get into that room. What if, instead of us trying to determine the best search algorithm, we let the robot find the solution? By using AI, we hope to program a robot which can find the best candle search solution and get us into the island room.

To do this, we are first going to build a virtual replicate of the arena and robot in a robotics simulator. As of right now, we are using The Simbad 3D Robot Simulator. Because Simbad was created for machine learning research and is simply designed, we believe we can get to the AI programming aspect of the project quickly. However, because it is very simple and the physics are not very life like, we may find we need another simulator sometime in the future when our program gets more complicated. The picture shows the world I created with a replicate of the arena, a sample robot, and a light representing the candle.

I have been pretty busy since my last blog post. For one, we now are working with the new 6-volt motors, these can work much better with our motor shield and will last longer with higher voltages applied to them. The same day we applied the new motors, Dr. Goadrich and I built the stand-offs to create the upper deck of the robot out of Lego blocks. The Legos allow us to easily remove the top portion of the robot for access to the Arduino and motor shield placed on the bottom deck.

The last video I posted had the robot (named Centegheny for the competition) running a basic program which did not use sensors. Thus, the first step I took was to add three IR sensors to the top deck: one of the right, middle, and left. I then wrote a program in C which used the sensors to avoid walls. If the left sensor was tripped, the robot turned to the right, and vice versa for the right sensor. If the middle sensor sensed something, it asked the left and right sensors which was farthest away from something, and turned in that direction. The video for this is shown below. (Please excuse my make-shift arena…)

Because we wish to use the parallel language Occam-pi with Plumbing, I began to translate this wall avoidance code into that language. Once the motor shield was able to work with the Plumbing libraries, it was fairly simple to translate the code, once I understood a few things I had to take into consideration that I didn’t with other languages. For instance, I learned that the If statement required a final condition just in case all other conditions were false. Otherwise, if all the condition are false, the code crashes, causing the program to restart completely.

Another odd thing that was discovered was the Plumbing code did not work with a low battery. The Arduino we are using has a recommended input voltage of 7-12 volts, thus I had plugged a 9-volt battery into it. After a few runs of the Plumbing code, the robot appeared to simply stop working despite nothing seeming to cause it. Baffled, we decided to run the old C code, code we knew without a doubt worked, and it did. After acquiring a multimeter, we set about trying to figure out what the problem could be. Eventually we tested the 9-volt battery to the Arduino. It was at about 5 volts and thus lower than the recommended voltage. However, the C code seemed to run fine on a lower voltage! I am still a bit puzzled on how this is possible.

Presently I am working on integrating the newly received IR sensors from Molly. I sent her longer range sensors and she sent me shorter range sensors. I will also be working on the code for the state diagram Molly posted. I also want to integrate the flame sensors into the robot at the same time. After that, we will simply need to attach our fan to the top.

Here is the state diagram that will help us to write the code for our robot. This is all the robot could possibly have to do to find the flame. The numbers 1, 2, 3, and 4 refer to the possible positions of the doors in the environment. Here is a diagram that shows this:

The first thing I did this week was play with the flame sensors in order to see what the values would be like. Sitting in a classroom with florescent lights had my sensor jumping to random numbers and I didn’t even have a flame anywhere. I will need to ask my teammates at our next meeting what values they were getting to see if they matched or if I did something completely wrong.

After that I decided to set my robot free from needing USB power as seen in my last video. Unfortunately, we hit a bit of a snag in that our 3 volt motors are not robust enough to handle our motor shield and other various things. Thus, we will need 6 volt ones, this isn’t a big problem, it just means our 3 volt motors will die sometime during testing, but can be easily replaced once the 6 volts get here.

However, I went ahead and started testing the Arduino and motor shield using the 3 volt motors. We have no gotten to the point of finalizing how we will secure all the pieces to the robot, so mine is held together in an unprofessional, MacGyver-like set-up of tape, wood, glittery string, and sticky tack. This will of course be changed once my teammates and I come together to determine how we will secure everything.

In the video below you can see my odd little robot running a basic program that has the robot go forwards, backwards, and stop.