Copyright 1997 John Storrs. All rights reserved. This document and the work to which it refers may be copied, modified and distributed under the terms of the GNU General Public License. See the file COPYING in the distribution.
The LME's Computer Craftsmanship project aims to realise affordable computer aided manufacture for craft enterprise, educational and personal use - to achieve a revolution for the world of 3d artifacts which parallels the 2d desk top publishing revolution. Hexapod is a component of this project. It is a software model of an interesting machine tool and robot architecture which is being explored by a number of developers around the world. A platform rigidly supported by 6 legs in a triangulated configuration can be manipulated with 6 degrees of freedom by changing leg lengths. This is an old public domain idea whose time has come now that low cost computing power has caught up with it. The regularity and comparative simplicity of the mechanism make it an excellent candidate for the 'laser printer' which the 3d revolution requires. Hexapod is a highly parameterised model of a class of machine tools based on this architecture. The software generates a wealth of design data for a given configuration, describing geometry, forces and deformations as the platform is loaded and moved. It allows calibration strategies to be assessed using a linear programming solver. It also generates solid model descriptions for the povray ray tracer which can be used to produce photo-realistic images.
The software is in c++, developed under Linux. The release should compile and
run cleanly in a Linux environment with compatible versions of g++ and the
libraries. You are on your own with other environments. I currently use
g++-2.7.2, libg++.so.27.1.4, libstdc++.so.27.1.4, libm.so.5.0.6,
libc.so.5.3.12. You will need lp_solve for calibration simulation, povray-3
for solid model image generation, and an image viewer such as xv or
ImageMagick. To install and make under Linux, first unpack the compressed tar
$ tar xvfz hexapod-1.1.tgz
Build dependencies and compile the source tree:
$ cd hexapod-1.1
$ make depend
Check that your system and ours agree:
$ make check
Generate design data for the current configuration:
$ make data
Generate two sizes of povray ray-traced image as required:
$ make smallpov
$ make largepov
Generate calibration coefficients for inspection (inefficient and slow):
$ make coefficients
Simulate a calibration strategy, generating and solving linear inequalities:
$ make calibration
Delete class object files in the source tree if required:
$ make clean
Delete all dependencies and object files in the source tree if required:
$ make realclean
You can use these make commands in the sub-directories as well as at the top level, but they don't propagate upwards. Working in a sub-directory is very convenient when exploring configurations. Do a top level make first so the class sub-directory object files exist and are up to date. More in section 4 below.
The source tree sub-directories, in logical order, are:
|maths||vector and matrix classes|
|artifacts||artifact and primitive modelling classes|
|hexapod||hexapod machine modelling classes|
|files||output file definitions|
|current||symbolic link to a machine version|
|version1||a machine version|
|check||a machine version configured for checking|
|design||machine version sub-directory for generated design data|
|rendering||machine version sub-directory for generated povray files|
|calibration||machine version sub-directory for calibration simulation|
The vector and matrix classes are central to the working of the artifact and hexapod classes. It would be very difficult to handle the mathematics of the hexapod architecture without them. There are a number of free c++ vector and matrix packages available. I have chosen the excellent package provided by Jean-Francois Doue in Graphics Gems IV. I have modified and extended his work in small ways. Thank you Jean-Francois.
The artifact and primitive classes implement the core of the hierarchical artifact modelling system required by the Computer Craftsmanship project. An artifact is composed of artifact and primitive instances. It can be viewed as a tree with artifact instances at the inner nodes and primitives at the leaves. Artifact instances have a transformation which is a property of the instance. Primitives are terminals which give substance to the artifact, which otherwise would be only empty mathematics. These classes are the beginning of a general purpose modelling system for artifact products of the Computer Craftsmanship system. The primitive classes will be much enlarged, extending the constructive solid geometry primitives, and implementing manufacturing features generated by simulated cutter motion. The present state of the classes is adequate for a model of the hexapod architecture as its first test.
The hexapod classes use the classes described above to construct a mathematical model of the LME hexapod machine. There is (or rather should be) a class for each machine component which implements it in terms of sub-components and primitives. The principal elements are the frame and bed, which are static, and the mechanism, which is dynamic. Each of the main classes can generate its part of the machine geometry for ray tracing. This functionality derives from the artifact and primitive classes. The mechanism also implements the data reporting functionality, relying heavily on the vector and matrix classes to do so.
The machine version sub-directories contain a function
defineParameters.C, which you should edit to change parameter
values, and source for the programs, generateDesignData,
generatePOVSource, generateCoefficients and
simulateCalibration. Output from the programs, which can be called
directly or via make, is placed in the design,
calibration sub-directories. The symbolic link current allows
compilation and data generation for the current version from the top level
makefile. To create a new version, make a copy of the version1
directory and contents, calling it what you will:
$ cp -a version1 new-version
$ cd new-version
Edit defineParameters.C, and you can make from within the directory (after a top level make depend; make):
$ make data
$ make smallpov
Etc. You can relink 'current' to the new version for convenience with:
$ cd ..
$ ln -snf new-version current
Design data output is determined by generateDesignData.C which exercises the model with calls of HexapodMechanism class methods within nested for-loops. The platform orientation and applied cutter force can be changed by editing this file. The data generation strategy is to move the cutter over an xy plane recording data values on a square grid, repeating for different z levels. With this background the meaning of the output files should be clear. There is a minor bug which I haven't traced which occasionally leaves all data output files zero length. Just run make data again if that happens.
Solid model output is determined by generatePOVSource.C, which can be edited to change the platform position and orientation for a snapshot. The resulting program generatePOVSource places its output, POVSource, in the sub-directory rendering This contains the povray driver script hexapod.pov which can be edited to change the camera position and lighting. You need to know a bit about povray to do this, but not a lot. Some guidance is provided by sample files hexapod.pov.ELEV, hexapod.pov.PLAN and the makefile. You must have povray set up properly before you start.
Calibration coefficients relate small changes in base parameters (top joint coordinates, closed leg lengths etc) to resulting changes in platform node position. They are generated for inspection by the program generateCoefficients, which puts its output in the sub-directory calibration. Edit generateCoefficients.C to limit the amount of data produced.
With calibration simulation the idea is to predefine a set of errors in the base parameters, plus a maximum noise level in calibration measurement readings. Then to take simulated measurements with the imperfect machine following some strategy - the measurement values are calculated using the calibration coefficients described above. Finally to generate and solve linear inequalities with the base parameter errors as the unknowns and the (noisy) measurement values as the constants. We use the free linear programming solver lp_solve to find a solution. If the solution matches the input sufficiently closely the strategy might be a viable calibration method for a real machine. Look at simulateCalibration.C and the variants in the calibration sub-directory to see how to control the process.
The LME's Computer Craftsmanship project and this work have been enabled by support from the European Commission.
Comments and offers of help with the project will be welcome.
John Storrs, June 1998
Laboratory for Micro Enterprise,
125 Culham 1 Site, Culham, Abingdon OX14 3DA, UK
Phone and fax (44) (0)1865 407085. Email firstname.lastname@example.org
Home Page http://www.i-way.co.uk/~storrs/
|LME Hexapod Machine||Computer Craftsmanship|