GovernorResearchProgramLog

Outline of Research Program

Set up separate CVS for experimental files
Make the scripts that generate multiple trials more robust and brain file independent
Run various modifications to the already completed research

Compare to fixed sample rate learning
Develop methods of RAVQ/governed network visualization
Explore methods to statistically compare the governed dataset with ungoverned dataset

Sample files and results are on /scratch/moses
Motors are not scaled but sensors are scaled in sample files
Motors are scaled in brain files while sensors are not
It would be slightly faster to scale motors as well as sensors in the sample file

Rewrote the brain files and put the new ones in brains/revised. I was going for too much generality and in the end decided only to separate out only the governor code in addition to the wall follow code.
I'm having a weird bug where the value returned by get('range', 'count') is 0 and should be 16.

A few bugs to iron out before pushing out some trials on the new governor brain (more options can be set from the command line), the discrete sample brain, and the random sampler brain.
I want to make the random sampler governor more sophisticated by making the distribution modifiable. What kind of distribution of sampling is going on with the governor? How will this compare to a fixed distribution?
The spiral test seems to be unrelated to catastrophic forgetting, so this test will have low priority.
I'm still searching for a good dataset to do non-robotic task.
Xites with information on benchmarking data sets:

I wrote a script to collect some statistical data on the governor. I can use this to tune the random sampler governor to model the governor. I can also observe requency changes in different environments.

I wrote a world and a brain to try to implment this blobCamera-as-gradient idea.

It's in CVS: see governor/worlds/gradworld.world governor/brains/GradientBrain.py. It works with the Player1BlobCamera.py robot.
Currently all it does is load up the Joystick and start printing out the first blob from the data structure returned from the blob service.
You can see that the idea works: the area (2nd elemtent of the tuple) gets larger as we approach either colored wall.
The obstacles are invisible to the camera: basically it's as if there's some sort of chemical gradient, or (probably more directly analogous) a diffuse lightsource placed such that the obstacles don't cast significant shadows.

I want to write a controller that tries to get as close as it can to the blue wall, then turn around and get as close as it can to the red wall, while avoiding the obstacles in the middle. This might be considered a gathering task: there's some resource at the blue wall that needs to be brought home to the red wall. Thus we need to have a stateful controller (going out or coming back), and it probably can't be purely reactive, because there will be times (if the robot is facing directly sideways) that neither blob will be in view, so it won't know what to do.

I could spend some time working up a control for this or: Would it be feasible to simply take 10 or 20 runs of human controlled data? I don't think it would take all that long to just run the robot back and forth for (say) 1000 or 2000 times steps using the joystick. I could use those runs for offline training. Thoughts?

Working on the probabilistic governor control as well as the localization task. For some reason using the blob camera makes the wall follow controller unusuable. Some sort of latency issue in combination with some stage issues?
Work on discrete sampler brain. What happens when the sample rate is the mean?

The sampling mean for the governor on tutorial.world data is consistantly 8 time steps. I'm going to run a set of tests to determine if a discrete sample sampling at the mean will perform comparably to the governor.
Trying to decide how to segment a world into regions for the localization task. I'm going to run some preliminary experiments with just two room separation. More might require a different world.
Also, it might be wise to begin training the network only after the governor has fully initialized, ie. the governor hasn't added any new model vectors for awhile.

They trained on room 3 last, and that's how they identified every room in the training run.

The more complicated world confuses even the governed network a bit in room 4.
The 95% confidence interval for network error over 1000 steps (governed, training 5000):

The 95% confidence interval for network error over 1000 steps (ungoverned, training 5000):

Here's a nice image of the model vectors produced from an adaptive ravq version of the governor.

It appears that there is no change in performance in switching to the adaptive ravq in W1. I will test world two next. While there is no performance increase, the number of model vectors created and used does decrease, which may be computationally important for more complicated governed tasks.
I've completed and collected experimental results for the localization experiment for both W1 and W2 and have compiled all the testing error data into gnumeric files for confidence interval and statistical description. Basically, the results show that the different governor architectures, ravq, aravq, and balancing buckets, all are equivalant on W1 and W2, and all are better than a standard network.