first version of README
This commit is contained in:
josch
parent
cb988c68d9
commit
560227cecf
1 changed files with 209 additions and 0 deletions
209
README.md
Normal file
209
README.md
Normal file
|
|
@ -0,0 +1,209 @@
|
|||
get the code
|
||||
============
|
||||
|
||||
$ git clone git@github.com:josch/sisyphus.git
|
||||
$ cd sisyphus
|
||||
|
||||
|
||||
compile evaluation library
|
||||
==========================
|
||||
|
||||
$ wget http://sourceforge.net/projects/moast/files/Pallet%20Viewer/Version%203/palletandtruckviewer-3.0.tar.gz
|
||||
$ tar xf palletandtruckviewer-3.0.tar.gz
|
||||
$ cd palletandtruckviewer-3.0
|
||||
$ patch -p0 < ../palletViewer-sharedlib.diff
|
||||
$ autoreconf -fi
|
||||
$ ./configure --libdir=`pwd`/..
|
||||
$ make
|
||||
$ make install-strip
|
||||
$ cd ..
|
||||
|
||||
test evaluation library (optional)
|
||||
==================================
|
||||
|
||||
$ python evaluate_multi.py examples/icra2012/packlist_R1.xml examples/icra2012/scorecog.xml
|
||||
|
||||
$ python evaluate.py examples/icra2012/Challenge2.order.xml examples/icra2012/packlist_R2.xml examples/icra2012/scorecog.xml
|
||||
|
||||
$ python evaluate.py examples/icra2012/Challenge2.order.xml examples/icra2012/packlist_R3.xml examples/icra2012/scorecogoverlap.xml
|
||||
|
||||
generate packlist files
|
||||
=======================
|
||||
|
||||
$ ./run.sh examples/icra2011/palDay1R1Order.xml packlist.xml examples/icra2011/scoreAsPlannedConfig1.xml
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
bruteforce2.py takes an order.xml and tries different strategies to create many
|
||||
lists of layerlists. Each layerlist is built with a different selection of
|
||||
strategies. Available strategies are article rotation and pallet rotation which
|
||||
can both be either true or false. Per default, bruteforce2.py tries all
|
||||
combinations of article and pallet rotations, which means that for each new
|
||||
layer, there are four possibilities how articles can be arranged in it.
|
||||
|
||||
A layerlist is the result of one specific combinations of strategies. For
|
||||
example: first layer with article rotation and pallet rotation, second layer
|
||||
without article rotation but with pallet rotation, third layer with neither and
|
||||
so forth.
|
||||
|
||||
bruteforce2.py outputs those layerlists one per line in python pickle gzipped
|
||||
and base64 encoded format. Python pickle is used as a fast serialization
|
||||
format. The data is gzipped because it is given to bruteforce3.py as a
|
||||
commandline argument and those must not exceed an OS specific value. The data
|
||||
is base64 encoded to avoid zero bytes, newlines and other whitespace characters
|
||||
in them.
|
||||
|
||||
As a result, the output of bruteforce2.py can not only be saved in a file, but
|
||||
you can also used split(1) on it to distribute it onto many machines for
|
||||
evaluations. You can also use head(1), tail(1), sort(1) or uniq(1) on the
|
||||
output.
|
||||
|
||||
bruteforce3.py takes as arguments an order.xml, a packlist.xml output file, a
|
||||
scoring.xml file and a number of layerlists, encoded as described above. For
|
||||
each layerlist it will try every possible permutation of how to place them on
|
||||
top of each other and evaluate each of them by using palletViewer.
|
||||
|
||||
Multiple instances of bruteforce3.py can be run on the same machine. Before
|
||||
bruteforce3.py exits, it will put a file lock on score_max.lock and read the
|
||||
currently highest score from score_max. If the just calculated score is higher,
|
||||
it will write its own score into score_max and update the contents of
|
||||
packlist.xml as well.
|
||||
|
||||
Since score_max always contains the currently highest score, it can always
|
||||
easily be checked during a run, what the currently highest score achieved is.
|
||||
|
||||
Since packlist.xml always contains the best packlist found so far,
|
||||
bruteforce3.py can always be aborted in the middle of execution, should it take
|
||||
too long to evaluate while still maintaining the current best packlist. One
|
||||
does not need to wait until run.sh finished execution.
|
||||
|
||||
Since score_max contains the highest score, it should be removed before each
|
||||
new run. This is already done by run.sh.
|
||||
|
||||
environment variables
|
||||
=====================
|
||||
|
||||
bruteforce2
|
||||
-----------
|
||||
|
||||
rot_article - try different article rotations (default: True)
|
||||
rot_pallet - try different pallet rotations (default: True)
|
||||
rot_article_default - default article rotation (default: False)
|
||||
rot_pallet_default - default pallet rotation (default: False)
|
||||
iterations - maximum number of iterations (default: -1)
|
||||
randomize - try random strategies instead of sequential (default: False)
|
||||
|
||||
bruteforce3
|
||||
-----------
|
||||
|
||||
multi_pallet - respect pallet max height and spread over multiple pallets (default: False)
|
||||
permutations - whether to try all layer permutations or not permute at all (default: True)
|
||||
iterations - maximum number of iterations (default: -1)
|
||||
randomize - try random strategies instead of sequential (default: False)
|
||||
|
||||
For orders that are too big to enumerate all possible permutations of layer
|
||||
strategies and orderings, using randomize and iterations for bruteforce2.py and
|
||||
bruteforce3.py is recommended.
|
||||
|
||||
The according line in run.sh could be changed to:
|
||||
|
||||
iterations=100 randomize=1 python bruteforce2.py $1 | randomize=1 iterations=1000 xargs --max-procs=4 --max-args=1 python bruteforce3.py $1 $2 $3
|
||||
|
||||
utility scripts
|
||||
===============
|
||||
|
||||
add_approach_points.py
|
||||
|
||||
takes a single or multi pallet packlist.xml and adds the three approach
|
||||
points to all the articles in it, relative to each articles position
|
||||
|
||||
barcodes.py
|
||||
|
||||
takes an order.xml and prints all barcodes in it
|
||||
|
||||
densities.py
|
||||
|
||||
takes an order.xml and prints the density of all articles
|
||||
|
||||
descriptions.py
|
||||
|
||||
takes an order.xml and prints a table with the description, ID, type,
|
||||
family, size and weight of every article
|
||||
|
||||
evaluate_multi.py
|
||||
|
||||
takes a multiple pallet packlist.xml and a scoring.xml and prints out
|
||||
the score that this packlist achieves
|
||||
|
||||
evaluate.py
|
||||
|
||||
takes an order.xml, a single pallet packlist.xml and a scoring.xml and
|
||||
prints out the score that this packlist achieves
|
||||
|
||||
num_articles_order.py
|
||||
|
||||
takes an order.xml and prints the number of articles within
|
||||
|
||||
num_articles_packlist.py
|
||||
|
||||
takes a single or multi pallet packlist.xml and prints the number of
|
||||
articles within
|
||||
|
||||
pallets.py
|
||||
|
||||
takes an order.xml and prints a table with the length, width, maximum
|
||||
load height and maximum load weight
|
||||
|
||||
split_multi.py
|
||||
|
||||
takes a multiple pallet packlist.xml and outputs pairs of single pallet
|
||||
packlist.xml and order.xml files by appending _$i.xml and _order_$i.xml
|
||||
to the original packlist.xml filename, respectively. The integer $i
|
||||
starts at 0 and will be incremented with each subsequent pallet.
|
||||
|
||||
evaluation of multi pallet packlists
|
||||
====================================
|
||||
|
||||
palletViewer cannot parse multi pallet packlists, hence the packlists have to
|
||||
be split into several single pallet packlists. Each of those packlists is then
|
||||
given to palletViewer for evaluation. The individual results are averaged for a
|
||||
final score. To avoid each of the palletViewer instances complain about missing
|
||||
articles, an according order.xml file is created for each single pallet
|
||||
packlist.xml.
|
||||
|
||||
Multi pallet packlists can evaluated like this:
|
||||
|
||||
python evaluate_multi.py packlist.xml scoring.xml
|
||||
|
||||
Or manually like this:
|
||||
|
||||
python split_multi.py packlist.xml
|
||||
python evaluate.py packlist.xml_order_0.xml packlist_R1.xml_0.xml scoring.xml
|
||||
python evaluate.py packlist.xml_order_1.xml packlist_R1.xml_1.xml scoring.xml
|
||||
...
|
||||
|
||||
bugs
|
||||
====
|
||||
|
||||
there is a "memory leak" in bruteforce3.py. Every loop iteration where a new
|
||||
permutation is tried out will stay in memory. This is not needed and should not
|
||||
be the case. This is the reason why run.sh supplies bruteforce3.py with only
|
||||
one layerlist at a time because otherwise, memory consumption would grow too
|
||||
big.
|
||||
|
||||
ICRA 2012 VMAC
|
||||
==============
|
||||
|
||||
Sisyphus won the IEEE ICRA 2012 Virtual Manufacturing Automation Competition.
|
||||
Here is some media about our submission:
|
||||
|
||||
Round1: ./examples/icra2012/packlist_R1.xml
|
||||
|
||||
Round2: ./examples/icra2012/packlist_R2.xml
|
||||
|
||||
Round3: ./examples/icra2012/packlist_R3.xml
|
||||
|
||||
announcement: http://youtu.be/8fYF-Ldi1NQ
|
||||
|
||||
presentation: http://youtu.be/FSqjGiVt50I
|
||||
Loading…
Reference in a new issue