CS 495 Special Topics in CS: Evolutionary Robotics Fall 2004, Instructor: Jeffrey Horn
What's REALLY New:
Not so New (Older Announcements):
- Final Exam: Snowed out!!! Officially moved to Friday, Dec. 17, 4pm. But I have already heard from many people who already have travel plans for Friday, or earlier. So here is what we'll do:
- You have the final details on your final project below. I have refined and commented the code, and re-scoped the project a bit, so that it is now much more focused and, I think, shorter.
- The project will due by Monday, Dec. 20, at the latest! I suspect most people will be able to finish it well before then.
- Another requirement is your attendance at, and participation in, the interactive VIDEO CONFERENCE with Gary Parker's students (robotics course, and maybe his Computational Intelligence course) from Connecticut College. We have been trying to make this happen, and it looks like it will this THURSDAY, Dec. 16, at 2pm (location to be announced...). If you absolutely cannot make it at that time, I understand, but then I would like to meet with you about your final project at another time, preferably our "new" final exam time slot (4pm Friday Dec. 17).
- I also have a short exam for you, but that will be take-home, and possibly on-line. It will just be a few questions about the simulation we have developed this semester. By doing the final project, you will be well-prepared to answer these!
- I will be checking over everyone's work so far, and letting you know what, if anything, I am missing from you.
- That is all! I am very happy with the simulation as it turned out, and consider it a big group project with credit to everyone. You will see just how far we have gone when you do the project, so ty it!
- The Project is here! See below.
- Homework 4 assigned, see below.
- Homework 3 is finally, actually, fully here! See below! Get going on this, we are now ready to race ahead. This will be cool, I promise.
- Homework 2 is assigned! See below.
- Found out that Nat Lyle's simulator will work well with Mozilla. Try it! (Apparently, Microsoft IE has a problem with Java code. Why am I not surprised!)
- OOOPS! The deadline for Argonne abstracts is actually Sept. 23. That is this Thursday. If you have an idea, see a faculty advisor about it, before Thursday!
- Homework 1 is re-assigned! Note the extra question. Now due next Tuesday, Sept. 14...
- The deadline for Argonne abstracts is Sept. 13! That is Monday. If you have an idea, see a faculty advisor about it, before Monday.
- Homework 1 is assigned. A quick one. No programming, yet! See below.
- Also, a reading assignment. (Read preface and Ch. 1 by next Tuesday, Sept. 7)
- Nothing is new. Everything is new. Welcome to the course!
CONTENTS
Week of Aug. 30 (first week)
Handouts
for a boolean LUT with N input bits and M output bits.
Homework 4, RESEARCHING THE STATE-OF-THE-ART
- Homework 3, VEHICLE SIMULATOR
- Handed Out: Friday, October 8, 2004
- Due: Tuesday, October 19, 2004 IN CLASS
- Here are the files you need:
- Most important, the script file "braitenberg.wdl"
- Also important, the model file for a primitive looking sensor: "sensor0.mdl"
- Not so important: some model files you can use for the vehicle (you can substitute almost an .mdl file):
- GOAL:
- Tasks:
- Start with the files above. You can use the "techdemo" world, or any other world (level) you'd like (e.g., "terrain")
- Add at least one more sensor to the "braitenberg_v1" action. See detailed instructions below. Basically, you are just modifying the "braitenberg_v1" action. There should be no need to change any of the "sensor0" action code, unless you want to. I tried to write the sensor action so that it could be reused for multiple sensors.
- Make the two (or more) sensors point in different directions. I suggest you keep them both centered on the vehicle (by keeping their x,y,z coordinate updated to the vehicle's x,y,z position; see code). When I tried to offset the sensors from the center of the vehicle, they did not stay put as the vehicle rotated, instead moving all over the top of the vehicle. Feel free to work on this if you'd like! I'm sure I was just not thinking straight when I worked out the geometry...
- Use the multiple sensor data to implement the "entity orbiting" behavior. You will be modifying the "if" statements to get this behavior. The rules of the behavior are simple. Here is an example Look-up Table (LUT) assuming two binary sensors, left and right, which tries to keep an entity on the right (thus orbiting the entity in a clockwise direction):
"ORBIT ENTITY (clockwise)" left sensor right sensor action no entity no entity turn right no entity entity go forward entity no entity turn left entity entity turn left But the real experimenting will come when you try this out. To test it, first run the world with one vehicle. Make sure the "enable_scan" flag is turned OFF for the vehicle's action (i.e., the "enable_scan = ON" line of code in the "braitenberg_v1" action is commented out). Then the only entity the vehicle will see will be the player (you). So see if it orbits you. My guess is that it will spiral into you. My experience (limited!) is that you will need to experiment with exactly HOW you implement the turning and forward actions below, in order to get stable orbiting. How far (how many quants) should you move forward at one time? How far should you turn left or right (in degrees) each time? Maybe you should try going forward while panning (turning)... Remember that each "wait(1)" command causes the engine to go off and update other entities, returning after on frame cycle. There are about 50-70 frame cycles per second, depending on the speed of your graphics processor, the complexity of the world, etc.
- Turn in you script file ( *.wdl) via WebCT or email.
- Detailed instructions:
- Get the files above. Put them in your "work" folder (probably yours is in "C:/Program Files/GStudio6/work")
- Then open up "techdemo.wmp." with the world editor (WED).
- Go to the "File" menu and choose "add script". Browse to your work folder and choose "braitenberg.wdl"
- Now create one or more entities in WED. Go to the "Object" menu and choose "Add Model" and pick whatever you like.
- Now select that model (make sure you are using the "picking" tool in the WED). It will turn red when it is the selected object. Then change to the "movement" tool in the WED (see upper bar) and move your object down to the ground in either the side view or front view windows.
- Now select your object again (I mean make sure it is selected, that is, red) and right click on it. When the menu pops up, choose "properties". When the properties window pops up, choose the "Behavior" tab. Then click on the folder icon, and you should see a list of available actions pop up. Choose "braitenberg_v1" from that list. If it is not there, go back to step 3, or get help (from me or another member of the class).
- In the WED, click on the "Build" icon (the goofy icon just to the left of the exclamation mark on the top of the window). In the "Map Compiler" window that pops up, choose "Update Entities" and "OK". This should be a fast compile, as it is just doing entities.
- In the WED, click on the "Run" icon (the exclamation mark). Test your behavior!
- To change the behavior, in order to accomplish the tasks of the assignment, edit the file "braitenberg.wdl". ( I suggest you use "textPad, or WordPad, or even NotePad, but not the built-in C-Script editor, as that seems to be very buggy...) When you are ready to test it, just save the changes and re-run the level (exclamation mark). No need to recompile the level, if you have only changed a script and not an entity. (But if you do change which action is assigned to which entity, then you'll need to recompile...)
- Good luck! This is the first time we are actually using a 3D game engine to do any kind of robot simulation, here at NMU. And I don't know of anyone else doing this kind of thing (although I have heard lots of TALK about using 3D game engines for robot simulators...). This assignment will prepare us for evolution. That is next!
- Handed Out: Tuesday, November 16, 2004
- Due: Before you leave for Thanksgiving break
- GOAL:
- To learn how to access and understand current research results in the field of ER.
- Specifically, learn how to obtain the full text of peer-reviewed, archival articles (as opposed to the usual googling for free, unfiltered postings)
- TASK:
- Go get a copy, electronic or paper, of a RECENT (year 2000 or later) full text article from a peer-reviewed source, such as one of the ones below (see SOURCES).
- Bring it to me and tell me why you chose it (briefly). I want you to choose a paper because (a) it is similar to what we are doing, or (b) it sounds cool, like something you'd want to do someday...
- SOURCES:
- GECCO conference proceedings:
- GECCO 2004: Most recent.
- Go to the GECCO-2004 web site.
- Also, here is a link to the on-line proceedings at the publisher's web site (copy and paste the following address into your browser)
- http://springerlink.metapress.com/app/home/issue.asp?wasp=6ealupyxxj5w70lxgndm&referrer=backto&backto=journal,167,1803;linkingpublicationresults,1:105633,1;&absoluteposition=2#A2
- Problem is, this only shows you the TOC and abstracts, not the full text of the article. What do you expect for free? Still, this will help you browse the papers and give you the reference information for requesting one.
- GECCO 2003 (we already have these on-line, password access, thanks to Jacob! Click here. See your email for username and password.)
- GECCO 2002
- GECCO 2001
- GECCO 2000
- JOURNAL of ARTIFICIAL LIFE AND ROBOTICS:
- JOURNAL OF ADAPTIVE BEHAVIOR
- JOURNAL OF GENETIC PROGRAMMING AND EVOLVABLE MACHINES
- JOURNAL OF ARTIFICIAL LIFE
- Explore the papers by looking at titles and abstracts. Pick one related to our work.
- Get it. First search on-line (e.g., GOOGLE (try out the new scholar.google.com) or our own on-line library subscriptions) to see if you can find an on-line full text copy of the article. If you cannot get it there, go to inter-library loan and ORDER IT!
We are now ready to experiment and explore. Your final project is to design, execute, and document an innovative experiment in evolutionary robotics. Note that, to the best of my knowledge, you will be the first doing this with 3DGS, and maybe the first doing this with a game engine!
The ultimate goal of this project is to find some new, publishable results. Toward that end, you are required to visit the following conference web site:
GECCO-2005 and explore it. In particular, look at the program track and tutorial for evolutionary robotics. Also, the CFP (call-for-papers) and the paper submission details. I intend to submit paper(s) to this conference, and I want you to generate the results (data) for OUR paper(s)! Whatever is ready to go by Jan. 17, that is what will be submitted...
As a first step in the project, here is an assignment to do BEFORE THANKSGIVING: Assignment 4 above.
Here are some useful files:
Here are some less useful files:
HERE ARE THE FINAL DETAILS: (12-13-04)
- Objectives:
- Same general objectives as above, but now I can be more specific: the goal is discovery, using our simulation code. I can think of at least three types of discovery that are now possible with our simulator:
- A clear case of adaptation through evolution, in which some genetic value(s) actually evolve(s) to a value very different from the initial value(s). For example, with the code I sent you in braitenberg.wdl, you can see that the robots' forward speed evolves, as does the range of their sensors, from the initial random values as the generations go by. Note that the evolved values should be well outside the range of initial random values. (This can be shown more clearly and easily, perhaps, if all the initial values are the same; e.g., start with all the initial sensor_width_angles set to 10. If the avg. eventually reaches 20, then that looks like evolution!) I would like to see two or more gene values evolve together (e.g., fwd_speed AND turning_speed).
- A controlled experiment, in which one and only one experimental parameter is varied, to get two different results. For example, if a run with interactive evolution turned OFF resulted in fast robots with narrow sensor_width-angles, while a run with interactive evolution turned ON resulted in slow robots with wide sensor-width_angles (all other run parameters being exactly the same!), then those results would reveal a direct, causal relationship, probably worth publishing!
- A case of emergence, in which the a truly interesting, surprising, perhaps even innovative, robot or robot strategy is evolved. For example, as I described by email, if the simulation "discovers" the ability to pass through walls by turning one's sensors backwards (even if this is an exploitation of a bug in the simulator, a mistake by the experimenter), this is still a case of emergence, of clever innovation by evolution, and I would happy to see it! But it must be unobvious, perhaps even surprising, and certainly "clever", to be a case of emergence (very subjective definition there, I know!). This might take quite a bit of careful observation, but I think it is a lot of fun.
- Tasks:
- Get the files you need (for your "GStudio6/work" folder): the first three are all in here
- rallycar.mdl
- sensor.mdl
- techdemo.wmp (or just follow the directions in "braitenberg.wdl" I sent, to modify your own "techdemo.wmp" file; does not take much...)
- braitenberg.wdl (I have sent this out by email on Monday; I don't want to post it on the web...)
- Follow the instructions in the comments at the top of the script file named "braitenberg.wdl", which I sent as an email attachment Monday, Dec. 13. Compile and run the simulation as is, to try it out. It should run like the published version I have put here.
- Once it is working on your GStudio, go read over the code in "braitenberg.wdl". The comments will tell you everything.
- Then start editing that code, and maybe the level itself using WED if you want to make changes to the environment, as the suggestions below. Edit->compile->run->edit, etc. You know the routine!
- Once you get some good, interesting results, tell me about them! Email is fine but in person might be easier. I will be in on Wed., Thursday, and Friday. Also, save your work! I eventually want a copy of all the files that you have modified, so that I can reproduce your results! I will set up a WebCT drop box for this, but I would be just as happy, or happier, with emailed files, a CD, a location on euclid or other server I can access, etc.
- SUGGESTIONS:
- I will give an A to anyone who can actually show the evolution of obstacle avoidance behavior in a digital Braitenberg vehicle. Imagine that if you evolve the fwd_speed and the turning-amount (angle, in degrees) FOR EACH ROW OF THE LOOK-UP TABLE (that is, 00, 01, 10, and 11, for a total of four pairs of outputs, speed, and turn angle, which is just eight total numbers to evolve), while maybe NOT evolving sensor configuration at all...
- The version of the code I sent you evolves fast cars with apparently narrow sensor_width_angles, which seems to make sense, given the large open room. But what about a different environment? Turning on interaction would make for a much more complex environment, with so many other robots running around, so maybe too complex. But how about a "statically" complex environment? For example, put MANY map entities, like blocks or cylinders, maybe all closely spaced, into the room. This is easy to do in WED. Then what do you evolve? Or how about just dragging Odin to another room (in WED)? Where ever Odin is, that is where the population will be. How about the hallway in techdemo? Much more confined than the Static Light room... Or maybe interaction, but with a much smaller population size...
- etc.
