Programming approach and conclusions:
As I had indicated before, Java was used as a development platform for the main reason of cross platform code portability. Several somewhat working versions of the program had been made throughout the course of the project development. As of writing of this paper, the final version has been modified and compiled. The current release is fully functional with the exception of simulation in the inverse kinematics module.
For the display of the manipulator a graphics engine was written with the significant effort put into it. This part of the project was highly supported with the knowledge acquired in CpE488D Computer Graphics course offered at University of Bridgeport, taught by Prof. Douglas Lyon.
As far as Java programming, all of my familiarity with this language comes from a CS410X Introduction to Java Programming course I had taken last semester, and CS411X Advanced Java Programming course I am taking now, both of which are offered in my school.
The 3D engine has some flaws concerning the ordering of the hierarchical model I am using. The flaw is within the actual ordering and placement of 3D faces before the rendering procedure which causes the model to look distorted in certain positions. There is a chance that this could be attributed to the possibility that the actual model might have some defective data. Autodesk's AutoCAD R13 and 3D Studio R4.0 were used to generate the model geometry. This has been done according to the very poor information found on Unimation's Web site (Fig. 4). This data was then imprinted inside several .class files which the application uses internally for the geometry representation.
Initially, the movement of the manipulator was going to be in the somewhat smooth fashion, sort of like an animation type simulation, but at the later time I discovered this to be very slow even on some of the high-end workstations this applications was tested on (Sun Sparc 5, PentiumPro 200, PowerPC 8100,…). This is why the simulation had been changed to the mere position change representations consisting of the initial and final positions. At this time with technology available, this performance is quite acceptable. The application has not yet been tested with a Just In Time (JIT) compiler/interpreter due the erratic behaviors of those I had a chance to use for my other projects. Also, some system platforms (Windows 95/NT) have been excluded from the JIT compiler society for now. It is my speculation that things are soon drastically to change when the JavaChip hits the market. According to Sun, these chips should increase the Java performance up to hundred times more than today's Java virtual machine interpreters.
Considering that not all of the potential users might have Java interpreters installed on their systems, the further step in the development was to build something I would call an "appletcation". Code which would act both as a full blown application which would work from within the OS and as an applet which can be used from within a browser such as Netscape or Internet Explorer. Distributed in this fashion, over the internet, the appletcation is still very usable, system independent, and easy to access.
Some important thing to mention are that when downloaded into the memory of the users computer, the appletcation uses this system's CPU resources for all of its calculations. Another thing is that the program runs in resolutions 800x600 and higher due to the implementation of the GUI.
Next...References, Resources, and Tools...
Back...Theory behind the project...