Success!

I finally solved the user-created Schema problem last night. The issue was that the MainBody field in LearnerUI was created, but not initialised until the actual simulation was started (as opposed to the main GUI). This explains why Schemas with no States worked, and why it was possible to edit Schemas while the simulation was running.

I changed the LearnerUI class to initialise the MainBody immediately, and also changed MainBody so that the initial Schemas are not added until the start of the simulation.

It's a little annoying that the problem was so simple, but it's working now anyway.

The code is (mostly) commented and a few tweaks to the "One Step" feature should be all that needs to be done.

Meeting 14

Had a meeting this morning to discuss the final report. I'm aiming to have it completed by this time next week so that it could be handed in as is, or tweaked based on Frank's advice.

This is the last meeting before the software submission deadline on Friday. It's a soft deadline, so I don't have to hand anything in, but I want to get the code finished and concentrate on the report.

Also, I've tracked the user-created Schema problem back to a null-pointer exception, most likely involving the MainBody. My early testing looks promising. There's a chance I'll get this issue fixed after all!

Meeting 13

Daniel is giving his presentation in the same session as mine on Thursday. We felt it best to collude slightly so that we weren't giving presentations so similar that we were repeating each other, but also so we weren't contradicting each other and confusing the audience.


Myself and Frank solved the "stepping" issue by placing the switch in the MainBody class, rather than Processor. The code needs cleaning-up, but the feature is working now.

Parsing the Exported Schema Library

I've just implemented the XML schema importing. I used the in-built java SAX parser and wrote an XML event handler myself to pull the appropriate variable data and create the Schema objects.

The problem executing the imported Schemas is still there though.

Meeting 12

Had a meeting this afternoon to catch up on progress made over the holidays and to discuss what more can be done before the deadline.

Other than the importing of Schemas, which should be implemented by tomorrow, there isn't much. Frank would like me to add a feature to allow "stepping through" the simulation one movement at a time like a debugger. I can see how to implement this using a simple boolean switch, but I'm not sure where it needs to go. At the moment, the simulation continues a step at a time, but the graphics aren't updated to match.

I have another meeting scheduled tomorrow with Daniel to discuss our presentations later this week. He might have a better understanding of the graphics code.

Exporting the Schema Library

The last planned feature is almost fully implemented. The library is successfully written to an XML Schema validated file. I'm still reading up on SAX and DOM parsers so Importing hasn't been implemented yet, but I don't foresee any problems with the parsing.

While writing the output methods, I removed a few unnecessary methods from the Schema class and discovered that the schemasValue, and activeSchemas hashtables haven't been included in the output. These have never shown up in exception stack-traces before, but they could be related to the Schema execution problem somehow. Either way, I need to edit the code to account for them.

Editing Schemas Update

I haven't fixed the XML Schema, but it seems too trivial a detail to devote much more time to at the moment. I have added functionality to the EditSchemaDialog to allow the user to edit the activeStates table for each State. I've also re-written the NewSchemaDialog to match, and cleaned up the Schema creation code.

Other than adding support for XML, I don't intend to add any more new features to the GUI. There are only a couple of weeks until the Software Submission deadline, and I feel that they would be best used testing and fixing bugs.

XML Schema Issue

I would still like the option to export the Schema Library to an XML file so I've been working on writing an XML Schema file to validate against.

I'm familiar with XML, but I've never worked with XML Schema before. I understand it for the most part, but I've run into an error when it comes to validating. The validator output is not very helpful! All I can tell for now is that:

Element 'element' is invalid, misplaced, or occurs too often.

I'm not sure that the XML Schema is required to parse an XML document successfully, but I'd prefer to have it just in case. Of course, this is a relatively minor feature so I don't want to spend a huge amount of time on it at the moment.

Editing Schemas

I've spent the last few days writing a dialog to display the details of a selected Schema and allow the user to edit them. As far as I can tell, the result of editing a Schema (especially a State) is the same as creating a new one from scratch.

Putting time and effort into features which ultimately don't work seems a bit pointless, but as Frank pointed out, it's an extra feature that I can "show off" in the software demonstration.

Testing Schemas

I'm still having problems with the creating new schemas. In order to test, I've set the "Import" button to recreate a Schema object from the library and add it manually. I found that a created Schema with a Response but no States executes correctly, leading me to believe that the problem is in the State object.

However, a Schema with Response and both states fails to execute. In the first instance, State 1 had a null value for activeStates, State 2 was "full". A second Schema with Response and both States "full" also failed to execute.

I'm putting all my effort into creating Schemas at the moment. Creating and parsing XML is relatively easy, but useless if the Schema objects created from it won't execute. The next thing I'm going to try is editing existing Schemas. If I can change objects that already exist and work, it might shed some light on why creating schema objects from scratch doesn't.

A small measure of success

After ignoring the Import/Export issue for the last few days, I've finally implemented a method of setting the block position while the simulation is running.

It needs some more robust error-handling, but as I'm so far behind schedule any progress is welcome.

Progress?

Not really.

I'm still stuck with the problem caused when executing user-generated Schemas. I think I've narrowed the problem down to the State class, but I can't get any further! I've spent the last 3 days focusing on this and to say I'm frustrated is an understatement!

I'm going to leave this for now and work on setting the position of the block via the GUI. Once that's done I'll try to formalise what I know about the schema problem and see if Frank and Daniel have any ideas.

Generating XML - An easier way?

As a personal project, I once hacked together a small program to convert my old plain text IM logs to the Adium XML format. This was only a converter, it didn't deal with parsing the XML, just outputting it to a file. After some searching I found the xmlenc library on SourceForge. It seems to be much lighter and easier to use than SAX or DOM, while being far more stable than anything I have time to write myself.

A friend has recommended that I try XStream. I've never heard of this before, but it looks good after a quick scan of the website. The main advantage here seems to be that it will read the file back in again, creating objects automatically.

I'm leaning toward the familiar at the moment. That might change after some more reading though.

Meeting 11

Short meeting today just to check on progress and assign tasks. Our next meeting will not be for a few weeks, as it is the Easter break and Frank is organising the AISB conference.

Due to the break, I have been at my parents house and not had much time to dedicate to project work. I have cleaned up the variable torque code by passing a floating point value rather than an integer. This has the effect of doubling or halving the torque value by simple multiplication instead of the round-about method I originally implemented.

I have the following tasks to complete as soon as possible.

• Clean-up of the schema library Import/Export code

The main issue is that Schemas which have been manually added or imported from a file cause an exception when executed. This is priority 1 for now.

It would be nice (but not essential) to export the schema library as XML. I have used a nice tag generation library in personal projects, but there might be a simpler way. The SAX and DOM parsers are probably worth looking at.

• Specify the block position through the GUI

As my learning task now only requires one "interesting" object, I would like to add a GUI feature which would let the user position the block manually. Most likely through the use of co-ordinates.

In addition to the above, there is also basic error-handling to be implemented in most cases.

These features don't really affect the learning simulation, but will allow me to show some success during the software demonstration in a few weeks time.

Meeting 10

Finished adding the mechanism to allow strong and weak arm movements. Currently, the torque to be applied to a movement is calculated by a method in the UpperArm and LowerArm classes. I have modified each class to apply a multiplier to the torque value before executing the movement. The multiplier is specified by an integer value in a Response object, which is attached to a Schema as normal. This could do with being cleaned up a little, but will have to wait until I have more time.

We also discussed a new file format for the schema library. This is primarily to include new aspects of the Schema class, but will hopefully provide an opportunity to fix the schema importing issue that has been bugging me for weeks! Frank suggested a new comma-separated values approach, whereas I would prefer to go with XML. The CSV format is easier to read manually, but I believe XML would be easier to parse inside the program.

Either way, I want to get these issues dealt with as soon as possible as I am now behind schedule as far as the project plan is concerned. I aimed to have the coding finished by the end of this week to leave me free to concentrate on the report. That will now have to wait.

First unforseen failure

It seems that something has corrupted the UpperArm, LowerArm and Response classes since I last worked on them yesterday. This is the first issue I've had with Netbeans, although I haven't found anything related to this on any Netbeans forums. It seems like simple bad luck! Haven't lost too much though. Subversion is doing its job!

It's a bit of a pain, coming just before my meeting with Frank tomorrow morning.

Interesting Rate never changes?

Changing the torque values is coming along nicely. I've not looked at the issue involving manually creating schemas, but I've noticed that the interestingRate field in Schema is always 0. How does the learning mechanism work?

Meeting 9

First one-to-one meeting with Frank. I explained the schema loading problem in detail, but he was unable to spot an obvious problem. It's beginning to annoy me as I originally wanted to have feature freeze by March 21st, and the ability to import schemas is central to making the learning simulation usable. Despite its importance, I'm putting this work on hold for the week to start on the learning task, which I've had to delay for a while as a result.

The first part of the learning task involves adding a method to change the torque value applied to the arm. This will allow the arm to move with varying degrees of force before striking an object. With Frank's help, I've isolated the code where the torque value is generated and decided that the best way to change it is by adding a new "torque multiplier" argument to the appropriate methods in the UpperArm and LowerArm classes. The multiplier will then be passed through from an updated Response object, which will contain the multiplier value.

As was the case last week, I'm confident of getting this done by the next meeting. The Easter break is fast approaching and I'm hoping to stay as close to schedule as possible.

Meeting 8

Still working on loading the schema library. I'm often finding that there's "gaps" in the data being read from the file. This is probably caused by a bug in the Schema.toString method, but I can't pin it down at the moment. I'd really like to use XML when exporting the library, rather than the comma separated values I have at the moment. I feel this would make things far easier when reading the file back into the program, but like everything else it depends on how much time I have.

My learning task was described in more details, and can be broken down into two main parts. I'm expected to get the first part done by the next meeting. I'm fairly confident I can achieve this although I will be using a lot more of the graphics and physics code than I have up until now. Joey has written up a document formally explaining the aims, and Frank has offered to point me in the direction of the relevant code.

Until now, myself and Daniel have been combining our code to create a stable, usable simulation. This will no longer be the case, as we are now working in different directions. Daniel will continue to work on the vision tasks, while I polish the GUI and work on causing secondary actions with the arm. As a result of this we will be holding separate weekly meetings with Frank from now on.

Integration Issues

There seems to be a problem with the Subversion repository. The code Daniel committed as Revision 9 has overwritten some of my Revision 8 changes. It's an easy enough, but time consuming fix. Especially when the point of the repository was to avoid this in the first place.

I'm also finding a compiler error in the Processor class. Arguments are being passed to a method without having been initialised, and I can't see what they are supposed to be. I'm still struggling to find consistent internet access, so I might not get a solution to this until our weekly meeting.

Creating new Schemas

Have just integrated the schema creation process into the GUI. My internet access has been restricted recently so I haven't committed changes to the Subversion repository in a while. I'm waiting on Daniel to commit his code before merging mine. The dialog has no real error checking, and the logic for choosing a Schema constructor is a little rough, but it works! Loading schemas from a file should be relatively simple now that I can make use of these methods.

Meeting 7

Finally, some progress! The export to file feature is working, albeit without the JFileChooser component. I still want to implement this in the future if time allows. My next task is to finish the import feature, which should be made easier by implementing a process allowing schemas to be added manually. The main problem I'm finding with this is deciding which Schema constructor should be called, depending on the values given in the GUI.

Once the GUI is in a stable condition, Frank has suggested that I attempt to implement a learning task where the arm will strike an object from above with varying levels of force to create a noise. The faster the arm moves before the collision, the louder the noise it will make. I can see some problems arising from my lack of familiarity with the graphics and physics models, but it should be an interesting task to undertake.

Meeting 6

Not made a great deal of progress regarding loading and saving the schema library since the last meeting. Changing the JFileChooser properties from the Netbeans GUI builder is the main problem I've encountered so far. I would prefer to use the JFileChooser as it includes a lot of error-handling methods, but a simple text dialog box would be acceptable for now.

I have also run into a problem with creating schemas manually in the GUI. Currently the Schema object constructors require State and Response objects to be passed as arguments, complicating the GUI dialog. My solution to this for now is to create new Schema constructors with take all the values stored by the schema and create the appropriate States and Responses.

Meeting 5

Had a short meeting this morning to check on progress.

Daniel has written some interesting methods in the Processor class to help with manually choosing a schema to execute. There was a discussion about the file format in which to save the schema library. It was decided that plain text is more suitable than a serialised object given the ability to edit the file by hand if needs be. As I am writing the load/save feature, creating a file format has also been assigned to me.

I was also asked to implement a method of adding a schema to the library manually. This should be relatively simple, and I hope to have this done by the next meeting.

Meeting 4

Daniel provided an archive containing the newest revision of his code. I've now merged my code and commited it to the subversion repository [revision 2]. My tasks for this week are to continue working on the GUI and, if possible, clean-up the ListModel syncing.

The main GUI task is to allow the loading and saving of schemas. Daniel is handling the backend and will most likely be dumping the schema library to a text file which can be parsed back in again. The frontend should be simple enough(!) as there is the JFileChooser Swing component already written. Although I've never used this component the Swing API looks like it has a helpful tutorial.

ListModel problem solved (for now)

After looking at Daniel's newest version of the code, where the Vectors containing Schemas have been replaced by ArrayLists, I have given up on automatically syncing the two data structures. The quick-and-dirty fix is simply to find every action which changes the ArrayList, and perform the equivilent action in the ListModel. This works well for the moment, and any progress is good, but I'd like to re-visit this and find a more elegant way to do it. One thought I have at the moment is to write an add/remove method in the Processor class which would take a schema as a parameter and add/remove is from both structures. Something like this should act to keep things in sync, so long as it is used everytime in place of modifying the structures directly.

Vectors and ListModels

For the last few days I've been trying to show the library of schemas and the current active schemas in jLists on the GUI. Each list of schemas is currently stored in a public Vector in the Const class, so accessing and displaying them from the GUI should be easy.

That seems to be only partly correct...

Accessing the Vector is fine, but displaying it in the jList is causing a major problem. I think the problem is caused by using passing the Vector directly to the jList constructer. This is allowed, but doesn't seem to take into account changes to the Vector itself. The solution looks like defining a ListModel, and making changes to that rather than the Vector. The problem with this is that apart from writing my own ListModel class, there doesn't seem to be a way to use a Vector to create a ListModel.

After spending a few days on this, I'm starting to consider just writing my own ListModel. Hopefully this will be simple enough, although I'd rather use a tested solution than hack together a link between such important components.

Subversion

Our Subversion repository has been created! There's nothing in it yet, but that should change in a couple of days.

Another Paper

Intelligence without representation, Rodney A. Brooks (PDF)

Abstract:
Brooks, R.A., Intelligence without representation, Artificial Intelligence 47 (1991) 139-159.

Artificial intelligence research has foundered on the issue of representation. When intelligence is approached in an incremental manner, with strict reliance on interfacing to the real world through perception and action, reliance on representation disappears. In this paper we outline our approach to incrementally building complete intelligent Creatures. The fundamental decomposition of the intelligent system is not into independent information processing units which must interface with each other via representations. Instead, the intelligent system is decomposed into independent and parallel activity producers which all interface directly to the world through perception and action, rather than interface to each other particularly much. The notions of central and peripheral systems evaporate-- everything is both central and peripheral. Based on these principles we have built a very successful series of mobile robots which operate without supervision as Creatures in standard office environments.

Meeting 3

The GUI is progressing nicely after talking with Frank. The Start and Pause buttons are working. The Stop function is still causing problems, probably due to threading issues. Daniel is still working on the eye and arm code. Once the GUI is usable, my next task is to implement the third stage of Piagetian development. This involves the arm striking an object to produce an interesting result. The Project Plan has been handed in. Frank is going to talk to Ernesto Compatangelo about setting up a Subversion repository on the DIT servers. I've also got a fair bit of reading to do, but I'll create separate posts for each paper.

Some more reading

The Constructivist Learning Architecture: A Model of Cognitive Development for Robust Autonomous Robots

Abstract:
Autonomous robots are used more and more in remote and inaccessible places where they cannot be easily repaired if damaged or improperly programmed. A system is needed that would allow these robots to repair themselves by recovering gracefully from damage and adapting to unforeseen changes. Newborn infants employ such a system to adapt to a new and dynamic world by building a hierarchical model of their environment. This model allows them to respond robustly to changes by falling back to an earlier stage of knowledge, rather than failing completely. A computational model that replicates these phenomena in infants would a mobile robot the same adaptability and robustness that infants have. This dissertation presents such a model, the Constructivist Learning Architecture (CLA), that builds a hierarchical knowledge base using a set of interconnected self-organizing learning modules. This dissertation then demonstrates that CLA (1) replicates current studies in infant cognitive development, (2) builds sensorimotor schemas for robot control, (3) learns a goal-directed task from delayed rewards, and (4) can fall back and recover gracefully from damage. CLA is a new approach to robot control that allows robots to recover from damage or adapt to unforeseen changes in the environment. CLA is also a new approach to cognitive modeling that can be used to better understand how people learn for their environment in infancy and adulthood.

It looks interesting, but a bit too much to read in one go. Parts 5 and 6 seem to be most relevent.

Threaded GUI Issues

Having some trouble getting the LearnerMainFrame class to play nicely with my new GUI class (LearnerUI). Controlling multiple threads is the main problem at the moment. Im going to check out the SwingWorker class. It looks like it should do what I want, which is simply to start and stop (and if possible, pause) the LearnerMainFrame without killing the LearnerUI instance.

I'm considering changing the LearnerMainFrame class to add new methods start, stop and pause methods, but I'm a little wary about making changes to common code without a real VCS. I raised the issue of setting up a Subversion repository in Meeting 1, but it was considered unnecessary at this stage. I'll raise it again next week.

Like the rest of the project, the GUI has become far more complicated. I'm hoping it becomes a little easier once I get used to using Swing again!

Meeting 2

Vision code is now working with random schemas. Daniel is taking starting work on the arm until the GUI is ready.

I've had trouble installing the Eclipse Visual Editor plugin (It doesn't seem to be supported in Eclipse 3.3). I've installed Netbeans 6 to use the Matisse GUI builder. It's impressed me so far. I might switch permanently to Netbeans once the GUI is stable.

Piaget

Made-Up Minds, Gary L. Drescher

Chapter 2:
A synopsis of Piaget's theory of the development of sensorimotor intelligence.
Six stages within the sensorimotor period, each characterised by schemas that embody a new elaboration of problem solving.

Piaget's ideas always made sense to me, and look like they would carry over to this project. Especially the idea of schemas representing actions. My first year developmental psychology notes could be useful here.

First Post!

Firstly, I'm not much of a "Blogging" person. I definitely see the advantages to keeping notes on the progress of this project, but we'll see how long this lasts.

Secondly, acknowledgements. I have been given some code to start working on. It seems pretty robust so- far! The graphics/physics model was taken from Olivier Renault's PollyColly C++ demos and rewritten in Java by Frank Guerin. The business logic was then added by Joey Lam.

My first task is to write a GUI to show what's happening inside the business logic, and to allow schemas to be saved and loaded so that the "learning" doesn't have to start from scratch with every execution.

The next task after that is to write the code that actually does the learning regarding the movement of the arm. This will make heavy use of schemas and the "vision" code written by Daniel McKenzie.

I'm probably getting ahead of myself...