This blog post is a brief reminder of our project and a summary of all the work that has been completed this summer. If you would like to read the latest progress since the last post, please skip to the section marked with “Recent Progress”.
Last school year Dr. Goadrich, Dr. Jadud, Molly Mattis, and I were able to build and program a robot to enter into the Trinity College Fire Fighting Home Robot Contest. We used an occam-pi library called Plumbing to program the robot. Using a parallel programming language allows for processes to run concurrently and makes changing how the robot acts a much easier task. Our robot was able to place 15th out of 41 contestants. You can see the video here.
While we were pleased with the results of our first run, our plans for the summer are to hopefully create a better candle search algorithm by introducing AI to evolve the robot brain controller. To do this we need to use a simulator which can run a virtual replication of our robot. We will program the simulator to produce robots for our genetic algorithm to evaluate. After evaluation, we will use crossover and mutation AI techniques to generate new robots which will hopefully be better than the last generation of robots.
At first we tried using USARSim as our simulator, but found it to be a bit overly complicated for our needs. For now, we’ve decided to use the Simbad 3D Robot Simulator. As our project gets closer to completion we may switch back to the USARSim simulator. My project partner Eren Corapcioglu has been working with the simulator to produce all the room configuration options the contest has. The Simbad simulator uses Java as its language and Java3D to render the virtual world.
Because our simulator uses Java and our robot uses a parallel language, we needed to find a way to translate Java into a parallel language. For this, we use JCSP. In the beginning I tried translating the occam-pi code into Java line for line. I was able to reproduce our physical robot which simply followed the right wall of the arena. We discovered that in order for our genetic programming to work, we would need to break up the processes into smaller parts. Each day we find different ways to produce the same processes but are easier to evolve.
Over the past few weeks we tried several different techniques in creating a program which will create random robots for our genetic algorithm to evaluate. As Eren mentioned in her last post, one attempt simply created processes and picked information channels randomly. This created rather unintelligent robots who listened to instructions from dead air.
—-Recent Progress —-
Instead, I expanded the brain processes into three main parts: Motor Control, Motor Final, and Alt Control. Alt Control generates a random number of Above and Below sensor threshold values and listens for a sensor to tell it if some threshold for either distance to an obstacle or light level has been reached.
Alt Control then tells a Motor Control “Hey, Motors, do something!” Each Motor Control has an object with values for which direction and speed each wheel should turn and how long the wheels should respond. The Motor Controls then feed into a Motor Final which is a simple alternative process. Motor Final simply keeps the robot from locking up if more than one Motor Control is trying to tell the motors to do different commands. The alternative switch selects which process gets to take place first.
The picture is the graphical representation of this brain configuration using Graphviz. The numbers for each process represent:
Above/Below Thresh: the sensor threshold level to send a signal.
Motor: The left and right wheel motor values. Negative is backwards, positive forwards. And the time period for this movement.
Node Edges: The channel number information and signals are flowing on.
Score: A score generated using an equation based on the time the robot has been in the world (the simulation ends if the robot runs into a wall) and the odometer number.